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.

4 thoughts on “Technical/Wire…Human/Content

  1. Hi Heather (and Lloyd) & all,

    I think the whole discussion started from the point that both groups are in appreciation of each other and that the world might benefit from collaborative work. At first I found FHIR’s strong motto about being “implementer’s stuff” a bit lip-service kind as it it were we could call openEHR as “clinician’s stuff” but the reality is both are “health informatics/ICT stuff” which is affecting everyone on the consumer/provider/regulator sides. So same goals/methods but different emphasis – what matters to everyone is/should be the quality of end-to-end solutions. Of course we need high quality content, as you rightfully indicate here, but we also need high quality wire mechanisms among others. To this end I continue to see both formalisms as rather complementary. Single big point of contact is the content – rest is pretty well segregated I guess: FHIR’s implementer friendly lightweight (in terms of complexity and learning curve) exchange mechanism and rest of openEHR’s model-driven development stack (which honestly can be quite scary for an ordinary developer).


  2. I wrote some of this in response to the first paragraph and later realized that a chunk of it may have been beating a dead horse. If we’re comfortable with the idea that FHIR Core doesn’t enforce good practice but that Profiles can and should, then you can skip down to the dashed line :>
    The quote is a little bit out of context. It’s not that the FHIR team doesn’t care about good practice vs. bad practice. It’s that we’ve made a conscious decision to say that “You should be able to share what you have, even if you’re not following absolute best practice”.
    There are several reasons for this:
    – “best practice” is not an absolute – it varies both with context and with time. As I mentioned before, best practice in a Boston ER and a Syrian refugee camp are not the same. Best practice 5 years ago and best practice today has changed significantly in some areas. The underlying infrastructure of a standard should *not* be dynamic because being dynamic creates interoperability silos and barriers. We want the wire format used to pass around a blood result to be the same in FHIR 15 years from now, even if the codes and use of the structures may have evolved a bit.
    – It’s exceptionally hard (if not impossible) for a single organization such as HL7 to determine with any level of authority or accuracy what “best practice” is across the full scope FHIR is intended to address.
    – It’s pretty rare that a given system is at “best practice” level with all of the types of data it needs to be able to exchange. If the standard forces best practice everywhere, then it means that very few (if any) systems would be able to be compliant with all of their data
    – The reality of the EHR/EMR market is a tension between implementability, ease of use and clinical best practice. The sweet spot is going to vary and trying to dictate that in the design of the core structures of a standard is unwise.
    – When a standard tries to prevent systems from doing things that we know existing systems do, one of two things happens – many systems don’t use the standard or systems use the standard in abusive ways. Neither of those things promotes interoperability. Realistically, if the base standard is extensible (as it must be to deal with the real world), there’s no way to prevent practical way to prevent implementers from following bad practices anyhow
    – If we can get healthcare systems to make use of the base FHIR structures with the data they’ve got, that provides a platform for them to improve their capabilities to be more in line with best practice.
    Because of the above, we make no attempt to enforce good or best practice with the *core* level of the FHIR standard.
    There may be cases where adjustments are need to the core resource designs themselves. (The chances we’ve gotten everything right in the first go are nil.) However, those adjustments need to be based on the FHIR precept of “what do most systems do”, not “what is best practice”.
    That said, FHIR *does* want to encourage implementations to move towards good practice (even best practice). We just think that this needs to happen using Profiles. With Profiles, you can be more adaptive – different profiles for different types of care, different environments, different time-frames. Profiles can be more easily subject to market forces because they get enforced through user interface constraints, not in the bowels of interchange (and are thus easier to change or to support multiple variants of). Profiles with authority will become defacto (or even legislated) standards for implementation.
    The FHIR core specification is a platform to allow healthcare information exchange. FHIR compliance in itself is not sufficient to establish “adequate” practice. I expect to see RFPs, legislation and other requirements demand not just “FHIR conformant” but “FHIR conformant with profiles X, Y and Z”.
    I think OpenEHR is in an excellent position to be defining FHIR profiles that reflect clinical best practices. If they do a good job of balancing the tension between good clinical care and implementability, those profiles will see significant uptake. And we’re happy to work with OpenEHR to make that happen.

  3. Hi Lloyd,
    all your arguments above about best practice changing over time are of course true – it’s a relative concept. I think Heather’s idea is that the technical infrastructure needs to be able to accommodate ‘best practice’ – whatever it is at a given point in time and place. There are core best practice concepts that can be given the status of international standards in clinical models, e.g. vital signs, basic demographics and so on. And others as you say are local to Boston or an MSF field hospital.
    The key for me is to establish a computing framework that accommodates that changing landscape of clinical semantics – constantly. One key thing the framework has to do is to enable longitudinal querying of detailed patient data over time, even with these changes going on, so that key indicators are still queryable after changes of technology, EMR and clinical models. We’ve discovered that’s doable, with a carefully constructed infrastructure. The key has turned out to be the trio of a) a well-crafted reference model, b) the (now) very powerful archetype language and c) a portable model-based query language. The imminent release of ADL/AOM 1.5 contains major improvements from industrial experience, as well as new knowledge gained from working with IHTSDO and Intermountain experts.
    My hope is to combine this technology with the FHIR concrete resources approach to provide a single single-source model-based standards generation machine for industry.

  4. Accommodating best practice in FHIR is straight-forward. Because of its built in extensibility structures, FHIR can support pretty much anything you can throw at it – best practice, super weird practice and anything in between. What we want in the core resource definitions are only those bits that are well understood, widely implemented and relatively stable – because once they’re in the resource and the resource goes normative, they’re pretty much locked there for all time. All of the more dynamic information that’s less well understood or less widely used is handled as extensions. In some cases, the good practice content will fit the “widely understood, implemented and stable” category and will be in core. In other cases it will fall in the “less understood, not yet implemented and/or unstable” and will be introduced using profiles.
    It should certainly be possible to take the models OpenEHR has created and port them to FHIR, it’s just that some of the model elements may be introduced as profile-defined extensions rather than as core.

Leave a Reply

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

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

Google+ photo

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

Twitter picture

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

Facebook photo

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


Connecting to %s