International Journal of Medical Informatics (2005) 74, 213220
Modelling and implementing electronic health
records in Denmark
Knut Bernsteina,, Morten Bruun-Rasmussena, Sren Vingtofta,
Stig Kjr Andersenb, Christian Nhrb
a
b
MEDIQ, Copenhagen, Denmark
Aalborg University, Denmark
Received 8 December 2003 ; received in revised form 11 July 2004; accepted 14 July 2004
KEYWORDS
Electronic health
records;
Information models;
Archetypes;
Paradigm shift;
Middleware
Summary The Danish Health IT strategy [Danish Ministry of Interior and Health,
National Strategy for IT in the Health Sector 20032007, Copenhagen, 2003 (in Danish). http://www.im.dk/publikationer/itstrategi/itstrategi.pdf. [1]] notes that integration between electronic health records (EHR) systems has a high priority. A
prerequisite for real integration and semantic interoperability is agreement of the
data content and the information models. The National Board of Health is working
on a common model for EHR, and its adoption is now being promoted through pilot
projects. At the same time, several development and implementation projects are
taking place at a regional level. These EHRs are built on information models from
different vendors and are based on different integration platforms. The Danish EHR
observatory, which has been monitoring the development of EHRs in Denmark since
1998, has analysed the challenges of using different information models and integration platforms. This paper also maps the development in Denmark to the new
paradigms in modelling techniques and integration technology.
2004 Elsevier Ireland Ltd. All rights reserved.
1. Introduction
In Denmark, the National Board of Health is developing a basic information model for electronic
health records (EHR) [2]. The specications currently exist at two levels: the conceptual level and
the informatics level. EHR systems are currently
developed and implemented in several counties in
Denmark by different providers. The systems are
based on different information models and differ* Corresponding author.
E-mail address: kb@mediq.dk (K. Bernstein).
URL: http://www.mediq.dk/ (K. Bernstein).
ent technology platforms. Through pilot projects,
attempts are taking place to align these models.
This paper presents a framework for understanding the observed development from 1st- to
2nd-generation EHRs. This framework consists of
a paradigm shift in both modelling techniques and
technology. The paper aims to analyse the different
models and implementation strategies in the three
major projects in Denmark and to map them to this
framework. Furthermore, the paper analyses the
modelling work by the National Board of Health,
and aims to identify compatibility challenges between the National initiative and the three County
projects.
1386-5056/$ see front matter 2004 Elsevier Ireland Ltd. All rights reserved.
doi:10.1016/j.ijmedinf.2004.07.007
214
The analyses are based on a survey made by the
Danish EHR observatory [3].
The EHR projects discussed in this paper are:
EHR development in Aarhus County based on a
Domain Object Model (Aarhus-DOM).
Distributed Health Care Environment in Copenhagen Hospital Corporation (DHE).
Shared record project in Vejle and Viborg Counties (SUP, Standardised Extraction of Patient
data).
Basic EHR Model from the National Board of
Health (G-EPJ).
2. Background: the technical and
modelling paradigm shift
The EHR observatory has, since 1998, monitored
the development of EHR in Denmark. The focus has
been on implementation and dissemination issues
and on questions related to integration of EHR systems. The implementation and dissemination issues
have been studied by analysing data on diffusion
rate of EHR systems, experience among the different stakeholders, and factors that increase diffusion and use of EHR systems. Questions related
to integration challenges include uncovering of differences and compatibilities between regional information models, analysing consequences of using
incompatible information models and identication
of the need for a common frame of reference. The
analysis of the data and the conclusions have been
published in annual reports [46], journals and conference proceedings [7,8].
Over the last 1015 years, there have been
several local development projects and prototypes
involving vendors with varying technology and
information models. Only recently, a strong coordination has taken place at the regional (County)
level. The result has been a transformation of pilot
projects into managed implementation projects.
At least some counties have succeeded in a substantial dissemination, i.e., in Velje County, around
60% of the hospital beds are served by an EHR.
Based on the monitoring, the EHR observatory
has observed recent fundamental changes in the
ideas regarding development and implementation
of EHR. The new paradigms are now massively
disseminated from a few front-runners to a broader
uptake. Since the changes are fundamental and
are spreading quickly, we consider them paradigm
shifts. The combined modelling and technology
paradigm shift creates the basis of moving from
1st-generation EHR systems to 2nd-generation
systems. The next generation EHRs will better
K. Bernstein et al.
support the new healthcare requirements with
patient-focused and shared care based on extensive re-use of information across organisations.
This implies secure communication of structured,
standardised datasets and a exible technological
system platform.
Below is presented a framework for understanding of the modelling paradigm shift and the technology paradigm shift.
2.1. The modelling paradigm shift
The new modelling paradigm consists of a separation of the generic information modelling from
the healthcare domain modelling. Consequently, instead of working with large, static models describing the entire healthcare-related world, it is now
possible to focus on smaller, dynamic models that
can be adjusted to different needs.
Various groups, i.e. in CEN, HL7 and OpenEHR,
have been working with similar ideas. We have
found useful the concept of Archetypes described
by Thomas Beale [9]: a model dening some domain concept expressed using constraints on instance structures of an underlying reference model.
We understand the archetype as a concept model
for a certain domain, based on constraints of a
generic information model. The archetypes will be
instantiated for a specic EHR and populated with
data. Templatesreecting the constraintscan
be useful to manage the instantiation at the user
interface.
The domain-related archetypes stand in contrast with the structure-related generic models.
At the structure-related generic level, the model
will only contain information on the basic parts
of the record and how they are related, i.e.
the record structure. The Electronic Health Care
Record Architecture standard from the European
Standardisation Organisation, CEN (ENV 13606)
[11], is such a generic standard. It denes the rules
for how a Folder can contain Compositions, which
can contain Headed sections containing Data items
or Clusters of Data items.
The (healthcare) domain-related content is described in the next level of models with the use of
archetypes. This level denes the types of entities,
acts, results etc. that can be found in the record,
i.e. medication, blood pressure or examination result. The actual value of a blood pressure (i.e. systolic blood pressure = 120 mmHg) is placed in a data
item as a result of an examination (blood pressure
measurement), which is a specic type of an act.
The blood pressure archetype describes in detail how the content is structured. This is a part of
Electronic health recordes in Denmark
215
Fig. 1 EHR architecture with three layers including a component-based middle layer. Component interfaces are
described using WSDL (Web Service Denition Language).
the healthcare (domain-specic) modelling work.
One advantage of this kind of modelling is that the
healthcare professionals can concentrate on modelling their domain without having to consider an
overall model.
2.2. The technology paradigm shift
The technology paradigm shift consists of a splitting up of the technical architecture in three
layers. The presentation layer handles the user
interfaces in the client applications, i.e. an
Internet browser. The presentation layer does not
communicate directly with the database layer.
All interaction goes via the applications in the
business logic layer (Fig. 1).
One advantage of this middleware EHR architecture, which already has been used in modern Hospital Information Systems (HIS), is that each layer
may be replaced separately. This gives the purchaser larger exibility to choose different vendors
for the databases, applications and user interfaces.
Furthermore, as shown in Fig. 1, the applications
can be divided into components. If these components are developed as web services, they can be
used outside the single hospital. The PICNIC project
[10] has described several basic components and
common health-related components, which have
the potential to be used at a regional or national
level. Some PICNIC components are developed in
open source, giving the possibility to adjust the
components for trans-national use.
A prerequisite for the replacement of layers and
components is interfaces between the layers that
are well-dened and public. The meaning of the
information must be preserved across layers, com-
ponents and systems, and the interface descriptions must also include the semantic level. Therefore, the success of technological development
should be seen in context with the new modelling
paradigms.
3. Methods and materials
The information about the EHR projects in Denmark, their information models and the implementation of these have been collected in three ways.
Literature and websites about the projects
themselves, and the available documentation on
the information models creating the basis for the
EHR applications has been studied (documented in
[5,6]).
Furthermore, workshops have been organised
with the county projects, where representatives for
the organisational and technical parts have been interviewed. At these workshops, semi-structured interviews were performed. The following areas were
highlighted:
The county EHR strategy and implementation
plans.
The basis for the EHR tender, i.e. workow analyses, requirements etc.
The plans for IT architecture and integration.
The use of models and standards.
Financial and organisational issues.
The information from the interviews were
analysed according to the framework described
in Section 2, in order to understand the use
of technology/architecture and modelling techniques/standardisation.
216
In addition, relevant standards and documentation from CEN, HL7 and OpenEHR have been used:
CEN ENV 13606 [11] as the main source.
HL7-parts of the Reference Information Model
[12].
OpenEHR-material on archetypes [9,13].
4. Results: descriptions of the four
projects
The data models for three major EHR projects in
Denmark and the standardisation initiative taken
by the National Board of Health is analysed and
compared. The models represent different system
development philosophies and scopes, relating
to the modelling and technology paradigm shifts
described above.
4.1. The semantic model
The National Board of Health has developed a basic information model for EHR systems and for data
transfer between EHRs [14]. The model is based
on a problem-oriented way of documenting the activities. It is a prerequisite that the bulk of data
is structured and based on common classications.
The record should be shared among all professional
groups, and the systems are required to be based
on the period of care principle. This implies that
all contacts to healthcare providers in relation to
one illness can be linked. When fully implemented,
K. Bernstein et al.
it will be possible to follow the interventions made
and assess the results achieved for a specic patient
problemregardless of what healthcare party provided the service.
The concept model is representing a general
clinical decision process and contains four activities
that are documented in four information entities
(see Fig. 2): the activity Diagnostic Consideration
is leading to a Diagnosis. The diagnosis is a
broad concept for any professional labelling of
the patients problem, using any relevant classication. It must not be conceived as medical
diagnosis only. The Planning activity results
in a set of planned interventions, i.e. activities
with the status planned. When executed, the
interventions change status, and then document
the actually performed activities. The outcomes
of the executed interventions are documented as
Results (i.e. lab. results from the intervention
blood test). Structured results can be evaluated
against operational goals. Since both the goal
and results are highly structured, they can be
automatically compared, without the need for
additional information entering. The resultsas
any other information in the recordcan initiate a
(re)consideration of the diagnosis. Such information
must be labelled to be in focus for that particular
diagnosis.
This concept level of the model is similar to the
philosophy behind HL7 version 3 and OpenEHR.
In addition to the generic model, class diagrams,
data denitions business rules and XML interfaces
have been developed [15].
Fig. 2 The Basic EHR modelconcept level. The circles represent activities, which is documented with information,
represented with the boxes. The diagnosis is a professional labelling of the patients problem, using any relevant
classication (not only ICD). The planning activity results in a set of planned interventions. When executed, they
produce a result, which can be assessed towards a goal.
Electronic health recordes in Denmark
There are mandatory relations between the basic elements: no intervention may be documented
unless a diagnosis is assigned as an indication.
The information that substantiates the diagnosis
must be explicitly pointed outthe so-called
information in focus. This may be any information
in the record including, for instance, the information from a referral letter. There must also be
an explicit relation between the result and the
intervention producing that result.
These mandatory relations, which are reected
in the information model class diagrams and business rules, are sound requirements for improving
the production data and quality data from the
healthcare sector. However, even if healthcare professionals may reason this way, they are not used to
document this way.
There are several challenges when disseminating
this model. It requires organisational and cultural
changes among the healthcare professionals. Furthermore, the model needs to be rened, specially
regarding the representation of results. In order
to full the intention of using highly structured
data, an extensive classication system needs
to be provided. The National Board of Health is
currently testing the use of SNOMED. And nally,
there are challenges to develop user interfaces
that can support and automate the data capture,
manipulation and presentation.
4.2. The generic model
Aarhus County is developing a common EHR
system for all the hospitals in the county. They
are developing a general conceptual modelthe
Domain Object Model (DOM). The generic model
is a basic part of the development tool used for
tailoring of EHR modules. These modules are based
on archetype-like models called Act Description
Denitions. These obtain integrity between the
individual modules and enable communication to
proprietary systems.
In the core of the DOM is the Act. In the
model, it is related to a Person and the persons
Period of care. The Act is represented by its
Act Description, which contains element groups
and elements in a recursive structure. Using the
Act Description Denitions, the structure and
content of the Act can be dynamically described.
For example, an Act Description Denition may
prescribe that an instance of Blood Pressure
must consist of an element group with two elements, containing two values in mmHg: systolic
and diastolic pressure. The information in the
Act Description Denitions is also used during
217
runtime to control the display of data in the user
interface.
The development in Aarhus County is, thus, using
the new modelling paradigm. The implementation
is also based on a three-layer, component-based
technology platform. It has been a challenge to
optimise system performance to obtain adequate
response time and to obtain an extensive and coherent set of archetypes. Currently, a medication
module has been implemented based on the common integration platform and the archetype-like
models. A prototype of the EHR has been developed
using the new Basic EHR model developed by the
National Board of Health.
4.3. The middleware model
The Copenhagen Hospital Corporation (H:S) has
chosen a middleware solution. They are building
the EHR system and are integrating existing systems on the middlewares data model. The product
used is Distributed Healthcare Environment (DHE
[16,17]). In H:S, the presentation layer will be
based on a web portal, communicating with various modules in the application layer.
This project is thus based on a three-layer technology platform, but is using the information model
that is built into the DHE product. This model is not
built with generic building blocks like the DOM in
Aarhus, but the healthcare concepts are modelled
explicitly, i.e. the model contains concepts like
Patient, Part of the body, Actual Act and
Resource.
One challenge has been to interface the middleware to a large number of legacy systems. Another
challenge has been to adjust the DHE-model to the
new Basic EHR model developed by the National
Board of Health. The original DHE-model was
contact-based, but the Basic EHR model demands
period of care-based registration. This implies
that each of the patients problems can be monitored separately over time and cross-organisational
borders.
The project has succeeded in developing the
core part of the EHR with multi-professional documentation using structured data. It is based on the
Basic EHR model and is using the H:S portal on top
of DHE.
4.4. The communication model
Hospitals in Vejle and Viborg Counties use a number
of different legacy EHR systems, which is not based
on the new Basic EHR model developed by the
National Board of Health. The systems are contact-
218
based (not period of care-based), without a clear
three-level system architecture. To give access to
data across counties and systems, the two counties
have launched the SUP standard (Standardised
Extraction of Patient data). This is a communication methodology including a concept model
[18].
The SUP model supplements the (system) models mentioned above, but is dedicated for communication purposes. In the SUP model the healthcare
concepts are also modelled explicitly. The core of
the model consists of 18 events types, which represent acts (i.e. procedure, medication, booking)
and observations (i.e. results, ndings, diagnoses).
The model can handle period of care-related
data.
Data is exported from the systems according
to the SUP structure and stored in a repository
database. The data then becomes accessible to
other authorised parties through a web browser.
The standard will be disseminated nationwide.
The shared record project in Vejle and Viborg
Counties is not aimed at close integration between
systems, but rather to give access to a view of patients data across systems and platforms. The simplied SUP model lays out the common structure
and format for the EHR data. The challenge in this
project has been to ensure correct and consistent
mapping from the EHR systems to the common SUPbased database.
4.5. Assessment of the new Basic EHR
model
Pilot projects are established to stimulate the uptake of the new Basic EHR model and to analyse to
what degree, systems based on the model full clinical requirements. The projects in Copenhagen and
Aarhus mentioned above are the main pilot sites.
The projects are co-funded by the National Board
of health, and the EHR observatory is responsible
for the validation.
EHR observatory is currently carrying out a clinical assessment and a technical validation.The comprehensive clinical assessment consists of:
Change readiness analyses.
Assessment of clinical functionality.
Workow analyses with video documentation.
Usability analyses.
The technical validation is based on a set of 500
tests with coherent test data, reecting the national Basic EHR model. The EHR pilots conformity
against the national model are validated by several
criteria:
K. Bernstein et al.
Conformity
Conformity
Conformity
Conformity
with
with
with
with
use-case specications.
the business rules.
the information model.
communication standards.
The documentation produced during the test is
consolidated in one document, stating the test result and possibly, the lack of functionality.
5. Discussion
Some 2nd-generation EHR systemswith secure
communication of structured, standardised
datasets and a exible component-based middleware platformare expected to be operational
in Denmark within a few years. The development
in Aarhus County and Copenhagen Hospital Corporation seem to be the prime candidateseven
though there are several technical, modelling and
organisational challenges.
The two-level modelling used in Aarhus is promising and interesting from a theoretical point of view.
The practical implementation has shown performance challenges and substantial effort to keep the
Act Description Denitions (archetypes) coherent
and updated.
It is not likely that the 1st-generation EHRs will
be able to full the requirements of the new Basic EHR model without very extensive reprogramming. Some of the main challenges are the new
requirements to relate all data to the period of
care, the mandatory links in the process model
and the extensive set of business rules. The experience from the development of the 2nd-generation
systems conrms that the data structures and program logic is very different from 1st-generation
systems.
As described above, there are several modelling
activities in Denmark, with somewhat different
purposes, methodologies and results. From the
Counties (the hospital owners), there is a clear
commitment to the National Board of Healths Basic EHR model. Also, several vendors are planning
to use the model or are testing parts of the model.
However, systems will be implemented in parallel
with the development of the Basic EHR model, and
several legacy EHR systems and other systems that
exist on the market. There is, therefore, a need
to ensure proper mapping between the various
models. Furthermore, the extensive international
modelling initiatives need to be taken into account,
i.e. HL7 version 3, CEN and OpenEHR.
Archetypes may have a role in the modelling
work, since it gives the healthcare professionals an
opportunity to handle smaller domain-specic mod-
Electronic health recordes in Denmark
els, without having to consider the whole model for
healthcare. This can be used to enhance the granularity of the Basic EHR modelespecially regarding
representation of intervention results. In this area,
the information is modelled in a generic way giving
the possibility to represent a wide variety of structures and formats of results.
Secondly, archetypes can be used for implementation and execution of EHR systems, based on the
generic (two-level) modelling.
Thirdly, the archetypes can be used at the userinterface level. There is a need for representation
of granular data at the user interface, where data
needs to be grouped together for a specic purpose. Archetypes can be used for presentation of
standard plans, which basically is a template of interventions with the appropriate links to diagnoses
and expected results. Similarly, the archetypes can
be used for presentation of other templates, i.e.
for capturing data for quality assurance, local workow, research etc.
219
on the other. However, neither new technology
nor new modelling techniques result in the desired
semantic interoperability by itself. This is only
achieved by continuous standardisation work
with participation from healthcare professionals
and industryand supported by validation and
evaluation.
Acknowledgement
The Danish Electronic Health Record Observatory
(EHR Observatory) consists of two organisations:
the consulting company MEDIQ and The Virtual Centre of Health Informatics at Aalborg University. The
EHR Observatory is funded by the Ministry of Interior and Health, the Danish Regions and Copenhagen
Hospital Corporation.
References
6. Conclusion
In Denmark, the EHRs are migrating from 1st to 2nd
generation. This involves a modelling and technology paradigm shift. The two-level modelling is
evident in a few projects, and the layered architecture is predominant in several projects. A new
generation of EHRs is also needed to comply with
the requirements coming out of the new Basic EHR
model.
There is a need to support the development of
2nd-generation EHR systems. This implies pilots to
validate the use of the model and to understand
how to create an efcient user interface to support
the new problem-oriented, period of careoriented, process-oriented and multi-professional
model. Classications for increased structuring of
information is required, as well as development
of regional middleware (regional platforms) to
support the layered approach. Financial support
through co-funded pilot projects is essential, and
is currently provided by the National Board of
Health.
Archetypes are likely to have a role in the development. Archetypes provide a way to increase
granularity of the model. Archetypes are also an
efcient tool for building templates for data presentation on the user interface, while keeping the
link to the model.
Several implementation projects in Denmark are
striving towards integration and communication
between different EHR systems on one hand, and
between EHR systems and other systems (i.e. HIS)
[1] Danish Ministry of Interior and Health, National Strategy for IT in the Health Sector 20032007, Copenhagen, 2003 (in Danish). http://www.im.dk/publikationer/
itstrategi/itstrategi.pdf.
[2] Basic EHR Model (Documents and specications in
HTML-format), The National Board of Health, 2002 (in
Danish). http://www.medinfo.dk/epj/gepj/020 20040416/
index.html.
[3] http://www.epj-observatoriet.dk/.
[4] K. Bernstein, M.B. Rasmussen, S.K. Andersen, C. Nhr, S.
Vingtoft, The EPR Observatory, Annual Report 2001(in Danish), Odense, The County of Funen, 2001. http://www.epjobs.dk/publikationer/Statusrapport2001.pdf.
[5] S.K. Andersen, C. Nhr, S. Vingtoft, K. Bernstein,
M.B. Rasmussen, The EPR Observatory, Annual Report
2002 (in Danish), Aalborg, Virtual Centre for Health
Informatics, 2002. http://www.epj-obs.dk/publikationer/
Statusrapport2002.pdf.
[6] M. Bruun-Rasmussen, K. Bernstein, S. Vingtoft, S.K. Andersen, C. Nhr, The EHR Observatory, Annual Report 2003
(in Danish), EPJ-Observatoriet, 2003. http://www.epjobs.dk/publikationer/Statusrapport2003.pdf.
[7] S.K. Andersen,C. Nhr, S. Vingtoft, K. Bernstein,
M.B. Bruun-Rasmussen, A comparative study of EHR
projects in Denmark, Stud. Health Technol.Inform, 90
(2002) 226231. http://www.epj-obs.dk/publikationer/
EpjObsMie2002.pdf.
[8] C. Nhr, S.K. Andersen, S. Vingtoft, K. Bernstein, M. BruunRasmussen, Monitoring the development and diffusion of
EHR systems in Denmark, in: R. Baud et al. (Eds.), Proceedings of Medical Informatics Europe, IOS Press, vol. 95, 2003.
[9] T. Beales, Constraint-based domain models for future-proof
information systems. http://www.deepthought.com.au/
it/archetypes/output/front.html.
[10] PICNIC Interim System Architecture, Deliverable 2.3.
http://www.medcom.dk/picnic/deliverables.
[11] ENV 13606-1 Health informatics, Electronic healthcare
record communication, Part 1: Extended architecture CEN
1999. http://www.centc251.org/.
220
[12] HL7 Reference Information Model Version 1.19.
http://www.hl7.org/.
[13] The Good Electronic Health Record. http://www.gehr.
[org/].
[14] L. Asp, J. Petersen, et al., A conceptual model for documentation of clinical information in the EHR, in: R. Baud
(Ed.), Proceedings of Medical Informatics Europe, vol. 95,
IOS Press, 2003.
K. Bernstein et al.
[15] http://www.medinfo.dk/epj/gepj/020 20040416/index.
html.
[16] The DHE middleware, Introduction, Specications from
GESI, Rome, Italy.
[17] The DHE model version 3, Specications from GESI, Rome,
Italy.
[18] SUP specication version 2.0. Draft 12 June, 2003 (In Danish). http://www.medcom.dk/.