Underpinnings of the Interoperability Reference Architecture

Abstract

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.

Full text

Underpinnings of the Interoperability Reference Architecture
Koray Atalag
National Institute for Health Innovation (NIHI),
The University of Auckland
Tamaki Campus, Auckland 1142, New Zealand
k.atalag@nihi.auckland.ac.nz
Alastair Kenworthy
Ministry of Health
Wellington, New Zealand
alastair_kenworthy@moh.govt.nz
David Hay
Orion Health
Auckland, New Zealand
david.hay@orionhealth.com
Abstract
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
certification.
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
Map
Source to
ECM
Map
ECM to
Recipient
Message
Payload
(CDA)
Exchange
Data
Object
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
(CKM)
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: http://www.hln.com/assets/pdf/Coming-to-Terms-
February-2007.pdf
[2] Health Level Seven International - Homepage [Internet]. [cited 2012 Jul 30]. Available from: http://www.hl7.org/
[3] E31 Committee. Specification for Continuity of Care Record (CCR) [Internet]. ASTM International; 2006.
Available from: http://enterprise.astm.org/filtrexx40.cgi?+REDLINE_PAGES/E2369.htm
[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
13606.
[5] Kalra D, Beale T, Heard S. The openEHR Foundation. Stud Health Technol Inform. 2005;115:153–73.
[6] DICOM Homepage [Internet]. [cited 2012 Jul 30]. Available from: http://medical.nema.org/
[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:635–40.
[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:
http://www.ejhi.net/ojs/index.php/ejhi/article/view/5%281%29%3Ae1
[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
22;183(5):E281–288.
[11] Johnson CW. Identifying common problems in the acquisition and deployment of large-scale, safety–critical,
software projects in the US and UK healthcare systems. Safety Science. 2011 Jun;49(5):735–45.
[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):291–9.
[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–
1183.

[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.
2012;12:28.
[16] MOH Holdings Pte Ltd | Homepage [Internet]. [cited 2012 Jul 30]. Available from: http://www.mohh.com.sg/
[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):2213–8.
[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):281–9.
[19] PCEHR Standards - nehta.gov.au [Internet]. [cited 2012 Jul 30]. Available from: http://www.nehta.gov.au/ehealth-
implementation/pcehr-standards
[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):285–90.
[21] National Health IT Plan 2010 [Internet]. National Health IT Board; Available from:
http://www.ithealthboard.health.nz/sites/all/files/National%20Health%20IT%20Plan%20v11_1.pdf
[22] Interoperability Reference Architecture [Internet]. National Health IT Board; 2012. Available from:
http://www.ithealthboard.health.nz/sites/all/files/Interoperability%20Reference%20Architecture%20v%201.0.pdf
[23] Health Information Exchange Architecture Building Blocks [Internet]. National Health IT Board; [cited 2012 Jul
30]. Available from: http://www.ithealthboard.health.nz/content/health-information-exchange-architecture-
building-blocks
[24] Atalag K, Yang HY, Tempero E, Warren J. Model Driven Development of Clinical Information Sytems using
openEHR. Stud Health Technol Inform. 2011;169:849–53.
[25] Goossen W, Goossen-Baremans A, van der Zel M. Detailed Clinical Models: A Review. Healthc Inform Res.
2010;16(4):201.
[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. 16–32.
[27] Oosterwijk H. Introduction to IHE. International Congress Series. 2004 Jun;1268:92–5.
[28] Clinical Knowledge Manager [Internet]. [cited 2012 Jul 30]. Available from: http://www.openehr.org/knowledge/
[29] Nehta Precription DCM [Internet]. Nehta; [cited 2012 Jul 30]. Available from:
http://dcm.nehta.org.au/ckm/OKM.html#showTemplate_1013.26.6_1
[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:
http://www.hl7.org/implement/standards/fhir/
[32] Nate Osit. Twitter / NateOsit: @omowizard @openehr Wow, those ... [Internet]. [cited 2012 Jul 31]. Available
from: https://twitter.com/NateOsit/statuses/189330807477907456