Tsp

Ja

b

c

a

A

R

R

3

A

K

C

s

o

N

1

1

AngTI

T

1d

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 8 ( 2 0 0 9 ) 521–531

journa l homepage: www. int l .e lsev ierhea l th .com/ journa ls / i jmi

owards a comprehensive electronic patient record toupport an innovative individual care concept forremature infants using the openEHR approach

asmin Bucka,∗, Sebastian Gardeb, Christian D. Kohl c, Petra Knaup-Gregori c

Faculty of Informatics, University of Applied Sciences Heilbronn, Heilbronn, GermanyOcean Informatics, Düsseldorf, GermanyInstitute for Medical Biometry and Informatics, University of Heidelberg, Heidelberg, Germany

r t i c l e i n f o

rticle history:

eceived 31 July 2008

eceived in revised form

March 2009

ccepted 3 March 2009

eywords:

omputerized medical record

ystem

a b s t r a c t

Purpose: This paper introduces the modelling of a prototype neonatology electronic patient

record (EPR) using openEHR archetypes. The EPR is necessary to support the complex com-

munication tasks of the innovative concept of ‘Developmental, Family-Centred, Individual

Care of Premature Infants and Newborns’ established for the Department of Neonatology at

Heidelberg University Hospital.

Methods: The data to be documented was analysed and modelled using the five step openEHR

data modelling approach (odma).

Results: The analysis revealed a total of 1818 items, which could be arranged into 70 clinical

concepts. The items and concepts were then mapped to 132 openEHR archetypes. Fifty-eight

of these archetypes could be reused either directly or via specialisation from the exist-

penEHR archetypes and templates

eonatology

ing openEHR archetypes. A further 67 archetypes were newly developed. To combine and

constrain archetypes for local settings 16 templates were developed.

Conclusion: By using the five step openEHR data modelling approach, semantic interoperabil-

ity, and a reduced need for repeated documentation of the same data can be realised. This

is of major importance within the hospital as well as for trans-institutional data exchange.

. Introduction

.1. Subject and motivation

t Heidelberg University Hospital for pediatric and juve-

ile medicine an innovative concept for supporting optimalrowth of premature infants is currently being established.he concept is called the ‘Developmental, Family-Centred,

ndividual Care of Premature Infants and Newborns’-model

∗ Corresponding author at: University of Applied Sciences Heilbronn, Mel.: +49 7131 504 236.

E-mail address: buck@hs-heilbronn.de (J. Buck).386-5056/$ – see front matter © 2009 Elsevier Ireland Ltd. All rights resoi:10.1016/j.ijmedinf.2009.03.001

© 2009 Elsevier Ireland Ltd. All rights reserved.

(German term: Entwicklungsfördernde, familienzentrierte,individuelle Betreuung Früh- und Neugeborener – EfiB). TheEfiB-model intends to provide an environment that optimallymeets the needs of premature infants [1,2]. In order to imple-ment this highly interdisciplinary care concept, an optimal

ax-Planck-Str. 39, 74081 Heilbronn, Germany.

communication between all involved persons is necessary.The relevant information has to be made available at the righttime and place and in an adequate form to all persons involved[3,4].

erved.

i c a l

522 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

1.2. Problem

To fulfil these communication tasks, electronic patient records(EPRs) and other systems for documentation purposes areused. At the Department for Neonatology at Heidelberg Uni-versity Hospital, three different medical record systems arecurrently used: two electronic systems and one paper-basedsystem.

IS-H*med, one of the electronic systems, is part of thehospital information system which is used throughout theentire Heidelberg University Hospital. The system is also usedfor transmitting patient data, findings, and reimbursementdata.

The other electronic system, called NeoDat, is used exclu-sively by the Department for Neonatology. Specific data aboutnewborns is stored in order to fulfil the legal obligation ofdelivering data to the European Neonatal Network and to theGerman Perinatal Register, with the intention of maintainingnational quality assurance.

A large amount of data to be entered in both electronic sys-tems. However, the lack of communication interfaces betweenthe electronic systems requires repeated documentation ofdata.

Furthermore, there is a paper-based patient record system.This record system is used by physicians to document theirorders. Nurses use it to record their observations.

When the paper-based record becomes too large, olderdocuments are transferred to a folder in the nurses’ room(there exists a separate folder for every patient of theward).

When a patient leaves the hospital, all paper-based docu-ments are archived in an additional folder. However, when apatient returns for outpatient care a few documents are usedagain. These documents are archived in a separate outpatient-folder and kept in the clinic [1].

This heterogeneous patient record system, whichincludes a variety of media and repeated documenta-tion, complicates the communication demanded by the EfiB-model.

1.3. Objectives

A comprehensive electronic patient record to support thecommunication tasks for the successful implementation ofthe EfiB-model, and to store and use the extracted infor-mation effectively is necessary [5]. A prototype for thiselectronic patient record was developed by using the openEHRapproach. With the openEHR approach, data can be stored,structured, and reused effectively. Repeated documentationcan be avoided and the required communication can be sup-ported.

The aim of this paper is to:

- briefly introduce the main characteristics of the EfiB-model;

- present the results of modelling the electronic patient

record for the Department of Neonatology at Heidelberg Uni-versity Hospital to support EfiB, using openEHR archetypesand templates;

- discuss the approach.

i n f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531

2. Background

2.1. EfiB-model

To create an environment which meets the needs of prematureinfants, the ‘Developmental, Family-Centred, Individual Careof Premature Infants and Newborns’-model (EfiB-model) wasdeveloped at Heidelberg University Hospital. This approach isstructured into modules.

The EfiB-model is based on the ‘individualised newborndevelopmental care and assessment programme’ (NIDCAP)which is meant to optimize therapy, care and the environmentto the needs of the children [6,7].

However, it is also based on ‘developmental care’. As such,it is required to correspond to the behaviour of the neonate[7,8].

These two core components are complemented by the fol-lowing modules:

- standardised pain therapy during elective interventions,- light reduction,- noise reduction,- physical therapy,- coordination of medical and custodial concerns,- encouragement of the parent–child relationship and the

parents’ competence,- admission management,- discharge management.

Different social ward rounds complete the concept:

- psychological attendance and counselling for parents,- psycho-social attendance and guidance for parents,- medical family counselling and interactive guidance for the

feeding of the child [1,9].

As many different occupational groups are involved in thecare of an infant a transparent documentation is particularlyimportant.

The intention of the EfiB-model is to empower the parentsto care for their child independently and competently afterdischarge.

2.2. openEHR

With the openEHR approach patient data can be structured,stored, managed, and exchanged in a safe and reliable waybetween different healthcare providers and other interestgroups.

The basic idea of this approach is to separate the definitionof the concepts of a domain from the concrete software andthe database and to relocate them in independently adminis-tered, standardised libraries – the archetypes [10].

Therefore, archetypes define the content of electronichealth records (EHR). In doing so each archetype is a thor-

ough, distinct, and clinically meaningful concept [11]. Thearchetypes’ data have the same meaning in every EHR andeverywhere in the EHR. Thus, they can always be safely inter-preted, and enable interoperability on the level of knowledge.

a l i n

Tlsd

c

-

-

-

-

-

-

d

Ap

1

2

3

4

d

-

--

-

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

o allow data exchange between systems based on differentanguages, archetypes are language independent models. Thetructures provided by archetypes accommodate terms andescriptions in various languages.

Archetypes can be divided into classes according to theirontent:

composition-archetypes: This thematic archetypes correspondto documents.section-archetypes: This organisational archetypes corre-spond to document headings.entry: This descriptive archetypes are divided into the cate-gories- observation-archetypes (e.g. ‘blood pressure’),- evaluation-archetypes (e.g. ‘adverse reaction’),- instruction-archetypes (e.g. ‘medication order’),- action-archetypes (e.g. ‘procedure’).structure-archetypes: Archetypes to model a structure (e.g.a tree or list) of items and reuse this structure in otherarchetypes.cluster-archtypes: Archetypes to model a cluster of items andto embed this cluster in other archetypes.element-archetypes: Archetypes to model a single item withthe intention of reuse.

In addition, demographic-archetypes are used to modelemographic data.

The formal language for expressing archetypes is therchetype Definition Language (ADL). The syntax can bearsed, and describes an archetype in four sections:

. Identification: Each archetype has a unique identifyingname. The ‘concept’ statement connects the archetype tothe described concept.

. Description: This section contains metadata such as the pur-pose, use, or author of the archetype.

. Definition: The allowed object structures and constrains aredefined by instantiate classes of the reference model anddetermine their hierarchical arrangement, value ranges,and occurrence.

. Ontology: The semantic of the archetype is added in this sec-tion. Thereto the items are lodged with textual descriptionsand optionally term bindings [12].

Based on these archetypes, templates for local use can beefined. Templates are necessary to:

combine items from different archetypes for several pur-poses, for example, to present a screen form for data entryto a user or compose the data which are integrated into aphysician’s report. This type of template is comparable tothe idea of structuring CDA documents [13,14],allocate default values to items,link archetypes to clinical terminologies such as SNOMED

CT or,otherwise constrain archetypes, for example, deleteoptional items of the archetype that are not required in thelocal context.

f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531 523

Templates provide the means of reusing archetypes in alocal context without ‘breaking’ the archetype. Therefore, thearchetypes can be reused in different settings and countries[15,16].

openEHR is an open community. Specifications of theapproach are available on the Internet, for example,www.openehr.org (openEHR Architecture Overview [15] andother openEHR specifications).

To further support the idea of the multiple use ofarchetypes, and therefore of achieving semantic interoperabil-ity, openEHR also provides a central library of archetypes (seehttp://www.openehr.org/clinicalmodels/archetypes.html).These are free to use, readily accessible, and can be adaptedto local circumstances.

3. Methods

To model data to be documented with openEHR archetypes,the five step openEHR data modelling approach (odma) wasdeveloped:

Step 1: Determine all items.For modelling archetypes, all items to be documented shouldbe known. Documented item categories and their valueranges have to be ascertained from existing electronic andpaper-based documentation systems.Step 2: Merge items to concepts.Next, the items have to be combined into coherent and clin-ically meaningful concepts. Concepts and their items arestructured hierarchically and the structure should be visual-ized, for example, in a mind map. During this process, itemsand structures that are repeated are identified and multiplemodelling of items needed in several archetypes can hencebe avoided.The example concept ‘feeding’ can be used to demonstratehow the development of hierarchical structures can avoidmultiple modelling of the same data. The items of the con-cept ‘feeding’ can be modelled within a cluster archetype.Next, they can be included in an instruction-archetype toplan the feeding as well as in an action-archetype to doc-ument that the newborn was fed.Step 3: Map the derived concepts to existing archetypes.To ensure maximum interoperability, already existingarchetypes are taken into account [17,18] in Step 3. Thearchetype-finder (www.archetypes.com.au) can help detect-ing archetypes that model required items or whole concepts.When mapping the derived concepts to archetypes, threecases can be distinguished: (1) If all items of a concept havealready been modelled in an archetype, this archetype can bereused. As archetypes should be maximum data sets, most ofthe reused archetypes will contain more items than needed.These items can be excluded from the documentation viatemplates. (2) When particular items are missing in an exist-ing archetype this archetype can be specialised and extendedby adding the missing items. An example for this case is

the archetype ‘patient’ as a specialisation of the archetype‘person’.According to the intention of archetypes being maximumdata sets, in principle no items of a modelled clinical concept

i c a l

524 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

should be missing. However, openEHR archetypes are stillunder development and will continue to be, because medicalknowledge increases. Items that are lacking can occur andshould be reported, discussed, and where appropriate addedto the basis archetype via the openEHR knowledge repository(http://www.openehr.org/knowledge/).Since most of the existing archetypes are in English, theymust be translated for use in other languages. (3) There existsno appropriate archetype for modelling the concepts. In thiscase a new archetype has to be modelled (cf. Step 4).

Step 4: Develop archetypes.If a reused archetype needs to be specialised or an adequatearchetype for a concept does not exist, a new archetype ismodelled.

Fig. 1 – The items collected from the neonatal record were summConcepts can be grouped into abstract categories (printed plain)instruction’ (highlighted in the ellipse) is regarded in further det

i n f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531

In principle a text editor could be used to define an archetype,if the archetype author uses the syntax of the ADL. Itis more intuitive and comfortable to model archetypeswith a tool like the Archetype Editor or the ADL Workbench(both available from the openEHR website or precompiled athttp://www.oceaninformatics.com).Step 5: Design templates.Templates can be designed to adapt the archetypes to localcircumstances or combine items from different archetypes,as introduced in Section 2.2. Templates can be designed

with any text or XML editor based on the draft openEHRtemplate schema. However, as for the archetypes it is morecomfortable to use a tool like the Template Designer of OceanInformatics.

arised and structured into 70 concepts (printed bold).to better visualize the structure. The concept ‘parentail in Fig. 2.

a l i n

4

TtoNt

Ftisl

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

. Results

he data of electronic or paper-based documentation sys-em can be represented with archetypes by means of thedma approach. odma was utilized to represent the data of theeonatology Department of the Heidelberg University Hospi-

al. The results are:

Results of Step 1:For the comprehensive electronic patient record, 1818 itemssuch as ‘surname’, ‘head circumference’, or ‘body tem-perature’ were systematically collected from the existingneonatology documentation. From the paper-based record,1175 items were taken, 574 items from NeoDat and 69 itemsfrom IS-H*med. In the different systems 155 items wererecorded repeatedly.Results of Step 2:

The items collected in Step 1 were arranged into 70 conceptswhich are illustrated in Fig. 1.As an example, the structuring process of the concept‘parent instructions’ is considered. This concept consists

ig. 2 – Structuring and summarising of the items of the concepthe structure of the items, which represents the current forms ustems, such as ‘bottom hygiene’ or ‘clothing’. It can be recognizeubordinated. To resolve the overlapping, the items were restrucower part of the figure, which shows that for each item in ‘categ

f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531 525

of a list of 32 major items such as ‘bottom hygiene’ or‘temperature control’. For each of the major items thesub-items guidance necessity (yes/no), theory (date/sign), demon-stration (date/sign), supervised accomplishment (date/sign) andautonomous accomplishment (date/sign) are found in the patientrecord. Therefore, the concept ‘parent instruction’ wasrestructured and summarised using the items categories field,guidance type and person (see Fig. 2), so that the sub-itemsdo not occur repeatedly. This simplified the structure, thearchetype modelling, and the template design.Results of Steps 3 and 4:A total of 132 archetypes were reused and developed:- Direct reuse of 40 archetypes: Forty of the adopted

archetypes did not need any adaptation. Examplesfor such archetypes are the observation-archetypes‘body temperature’ or ‘height’.

- Reuse by specialisation into 13 archetypes: Six archetypescould be reused and specialised into altogether 13

archetypes (e.g. ‘insured person’, ‘patient’ and ‘physician’as a specialisation of the archetype ‘person’).

- Reuse of 12 archetypes by extension: Further 12 archetypeswere reused and extended by missing items that belong

‘parent instruction’. The upper part of the figure illustratesed in the neonatology department. There are 32 major

d that for each of the major items the items in the box aretured to a more efficient archetype model. This led to theory field’ the items of ‘guidance type’ can be documented.

526 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 8 ( 2 0 0 9 ) 521–531

Table 1 – List of the directly reused, specialised or extended openEHR clinical and demographic archetypes, ordered byclass.

class Archetype Specialisation

demographic-ADDRESS location address

demographic-PERSON person person-motherperson-patientperson-insurantperson-physician

ENTRY.ACTION intravenous fluid administration intravenous fluid administration-extendedmedication medication-extended

procedure procedure-phototherapyprocedure-retinopathy therapyprocedure-screening

referraltransfusion

CLUSTER delivery of infantdimensionsdimensions-circumferencesymptom symptom-important

COMPOSITION report report-extended

ENTRY.EVALUATION adversealertcheck listcheck list-medicationgoalpregnancy pregnancy-extendedproblemproblem-diagnosis problem-diagnosis-extendedrisk risk-clinical risk index for babies

ENTRY.INSTRUCTION intravenous fluid orderlaboratory requestmedicationnon drug therapyreferraltransfusion

ITEM TREE gas administration gas administration-extendedintravenous fluids intravenous fluid-extendedlaboratory requestmedication medication-extendedmedication-vaccineoxygen

procedure procedure-phototherapyprocedure-retinopathy therapyprocedure-screening

referral

ENTRY.OBSERVATION apgarautopsyblood film blood film-extendedblood gasesblood matchblood pressure blood pressure-extendedbody temperaturebody weight body weight-extendedbody weight-birthchest expansiondimensions

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 8 ( 2 0 0 9 ) 521–531 527

Table 1 – (Continued )

class Archetype Specialisation

heart rateheart rate-pulseheightlaboratorylaboratory-c reactive proteinlaboratory-glucose laboratory-glucose-extendedlaboratory-liver functionlaboratory-urea and electrolytes laboratory-urea and electrolytes-extendedoximetryrespiration

SECTION findings

Fig. 3 – Newly modelled archetypes for the neonatal patient record, arranged according to archetype classes (cf. Section 2.2).

528 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 8 ( 2 0 0 9 ) 521–531

Fig. 4 – An example for a newly developed evaluation-archetype to document the results of an ophthalmic examination.hety

This archetype is a specialisation of the newly modelled arc

to the clinical concept (e.g. extension of the archetype‘laboratory-urea and electrolytes’ by the items ‘calcium’,‘magnesium’ and ‘phosphate’).Hence, altogether 58 of the available openEHR archetypescould be reused, as listed in Table 1.

- Development of 67 new archetypes: The 67 new archetypeshad to be developed to capture the remaining con-cepts not yet modelled by openEHR archetypes. Fig. 3presents an overview of these archetypes. Fig. 4 presentsas an example the html-view of the newly modelledevaluation-archetype ‘examination-ophthalmic’, which isa specialisation of the also newly modelled archetype‘examination’.

The archetypes were specialised and developed by using theArchetype Editor and the ADL Workbench.Results of Step 5:On the basis of the 132 archetypes, 16 templates havebeen developed with the Template Designer of Ocean Infor-

matics: To constrain archetypes for local settings and toallocate default values, seven templates such as ‘pregnancy’and ‘weight’ were developed. In order to compile datafrom different archetypes, a further nine templates such

pe ‘examination’.

as ‘neonatal survey’ and ‘relocation record’ were also devel-oped.

5. Discussion

Current publications on the openEHR approach focus on thefoundation and approach itself [19], on the implementa-tion of the specification [20], on the comparison with otherapproaches [21–23], on standard development (for example,as a national resource [24] or as clinical data sets [25]), and onsupporting tools (for example, for validation [26] or visualisa-tion [27,28]).

Nevertheless, the practical application of openEHR is not yetwidely reported.

In the study openEHR was not applied for modelling theo-retical concepts of a domain, rather it was applied to modelclinical information which is used for supporting patient care.

In order to establish if the openEHR approach is suitable forthis, a feasibility study was performed. odma was developedas a process model for applying archetype modelling on anextensive set of items.

a l i n

5

Thoaobii

btw

raaarbDtp

amb

5

omrTcisadow

mf

eiqcTr

fawNtcs

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

.1. Discussion of the results

he modelled archetypes and templates provide a compre-ensive basis for EPR-implementation in neonatology. Basedn openEHR archetypes for the Department of Neonatology,comprehensive electronic patient record was drafted. In

rder to build a running system, additional components wille needed such as a database, a query language, and a user

nterface. To avoid repeated documentation the EPR should bentegrated in the existing clinical information system.

The results can now be used to either develop from theeginning an own openEHR based electronic patient record, oro specify detailed requirements for an already existing soft-are on the market.

The resulting archetypes can be made available by refer-ing to openEHR. The translations of the 58 reused archetypesre already available at http://svn.openehr.org/knowledge/rchetypes/dev/index.html. However, the newly modelledrchetypes are not comprehensive and general enough to rep-esent the maximum basic data set for the whole community,ecause they are tailored to the needs of the Neonatologyepartment of Heidelberg University Hospital. Nonetheless,

hey can be used to verify if other neonatology archetypesrovided in the openEHR archetype library are complete.

In addition, it is important to note that the newly modelledrchetypes which are developed for a non-English environ-ent must be translated into English before they can be fed

ack to openEHR.

.2. Discussion of the method odma

dma was developed as a process model for applying archetypeodelling on an extensive set of items. Its applicability in a

eal clinical context with an item list of 1818 items was proved.he major advantages of odma are that overlapping itemsan be identified, and repeated modelling of items neededn several archetypes can be avoided. For this, it is crucial totructure the items appropriately before archetype modellings described in Step 2. Overlapping concepts can be identifieduring structuring of the items. This task is beyond the scopef the openEHR approach. Therefore, a process model like odmaas necessary.

Overlapping occurs, for example, when in clinical docu-entation the same data have to be recorded in different

orms.The structuring of the items and the search for items in

xisting archetypes is rather time-consuming and challeng-ng. The quality of the archetypes depends strongly on theuality of the structuring process. Unfortunately, there areurrently no application systems which support this process.he degree of the semantic interoperability that could beeached depends strongly on the reuse of archetypes.

In order to enable semantic interoperability, the openEHRoundation enables archetypes to be freely reused by variouspplication systems. The number of the available archetypes,hich could be used and/or adapted for the Department of

eonatology, was comparatively high at 50%. In this study

he reuse of archetypes saved modelling effort. However, theomparison of required and already existing items and thepecialisation or extension of archetypes by expanding pre-

f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531 529

determined structures and translating the archetypes werevery time-consuming. The strengths of the openEHR approach,including interoperability, flexibility, and the possibility toavoid repeated documentation, justified the effort.

Automation of searching and mapping would save mod-elling effort, and ease drafting of an EPR. This is especially thecase with regard to the trend of a growing archetype libraryand therewith the expansion of the effort of performing Step 3of odma. The need to support this issue has been recognized byopenEHR. As such, an extensive ontology has been establishedfor classifying and retrieving archetypes as well as searchingfor all items in all archetypes.

Another benefit of odma is that all items from thepaper-based documentation can be exactly recovered in thearchetypes. By using templates, electronic forms can be builtusing the same structure as the paper forms the hospital staffis already familiar with.

In the process model two cases are not covered. Firstly,no step was provided for extending existing archetypes.Archetypes should be maximum data sets. Therefore, thereshould not be an item missing. This is an ideal situation, andin reality missing items will occur. Nevertheless, odma doesnot provide a procedure for this case because the openEHRknowledge repository should be used to enable semantic inter-operability. Secondly, the case that the items of a certainconcept might be distributed among two or more archetypesis ignored. If this case occurs, the respective concept shouldbe split into two or more concepts and can be combined withother items.

5.3. Lessons learnt about openEHR

All collected items from the Department of Neonatologycan be modelled into archetypes via the openEHR approach.Therefore, openEHR is regarded as suitable for modelling com-prehensive item lists.

Using odma, a deeper insight into the benefit and the limi-tations of the archetype approach was gained.

A major advantage is the separation of technical anddomain aspects. It proved most helpful that the openEHRapproach assumes clinical concepts to change over time.Therefore, it is possible to adapt and expand archetypes atseveral stages of a project.

As it is extensive and needs much professional knowledgeto model high quality archetypes, a web-based knowl-edge repository for openEHR knowledge resources such asarchetypes is currently under development. The repositoryaims to establish more governance of archetypes, as well asto collaborative manage, develop, discuss, improve, and pub-lish archetypes. In this way it also could be reported whensingle items which are a part of a clinical concept are missingin an already existing archetype [29,30].

The openEHR reference model contains items to documentpoints in time. This is not obvious when modelling with theArchetype Editor, and can lead to misunderstandings becausethe user does not directly see any possibility to document

dates.

As the tools to model archetypes are still under develop-ment, such shortcomings can be expected to be eliminated.At the time of the template modelling not all functions of

i c a l

r

530 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

the Template Designer were completely implemented. Hence,the templates for the Department of Neonatology are not yetcomplete.

5.4. Comparison to other approaches

The openEHR approach was chosen to design the electronicpatient record for the Department of Neonatology at the Hei-delberg University Hospital because there is a large collectionof open source tools in different programming languages, ref-erence implementations of the openEHR specification, and amultitude of archetypes. Furthermore openEHR archetypes areconsistent with EN 13606, but also more detailed.

To the best knowledge of the authors, other approaches tosystematically model openEHR archetypes and templates forcomprehensive item lists have not been previously published.

It would have been possible to model the neonatology databy other approaches like the HL7 Clinical Document Archi-tecture. However, it was not intended to represent documentstructures but rather to comprehensively and consistentlymodel the data in order to avoid repeated documentation ofthe same items in different documents [31,32].

Other standardisation efforts are mainly implemented incommercial products (e.g. DICOM Structured Reporting, whichuses DICOM to archive and communicate structured reports)or are regionally used (e.g. Medical Markup Language) [33].

5.5. Perspective

An approach (odma) for applying archetype modelling wasdeveloped. However, the approach needs further research andvalidation in order to prove if the aim of avoiding repeated dataentry is reached, if odma is suitable for other clinical depart-ments, and if the resulting archetypes are an adequate basisfor qualitative archetypes.

The newly modelled archetypes of this research should betranslated into English and validated by health care profes-sionals in neonatology to correct and complete the concepts.It should be examined if they can also be used in othermedical fields. In future, the archetypes can be made avail-able in the archetype library so that others can use them toenable interoperability among different clinical applicationsystems.

6. Conclusion

The approach odma proved feasible in a real clinical settingwith an extensive item list, because of the separation of tech-nical and domain aspects.

Repeated documentation of the same data is a major obsta-cle to efficiently establishing interdisciplinary care concepts.The aim and motivation for using the openEHR approach was toavoid repeated data entry. By systematically structuring andmodelling the underlying item lists, archetypes can support

this.

If odma and available archetypes are used in different set-tings, semantic interoperability among the resulting systemscan be achieved. This can open new perspectives for trans-institutional data exchange and analysis.

i n f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531

Summary pointsWhat was already known on the topic

• The openEHR approach is established and with it thesyntax of archetypes as models of clinical content.

• It has been explored how existing Clinical Data Setscan be expressed by openEHR archetypes and tem-plates. Large organisations such as the UK NationalHealth Service Connecting for Health have started toexpress clinical content using openEHR archetypes.

What this study added to our knowledge

• Application of the openEHR archetype methodology tomodel the clinical information used in a real clinicalsetting with an established documentation infrastruc-ture.

• Introduction of a systematic approach (odma) for themodelling of openEHR archetypes and templates in areal clinical setting.

• Introduction of new clinical archetypes and validationof existing archetypes.

Acknowledgement

Contributors: Jasmin Buck performed the analysis, modelledthe archetypes, and contributed to the final manuscript.Sebastian Garde participated in the design of the approach,reviewed the archetypes, and contributed to the finalmanuscript. Christian D. Kohl performed the pilot survey inthe Department of Neonatology, participated in the analysis,reviewed the archetypes regarding plausibility, and con-tributed to the final manuscript. Petra Knaup participated inthe design of the study, reviewed the archetypes, and con-tributed to the final manuscript.

e f e r e n c e s

[1] C.D. Kohl, C. Schott, D. Verveur, O. Linderkamp, P.Knaup-Gregori, Can an EPR support the concept offamily-centred, individualized developmental care ofpremature infants and newborns? MEDINFO 2007(Proceedings of the 12th World Congress on Health (Medical)Informatics), Studies in Health Technology and Informatics12 (Part 1) (2007) 73–77.

[2] O. Linderkamp, Minimization of intensive care for tinypreterm infants, in: J. Bitzer, M. Stauber (Eds.),Psychosomatic Obstetrics and Gynaecology, MonduzziEditore, International Proceeding Division, Bologna, Italy,1995, pp. 243–247.

[3] P.J. Toussaint, E. Coiera, Supporting communication in

health care, International Journal of Medical Informatics 74(October (10)) (2005) 779–781.

[4] F. Leinert, W. Gaus, R. Haux, P. Knaup-Gregori, K.-P. Pfeiffer,Medical Data Management—A Practical Guide, Springer,New York, 2003.

a l i n

Part 1, Methods of Information in Medicine 45 (3) (2006)

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

[5] M. Hertzum, J. Simonsen, Positive effects of electronicpatient records on three clinical activities, InternationalJournal of Medical Informatics 77 (December (12)) (2008)809–817.

[6] H. Als, Program Guide: Newborn IndividualizedDevelopmental Care and Assessment Program (NIDCAP),NIDCAP Federation International, Boston, 2001.

[7] J. Young, Frühgeborene: fördern und pflegen, UllensteinMosby, Wiesbaden, 1997.

[8] C. Schott, D. Verveur, V. Ziesenitz, O. Linderkamp, DieGehirnentwicklung frühgeborener Kinder, Pflegezeitschrift11 (2006) 685–688.

[9] L. Holsti, R.E. Grunau, T.F. Oberlander, M.F. Whitefield,Intensive care unit movements are associated with acutepain in preterm infants in the neonatal specific newbornindividualized developmental care and assessmentprogram, Pediatrics 114 (July (1)) (2004) 65–72.

[10] T. Beale, Archetypes: constraint-based domain models forfuture-proof information systems, in: K. Baclawski, H. Kilov(Eds.), Eleventh OOPSLA Workshop on Behavioral Semantics:Serving the Customer, Northeastern University, Boston,2002, pp. 16–32.

[11] L. Bird, A. Goodchild, Z. Tun, Experiences with a two-levelmodelling approach to electronic health records, Journal ofResearch and Practice in Information Technology 35 (2)(2003) 121–138.

[12] T. Beale, S. Heard. The openEHR Archetype Model ArchetypeDefinition Language [cited 2008 Ocober 30]. Available from:http://www.openehr.org/releases/1.0.1/architecture/am/adl2.pdf.

[13] R.H. Dolin, L. Alschuler, C. Beebe, P.V. Biron, S.L. Boyer, D.Essin, E. Kimber, T. Lincoln, J.E. Mattison, The HL7 ClinicalDocument Architecture, Journal of the American MedicalInformatics Association 8 (November–December (6)) (2001)552–569.

[14] R.H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F.M. Behlen, P.V.Biron, A. Shabo Shvo, HL7 Clinical Document Architecture,Release 2, Journal of the American Medical InformaticsAssociation 13 (January–February (1)) (2006) 30–39.

[15] T. Beale, S. Heard, D. Kalra, D. Lloyd. Architecture Overview[cited 2008 October 29]. Available from: http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf.

[16] S. Heard, T. Beale, G. Freriks, A. Rossi Mori, O. Pishev.Templates and archetypes: how do we know what we aretalking about? [cited 2008 October 29]. Available from:http://www.openehr.org/publications/archetypes/templatesand archetypes heard et al.pdf.

[17] S. Garde, P. Knaup, E. Hovenga, S. Heard, Towards semanticinteroperability for electronic health records: domainknowledge governance for openEHR archetypes, Methods ofInformation in Medicine 46 (3) (2007) 332–343.

[18] S. Garde, E. Hovenga, J. Gränz, S. Foozonkhah, S. Heard,Managing archetypes for sustainable and semanticallyinteroperable electronic health records, Electronic Journal ofHealth Informatics 2 (2) (2007) e9.

[19] R. Chen, G. Klein, The openEHR Java referenceimplementation project. MEDINFO 2007 (Proceedings of the12th World Congress on Health (Medical) Informatics),Studies in Health Technology and Informatics 129 (Part 1)(2007) 58–62.

f o r m a t i c s 7 8 ( 2 0 0 9 ) 521–531 531

[20] D. Kalra, T. Beale, S. Heard, The openEHR Foundation.Regional Health Economies and ICT Services, The PICNICExperience, Studies in Health Technology and Informatics115 (2005) 153–173.

[21] B.G. Blobel, K. Engel, P. Pharow, Semanticinteroperability—HL7 Version 3 compared to advancedarchitecture standards, Methods of Information in Medicine45 (4) (2006) 343–353.

[22] B. Blobel, Advanced and secure architectural EHRapproaches, International Journal of Medical Informatics 75(March–April (3–4)) (2006) 185–190.

[23] L. Michelsen, S.S. Pedersen, H.B. Tilma, S.K. Andersen,Comparing different approaches to two-level modelling ofelectronic health records. Connecting Medical Informaticsand Bio-Informatics, (Proceedings of MIE2005), Studies inHealth Technology and Informatics 116 (2005) 113–118.

[24] D. Hoy, N.R. Hardiker, I.T. McNicoll, P. Westwell, A. Bryans,Collaborative development of clinical templates as anational resource, International Journal of MedicalInformatics 78 (April (Suppl. 1)) (2009) 95–100.

[25] R. Chen, S. Garde, T. Beale, M. Nyström, D. Karlsson, G.O.Klein, H. Ahlfeldt, An Archetype-based testing framework.eHealth Beyond the Horizon—Get IT There (Proceedings ofMIE2008), Studies in Health Technology and Informatics 136(2008) 401–406.

[26] E. Sundvall, M. Nyström, M. Forss, R. Chen, H. Petersson, H.Ahlfeldt, Graphical overview and navigation of electronichealth records in a prototyping environment using GoogleEarth and openEHR archetypes. MEDINFO 2007 (Proceedingsof the 12th World Congress on Health (Medical) Informatics),Studies in Health Technology and Informatics 129 (Part 2)(2007) 1043–1047.

[27] T. Schuler, S. Garde, S. Heard, T. Beale, Towardsautomatically generating graphical user interfaces fromopenEHR archetypes. Ubiquity: Technologies for BetterHealth in Aging Societies (Proceedings of MIE2006), Studiesin Health Technology and Informatics 124 (2006)221–226.

[28] S. Garde, E. Hovenga, J. Buck, P. Knaup, Expressing clinicaldata sets with openEHR archetypes: a solid basis forubiquitous computing, International Journal of MedicalInformatics 76 (December (Suppl. 3)) (2007) S334–S341.

[29] S. Garde, P. Knaup, E. Hovenga, S. Heard, Towards semanticinteroperability for electronic health records, Methods ofInformation in Medicine 46 (3) (2007) 332–343.

[30] E. Hovenga, S. Garde, S. Heard, Nursing constraint modelsfor electronic health records: a vision for domain knowledgegovernance, International Journal of Medical Informatics 74(December (11–12)) (2005) 886–898.

[31] A. Shabo, A global socio-economic-medico-legal model forthe sustainability of longitudinal electronic health records.Part 2, Methods of Information in Medicine 45 (5) (2006)498–505.

[32] A. Shabo, A global socio-economic-medico-legal model forthe sustainability of longitudinal electronic health records.

240–245.[33] M. Eichelberg, T. Aden, J. Riesmeier, A survey and analysis of

electronic healthcare record standards, ACM ComputingSurveys (CSUR) 37 (4) (2005) 277–315.