Udo ALTMANN*, Volker HAEBERLIN, Ali TAFAZZOLI, Joachim DUDECK
Institut für Medizinische Informatik, Heinrich-Buff-Ring 44, 35392
Gießen, Germany
*Informationszentrum für Standards in der Onkologie der Deutschen
Krebsgesellschaft e.V.
Abstract. The "Methodology for the Development of Health Care Messages" was published in 1995 by CEN TC251. This contribution describes the application of the methodology in a project of developing messages for the exchange of tumour patient data. A standard data set, the "Basisdokumentation für Tumorkranke" was already available for the data of tumour documentation. The development of the messages as well as the design and implementation of a communication interface in a documentation system could therefore be carried out straight forward. Problems arise due to the import of data from different sources. Up to now, there is no standardized method for identifying patients and numbering of different tumours. An automated matching of new data to a specific patient or tumour is therefore not always possible. Methods are presented which try to make a compromise between fully automatic data import and complete user control.
The "Methodology for the Development of Health Care Messages" of the CEN TC 251 WG3 has been developed with the aim to recommend a methodology for the definition of character-based EDI messages in healthcare [1].
The ability of data exchange becomes an important factor for the future of tumour registries because tumour registries can no longer be regarded as isolated systems only collecting data. They have to be embedded into a context of in- and outpatient care. The "Gießener Tumordokumentationssystem" (GTDS) is a system used by tumour registries for the tumour documentation as well as for the support of individual clinical treatment and follow-up care [2].
On the one hand, GTDS provides specific functionalities to support registry tasks. Physicians are reminded if the documentation of an appointment is missing or if 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 also supported by appropriate reports.
On the other hand the data are used to support clinical routine of physicians and nurses. In the GTDS several services are provided for this purpose like automated discharge letters and overviews of a patient's history, scheduling of therapy and follow-up, individual dosage calculation for chemotherapy, access keys to specific information sources like PDQ (Physician Data Query from the National Cancer Institute of the U.S.), and knowledge based functions (using Arden Syntax). The efforts made to integrate such a disease specific system, for example into a hospital information system, were described in [3].
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 group meetings in this area developed the system and implemented GTDS in 30 registries.
In 1994 a nation-wide working group with interested members not only from users of the GTDS met to define requirements and descriptions of messages and interchange formats in the area of tumour documentation. The procedure followed the "Methodology for the Development of Health Care Messages" to a great extent although it was only available as a draft version at the end of 1994.
The development of the GTDS and the initial efforts to establish communication standards in tumour documentation have been sponsored by the Federal Ministry of Health. The further development is now part of the "Information Center for Standards in Oncology" of the German Cancer Society and is financed by user fees and sponsoring by the Federal Ministry of Health.
Firstly, this contribution will describe the results of this work and the following developments. Then the design of the interface realized in the GTDS will be compared to the steps described in the methodology. Finally, registry specific problems of the realization will be discussed.
The first task according to the methodology is the definition of the scope of the message development activities and the description of scenarios and user requirements. The resulting possible communication paths are listed in table 1.
Table 1: Possible communication paths of tumour registries with other institutions
hospital cancer -> epidemiological cancer registry registry physician's <-> hospital cancer registry (follow-up management, office system information requests) hospital cancer -> anonymous central data evaluation registry hospital cancer -> tumour specific registry (for example melanoma) registry hospital cancer <-> hospital cancer registry registry ADT-server -> hospital cancer registry laboratory -> hospital cancer registry hospital cancer <-> pharmacy (chemotherapy) registry
The next step is dealing with the development of a domain information model (DIM). Most of the data used are defined in the "Basisdokumentation für Tumorkranke" [4, 5], a basic data set for tumour diseases, which forms also the basis of the data stored in the GTDS.
Therefore, the entity relationship diagram [6] used for the development of the GTDS database structure could be considered as a sufficient description of the domain information model.
No formal representations exist for the general message descriptions. They can be derived from the hierarchical general message descriptions which are described as HL7 abstract message definitions (using generic and application generated Z-segments). An example for such a general message description is shown in table 2.
Table 2: Structure of Message described as HL7 abstract message definitions (using generic and application generated Z-segments)
MSH Message Header
EVN Event Type
ZPA Patient Identification (anonymous)
ZPZ General state of health
ZST State of the disease
ZAN Tumour specific case history
{[ZLO] Topography
[ZHI]} Morphology
ZSM Staging (TNM etc.)
{[ZTO] Surgery
[ZKO]} Complication
{[ZTB] Radiation
[ZNW]} Side-effects
{[ZTI] Chemotherapy
[ZNW]} Side-effects
{ZTD} Causes of death
From the view of HL7 (and also from the later discussed BDT) the data exchanged between registries can be distinguished into a more general part already covered by the standards and the tumour specific part for which no standardized definitions exist and which is expressed for example in Z-segments (as described above). The complete description of the HL7 Segments results in implementable message specifications.
Although the descriptions were primarily made in HL7 [7], they can be regarded as general descriptions which are not restricted to one specific interchange format but can also be mapped into another interchange format. In Germany, an additional interchange format standard, the BehandlungsDatenTräger (BDT), is widely used for the exchange of data in the area of physician office systems. Since some of the scenarios include communication with such systems, similar descriptions (implementable message specifications) exist for this purpose [8]. The BDT format is also designed to be used for the exchange of data among cancer registries, because the definition is simpler and the needed types of communication does not require sophisticated definitions of event types.
The communication interface of the GTDS consists of several message format specific modules (for HL7, BDT, ASCII, ...?) and a message format independent module which
Another important feature, the decision, whether data already exist and have to be updated or have to be inserted, will be discussed later.
As shown in table 3, this design has remarkable parallelisms with the development of the message descriptions.
The parallelism of DIM and data base structure is a specific advantage of this development, which benefits from the common understanding of the medical record. The separation of format specific and format independent components has proved to be well-founded. Further optimization might be achieved by the implementation of a third layer, which serves as container of message contents after the message has been parsed.
Table 3: Comparison between the steps of the development of health care messages and the structure of the GTDS communication interface
1. Domain Information Model (DIM) is GTDS data base structure is based on
"Basisdokumentation"
based on "Basisdokumentation"
2. General Message Description (GMD) message format independent module
(semantic structure of the guarantees semantic consistency of
message) the database after the import of a
message (but is not restricted to the
contents of a specific message)
3. Hierarchical - GMD realized in format specific modules
(might be separated into a third
layer between format specific and
format independent layer in future)
4. Implementable Message format specific modules
Specification
The message specific modules have been realized for the formats HL7, BDT, and ASCII (fixed length and delimiter). At present, HL7 is only used for the exchange of ADT data for the reasons described above and the current lack of communication partners in the hospital environment. The transfer of data among registries is done with BDT. BDT is also used for the transfer of data to the DHE-adapter (Distributed Healthcare Environment) in the European Communities Telematics Research Project HC 1019 HANSA (Healthcare Advanced Networked System Architecture) [9]. In this example, a server process continuously looks for new or updated data in the GTDS database and exports the data to the DHE-adapter. The ASCII format is used in situations when standard communication interfaces are not available, mainly for the transfer of ADT data.
Problems are caused by the nature of tumour registries since registries require the import from many different sources. In contrast to the situation in hospital information systems, there is no "leading" server for the patient identification like an ADT system. Therefore, every time when data are to be imported into the application, a complex procedure of identification has to be carried out. Identification is not only necessary for patients but also for tumours and some other objects for which information may come from different sources. Even when data of an object are not to be imported, object information has to be used for relating objects to each other, for example, transmitted follow-up information to a specific tumour.
Automatic algorithms using object attributes like names, date of birth, sex, or classification codes for tumours are burdened with a risk of errors during matching objects which is greater than doing it mentally controlled. On the other hand, user control reduces the benefit by the exchange of messages.
Therefore, a master object index has been implemented which stores the identification data of an object in other systems. Whenever a critical object has to be imported, the index is searched, based on its primary key attributes, whether the object already exists in the database. If it exists, no user interaction has to take place. If not the database is searched for similar objects, using the object's best identifying attributes. The search for similar data is calibrated to reduce the risk of erroneously matching the object to be imported to an existing object. If no similar object has been found, the object is imported without user interaction. If at least one similar object is found which can not be exactly matched in all major attributes, the record is discarded or a controlling user is asked to make a decision based on the attributes of the existing objects and the object to be imported. In both cases the primary key attributes are stored in the master object index and the object can be identified automatically on the next import.
The "Methodology for the Development of Health Care Messages" of CEN/TC 251 WG 3 has been proved to be a useful guideline for the development of data interchange descriptions for the tumour documentation. It could be demonstrated that it can also serve, to a certain extent, as a kind of guideline for the design of communication interfaces. But the existence of an accepted standard for the medical record which is implemented in a documentation system as well as in the description of the messages does not guarantee easy implementation. The problems which arise when importing data without unified identification system from different sources may require user interaction to a certain degree.
References