Healthcare: openEHR’s potential to handle Complexity & Diversity

Healthcare: openEHR’s potential to handle complexity & diversity

We have noted that healthcare is a complex system that is particularly  information-intensive. We have noted that healthcare reform requires clinical leadership, process improvement and effective health IT.

In noting that healthcare IT has had mixed success to date, we have identified the important need to support the greater alignment of process improvements with information systems.

While aware that the current health IT industry has some way to go, the conclusion reached in exploring this challenge to date is the international requirement for an open, generic-process-oriented health- information service-oriented-architecture standard.

As I have already introduced the openEHR specification (the result of many years of European and Australian R&D) as the leading candidate solution to this need, let me now briefly explain its key parts in a little more detail.. which can be conceptualised in 4 key layers…

At the core of the openEHR specification is the reference information model that is immediately  recognisably as linked to the generic processes of healthcare.
Within the openEHR specification those processes are named as Observation, Evaluation, Instruction and Action. (This generic process nomenclature fits with any generic process analysis I have seen to date and I might further suggest that the approach taken may have utility in other domains.).
This clinical process oriented foundation is key to the value of openEHR, setting it aside from all other international health IT standards and provides the useful basis of components that are then built on top..

At a layer above the reference model in the openEHR “stack”, openEHR offers the archetype, now an EU and ISO standard en13606, currently being explored by eHealth programmes in the UK, Sweden, Singapore amongst others..
The archetype can be explained to clinicians as a maximal dataset/common structure for common clinical concepts eg Pulse, Blood Pressure etc that relate to the key core generic process patterns that are seen amidst the complexity of healthcare.
While there is one reference model, the number of draft archetypes internationally available today number in the hundreds. The openEHR Foundation has made an openEHR Clinical Knowledge Manager available online as a means to harnessing a growing online community who are overseeing and furthering the development of key archetypes, as per “wikinomics” and the rest of the Web 2.0 revolution.
To clinical staff archetypes can be explained as clinical “Lego bricks” as they should therefore be developed with reuse in mind.
In process terms, archetypes relate to the logical layer in our earlier look at process analysis..
In software engineering terms they can be understood as reusable objects within an object oriented software library that the clinical end users help to co-author.

While the archetypes should be understood as maximal datasets that can be reused by many/all clinical specialties, it is at the template level that the balance between international standardisation and local flexibility is struck.
The template mechanism allows a national/region/hospital/department/individual clinician to reuse standardised archetypes, while composing the template and constraining the archetypes in order to meet the requirements of their specific template requirement..
Candidate templates might include Emergency Discharge Summary, Asthma Pathway, etc.
While archetypes may number in the hundreds, one can easily imagine thousands/tens of thousands of template requirements in the diverse ecosystem of healthcare.
To clinical staff, templates can be explained as those “Lego toys” that can be rebuilt in an infinite number of ways from the underpinning bricks.
In process terms, templates relate to the physical process layer in our aforementioned look at process analysis.
In software engineering terms templates can be understood as close to the applications that can be derived from reusable object oriented libraries.

This “2 level modelling” between archetypes and templates are key to openEHR and I believe are the key to both handling the deep complexity, wide diversity and ongoing evolution of healthcare systems.

At the top of the openEHR stack, templates can be transformed into a User Interface (UI) layer.
There may be room for debate on how much variation there should be at the UI layer in an ideal healthcare information system platform.
If you accept the patient safety arguments made by the NHS CfH Common User Interface team, then you could argue  there should be a consistency transformation between an openEHR template and the related UI layer, thereby ensuring a consistent approach to navigation, data review, data entry etc..
However from a health IT vendor perspective you may want to offer an choice of e UI on top of the openEHR archetypes and templates…

In my opinion these 4 key layers of openEHR specification (i.e. reference model/archetype/template/UI) offer key elements that healthcare now requires of a open service oriented architecture standard.

In offering this open specification, openEHR offers a foundation which should offer;
-fit with clinical process
-reuse of clinically related component parts
-balance between international standardisation and local flexibility
-basis to support cross organisational workflow required of patient centred care pathways.
-basis for integration of healthcare information and knowledge management via effective linkage between the electronic health record and decision support…
thereby the potential (and holy grail) of semantic interoperability in healthcare.

Having explained the important elements of the openEHR specification, let me now make a case for greater collaboration between openEHR and the other key players in the health IT standards field.

Aside from the key requirements around a clinical process oriented health record architecture standards, there is a case to be made for other important related standards.

If archetypes provide a common specification for building healthcare information systems, then the key elements of the language used within that information system may also benefit from standardisation.
The International Health Terminology Standards Development Organisation (IHTSDO) offers an international standard terminology (i.e. SNOMED CT), while the  and the World Health Organisation offers the International Classifications of Diseases (e.g. ICD 10) as important medical vocabulary standards that are also important to note.
While neither offer the 4 layer stack and the 2 level modelling on offer with archetypes-templates… it is clear that archetypes and templates need to leverage the important added value of terminologies and classifications and indeed should be developed with that alignment in mind..

Beyond the need for standard and reusable components (e.g. archetypes/templates with terminology subsets etc) within systems , there is of course a requirement for a standard mechanism to exchange related information between healthcare systems. Health Level 7 (HL7) is the key player in this space internationally, having developed the widely used HL7 v2 messaging standard and then the more recent and more complicated v3 standard. The HL7 Clinical Document Architecture as an important messaging standard that appears well suited to the interchange of structures messages between healthcare systems (while flexible about the clinical content within) and is one of several important and valuable standards that HL7 offers health IT developers as health reform moves forward.
By standardising the messages between systems rather than the underpinning health information platform, the approach of HL7 to date has understandably been to accommodate the diversity of proprietary health information architectures within the current market.
This approach has provided (and continues to provide) significant value by facilitating the sharing of information between healthcare systems, yet without either a process oriented SOA or the complex-systems-ready two-level-modelling that openEHR archetypes and templates offer, my view is that the current HL7 standards alone are not enough to address the complex and diverse needs of healthcare reform.
The Integrating the Health Enterprise also offer standards for information sharing, with an emphasis on the logistics of sharing specific elements of the health record such as patient identification and document sharing, while also remaining agnostic about the foundational architecture of clinical information systems.

While I have attempted to expound the inherent value and potential of the openEHR specification in healthcare, it is my view that none of the health IT standards outlined can thrive and add value in isolation.

Healthcare reform now requires both collaboration between those key international health IT standards bodies and ongoing innovation from those tackling healthcare improvement efforts at the frontline.

As we conclude our exploration of openEHR and its potential to handle the complexity and diversity of healthcare, we now move onto explore one means to unite both international standards and local innovation efforts.. and the growth of open source efforts which may support international healthcare reform.


Beale, T, Heard, S “An Ontology-based Model of Clinical Information”

Proceedings MedInfo 2007, K. Kuhn et al. (Eds), IOS Publishing 2007.

Health Level 7

Hovenga, E(2008) “Importance Of Achieving Semantic Interoperability For. National Health Information System”

Click to access 18.pdf

Integrating the Health Enterprise

International Health Terminology Standards Development Organisation (ITHSDO)

Kalra, D (2002) “Clinical Foundations and Information Architecture for the Implementation of a Federated Health Record Service”

openEHR Foundation

openEHR Clinical Knowledge Manager

Tapscott D, Williams A D (2006) “Wikinomics: How Mass Collaboration Changes Everything”



  1. Hi Tony,
    Good read. Why is the role of HL7 FHIR not mentioned? I fully understand this protocol has not been approved yet.

    • Fair question, at the time of writing HL7 FHIR was not on the horizon. Mind you the issues remain the same as I see it, as FHIR being promoted as a interchange API format rather than a means to build a standards based Services Oriented EHR Architecture.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: