Conference PaperPDF Available

Underpinnings of the Interoperability Reference Architecture


Abstract and Figures

As we are moving into new paradigms of care, sharing of health information becomes crucial. We need new systems and more interconnectivity to support this. The regional approach to eHealth solutions in New Zealand hinges on establishing trusted and interoperable systems. The Interoperability Reference Architecture is a first step towards providing overall principles and standards to reach this goal. A core group from the Sector Architects Group was formed and prepared the first draft of this document. After initial internal feedback it went through wider consultation – including public. Good feedback was received, including international. It then went through formal HISO processes and was approved as a national interim standard. The Reference Architecture comprises three pillars which define: 1) XDS based access to clinical data repositories, 2) a common content model underpinned by CCR and openEHR Archetypes to which all health information exchange should conform, and 3) use of CDA as common currency for payload. A trial implementation is yet to be conducted, however we used the Content Model to align ePrescribing data model with the Australian model in order to validate the methodology. The Reference Architecture will provide an incremental step-by-step implementation approach to interoperability and thus minimise risk.
Content may be subject to copyright.
Underpinnings of the Interoperability Reference Architecture
Koray Atalag
National Institute for Health Innovation (NIHI),
The University of Auckland
Tamaki Campus, Auckland 1142, New Zealand
Alastair Kenworthy
Ministry of Health
Wellington, New Zealand
David Hay
Orion Health
Auckland, New Zealand
As we are moving into new paradigms of care, sharing of health information becomes crucial. We
need new systems and more interconnectivity to support this. The regional approach to eHealth
solutions in New Zealand hinges on establishing trusted and interoperable systems. The
Interoperability Reference Architecture is a first step towards providing overall principles and
standards to reach this goal. A core group from the Sector Architects Group was formed and
prepared the first draft of this document. After initial internal feedback it went through wider
consultation including public. Good feedback was received, including international. It then went
through formal HISO processes and was approved as a national interim standard. The Reference
Architecture comprises three pillars which define: 1) XDS based access to clinical data
repositories, 2) a common content model underpinned by CCR and openEHR Archetypes to which
all health information exchange should conform, and 3) use of CDA as common currency for
payload. A trial implementation is yet to be conducted, however we used the Content Model to
align ePrescribing data model with the Australian model in order to validate the methodology.
The Reference Architecture will provide an incremental step-by-step implementation approach to
interoperability and thus minimise risk.
1. Introduction
Interoperability can be defined at functional (or syntactic), semantic and process levels. The first is the mere ability of
different systems to exchange data without any guarantee of understanding the meaning. Semantic interoperability
requires data and the context be encapsulated in a computable way so that the receiving system can process information
in the intended way. Alignment of processes and service level agreements leads to process interoperability [1].
It is imperative to achieve all three levels in order to achieve true systems interoperability. It is fair to say that achieving
semantic interoperability is the hardest and is the main focus of many interoperability standards in eHealth, such as HL7
(v2/v3 messaging, CDA/CCD and the upcoming FHIR standard) [2], ASTM Continuity of Care Record (CCR) [3],
ISO/EN 13606 [4], openEHR [5] and DICOM SR [6]. There’s a need for a common terminology, healthcare concept
definitions and the means to represent data in the form of generic technical building blocks (aka reference model) [7,8].
It is apparent that there is no one-size-fits-all solution to eHealth interoperability [9]. In places with high health IT
adoption, such as the US, we see islands of advanced provider-centric systems but little inter-connectivity. This means
complete health information cannot be accessed or even be known to other providers in the course of a patient journey.
Canada Health Infoway [10] is a national programme which provides leadership, funding and a broad set of standards,
including those for interoperability, mainly underpinned by HL7 v3. Using the same standard, however, the NHS CfH
project in the UK with the aim of establishing a centralised electronic health record (EHR) system have recently had a
catastrophic failure [11], as did the Dutch national EHR system [12]. In Nordic countries almost all GPs use an EHR
system (e.g. 100% in Denmark and Sweden) but the figures are much lower for hospitals with the exception of Sweden
(97%). This pattern is also present in other countries with good EHR adoption in primary care, such as the Netherlands
(99%), UK (96%), Australia (95%) and New Zealand (100%) [13,14]. France has recently deployed a national EHR
programme (Dossier Médical Personnel) based on regional solutions which is underpinned by HL7 CDA and IHE XDS
Profiles [15]. Adoption of health IT and interoperability strategies are quite variable in the rest of Europe. With a new
primary care system in its infancy, most hospitals in Turkey have comprehensive and fully integrated systems in place
with limited interoperability (first author’s personal experience). Singapore puts a large emphasis on interoperability in
their national EHR which is underpinned by a Logical Information Model (LIM) that encapsulates the structure and
semantics of information and links with terminology [16]. Japan has developed the medical markup language (MML)
that has predetermined tags and structure for commonly used clinical forms and represented as XML [17]. South Korea
uses ebXML and CDA as the basis of data exchange [18]. Brazil has developed a propriety XML based messaging
system (TISS) for billing purposes and is planning to implement a CDA based solution to exchange laboratory results.
A recent announcement states they will use ISO 13606 extracts developed by the state of Minas Gerais for national
health information exchange (HIE) [personal communication]. Nehta have long been providing leadership for
interoperability and the recent national EHR programme (PCEHR) heavily relies on standards including HL7 CDA,
XDS, openEHR Archetypes and SNOMED [19].
While the ultimate goal is to establish a comprehensive shared EHR for all users (including the patient), no single
jurisdiction has been able to achieve that goal at this time. A wide range of interoperability standards are being used
depending on local needs and constraints in these jurisdictions as well as proprietary solutions, such as the Danish
MedCom [20]. It looks, though, that there’s recently a shift towards the dual-level approach where the semantics of
information is separated from the technical environment by modelling as described by openEHR and ISO/EN 13606.
Sweden and Brazil, for example, have committed to using openEHR as the basis of their national eHealth programs.
Singapore’s LIM is also underpinned by ISO 13606 (a subset of openEHR).
Here in New Zealand, we are midway into a four-year programme with the primary objective that health practitioners in
all settings have access to a shared electronic view of core personal health information, which will also be available to
the individual concerned. This will be available to all New Zealanders, from a target date of 2014. Rather than one size
fitting all, a number of solutions can be envisaged, each designed for a different life stage or health status for example,
early childhood or having long term conditions. The strategy set out in the National Health IT Plan 2010 (NHITP)
[21] requires local funding to be pooled and invested regionally, particularly with regard to interoperability in the
development of regional clinical data repositories for referrals, test results, medication lists, etc. This will then provide a
base of objective health information for shared care systems to draw on, as well as from the patient and provider
identity systems that will continue to exist at national level.
The notion of the New Zealand health sector or at least its publicly funded organisations adopting a common set of
reference architectures arose in 2008. At this time there was little in the way of regional organisation; however, it
happened that three or four DHBs had architecture teams, and it was out of these that the first material came together
this nascent health sector architecture being modelled on the TOGAF architecture framework, and named ‘Health Base’.
A national health sector architects group of thirty or so began meeting in 2010, and was accorded status as an advisory
group to the National Health IT Board (NHITB), and directed by its own governance group.
Technical working groups were formed, among them one with the brief for interoperability in particular, to make
choices about the ways in which systems could best interoperate in order to achieve the shared care vision described by
the NHITP. The team’s primary task was then to formulate a suitable and consistent set of rules, which eventually
became on its completion twelve months later the sector’s approved Interoperability Reference Architecture [22].
The aim of this paper is to report on the methodology followed during write-up of the Reference Architecture, and to
provide an overview with an emphasis on ECM.
Our work on interoperability had a number of constraints and influences. Foremost, there was the need to embrace the
shared care vision of the NHITP. The plan introduced the idea of regional repositories as a key sharing mechanism.
There was no notion that fully integrated systems would rule; rather, existing applications would continue to be
supported alongside new ones, albeit while adding new information sharing capabilities. Generally, we wanted to
protect existing investments and foster a useful diversity of vendors in the market. With new interest in data quality and
the use of properly structured and coded data (e.g. using SNOMED), we had an opportunity to enable these things.
All in all, the scope was more or less defined for us. Our key philosophy from an early point was the idea that it was not
our business to define how individual systems worked internally, how their databases were structured, or what
technologies they used; we would limit ourselves to defining what occurs between systems and at their interfaces.
2. Materials and Methods
The team’s work was underpinned by a number of principles that were seen as the most important to the sector.
1. Align to national strategy as reflected in national and regional plans
2. Align to business needs prioritise the Reference Architecture in line with regional and national programmes
3. Invest in information use a technology agnostic common content model, and use standard terminologies
4. Work collaboratively with the sector respect the needs and input of all influential parties across the sector
5. Use proven standards adopt suitable and consistent national and international standards wherever they exist (in
preference to inventing new specifications)
6. Use a services approach move the sector from a messaging style of interaction to one based on web services
We believed that these principles, properly applied, would enable the creation of a fit-for-purpose, timely and
compelling specification that would have authority within the sector. And we came to respect another important
principle, which was to leave room for innovation. Above all, we had to be pragmatic and reasonable in terms of what
we wrote into our specifications, and therefore asked of implementers.
The project to produce the Reference Architecture was initiated under the auspices of the Health Sector Architects
Group (SAG), which is an advisory group to the NHITB. A small team was created from members of the SAG
Interoperability Technical Working Group and government funding was made available for supporting the involvement
of members working for non-governmental organisations and to cover logistical costs. Consideration was given to
include the vendor perspective and this technical group included vendor representatives but not the core group in order
to be fair to all vendors operating in New Zealand. However, as the document was to have public input before being
ratified by HISO, those vendors (and others) who wanted to give input would have an opportunity to do so.
Having formed the core team, the first task was to define the core principles from which the Reference Architecture
would develop. This was a reasonably straightforward task, and the resulting principles (the most significant of which
are described above) were documented and presented back to the SAG, where there was good discussion, and the
Principles themselves were agreed upon by that group. These principles were proved a useful touchstone many times in
the development process when choices had to be made. The core team then had a number of face to face meetings to
flesh out the document, supplemented by individual work between those meetings. It took some time for the team to
agree on the methodology to define a single content model to which all health information exchange artefacts should
conform. The decision to use the openEHR model driven approach was, at the time, quite controversial though
subsequent movements in the industry have shown that it was the correct one. It is important to note that the
organization of the information the model - is not the same as the mechanism of representing it ‘on the wire’.
Separating the information model from its representation makes it possible to use different representations, yet remain
consistent with the model, and this will be important as we move forward.
Once the initial draft of the Reference Architecture was created, it was published on a public forum (HIVE) for
feedback from the health IT community. Interestingly, the initial reviewers were from the International community and
the feedback was substantially positive. The document was also presented to HISO for comment.
Even after a couple of rounds of editing, the completed reference architecture document ran to over 100 pages. The
authors were reluctant to cut further into their carefully worded explanations, but recognised a risk that readers would
miss the key messages amid the weight of text. So it was decided to reinforce these ideas by formulating them as sets of
architectural directives, brought out into new specifications. Three sets of directives were created, each fashioned as an
architecture building block. The first building block specified interfacing requirements for clinical data repositories. The
second described particular means of deriving an exchange content model and representing it. And the third specified
the use of structured documents as the currency of exchange. In this way, each building block by itself represented an
independent concern, while the three together provided a concise statement of what implementers would need to adhere
to at a minimum in building regional health information exchanges.
To cement their place, this series on health information exchanges was submitted to HISO as a proposal for a new
national standard. The committee accepted the proposal, and the drafts were issued for public comment by the sector. At
the close of five weeks, there were fourteen responses, presenting a total of a little more than 100 individual points. An
evaluation panel was convened, with the authors and a number of sector experts, including vendors’ representatives,
meeting in person to consider the arguments made. While several issues proved to be complex and had to be debated,
most could be resolved by the end of the day. It was a reflection of the complexity of the residual issues that it was not
until three months later that the panel finally accepted the revised drafts by ballot. The HISO committee endorsed this
decision, and an interim standard i.e. one subject to trial implementation before full approval was declared.
It is worth a closer look at where the difficulties lay. While comments on the first (repositories) and third (documents)
building blocks were largely positive and reinforcing, it was the second specification the Exchange Content Model
(ECM) that received the most critical attention and, in consequence, took the longest to agree upon. However, we got
there in the end. On reflection, part of the problem might have been that, contrary to intentions, we had somehow mixed
two distinct concerns in that building block (derivation versus representation, with respect to the ECM). In any case, the
HISO process proved invaluable in flushing out the important issues, and strengthening the specification as a result. The
process was also helpful in promoting the new specifications to the sector, and establishing the status of those
specifications in particularly, the expectation that solutions would have to be built this way in order to receive
The building blocks as they stand currently define interoperability at a ‘bronze’ (or base) level (as opposed to silver or
gold), and will develop from there as we gain experience with actual solutions. There is already a trial implementation
at the planning stage, and over the next twelve months we can expect to see this experience inform product
development and implementations around the country.
2.1. Overview of ABB
In a little more detail, the three architecture building blocks [23] are scoped as follows:
HISO 10040.1 is about clinical data repositories and their interfaces. It states requirements for a particular set of
document sharing services based on the IHE XDS integration profile. XDS defines methods to store, locate and retrieve
information from multiple sources or repositories (as in regional and national levels). The central mechanism used to
achieve this is a registry providing a consolidated index over all content within the ecosystem.
HISO 10040.2 is about the single content model for information exchange. It is both a prescription for the derivation of
this model from CCR specification, and a prescribed means of representing that model as a set of detailed clinical
models expressed as openEHR archetypes. In addition, we require an alternate formulation of these models as ISO/IEC
11179 data element definitions.
Lastly, HISO 10040.3 is about the use of HL7 CDA structured documents as the common currency of exchange the
payload. In addition CDA can be used to define health records of various forms, for example a shared health summary
record, at some set of interfaces.
2.2. Exchange Content Model (ECM)
One of our principles is to invest in information. This implies focusing on defining which information we will be
dealing with instead of investing on a specific solution or technology, thus mitigating risk. This is as simple as defining
universal characteristics of common information, for example the concepts, terms used to describe them and their
structure, repeatability and optionality, data types, value sets, default and reference values, and associated coding and
classification systems. The main premise of this approach is that semantic interoperability can be achieved provided that
all information in transit are derived from this content model designated as the single source of truth. Traditionally
documents, spreadsheets and generic modelling formalisms (e.g. UML) are used to capture this information. However
health information is highly changeable [24] and maintaining the content becomes difficult and frequently this leads to
inconsistencies over time where each implementation evolves in its own way which renders data non-compatible. We
also recognise that the content model must provide different representations to suit the needs of different user roles,
with different levels of technical and domain expertise.
The Reference Architecture is underpinned by the Detailed Clinical Models (DCM) approach to represent the content
model in a consistent and technology agnostic way in terms of a computer-processable information model [25]. Each
DCM defines a meaningful unit of health information which includes the necessary context in order to preserve its
semantics when transferred to another system. Thus a DCM is the smallest non-dividable atoms of health information
exchange which is different from the alternative method of trying to achieve semantic interoperability by using single or
compositional terms. DCM contain all possible data items for a given concept; hence it defines a maximal dataset. In
most cases only a fraction of data items defined in a DCM will be required for a particular exchange. However using
data items from the same set will ensure consistency among implementations and when the data are aggregated from
different sources they will conform to the same DCM and thus be comparable (Figure 1).
We decided to use openEHR Archetypes [26] as the means to express DCM. This is commonly known as two-level
modelling where the first level comprises a reference model (RM) comprising fairly stable technical artefacts as
common building blocks that depict the generic characteristics of health information (e.g. data structures and types) and
provide the means to define clinical context to meet ethical, medico-legal and provenance requirements.
Source System Recipient System
Source data Recipient data
Exchange Content Model
Conforms to
Source to
ECM to
Web Service
Figure 1 - Health information exchange (either message or web services based) conforming to ECM
At the second level the discrete clinical concepts are defined by pulling together these building blocks and constraining
them (e.g. defining hierarchy, optionality, repeatability, providing default values and etc.) using visual tools. This
layered approach effectively separates the business and technical concerns and makes it possible for clinicians and other
domain experts to do the modelling. It also helps with clinician engagement and can significantly reduce the time and
effort required to build and maintain ECM. It is also possible to link data items to biomedical terminologies leveraging
the vast amount of knowledge needed for automated decision support.
A typical example is the blood pressure measurement Archetype (Figure 2). It consists of a data part that holds the
actual measurement data (e.g. systolic and diastolic blood pressure). Along with the main data essential context
information required for the correct interpretation by a different system, such as cuff size (e.g. adult, child) and patient
position (e.g. lying, sitting) are also captured.
Figure 2 - Mindmap representation of the blood pressure measurement Archetype from Nehta DCM repository
Archetypes can be modified safely without breaking original semantics and data-level compatibility by a formal method
called Archetype Specialisation. Here new data items or values can be added as well as items providing more detail to
existing content. It is also possible to define tighter constraints, for example a free text data item can be further
constrained to coded text. As such any coded text entered using the specialised archetype will still conform to the parent,
and can be persisted and queried alike in different systems.
CCR will be used as the starting point for ECM and will include its subject areas (headings and scope), conceptual data
elements and business descriptions. The main departures are that the CCR XML schema will not be used, and that the
contents of the model will be extended to suit New Zealand requirements. CCR, IHE Content Profiles [27] and
international DCM (where appropriate) as well as existing data models in New Zealand will be used to populate ECM.
New DCM’s will be created when necessary.
The Reference Architecture depicts that ECM data definitions shall be represented using ISO/IEC 11179 meta-data
standard and stored in Australia’s national METeOR registry in a separate area. While we acknowledge that DCM
based representation and METeOR may have some overlap the envisaged usage is to register individual data elements
with explicit context, mostly administrative, and leave complex clinical semantics to the DCM. This would help manage
the somewhat uncontrolled degree of freedom in Archetype development. There is also a recommendation to use
SNOMED CT Reference Sets wherever possible, in preference to other value sets.
Governance of the Exchange Content Model, especially keeping the core model stable and consistent over time, will be
critical. openEHR offers many advantages in that respect by means of formal Archetype specialisation mechanism,
versioning, and a web based collaboration and artefacts repository called the Clinical Knowledge Manager (CKM) [28].
Archetypes can be transformed into different formats, including human readable (e.g. mind maps, pdf) and computable
(e.g. UML class model, XML schema, HL7 CDA template) artefacts and made available for technical professionals. It
thus provides single source management of ECM while allowing for different representations of same information as
required. While it is possible to do these transforms automatically (by creating an XSLT transform once per Archetype),
this will initially be done manually, and automated transforms created at a later stage.
2.3. Putting ECM into Work A Practical Example
As a practical example to understand the ECM methodology we have selected the Community ePrescribing Pilot
Project (CePP) and aligned its dataset with the Australian model [29]. We used Archetype specialisation and followed
these steps:
1. Mapped items corresponding to the same concepts to each other.
used as is if labels were the same, otherwise renamed
disabled enumerated values in Archetypes not in CePP
put tighter constraints where CePP had more precise definitions (e.g. ‘Administration route’ has an
enumerated code list in CePP whereas the corresponding Archetype item is free text).
used NZMT terminology in the Archetype for specifying drugs in the prescription which is able to capture
data from Trade name, ULM code, Generic Name and Generic ULM code items in CePP
2. Added new items to Nehta Archetypes present in CePP only.
3. Disabled items not used in NZ context
As a result we were able to reach full alignment with the Nehta model using Archetype specialisation method.
3. Results and Discussion
The Reference Architecture is intended to be a key national standard. There is a lot hinging on this it is more or less
essential to the National Health IT Plan, or at least to its sustainable realisation. It is fair to say that SAG TWG and
HISO standardisation processed worked well. However a trial implementation is yet to be conducted in order to validate
the Reference Architecture.
It takes at least four to nine years before eHealth initiatives demonstrate their return on investment in terms of socio-
economic returns [30]. The consensus internationally seems to favour an incremental step-by-step implementation
strategy in order to minimise risk underpinned by supporting a standards-based approach. The challenge we face today
is the introduction of new paradigms of care, such as shared care, and to support these new classes of systems as
described in the National Health IT Plan. The need for new standards and mechanisms for interoperability arise from
the regional/national scope of solutions and the distributed but pervasive nature of these. The Reference Architecture
will enable sector wide cohesion which is important at this time for New Zealand with so many different projects
currently running, and more to start in the near future. Aspects of some existing standards have been overtaken by this
work-these will require revision or even replacement (e.g. the existing specifications for e-referral and discharge). There
is also the conspicuously vacant space around shared care that we need to consider. We will need to develop suitable
migration strategies that effectively pursue the necessary change while protecting current investments where we can.
In this rapidly changing world of healthcare interoperability the Reference Architecture needs to evolve as more
evidence accumulates internationally as to what is working and what is not. For example the emerging HL7 FHIR
standard looks likely to replace the current document centric model based on CDA with a web services based approach
[31]. However the underpinning principles we believe are likely to be future-proof, such as the services based
orientation, definition of a computable content model and registry based information exchange. To this end the
Reference Architecture does not prescribe any fixed solution architecture as to whether it is best to develop a centralised
EHR or adopt a message/document centric information exchange or a true distributed system. Since the publication of
the building blocks, the Reference Architecture has been extended by the addition of specific directives for referral,
discharge and shared care solutions. This is a healthy evolution, with the new material showing what can be achieved by
applying the straightforward rules already defined to particular application domains.
Since it is crucial that such standards and the methodologies prescribed need to be understood easily by system
designers and implementers, a number of seminars and training activities have been organised by HINZ, HL7 New
Zealand and the newly established New Zealand Chapter of openEHR (working under auspices of HL7NZ). Many
participants have expressed very positive feedback including those from overseas. A Tweet [32] from US said: Wow,
those specs are surprisingly readable! Can we get someone to visit the states and help with ours? :)”.
Next steps will include the development of a certification and accreditation framework for assessing solutions and
suppliers. As a key part of this, vendors will be asked to demonstrate willingness to work within the Reference
Architecture’s rules and develop their products accordingly.
4. Acknowledgements
We acknowledge contributions of Alan Le Maitre who was a member of the core group. Special thanks to our fellow
colleagues in the SAG TWG and others for their valuable feedback and support, and also to the NHITB for
commissioning the work.
5. References
[1] Health Level Seven EHR Interoperability Work Group. Coming to Terms: Scoping Interoperability for Health
Care [Internet]. 2007 Feb. Report No.: FINAL. Available from:
[2] Health Level Seven International - Homepage [Internet]. [cited 2012 Jul 30]. Available from:
[3] E31 Committee. Specification for Continuity of Care Record (CCR) [Internet]. ASTM International; 2006.
Available from:
[4] ISO Technical Committee 215: Health informatics, Working Group 1: Health Records and Modelling
Coordination. ISO 13606 - Health informatics-Electronic health record communication. ISO; Report No.: ISO
[5] Kalra D, Beale T, Heard S. The openEHR Foundation. Stud Health Technol Inform. 2005;115:15373.
[6] DICOM Homepage [Internet]. [cited 2012 Jul 30]. Available from:
[7] ISO Technical Committee 215: Health informatics, Working Group 1: Health Records and Modelling
Coordination. ISO TR 20514 - Electronic Health Record Definition, Scope and Context. ISO; 2005 Jan. Report
No.: ISO TR 20514.
[8] Lewalle P, Rodrigues JM, Zanstra P, Ustun B, Kalra D, Surjan G, et al. A deployment and Research Roadmap for
Semantic Interoperability: the EU semantic health project. Stud Health Technol Inform. 2009;136:63540.
[9] Atalag K, Paton C, Kingsford D, Warren J. Putting Health Record Interoperability Standards to Work. electronic
Journal of Health Informatics [Internet]. 2010;5(1). Available from:
[10] Rozenblum R, Jang Y, Zimlichman E, Salzberg C, Tamblyn M, Buckeridge D, et al. A qualitative study of
Canada’s experience with the implementation of electronic health information technology. CMAJ. 2011 Mar
[11] Johnson CW. Identifying common problems in the acquisition and deployment of large-scale, safetycritical,
software projects in the US and UK healthcare systems. Safety Science. 2011 Jun;49(5):73545.
[12] Kaplan B, Harris-Salamone KD. Health IT Success and Failure: Recommendations from Literature and an AMIA
Workshop. J Am Med Inform Assoc. 2009;16(3):2919.
[13] Schoen C, Osborn R, Doty MM, Squires D, Peugh J, Applebaum S. A survey of primary care physicians in eleven
countries, 2009: perspectives on care, costs, and experiences. Health Aff (Millwood). 2009 Dec;28(6):w1171
[14] Gray BH, Bowden T, Johansen I, Koch S. Electronic health records: an international perspective on ‘meaningful
use’. Issue Brief (Commonw Fund). 2011 Nov;28:1–18.
[15] Metzger M-H, Durand T, Lallich S, Salamon R, Castets P. The use of regional platforms for managing electronic
health records for the production of regional public health indicators in France. BMC Med Inform Decis Mak.
[16] MOH Holdings Pte Ltd | Homepage [Internet]. [cited 2012 Jul 30]. Available from:
[17] Takemura T, Araki K, Arita K, Suzuki T, Okamoto K, Kume N, et al. Development of Fundamental Infrastructure
for Nationwide EHR in Japan. Journal of Medical Systems. 2012;36(4):22138.
[18] Han SH, Lee MH, Kim SG, Jeong JY, Lee BN, Choi MS, et al. Implementation of Medical Information Exchange
System Based on EHR Standard. Healthc Inform Res. 2010 Dec;16(4):2819.
[19] PCEHR Standards - [Internet]. [cited 2012 Jul 30]. Available from:
[20] Protti D, Bowden T, Johansen I. Adoption of information technology in primary care physician offices in New
Zealand and Denmark, Part 3: Medical record environment comparisons. Inform Prim Care. 2008;16(4):28590.
[21] National Health IT Plan 2010 [Internet]. National Health IT Board; Available from:
[22] Interoperability Reference Architecture [Internet]. National Health IT Board; 2012. Available from:
[23] Health Information Exchange Architecture Building Blocks [Internet]. National Health IT Board; [cited 2012 Jul
30]. Available from:
[24] Atalag K, Yang HY, Tempero E, Warren J. Model Driven Development of Clinical Information Sytems using
openEHR. Stud Health Technol Inform. 2011;169:84953.
[25] Goossen W, Goossen-Baremans A, van der Zel M. Detailed Clinical Models: A Review. Healthc Inform Res.
[26] Beale T. Archetypes: Constraint-based domain models for future-proof information systems. Eleventh OOPSLA
Workshop on Behavioral Semantics: Serving the Customer. Seattle, Washington, USA: Northeastern University;
2002. p. 1632.
[27] Oosterwijk H. Introduction to IHE. International Congress Series. 2004 Jun;1268:925.
[28] Clinical Knowledge Manager [Internet]. [cited 2012 Jul 30]. Available from:
[29] Nehta Precription DCM [Internet]. Nehta; [cited 2012 Jul 30]. Available from:
[30] European Commission. EHR-Impact -The socio-economic impact of interoperable EHR and ePrescribing systems
in Europe and beyond. 2009. Report No.: Final study report.
[31] HL7. Fast Healthcare Interoperability Resources (FHIR) [Internet]. [cited 2012 Aug 2]. Available from:
[32] Nate Osit. Twitter / NateOsit: @omowizard @openehr Wow, those ... [Internet]. [cited 2012 Jul 31]. Available
... The standardization efforts in syntax include HL7 v3 CDA R2 [26], European Committee for Standardization (CEN)/International Organization for Standardization (ISO) 13606 [50], and open-EHR [51,52]. The choice of which standard to use mainly depends on the recommendations provided in each single country [53]. For example, in 2010, the Italian Healthcare Ministry produced national guidelines for the Italian institutional EHR and recommended the adoption of HL7 v3 CDA R2 [54]. ...
Full-text available
The eSource Data Interchange Group, part of the Clinical Data Interchange Standards Consortium, proposed five scenarios to guide stakeholders in the development of solutions for the capture of eSource data. The fifth scenario was subdivided into four tiers to adapt the functionality of electronic health records to support clinical research. In order to develop a system belonging to the “Interoperable” Tier, the authors decided to adopt the service-oriented architecture paradigm to support technical interoperability, Health Level Seven Version 3 messages combined with LOINC (Logical Observation Identifiers Names and Codes) vocabulary to ensure semantic interoperability, and Healthcare Services Specification Project standards to provide process interoperability. The developed architecture enhances the integration between patient-care practice and medical research, allowing clinical data sharing between two hospital information systems and four clinical data management systems/clinical registries. The core is formed by a set of standardized cloud services connected through standardized interfaces, involving client applications. The system was approved by a medical staff, since it reduces the workload for the management of clinical trials. Although this architecture can realize the “Interoperable” Tier, the current solution actually covers the “Connected” Tier, due to local hospital policy restrictions.
... Use of information models for representing complex clinical concepts fostering data consistency and interoperability is well accepted and underpins the New Zealand Interoperability Reference Architecture and is defined as an interim HISO standard (14). This comprehensive modelling study further validated that it is possible to faithfully represent all ANZACS-QI datasets using openEHR by substantial amount of reuse of existing international validated Archetypes. ...
Conference Paper
Full-text available
In this paper we describe a standards based information modelling study conducted for the national cardiac registry: ANZACS-QI. The aim was to support data management processes and especially for meta-data management. We have used the openEHR method to faithfully represent three datasets with 91 Archetypes and have exploited the Annotations feature of the specifications and tooling to add project specific meta-data. This study builds on the previous modelling work done for PREDICT dataset in the primary care from the same research programme (VIEW). Current document based data dictionaries and spreadsheet based business and validation rules were expressed successfully together with the data definitions as single-source. We expect this work will improve the data quality of the Registry by providing consistency during its evolution and better communication among the Project team. In line with the National Interoperability Reference Architecture this work can result in a high degree of semantic interoperability with other Sector datasets and information systems.
... This is an end-to-end implementation of openEHR specifications -from modelling of the Registry dataset to the development of the front-end web-based application and the back-end clinical data repository. This international standard underpins our national Interoperability Reference Architecture (13) and is the depicted standard for establishing a reference library of common clinical concept definitions (14). At the heart of openEHR lies the Archetype paradigm which is a way of constructing information models by means of putting together and configuring building blocks defined in a common reference model (RM). ...
Conference Paper
Full-text available
Gestational diabetes has implications for both mother and child with risk of complications during pregnancy, and type 2 diabetes later in life. This paper presents the initial lessons learned from the development of a clinical registry. The aims of the Registry are: 1) 100% successful diabetes screening within 3 months of delivery; 2) Annual type 2 diabetes screening; 3) Early warning in subsequent pregnancies. We have employed the openEHR standard which underpins our national interoperability reference architecture to represent the dataset and also to build the web-based registry system. Use of this rigorous methodology to tackle health information is expected to ensure semantic consistency of Registry data and maximise interoperability with other Sector projects. The development work has been facilitated by the ability to transform the dataset automatically into software code – ensuring clinical requirements accurately translated into technical terms. Dataset has been finalised, registry system has been developed and deployed for pilot implementation. Data entry is underway for participants after consenting. This registry is expected to increase the screening of women leading to earlier detection of diabetes. It should provide a valuable picture of the condition and is intended for extension and wider roll-out after evaluation.
... This middle-out approach is defined in New Zealand's Interoperability Reference Architecture (IRA) [12] underpinned by the openEHR formalism. This provides a canonical model for representing health information and a framework for authoring and governing Archetypes and other related artefacts (terminology subsets and openEHR Templates) enabled by the web based Clinical Knowledge Manager (CKM) [13]. ...
This chapter describes a middle-out approach to eHealth interoperability, with strong oversight on public health and health research, enabled by a uniform and shared content model to which all health information exchange conforms. As described in New Zealand's Interoperability Reference Architecture, the content model borrows its top level organization from the Continuity of Care Record (CCR) standard and is underpinned by the openEHR formalism. This provides a canonical model for representing a variety of clinical information, and serves as reference when determining payload in health information exchange. The main premise of this approach is that since all exchanged data conforms to the same model, interoperability of clinical information can readily be achieved. Use of Archetypes ensures preservation of clinical context which is critical for secondary use. The content model is envisaged to grow incrementally by adding new or specialised archetypes as finer details are needed in real projects. The consistency and long term viability of this approach critically depends on effective governance which requires new models of collaboration, decision making and appropriate tooling to support the process.
Conference Paper
Full-text available
Most information systems today are built using "single-level" methodologies, in which both informational and knowledge concepts are built into one level of object and data models. In domains characterised by complexity, large numbers of concepts, and/or a high rate of defini- tional change, systems based on such models are expensive to maintain and usually have to be replaced after a few years. However, a two-level methodology is possible, in which systems are built from information models only, and driven at runtime by knowledge-level concept definitions, or "archetypes". In this approach, systems can be built more quickly and last longer, whilst archetypes are authored directly by domain specialists, rather than IT personnel. Executed properly, the approach has the potential for creating future-proof systems and infor- mation. Work in the medical informatics domain on electronic health records (EHRs) has shown that a two-level methodology is implementable, makes for smaller systems, and empowers domain users.
Full-text available
In France, recent developments in healthcare system organization have aimed at strengthening decision-making and action in public health at the regional level. Firstly, the 2004 Public Health Act, by setting 100 national and regional public health targets, introduced an evaluative approach to public health programs at the national and regional levels. Meanwhile, the implementation of regional platforms for managing electronic health records (EHRs) has also been under assessment to coordinate the deployment of this important instrument of care within each geographic area. In this context, the development and implementation of a regional approach to epidemiological data extracted from EHRs are an opportunity that must be seized as soon as possible. Our article addresses certain design and organizational aspects so that the technical requirements for such use are integrated into regional platforms in France. The article will base itself on organization of the Rhône-Alpes regional health platform. Different tools being deployed in France allow us to consider the potential of these regional platforms for epidemiology and public health (implementation of a national health identification number and a national information system interoperability framework). The deployment of the Rhône-Alpes regional health platform began in the 2000s in France. By August 2011, 2.6 million patients were identified in this platform. A new development step is emerging because regional decision-makers need to measure healthcare efficiency. To pool heterogeneous information contained in various independent databases, the format, norm and content of the metadata have been defined. Two types of databases will be created according to the nature of the data processed, one for extracting structured data, and the second for extracting non-structured and de-identified free-text documents. Regional platforms for managing EHRs could constitute an important data source for epidemiological surveillance in the context of epidemic alerts, but also in monitoring a number of indicators of infectious and chronic diseases for which no data are yet available in France.
Full-text available
Research has shown that the United States lags many other countries in the adoption of electronic health records (EHRs). The U.S. has now embarked on a major effort to achieve "meaningful use" of health information technology by clinicians and hospitals. This issue brief describes the extent of meaningful use in three countries with very high levels of health information technology adoption—Denmark, New Zealand, and Sweden. While all three have achieved high levels of meaningful use, none has reached 100 percent in all categories. The brief find[sic] high levels of meaningful use for EHR items and substantial information-sharing with other organizations or health authorities, although less information is shared with patients. Insights that may prove useful to the United States include providing economic incentives to encourage adoption and designating an organization to take responsibility for standardization and interoperability.
Full-text available
openEHR and the recent international standard (ISO 13606) defined a model driven software development methodology for health information systems. However there is little evidence in the literature describing implementation; especially for desktop clinical applications. This paper presents an implementation pathway using .Net/C# technology for Microsoft Windows desktop platforms. An endoscopy reporting application driven by openEHR Archetypes and Templates has been developed. A set of novel GUI directives has been defined and presented which guides the automatic graphical user interface generator to render widgets properly. We also reveal the development steps and important design decisions; from modelling to the final software product. This might provide guidance for other developers and form evidence required for the adoption of these standards for vendors and national programs alike.
Full-text available
To develop effective ways of sharing patients' medical information, we developed a new medical information exchange system (MIES) based on a registry server, which enabled us to exchange different types of data generated by various systems. To assure that patient's medical information can be effectively exchanged under different system environments, we adopted the standardized data transfer methods and terminologies suggested by the Center for Interoperable Electronic Healthcare Record (CIEHR) of Korea in order to guarantee interoperability. Regarding information security, MIES followed the security guidelines suggested by the CIEHR of Korea. This study aimed to develop essential security systems for the implementation of online services, such as encryption of communication, server security, database security, protection against hacking, contents, and network security. The registry server managed information exchange as well as the registration information of the clinical document architecture (CDA) documents, and the CDA Transfer Server was used to locate and transmit the proper CDA document from the relevant repository. The CDA viewer showed the CDA documents via connection with the information systems of related hospitals. This research chooses transfer items and defines document standards that follow CDA standards, such that exchange of CDA documents between different systems became possible through ebXML. The proposed MIES was designed as an independent central registry server model in order to guarantee the essential security of patients' medical information.
Full-text available
Due to the increasing use of electronic patient records and other health care information technology, we see an increase in requests to utilize these data. A highly level of standardization is required during the gathering of these data in the clinical context in order to use it for analyses. Detailed Clinical Models (DCM) have been created toward this purpose and several initiatives have been implemented in various parts of the world to create standardized models. This paper presents a review of DCM. Two types of analyses are presented; one comparing DCM against health care information architectures and a second bottom up approach from concept analysis to representation. In addition core parts of the draft ISO standard 13972 on DCM are used such as clinician involvement, data element specification, modeling, meta information, and repository and governance. SIX INITIATIVES WERE SELECTED: Intermountain Healthcare, 13606/OpenEHR Archetypes, Clinical Templates, Clinical Contents Models, Health Level 7 templates, and Dutch Detailed Clinical Models. Each model selected was reviewed for their overall development, involvement of clinicians, use of data types, code bindings, expressing semantics, modeling, meta information, use of repository and governance. Using both a top down and bottom up approach to comparison reveals many commonalties and differences between initiatives. Important differences include the use of or lack of a reference model and expressiveness of models. Applying clinical data element standards facilitates the use of conceptual DCM models in different technical representations.
Full-text available
This paper provides a snapshot of the current interoperability standards landscape and investigates how different standards are adopted in different jurisdictions. The aim is to provide useful insights for decision makers by looking from a wider angle to include political, social and business drivers rather than taking a purely technical approach. Semantic interoperability, which is a major bottleneck to achieving eHealth systemic interoperability, is dependent on terminology, content and messaging standards. In particular, the architectural aspects of content and messaging standards seem to be critical and currently the subject of many heated debates. A considerable amount of effort into international harmonisation is underway and evidence shows that it may be possible to use different standards and yet still be able to accomplish semantic interoperability. It is recommended that a careful analysis be performed to seek evidence, rather than relying on hearsay, for determining how each standard fulfils certain requirements depending on the context. An environmental scan and literature survey highlights the fact that making a good choice of standards depends on what outcomes are desired, and usually involves selection of a number of different standards to be applied together. It is to be noted that, non-technical aspects of standards, such as acceptance, feasibility of implementation or availability of expertise, are as important, and determine what is achievable. The paper concludes by presenting a number of options which include combinations of standards and also provides insights for the evaluation and selection process.
Full-text available
The movement of create medical information systems that is now taking place involves both progress in EMR (Electronic Medical Records)-computerization of records at hospitals and clinics, and also in EHR (Electronic Health Records) in which information is shared with individual regions. However, the geographical coming and going of people in modern society is extremely active. Naturally the places these people move to are not necessarily within the same region. For this reason, even if the basic unit for the health care supply system is in practical terms limited to the local level, if services are restricted to only one region, many persons may be unable to receive the benefits of health care cooperation. In this study, we constructed a mechanism for a medical cooperation system which links the EHR systems of individual regions and is able to create a one-patient, one-record system on the national level. In this paper, we will provide a report of this mechanism and of the 4-year operational trial.
Public and private organisations are investing increasing amounts into the development of healthcare software. These applications are perceived to offer numerous benefits. Software systems can improve the exchange of information between healthcare facilities. They support standardized procedures that can help to increase consistency between different service providers. Electronic patient records ensure minimum standards across the trajectory of care when patients move between different specializations. Healthcare information systems also offer economic benefits through efficiency savings; for example by providing the data that helps to identify potential bottlenecks in the provision and administration of care. However, a number of high-profile failures reveal the safety concerns that arise when staff must cope with the loss of these applications. In particular, teams have to retrieve paper based records that often lack the detail of electronic systems. Individuals who have only used electronic information systems face particular problems in learning how to apply paper-based fallbacks. The following pages compare two different failures of healthcare information systems in the UK and North America. The intention is to ensure that future initiatives to extend the integration of electronic patient records will build on the ‘lessons learned’ from previous systems.