The Gieen Tumor Documentation System (GTDS) Review

and Perspectives
Altmann, U., Dudeck, J.
Institut fr Medizinische Informatik, Justus-Liebig-Universitt Gieen
Heinrich-Buff-Ring 44
35392 Gieen
Tel.:

0641 / 99 41380

Fax:

0641 / 99 41359

E-Mail:

[email protected], [email protected]

Summary
Objectives: GTDS is a documentation system used by more than 40 German hospital cancer
registries. This paper discusses the factors that contributed to its success concerning design,
development, and, routine use.
Methods: Success is measured in terms of the system's financial independence of public
grants and its successful use by the registries. The description of the system's use is backed on
a user survey conducted in 1999. Success factors are presented in a descriptive way covering
the topics public sponsoring, general system concepts (functionality, integration into the
process of care and communication with other systems), design (CASE tool, requirements
specification), implementation (ORACLE database and tools), and, interaction with
customers.
Results: GTDS has become the main tool in hospital cancer registries in Germany and
remarkably contributed to their success. Especially in the new states a comprehensive data
network between hospital cancer registries and population based cancer registries has been
established. After the first years of routine use the registries produce valuable data analyses on
the basis of common tools. Under specific conditions physicians use the system directly for
treatment management. The system succeeded to be financed by support contracts for
continuous development which indicates generally good user acceptance. Close interaction
between users and developers is important to meets user requirements during development
and maintenance.
Conclusion: Important success factors are the strong ministry's support including initial
sponsoring and introduction of support contracts, the comprehensive functionality as well as
flexibility and broad user support which allow the adaptation to quite different environments.

Keywords
cancer, tumor, registries, documentation, success factors, systems integration

Introduction
History
Immediately after the reunification of Germany in 1991 our working group on tumor
documentation (Arbeitsgruppe zur Koordination Klinischer Krebsregister - AKKK) at the
Institute of Medical Informatics in Gieen was asked to develop an information system for
hospital cancer registries (HCR) which is now well known as GTDS (Gieener
Tumordokumentationssystem). This work was supported by a grant of the Federal Ministry of
Health and Social Security and was embedded into a large program for better care of cancer
patients that supported the establishment of comprehensive cancer centers including affiliated
HCRs in particular in the New States of Germany.
Environment: German Hospital Cancer Registries
HCRs collect diagnostic, treatment and follow-up data of cancer patients in hospitals and
comprehensive cancer centers. They provide valuable data for quality management and
assessment of therapy strategies under routine conditions. HCRs can also be integrated into
clinical trials or other scientific evaluations.
While hospital cancer registries (or hospital-based cancer registries) can be found in many
countries, German HCRs might differ from the general understanding of this type of registry
in two aspects. Many German HCRs are operated by comprehensive cancer centers. German
comprehensive cancer centers are, according to the definition of their association (ADT
Arbeitsgemeinschaft Deutscher Tumorzentren, http://www.tumorzentren.de), regional
associations of care givers from different institutions with the aim to provide an optimal state
of the art of cancer care. Therefore, HCRs often have to serve many hospitals and also have to
integrate information for one case from different institutions. The second difference is that
they support patient management in an interdisciplinary environment. Due to characteristics
of the German fragmented health system (ambulatory care/GPs on the one side, hospital care
on the other side) there often exist deficits in communication of important medical data.
HCRs are considered to help improving this situation. Another long standing issue of HCRs is
the organization of systematic follow-up care to implement follow-up guidelines.
Goals of the development
Thus, in the design of GTDS we assumed that in the long run the data collected in HCRs have
to be used not only in the registry but also to support interdisciplinary patient care in
oncology. From the very beginning we were aware that various hospital cancer registries will
have different specializations. Therefore GTDS had to provide quite different functions for
using registry data to support patient care and the management of the cancer registry itself.

Development
In a nation-wide working group experts from existing HCRs with various experiences and
also future users participated in the specification process of the system requirements. User
participation has also accompanied the further development since then.
Following the aforementioned design concept we primarily developed a comprehensive data
model consisting of approximately 150 relations to structure the required data according to
the 3rd normal form. The design of the GTDS data model was supported by a powerful CASE
tool (IEF). Although after the initial design a large number of additional tables were
introduced to enable new functionalities, the core model is still valid.
Up to three developers where employed in the project in the initial phase. Two developers are
currently responsible for continuous development and user support.
Technology
The system is based on the ORACLE database and ORACLE development tools
(Developer/2000 Forms and Reports). GTDS is a typical client/server application and requires
at least an initial installation of a small runtime environment on each client PC. Recent
developments to provide web-browser access [1] are based on the JAVA language and open
source tools from the Apache Project (Tomcat Servlet Engine, XML libraries).
Functionality
GTDS supports primarily the management of the Tumorbasisdokumentation, the
comprehensive data standard for hospital cancer registries in Germany [2]. Extensions of this
basic data set can be integrated dynamically and partially be defined by the users themselves.
Besides basic data set entry the following services are provided within GTDS [3].

Information and communication: Overview reports, discharge letters etc. based on

registry data are widely used to provide participating physicians with comprehensive
information about all important events occurring during the course of the disease of a
patient.

Follow-up management and treatment support: Follow-up guidelines and

chemotherapy protocols can be defined and assigned to patients. Based on defined
templates individual examinations or dosages can be calculated and also be adapted to a
patient's situation. The management of care is supported by patient reminders, generation
of documentation sheets, etc.

Evaluation and analyses: Some often used standard reports are provided within GTDS.
For more sophisticated analyses the data spread to numerous tables can be aggregated to
comprehensive data sets that can easily be exported to statistic analysis. [4]

Connectivity: HL7 interfaces are integrated to transfer data from Hospital Information
Systems (HIS) to the GTDS (i.e. ADT and laboratory data, pathology reports etc.) to
facilitate the collection of data and to avoid multiple data entries. A generic import facility
opens the system to take over data from different source systems in various formats.

Cooperation with population based cancer registries: To avoid multiple data

acquisition for both, hospital and population based cancer registries, data can be exported
electronically to population based cancer registries (PBCR). Thus physicians have to
report only to the HCR. On the other hand death certificate information that often is only
available in PBCRs can be imported into GTDS and helps to provide reliable survival data
for data analyses. [5]

Trial support and knowledge based functions: GTDS includes some administrative data
for assigning patients to trials. Trial eligibility can be checked vie an integrated ArdenSyntax [6] module [7]. Protocols and treatment plans can be linked to trials to support the
execution of the defined chain of events.

Extensive material about GTDS (most in German) is available at our web site
http://www.gtds.de.

Objectives
This paper discusses the factors that contributed to the success of GTDS concerning design,
development, and, routine use.

Methods
Measurement of success
Success is measured in terms of the system's financial independence of public grants and its
successful use by the registries.
The system's use was evaluated in 1999 by conducting a user survey on behalf of the Federal
Ministry of Health. The aim was to measure the achievements and to develop strategies for
further directions. The survey was sent out to all registries that used GTDS at that time (29)
and covered the following areas:

Structure of the registry / staff / strategic goals / procedure of documentation

Used functionality and intended use of the system

Level of detail of documentation and expenditure of time

User satisfaction (normal user/administrator)

Intended development of the registry

The fourteen-page questionnaire was partially structured and partially allowed free text. The
results were not blinded since some of the free text statements could only be assessed with
some internal knowledge and this knowledge would also have enabled us to identify the
responding registry in many cases. Where applicable, results were analyzed univariately. The

survey was originally not intended for publication but selected results may help to foster
statements and such will be presented in the appropriate results sections of this paper.
Evaluation of success factors
Success factors are presented in a descriptive way covering the topics public sponsoring,
general system concepts (functionality, integration into the process of care and
communication with other systems), design (CASE tool, requirements specification),
implementation (ORACLE database and tools), and, interaction with customers.

Results
Number of installations / Independence of public grants
GTDS is now in use in more than 40 hospitals cancer registries in Germany. It is one of the
few application systems supported by public funding and developed in a university institute
which have successfully survived and are in continuous use. The successful start of the GTDS
was without any doubts facilitated by the funding of the Federal Ministry of Health and Social
Services. The centers included in this program had to pay the first maintenance fee only after
several years of GTDS experiences and application. The funding program finished in 2000.
But not all cancer centers using GTDS participated in this program and also all new users did
choose GTDS without such incentives.
The number of installations is continuously increasing by approximately 2-4 per year without
any advertising or marketing actions. Up to now only few users (about 5) finished an existing
support contract. Almost all of these centers did not really start working with the system for
different reasons (e.g. no documentation staff, competing established system). In one case the
reason was a technological shift towards a monolithic hospital information system.
Successful use by hospital cancer registries
The success of such a system is highly dependent on its successful use in the registries. A
recent evaluation (publication in progress), carried out on behalf of the German Cancer Aid,
the German Cancer Society and the Association of German Comprehensive Cancer Centers,
showed that about 55% of the comprehensive cancer centers use GTDS. Those centers had a
distinct better performance concerning the topic "hospital cancer registry" than others.
Performance was measured as a score that was composed of answers to eight questions
concerning completeness of data and various aspects of use of the registry. Although no causal
relationship between GTDS use and performance of cancer registries can be derived from this
fact, it indicates a good level of functionality. This evaluation is one of the foundations to
which the 77th Conference of State Health Secretaries referred in June 2004 when it stated that
cancer registries contribute substantially to quality management and patient care. The same
conference appealed to the health insurance companies and the Federal Ministry of Health to

achieve a more complete regional coverage of hospital registries and to make use of registries
for cancer control programs like screening and disease management programs. A (German
language) version of the decision is available at http://www.gmkonline.de/.
Before 1994 the situation of population-based cancer registration in Germany was very
unsatisfactory. Only the small Saarland registry produced data that were extrapolated to the
whole republic. The formerly excellent cancer registration in the new states had decreased to
an unacceptable quantity. To overcome this situation, a federal legislation forced the
establishment of PBCRs in every state until the end of 1999. Subsequently comprehensive
cancer networks between hospitals, HCRs and PBCRs have been established in particular in
the new states of Germany. Due to the integration of HCRs into patient management the data
transferred to the appropriate PBCR are of high quality. In the central PBCR of the New
States more than 90% of the cases are already transmitted electronically nearly completely
from GTDS systems. In some states like Brandenburg, Mecklenburg-Vorpommern and parts
of Saxony a nearly complete registration of cancer patients has been achieved already. The
electronic transfer of data helps to decrease the cost of population based cancer registration to
a large extent.
We have no systematic information about publications which are based on data collected and
stored in GTDS installations. After ten years of routine operation the HCRs report
(informally) that they can see an increasing awareness of the existence and usefulness of
registry data and functionalities by physicians. Several annual reports of tumor centers
(partially with the participation of health departments, health insurances, and, associations of
physicians and hospitals) are now routinely published. They reflect the increasing ability to
provide information on the course of tumor diseases. Reports about quality of medical
treatment have also been published [8] and several centers specialized on breast cancer have
passed the certification process for being recognized as "specialist breast units" with the help
of GTDS registry data.
Factors of success
Development
The decision to use a CASE tool for the design phase resulted in a very successful application
design since only minor changes and extensions of this model became necessary during more
than ten years of routine use of GTDS [3] in different environments.
This development environment allowed a good productivity in the small developer team. The
corresponding runtime environment turned out to be very stable and produces rarely system
crashes. This was very important because otherwise the small developer team would not have
been able to manage development and support.
We were not able to pursue an active marketing which resulted in a slow growth of the

number of installations (due to the restricted marketing capabilities) and enabled us to fulfill
on one side the challenges of new users and at the same time not to neglect the requirements
of existing users.
General remarks concerning the results of the survey
The results of the 1999 survey will be cited in the following subsections. Note that in 1999 the
majority of the GTDS users were still using the old alpha-numeric user interface. From 29
registries 27 answered so that there is only little bias from non-responding registries. Since
there was no blinding, some bias may result from relationships between investigator
(=developer) and respondent(=customer).
Figure 1 shows the use of different aspects and modules of the GTDS system and relate to
functionality described in the introduction. The difference between "basic data" and detailed
"therapy data" is that in GTDS therapy can be documented either in simple categories
(surgery, radiation, etc.) or detailed (type of surgical treatment, etc.), including complications
and adverse events.
Figure 2 shows the results regarding user satisfaction. The categories represent answers to
item related questions, e.g. the choices for the item "data entry" were "data entry at large is
well-done" (category "high satisfaction"), "data entry at large is satisfactory" (category "
significant enhancement required"), and, "data entry is not adequate for routine use" (category
"severe impact on usability").
Comprehensiveness of functionality
The comprehensive functionality provided in the GTDS is an important success factor. We are
aware of at least two other developments of documentation systems which took over essential
parts of our initial data model. Figure 1 shows, that all functionalities available in the GTDS
are used at least in some installations. Registries who want to extend their activities can
seamlessly use the already available additional functionalities.
Variability, Adaptability and Training
Figure 1 also provides some idea about the variability of the systems use. Variations are not
only related to whether a specific functionality is used or not but also to the way how
registrars work: do they abstract information from paper forms or from medical reports? Do
they have the medical records available? Is an entry form adapted to a specific paper form?
Use of medical language is not always coherent with documentation conventions what can
result in ambiguous interpretation of medical data. Defaulting values in a specific way may be
correct in one registry but inadequate in the context of another registry.
It is generally accepted that objectives have to be defined before a system is installed and
used. Unfortunately, the objectives defined in the data standard for tumor documentation [2]
are rather general and comprehensive. In reality resources are limited and each registry has to

define a strategy to cope with the own limitations: shall we limit the number of cases we
document but document these cases extensively or shall we go the other way around? Such
strategies should have to be discussed with the physicians within the tumor center.
Regrettably the physicians' perception of a cancer registry's requirements and capabilities
often is low in the beginning, and the missing input of concrete questions that shall be
answered by the registry can lead to an inappropriate documentation strategy. In addition
there are no general regulations for running and financing HCRs. So it was and is still the
important task of the HCRs to adapt the comprehensive functionality of GTDS to their own
requirements and to convince physicians, administrators and other opinion leaders
continuously of the usefulness of the system by providing required data and reporting services
and thus giving a rationale for their existence.
It is clear that on one hand a system for many registries has to provide adaptability and to be
open to varying uses and on the other hand, if a high grade of user adaptability is required
specific workflows can only be enforced to some degree. Figure 2 reflects this conflict
showing that although the majority of registries were satisfied with data entry and
functionality, there is always some need for improvement to better support specific
workflows.
We (the developers and "leading" users) learned much about the variety of GTDS usage when
we started to define and implement the standard data analysis sets for improving the data
analysis capabilities of the system.
To conclude it is important to provide sufficient training und understanding of the logic of the
system to enable users to work efficiently. We try to compensate for deficits resulting from
non optimal workflow by providing extensive user support which is esteemed as the results
for "user support availability" and "user support trouble shooting" show.
Integrability
Integration is important to avoid multiple data entry with its related problems (uneconomic
and unaccepted documentation, transcription errors). The first step was the integration of
HCRs with PBCRs which was also backed by the 1994 federal legislation that allowed
physicians to report incidence data via HCRs. But our approach goes beyond this cooperation. We try to help the HCRs to establish themselves as centers of oncology data
networks [5], where data is also shared between HCRs when patients are treated in different
centers. In addition data have to be exported to other institutions that carry out quality
management programs or scientific investigations, for example comparable to the National
Cancer Database (NCDB) program by the US American Commission on Cancer
(http://www.facs.org/dept/cancer/ncdb/). Yet the number of such use is still small and it is a
continuous process to raise awareness of the HCRs capabilities to take part in such activities.
The user satisfaction in the 1999 survey concerning integrability was not very high which

seems to contradict these positive experiences. But the question was related to the system's
ability to access data from other systems and to provide data to other systems which has to be
assessed rather in the context of hospital information systems than in the context of
communication with PBCRs. Indeed we were able to introduce different interfaces to various
systems at multiple locations since 1999. Yet the majority of registries still don't use this
possibility. This is often related to organizational and financial issues. Standards
communication interfaces as such based on HL7 are sometimes not as easily available as
desired, their installation causes additional costs or technical staff is overloaded.
Integration means also embedding tumor documentation into clinical workflow. One of our
intentions is to bring GTDS to the physician's desk. But the number of physicians working
intensively with the GTDS client is still limited in particular due to logistical problems. At the
University Hospital of Gieen one of these successful implementations is running in an
oncological day clinic where physicians enter and retrieve data online from the GTDS. Many
business processes are supported starting with the calculation of chemotherapy and finishing
with discharge letters.
User interaction and user satisfaction
As shown above, we have a close relationship to our users through our helpline. This
relationship helps us also to understand changing or newly upcoming requirements. Training
courses and workshops are regularly organized and user requirements and experiences are
used to continuously improve the system. As a small team we communicate rather efficiently
and can provide solutions often very quickly. For example, when new fields of activity like
disease management programs or certification of specialist breast units emerged we provided
new functionalities very soon after they were requested.

Discussion
Competing systems
Some generally very active HCRs still use own developments that are optimally adapted to
their particular needs and sometimes have a history that goes back to late 1970ies, e.g. based
on the program generator KRAZTUR [9]. Usually the operation of such systems is related to
appropriate in-house development capabilities. Besides GTDS a small number of actual
developments exist:

ONDIS is a development in the Westfalen part of the state Nordrhein-Westfalen which is

provided by the regional Association of Statutory Health Insurance Physicians (KV-WL)
as a tool with a focus on follow-up management. The system is the successor of the no
longer supported system INMEDD that was also distributed outside Westfalen to some
extent. INMEDD like GTDS was financed by maintenance fees but was stopped when the
KV-WL introduced its system mandatory for all INMEDD registries in Westfalen-Lippe.
The lesson to be learnt from this is that health politics can have significant influence on

the success of a system. This is also true for GTDS although GTDS is regionally more
distributed and financially independent from such an organization's politics.

At least three commercial developments exist with a rather active marketing. Generally
they aim not so much at the registry sector but more at departments with a specific
scientific interest or interest in quality management. Sometimes they are backed by
opinion leaders from scientific medical societies (e.g. Mastology) for specific application
areas (e.g. specialist breast units). Nevertheless the functionality provided by these
systems and the functionality of GTDS overlap and they compete at some locations. Since
the developments are rather new, the long-term effects of these developments cannot yet
be assessed. We try to establish communication interfaces at locations where both systems
are used.

For pediatric oncology a specific documentation system (DOSPO/CATIPO) [10] existed

which aimed at support of multi-centre trials, support of documentation and therapyplanning, and, support of electronic data exchange to trial centers and the childhood
cancer registry. Childhood cancer registration in Germany is completely separated from
adult cancer registration with one central childhood cancer registry and large support of
clinical trials where most patients are treated. The approach of an integrated
documentation with this system was quite similar to that of GTDS. The project was
carried out at the University of Heidelberg. Unfortunately the project had to be stopped
since there was no perspective for continuous financial support. When we compare this to
the financing of GTDS, we have to state that the sponsor of our work (Federal Ministry of
Health) requested concepts for continuous financing of the project three years before the
project's ending and also gave political support to establish the support contracts with the
registries.

Completeness of functionality and clinical integration

Systems like OCIS [11] and ONCOCIN [12] have been successfully developed to support the
management of patient care in oncology. In his final report "An Integrated Oncology
Workstation" [13] to the US National Cancer Institute (NCI) E.H. Shortliffe describes
scenarios for a system "that provides an oncologist with a wide variety of data-management
and decision-support tools [] . The notion of integration requires that the various resources
are tied together in a uniform fashion which allows the user to move fluidly from one
application to another [] . ".
With our idea of clinical integration we address a number of similar issues. For example, the
definition and calculation of chemotherapy treatment plans helps to implement knowledge
and treatment supporting guidelines. Communication interfaces provide integration of data
from different sources. Trial eligibility can be checked via an integrated Arden module. [6, 14]
But even where communication interfaces are in operation and optimal data integration seems
to be achievable, GTDS is mostly used by registrars, not by physicians. One reason for this
rare use is that an oncology specific system can provide support of clinical workflow only in
specific oncological environments. In other environments oncological diseases are only part
of the patient spectrum and it is usually not acceptable for the user to operate different user
interfaces. In contrast to US American comprehensive cancer centers (CCC) German CCCs

are often associations of not oncology specific departments and the success of such
"monolithic" systems for cancer patients like OCIS or ONCOCIN cannot be expected in this
environment.
Our strategy to address this issue is to split GTDS functionalities in small and simple units
that can be provided via web browser or web services and thus can more easily be integrated
into other systems [1]. Still this strategy will not have short term effects since although the
technical basis for such services exists (e.g. SOAP) manufacturers of hospital information
systems would have to adapt their systems to integrate the appropriate functionality.
Various initiatives to integrate registry data sets into general hospital or physician office
information systems were reported informally. We think that this approach can be successful
for a well-defined, limited environment. But a registry's business processes are different from
simply building new components of medical records. For example they often require the
integration of data from various sources that also reside outside this environment. We see such
developments more as a valuable source for a registry system than as a replacement for a
registry system.
Looking back at the multiple successful and unsuccessful efforts to make integration work we
can fully confirm Shortliffe's statement that "The striking lesson of the report is that most of
the barriers to successful implementation of a fully integrated oncology workstation are not
technical but logistical and sociopolitical."
Perspectives
During last years hospital cancer registries have not been well accepted at least in some parts
of the medical community. The already mentioned evaluation on behalf of the German Cancer
Aid, the German Cancer Society and the Association of German Comprehensive Cancer
Centers has shown convincingly, that HCRs integrated in the multidisciplinary care process
fulfill an important task to improve patient treatment. The aforementioned decisions of the
77th Conference of the Secretaries of Health show the increasing public awareness that the
data collected in HCRs are a reliable and easily available basis for treatment evaluation and
quality control. Most of the successfully running HCRs in comprehensive cancer centers are
GTDS users. Even if the tumor documentation system is only one factor of a successful
performance of an HCR, the functionality of the tool is an important prerequisite for
providing the necessary and required services by the registry. GTDS does fulfill this task
successfully and played therefore an important role in the now apparently emerging general
acceptance of HCRs in Germany.
Integrated patient care is one of the most actual topics of health policy. Oncology is an
example, where integrated care concepts are especially important because of the high number
of different specialties and physicians who are involved in the treatment of a specific case.

Therefore we will proceed with our efforts towards most integrated tumor documentation.
HCRs have to find their role in such care concepts since it is not economical to build up
parallel information infrastructures. This role will be different for each registry since the
environment will be different at each location. In some registries most of the integrated care
data will be transferred electronically via communication interfaces. Other registries will have
to provide specific user interfaces to collect data at the right place and at the right time in the
process of care. If physicians have to document directly, these data units have to fit into the
workflow, e.g., when planning or discharge activity is done.
To reduce technical requirements to a minimum, such solutions will increasingly be webbrowser based. The further development of the GTDS web interface will enable the registries
(in combination with certificates, like provided by health professional cards, for encryption
and authentication) to spread their network from the hospitals to the physicians offices.

Conclusion
GTDS is a successful application system for running hospital cancer registries in combination
with online functionality for supporting patient care. Among the success factors is the initial
funding by public grants that continued until some critical mass of installations was achieved.
In addition, there existed strong political support to transfer maintenance costs to the users of
the system.
Data processing systems for such a specific application area as cancer registries are extremely
dependent on health political factors. We hope that the positive results from hospital cancer
registries will promote the further development.
Flexibility and extensive user support, not only restricted to closely system related issues,
contributed to a generally good "customer relationship". The reliable funding of new
developments by support contracts and the slow growth of the number of installations (due to
the restricted marketing capabilities) enabled the small developer group to fulfill on one side
the challenges of new users and at the same time not to neglect the requirements of existing
users.
The broad functionality developed in co-operation with users and experts from pre-existing
registries as well as the continuous adaptation to new requirements like integrated patient care
guarantees the usability in various types of registries and the development of the registries
themselves.

References
[1] Altmann U, Tafazzoli AG, Katz FR, Dudeck J. XML-Based Application Interface Services - A
Method to Enhance Integrability of Disease Specific Systems. Int J Med Inf. 2002 Dec;68(13):27-37, Elsevier Science Ireland Ltd
[2] Dudeck J, Wagner G, Grundmann E, Hermanek P. Basisdokumentation fr Tumorkranke. 4. Ed.,
Springer Verlag Berlin Heidelberg New York etc. 1994
[3] Altmann U, Katz FR, Haeberlin V, Willems C, Dudeck J.Concepts of GTDS: An Oncology
Workstation. MEDINFO 95 Proceedings, IMIA 1995: 759-762
[4] Altmann U, Burger U, Gruber F, Katz F, Marqua S, Schmieder G, Schubotz B, Tillack A,
Wulff V. Datenanalyse auf Knopfdruck - ein zentrumsbergreifendes Auswertungskonzept fr
klinische Tumorregister. In: Informatik, Biometrie und Epidemiologie in Medizin und Biologie 23 2002. Abstracts der 47. Jahrestagung der GMDS, pp 54-55
[5] Altmann U, Dudeck J, Eisinger B, Kunath H, Schott G, Kurbjuhn H, Wchter W, Tafazzoli AG,
Katz FR. Development Of An Oncology Data Network In Germany. In: A. Hasman et al. (Eds.):
Medical Informatics Europe '00. Amsterdam: IOS Press 2000, 959-963
[6] Hripcsak G, Clayton PD, Pryor TA, Haug P, Wigertz OB, Van der lei J. The Arden Syntax for
Medical Logic Modules. SCAMC 1990: 200-204
[7] Tafazzoli AG, Altmann U, Burkle T, Holzer S, Dudeck J. Integrated decision support in a hospital
cancer registry. Artif Intell Med 2002 Mar;24(3):243-55
[8] Kurbjuhn, H., Marqua, S. Tumorzentrum Land Brandenburg
Sachbericht Onkologie 2002, www.tumorzentrum-brandenburg.de
[9] Ellssser KH, Kohler CO, Wagner G. KRAZTUR--a generator for medical documentation and
information systems. Methods Inf Med. 1981 Oct;20(4):191-5
[10] Knaup P, Wiedemann T, Bachert A, Creutzig U, Haux R, Schilling F. Efficiency and safety of
chemotherapy plans for children: CATIPO--a nationwide approach. Artif Intell Med. 2002
Mar;24(3):229-42
[11] Enterline JP, Lenhard R, Blum BI. A clinical information system for oncology. Springer Verlag
New York Berlin Heidelberg 1989
[12] Kent DL, Shortliffe EH, Carlson RW, Bischoff MB, Jacobs CD. 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

[13] Shortliffe EH. An Integrated Oncology Workstation. National Cancer Institute, Maryland,
Bethesda 1990
[14] McDonald CJ, Hui SL, Smith DM, Tierney WM, Cohen SJ, Weinberger M, McCabe GP.
Reminders to Physicians from an Introspective Computer Medical Record. Annals of Internal
Medicine, 1984;100:130-138

Figure 1: Use of GTDS functionality (1999 survey)

Figure 2: User satisfaction (1999 survey)