Concepts of GTDS - An Oncology Workstation

U. Altmann, F. R. Katz, V. Haeberlin, C. Willems and J. Dudeck (Beitrag für Medinfo 95)

Arbeitsgruppe zur Koordination Klinischer Krebsregister, Institut für Medizinische Informatik,
Heinrich-Buff-Ring 44, 35392 Gießen, Germany

Contents

Abstract

Introduction

Concepts

Choice of Development Tools

Realization and Applications

Future Perspectives

Conclusion

References

Abstract

In Germany computer systems are in use in hospital cancer registries for more than 10 years. Primarily they have been used for retrospective documentation of malignant tumors with only few functions for the support of follow up care and statistical evaluation. With the general availability of PC-systems and computer networks interest increased to use the data for the support of the treatment process itself. Therefore we have decided to design and develop a new oncology information system which covers both aspects, (1) the documentation of all relevant data items for the cancer registries and (2) the routine support of the physician in the clinical treatment process. In this contribution the design and concept of this oncology information system as well as experiences gained during the development process are discussed. Future plans to further extend the system to a comprehensive oncology workstation are presented.

Back to Contents

1. Introduction

The treatment of malignant tumors is a task of increasing complexity which requires the cooperation of different medical disciplines. Computers can support this process by providing patient data, comprehensive information and medical knowledge at the physicians desk. Several systems like OCIS [1] and ONCOCIN [2] have been successfully developed to support the management of patient care and the requirements for the development of an "Integrated Oncology Workstation" have been described[3].

Since the beginning of the eighties a network of hospital cancer registries (HCR) has been established in Germany supported by the Federal Government and the "Deutsche Krebshilfe", a private nonprofit organization. Primarily the HCR collected and stored data of nearly all patients treated in comprehensive cancer centers and related hospitals according to a uniform basic data set (UBDS) defined by the Association of German Tumor Centers (ADT). The scope of the data set and the encoding rules are described in the "Basisdokumentation für Tumorkranke" [4]. The availability of computer networks within hospitals has increased the interest to use these data not only for retrospective documentation but also for supporting the treatment process itself. The content of UBDS has therefore been redefined [5, 6]. In particular the description of treatment data was extended. To introduce this new UBDS it was necessary to develop a comprehensive oncology workstation which is able to handle this data set and to provide it for treatment purposes. Therefore in 1991 a nationwide working group ("Arbeitsgruppe Tumordokumentationssystem", AGTDS) has been established to define the requirements and the design of a new oncology information system. The working group has been composed of medical and computer science specialists working in comprehensive cancer care centers. Coordination of this work and programming of the system ("Gießener Tumordokumentationssystem", GTDS) was done by the working group ("Arbeitsgruppe zur Koordination Klinischer Krebsregister", AKKK). The whole development has been sponsored by the Federal Ministry of Health.

Back to Contents

2. Concepts

The fundamental concepts, which have been considered during the GTDS development are the following [7]:

• Uniform Presentation of Entry Forms: The user should have a consistent way in accessing and modifying data
• Data Protection: GTDS can be used in an environment, in which many departments and outpatient clinics enter data into a single database. Patient data are stored with relation to the department, the physician or medical user is belonging to and can only be modified by users of the same department. All departments which participate in the treatment of the patients are allowed to see the tumor specific data. Other departments are only allowed to see identification data of the patient to avoid duplicate records.
• Context Sensitive Help: A context sensitive help system has been implemented displaying field, block or form specific help or if required general system information. Every coded field with more than two possible values can be filled by selection from a list of values.
• Context Sensitive List of Values: In some cases the list of values for a field can be limited to a subset dependent from the values in other fields. Besides consistency checks this is a very important precaution for a high quality of data.
• Use of Free Text: The use of free text is very important because certain facts can not be stored in a structured way but have to be displayed in the system or in reports generated by the system. A special type of free text application, the so-called adaptive documentation, will be described later.
• Clearly Arranged Overview: Data generally can be accessed from overview to detail. For the reason that not every center uses the full extent of all data, the user has to select the details he wants to see and thus is not forced to step through a lot of empty fields.
• Adaptibility: Where coded data storage is based on a particular classification system, the applied classification system is stored together with the actual code of the clinical item. Thus it is possible to accomodate the usage of different revisions of classification systems over time and also the usage of different coding systems (e.g. for examinations, follow up schemes and chemotherapy protocols) in different centers. Thus every user has the possibility to adapt the system very close to his own needs.
• Adaptive documentation: It is well known that coded data storage is important for statistical analysis and decision support functions, but often associated with a loss of information. Therefore clinicians usually require a more specific textual representation, especially for the usage in medical reports (e.g. discharge letters). This requirement has been satisfied by the double storage of information, where this feature is needed. The physician may modify the textual representation of the code (originally given by the applied classification system) and adapt it to his own needs. This new textual representation is than stored in addition to the classification code. For example the ICD-O term "Overlapping lesion of lung" for the code C 34.8 will not be accepted but the user has the possibility to write "Tumor of the main bronchus infiltrating the upper and middle lobe of the lung". Thus the code selected from the list will be preserved and the data can be statistically evaluated

As mentioned above the AGTDS has been composed of medical and computer science specialists coming from different centers and using different documentation systems. Thus a wide range of experiences could be integrated in the design and development. The intention for the sponsoring of the development by the Federal Ministry of Health was to create a documentation tool, which should be centrally programmed and supported to avoid ineffective dispersion of financial efforts. Therefore the system should be suitable to different centers with different organization and contents of documentation (apart from the minimum basic data set). The design of the system had to be functionally but not organizationally oriented. The structure had to be modular with the ability to make individual adjustments. As many function as possible should be dependent from parameters stored in the database itself. For the reason that the system should be integrated in different environments and as independent as possible from certain hardware requirements, the development tools should allow an easy portability to different platforms.

Back to Contents

3. Choice of the Development Tools

Data should be stored in a relational database management system (RDBMS), because this is the easiest way to access data in different ways. Data design should be made using an entity relationship diagram as the adequate method for the design of a relational database system. First we decided to use a CASE tool (IEF from Texas Instruments) which is not only independent from hardware but also from RDBMSs concerning the target environment [8]. Although it is possible to generate an almost complete system using IEF, we finally decided to use ORACLE and its tools for the programming when the phase of data design had finished. The reason was that the development of two small prototypes with ORACLE and IEF had shown, that the functional capabilities and the speed of development of ORACLE tools are much higher than those of IEF, which only allowed a block mode oriented processing. We used ORACLE's SQL*Forms and SQL*Menu for programming the entry forms and SQL*ReportWriter for medical reports and simple statistics.

Back to Contents

4. Realization and Applications

In 1992 an alpha version has been implemented at three centers to test and adapt the functionality. The system was chosen for the application in particular in centers in the new states by the Federal Ministry of Health. In 1993 the beta phase began with the installation at ten more centers. From the beginning approximately 2,5 persons are engaged in programming and support of the system. Up to now GTDS has been introduced in over 17 centers with different demands concerning the hospital cancer registry. Some centers use it only for the documentation of tumor diseases. Others use it for managing or supporting the follow up care by sending reminders to outstanding examinations to doctors or patients and collecting the results of these examinations. They send medical reports or overviews generated by GTDS to the participant physicians to improve communication among them. An other way of using GTDS is as on line information system for a oncology ward or outpatient department. Chemotherapy can be planned on line and the physicians rely on the information in a high grade. This is the step which is most close to the realization of an oncology workstation.

Back to Contents

5. Future Perspectives

Although many functions of an oncology workstation could be realized in GTDS there are further steps which have to be done to realize a fully integrated workstation.

• Integration into HIS: First of all GTDS must be available at each physicians place to work. Due to its data security concept it is possible to integrate GTDS in a hospital network.
• Integration of Communication Interfaces: Many of the data stored in GTDS are data which already are available in existing components of a HIS. Demographic data, laboratory results and histologic evidences can be taken over from other subsystems. On the other hand examination orders and medication data from the planning of chemotherapy can be put into other systems. In this way the expenses for documentation is reduced considerably and acceptance will increase. Therefore a HL7 interface is just about to be implemented in GTDS.
• Integration of Clinical Trial Management: Many of the tumor patients especially when they are treated in university hospitals participate in one ore more clinical study. A module will be available which enables the users to keep track of the existing studies and the participant patients. Clinical trial data will be stored and automatically be exported to the clinical trial center. In this way the administrative expense of studies is reduced considerably and acceptance will increase.
• Integration of Medical Knowledge: Many sources of medical information can now be accessed with computers, including bibliographic databases (for example MEDLINE or CANCERLIT), databases of clinical trials (for example PDQ) and medical textbooks. Those on line references are highly accepted by physicians, as the experiences show we made at Gießen University Hospital [9,10]. Although there are no problems to access them as stand alone systems it should be aspired to access them with parameters which allow to display already the right context. For example if the actual patient has a colon cancer this disease is probably used as a search term in MEDLINE. As soon as such an interface will be available we will be going to integrate these references.
• Integration of Knowledge Based Functions: The more complex modern treatments of tumor diseases have become, the more important it is to be able to support physicians work by reminders generated by computer systems [11]. Although it will not be possible to check every critical situation in clinical treatment it might often be useful to remind to conditions which would have been forgotten. Therefore a compiler for the Arden syntax [12] has been developed and is being integrated into GTDS. The first application of knowledge based functions has focused on checking a patient's eligibility for special therapies or clinical trials.
• Graphical User Interface: At present GTDS is realized as a semigraphic version using text terminals or emulations as front ends. The recently released versions of the developing tools now allow to program sophisticated graphical user interfaces, to which many users are already familiar. We hope that physicians' willingness to work with the GTDS will increase.
• Increase of Data Security: If the use of GTDS is extended to many different users in a clinic network it will be necessary to provide additional features to increase data security. Information entered into the system should be better protected against modification. Modifications should be recorded including the authorization and only be possible in a certain range of time. The concept of user roles has to be extended. ORACLE7 enables to realize these measures within the RDBMS without modifying the application itself.

Back to Contents

6. Conclusion

Developing a system with a CASE-tool enforces systematic proceeding. In this way severe errors during development are reduced. It is not possible to do the development quick and dirty. In this regard there was a benefit by using a CASE-tool not only in view of the generation of DDL-statements. The 4GL we used enabled us to develop a complex and comfortable application with limited human resources. A small developing team reduces communication overhead. Combined with the tool's capabilities a flexible response to user wishes is possible. The present version of GTDS is a useful tool for hospital cancer registries. There are extensive possibilities for the documentation of tumor dieseases. Many functions are realized which help to support the patients' treatment and thus increase the cancer registries' acceptance. This is the result of the cooperative work of many specialists and the use of modern tools for design and programming (CASE tools and 4GL). The further development towards an integrated oncology workstation and its integration into HIS requires extensions which are partially about to be realized.

Back to Contents

7. References

1. J.P. Enterline, R. Lenhard, B.I. Blum, A clinical information system for oncology, Springer Verlag New York Berlin Heidelberg 1989

2. D.L. Kent, E.H. Shortliffe, R.W. Carlson, M.B. Bischoff, C.D. Jacobs, Improvement in Data Collection Through Physician Use of a Computer-Based Chemotherapy Treatment Consultant, Journal of Clinical Oncology, Vol 3, No 10 (October) 1985, 1409-1417

3. E.H. Shortliffe, An Integrated Oncology Workstation, National Cancer Institute, Maryland, Bethesda (1990)

4. G. Wagner, E. Grundmann, Basisdokumentation für Tumorkranke 3. Aufl., Springer Verlag Berlin Heidelberg New York etc. 1983

5. J. Dudeck, G. Wagner, E. Grundmann, P. Hermanek, Basisdokumentation für Tumorkranke 4. Aufl., Springer Verlag Berlin Heidelberg New York etc. (1994)

6. J. Dudeck, W. Wächter, U. Altmann, F. Katz, The definition of a new uniform basic data set for hospital cancer registries in Germany, in: MIE-Proceedings 1993, Freund Publishing House Ltd. 489-492

7. F. Katz, U. Altmann, J. Müller, J. Dudeck, Funktionsumfang des Gießener Tumordokumentationssystems (GTDS), in Entwicklungstendenzen der Tumordokumentation in Klinik und Nachsorge - 6. Informationstagung Tumordokumentation Dortmund 1992, Ferber Gießen (1994) 101-131

8. U. Altmann, F. Katz, J. Müller, W. Wächter, J. Dudeck, Die Entwicklung eines Tumordokumentationssystems für Klinische Krebsregister, Europäische Perspektiven der Medizinischen Informatik, Biometrie und Epidemiologie, 37. Jahrestagung der GMDS 1992, MMV Medzin Verlag München (1993) 41-44

9. H.U. Prokosch, B. Puhle, J. Dudeck, One-Stop-Information-Shopping: Do we meet the information needs of the hospital staff? MIE-Proceedings 94, 362-365

10. G. L. Kreps, M. D. Naughton, The role of PDQ in Disseminating Cancer Information, MEDINFO 86, Elsevier Science Publishers (1986)

11. C. J. McDonald, S. L. Hui, D. M. Smith, W. M. Tierney, S. J. Cohen, M. Weinberger, G. P. McCabe, Reminders to Physicians from an Introspective Computer Medical Record, Annals of Internal Medicine, 1984;100:130-138

12. G. Hripcsak, P.D. Clayton, T.A. Pryor, P. Haug, O.B. Wigertz, J. Van der lei., The Arden Syntax for Medical Logic Modules, SCAMC 1990, 200-204

Back to Contents