Representing FHIR clinical content in openEHR

Over the past few days I’ve attempted the task of representing the FHIR Skin and Wound Assessment profiles using openEHR archetypes.

I note that there are three Skin and Wound Assessment FHIR Implementation Guides available online:

  1. "Full CIMI" version – which is the one I chose to model;

  2. Federal Health Information Model (FHIM) version; and

  3. Mitre’s ‘mini-CIMI’ version.

I’m a clinical modeler, a clinician by background, so I’m always looking at how we can best represent clinical data in ways that are friendly to grassroots, non-technical clinicians of any sort. The FHIR IG is a tough beast to decipher, despite my experience of gathering patient requirements and turning them into implementable specifications for more than a decade.

My intent as I started this work was specifically that as a clinician I didn’t want to have to fully understand the FHIR representation. I wanted to be able to look at the clinical data and recreate it using my familiar openEHR tooling and representations.

I estimate that it has taken me nearly 2 full days of work – much more than I anticipated - and mostly to trawl through the myriad of online pages for each FHIR resource and associated profile, then to piece together the connections visually so that I could create/reuse appropriate openEHR archetypes and templates. The openEHR representation didn’t take long, largely because of reuse. It was the analysis that was the time killer.

Despite all of that effort, I am still not confident that I’ve got it right. But the following post reflects my experience, plus learnings and some queries.

My modelling assumptions

The three base clinical representations that I’ve gleaned is the Wound Presence Assertion, the Wound Absence Assertion and the Wound Panel Assessment.

Rightly or wrongly, my openEHR templates assume the following:

  • ‘Wound Presence Assertion’ profile is the equivalent of our recording a diagnosis and overview of a wound – so I’ve created a Wound Presence Assertion template, based on the EVALUATION.problem_diagnosis);

  • ‘Wound Absence Assertion’ profile is the positive assertion that a wound is excluded or not present; and

  • ‘Wound Assessment Panel’ is the equivalent of clinical examination findings about a single, identified wound – so I’ve created a Wound Assessment Panel template, based on the OBSERVATION.exam archetype.

  • If FHIR components were modelled as 0..1 occurrences then I added them to the archetype at the root level – see the size measurements and edge related data elements in the Examination of a Wound CLUSTER archetype.

  • If FHIR components were modelled as 0..* occurrences then I added them as repeatable internal cluster groupings – see the Tunnelling and Undermining clusters in the same archetype.

openEHR Representation

You’ll note that I haven’t created a template for the Wound Absence Assertion. I’ll be curious to understand the use case from the FHIR modellers but I cannot understand the use case where a clinician will explicitly record that a wound is absent, not there. They will record that a previously known wound has healed over, or that the skin in the area is normal. But to record that a pressure ulcer on the right buttock is absent – I don’t think so, not even in a medico-legal scenario! If someone can provide me with a use case, I’m happy to reconsider…

I’ve uploaded the resulting two templates and the associated archetypes to a public incubator on CKM. You can view them all here: https://ckm.openehr.org/ckm/#showProject=1013.30.9.

The two templates comprise 6 reused archetypes, and I created two new archetypes:

The clinical content within the FHIR IG is generally very sound, and I can see that a lot of work has gone into the development of it and especially the value sets. It is a very useful resource, if you can discern the content in amongst all of the rest of the tech spec. I must admit I got very frustrated and very confused and had to restart a few times.

Once I’d teased it out, I’m very grateful to those who did the hard yards of clinical analysis that underpins this Skin and Wound assessment. Credits on the IG attribute the domain content analysis to Susan Matney from Intermountain Health. I have some other questions for clarifications and would like to discuss a few issues but otherwise this is a really sound piece of work and I’m very pleased with the end result in openEHR.

The templates are up on CKM for you to take a look at:

The rather ugly CKM default UI for templates is deliberately designed for displaying the individual data elements and most of the relevant constraints – much easier for a clinician to be able to review and approve from a content point of view. CKM doesn’t display the URL to value sets, although if you download the .oet and .opt files you will find them safely stored within the code.

Questions, issues

General modelling

I’ve reconfirmed that the openEHR reference model is a godsend. That the data types have set attributes is a given and doesn’t need to be represented over and over again is something I now appreciate enormously, including null flavours etc. Brilliant. There is so much endless repetition in the FHIR resources for RM related data and it takes ages to locate the real clinical data amongst everything else.

Wound Presence Assertion

  • Anatomical location of the wound is only recorded in this model. I’m not so sure about whether this is a good idea. I think that anatomical location should also be modelled for each examination event (ie included in the Wound Assessment Panel) so that what is being examined is clear and unambiguous. At present the anatomical location of the wound represented by the Assessment Panel appears to only be associated with the Presence Assertion via a common identifier (WoundIdentifier).
    Note that I can only find the Anatomical location model in the Logical model and not in the Profile, so maybe I’m missing something?

  • In the logical model, Laterality is represented as ‘Unilateral left’, ‘Unilateral right’ and ‘Bilateral’. I totally agree with the left and right but I have a major problem with identifying one (or more) wound(s) as ‘bilateral’. ‘Bilateral’ should probably not refer to direct observational exam findings at all, but is may have some value in recording conclusions. For example, in examination of each ankle, the finding of pitting oedema may be made, but each side is likely to need explicit recording of different severity or association with ulceration etc, so the findings from each side should be recorded one separately. However, the conclusion of the clinician, at a higher level of abstraction in a physical findings summary or as a diagnosis, may well be bilateral ankle oedema, but it is not advised for use at the point of recording the examination findings.
    Given that this representation of anatomical location is in the Assertion and as best I can tell the concept being modelled is a single Wound (SNOMEDCT::416462003), the notion of a bilateral wound is not appropriate.

  • Clinical status values – now these were tricky. We have an existing ‘Problem/diagnosis qualifier’ archetype. It is a messy beastie, largely because clinicians are notoriously messy at how they record these kind of things. The FHIR value set used in this template comprises values from 4 (yes, four) data elements that we have identified as having completely different axes in our archetype. The FHIR value set is drawn from parts of each of our ‘Active/Inactive’, ‘Resolution phase’, ‘Remission status’ and ‘Episodicity’ data elements.

Wound Assessment Panel

  • As above, I’m concerned that there is no explicit recording of the Anatomical location/laterality parameters so that we can track examination findings over time, especially if there are multiple wounds. An identifier as a connector seems a little flimsy for me.

  • The concept seems to be a generic wound, but the data elements seem to be focused on recording the findings of an open, ulcerated lesion in reality. If the wound was a long laceration, for example, there are parameters missing such as beginning and end point, relative location to a body landmark. An animal bite might also be difficult to record at the best of times, and something simple like a narrative description would also be helpful.

  • There is a data point about a pressure ulcer association, with two values – device and pressure site, which reinforces the focus on a pressure ulcer and is very specific. I have modelled that same data point as a repeating cluster pattern of a ‘Factor’ associated present/absent attributes to make this model more applicable to a range of wounds.

  • Tunnelling is a tricky concept to model. In the FHIR model, tunneling seems to assume that the tunneling radiates out from the edge of the wound but doesn’t allow for deep tunneling from the middle of the wound to be recorded.

  • The use of a clockface direction is common in a few clinical scenarios, including this one. However the openEHR experience has identified that in order to represent it accurately a few assumed items need to be recorded, such as identification of the central landmark around which the clockface is oriented, as well as the anatomical landmark that identified the 12 o’clock reference point. See our recently published Circular anatomical location archetype.

  • The Undermining model is represented in the archetype/template as a repeating CLUSTER to allow multiple measurements of the amount undermined in different directions. In the FHIR model, the length and direction are both optional. In the archetype I’ve made the length mandatory as there is no point recording a direction by itself.

  • I did not model exudate volume in the template as it is measured, and it is not clear to me how you measure a volume at an examination (assuming this assumption about the recording context is correct). Rather it is usually recorded over time, and so does not seem to belong here. I did model the Amount, with a value set that is not available to view, as I assume it is descriptive and could be appropriate here.

  • Episode is modelled within this context, however it seems to me that it is probably better placed in the Assertion. See the ‘Episodicity’ data element within  the Problem/diagnosis qualifier archetype.

  • Similarly ‘Trend’ feels a little tricky in the context of examination findings. I guess that it could be useful if part of a sequence of exam findings and if it correlated back to the longer timeframe of ‘Course description’ narrative within the Problem/Diagnosis archetype.

  • There are a few data element which record Yes/No/Unknown answers as though it is answering a questionnaire within the context of recording exam findings. In openEHR we tend to record these as findings that are Present/Absent/Indeterminate so that we can bind, arguably, more meaningful codes to each value and not mix history-like recording with observations.  

For a grassroots clinician to review the content there is no doubt that the IG is next to impossible. Perhaps the FHIR community has a more clinician-friendly view that I’m not aware of. It is absolutely needed!

Wouldn’t it be great if FHIR and openEHR communities could collaborate such that this CKM representation could be used to support the FHIR work… but I’ve probably said that a million times… or maybe more. Perhaps one day <sigh>.

A common data language is essential for digital health disruption

The lack of a common health data language has been ‘the elephant in the room’ for a very long time. Unfortunately, very few people acknowledge the need for a clinical lingua franca as a critical foundation for eHealth. The mainstream view seems to be that messages are/will be enough and that creating a standard language for health information is either too hard or too complicated. Is it really that hard? Or is that just the view of those with vested interest in perpetuating the message paradigm?

Adverse reaction risk: provenance

Recording adverse reactions, allergies and intolerances to medications and other substances is universally regarded as a high priority for clinical safety. This is the ‘Adverse reaction risk’ archetype’s story - an international, cross SDO collaboration that achieved consensus. It demonstrates the potential value that comes if we choose to work together, rather than create more silos.

The challenge for FHIR: meeting real world clinician requirements

With the increasing burden of technical engagement resulting from the incredible expectations generated by FHIR globally, perhaps the clinical content specification should be outsourced to... the clinicians first of all, ensuring that the clinical content can be represented in a technical format for implementation.

Therapeutic Precautions are the 'new black'!

Clinical modelling around the concepts of warnings, alerts and notifications is incredibly complex and each of the terms are loaded with confusion. It is not going to be easy to navigate this area and achieve a common understanding that will underpin information models for sensible and cross paradigm decision support.


In a comment on one of my most recent posts, Lloyd McKenzie, one of the main authors of the new HL7 FHIR standard made a comment which I think is important in the discourse about whether openEHR archetypes could be utilised within FHIR resources. To ensure it does not remain buried in the rather lengthy comments, I've posted my reply here, with my emphasis added.

Hi Lloyd,

This is where we fundamentally differ: You said: "And we don’t care if the data being shared reflects best practice, worst practice or anything in between."

I do. I care a lot.

High quality EHR data content is a key component of interoperability that has NEVER been solved. It is predominantly a human issue, not a technical one - success will only be achieved with heaps of human interaction and collaboration. With the openEHR methodology we are making some inroads into solving it. But even if archetypes are not the final solution, the models that are publicly available are freely available for others to leverage towards 'the ultimate solution'.

Conversely, I don't particularly care what wire format is used to exchange the data. FHIR is the latest of a number of health data exchange mechanisms that have been developed. Hopefully it will be one that is easier to use, more widely implemented and will contribute significantly to improve health data exchange. But ultimately data exchange is a largely technical issue, needs a technical solution and is relatively easy to solve by comparison.

I'm not trying to solve the same problem you are. I have different focus. But I do think that FHIR (and including HL7 more broadly) working together with the openEHR approach to clinical modelling/EHRs could be a pretty powerful combo, if we choose to.


We need both - quality EHR content AND an excellent technical exchange format. And EHR platforms, CDRs, registries etc. With common clinical archetypes defining the patterns in all of these uses, data can potentially start to flow... and not be blocked and potentially degraded by the current need for transforms, mappings, etc.

Archetypes: health data bridges

What do we want for our health data - silos of information models for different purposes or ones that bridge multiple use cases? From a series of emails shared on the HL7 Patient Care email list in the past few days...

Grahame Grieve (FHIR, HL7):

"Heather, you need to keep in mind the difference between FHIR and clinical models: it's not our business to say not to exchange data that people do have because some user in an edge case might not understand it. We define an exchange standard, not a clinical UI standard..."


"Heather, do not lose sight of the difference between a clinical standard for what care/records should be, and FHIR, which is an IT standard for how care records are."

My response:

"...I am concerned about developing another standard that you state clearly is only designed for exchange and not for what care records should be. If we are not designing to try to harmonise data requirements for health information exchange, how clinical care records are and how clinical care records should be, then we are building siloes of data structures again, that will require mappings and transforms ad infinitum. I’d hate to see us end up with a standard for exchange that can’t be implemented for persistence"...

If we end up with models for exchange, models representing current data in systems (whether or not they represent good clinical practice and models that are regarded as the roadmap for good data, then what have we got? Three sets of data models that perpetuate the nightmare of non-interoperability.

Our openEHR archetypes are attempting to bridge all of these. Use them in whatever context you choose - messages, document exchange, EHR persistence, CDS, secondary use, aggregation and analysis, querying etc. The 'secret sauce' is the use of a second layer of modelling - the template, that allows the correct expression of the archetype appropriate for the context of use.

Mappings and transformations are acceptable where we don't have any choice, especially with legacy data, but they open us up to vulnerabilities from errors, misinterpretation and ambiguity, concerns re data integrity and possible overt data loss. Given the choice, lets work towards creating high quality data that can be re-used in multiple contexts safely.

Stop the #healthIT 'religious' wars

I seemed to trigger an interesting discussion over on Grahame Grieve's blog when I posted the following question to him on Twitter. https://twitter.com/omowizard/status/432869451739185152

Grahame responded a la blog, but not really answering the essence of my question.

However, below is a great comment copied directly from the discussion thread, and submitted by Koray Atalag (from openEHR NZ). In it he has succeeded in expanding my twitter-concise thoughts rather eloquently:

"Hi guys,

I’m interested in getting these two awesome formalisms as close as possible. In what way – have no clue at the moment apart from existing mutual understanding and sympathy at a personal level. Well that’s where things start I guess ;) Ed Hammond once said, as he was visiting us in Auckland last year, convergence in standards is a must, mappings just become complex and hard to maintain. I kind of agree with that. Where I’d like to see openEHR and FHIR is really dead simple – Share what they are the best. Here is how I see things (and apologise if you find too simplistic): 1) Archetypes are THE way to model clinical information – anyone argue with that? 2) FHIR IS the way to exchange health information over the wire; modern, non-document/message oriented, heaps of interest from vendors etc. 3) openEHR’s Model Driven Development methodology can be used to create very flexible and highly maintainable health information systems. So this is a different territory that FHIR covers. Inside systems vs. Outside. A growing number of vendors have adopted this innovative approach but it’d be dumb to expect to have any significant dominance over the next decade or so.

So why not use openEHR’s modelling methodology and existing investment which includes thousands of expert clinicians’ time AND feed into FHIR Resource development – I’d assume Archetypes will still retain lots of granularity and the challenge would be to decide which fall under the 80%. I take it that this proportion thing is not mathematical but a commonsense thingy.

As with anything in life there is not one perfect way of doing health IT; but I feel that FHIR based health information exchange with propriety (and from the looks increasingly monolithic) large back-end HIS and openEHR based health information systems working with rich and changeable clinical data (note some Big Data flavour here ;)will prevail in this rapidly changing environment.

So I’m interested – probably mapping as a starting step but without losing time we need to start working together.

The non-brainer benefits will be: 1) FHIR can leverage good content – I tend to think a number of Published or Under Review type archetypes have been in use in real life for a while and that’s probably what Heather was referring to by clinical validation. A formal clinical validation is a huge undertaking and absolutely unnecessary I guess unless you’re programming the Mars Colonisation Flight health information systems!

2) openEHR can learn from FHIR experience and use it as the means to exchange information (I haven’t yet seen EHR Extracts flying over using modern web technologies). There is an EHR service model and API but I’d say it is not as mature as rest of the specs.

3) Vendors (and the World for that matter) can benefit from 1) mappings; and then 2) better FHIR Resources in terms of more effectively managing the semantic ‘impedance mismatch’ problem. An example is medication – I’d assume an HIS data model for representing medication should have at least the same granularity as the FHIR Resource it ought to fill in (practically only the mandatory items). If any less you’re in trouble – but having a sound model will ease the HIS internal data model matching and help with deciding which part is 80% vs. 20%.

4) Needless to say vendors/national programmes using pure openEHR vs. FHIR + something else will benefit hugely. Even ones using CDA – remember some countries are using (or just starting as in New Zealand) Archetypes as a reference library and then creating payload definitions (e.g. CDA) from these. So having this openEHR – FHIR connection will help transition those CDA based implementations to FHIR. Interesting outcome ;)

5) I think in the long run vendors can see the bigger picture around dealing with health information inside their systems and perhaps start refactoring or rebuilding parts of it; e.g. clinical data repositories. An HIS with sound data model will likely to produce better FHIR instances and definitely have more capability for using that information for things like advanced decision support etc.

All for now…"

And then the conversation continues, including Thomas Beale from @oceaninfo and Borut Fabjan from @marandlab. I know of many others who have expressed a strong desire for openEHR clinical content and FHIR to be more aligned and collaborative.

FHIR seems here to stay - it is gathering fantastic momentum. The openEHR methodology for developing clinical content is also gathering momentum, including national program adoption in a number of countries and in clinical registries.

Chuck Jaffe (CEO of HL7) emphasised the need for collaboration between standards at last week's Joint Inter-Ministerial Policy Dialogue on eHealth Standardization and Second WHO Forum on eHealth Standardization and Interoperability at the World Health Organisation in Geneva.

So let's do it.

We all live in the real world and need to be more proactive in working together.

It is time to stop the 'religious wars', especially the long-time, tedious 'not invented here' argument between openEHR and HL7 and the ever-ongoing lets 'reinvent the wheel' approach to EHR content that occurs more broadly.

I call on all participants in the eHealth standards world to get the 'best of breed' standards working together.