Udo ALTMANN, Frank KATZ, Ali TAFAZZOLI,
Volker HAEBERLIN, Joachim DUDECK
Arbeitsgruppe zur Koordination Klinischer Krebsregister
Institut für Medizinische Informatik, Heinrich-Buff-Ring 44, 35392
Gießen, Germany
Introduction
Requirements for the Integration
Realization
* Data Exchange
* Graphical User Interface
* Information Server
Conclusion
References
Abstract. During the last four years a new documentation system for tumor diseases has been developed and was implemented at 29 hospital tumor registries by the "Arbeitsgruppe zur Koordination Klinischer Krebsregister". Although the so-called "Gießener Tumordokumentationssystem" GTDS has primarily been implemented for the use in registries, from the beginning many functions and services have been integrated to fulfil specific clinical requirements in order to support the individual treatment of oncologic patients. The physicians' interest in a direct on-line use of such systems is increasing. Specific impediments like the registry specific user interface, the need for entering partially redundant data, and the restriction to oncologic patients stand in the way of a wide spread on-line use. Support of data exchange, graphical user interface, and availability of services which can be called from other systems are the key developments which will help to integrate GTDS into a hospital information system.
The documentation of tumor diseases is an example for disease specific documentation which has a long tradition. The uniform basic data set used by the German hospital cancer registries since 1983 [1] was redefined in 1990 [2, 3]. In particular, the documentation of therapy was extended in order to meet the physician's interest in more detailed information and analysis, e.g., for quality assurance. Since many of the existing systems used by the registries could not or only with great difficulties be adapted to this new data set, a new documentation system, the so-called "Gießener Tumordokumentationssystem" (GTDS), has been developed [4, 5]. A nation-wide working group formed by experts from different registries defined the requirements and the "Arbeitsgruppe zur Koordination Klinischer Krebsregister" (AKKK), a central service group for data evaluation, training of documentation staff and organization of congresses and scientific working groups in this area developed the system and implemented it in 29 registries. A CASE tool (IEF from Texas Instruments) was used for the design of the data model [6]. The system is completely realized in an ORACLE environment using the tools SQL*Forms 3.0, SQL*Menu 5.0 and SQL*ReportWriter as frontends. From our view this proceeding gave us at that time a maximum of portability and productivity. The work of the AKKK is sponsored by the Federal Ministry of Health.
The primary goal of German hospital cancer registries is to collect information about the whole course of the disease including follow-up care. It is important to stress the fact that in contrast to department systems registries collect data from different medical disciplines. In Germany in- and outpatient care are for the most part completely separate. For this reason different strategies and functionalities are required for collecting and tracking a patient's data. Most of the existing tumor documentation systems provide overviews of patient histories and support the scheduling of follow-up care.
GTDS provides specific functionalities to support registry tasks. Physicians are reminded if the documentation of an appointment is missing or there has not been any information about the patient's state for a long time. Public registration offices are inquired automatically if any medical information is missing. Administration tasks, e.g., reimbursement of documentation expenses, statistics for negotiation with financing institutions, are supported by appropriate reports.
It is well-known that the acceptance of a documentation system increases when the data can be used to support clinical routine of physicians and nurses. In the GTDS several services are already provided for this purpose like
* automated discharge letters and overviews of a patient's history,
* scheduling of therapy and follow-up care including diagnostic observations,
* individual dosage calculation for chemotherapy,
* access to specific information data like PDQ (Physician Data Query from the National Cancer Institute of the U.S.), and
* knowledge based functions to support physicians, e.g., in treatment decisions (using ARDEN syntax)
Because of the different interests and working methods of physicians compared with registry staff, a registry system can not just simply be connected to a hospital network. Additional precautions have to be taken to facilitate the use of the system and its functionality. In this contribution additional developments which have been made in order to promote GTDS in the environment of a hospital information system are presented.
At Gießen University hospital a comprehensive hospital information system has been introduced which serves more than a thousand users at wards, physicians' offices, and department offices [7]. At present the GTDS services which are designated to support clinical routine are mainly used by interaction with the registry staff and not directly by physicians. Discussions with physicians indicated that certain important modifications are required to integrate GTDS into this hospital network. The kernel of the system, the GTDS database, could be used without larger modifications since from the beginning it was designed to serve not only for registry but also for clinical tasks.
But physicians and registry staff approach and use the data quite differently. Registry staff collects data, e.g., from printed documentation forms after diagnosis, treatment or follow-up observations have been completed. Physicians, however, collect and review data during treatment. Registry staff is permanently working with the system and is experienced. Physicians and nurses are infrequent users who need more sophisticated guidance and support. Therefore different user interfaces, adapted to the varying approach to the data, have to be provided.
Another important prerequisite for integrating a system in a hospital information system is the integration of data. On the ward, data are available from various ancillary systems like clinical laboratory, radiology, pathology etc.. Physicians expect that this information is also available on-line in the oncology system. They are not prepared to enter such data once more or to switch to other systems for looking at them.
Fig. 1 (not yet available): MFICI. In the integrated system data have to be provided from different ancillary systems and have to be transmitted to peripheral systems like physicians' office systems. For data transmission standard interfaces like HL7 and BDT are used. They are connected with the database via a newly developed Message Format Independent Communication Interface (MFICI), which is also able to handle fixed length and delimited format records
The first step in the integration process was the development of a powerful communication interface to other ancillary systems using standard interfaces. In Germany two types of standard interfaces are already used in hospitals and physician's offices, the Health Level Seven (HL7)- and the BehandlungsDatenTräger (BDT)-interface. GTDS uses HL7 to receive data from the hospital admission, discharge and transfer (ADT) server and from various ancillary systems like clinical laboratory, radiology etc.. BDT is a specific German ASN.1-like format for the transmission of medical record data between physician's office computer systems and has become a quasi standard in Germany. So BDT is used for the communication between registries and will be used for the communication between GTDS and the physician's office computer systems. For both interfaces it was necessary to define oncology specific segments and messages [8, 9, 10]. The standard interfaces are connected with the GTDS via a Message Format Independent Communication Interface (MFICI) which is described elsewhere [10] (Fig. 1, (not yet available)). The MFICI is also able to handle fixed length and delimited format records which are still in use for the communication with population-based tumor registries. It allows to assign contents from a message or other structured sources to database fields without dealing with the underlying data structure (especially primary and foreign keys) of GTDS.
GTDS has a semi-graphical interface which already provides windows but which does not offer mouse support nor apply graphical figures. The new interface is based on the graphical version of the tools which have become available now. The first aim of the design of a graphical user interface was rather to display information than to support data entry. The aim is to prepare and motivate physicians for the on-line tumor documentation whilst the documentation itself is still carried out by registry staff. Patient data can be accessed by selecting the patient from a list of actual or recently hospitalized patients of the physician's ward instead of entering search criteria like in a registry. This list is maintained by messages from the hospital's ADT system. In the next step a short overview of the patient's history is given and the physician can select the interesting detail information (site, histology, stage, diagnostic procedures, activity status etc.). Besides displaying patient data, the user interface also allows direct access to some reporting functions (medical reports, overviews). Since the graphical user interface operates directly on the database, it requires the presence of a network.
The next aim will be to offer functions for adding or modifying existing data. Some functions like planning follow-up care and dosage calculation of chemotherapy which require only a minimum of data entry will be realized first. When more data entry is available it will be possible for clinicians to write medical reports immediately without interaction with the registry staff.
An additional possibility to access information from GTDS is to call special services which are initially ASCII documents like the medical reports mentioned above (Fig. 2 (not yet available)). This allows an easy integration of GTDS functionality into other systems (e.g., department systems) so that the user is not forced to call specific applications for displaying a patient's tumor data. This proceeding was tested in cooperation with a commercial software developer. Thus not only applications inside a hospital network but also physicians' office computer systems can access GTDS as an information system. The special confidentiality aspects of this proceeding are discussed in the so-called REGKOM-project.
Fig. 2 (not yet available): Structure of the Information Server. GTDS services, which can be called in batch mode, are accessed via a service daemon, which establishes the correct environment (authorization, parameters etc.)
An enhancement already experimentally tested is to provide GTDS services as hypertext documents instead of simple ASCII files and integrate these services into a World Wide Web (WWW)-like infrastructure. Similar to Cimino et al. [11] the user has the possibility to select patients from a list and interactively request additional data. As a first implementation a summarizing report was prepared in this way. GTDS provides a set of tables in which information sources and even external programs can be linked to specific clinical findings (e.g., topography and morphology of a tumor). When the summarizing HTML report is generated, the appropriate information links to PDQ are included based on the patient data.
Disease specific systems (DSS) like tumor documentation systems offer a unique functionality which is usually not available in departmental systems because these systems are designed for administrative or general medical purposes. On the other hand, for several reasons, DSSs are often restricted to a subset of mainly experienced users, a subset of data (in comparison to general medical data), or a subset of patients. This results in a lack of acceptance by physicians. Since more and more hospitals are implementing comprehensive networks DSSs have to be moved from isolated to integrated systems. The necessity for integration is stressed by the fact that although the functionality provided by DSSs is required for supporting patient care, the preparedness to supply financial resources for the collection of data in isolated systems, only to be used for historical analyses, is remarkably decreasing.
The integration of a DSS into a hospital information system requires standard communication interfaces which help to access data from other systems. It also requires user interfaces which are adapted to the clinical users like physicians or nurses who access the system only occasionally and in another context than the staff of the registries. Finally, DSS services can be made available to, e.g., department systems or can be integrated into a WWW-like infrastructure.
[1] G. Wagner, E. Grundmann, Basisdokumentation für Tumorkranke 3. Auflage. Springer Verlag Berlin Heidelberg New York etc., 1983
[2] J. Dudeck, G. Wagner, E. Grundmann, P. Hermanek, Basisdokumentation für Tumorkranke 4. Auflage. ISBN: 3 540 56397 0. Springer Verlag Berlin Heidelberg New York etc., 1994
[3] J. Dudeck, W. Wächter, U. Altmann, F. Katz, The definition of a new uniform basic data set for hospital cancer registries in Germany. MIE-Proceedings 1993, Freund Publishing House Ltd. 489-492
[4] U. Altmann, F.R. Katz, V. Haeberlin, C. Willems, J. Dudeck, Concepts of GTDS: An Oncology Workstation. MEDINFO 95 Proceedings, IMIA 1995
[5] U. Altmann, F.R. Katz, V. Haeberlin, C. Willems, J. Dudeck, GTDS - An Oncology Workstation. In Hospital Information Systems, Elsevier Science B.V. (1995) 117 - 129
[6] 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 Medizin Verlag München (1993) 41-44
[7] H.U. Prokosch, J. Dudeck, G. Junghans, K. Marquardt, P. Sebald, A. Michel, WING - Entering a New Phase of Electronic Data Processing at the Gießen University Hospital. Meth Inform Med 1991; 30: 289-298
[8] Protokoll der Arbeitsgruppe GTDS-Schnittstellen, available from the authors
[9] Schnittstelle für den Transfer von Daten zur Tumorbasisdokumentation, available from the authors
[10] V. Haeberlin, Inaugural Dissertation
[11] J.J. Cimino, S. A. Socratous, P. D. Clayton, Internet as Clinical Information System: Application Development Using the World Wide Web. JAMIA, 1995:2(5): 273-284