Journey to interoperability I

Despite some wins, the transition to EHRs has generally been much slower than we anticipated, much harder than we imagined, and it is not hard to argue that interoperability of granular health data remains frustratingly elusive.

Bridging the interop chasms

True or false: if we want to achieve any degree of semantic interoperability in our clinical systems we need to standardise the clinical content, keeping it open and independent of any single implementation or messaging formalism?

"We have the capability!"

We have had the technology for a purpose-built openEHR-compliant 'plug & play' platform for some time; standalone applications have been built, but just recently it appears that the practical reality of an multi-application platform is also about to happen. "We have the technology. We have the capability..." Stay tuned.

...Reminds me of my 1970's hero, Steve Austin, the Six Million Dollar Man. With apologies to Steve:

"We have the technology. We have the capability to make the world's first universal health platform. openEHR will be that platform. Better than ever before. Robust health data...application independent...semantically interoperable!"


Preserving health data integrity

How valuable do we really think health data is? How seriously do we take our responsibility to preserve the integrity of our health data? Probably not nearly as much as we should.

Consider the current situation of most clinicians or organisations when purchasing a clinical EHR system. What do they look for? Many possible answers are obvious, but there is one question that I suspect very few are asking. How many consider what data they will be able to export and convert to another format, preserving the current data integrity, at the end of the typical 5-10 year life span of the application? Am I wrong if I suggest it is not many at all?

Despite all the effort that we clinicians put into entering detailed data to create a quality health record we don't seem to often consider the " What next?" scenario. How much and precisely what data will we be able to safely extract, export, transfer or convert into the next, inevitable, clinical system? Ironically, we are simultaneously well aware that clinical systems have a limited technical life span.

Any and all of the health data in a health record is an incredibly valuable asset to the holder, to the patient (if these are not the same entities) and to those downstream with whom we may share it in the future - in terms of $$ invested; manpower resources used to capture, store, classify, update and maintain it; and not least the future value that comes from appropriate and safe clinical decisions being made upon the integrity of existing EHR data.

Yet we don't seem to consider it much... yet. However, as more clinicians are creating increasing amounts of isolated pockets of health data, we should be thinking about it very hard.

Every time we change systems we put our health data at risk - risk of absolute data loss and risk of possible corruption during the conversion. The integrity of health data cannot be guaranteed each time it is ported into a new system because current methods always require some kind of intervention - mapping, transformations, tweaking, 'cleaning', etc. Small errors can creep in with each data manipulation and which over time, can compromise the safety and value of our health data. On principle we know that the data should not be manipulated, but being limited by our traditional approach to siloed EHR applications, we have previously had little choice.

We need to change our approach and preserve the integrity of our health data at all costs. After all it is the only reason why we record any facts or activity in an electronic health record  - so we can use the data for direct patient care; share & exchange the data; aggregate and analyse the data, and use the data as the basis for clinical decision support.

We should not be focused on the application alone.

Apps will come and go, but we want our health data to persist - accurate and safe for clinical use - beyond the life span of any one clinical software application.

I've said this before, but it's worth saying many times over:

It's. all. about. the. data.

One of the key benefits of the openEHR paradigm is that the data specifications (the archetypes) are defined independently of any specific clinical system or application; are based on an open EHR architecture specification; and are publicly available in repositories such as the Clinical Knowledge Manager. It means that any data that is captured according to the archetype specification is directly usable by any and all archetype-compliant systems. Plus the data is no longer hard-wired into a proprietary application so that it is orders of magnitude easier to accurately share or transfer health data than it has before.

Clinical system vendors that don't directly embrace the archetype-technology may still 'archetype-aware', and can choose to use the archetype specifications as a means to understand the meaning of existing archetyped data and integrate it appropriately into their systems. Similarly they can map from their non-openEHR systems to the archetype specifications as a standardised method for data export and exchange.

The openEHR paradigm enables potential for archetype-compliant systems to share the same archetyped data repository - along the lines of an Apple platform 'plug & play' approach, with applications being added, removed or updated to suit the needs of the end-users, while the data persists intact. No more data conversions needed.

Adapted from Martin van der Meer, 2009

Now that's good news for our health data.

To HIMSS12... or bust!

This blog, and hopefully some others following, will be about my thinking and considerations as I man an exhibition booth at the huge HIMSS12 conference for the first time next month… Well, we’ve committed. We’re bringing some of the key Ocean offerings all across the ocean to HIMSS12 in Las Vegas next month. If it was just another conference, I wouldn’t be writing about it. But this is a seriously daunting prospect for me. I’ve presented papers, organised workshops, and run conference booths in many places over the years – in Sarajevo, Göteborg, Stockholm, Capetown, Singapore, London, Brisbane, Sydney, Melbourne – but this is sooooooo different!

The equivalent conference here in Australia would gather 600-800 delegates, maybe 40-50 exhibition booths. Most European conferences seem to be a similar size, admittedly these are probably with a more academic emphasis, rather than such a strong commercial bent, which might explain some of the size difference. By comparison, last year’s HIMSS conference had 31,500 attendees and over 1000 exhibition booths – no incorrect zeros here - just mega huge!

I can’t even begin to imagine how one can accommodate so many people in one location. I have never even visited HIMSS before – we are relying heavily on second hand reports. You may start to understand my ‘deer in headlights’ sensation as we plan our first approach to the US market in this way.

Ocean's profile is much higher elsewhere internationally. Our activity in the London-based openEHR Foundation and our products/consulting skills have a reasonable profile in Australia and throughout much of Europe; and awareness is growing in Brazil as the first major region in South America. In many ways the US is the one of the last places for openEHR to make a significant impression – there are some pockets of understanding, but the limited uptake is clearly an orthogonal approach to the major commercial drivers in the US at present, however we are observing that this is slowly changing... hence our decision to run the gauntlet!

openEHR’s key objective is creation of a shareable, lifelong health record - the concept of an application-independent, multilingual, universal health record. The specification is founded upon the the notion of a health record as a collection of actual health information, in contrast to the common idea that a health record is an application-focused EHR or EMR. In the openEHR environment the emphasis is on the capture, storage, exchange and re-use of application-independent data based on shared definitions of clinical content – the archetypes and templates, bound to terminology. In openEHR we call them archetypes; in ISO, similar constructs are referred to as DCMs; and, most recently, there are the new models proposed by the CIMI initiative. It’s still all about the data!

So, we’re planning to showcase two products that have been designed and built to contribute to an openEHR-based health record - the Clinical Knowledge Manager (CKM), as the collective resource for the standardised clinical content, and OceanEHR, which provides the technical and medico-legal foundation for any openEHR-based health record – the EHR repository, health application platform and terminology services. In addition, we’ll be demonstrating Multiprac – an infection control system that uses the openEHR models and is built upon the OceanEHR foundation. So Multiprac is one of the first of a new generation of health record applications which share common clinical content.

This will be interesting experience as neither are probably the sort of product typical attendees will be looking for when visiting the HIMSS exhibition. So therein lies one of our major challenges – how to get in touch with the right market segment… on a budget!

We are seeking to engage with like-minded individuals or organisations who prioritise the health data itself and, in particular, those seeking to use shared and clinically verified definitions of data as a common means to:

  • record and exchange health information;
  • simplify aggregation of data and comparative analysis; and
  • support knowledge-based activities.

These will likely be national health IT programs; jurisdictions; research institutions; secondary users of data; EHR application developers; and of course the clinicians who would like to participate in the archetype development process.

So far I have in my arsenal:

  • The usual on-site marketing approach:
    • a booth - 13342
    • company and product-related material on the HIMSS Online Buyers Guide; and
    • marketing material – we have some plans for a simple flyer, with a mildly Australian flavour;
  • Leverage our website, of course;
  • Developing a Twitter plan for @oceaninfo specifically with activity in my @omowizard account to support it, and anticipating for some support from @openEHR – this will be a new strategy for me;
  • And I’m working on development of a vaguely ‘secret weapon’ – well, hopefully my idea will add a little ‘viral’ something to the mix.

So all in all, this will definitely be learning exercise of exponential proportions.

To those of you who have done this before, I’m very keen to receive any insight or advice at this point. What suggestions do you have to assist a small non-US based company with non-mainstream products make an impact at HIMSS?

Why the buzz about CIMI?

With the recent public statement from the Clinical Information Modelling Initiative (CIMI) my cynical heart feels a little flutter of excitement. Maybe, just maybe, we are on the brink of a significant disruption in eHealth. Personally I have found that the concept of standardising clinical content to be compelling and hence my choice to become involved in development of archetypes. During my openEHR journey over the past 5 or so years it has been very interesting to watch the changing attitudes internationally - from curiosity and 'odd one out'  through to "well, maybe there's something in this after all".

And now we have the CIMI announcement...

So what has been achieved? What should we celebrate and why?

At worst, we have had a line drawn in the sand: a prominent group of thought leaders in the international health informatics domain have gathered and, through a somewhat feisty process, recognised that a collaborative approach to the development of a single logical clinical content representation (the CIMI core reference model) is a desirable basis for interoperability across formalisms. Despite most of the participants having significant investment and loyalty to their own current methodology and flavor of clinical models, they have cast aside the usual 'not invented here' shackle and identified a common approach to an initial modelling formalism from which other models will be derived or developed. Whether any common clinical content models are eventually built or not, naming of ADL 1.5 and the openEHR constraint model as the initial formalism is a significant recognition of the longstanding work of the openEHR Foundation team - the early specifications emerged nearly 20 years ago.

At its idealistic best, it potentially opens up a new chapter for health informatics, one that deviates from the relatively safe path of incremental innovation that we have followed for so many years - the reliance on messages/documents/hubs to enable us to exchange health information. There is an opportunity to take a divergent path, a potentially transformational innovation, where the focus is on the data itself, and the message/document/EHR becomes more simply just the receptacle or vehicle for the data. It could give us a very real opportunity to store lifelong health information; simplify data exchange (whether by messages or documents), aggregation, querying and analysis; and support knowledge-based activities such as decision support - all because we will (hopefully) have non-proprietary, common, agreed and fully defined models of clinical content and known transformations between each formalism.

Progress during the next few months will be telling. In January 2012, immediately before the next HL7 meeting in San Antonio, the group will gather again to discuss next steps.

There is a very real risk that despite best intentions all of this will fade away to nothing. The list of participating organisations, including high profile standards organisations and national eHealth programs, is a veritable Who's Who of international health IT royalty, so they will all come with their own (organisational and individual) work experience, existing modelling resources, hope, enthusiasm, cynicism, political agendas, bias and alliances. It could be enough to sink the work of this fledgling group.

But many are battle-weary, having been trudging down this eHealth path for a long time - some now gradually realising that the glacial incremental innovation is not delivering the long-term sustainable answers required for creating 21st Century EHRs as they had once hoped. So maybe this could be the trigger to make CIMI fly!

I think that CIMI is a very bright spark on the health IT horizon. Let's hope that with the right management and governance it can be agilely nurtured into a major positive force for change. And in the future, when its governance is mature and processes robust, we can integrate CIMI into the formal standards processes.

Best of luck, CIMI. We're watching!

Unambiguous data: Positive presence; positive absence

The bulk of openEHR archetype modelling is focused on how to record the positive presence of data – for example the diagnosis of diabetes or asthma, or orders for long-term beta blocker medication. When it is not possible to determine data values – the nature of clinical medicine being not so exact a science – 'null flavours' are used to mark an 'incapacity to obtain data', especially for a mandatory data point. The current openEHR null flavours are:

  • no information - "No information provided; nothing can be inferred as to the reason why, including whether there might be a possible applicable value or not";
  • unknown – "A possible value exists but is not provided";
  • masked – "The value has not been provided due to privacy settings"; and
  • not applicable – "No valid value exists for this data item".

If there is no data recorded at all, nor any null flavour, no conclusion can safely be drawn from the lack of data; there is a void in our knowledge.

And then there is the need to record things that are noticeably not present. Some approaches subscribe the notion of 'negation' – resulting in a somewhat awkward and potentially ambiguous statement that might go something along the lines of 'diagnosis of diabetes, not', potentially sitting closely alongside another selectable term of 'diagnosis of diabetes'. You can see that it is easy to get it wrong.

The openEHR preferred approach is to record the positive absence of data – an explicit and unambiguous statement of 'no history of diabetes' in an archetype with the explicit intent to record the absence of a diagnosis.

Specific absence of data needs to be recorded positively, where this is sensible:

  • To encourage unambiguous clinical records;
  • Assisting clinical decision support; and sometimes (unfortunately)
  • For medico-legal purposes.

Examples of global positive exclusion statements include:

  • No known adverse reactions
  • No surgical history
  • No significant family history
  • Not currently taking any medicines

Specific positive exclusion statements include:

  • No known allergy to penicillin (or <insert drug/plant/food/venom or other substance here>);
  • No family history of bowel cancer (or <insert diagnosis here>);
  • Not currently taking immunosuppressants (or); or
  • No pacemaker in situ.

Keep in mind that exclusion statements are only meaningful and relevant at the decision-making moment at which they are recorded. They have a fleeting temporal validity, and then the question has to be asked again – "Are you allergic to anything?"or "Have you ever had any serious illness or operations?".

Some examples:

  • Recording an absence of an adverse reaction event to penicillin becomes immediately obsolete when the patient suffers an anaphylactic reaction to the penicillin subsequently administered; or
  • The past history might reveal no previous diagnosis of asthma, yet asthma might be the cause for today's wheeze; or
  • In a Discharge Summary – 'Not currently taking any medications' is a vital piece of information for the patient's usual GP, yet that drug-free state might only be current until the first follow-up visit.

So exclusions cannot be relied upon for any future decision-making. They are just 'in the moment' statements that need to be re-asked and regularly updated in records (both paper and electronic) as part of routine clinical practise.

So while they may be valuable, does that mean we desire to model every possible negative statement positively? This is certainly not desirable, nor is it helpful. A pragmatic approach is to research those situations where explicitly modelling exclusion statements provide some obvious value; preferably those that will have consistent re-use or may be utilised in knowledge-based activities such as Clinical Decision Support (CDS) systems.

Improved outcomes may result if CDS systems prompt for the recording a positive statement of:

  • 'no known adverse reactions' prior to prescribing medicines; or
  • 'no history of asthma' prior to prescribing beta blockers.

Currently we have archetypes for recording the presence of an Adverse Reaction, a Problem/Diagnosis, Family History and Medicines. In addition we have a generic parent archetype for Exclusion (ie the positive absence) plus specialisations for Adverse Reaction, Medication, Family History and Problem/Diagnosis exclusions so far.  The generic Exclusion archetype can be used as a standardised way to record the more uncommon statements – 'Not (currently) pregnant' might be a candidate here. But if there are regular use cases identified, these too may warrant their own explicit archetypes to ensure that positive absence is recorded consistently and safely.

Making sense of 'Severity'

'Severity' is a pretty simple clinical concept, isn't it? I thought so too until I first sat down to create a single, re-usable archetype to represent 'Severity'. I soon discovered that I had significantly underestimated it - the challenge was greater than appeared at first glance.

The archetype development process is usually relatively straight forward - a brain dump of all related information into a mind map, followed by rearranging the mind map until sensible patterns emerge. They usually do, but not this time.

However, the more I investigated and researched, the more I could see that clinicians express severity in a variety of ways, sometimes mixing and 'munging' various concepts together in such a way that humans can easily make sense of it, but it is much harder to represent in a way that is both clinically sensible and computable.

The simple trio of 'Mild', 'Moderate' and 'Severe' is commonly used as a gradation to express the severity of a condition, injury or adverse event. Occasionally these are defined for a given condition or injury, however most often these are subjective and there should be concern that one clinician's mild might be another's moderate. Some also include intermediate terms, such as 'Mild-to-moderate' and 'Moderate-to-severe', but one has to begin to be concerned if these more subtle differences make the judgement even more unreliable, especially if we need to exchange information between systems.

Others add 'Trivial' – is this less than 'Mild'? By how much? Is there a true gradation here? And what of 'Extreme'? Still others add 'Life-threatening' and 'Death' – but are these really expressing severity? Or are they expressing clinical impact or even an outcome?

When exploring severity I found examples of severity expressed by clinicians in many ways. This list is by no means exhaustive:

  • Pain – expressed as intensity, often including a visual analogue scale as a means to record it ie rate from 0-10
  • Burns – describing percentage of body involved e.g. >80% burns
  • Burns – describing the depth of burn by degree e.g. first degree
  • Perineal tears – describe the extent and damage by degree – e.g. second degree tear
  • Facial tic – expressed in using frequency e.g. occasional through to unrelenting
  • Cancer – expressed as a grade, clinical or pathological
  • Rash – extent or percentage of a limb or torso covered.
  • Minor or major
  • Mild, disabling life-threatening
  • Relative severity – better, worse etc
  • Functional impact – ordinary activity, slight limitation, marked limitation, inability to perform any physical activity
  • Short or long term persistence
  • Acute or chronic

In practice, clinicians can work interchangeably with any of these expressions and make reasonable clinical sense of it. The challenge when creating archetypes, and other computable models, is to ensure that clinicians can express what they need in a health record, exchange that information safely with other clinicians, allow for knowledge-based activities such as decision support.

In addition, there also needs to be a clear distinction between 'severity' and other, related qualifiers that provide additional context about 'seriousness' of the condition, injury or adverse reaction. These sometimes get thrown into the mix as well, including:

  • Clinical impact (or significance);
  • Clinical treatment required; and
  • Outcomes.

Clinical impact/significance might include:

  • None - No clinical effect observed
  • Insignificant - Little noticeable clinical effect observed.
  • Significant - Obvious clinical effect observed
  • Life-threatening - Life-threatening effect observed
  • Death – Individual died.

Immediate clinical treatment required might include:

  • No treatment
  • Required clinician consultation
  • Required hospitalisation
  • Required Intensive Care Unit

Outcomes might include:

  • Recovered/resolved
  • Recovering/resolving
  • Not recovered/resolved
  • Fatal

Then there are those that recovered or the condition resolved but there were other sequelae such as congenital anomalies in an unborn child...

Severity ain't simple.

Over time, and repeatedly returning to it when modelling it in various archetypes including Adverse Reaction and Problem/Diagnosis, I've come to the conclusion that I don't think it is useful or helpful for us to model 'severity' in a single, re-usable archetype. It seems to work better as a single qualifier element within archetypes – then we can bind it in to terminology value sets that are useful for that specific archetype concept and for the use-case context.

When a clinical knowledge pattern is easily identified, creating an archetype is easy - the archetype almost writes itself! So over time I've learned not to try to force the modelling. Some archetypes 'work'; some, like this one, just don't.

Anatomy of an archetype

With this blog I want to establish a simple baseline statement or overview about openEHR archetypes, aggregated from other posts and publications – a reference point if you like – from which we can journey further and in more detail into the issues around clinical modelling using specific archetypes. Archetypes are a strong basis for data liquidity. Create the archetype once, agree through peer-review, re-use when and where required – the foundation for a 'universal health record'.


Formal Definition

An archetype is a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model. openEHR archetypes are based on the openEHR reference model. Archetypes are all expressed in the same formalism. In general, they are defined for wide re-use, however, they can be specialized to include local particularities. They can accommodate any number of natural languages and terminologies. [Archetype Definitions and Principles]

Clinician's 'lay' definition:

An archetype is a structured, computable specification for one single, discrete clinical concept. - much simpler!

Each archetype is a rich health data specification, defined and agreed by the clinicians themselves to ensure that each model is 'fit for clinical purpose'. Collectively these archetypes together can create an electronic health record 'lingua franca', or an example of PCAST report's 'Universal Exchange Language (although archetypes are not limited only to exchange of health information).

Archetypes can be used to model a range of clinical concepts:


Archetypes are:

  • Potential 'agents for change' – allowing knowledge-driven EHRs as an orthogonal approach to EHR development.
  • The basis for a coherent and consistent approach for the whole continuum of clinical care and related activities:
    • Recording, storing and querying health information in electronic health information;
    • Exchanging health information - the broader the agreement & governance, the greater the potential for interoperability;
    • Data aggregation;
    • Knowledge-based activities; and
    • Comparative data analysis.

Using archetypes requires:

  • A change of mindset – no longer silos of data; no longer message and document driven.
  • Upfront planning & coordination in development of archetypes, but not necessarily more time
    • To ensure the quality of clinical data in our EHRs
    • To warrant the clinical data is safe & 'fit for purpose'


Each archetype is designed:

  • As a maximal data set effectively everything one can think of about a clinical concept in all situations by the consumer and any and all providers. This design intent is pragmatically constrained to be sensible in some situations, however good archetype design will always ensure that the full model can be achieved through nesting of additional archetypes to create the maximal dataset/universal use-case ideal.
  • For the 'universal use-case' – for re-use in any and all scenarios, from use at home, to primary care, community care, hospital care, secondary use and for research.

Each archetype needs to represent the variety of data that is required to represent the information required for all aspects of clinical care and related activities, including:

  • The ability to capture both free-text vs structured data;
  • Normal statements such as "Nil significant" or "NAD";
  • Graphable data;
  • Images – eg a homunculus, or a surgical diagram;
  • Multimedia including photos, video and audio or an ECG wave format;
  • Questionnaires, checklists etc

Think about how the clinician may record the data: different clinicians will need differing approaches to recording their health information and the models need to allow for this clinical diversity. Some will prefer to use more free text and others more structure; some need more detail than others; we need to capture current requirements for recording and exchange while keeping in mind what might be best practice in the near and distant future.

The best designers, without a doubt, have a clinical background. I have seen clinicians and non-clinicians given identical clinical content, but the archetypes produces are surprisingly different. Clinician modellers definitely model their domain better than those who are not familiar with clinical practice. They are perhaps better able to envision the fractal nature of medicine and take that in to account in creating archetypes, especially the complex areas which require nesting of archetypes within each other to capture the depth and richness required in the models.

Integration with terminologies such as SNOMED, ICD or LOINC are strategic and important – the structure of an archetype is not enough to represent clinical information adequately, and similarly terminology alone is inadequate. However the combination of terminology within an archetype structure, by naming elements or provision of value sets, is semantically very powerful. There is still considerable work to be done to determine how to represent the information overlap – that which can be expressed either in the archetype structure itself or via terminology. This remains a 'grey zone' and is a pressing area for collaboration or research.

Archetype classes – support clinician's processes

There are four main categories of archetypes that are useful to understand – each corresponding to classes in the openEHR Reference Model.

1.  Compositions – which correspond to commonly used clinical documents, such as 'antenatal visit' or 'care plan'. 2.  Sections – these are effectively used to assist with human navigation within EHRs and correspond to document headings, for example 'antenatal examination' or 'summary'.

3.  Entries – these are the most common and are fundamental building blocks of EHRs. There are four main types of Entry archetypes:

  • Observations – recording measurable or observable data e.g. blood pressure, symptoms or weight;
  • Evaluations – recording clinically interpreted findings e.g. adverse event, diagnosis or assessment of risk;
  • Instructions – recording the initiation of a workflow process, such as a medication order or referral;
  • Actions – recording clinical activities e.g. procedure or medication administration. Actions complement the instruction and can record the ensuing state of the instruction, such as 'completed' or 'cancelled'.

4. Clusters

Lifecycle & Governance

The Clinical Knowledge Manager (CKM) – - is an international, online clinical knowledge repository under the auspice of the openEHR Foundation that provides:

  • Access to a library of cohesive archetypes and related knowledge artefacts;
  • Peer review, life cycle management & publication process via a Web 2.0 approach for clinical content, terminology binding, terminology reference set binding and translations;
  • Clinical Knowledge governance underpinned by a digital asset management system and providing:
    • Provenance, audit trails, validation checking
    • Release sets for implementation

Archetypes are freely available under a Creative Commons license.


The need for EHRs to be able to represent clinical diversity is absolutely underrated. Existing EHR systems corral clinicians into certain types of recording etc, but for safety we need more diverse ways for clinicians to record what they need for patient care, and also to ensure that what is exchanged is appropriate for the patient and their individual circumstances. A 'one size fits all' document approach to emergency summaries or messages can be potentially unsafe. Elderly, pregnancy, chronic disease, paediatrics are extremely common examples where there are specific additional requirements needed to summary data sets

Templates are computable specifications for a specific clinical scenario or use-case. The openEHR paradigm takes the governed and agreed archetypes from CKM and creates clinically useful specifications that can be implemented in systems by:

  • Aggregating the necessary archetypes together; and
  • Constraining the maximal dataset archetypes so that only relevant data elements are active.

Examples include all clinical content required for a specific Message, Document, Clinical consultation or Report e.g. a histopathology report, a referral, an antenatal visit or a discharge summary.

In this way we can, in colloquial terms, 'have our cake and eat it too'. At the same time, CKM ensures tight clinical knowledge governance, yet templates allow for expression of clinician diversity.


Archetypes provide a 'glide path' to knowledge-level interoperability of health information. They can:

  • Bootstrap new application development – a source of agreed clinical content, avoid re-inventing the wheel for each vendor, organisation or project;
  • Provide a forward 'roadmap' for existing applications – supporting gradual transition from proprietary silos to common data representations, perhaps via mapping to common messages as an interim step;
  • Support data integration – the means to migrate valuable silos of legacy data to a common, re-usable representation
  • Enable data aggregation & comparative analysis – the basis for ensuring 'apples' are 'apples', not 'oranges';
  • Simplify messaging – keep message content consistent with EHR content;
  • Enable knowledge-based activities eg Clinical Decision Support Systems – consistent & coherent; create once, re-use in all systems.

Don’t re-invent the (clinical content) wheel...

It was with great interest that I read about the the recommendation for a universal exchange language in the recent release of the US report to the President: REALIZING THE FULL POTENTIAL OF HEALTH INFORMATION TECHNOLOGY TO IMPROVE HEALTHCARE FOR AMERICANS: THE PATH FORWARD. I had asked the Direct project about the existence of a national plan for standardising clinical content only recently... It appeared that here was a plan after all.

So, to the report. The approach and benefits proposed started well...

The best way to achieve a national health IT ecosystem is to ensure that all electronic health systems can exchange data in a universal exchange language. The systems themselves could be designed in any manner desired — they could accommodate legacy systems that prevail or new recordkeeping systems and formats. The only requirement would be that the systems be able to send and receive data in the universal exchange language. (p41)

I have previously blogged about a universal health record underpinned by an application independent library of clinical content definitions, so the intent and benefits are well aligned with my preferred approach.

But then alarm bells started to ring....

Because of its multiple advantages, we advocate a universal exchange mechanism for health IT that is based on tagged data elements in an extensible markup language. If there were another equally good solution, it should also be considered; we have collectively been unable to think of one. (p43)

Issue #1: Isn't it more appropriate for step one to identify the need for standardised clinical content as a policy, rather than specify the format up front? Isn't that really the domain of health informatics experts as part of a subsequent work plan? I feel like we've skipped a couple of steps in the decision-making process. And are they really advocating the creation of this metadata-tagged XML from a zero starting point?

Issue #2: The last 9 words of that paragraph, "...we have collectively been unable to think of one." I'm glad that they are still open to equally good solutions being considered as indeed there are many ways that individuals, groups and organisations are exploring how to standardise clinical content definitions as the basis for a universal exchange mechanism.

In ISO TC 215, the International Standards Organisations Technical Committee for Health Informatics, there is a new work item which has been evolving for at least 2 years, although yet to attain committee draft status, known as ISO 13972 - Quality criteria for detailed clinical models. This work item is targeting a new international standard for determining quality criteria about the development of detailed clinical models - all clinical models, pick your flavour! In the world of international standards it has been recognised for years that with the plethora of different approaches to developing clinical models for EHRs, there is a need for some criteria to support quality aspect in their development. This work is being led by modellers from the Netherlands, with experts participating from the Australian, Danish, German, Swedish, US and Canadian standards organisations. Creating clinical content is definitely not a new field of endeavour by the time it enters the international standards arena.

So, I am extremely surprised that this expert PCAST group have not been able to 'collectively think' of an existing alternative.

In my last blog - Clinical Knowledge Governance in a Web 2.0 world – I pointed to a number of approaches to standardised clinical content to support health information exchange.

1. In the US – including, but by no means limited to:

  • the HL7 standards organisation - where my UK colleague, Charlie McKay, informs me that there are more than 20 different approaches to clinical content development. Keith Boone (@motorcycle_guy) has posted his response to the PCAST report from a HL7 point of view - The Language of HealthIT;
  • Stan Huff's group at Intermountain Health in Utah have had extensive experience in defining standardised clinical content across all of Intermountain's systems – they are leading experts in this domain; and
  • I understand Don Mon and his team from AHIMA have also been working in this area.

2. In Europe, and Australia:

In addition, a few more points...

Firstly, the focus of the PCAST report is still only on data exchange, not on ensuring a sound foundation of a person-centric electronic health record. I'll say it again... get the data right and then the data will be able to be re-used, to multitask, be liquid, flowing to where it needs to be. It will become the solid foundation on which to build lifelong health records, simpler health information exchange, data integration & aggregation, research, reporting and knowledge-based activities. By focusing on exchange alone, then... you'll hopefully be able to exchange well and the rest will be considerably more uncertain.

Secondly, the proposed variant of XML is described as a 'straightforward' and 'superior' solution (p44), and the assumption that it will be scalable, protected by encryption, and that data element access services will be enough to support the health information exchange required. By contrast HL7, ISO/CEN 13606 and openEHR have taken decades to develop and refine underlying reference models to ensure that they have an unambiguous, consistent, secure way to represent personal health information – so you know who created the data, who is the subject of care, what the data means, what are the access rules applicable etc. In the openEHR environment, the specification authors developed Archetype Definition Language (ADL) for the purpose - and now part of the ISO 13606 standard - because the alternatives such as standard XML were not robust enough to represent health information. A 'straightforward' XML approach has a strong possibility of failure without a RM underpinning it.

And finally, there is the area of clinical knowledge governance itself. Health is dynamic, complex and diverse. The work required to represent healthcare as computable clinical content definitions or specifications is huge – don't underestimate the sheer volume of work that will be required. It is not realistic to expect a 'rapid mapping' of existing proprietary data structures into tagged data elements. Who will decide the clinical content in the models? If there are over 7000 clinical vendors in the US, which will be 'the source' or sources? Which are 'correct' or 'authoritative'? What methodology will be used to create the models? What level of granularity for each clinical element? How will they be aggregated together to represent clinical documents or events, and constrained to be useful for the clinical purpose? I have a million more questions...

Once the information models are defined, there will be a need for them to be validated before they can become the basis for a standardised or national clinical content library – suitable for consumers, clinicians, organisations, vendors, researchers and jurisdictions. A requirement will be recognised for life-cycle management and publication of these models, roadmaps for legacy data to migrate towards, and harmonise with, the new national health information 'source of truth', plus ongoing maintenance and governance.

Eric Browne stated in his recent blog, Recasting e-Health in the USA:

The work in Sweden, the UK, Singapore and even Australia, based on openEHR or ISO 13606 archetypes (i.e. implementable renditions of Detailed Clinical Models) is far more advanced and promising than that offered by the PCAST approach.

openEHR, which is my interest, has an approach to defining, agreeing and governing clinical content models for electronic health records, known as archetypes. It has taken more than 18 years to develop the openEHR technical specifications, and the last 10 years to achieve its' current approach and position in terms of clinical modelling. It is gaining traction, albeit with a modest volunteer community, especially now that it has a collaborative portal, known as the Clinical Knowledge Manager, to support sharing or models, reviews of clinical content, translation and terminology binding, and model governance.

Standardising health information definitions for health records or exchange is not a trivial task. Learn from what has already been achieved – all shapes, flavours and doctrines. Whatever you do, don't reinvent the wheel and create yet another universal language!

Clinician-led eHealth records - a knowledge-enabled approach

My presentation given to W.H.O. in Geneva last week... [slideshare id=5492832&doc=20101008whoclinician-ledehealthrecords-101019133425-phpapp02]

An orthogonal question...

Just askin'. Just curious... What single eHealth activity, process or solution now available could:

  • Ensure that EHR data is safe and ‘fit for clinical purpose’;
  • Support data integration, data aggregation & comparative analysis;
  • Simplify and support messaging and data exchange;
  • Enable co-ordinated knowledge-based activities; and
  • Provide a clear transition path for existing EHR applications towards common data representations. there's a list that covers a broad range of eHealth, including may of our current, collective headaches, doesn't it!

The main thrust of the question is one that doesn't get asked very often, as it is  orthogonal to our more common application- and messaging-driven approaches.  It focuses on the most important part of any eHealth activities, yet it remains largely ignored - the quality and re-use of health information. Liquid data. Shareable data.

My opinion is that we need a clinical knowledge repository of common and agreed data definitions - that much should be clear from my other posts.

What other alternatives do you think can provide a solution in this knowledge space? How will we fill these needs?

Archetypes: the ‘glide path’ to knowledge-enabled interoperability

In a world where connectivity is the universal aspiration, our health information is largely still caught up in silos and, in the main, is not accessible to those who need it – patients, clinicians, researchers, epidemiologists and planners. Shared electronic health records (EHRs) are increasingly needed to support the improvement of health outcomes by providing a timely, comprehensive and coordinated foundation for provision of healthcare. For decades people have been attempting to share health information, but the incremental approach has not been wholly successful – progress has been made, but despite enormous investment and resources, the solution has been found to be more difficult than most anticipated; many well-funded attempts have been stunningly unsuccessful. Healthcare provision appears not to fit the model that has been so successful in other domains such as banking or financial services. Why has sharing health information been so difficult? After all, on the surface, data are, simply, data.

Why is the health information domain different?

Health information is the most multifaceted and largest knowledge domains to try to represent in a computer. The SNOMED CT terminology alone has over 450,000 terms expressing health-related concepts, and our collective knowledge about health is far broader, deeper and richer than that required to represent financial systems. The added bonus in health is that our information domain is dynamic - growing and changing as our understanding increases.

Recording, communicating and making sense of health information is something that clinicians do remarkably well in a localised, non-digital world. However the human cognitive processes and assumptions that underpin the traditional health records do not easily translate into the computerised environment. Consider the need for narrative versus structured data; the complexity of clinical statements; use of the same data in a variety of clinical contexts; the need for clinicians to make ‘normal’ or ‘nil significant’ statements, and also the oft underrated positive statements of absence; and the need for graphs, images or multimedia in a good health record. Grassroots clinicians have different personal preferences for creating their clinical records and to support their requirements for direct provision of clinical care and communication to colleagues. In parallel, jurisdictions have different expectations of the grassroots clinical data collection that will support reporting, data aggregation and secondary use of data.

Throw into this mix the complex and convoluted processes required to support healthcare provision; mobile patient populations; and the need for lifelong health records, and it starts to become easier to understand why eHealth has been more of a challenge that many first thought.

Information-driven EHRs

Traditional approaches to the development of EHRs have been software application-driven, hard-coding clinical knowledge into the proprietary data model for each software system and resulting in silos of health information locked away in proprietary databases. This is valuable data, and even more valuable if we can get access to it, exchange it and utilise it. Key stakeholders – patients, clinicians, researchers, planners and jurisdictions – are currently disempowered and are not easily able influence or express their data requirements. We have mistaken the software application for the electronic health record - a classic example of the ‘tail wagging the dog’.

If we focus on the electronic health record being the data, we turn the traditional paradigm upside down. Our EHRs become information-driven by putting the stakeholders at the centre to direct the information content and quality aspects of our EHR systems. It is only then that our systems will be able to reflect the real requirements of stakeholders, ensuring that health information collected data is ‘fit for use’ and will support personal health records, clinician health records and, with appropriate authorisation and permissions, the broadest range of secondary use.

Sharing health information requires common and coherent health information definitions or models – ensuring that health information can be expressed in a way that is meaningful to stakeholders AND that computers can process it. According to Walker et al , Level 4 interoperability, or ‘machine interpretable data’, comprises both structured messages and standardised content/coded data. In practice, it means that data can be transmitted and viewed by clinical systems without need for further interpretation or translation. This semantic, or knowledge-level, interoperability is absolutely required for truly shareable health records, data aggregation, knowledge-based activities such as clinical decision support, and to support comparative analysis of health data. Further, it is only when this health information model is agreed at a local, regional, national or international level, that true semantic interoperability can occur at each of these levels. The broader the level of clinical content model agreement, the broader the potential for semantic health information exchange.

The openEHR paradigm

openEHR is a purpose-built, open source, information-driven electronic health record architecture focused on ensuring that the grassroots health information is recorded clearly, coherently and unambiguously in EHRs, and supporting re-use in other contexts where appropriate. It adopts an orthogonal approach to EHRs - a dual-level modelling methodology with clear separation of the technical from the clinical domains, where software engineers focus on their application development and the clinical domain experts focus on the health information definitions. openEHR focuses on the data - using computable knowledge artefacts known as archetypes and templates to formally express health information.

openEHR archetypes are computable definitions created by the clinical domain experts for each single discrete clinical concept – a maximal (rather than minimum) data-set designed for all use-cases and all stakeholders. For example, one archetype can describe all data, methods and situations required to capture a blood sugar measurement from a glucometer at home, during a clinical consultation, or when having a glucose tolerance test or challenge at the laboratory. Other archetypes enable us to record the details about a diagnosis or to order a medication. Each archetype is built to a ‘design once, re-use over and over again’ principle and, most important, the archetype outputs are structured and fully computable representations of the health information. They can be linked to clinical terminologies such as SNOMED-CT, allowing clinicians to document the health information unambiguously to support direct patient care. The maximal data-set notion underpinning archetypes ensures that data conforming to an archetype can be re-used in all related use-cases – from direct provision of clinical care through to a range of secondary uses.

Templates are used in openEHR to aggregate all the archetypes that are required for a particular clinical scenario – for example a consultation or a report. These can also be shared, preventing more ‘wheel re-invention’. Individual content elements of each maximal archetype can be ‘disabled’ in the template so that the only data elements presented to the clinician are those that conform to national or local requirements and are relevant and appropriate for that use-case scenario. For example, a typical Discharge Summary may commonly comprise 10 common archetypes; templates allow the orthopaedic surgeon to express a slightly different ‘flavour’ of the Discharge Summary based on which elements of each archetype being either active or disabled, compared to that required by a Obstetrician who needs to share information about both mother and newborn. One ‘size’, or document, does not fit all. The archetypes, as building blocks, are the key to semantic interoperability; while templates allow flexible expression of the archetypes to fulfill use-case requirements.

How achievable is this? Only ten archetypes are needed to share core clinical information that could save a life in an emergency or provide the majority of content for a discharge summary or a referral. If each archetype takes an average of six review rounds to reach clinician consensus and each review round is open for 2 weeks, it is possible to obtain consensus within an average of three months per archetype – some complex or abstract ones may be longer; other simpler, more concrete archetypes will be shorter. Many archetypes are already well developed in the international arena and within national programs. As archetype reviews can be run in parallel, a willing community of clinicians could achieve consensus for core clinical EHR content within three to six months.

It is estimated that as few as fifty archetypes will comprise the core clinical content for a primary care EHR, and maybe only up to two thousand archetypes for a hospital EHR system including many clinical specialties. The initial core clinical content will be common to all clinical disciplines and can be re-used by other specialist colleges and interested groups. More specialised archetypes will gradually and progressively be added to enhance the core archetype pool over time.

The openEHR Clinical Knowledge Manager (CKM) is an online clinical knowledge management tool – - which provides a repository for archetypes and other clinical knowledge artefacts, such as terminology subsets and document templates. Based on a data asset management platform it provides a clinical knowledge ecosystem supporting the publication lifecycle and governance of the archetypes. Within CKM, a community of grassroots clinicians and health informaticians collaborate in online reviews of each archetype until consensus is reached and the agreed archetype content is published. Clinicians and other domain experts need no technical knowledge to engage with archetypes - the technical aspects of archetypes are kept hidden ‘under the bonnet’ – but they use their expertise to ensure that the content definitions within each archetype is correct and appropriate. Each content review is conducted online at a time of convenience to the clinician and usually only takes five to ten minutes for each participant. Thus the clinical domain experts themselves drive the archetype content definitions, and CKM has become a peer-reviewed knowledge resource for all parties seeking shared, standardised and computable health information models.

At the time of writing CKM has acquired, largely by word of mouth, 565 registered users from 62 countries, including 181 people who have volunteered to review archetypes, and 73 who have volunteered to translate archetypes. The repository contains 273 archetypes, of which 15 have content that are in team review and 9 published. Two example templates have been uploaded, and we await final publication of the openEHR template specification before we expect to see template activity increase. Terminology subset functionality has been added only recently and our first terminology subsets uploaded. So, while CKM is still relatively new, its Web2.0 approach to artifact collaboration and publishing, combined with formal knowledge artifact governance positions CKM as a pioneering ‘one stop shop’ for clinical knowledge resources online.

Current CKM functionality includes:

  • Display of artefacts including structured views, technical representations and mind maps to make it easy for clinicians and others to review;
  • Uploading of new knowledge artefacts – archetypes, templates and terminology subsets – for review and publication;
  • Archetype metadata supporting classification, ontological relationships and repository-wide searches;
  • Digital asset management including provenance and artefact audit trail;
  • Integration with openEHR tools supporting quality assessment & technical validation checks;
  • Review and publication process for clinical content – draft, team review, published and reassess states
  • Terminology binding and terminology subset reviews;
  • Online archetype translation with review;
  • Community engagement via threaded discussions, repository downloads, attached resources, watch lists, email notifications, user dashboards and release sets;,
  • Editorial support via To Do lists, user and team administration, review management, artefact modification, classification management, broadcast emails etc;
  • Subscriber auto-notification including Twitter and email
  • Reports – Archetypes, Templates and Registered users

A governed repository of shared and agreed archetypes will provide a ‘glide path’ towards full semantic interoperability of health information; a clear forward path for standardisation of data definitions. These will bootstrap new application or program development, provide a ‘road map’ to support gradual transition of existing systems to common data representation and provide the means to integrate valuable silos of legacy data.

Benefits of a collaborative, data-driven approach

A collaborative and domain expert-led approach to our health information provides many benefits which include the following.

Benefits for stakeholders

  • Active involvement of domain experts to ensure the safety and quality of health information.
  • Development of a coherent set of health information definitions:
    • Improved data quality – shared core clinical content plus specialised domain-specific content will be agreed and ratified by the domain expert community; health information created will need to conform to the agreed archetype specifications.
    • Improved data ‘liquidity’ – specifications to support exchange, flow and re-use of health information - from direct patient care through to secondary use of data. Improved data longevity – shared non-proprietary health information definitions minimise need for data transformations or system migration and the inherent risk of data loss; will support the cumulative, lifelong health records and longitudinal data repositories;
    • Improved data availability – easier integration of health information from disparate sources when based on common archetype definitions;
    • Re-use, integrate and aggregate data for supporting quality processes such as clinical audit, reporting and research; and
    • Break down the existing ‘silos’ of health information based on proprietary and varied definitions.
  • Online collaboration maximises the potential for a breadth of grassroots stakeholder engagement in ensuring correctness of the health information definitions.
  • Active participation by clinical domain experts to shape and influence their EHRs, ensuring that EHR content is ‘fit for clinical purpose’.
  • Online participation in clinical content review will be of short duration and at times of convenience to the clinician, avoiding the significant time and opportunity cost of attendance at face-to-face meetings.

Benefits for patients

  • Data created and stored in a shared, standardised and non-proprietary representation supports the potential for application-independent data records that can persist for the life of the patient.
  • Improved data ‘liquidity’ – so that data can flow between healthcare providers and systems to where the patient needs it.

Benefits for national programs and other jurisdictions

  • Development of a coherent national set of clinical content specifications to support the shared EHR programs, health information exchange and secondary use.
  • Enables national governance of foundation clinical content while at the same time facilitates flexible expression of local domain requirements
  • Efficient use of sparse clinical, informatics and stakeholder resources:
    • Design & create an archetype once; re-use many times;
    • Leveraging existing clinical specification work done internationally to improve local national pool of archetypes;
    • Online collaboration maximise the potential for stakeholder engagement at the same time as minimising the requirement for expensive face-to-face meetings; and
    • Review and publication of agreed clinical specification definitions within weeks to months;
    • Review and standardisation of clinical documents containing agreed archetypes will be relatively short.
  • • Clinical knowledge management ecosystem:
    • Single national repository of clinical knowledge artefacts, including archetypes and terminology subsets.
    • Focussed and coordinated knowledge management environment where all stakeholders can observe, participate and benefit; the opposite of the current fragmented, isolated and proprietary approach to defining health information content.
    • Digital knowledge asset management:
      • Manages authoring, reviewing, publication and update lifecycle of all knowledge assets;
      • Provenance and asset audit trails;
      • Ensures asset compliance to quality criteria;
      • Ensures technical validation of assets; and
      • Development of coherent release sets for implementers;
    • Governance of knowledge assets.
    • Distribution of knowledge assets via coherent release sets.
  • Removes the need for per message or per document negotiation between application developers, organisations and jurisdictions each time information needs to be integrated or exchanged by use of the standardised content within more generic message wrappers or document structures.
  • Transparency of editorial and publishing processes; accountability to the domain expert community itself.
  • Precludes the need for ratification of clinical or reporting documents through a traditional standards process when they consist of subsets of the nationally agreed archetypes.

Benefits for application developers

  • Download coherent sets of clinical content definitions from a published and agreed national repository – not re-inventing the wheel by defining each piece of health information over and over.
  • Software development remains focused within the expert technical domain – user interface; workflow processes; security, data capture, storage, retrieval and querying; etc.
  • Removes the need for per message or per document negotiation between vendors, organisations and jurisdictions each time information needs to be integrated or exchanged by use of the standardised content within more generic message wrappers or document structures.

Benefits for secondary users of data

  • Existing data can be mapped to archetypes once only, and transformed into a validated and consistent format; new data can be captured and aggregated according to the same national archetype definitions.
  • Data stored in a common representation can be more easily aggregated and integrated.
  • Access to valuable legacy data that would otherwise be unavailable.

Agreed and shared representations of the health information, embracing existing stakeholder requirements and developed rapidly by an active online community, will kick-start and accelerate many currently fragmented eHealth activities. Sharing archetypes as the definition of our health information will not only provide a common basis for recording and exchanging health information but also simplify data aggregation of data, support knowledge-based activities and comparative data analysis. Perhaps even more compelling, we are making certain that our domain experts warrant that the data within our EHRs, and flowing between stakeholders, is safe and 'fit for purpose'.

Gimme an… uhr?

What do we have? You can have all the messages, connect-a-thons and profiles that you like - certainly you will achieve short- to medium-term connectivity wins but it is not enough. It is not sustainable and clinicians want and need to share relevant data when it is needed. Predetermined messages and documents will be a great start, but it's not enough.

You can invest huge resources in terminology - we definitely need it - but terminology in isolation is also not enough.

You can demand all the 'damn data' that you want, but non-standardised data will still largely not be computable - largely limited to read-only access.

What do we want?

We hear talk about:

  • shared electronic health records;
  • semantic interoperability; and
  • health data liquidity.

Essentially these phrases describe different aspects of the same 'elephant in the room'; just using different jargon...

We expect our healthcare professionals to be able to safely exchange important health information. To have the right health information available at the right place at the right time. To prevent us repeating our health histories ad nauseum. In fact a huge percentage of patients assume that we can already do this! But we can't... yet. Shared health records are not easy.

What do we need?

A single data-driven "universal health record", an uhr! And please note the deliberate lack of capitals.

What on earth is an uhr, I hear you quite reasonably ask...? A uhr is simply a non-proprietary pool of standardised health data which can be used for any purpose we want - PHR, EHR, EMR, SEHR, IEHR, research, epidemiology, reporting & stats, shared care, clinical decision support & more. There is no particular EHR application associated with it; in fact it works with any and every software program, vendor and healthcare provider.

The key (and I say it yet again)... it's. all. about. the. data.

In addition, and supported by:

  • Collaboration at international, national, jurisdictional or organisation level to share and re-use the clinical data definitions, so that our health information can similarly be shared.
  • Clinicians driving the clinical content definitions - reflecting the information they need for recording health care for themselves and their patients, ensuring that EHRs are 'fit for purpose'. Terminology integrated with these structured clinical content definitions to unambiguously define the building blocks of the health record.

As a result:

  • Message structures required for data exchange become more about the wrapper and less about content - much easier to negotiate and maintain.
  • Vendors no longer have clinicians locked-in to proprietary data silos
  • Tools used to do 'clever stuff' with our data need only to be built once to conform to these agreed clinical data definitions - think decision support, reporting, data repositories, and integration. Now that takes away a lot of the barriers we strive to overcome!
  • Data in a common format can be exchanged between systems - data liquidity becomes a reality, flowing to where it is needed and according to authorisation and access permissions.

Gimme a universal health record. Gimme my damn, um,... uhr, and let my data flow...

And so,  I archetype;-)

openEHR - the World’s Record

I wrote this overview of openEHR way back in 2007, and it was published in PulseIT (Sydney, Australia) [Internet], pp50-55, Issue 6, November 2007. The online publisher has removed access to it, so I've posted it here.

The principles remain unchanged.  I've updated some links, and indicated some minor parts that are a little out-of-date. My previous posts, What on earth is openEHR & Connect with openEHR provide up-to-date stats and links.

In a world where connectivity reigns, our health information is largely still caught up in silos and, in the main, is not shareable by clinicians.  Shared electronic health records (SEHRs) are increasingly needed to provide timely, comprehensive and coordinated healthcare.  Over many years there have been ongoing and thorough attempts to achieve the sharing of health information in order to support the improvement of health outcomes, but this incremental approach, gradually building on previous experience, has not been wholly successful.  Progress has been made, but despite enormous investment and resources, the solution has been more difficult than most ever anticipated.  Healthcare provision does not seem to fit into the same kind of data sharing model as has been successful in other domains such as banking or financial services.

In order to support interoperability of health information SEHRs need clinical content to be standardised.  This assists the move to standardised communication of complex health information between systems and the opening of these vertical domain and organisational silos, allowing accurate and semantically computable health information flow.  Inevitably the shared clinical content specifications begin to influence the information models within clinical applications.  openEHR is an electronic health record architecture based on many years of research and development, and designed to work in partnership with all vendor systems, organisations and providers to facilitate semantic interoperability of health information.  It is a comprehensive and transformational solution which applies to the capturing and sharing of information from the most complex and dynamic knowledge domain – health.

Why are Health Records so difficult?

The interoperability of health information problem is twofold – firstly, the evolving clinical needs and requirements for a SEHR are difficult to pin down, and secondly the technical issues related to a SEHR solution.

Why are clinical requirements so difficult to capture and transform into an electronic health record (EHR)?  Certainly no-one will argue that our experience of healthcare delivery is changing – hospital in the home projects; supported self-management; patient requests for access to GP and hospital clinical records; personal health records; service coordination; clinical care plans; preventive health priorities...  The list goes on, mirroring the rapidly evolving change in clinical EHR requirements needed to support these new paradigms of healthcare delivery.  These new ways of delivering care require a coordinated approach – healthcare providers need to collaborate efficiently in real time, which is not adequately supported by traditional methods such as meetings and phone calls.  We really need an interoperable and integrated patient record in which all healthcare providers can participate, within a framework providing governance, authorisation and security measures.

Clinical knowledge domain is very complex and dynamic, so any clinical system created using traditional software development methods (embedding the clinical knowledge directly into proprietary application code and databases) has an uphill battle to deal with the changes.  Considering the time it takes for a clinical application to be developed, it may already be out-of-date at its launch!  The inherent difficulties in updating knowledge structures that are hard-coded into the application and database inevitably lead to a gradual deterioration of the integrity of the system.

Clinical decision support is another difficult area – there is a lot of discussion about it, but there is very little real computerised decision support happening in practice.  Certainly, each clinical system has some that is custom built – usually limited to allergy and drug interaction alerts and a reminder system – but there has been very little general progress in this area.  Why is clinical decision support (CDS) still largely found only in the academic domain and not implemented in production clinical systems?  We already have clinical guidelines and other resources which are approved and used in paper formats – why are they not integrated in our clinical desktop applications?  The answer is multi-factorial.  Things that have blocked progress include ownership and sharing of intellectual property, licensing problems etc, but the main issue is to do with practical implementation and cost.  An approved guideline can be transformed into some proprietary computable format, but then it has to be able to integrate into every other clinical system – lots of interfaces have to be built, paid for and maintained.  This is a nightmare.  Another approach is for each system developer to take a guideline and integrate it into their system as best they can.  This introduces variability and the potential for significant quality and liability issues to arise.

Silos of proprietary information cannot talk to each other without mappings and necessary assumptions.  Such transformations inevitably compromise the quality and integrity of the information being shared, thus creating more threats to patient safety.  It is only through use of a common logical clinical content model reflected in our EHRs and CDS systems that the guidelines can be created once according to this agreed model and can be integrated meaningfully and accurately with the clinical information systems to give us quality clinical decision support at the point of care.

From a technical point of view, the current reality around the world is that the majority of vendors are competing to build the greatest and ‘best of breed’ clinical software applications, but all are doing it in their own proprietary way.  The software may have a rich functionality and a great user interface.  It may do a great job in the clinic, hospital or network on which it is installed, but how does it share clinical data?  Some software applications may be able to share with the same system in another geographical location because they share a common data structure, but cannot easily share with the system of another vendor.

Current clinical applications can usually send or receive point-to-point messages using a format which is known and agreed, and based on a standard such as the Health Level 7 (HL7) version 2.  The software may also incorporate a terminology to assist in capturing and storing common clinical concepts.  However, there is a common misconception that if we simply have a messaging standard paired with a terminology, then we have ‘achieved interoperability’.

A New Paradigm for Electronic Health Records

Most of us mistake the software program for the electronic health record; in fact in the USA the word EHR means a clinical application.  The openEHR approach asserts that it is not the application, but rather the data, or health information, which makes up the health record.  And further, that it is a common and agreed structure of that data is what makes the electronic health record of any use for computing in health.

In order for two clinical systems to be able to share health data unambiguously, such that clinicians can read it and the computer can compute with it, more is required.  This semantic, or knowledge-level, interoperability, based on a common and coherent clinical model, is an absolute requirement for truly shareable EHRs and valuable complementary functionality such as clinical decision support and workflow/care planning.  Further, it is only when this clinical content structure is agreed at a local, regional, national or international level, that true semantic interoperability can occur at each of these levels.  The broader the level of clinical content model agreement, the broader the potential for semantic health information exchange. While an increasing number of health informatics experts agree on this view of the problem, incremental work towards EHR standards based on messaging paradigms, such as HL7 v3, have only had limited degrees of success.  At an international level, there is increasing concern that this incremental approach to SEHRs may not be able to solve the issues of semantically interoperable EHRs.  Remember that Einstein argued: “We can't solve problems by using the same kind of thinking we used when we created them.”

We need semantic interoperability for our SEHRs and in order to achieve this we need a transformational change.  We need to use a different paradigm.  The openEHR paradigm has been collaboratively developed, reviewed and refined to realise a collective vision of a high quality, internationally interoperable EHR.

What is semantic interoperability?

Let’s be clear about what semantic interoperability means.  According to Walker et al[1], Level 4 interoperability, or ‘machine interpretable data’, comprises both structured messages and standardised content/coded data.  In practice, it means that data can be transmitted and viewed by clinical systems without need for further interpretation or translation.  This is a basic foundation for a truly shareable EHR and for functionality such as clinical decision support.

For clarity, existing HL7 v2 messages probably fit into Level 3 of Walker’s conceptual framework – ‘Machine organisable data’ which comprises structured messages but unstructured content.  According to Walker, a level 3 message “requires interfaces that can translate incoming data from the sending organization’s vocabulary to the receiving organization’s vocabulary; usually results in imperfect translations because of vocabularies’ incompatible levels of detail.”  We cannot directly compute on a Level 3 message – it requires interpretation or transformation before the computer can use it.  HL7 v3 goes a step further with an underlying semantic model.  The problem has been that using this in systems has proved very difficult.  The HL7 CDA, chosen by Nehta for communication in Australia, bypasses some of the difficulties by at least enabling us to share documents that we can read.  More is needed to achieve semantic interoperability.

What is openEHR?

openEHR[2] is a set of open specifications for an Electronic Health Record (EHR) architecture – but it is not a software application.  Its design purpose is to enable semantic interoperability of health information between, and within, EHR systems – all in a non-proprietary format, avoiding vendor lock-in of data.

All clinical knowledge concepts are captured in a structured way - known as archetypes – outside the software.  The types of archetypes support the recording required for common clinical activities, with some of the key building block archetypes comprising observations, evaluations, instructions and actions.  Data built according to these are stored in an EHR in larger ‘composition’ structures, which have their own archetypes.  Compositions are comparable to a document that results from a clinical event which is performed e.g. a consultation record or a discharge summary.  Archetypes can be simple, such as temperature, blood pressure or diagnosis, or complex, such as capturing the risk to a fetus if the father has a grandmother with Huntingdon’s chorea.  The archetypes contain a maximum data set about each clinical concept, including attendant data required such as: protocol, or method of measurement; related events; and context that is required for the clinical data to be interpreted accurately.  The creation of archetypes and templates is almost purely a task for clinicians – openEHR archetypes put clinicians in the driver’s seat, enabling them to create the breadth, depth and complexity of the health record to suit their needs for direct healthcare provision.

Aggregations of archetypes are combined in openEHR ‘templates’ in order to capture the data-set corresponding to a particular clinical task, such as an ICU discharge summary or antenatal visit record.  When clinicians look at templates, the information contained within them inherently makes sense and doesn’t require significant training for interested clinicians to be able to create templates for their own purposes – be it domain, organisation or purpose specific.  Templates can be used to build generic forms to represent the approximate layout of the EHR in a practical sense, and these can be used by vendors to contribute to their user interface development.

Both archetypes and templates can be linked to terminologies or contextually appropriate terminology subsets that will support appropriate term selection by healthcare providers at the point of data entry.

openEHR is rapidly gaining international momentum, supported by evidence from current high profile implementations of the openEHR specifications such as in the UK NHS Connecting for Health program.

Who is openEHR?

The openEHR Foundation owns the intellectual property of the openEHR architecture specifications.  The Foundation is a not-for-profit company, with the founding partners being University College London (CHIME department) and Australian company, Ocean Informatics. The specifications are the result of over 15 years of research and international implementations, including the Good European Health Record (GEHR), and the collaboration of an international community of people who share a common goal – that of the realisation of clinically comprehensive and interoperable electronic health records to support seamless and high quality patient care.

The registered online community has over 1000 members from 75 countries with many actively participating in debate and contributing to ongoing openEHR development from both technical and clinical perspectives.

What is openEHR used for?

openEHR is a specification for secure, shareable health information and provides a foundation on which to build interoperable, modular software applications.  These, in turn, can support distributed clinical workflow, such as care plans.

The openEHR specification can be implemented in a number of ways:

  • Scalable EHRs – from Personal Health Records to small/medium/large organisations to regional or state clinical record systems and on through to National e-Health programs;
  • Message-based, web-service, middleware applications; and
  • Integrating existing clinical systems, including virtual federation of data for research or public health purposes.

However, while it has much in the way of additional functionality, it is important not to lose sight of openEHR’s raison d'être – semantic interoperability, or more simply, a truly shareable Electronic Health Record.

How is openEHR different?

There are many aspects of openEHR which clearly differentiate it from other EHR models:

  1. Open source initiative The openEHR specifications are freely available under an open licence.
  2. Separation of the technical and clinical domains The openEHR design is markedly different to traditional EHR development - it is a 2 level information model.  These 2 levels allow a clear separation of the technical reference (i.e. data) model on which software is based from the clinical knowledge itself.  The appeal of this new design is that the technical components of the EHR can be kept quite separate from the dynamic clinical knowledge model.  In practice, the technicians manage just the technical aspects, while the clinicians are critical in the development of the clinical archetypes and templates that shape the nature of their EHR.
  3. Purpose-built EHR The design of the reference and archetype models support many unique openEHR features required for robust clinical record keeping, clinical business process and medico-legal compliance, such as:  distributed versioning and merging of EHR records, including audit trails; a strong history and event model for complex observational information; and archetype-driven semantic querying. openEHR designs supports configurable security, anonymous EHRs, fine-grained standards-based privacy, digital signing, and access auditing.
  4. Knowledge-enabled – capturing the dynamic and complex nature of health information Clinicians are able to contribute actively and directly to the development of the clinical knowledge models that underpin their EHRs.  Archetypes can be revised and versioned to reflect the rapid and varied changes in health domain knowledge.
  5. Terminology agnostic openEHR connects flexibly to any or all terminologies through either archetypes or templates.  Terminologies such as SNOMED-CT are leveraged when used alongside archetypes, with the archetype clinical model providing context to minimise the need for post-coordination and complexity.  Archetypes and terminologies are not competitive but rather complement each other.
  6. Semantic querying Archetypes, in combination with terminologies enable powerful possibilities for semantic querying of repository data – whether for individual usage or for population research.  Archetype-based querying enables true longitudinal processing of health data, regardless of the originating system.
  7. Language independent There is no language primacy in archetypes; they can begin in any language and be translated to multiple other languages.  Translation enables the same archetype to be used in different countries, with data created in one language to be interoperable with systems developed and used in other languages.  Archetypes are currently available in English, German, Turkish, Dutch, Swedish, Farsi, Spanish and Portuguese.
  8. Sustainable reference model – life-long EHRs The openEHR reference model has been rigorously engineered over the past 15+ years as the foundation for a comprehensive health computing platform.  It consists only of generic data types, structures and a small number of generic patterns, resulting in a small, stable and sustainable information model for IT people to maintain.  This approach allows a clinical data repository to act as a future-proof data store, totally independent of software applications and technology change.  In practice this means that no software application changes, or redeployment, are required when new or revised archetypes are published to reflect changing clinical knowledge.  As a result, life-long, application-independent health records are possible for the first time.
  9. Ease of implementation openEHR is comparatively easy to implement:

    • there is little infrastructure required;
    • the software required is small, due to being based on a compact and stable, object-oriented reference model; and
    • the clinical models (Archetypes) can be developed separately from the software application.
  10. Ongoing development and enhancement Based on feedback from its international collaborators, openEHR is undergoing continuing development, with ongoing maintenance and releases of specifications and software.
  11. Governance of shared content Archetypes are created once, and if broadly agreed upon, they can become the basis of consistent sharing of data content between systems, providers and even other countries.  While archetypes can be designed and used by a given solo practitioner/researcher or locally within an organisation, the power of archetypes becomes more evident the more broadly they are shared.  All systems that use the same archetype – even across country borders and terminologies – will be able to interoperate. The openEHR Foundation is in the process of developing an ontologically based international, open source archetype and template repository[3].  This is being supported by a governance framework which will facilitate archetypes to be submitted for international clinical review, and publication.  It comprises a complete archetype and template lifecycle and version management repository and supporting processes to allow countries, regions, organisations or vendors to freely download and utilise these commonly agreed archetypes in their clinical systems.  Archetype libraries can also be set up at other levels, as needed – domain, organisational, regional, or national.
  12. A collaborative model of development rather than a standards-based path The openEHR development to date has been the result of an interested and motivated volunteers from a broad international community of clinicians and software engineers.  Formal and rigorous processes have underpinned its progress and both Architectural and Clinical Review Boards, comprising world experts in their fields, have had oversight of the overarching strategy, process and governance. Standards are not rejected in the openEHR approach; they are just not a part of the development process.  In comparison to a traditional standards-based approach, openEHR development has been relatively rapid and pragmatic, rather than being held back by the slower process of ‘design by committee’.  In fact, the recent European CEN standard for EHR extracts (EN13606) has been based on an earlier version of, and a subset of, openEHR.  In addition, openEHR’s Archetype Definition Language (ADL), has recently been accepted as an International Standards Organisation (ISO) committee draft, for consideration as a standard.

Where is openEHR being used? [as at October, 2007]

openEHR is being used in both active research and commercial activities.  [4] Research on openEHR is being conducted in Sweden, Australia, United Kingdom, USA, Sri Lanka and Spain.  Commercial development is occurring in Australia, United Kingdom’s NHS Connecting for Health, Netherlands, Belgium, Sweden, Turkey and the USA.

The United Kingdom’s National Health Service (NHS) Connecting for Health program has just commenced a formal clinical modelling program using openEHR archetypes and templates to provide a common and agreed clinical content on which to base its clinical applications.  In a pilot early in 2007, content developed for NHS Maternity and Emergency domains were provided to vendors for implementation in new clinical application development.[5] These archetypes are available in the public domain, and have undergone broad internal review by expert clinicians prior to being approved for NHS usage.  The Emergency templates developed reflect the top 10 presentations to an Emergency Department – including chest pain, shortness of breath and collapse.  The Maternity templates followed the clinical journey of a pregnant woman – from a pre-pregnancy consultation and antenatal visits, through to capturing the labour and delivery record, including Partogram data.  Each template is made up of a variable number of archetypes – ranging from a few simple templates containing only 2 or 3 archetypes through to complex templates containing up to 80 discrete clinical concepts.

Current openEHR status and supporting tools [as at October, 2007]

  1. openEHR Specification The latest openEHR Specification (Release 1.0.1) was published on 15 April 2007.
  2. Clinical Content Development of archetypes and templates has gained significant momentum in the past 12 months:
    • Archetypes As a result of initial Australian modelling work and, more recently, within the UK NHS, there are now approximately 250 archetypes.
    • Templates Over forty distinct templates representing clinical needs in Emergency and Maternity were developed over a short time period in March/April 2007.
  3. Commercial Tools Currently there are a number of commercial tools supporting the open source openEHR implementation.  The major tools to date are developed in .Net and Java.  Australia’s Ocean Informatics[6] has developed a suite of products supporting openEHR implementation in .Net, while Sweden’s Linkoping University have developed an Archetype Editor in Java and Cambio Healthcare Systems[7] have an early Java kernel.

The Ocean .Net products include:

  • Clinical Knowledge Suite:
    • Archetype Editor (open source) and Template Designer, including semi-automated screen form construction based on templates;
    • Terminology Toolset – including a caching terminology server and subsetting tool, incorporating SNOMED-CT in the first instance; and
    • Archetype-powered Query Designer
  • OceanEHR platform – including a universal data repository, demographic service binding, generic EHR Viewer; and data integration & transformation services.
  • Archetype/Template Library Service as an online template and archetype repository

Get involved with openEHR

Membership of the openEHR community is free and open to everyone via the openEHR website[8].  It assumes a commitment to a common vision for high quality, interoperable EHRs, and a willingness to share ideas and experience.  All levels of interest and contribution are welcome – from novice to expert.  The lists range from discussion on technical, clinical and implementer mailing lists through active development of archetypes, templates and tools, to review and critique of clinical content models and technical specifications. Whether you are a clinician, patient advocate, vendor or provider of health care you have a role in the development of what is becoming known as 'the world's record'.

[1] Walker J, Pan E, Johnston D, Adler-Milstein J, Bates DW, Middleton B. The Value of Health Care Information Exchange and Interoperability. Health Affairs 2005 Jan 19 -
[2] For more details, see
[3] For more details, see [UPDATE 2010: Clinical Knowledge Manager -]
[4] For more details, see [UPDATE 2010:]
[5] For more details of the NHS clinical modeling work, see
[6] For more details, see
[7] For more details, see

Is your clinical data 'fit for purpose'?

We clinicians expect a lot from our electronic health records (EHR), & so we should. Yet I am surprised at how remarkably passive we, as a group, are about the structure & quality of the data that underpins it.

  • Does it store the data we need?
  • Can it be utilized for decision support.
  • Will it support our research?
  • Can it easily be shared?

Most of us don't know - we just don't tend to look 'under the bonnet'.

Yet we are undeniably clinical domain experts. We also understand what information we need for providing patient care & our research. What if our systems don't capture what we need or in the optimal way for us to use?

We need to ensure that all our efforts to conscientiously enter good patient data is reflected in the underlying data structure - that our clinical data is 'fit for purpose'.

It is important to understand & acknowledge that there are many ways to represent the same data, and not all are equivalent! We need those trained as both clinicians & informaticians to be intimately involved in developing high quality eHealth tools. Clinician informaticians provide the critical link between our software engineers & our grassroots clinician experts.

Have you ever considered how the data in our systems is designed?  What is the process? What is the criteria for 'quality'?

I have seen many examples of clinical information requirements that have been gathered 'with extensive stakeholder engagement'. OK, but when you enquire who gathered the requirements it is not always (& sadly, most often not) a clinician informatician who has asked the questions. I have to ask the question. If you are not a clinician & don't understand how health data is going to be used (content, processes, reference models, querying, use of terminologies etc), how can you ask a reference group the right questions in the first place & ensure that you have the right answers? The chances of the reference group consisting of clinician informaticians to spoon feed you the right information is pretty slim. So by my reckoning there may be a significant risk of 'the blind leading the blind' syndrome occurring in this not uncommon scenario. Learning point: Always question the credentials of the initial data requirements!

On a number of occasions I have been shown some data requirements for core archetype modeling - problem/diagnosis, adverse reactions, medication orders & the like. It is frequently clear they have been developed by a technical analyst with very little clinician informatician input. Turning these requirements into an archetype is not an issue, however I have concerns that my 'fit for clinical use' criteria will not be met. They might be perfect for reporting back to government, but for clinical care, decision support, research, sharing etc... maybe not so good, yet they are being created for use in desktop clinical EHRs.

Interestingly in openEHR training sessions I have supplied a set of clinical requirements for an archetype to participants, encouraging them to break into mixed teams of both clinicians & technicians to try their hand at collectively building their first archetype. Not so surprisingly, they most often split into clearly demarcated technical & clinical groups - no cross-pollination at all;-). Despite being presented with the same requirements, inevitably both groups tend to represent the data quite differently - clinicians intuitively represent it the way they know it & need it; the technicians making a best guess based on their incidental domain knowledge. 

When I train people in how to build archetypes, I always state that the best archetypes - by that I mean 'fit for purpose' - are those built by clinician informaticians. Next best are those built in close collaboration with clinician experts, preferably staring over their shoulder & offering feedback in real time! Lastly, those built by technical modelers with little or no direct domain understanding. (Unfortunately, by far the most modelers that are in the employ of our national eHealth programs & large vendors are in the latter category.)

I have seen surprisingly bad archetyping efforts by very proficient technical modelers, largely just because they don't understand the clinical context. In most instances, a spreadsheet or UML diagram of requirements just isn't enough. On many occasions over the past few years I have found that their idea of a clinical concept is often quite different to that of a clinician - not unexpected really!

My conclusion - clinical experience matters!

Health informaticians are few on the ground. Clinician informaticians are even fewer. We need a transformational approach to EHR development - working smarter & more efficiently. Clinician informaticians are critical to ensure the development of shareable, 'fit for purpose' clinical content specifications as a solid foundation for good quality health data, both within & for sharing between systems.

What if... grassroots professional clinical colleges were driving EHRs?

Is the tail wagging the dog? Should vendors decide what clinicians need? OR should the professional clinical colleges be driving the EHRs that members need to provide quality healthcare to their patients? From a quality point of view, one could strongly suggest that colleges should be the experts driving this new paradigm of clinical care. As a group, professional clinical colleges as a group usually state that one of their major roles is in establishing and driving the benchmarks for acceptable clinical practice standards in their field of expertise. Most do this very well in the traditional areas of clinical practice.

Scouring the web it is possible to see that some are engaging actively in eHealth. For example, from the website of The Council of the Royal College of Physicians in UK, a vision statement published in January 2010 incorporates this final paragraph:

"Effective implementation of standardised, structured, patient focused records requires strongly led culture change, embraced by all medical and clinical staff. They are essential prerequisites for safe, high quality care and for the safe, efficient and effective migration from paper to electronic patient records. Such records will also enable innovative development of services that cross traditional boundaries and, by giving patients access to their record, empower them to take more responsibility for their own care."

If colleges have had a traditional role in ensuring safe, high quality care, then the advent of electronic health information should logically trigger a natural extension of their pre-existing work and roles into the eHealth arena. I would go further and suggest that they should also be actively driving an eHealth agenda that reflects their college remit regarding provision of quality care and standards; ensuring that the data created, stored, shared and queried is good and fit for use in clinical care.

This agenda may, or may not, be aligned with the activities of national eHealth programs. As we look at the news in recent weeks it is becoming apparent that many are struggling with implementation of top-down agendas. We have seen major changes in the national approach to eHealth happening in Netherlands, Germany, and England's NHS. Perhaps it is time for a grassroots, bottom-up approach from the end-users, the healthcare providers, and their patients, the healthcare consumers.

How can colleges drive eHealth?

  1. Promote the establishment of a universal health record - a long-term, data-driven health record platform based upon open source specifications, a standardised health data structure, and application-independence. If we place the patient's universal health record at the focus, applications can effectively 'plug & play' with an open, standardised patient data repository, instead of struggling/battling to move/transform/migrate/map/message bits of health information between proprietary application silos.
  2. Develop clinical quality-related eHealth standards:
    • Knowledge artefacts specifications The clinical knowledge expertise of colleges can be used not only to develop principles of best practice and clinical guidelines etc but also the structured clinical content specifications that underpin the universal health record and ensure that the health record is able to capture all the data that their clinicians need to provide quality clinical care, to share with other healthcare professionals and for research. These specifications need to be defined both at the clinical concept level, such as the specification for blood pressure, but also expressing how many clinical concepts can be aggregated together and constrained to specify the requirements for a computable discharge summary or an anaesthetic record. Ideally this would be work done in collaboration with other clinicians, colleges and informaticians to make sure that the agreed concept specifications are applicable for all colleges and clinical domains, so that there is one common concept in use for all. Colleges as domain experts are also best placed to determine the terminology subsets that are appropriate for use by their clinicians.
    • EHR best practice: Develop principles around the best practice use of electronic health records, including:
      • Data quality principles and activities. As health records become electronic, the previous remit of Colleges to make sure that clinical practices are accredited and that paper records are kept to a documented standard can be transformed to the eHealth paradigm. There are similar principles that can be developed and applied when clinicians are capturing and using data. Programs such as Primus Plus in the UK have worked directly with primary care clinicians to educate and support about best practice data management.
      • EHR safety - User interfaces,clinical processes, decision support etc

Colleges may bundle these new standards-based eHealth activities within existing service provision to, or activities involving, their members.

In addition, commercially savvy colleges could develop ways to develop and sell practical solutions or packages around these quality principles direct to members – products or programs to make it easy for members to put the evidence-based and quality principles into practice.

Herein lies a challenge for contemporary professional clinical colleges – to both embrace eHealth and to actively drive it in a way that promotes and preserves safety, quality and best practice in healthcare, such that eHealth becomes a positive tool for healthcare provision and, possibly even, reform.

And how to do this in practice? Well, it is no secret that I think openEHR can offer a solution to a lot of these issues - see my previous posts 'What on earth is openEHR' and 'Connect with openEHR'.

Time will tell if I'm on the right track. For me as a clinician, the more time I spend with it, the more compelling this openEHR story becomes...

So I'll ask you a question. Is the tail wagging the dog? Should vendors be deciding what clinicians need? OR Should the colleges be driving vendors to develop the EHRs that members need to provide quality healthcare to their patients? From a quality point of view, one could strongly suggest that professional colleges should be the experts driving this new paradigm of clinical care.

What on earth is openEHR?

What is openEHR wordleMy experience in eHealth started as a suburban General Practitioner using an EHR application for prescribing and clinical notes, and then I moved sideways, becoming involved in building proprietary clinical software and a Personal Health Record. From 2000 I worked for 4 years in a single company that owned that PHR plus a primary care clinical application and a hospital application - the intent being that data created in one could be transferred between the systems, but we found it wasn't that easy - for various reasons they all had different database structures, even within the same vendor! So if we have to do the same thing between disparate vendors in an environment that is more competitive than collaborative, the picture becomes infinitely more complicated. In more recent years, I have had my world view shifted from the traditional application-drive EHR to a data driven health record (note the deliberate lack of capitalization) - see my previous blog posts. Once we focus on getting the data right, capturing it or displaying it in the applications are just one of the many things we can do with the data.

Why? I first heard about openEHR nearly 10 years ago. I didn't understand openEHR at all initially, but there was something in the commonsense of getting the foundation data defined and standardized that resonated with me. Over time I have become convinced that openEHR provides an orthogonal approach to eHealth that has a very reasonable chance of success, and more importantly, of making a difference. I no longer believe that the traditional application-driven approach to electronic health information management is effective, economic or sustainable.

What is openEHR?

Think of openEHR as the open source health equivalent of the iPod/iPhone platform – a technical framework which will allow any compatible application, organization or provider to share 'plug and play' access to standardized data. This is openEHR’s innovation – the focus on ensuring that the underlying health data is correct, robust and trustworthy!

Rich health data definitions known as archetypes, are defined and agreed by the clinicians themselves to ensure that each piece of health information is unambiguously understood, ‘fit for purpose’ and can be dynamically used & reused to support wise and safe health choices, now and into the future. These same archetypes are also computable, so that when these common data definitions are shared, they act as a 'lingua franca', making it much simpler to capture, store, aggregate, query and exchange health information - effectively making the data 'sing and dance' and to flow according to privacy and access rules.

Developed over more than 15 years through international research, community input and implementations, openEHR is purpose-designed as a non-proprietary universal health record: application independent, yet supporting accurate and safe health information exchange between software programs, consumers, health care providers, organisations and researchers; and across the diverse requirements of private/public providers and regional, national and international jurisdictions.

Why openEHR?

  • It is open source - break down the proprietary silos of data created by application vendors.
  • It is the basis for the recently published ISO13606 standard for EHR extract. openEHR evolved and grew away from 13606 approx. 5 years ago as 13606 entered the CEN and ISO standards approval process; openEHR has subsequently progressed and developed as a direct result of implementation experience. At present openEHR is the commonest implementation pathway for nations mandated to adopt the 13606 standard.
  • It is driven by an international open source community.
  • It has been developed using a robust engineering process.
  • The clinical content is driven by the domain experts - usually, but not limited to the clinicians themselves - through the Clinical Knowledge Manager.
  • Archetypes are designed as maximal data sets for the universal use-case so the same data definitions can be used in any software application - whether a PHR, EHR, research project, clinical decision support system or running population queries.
  • It is purpose-designed as a shared health record.
  • The structured archetype definitions complement other standards-related work - for example the recent announcement of a collaborative work program between the openEHR Foundation and IHTSDO to explore how the SNOMED-CT and openEHR archetypes can be combined to provide a strong semantic solution for health information.

Who is using openEHR?

International momentum is building - current users noted on the openEHR website include commercial, government, academic, and non-profit organisations.


Current eHealth developments are progressing at a glacially slow rate because we are trying to develop interoperability by traditional and incremental methods. I'm increasingly sceptical that this is effective, economic or sustainable. And in fact, though direct experience I have become convinced that openEHR's orthogonal approach can make a significant difference. I now work with openEHR every day, including:

  • alongside an international group of like-minded clinicians collaborating in their spare time in a Web2.0 application to develop, publish and govern the archetypes;
  • with national eHealth programs who are seeking to build a library of clinical content definitions as a 'single source of truth' to mandate for use by vendors;
  • with vendors who no longer have to reinvent the wheel but can take the published archetypes and re-use them within their systems; and
  • with researchers trying to aggregate and integrate disparate data from multiple sources into one cohesive repository on which they can query their valuable data.

I'm not trying to sell you a software application like everyone else claiming an 'eHealth solution'; I'm trying to persuade you to take a look at an alternative approach to eHealth, to share a little of my vision and my passion!

Consider becoming part of an international open source community. Contribute and collaborate alongside other clinicians, informaticians and techies to build something bigger than all of us. Share a vision of how eHealth could work better and more effectively if we get the foundations for a universal health record consistent and solid.

It. is. all. about. standardizing. the. data.