Procedural Creation of Medical Reports with Hierarchical Information Processing in Radiation Oncology

Background: For many years, the oncological doctor's letter has been the pivotal means of information transfer to general practitioners, medical specialists or medical consultants. Yet, both creator and recipient require a high level of abstraction, retentiveness and analysis due to the large number of diagnoses and therapies. In contrast to the commonly used structure of doctor's letters, where all diagnoses and therapies are listed in sequential order with all diagnoses first, it is by no means trivial to establish the important chronological and hierarchical context in the description of oncological cases. Additional aspects of importance are the integration of these letters into existing clinical and departmental information systems (for example via HL7 interface), various export formats (for example PDF, HTML), fax and encrypted email. Moreover these letters need a modern layout that, among others, meets the requirements of corporate design. Methods: The requirements for a doctor's letter system are manifold and can only be represented rudimentarily via a normal word processing system. Due to this deficiency we developed a system that covers all special features and requirements for clinical use. The system is based on a scalable and extensible client-server architecture. We use the programming languages Harbour, C++, PHP and JavaScript, Microsoft SQL database for data storage and the HL7 standard as the interface to other information systems such as hospital information system (HIS). Export formats are PDF, HTML/XML. Layouts are generated with TeX, LaTeX and MikTeX. Results: The aforementioned requirements were resolved with the doctor's letter and finding system IntDok. The hierarchical presentation of diagnoses, histologies and therapies provides the recipient with a first outline of the course of the disease. A strict procedure controls the whole process of document compilation and assists the user with many highly regarded tools such as text blocks, import and export (PDF and HTML/XML including barcodes) functions or HL7 interface to other information systems. The software also provides a sophisticated mail merging. All content from previous letters can easily be inserted into the current document. A TeX-server automatically provides document layout including supreme hyphenation so that uniform and perfect appearance (corporate design) is guaranteed. The documents are saved in a MS-SQL database (almost 230,000 documents since 1991), independent of any proprietary formats such as MS-Word. Conclusion: Creation of documents is fast, simple and well-structured. Sophisticated tools guarantee the optimal use of human resources and time. The system is an important module in our overall digital work environment.


Background and Subject
For many years, the oncologic doctor's letter is the pivotal means of information transfer to general practitioners, medical specialists or medical consultants. As the personal computer found its way into the standard business environment since the mid-1980s, office software -WordStar, WordPerfect, followed by Microsoft-Word and OpenOffice -were brought to the market. These software packages slowly replaced the traditional way of writing doctor's letters and reports of medical findings with a typewriter.
Both creator and recipient of an oncologic doctor's letter require a high level of abstraction, retentiveness and analy-sis due to the large number of diagnoses and therapies. In contrast to the commonly used structure of doctor's letter, where all diagnoses and therapies are listed in sequential order with diagnoses first, it is by no means trivial to establish the important chronological and hierarchical context in the description of oncological or traumatological cases. These circumstances were pivotal in the development process of the software, which will be shown here. The project started in 1991 and is still being developed.
The integration of the documents into existing hospital information system (HIS, for various abbreviations see Table 2 in the appendix) or departmental information sys-This article is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit tems via HL7-interface [1][2][3], various export formats (PDF, HTML/XML or TIFF), fax and encrypted email transmission, a modern layout based on TeX [4][5][6], to the end of meeting the criteria of corporate design [7] were additional aspects of importance. All documents should be available online [8].
Furthermore, layout and content should be easily adjusted to new requirements. Documents should be stored in a database [9,10] to maintain platform independence and to fulfil the requirements set by radiation safety legislation [11]. With specific barcodes on each document it becomes possible to automatically distribute the documents to other systems [12] Finally, another important aim is defined by the effective use of human resources to create the optimal doctor's letter. Powerful software tools are needed to that end, which are presented in this work as well.
A central requirement for the system presented here is the integration into our digital concept, which has existed for many years [13][14][15].

Material and Methods
The requirements for a doctor's letter system are manifold and can only be represented rudimentarily via a typical word processing system.
Due to this failing, we developed a system (IntDok) that covers all special features and requirements for clinical use.
In addition, our current departmental system MOSAIQ (version 2.6, Elekta AB Sweden) does not meet our requirements for writing doctor's letters.
Because of the complexity of the task, a thorough analysis of the requirements was carried out prior to commencement and implementation, where the authors could draw from a wealth of experience. In this context we have seen that there are only a few commercial systems that attended to this matter. Thus, standard programs such as Microsoft Word were and are the tools used for writing doctor's letters. Table 1 depicts the requirements that resulted from the analysis mentioned before, including the corresponding year of each step of implementation. A detailed description of all functionality is beyond the scope of the present work, so that the following paragraphs are limited to the most important functions. IntDok is a module of the parent system MEDATEC, which is explained later in the section technical background. The system has been, and is being, continuously developed in close cooperation with the users. The cooperation with the user was, and still is, a decisive factor for the constant improvement and extension of the system. Above all, the users recognize the strengths and weaknesses of a program best during their daily work.
Functionality in the period until 1995: The creation of documents was workflow optimized and enabled efficient working. Operation was simple and the guidance through the program is strictly procedural so that even new users readily familiarize themselves with the system. From the outset, we have ensured that documents are created with clinical cases in mind -as it is typically and usually done in clinics ( Figure 1) -and in accordance with a comprehensive access and control rights concept.
As early as 1991, a first software version running with the operation system MS-DOS (Microsoft, Redmond) was established in our department which already met the most important requirements. It is noteworthy that, from the beginning, the project included a pseudo-graphical interface that we named 'ergonomic shell' ('ErgoShell').
In addition, we attached great importance to store all documents within a database, independent of any proprietary file formats as, e.g., MS-Word. We started in 1991 with the Clipper compatible programming environment.
Furthermore, the software offers a sophisticated mail merge system with one main addressee and up to 10 recipients in carbon copy. The software then automatically creates copies for primary care and archive for example. The address field of all copies contains the respective address with automatic adjustment of the salutation (e.g., Mr. or Ms.); manual copying of letters and tedious addressing can be completely omitted.
Import of demographic and clinical case-related data from the hospital information system (HIS) has been implemented in this time interval. As content such as diagno-ses, therapies or other assessments can be imported from a patient's previous documents, it eliminates repetitive input of existing data. User-defined text blocks essentially simplify the creation of documents.
An essential core functionality was to combine diagnoses, histologies and therapies in a hierarchical way ( Figure  2). This combination ensures that each therapy (and each histology, if needed) is directly linked to the corresponding diagnose. A tree structure is created with increased comprehensibility that immediately provides the reader with a clear and meaningful overview about recent diagnoses and therapies ( Figure 3). Figure 2 shows a typical input form for an oncological doctor's letter. The secretary fills in the corresponding fields and the letter is then automatically generated based on this data via the corresponding TeX template. Behind most of the fields sub-forms are hidden, which can be reached via the small button to the right of a field. Depending on the requirements, various functionalities are available there. For example, the button right to the field 'recipient' leads to a multiple selection list-box to select the different recipients.
Integration of an interface to BDT (Behandlungsdatentransfer = transfer of treatment data) enabled the use of patient's electronic insurance cards in 1995; BDT is the official standard of the federal Health Insurance Association for the exchange of treatment data in Germany. Import of demographic data stored on those cards was possible, rendering the system even more interesting for external practitioners.
Functionality in the period from 1995: 1995 to 1997:The whole software package was migrated from MS-DOS to Windows 3.1x, facilitating functionality like copy-paste from other programs, or the inclusion of images and graphics; the latter functionality, however, was only in full use from 2005 onward.
2001: Since 2001, documents are rendered with a custom-built TeX-Server [4-6] and special templates, so that a thoroughly homogenous and professional corporate design is ensured (Figure 3). Document authors choose data either from predefined (yet customizable) lists or fill in text fields ( Figure 2). The remaining steps including hyphenation and spell checking are carried out by the system. Spell checking is extensible so that medical terms or labels of (generic) drugs are easily added.
In addition, depending on access rights of the user, the finalized document can be locked to prevent further editing. 2002: Support added for relevant file formats like PDF, HTML andXML 2003-2005: In 2003, we introduced a web server (Web-Doc), developed in-house [8] to make all documents accessible online ( Figure 4); with regard to data protection, this service is only available within our secured network (Intranet). In addition, this web server offers other medical documents and findings related to a patient ( Figure 5). For this functionality, we have programmed a proprietary interface to access the documents via HTML format (added 2002). We streamlined the software administration, improved configuration options as well as import and export abilities. In addition we enabled the integration of graphics and images.
2007: At first, the software architecture was fundamentally re-designed, and modularity was decisively enhanced, so that new requirements could be implemented even easier. Thus, the system can be used in virtually all medical disciplines, and it is multi-client enabled, serving, for example multiple departments within one clinic. The software provides a high level of configurability and, in addition to standard doctor's letters, clinical reports (for example about surgical procedures), medical documentation or miscella- neous documents or correspondence can be created. In 2008 the database was migrated to a MS-SQL [9, 10] database, which is still in use today. It should be noted that all of about 230,000 documents created since 1991 have been successfully migrated despite numerous system updates, underlining the future-proof storage concept.

2009-2010:
In this period, we completed the migration from 16-bit to 32-bit operating system. 2010: A speech recognition program (Dragon) was added in 2010. Due to the intervention of the staff council we had to deactivate this feature after 2 months. Since Windows 7, speech recognition has been integrated into the operating system and allows direct dictation in any Windows text box; therefore external recognition software is no longer required, but can be easily integrated and used in the same way.
All documents are provided with a barcode on each page containing the patient identifier, document quality, number of pages, current page number and clinical case number (Figure 3). 2014-2016: Barcodes gave us the opportunity to automatically distribute the documents to other systems via our self-developed import / export tool [12]. As an example: Finalized doctor's letters from our department are sent simultaneously as a PDF, fully automatically and categorized (for example doctor's letter or finding to the hospital information system (HIS), as well as to our departmental system (MOSAIQ™)

Technical background
Finally, we would like to outline the technical background of the system. Due to the complexity of this topic, we cannot present this in detail in this paper.
IntDok is a module of the parent system MEDATEC (Medical Data and Text processing with Computer). IntDok was the very first module we developed inside this environment. Since the developments took place in parallel, a logical separation between the two systems, at least at the beginning, was not readily apparent.
As mentioned above, custom scripting languages have been developed for this project. In principle, this approach can be considered as an early precursor to Document Type Description (DTD) and Extensible Markup Language (XML) system.
The Interactive Mask Generator (IMAGE) is an executable binary, which was developed in parallel to the MSDL module.
With these tools, we define both the scope of functions and the program flow for a complete project.
The executable programs are merely single basic modules (kernel) that load, interpret, represent, and store statements from those definitions.
For each project, definition files are created that provide all information necessary for the project (table structures including dependencies, the contents of the input forms and procedural relationships).
These definitions are parsed by the MSDL interpreter and then translated once via the MSDL compiler into a database structure, named structure-DB (strDB).The appearance and functionality of the system will later be determined solely by such a strDB. In a second step, the placement of the fields for every defined input form is determined once using our interactive tool (IMAGE). This tool receives all needed information from the same source (strDB) and stores the field positions in this database (Figure 6). Because various modules, e.g. doctor's letter or tumour documentation (TuDok), can be merged, almost any requirement of an institution is relatively easy to model. Figure 6 shows the module 'Tumour Documentation' (TuDok) as an example for a merging candidate.
All input forms are stored in the strDB as well and every single form is generated and displayed on demand from the contents of the strDB.
Due to this procedure, the content of the system is virtually unlimited and the load on the main memory is completely independent of the number of input forms, different document types or the project size. Thus, even very large projects can be realized without difficulty.
For the TeX server, introduced in 2001, two script languages/interpreters were created that combine TeX code with database content. TPL defines the basic types of used tags and TXF extend TeX files and act as a database to TeX interface. Figure 7 shows the basic scheme of the doctor's letter system.
In the supplements (see appendix II) we have attached examples of definition files without further explanation.

Results
The problems and requirements of creating medical documents discussed in this manuscript have been effectively and smoothly resolved with the doctor's letter and finding system IntDok. The reader of those documents gets a comprehensive and quick overview of a patient's history with the help of the hierarchical order of diagnoses, histologies and therapies. Document creation is controlled with a strictly procedural approach and the user is supported by many valuable and essential tools such as reusable text blocks, extensible lists and import and export functions. HL7 interfaces to the hospital information system (HIS) and departmental information system (MOSAIQ™) provides all demographic patient data, addresses and content of those systems to the user. With templates, it is easy to implement the integration of barcodes to meet requirements set by other systems or organizations.
The software offers a sophisticated mail merge mechanism. Hierarchical text blocks of diagnoses and therapies or reporting text from former documents are easily imported into the current document and the user only has to add new diagnoses, therapies or text. Export is possible to PDF or HTML/XML format. A TeX server automatically creates document layout so that uniform appearance is guaranteed; the adaption to the corporate design of our hospital is an easy task. In addition, including a speech recognition module presents no problem. The documents are stored in a MS-SQL database, independent of any proprietary formats as, e.g., MS-Word. All documents are accessible within a web server. The database comprises all doctor's letters and reports created in our department since 1991 -approximately 230,000 documents to date. All documents can be transmitted to other systems in PDF format, retaining all necessary metadata, for example diagnoses codes as ICD and qualifiers (e.g. doctor's letter or finding).

Discussion
The software IntDok allows for quick and structured creation of documents, enabling the handling of hierarchical blocks of diagnoses and therapies and ensures the optimum use of human resources with sophisticated tools. Within a very short amount of time, the user is able to edit very complex oncological doctor's letters. IntDok is integrated in an excellent way into our multimodal document management [12], introduced in 2013. For over four years, our department has been working almost completely without any 'analog' medium (film-and paperless) [13,14]. Sending doctor's letters or reports to remote institutions is the last process linked to paper. We are currently negotiating with an external service provider to receive our documents electronically. The service provider will then send the documents by post to the recipients (patients, doctors in private practice and external clinics). We have simultaneously submitted a request for approval of this procedure to the state data protection authorities. If we succeed in this step, our clinic will also be completely paperless in external communication.
Due to the modular design of the system new requirements can be implemented easily. Thus, the system can be used in virtually all medical disciplines, and it is multi-user enabled, serving, for example multiple departments within one clinic. The software provides a high level of configurability and, in addition to standard doctor's letters, clinical reports (for example about surgical procedures), medical documentation or any other documents or correspondence can be created.
For many years, MEDATEC was the largest HIS implementation at Freiburg University Hospital, with around 350 workstations in daily routine use. It was used in almost all clinics of the University Hospital and consisted of the modules for example IntDok (doctor's letter), Melody (surgical management), TuDok (tumour documentation), D-Arzt (emergency outpatient unit).
Participating clinics were dermatology, radiation oncology, head and neck, gynaecology, all surgical clinics (traumatology, orthopaedics, hand and plastic surgery, general and visceral surgery, endoscopic surgery, neurosurgery), internal medicine (endoscopy) and geriatrics. This can also be seen in the attached supplements, the entire system is highly configurable and adaptable.
However, the configuration and adaptation to new requirements requires detailed knowledge of the internal structure and, above all, of the self-developed scripting languages.
But due to the fact that the system is not commercially available, it is difficult to implement and maintain in external facilities. Moreover we cannot currently provide the necessary support to external institutions.
The software system is constantly evolving and new features continue to be added.
Finally, we are currently planning to port the software system presented here to a 64 bit platform, so that it can make use of larger amounts of memory and increased stability on 64-bit operating systems.
The current HIS systems (e.g. Orbis from Agfa, Millennium/ISH-Med from Cerner, CGM Clinical from CompuGroup, I-Soft from i-Solutions Health and MCC from Meierhofer) have a very good range of functions; however, in our opinion they are very slow in implementing adaptations or even innovative solutions. ISH-Med and SAP offer at least modular and adaptive structures, but are often classified by users as unintuitive and unwieldy.
In addition, none of these manufacturers has attempted so far to control linear accelerators (linac). In view of the relatively manageable number of radiation therapy facilities, the HIS manufacturers avoid the costly step of solving the difficult technical and legal requirements of linac control. Currently only MOSAIQ (Elekta) and ARIA (Varian) are available for radiation oncologies; Raysearch is about to launch the RAYCARE system. However, both Elekta and Varian have only started to develop towards HIS function-ality in recent years. Therefore, external but integrative software solutions are currently still necessary (as here e.g. IntDok) if you want to work continuously and effectively in a digital environment.

Conclusion
Creation of documents using the presented system is fast, simple and well-structured. Sophisticated tools ensure the optimal use of human resources and time. The hierarchical blocks of diagnoses, histologies and therapies give the reader a chronological and rapid overview of the previous course of therapy.
As discussed above, the entire system can be used in almost any clinical area, as it can meet all the important requirements of a clinical facility.
The modular design allows fast implementation and guarantees short time-scales necessary to implement changes or new requirements.
The limiting factor for providing the system to other facilities is due to the fact that our department cannot currently bestow support for set-up and maintenance. IntDok is an important module in our overall digital work environment [15].