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
more user-friendly and comprehensive data capture. On the
other hand, we believe that ubiquitous computing requires
ubiquitous availability of information and knowledge as a pre-
requisite.
A considerable amount of work has already been under-
taken by the Health Informatics community along the
path to ubiquitous use of patient information and health
knowledge: National and international standards develop-
ments, connectivity using HL7, document exchange using
HL7 CDA [2], comprehensive specifications for Electronic
Health Records like the recent release of openEHR Version
1.0 (http://www.openEHR.org), the development of special-
ist clinical data sets (CDSs) on a national and sometimes
international level. Also the detailed clinical models (DCM,
http://detailedclinicalmodels.org) initiative is worth mention-
ing internationally. Creating CDSs is a tedious task and the
bigger the scope or the applicable region is, the bigger is the
effort [3]. To name but a few, in Germany, Merzweiler et al.
defined a basic data set for pediatric oncology [4,5], Flynn et
al. recently defined the European data standard for clinical car-
diology practice [6], and the international Nursing Minimum
Data Set (i-NMDS, http://www.inmds.org) is currently under
development.
With the release of openEHR Version 1.0 there is a com-
mon information and knowledge model for Electronic Health
Records available that can solve some of these still pre-
vailing problems of insufficiently ubiquitous information
and knowledge in the health sector by improving semantic
interoperability and providing a common basis for decision
support, data mining, etc.
To investigate our hypothesis that ‘expressing clinical data
sets as openEHR clinical content models (archetypes) is feasible
and useful, the aim of this paper is to
• present an approach to develop openEHR archetypes based
on existing CDSs (feasibility);
• outline typical problems that arise when developing CDSs;
• analyse whether openEHR archetypes can be used to over-
come some of the problems of CDS development (usefulness).
Please note that nothing in this paper is intended to imply
that the concept of CDSs is unimportant or needs to be
replaced. Rather, it is about showing an alternative way to
structure and organise CDSs.
2. Material and methods
2.1. Analysis of clinical data sets
The results in this paper stem from the analysis of var-
ious existing CDSs and typical development processes for
CDSs with a special focus on German, other European and
Australian data sets. Further, we analysed the openEHR and
archetypes approach with regard to their suitability for the
development of CDSs. For this, we investigated existing liter-
ature for criteria for ‘good’ CDSs. While we found very little
published literature dealing with this exact problem, some
not yet published works are currently circulated as drafts,
for example the principles (e.g. system-independency, use of
S335
existing standards) for good data development in Ref. [7], cir-
culated until January 2007 for public comment and now being
revised based on this feedback. Also, desiderata for terminolo-
gies (e.g. ICD) have been postulated by Cimino [8]. These are
not applicable as such to CDSs or archetypes, but still helped
us to identify some common problems of CDSs. In addition,
our work on defining CDSs and implementing them in applica-
tion systems with structured data entry is of importance here:
• standardizing terminology in Paediatric Oncology: the basic
data set [5];
• recording clinical data: from a general set of record items to
case report forms (CRF) for clinics [9];
• an architecture for using routine data for nationwide
research [10];
• TERMTrial: terminology-based documentation systems for
cooperative clinical trials [4].
Most importantly, we used the process described later in
this paper for the development of archetypes based on existing
CDSs to develop archetypes based on the German Basic Data
Set for Paediatric Oncology.
2.2. The openEHR and archetypes approach
The openEHR approach (http://www.openEHR.org) is defined in
comprehensive specifications originally based on the results
of the European Union’s GEHR-Project, used and refined in a
series of further European and Australian projects. Its design
principles are described by Beale et al. [11]. The main char-
acteristic of openEHR is a two level modelling approach for
EHRs. The first level of this approach is the reference model
which is reduced to a relatively small set of classes to sup-
port the medico-legal requirements and record management
functions. The second level involves the openEHR archetype
methodology representing all the clinical knowledge that
rather than being hard-coded in databases and applications
is defined in archetypes. Each archetype represents one clini-
cal concept by constraining instances of the openEHR reference
model. By using two levels – a reference model and archetypes
– openEHR separates technical concerns from clinical data col-
lection. Archetypes themselves are terminology-neutral, but
can link to external terminologies like SNOMED CT.
3. Results
The Clinical Data Set for Paediatric Oncology in Germany
consists of 260 items. Using the process described in this
paper, we transferred the CDS into a total of 46 openEHR
archetypes. Before we present the problems found with this
and other CDSs and discuss possible solutions using the
openEHR archetype methodology, we present an overview of
the process used to transform CDSs into openEHR archetypes.
3.1. An overview of the process to transform CDSs
into archetypes
In order to explore the feasibility of our approach to express
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
this section.
After proper analysis of the existing CDS, initially all appro-
priate high-level archetype concepts present in the CDS, for
example ‘blood pressure measurement’ or ‘diagnosis’ should
be defined. It is possible to use an Archetype Editor at
this stage already, but not necessary. Of good value is the
use of a mindmap laying out all the archetype concepts.1
Thus, overlapping concepts can be identified and appro-
priately dealt with. At this stage, we also decide on the
use of existing demographics archetypes. These should be
identical or specialized from existing openEHR demographics
archetypes.
After all high-level archetype concepts are defined—and
before actually designing the archetypes from scratch using
an Archetype Editor, it is necessary to check for existing ref-
erence archetypes. Archetypes already published for example
on the openEHR website have undergone extensive peer-review
already and thus are a valuable source for any archetype
developer. The Archetype Finder developed by the first author
of this paper is available at http://www.archetypes.com.au
and helps identifying relevant existing archetypes by use of
an OWL ontology [3]. The use of the Archetype Finder by
archetype developers avoids that already defined archetypes
are reinvented thus saving effort and also fostering seman-
tic interoperability by avoiding overlapping and incompatible
concepts. If an archetype is only available in a foreign language
it can be translated. If no fitting archetypes are discovered,
an appropriate structure for the new archetype has to be
selected: This includes the decision if a clinical concept
is an
• Observation (i.e. objective data the health professional
observes from the patient, e.g. a blood pressure measure-
ment);
• Evaluation (i.e. opinions, including assessments, goals and
plans by the health professional usually based on observa-
tions, e.g. a diagnosis);
• Instruction (i.e. the health professional instructs an ‘agent’,
e.g. a medication order);
• Action (i.e. an action on the patient, e.g. a medication action,
which includes among others the dispensing and adminis-
tration of the medication. Actions are often but not always
based on an instruction).2
Using an Archetype Editor, the archetype is then defined (or
specialised respectively) by adding data items of the appropri-
ate type, binding data items to internal codes or terminologies
like SNOMED CT. For certain archetypes, History events are
defined to express the points of time when the data is sup-
posed to be captured. State (essential for the interpretation of
a measurement) and Protocol information (e.g., what kind of
1
Cp. the Mindmap of existing archetypes at http://svn.openehr.
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
efforts, including among others the model of Rector et al. [12].
device was used) can be added to the archetype. Broad input
from clinicians should be sought during this phase (however
if the data set is already well defined less input is necessary).
Often CDSs do not define the exact points of time when data
documentation is required. If the data set does not provide all
the necessary information, this information has to be gath-
ered or agreed on by the responsible domain experts. Finally,
section and composition archetypes are defined for ordering
the clinical contexts into a fitting structure.
Once an archetype is defined, it should be submitted to the
Clinical Review Board of openEHR as for semantically interop-
erable systems, archetype development should be coordinated
to avoid incompatible archetypes for the same concept by
systematic Domain Knowledge Governance. Thus, it can be
ensured that no overlapping concepts or otherwise incom-
patible archetypes are used for different health disciplines,
etc.
The resulting archetypes will look considerably different
than the original CDS. This is because archetypes define
a comprehensive clinical concept, whereas CDS are data-
oriented.
3.2. Developed archetypes
An overview of some the developed observation, evaluation,
instruction and action archetypes is given in Fig. 1. In addition,
we developed SECTION archetypes (roughly equivalent to Doc-
ument Headings), and structural archetypes (e.g. ITEM TREE
archetypes), which can be reused in various other archetypes,
and ADMIN ENTRY archetypes, which are used for adminis-
trative purposes.
Fig. 2 presents one concrete example for the conversion of
the representation of toxicities in existing CDS to one openEHR
archetype. Although both CDS and archetype are in German, it
is evident from this figure that we chose to represent toxicities
differently in the resulting archetype: The original CDS uses
coding tables to define the various toxicities like ‘vomiting’
(German: “Erbrechen”) and the available value set (here: num-
ber of episodes within 24 h coded to severities 0–4) whereas
archetypes can explicitly represent these toxicities and define
appropriate value sets. (NB: These value sets could also be
derived from or linked to a terminology query, e.g. to SNOMED
CT.) (Fig. 3).
3.3. Problems with current CDSs
Notwithstanding the importance of the work on CDSs,
there are several problems that remain unsolved even if
all clinical data were formally expressed in standardized
CDSs but not following a common methodology: during
our work on CDSs, implementing them in application sys-
tems with structured data entry and transferring them to
openEHR archetypes, we observed the problems outlined in
Table 1.
3.4. The potential of openEHR to overcome the
The openEHR approach and archetypes address the problems
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
The ‘good’ modelling of clinical content is one of the most
important tasks we face today in Health Informatics. As such,
the development of CDSs with an increasingly international
scope is of vital importance. We believe that the presented
results support our hypothesis that expressing CDSs as
openEHR archetypes is (a) feasible and (b) useful as it helps to
better structure CDS. To overcome some of the shortcomings
of current CDSs (like conflicting basic data types) a uni-
form model like the openEHR model is helpful. To overcome
other shortcomings like overlapping, inconsistent concepts,
systematic Domain Knowledge Governance is required in
addition. As each archetype forms a clearly defined semantic
unit that expresses one clinical concept, archetypes enable
knowledge to be governed within clearly defined boundaries.
Some of the described problems of CDS development can
be overcome by other means, e.g. by the development of a
Guide to Data Development [7]. Archetypes enable clinicians
to focus on the clinical content, not on technical details like
we encountered during the development of our archetypes
was the insufficient support for hierarchical archetypes,
which could flexibly reuse other existing archetypes as a
part of their own. While the openEHR specifications allow
this, no tooling support was available to support this. In
discussion with other archetype developers, we found that
this is a common problem which needs to be addressed and
the most recent version of the Archetype Editor (Release 1
candidate, Build 1231 available from http://oceaninformatics.
biz/archetype editor/ArchetypeEditor download.html) now
includes so-called Cluster and Element archetypes to facil-
itate these hierarchies. With regard to consistently binding
archetypes to a user-nominated terminology like SNOMED
CT, a problem increasingly recognised among archetype
developers is that the terminology itself has to be internally
consistent and complete. Also binding archetypes to a termi-
nology that supports post-coordination like SNOMED-CT can
cause some challenges.
With regard to the comparison of CDS and archetypes, a
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
Table 1 – A summary of problems identified with clinical data sets
Problem 1: Basic Data Types
Problem 2: Presentation Formats
Problem 3: Design principles
Problem 4: Time of data capture
Problem 5: Interpretation of the data
Problem 6: Integrity constraints
Problem 7: Replication of domain knowledge
Problem 8: Multi-language support
Problem 9: Non-integrated specialist applications
set, whereas a CDS would usually serve as a minimum basic
data set. While this statement is not inherently true of the
two approaches, it describes the way the two approaches are
currently usually used. The way we currently use these two
approaches is to a large part due to the direction that on the
one hand existing CDSs and CDS design tools and on the other
hand existing archetypes, archetype principles and archetype
design tools provide.
Thus, reporting based on defined CDSs can be seen as one
feature of an archetype-based system. Although we cannot
prove it yet, we believe that openEHR archetypes are more
expressive than any kind of conventional structure for CDSs.
Because of this and the described advantages of archetypes,
we believe that openEHR archetypes are an adequate means
for developing and structuring new CDSs. As shown in Sec-
tion 3.1, it is also possible to transform existing CDSs into
archetypes. Generally speaking, the better the quality of the
CDS adheres to good data development guidelines, the less
effort is required to transform it into a collection of archetypes.
We note that this transformation is not an automatic process,
but requires thinking and judgment on a conceptual level,
and additional clinical input during the actual development
of these archetypes. Also, archetypes do not solve the prob-
lem that domain experts will need to agree on the appropriate
S339
CDSs use different kinds of basic data types. This imposes various kinds
of challenges when exchanging or migrating existing data
CDSs use different kinds of presentation formats. This is confusing for
clinicians and technicians alike
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
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
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
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]
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.
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]
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
representation for a clinical concept. However, as archetypes
separate informatics concerns and clinical content discus-
sion, in our experience from archetype workshops recently
conducted for clinicians in Melbourne, Sydney and Brisbane,
archetypes help clinicians to focus on the discussion of clinical
content, serve as a great ‘change agent’ and are a good means
to involve clinicians in the ‘boring’ modelling of clinical con-
tent. Thus, by using archetypes to develop new CDSs, a more
streamlined development process can be adopted. Some train-
ing for clinicians serving as lead developers for archetypes is
necessary to understand the basic concepts of archetypes [18].
More generally, the openEHR two-level modelling and
archetype methodology cannot overcome all of the barri-
ers to ubiquitous computing (cp. [19]). For example, easier,
higher quality, more convenient and faster data capture at
the point of care (or in fact anywhere) as envisioned by ubiq-
uitous computing (e.g. wearable devices, and combination of
technologies such as voice or handwriting recognition) are
beyond the scope of this approach. The openEHR approach
can however provide the common basis for ubiquitous pres-
ence of meaningful and computer-processable knowledge and
information and thus contribute to the usability of clini-
cal systems, improve data quality, and improve semantic
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-
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
openEHR approach cannot overcome all barriers to Ubiquitous
Computing. Therefore, existing CDSs should in our opinion
be transferred to archetypes and new data sets directly be
defined using archetypes; this will foster semantic interop-
erability, support ubiquitous computing and help to develop
archetypes that are arguably of better quality than the original
CDS.
Acknowledgements
The authors would like to thank Dr. Sam Heard, Dr. Carola
Hullin, Dr. Heather Leslie and Thomas Beale for valuable dis-
references
[1] M. Scheffler, E. Hirt, Wearable devices for telemedicine
applications, J. Telemed. Telecare 11 (Suppl. 1) (2005) 11–14.
[2] R.H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F.M. Behlen, P.V.
Biron, A. Shabo Shvo, HL7 Clinical Document Architecture,
Release 2, J. Am. Med. Inform. Assoc. 13 (2006) 30–39.
[3] S. Garde, P. Knaup, E. Hovenga, S. Heard, Towards Semantic
Interoperability for Electronic Health Records: Domain
Knowledge Governance for openEHR Archetypes, Methods
Inf. Med., 2006, in press.
[4] A. Merzweiler, R. Weber, S. Garde, R. Haux, P. Knaup-Gregori,
TERMTrial—Terminology-based documentation systems for
cooperative clinical trials, Comput. Methods Programs
Biomed. 78 (2005) 11–24.
[5] A. Merzweiler, H. Ehlerding, U. Creutzig, N. Graf, B. Hero, P.
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
Standardizing terminology in pediatric oncology—the
basic data set (in German), Klin. Padiatr. 214 (2002)
212–217.
[6] M.R. Flynn, C. Barrett, F.G. Cosio, A.K. Gitt, L. Wallentin, P.
Kearney, M. Lonergan, E. Shelley, M.L. Simoons, The
Cardiology Audit and Registration Data Standards (CARDS),
European data standards for clinical cardiology practice, Eur.
Heart J. 26 (2005) 308–313.
[7] Standards Australia IT-014-02, Guideline for Data
Development in Health (Draft for comment), 2006.
[8] J.J. Cimino, Desiderata for controlled medical vocabularies in
the twenty-first century, Methods Inf. Med. 37 (1998)
394–403.
[9] A. Merzweiler, P. Knaup, R. Weber, H. Ehlerding, R. Haux, T.
Wiedemann, Recording clinical data—from a general set of
record items to case report forms (CRF) for clinics, in: V.
Patel, R. Rogers, R. Haux (Eds.), Medinfo 2001. Proceedings of
the 10th World Congress on Medical Informatics, IOS,
Amsterdam, 2001, pp. 653–657.
[10] P. Knaup, S. Garde, A. Merzweiler, N. Graf, F. Schilling, R.
Weber, R. Haux, Towards shared patient records: an
architecture for using routine data for nationwide research,
Int. J. Med. Inform. 75 (2006) 191–200.
[11] T. Beale, A. Goodchild, S. Heard, EHR Design Principles,
openEHR Foundation, 2001.
[12] A.L. Rector, W.A. Nowlan, S. Kay, Foundations for an
electronic medical record, Methods Inf. Med. 30 (1991)
179–186.
S341
[13] L. Friedman, C. Furberg, D. DeMets, Fundamentals of Clinical
Trials, PSG Publishing Company, Littleton, 1985.
[14] U.S. Department o f Health and Human Services—Food and
Drug Administration, Guidance for Industry. Computerized
systems used in clinical trials, 1999.
[15] F. Leiner, W. Gaus, R. Haux, P. Knaup-Gregori, Medical Data
Management—A Practical Guide, Springer, New York, 2003.
[16] B. Trombert-Paviot, J.M. Rodrigues, J.E. Rogers, R. Baud, E.
van der Haring, A.M. Rassinoux, V. Abrial, L. Clavel, H. Idir,
GALEN: a third generation terminology tool to support a
multipurpose national coding system for surgical
procedures, Int. J. Med. Inform. 58/59 (2000) 71–85.
[17] V. Mludek, P. Knaup, S. Garde, A. Merzweiler, R. Weber, T.
Wetter, Formale Definition von Integritätsbedingungen für
den Basisdatensatz der Pädiatrischen Onkologie (Formal
Definition of Integrity Constraints for a Basic Data Set for
Pediatric Oncology), Informatik, Biometrie und
Epidemiologie in Medizin und Biologie 33 (2/3) (2002) 338.
[18] S. Garde, E.J.S. Hovenga, J. Gränz, S. Foozonkhah, S. Heard,
Towards a repository for managing archetypes for electronic
health records. In: J. Westbrook, J. Callen, G. Margelis (Eds.),
Bridging the Digital Divide: Clinician, Consumer and
Computer, Health Informatics Society of Australia (HISA).
Paper 013. HIC 2006: 14th Australian Health Informatics
Conference, Sydney, 20–22 August, 2006.
[19] P. Schloeffel, openEHR archetypes: Putting the clinician back
in the driver’s seat, HIC 2003 (Health Informatics Conference
Australia), Sydney, 2003.