You are on page 1of 8

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341

journal homepage: www.intl.elsevierhealth.com/journals/ijmi

Expressing clinical data sets with openEHR archetypes:


A solid basis for ubiquitous computing

Sebastian Garde a,b,∗ , Evelyn Hovenga a , Jasmin Buck c , Petra Knaup c


a Health Informatics Research Group, Faculty of Business and Informatics, Central Queensland University,
Melbourne, Vic and Rockhampton, Qld, Australia
b Austin Centre for Applied Clinical Informatics, Austin Health, Heidelberg Vic, Australia
c University of Heidelberg, Department of Medical Informatics, Germany

a r t i c l e i n f o a b s t r a c t

Article history: Purpose: The purpose of this paper is to analyse the feasibility and usefulness of expressing
Received 15 December 2006 clinical data sets (CDSs) as openEHR archetypes. For this, we present an approach to trans-
Received in revised form form CDS into archetypes, and outline typical problems with CDS and analyse whether some
15 February 2007 of these problems can be overcome by the use of archetypes.
Accepted 19 February 2007 Methods: Literature review and analysis of a selection of existing Australian, German, other
European and international CDSs; transfer of a CDS for Paediatric Oncology into openEHR
archetypes; implementation of CDSs in application systems.
Keywords: Results: To explore the feasibility of expressing CDS as archetypes an approach to transform
Electronic health records existing CDSs into archetypes is presented in this paper. In case of the Paediatric Oncology
Semantic interoperability CDS (which consists of 260 data items) this lead to the definition of 48 openEHR archetypes.
openEHR To analyse the usefulness of expressing CDS as archetypes, we identified nine problems
Archetypes with CDS that currently remain unsolved without a common model underpinning the CDS.
Clinical data sets Typical problems include incompatible basic data types and overlapping and incompati-
Computerized medical record ble definitions of clinical content. A solution to most of these problems based on openEHR
systems archetypes is motivated. With regard to integrity constraints, further research is required.
Conclusions: While openEHR cannot overcome all barriers to Ubiquitous Computing, it can
provide the common basis for ubiquitous presence of meaningful and computer-processable
knowledge and information, which we believe is a basic requirement for Ubiquitous Com-
puting. Expressing CDSs as openEHR archetypes is feasible and advantageous as it fosters
semantic interoperability, supports ubiquitous computing, and helps to develop archetypes
that are arguably of better quality than the original CDS.
© 2007 Elsevier Ireland Ltd. All rights reserved.

1. Introduction able devices to continuously monitor and respond to changes


in the health of a patient [1]. Ubiquitous computing, i.e. the
In our quest for ubiquitous computing, the Health Informat- integration of computation into the environment, rather than
ics community currently investigates the use of unobtrusive, having computers which are distinct objects, is an exciting
active, non-invasive technologies, including for example wear- research field that offers potential e.g. for higher quality and


Corresponding author at: Health Informatics Research Group, Faculty of Business and Informatics, Central Queensland University,
Melbourne, Vic. and Rockhampton, Qld., Australia. Tel.: +61 3 9496 4040; fax: +61 3 9496 4224.
E-mail address: s.garde@cqu.edu.au (S. Garde).
URL: http://healthinformatics.cqu.edu.au (S. Garde).
1386-5056/$ – see front matter © 2007 Elsevier Ireland Ltd. All rights reserved.
doi:10.1016/j.ijmedinf.2007.02.004
i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341 S335

more user-friendly and comprehensive data capture. On the existing standards) for good data development in Ref. [7], cir-
other hand, we believe that ubiquitous computing requires culated until January 2007 for public comment and now being
ubiquitous availability of information and knowledge as a pre- revised based on this feedback. Also, desiderata for terminolo-
requisite. gies (e.g. ICD) have been postulated by Cimino [8]. These are
A considerable amount of work has already been under- not applicable as such to CDSs or archetypes, but still helped
taken by the Health Informatics community along the us to identify some common problems of CDSs. In addition,
path to ubiquitous use of patient information and health our work on defining CDSs and implementing them in applica-
knowledge: National and international standards develop- tion systems with structured data entry is of importance here:
ments, connectivity using HL7, document exchange using
HL7 CDA [2], comprehensive specifications for Electronic • standardizing terminology in Paediatric Oncology: the basic
Health Records like the recent release of openEHR Version data set [5];
1.0 (http://www.openEHR.org), the development of special- • recording clinical data: from a general set of record items to
ist clinical data sets (CDSs) on a national and sometimes case report forms (CRF) for clinics [9];
international level. Also the detailed clinical models (DCM, • an architecture for using routine data for nationwide
http://detailedclinicalmodels.org) initiative is worth mention- research [10];
ing internationally. Creating CDSs is a tedious task and the • TERMTrial: terminology-based documentation systems for
bigger the scope or the applicable region is, the bigger is the cooperative clinical trials [4].
effort [3]. To name but a few, in Germany, Merzweiler et al.
defined a basic data set for pediatric oncology [4,5], Flynn et Most importantly, we used the process described later in
al. recently defined the European data standard for clinical car- this paper for the development of archetypes based on existing
diology practice [6], and the international Nursing Minimum CDSs to develop archetypes based on the German Basic Data
Data Set (i-NMDS, http://www.inmds.org) is currently under Set for Paediatric Oncology.
development.
With the release of openEHR Version 1.0 there is a com-
2.2. The openEHR and archetypes approach
mon information and knowledge model for Electronic Health
Records available that can solve some of these still pre-
The openEHR approach (http://www.openEHR.org) is defined in
vailing problems of insufficiently ubiquitous information
comprehensive specifications originally based on the results
and knowledge in the health sector by improving semantic
of the European Union’s GEHR-Project, used and refined in a
interoperability and providing a common basis for decision
series of further European and Australian projects. Its design
support, data mining, etc.
principles are described by Beale et al. [11]. The main char-
To investigate our hypothesis that ‘expressing clinical data
acteristic of openEHR is a two level modelling approach for
sets as openEHR clinical content models (archetypes) is feasible
EHRs. The first level of this approach is the reference model
and useful, the aim of this paper is to
which is reduced to a relatively small set of classes to sup-
port the medico-legal requirements and record management
• present an approach to develop openEHR archetypes based functions. The second level involves the openEHR archetype
on existing CDSs (feasibility); methodology representing all the clinical knowledge that
• outline typical problems that arise when developing CDSs; rather than being hard-coded in databases and applications
• analyse whether openEHR archetypes can be used to over- is defined in archetypes. Each archetype represents one clini-
come some of the problems of CDS development (usefulness). cal concept by constraining instances of the openEHR reference
model. By using two levels – a reference model and archetypes
Please note that nothing in this paper is intended to imply – openEHR separates technical concerns from clinical data col-
that the concept of CDSs is unimportant or needs to be lection. Archetypes themselves are terminology-neutral, but
replaced. Rather, it is about showing an alternative way to can link to external terminologies like SNOMED CT.
structure and organise CDSs.

3. Results
2. Material and methods
The Clinical Data Set for Paediatric Oncology in Germany
2.1. Analysis of clinical data sets consists of 260 items. Using the process described in this
paper, we transferred the CDS into a total of 46 openEHR
The results in this paper stem from the analysis of var- archetypes. Before we present the problems found with this
ious existing CDSs and typical development processes for and other CDSs and discuss possible solutions using the
CDSs with a special focus on German, other European and openEHR archetype methodology, we present an overview of
Australian data sets. Further, we analysed the openEHR and the process used to transform CDSs into openEHR archetypes.
archetypes approach with regard to their suitability for the
development of CDSs. For this, we investigated existing liter- 3.1. An overview of the process to transform CDSs
ature for criteria for ‘good’ CDSs. While we found very little into archetypes
published literature dealing with this exact problem, some
not yet published works are currently circulated as drafts, In order to explore the feasibility of our approach to express
for example the principles (e.g. system-independency, use of CDS as archetypes, we took an existing CDS and transferred
S336 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341

it into archetypes. The process we followed is documented in device was used) can be added to the archetype. Broad input
this section. from clinicians should be sought during this phase (however
After proper analysis of the existing CDS, initially all appro- if the data set is already well defined less input is necessary).
priate high-level archetype concepts present in the CDS, for Often CDSs do not define the exact points of time when data
example ‘blood pressure measurement’ or ‘diagnosis’ should documentation is required. If the data set does not provide all
be defined. It is possible to use an Archetype Editor at the necessary information, this information has to be gath-
this stage already, but not necessary. Of good value is the ered or agreed on by the responsible domain experts. Finally,
use of a mindmap laying out all the archetype concepts.1 section and composition archetypes are defined for ordering
Thus, overlapping concepts can be identified and appro- the clinical contexts into a fitting structure.
priately dealt with. At this stage, we also decide on the Once an archetype is defined, it should be submitted to the
use of existing demographics archetypes. These should be Clinical Review Board of openEHR as for semantically interop-
identical or specialized from existing openEHR demographics erable systems, archetype development should be coordinated
archetypes. to avoid incompatible archetypes for the same concept by
After all high-level archetype concepts are defined—and systematic Domain Knowledge Governance. Thus, it can be
before actually designing the archetypes from scratch using ensured that no overlapping concepts or otherwise incom-
an Archetype Editor, it is necessary to check for existing ref- patible archetypes are used for different health disciplines,
erence archetypes. Archetypes already published for example etc.
on the openEHR website have undergone extensive peer-review The resulting archetypes will look considerably different
already and thus are a valuable source for any archetype than the original CDS. This is because archetypes define
developer. The Archetype Finder developed by the first author a comprehensive clinical concept, whereas CDS are data-
of this paper is available at http://www.archetypes.com.au oriented.
and helps identifying relevant existing archetypes by use of
an OWL ontology [3]. The use of the Archetype Finder by 3.2. Developed archetypes
archetype developers avoids that already defined archetypes
are reinvented thus saving effort and also fostering seman- An overview of some the developed observation, evaluation,
tic interoperability by avoiding overlapping and incompatible instruction and action archetypes is given in Fig. 1. In addition,
concepts. If an archetype is only available in a foreign language we developed SECTION archetypes (roughly equivalent to Doc-
it can be translated. If no fitting archetypes are discovered, ument Headings), and structural archetypes (e.g. ITEM TREE
an appropriate structure for the new archetype has to be archetypes), which can be reused in various other archetypes,
selected: This includes the decision if a clinical concept and ADMIN ENTRY archetypes, which are used for adminis-
is an trative purposes.
Fig. 2 presents one concrete example for the conversion of
• Observation (i.e. objective data the health professional the representation of toxicities in existing CDS to one openEHR
observes from the patient, e.g. a blood pressure measure- archetype. Although both CDS and archetype are in German, it
ment); is evident from this figure that we chose to represent toxicities
• Evaluation (i.e. opinions, including assessments, goals and differently in the resulting archetype: The original CDS uses
plans by the health professional usually based on observa- coding tables to define the various toxicities like ‘vomiting’
tions, e.g. a diagnosis); (German: “Erbrechen”) and the available value set (here: num-
• Instruction (i.e. the health professional instructs an ‘agent’, ber of episodes within 24 h coded to severities 0–4) whereas
e.g. a medication order); archetypes can explicitly represent these toxicities and define
• Action (i.e. an action on the patient, e.g. a medication action, appropriate value sets. (NB: These value sets could also be
which includes among others the dispensing and adminis- derived from or linked to a terminology query, e.g. to SNOMED
tration of the medication. Actions are often but not always CT.) (Fig. 3).
based on an instruction).2
3.3. Problems with current CDSs

Using an Archetype Editor, the archetype is then defined (or


Notwithstanding the importance of the work on CDSs,
specialised respectively) by adding data items of the appropri-
there are several problems that remain unsolved even if
ate type, binding data items to internal codes or terminologies
all clinical data were formally expressed in standardized
like SNOMED CT. For certain archetypes, History events are
CDSs but not following a common methodology: during
defined to express the points of time when the data is sup-
our work on CDSs, implementing them in application sys-
posed to be captured. State (essential for the interpretation of
tems with structured data entry and transferring them to
a measurement) and Protocol information (e.g., what kind of
openEHR archetypes, we observed the problems outlined in
Table 1.

1
Cp. the Mindmap of existing archetypes at http://svn.openehr.
3.4. The potential of openEHR to overcome the
org/knowledge/archetypes/dev/html/en/ArchetypeMap.html.
2 problems with CDSs
The resulting process model of observations, evaluations,
instructions and actions is a synthesis of Lawrence Weed’s
problem-oriented method of EHR recording, and later related The openEHR approach and archetypes address the problems
efforts, including among others the model of Rector et al. [12]. associated with CDSs as presented in Table 2.
i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341 S337

Fig. 1 – A simplified overview of a selection of developed ‘clinical’ archetypes for Paediatric Oncology. Not taken into
account are administrative archetypes (ADMIN ENTRY), structure archetypes (e.g. ITEM TREE), or SECTION archetypes.

Fig. 2 – An example of the conversion of the 260 items of the German CDS for Paediatric Oncology to 46 openEHR archetypes:
Toxicities as coded in the CDS are converted to openEHR archetypes. Toxicities in the CDS are coded in corresponding coding
tables, whereas we chose to incorporate the various toxicities as distinct fields directly into the archetype.
S338 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341

Fig. 3 – A screenshot from Ocean Informatics’ Archetype Editor, displaying the state data for a Blood Pressure Measurement.
State data is the data that is required for safe interpretation of the actual measurement.

the definition of basic data types. One particular problem


4. Discussion we encountered during the development of our archetypes
was the insufficient support for hierarchical archetypes,
The ‘good’ modelling of clinical content is one of the most which could flexibly reuse other existing archetypes as a
important tasks we face today in Health Informatics. As such, part of their own. While the openEHR specifications allow
the development of CDSs with an increasingly international this, no tooling support was available to support this. In
scope is of vital importance. We believe that the presented discussion with other archetype developers, we found that
results support our hypothesis that expressing CDSs as this is a common problem which needs to be addressed and
openEHR archetypes is (a) feasible and (b) useful as it helps to the most recent version of the Archetype Editor (Release 1
better structure CDS. To overcome some of the shortcomings candidate, Build 1231 available from http://oceaninformatics.
of current CDSs (like conflicting basic data types) a uni- biz/archetype editor/ArchetypeEditor download.html) now
form model like the openEHR model is helpful. To overcome includes so-called Cluster and Element archetypes to facil-
other shortcomings like overlapping, inconsistent concepts, itate these hierarchies. With regard to consistently binding
systematic Domain Knowledge Governance is required in archetypes to a user-nominated terminology like SNOMED
addition. As each archetype forms a clearly defined semantic CT, a problem increasingly recognised among archetype
unit that expresses one clinical concept, archetypes enable developers is that the terminology itself has to be internally
knowledge to be governed within clearly defined boundaries. consistent and complete. Also binding archetypes to a termi-
Some of the described problems of CDS development can nology that supports post-coordination like SNOMED-CT can
be overcome by other means, e.g. by the development of a cause some challenges.
Guide to Data Development [7]. Archetypes enable clinicians With regard to the comparison of CDS and archetypes, a
to focus on the clinical content, not on technical details like set of archetypes could be compared to a maximum basic data
i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341 S339

Table 1 – A summary of problems identified with clinical data sets


Problem 1: Basic Data Types CDSs use different kinds of basic data types. This imposes various kinds
of challenges when exchanging or migrating existing data
Problem 2: Presentation Formats CDSs use different kinds of presentation formats. This is confusing for
clinicians and technicians alike
Problem 3: Design principles CDSs do not necessarily follow basic design principles (e.g. properly
modelled relationships between concepts, optionality or repeatability of
concepts). This leads to problems in implementing the CDS—on paper or
electronically
Problem 4: Time of data capture CDSs often do not define when and how often which data item has to be
captured. This also leads to problems with conventional or electronic
data capture. In addition, the workflow to document the data is effected
Problem 5: Interpretation of the data CDSs often do not or not consistently define data important for the
interpretation of a measurement. For example, without the information
whether a patient was resting or exercising before a blood pressure
measurement, the actual blood pressure reading cannot be interpreted in
a clinically meaningful (and thus safe) way
Problem 6: Integrity constraints CDSs often do not define integrity constraints that will allow data
validation at runtime. This leads to data quality issues as ‘No study is
better than the quality of its data’ [13]. Also the American Food and Drug
Administration demanded in their industry guidelines for computerized
systems used (in clinical trials) to ‘alert the user to data that are out of
acceptable range’ [14]
Problem 7: Replication of domain knowledge Domain knowledge is replicated inconsistently within or across the
various data sets. This leads to overlapping clinical concepts, thus
reducing the possibility of sharing/reusing the data according to the
document once, use multiple times paradigm (e.g. [15]) and also endangering
semantic interoperability.
Problem 8: Multi-language support Depending on the tools used to model CDSs, no support may be provided
to develop or maintain CDSs in different languages. This is becoming
increasingly relevant for example in the EU; compare the multi-language
support of GALEN’s Classification Workbench (CLAW) for clinical
terminologies [16]
Problem 9: Non-integrated specialist applications Tools to support or make use of CDSs are reinvented all the time, and
specialist applications which are not integrated in the master health
information system are developed and have to be maintained

set, whereas a CDS would usually serve as a minimum basic representation for a clinical concept. However, as archetypes
data set. While this statement is not inherently true of the separate informatics concerns and clinical content discus-
two approaches, it describes the way the two approaches are sion, in our experience from archetype workshops recently
currently usually used. The way we currently use these two conducted for clinicians in Melbourne, Sydney and Brisbane,
approaches is to a large part due to the direction that on the archetypes help clinicians to focus on the discussion of clinical
one hand existing CDSs and CDS design tools and on the other content, serve as a great ‘change agent’ and are a good means
hand existing archetypes, archetype principles and archetype to involve clinicians in the ‘boring’ modelling of clinical con-
design tools provide. tent. Thus, by using archetypes to develop new CDSs, a more
Thus, reporting based on defined CDSs can be seen as one streamlined development process can be adopted. Some train-
feature of an archetype-based system. Although we cannot ing for clinicians serving as lead developers for archetypes is
prove it yet, we believe that openEHR archetypes are more necessary to understand the basic concepts of archetypes [18].
expressive than any kind of conventional structure for CDSs. More generally, the openEHR two-level modelling and
Because of this and the described advantages of archetypes, archetype methodology cannot overcome all of the barri-
we believe that openEHR archetypes are an adequate means ers to ubiquitous computing (cp. [19]). For example, easier,
for developing and structuring new CDSs. As shown in Sec- higher quality, more convenient and faster data capture at
tion 3.1, it is also possible to transform existing CDSs into the point of care (or in fact anywhere) as envisioned by ubiq-
archetypes. Generally speaking, the better the quality of the uitous computing (e.g. wearable devices, and combination of
CDS adheres to good data development guidelines, the less technologies such as voice or handwriting recognition) are
effort is required to transform it into a collection of archetypes. beyond the scope of this approach. The openEHR approach
We note that this transformation is not an automatic process, can however provide the common basis for ubiquitous pres-
but requires thinking and judgment on a conceptual level, ence of meaningful and computer-processable knowledge and
and additional clinical input during the actual development information and thus contribute to the usability of clini-
of these archetypes. Also, archetypes do not solve the prob- cal systems, improve data quality, and improve semantic
lem that domain experts will need to agree on the appropriate interoperability.
S340 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341

Table 2 – Solutions to the problems identified based on the openEHR approach


Solution to Problem 1 The openEHR approach offers a common reference model. It uses, among others, the ISO 11404 standard for basic
data types. Thus with openEHR, CDS developers automatically adhere to existing standards
Solution to Problem 2 Existing tools like the Archetype Editor or the Archetype Workbench present archetypes in various ways that can be
easily understood by clinicians and technicians (for example, prototype graphical user interfaces, HTML rendition
of the archetype). In Australia, this is used for example by major Australian institutions like the National E-Health
Transaction Authority (NEHTA, http://www.nehta.gov.au) who successfully develop national specifications based on
archetypes
Solution to Problem 3 Archetypes offer a predefined structure for expressing clinical knowledge, thus providing CDS developers with the
necessary structure to build their data sets in a uniform way adhering to basic design principles
Solution to Problem 4 Archetypes have inbuilt support for defining time-series when recordings should take place (History events) offering
a sophisticated model to define time based on clinical needs. This includes points in time as well as time intervals,
for example used to express the postural change as the difference between standing and sitting/lying blood pressure
Solution to Problem 5 Relevant archetypes have state data, i.e. all information that is relevant for the interpretation of a measurement can
be captured in a consistent way. Fig. 3 displays a screenshot of the state data for a blood pressure measurement. We
note that CDS developer can of course use a simple word processor to include such specifications in any CDS. The
value of the archetype approach for this problem as well as the previous problem lies in the fact that the user is
prompted to consider such facets as part of the CDS/archetype specification and has a user-friendly and standard
way of entering them
Solution to Problem 6 Archetypes are also used to define integrity constraints in a uniform way that can be used to validate captured data.
In an archetype-enabled clinical system this will eventually be done automatically or with only minor
coding/integration efforts by adding the archetype to the system. It has to be said that not all possible types of
integrity constraints are currently supported by openEHR archetypes or can only be expressed by so-called
‘invariants’, which are very technical and formal in nature and not recommended for use by clinicians. More
research is needed in this complex area and research conducted on integrity constraint has to be implemented (cp.
[17]).
Solution to Problem 7 Processes to ensure that domain knowledge is and remains consistent are being put in place by the openEHR
foundation to avoid the inconsistent re-definition of clinical knowledge, and to avoid the definition of clinical
concepts that are overlapping. To support these processes (by Domain Knowledge Governance as discussed in [3]),
the Archetype Finder – developed by the first author – can be used. The Archetype Finder has relevant meta-data for
archetypes based on a Protégé-OWL ontology to enable a high precision and high recall of relevant archetypes
(http://www.archetypes.com.au). Making agreed archetypes freely available at one central place is another
mechanism to avoid ‘reinventing the wheel’
Solution to Problem 8 Since any translation occurs within one archetype only, translating an archetype is relatively easy and meaning and
structure can be preserved across languages. This is comparable to the multi-language support of GALEN’s
Classification Workbench [16] for terminologies
Solution to Problem 9 Existing tools like the Archetype Editor and the Archetype Finder offer considerable support during the
development of archetype-based CDSs. As agreed models of clinical or other domain specific concepts, archetypes
are clinically meaningful entities with a common structure and have the same meaning no matter where they
appear. Thus, archetypes can be shared by multiple health systems and authorities and information can be
exchanged between different systems with increased ease and semantic meaning. This may eventually lead to
clinical systems based on these archetypes that are more easily maintainable as domain knowledge needs no
longer be hard-coded into the system

cussion about openEHR and archetypes in general and this


5. Conclusion project in particular.

In the forthcoming era of ubiquitous computing, we must not


neglect the fact that ubiquitous computing involves ubiqui- references
tous access to information and knowledge. We conclude that
a good common information model and an archetype-based
approach can be of vital importance in realizing this. The [1] M. Scheffler, E. Hirt, Wearable devices for telemedicine
openEHR approach cannot overcome all barriers to Ubiquitous applications, J. Telemed. Telecare 11 (Suppl. 1) (2005) 11–14.
Computing. Therefore, existing CDSs should in our opinion [2] R.H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F.M. Behlen, P.V.
Biron, A. Shabo Shvo, HL7 Clinical Document Architecture,
be transferred to archetypes and new data sets directly be
Release 2, J. Am. Med. Inform. Assoc. 13 (2006) 30–39.
defined using archetypes; this will foster semantic interop-
[3] S. Garde, P. Knaup, E. Hovenga, S. Heard, Towards Semantic
erability, support ubiquitous computing and help to develop Interoperability for Electronic Health Records: Domain
archetypes that are arguably of better quality than the original Knowledge Governance for openEHR Archetypes, Methods
CDS. Inf. Med., 2006, in press.
[4] A. Merzweiler, R. Weber, S. Garde, R. Haux, P. Knaup-Gregori,
TERMTrial—Terminology-based documentation systems for
Acknowledgements
cooperative clinical trials, Comput. Methods Programs
Biomed. 78 (2005) 11–24.
The authors would like to thank Dr. Sam Heard, Dr. Carola [5] A. Merzweiler, H. Ehlerding, U. Creutzig, N. Graf, B. Hero, P.
Hullin, Dr. Heather Leslie and Thomas Beale for valuable dis- Kaatsch, M. Zimmermann, R. Weber, P. Knaup,
i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S334–S341 S341

Standardizing terminology in pediatric oncology—the [13] L. Friedman, C. Furberg, D. DeMets, Fundamentals of Clinical
basic data set (in German), Klin. Padiatr. 214 (2002) Trials, PSG Publishing Company, Littleton, 1985.
212–217. [14] U.S. Department o f Health and Human Services—Food and
[6] M.R. Flynn, C. Barrett, F.G. Cosio, A.K. Gitt, L. Wallentin, P. Drug Administration, Guidance for Industry. Computerized
Kearney, M. Lonergan, E. Shelley, M.L. Simoons, The systems used in clinical trials, 1999.
Cardiology Audit and Registration Data Standards (CARDS), [15] F. Leiner, W. Gaus, R. Haux, P. Knaup-Gregori, Medical Data
European data standards for clinical cardiology practice, Eur. Management—A Practical Guide, Springer, New York, 2003.
Heart J. 26 (2005) 308–313. [16] B. Trombert-Paviot, J.M. Rodrigues, J.E. Rogers, R. Baud, E.
[7] Standards Australia IT-014-02, Guideline for Data van der Haring, A.M. Rassinoux, V. Abrial, L. Clavel, H. Idir,
Development in Health (Draft for comment), 2006. GALEN: a third generation terminology tool to support a
[8] J.J. Cimino, Desiderata for controlled medical vocabularies in multipurpose national coding system for surgical
the twenty-first century, Methods Inf. Med. 37 (1998) procedures, Int. J. Med. Inform. 58/59 (2000) 71–85.
394–403. [17] V. Mludek, P. Knaup, S. Garde, A. Merzweiler, R. Weber, T.
[9] A. Merzweiler, P. Knaup, R. Weber, H. Ehlerding, R. Haux, T. Wetter, Formale Definition von Integritätsbedingungen für
Wiedemann, Recording clinical data—from a general set of den Basisdatensatz der Pädiatrischen Onkologie (Formal
record items to case report forms (CRF) for clinics, in: V. Definition of Integrity Constraints for a Basic Data Set for
Patel, R. Rogers, R. Haux (Eds.), Medinfo 2001. Proceedings of Pediatric Oncology), Informatik, Biometrie und
the 10th World Congress on Medical Informatics, IOS, Epidemiologie in Medizin und Biologie 33 (2/3) (2002) 338.
Amsterdam, 2001, pp. 653–657. [18] S. Garde, E.J.S. Hovenga, J. Gränz, S. Foozonkhah, S. Heard,
[10] P. Knaup, S. Garde, A. Merzweiler, N. Graf, F. Schilling, R. Towards a repository for managing archetypes for electronic
Weber, R. Haux, Towards shared patient records: an health records. In: J. Westbrook, J. Callen, G. Margelis (Eds.),
architecture for using routine data for nationwide research, Bridging the Digital Divide: Clinician, Consumer and
Int. J. Med. Inform. 75 (2006) 191–200. Computer, Health Informatics Society of Australia (HISA).
[11] T. Beale, A. Goodchild, S. Heard, EHR Design Principles, Paper 013. HIC 2006: 14th Australian Health Informatics
openEHR Foundation, 2001. Conference, Sydney, 20–22 August, 2006.
[12] A.L. Rector, W.A. Nowlan, S. Kay, Foundations for an [19] P. Schloeffel, openEHR archetypes: Putting the clinician back
electronic medical record, Methods Inf. Med. 30 (1991) in the driver’s seat, HIC 2003 (Health Informatics Conference
179–186. Australia), Sydney, 2003.