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.

8 thoughts on “Archetypes: health data bridges

  1. It seems really odd to say that “Our openEHR archetypes are attempting to bridge all of these” when this discussion started with a proposal to remove an element that people use because experts think it’s no safe. What is it that you are trying to achieve here?

    • No oddness here. I raised a discussion point about a data element in a FHIR model. Is it really safe or just perpetuating legacy data? If there might be safety issues it seems a reasonable thing to raise? The data element in question has significant divergence between the values in the FHIR resource and the values that other HL7 Patient Care clinicians regard as safe. In reviews a number of years ago, clinicians in AU wanted it removed.
      In the HL7 and openEHR communities there is currently not a clear consensus regarding the Criticality data element in allergies/adverse reactions.

      Bridging with archetypes means finding a mechanism to try to bring the content for all requirements together sensibly and safely – we are not just interested in exchange or EHR persistent, but both of these and the broad range of other contexts and uses.

      WRT to the Adverse Reaction archetype, we have had significant push back in AU and that is represented in the current AU archetype. However there is now a desire from other geographical regions to re-explore this and so we plan to run a new clinical in the international openEHR CKM to attempt to resolve this and other outstanding questions.
      Whether the clinical community decides to include, exclude, or represent this data element differently, then the archetype should provide advice on how to manage legacy data safely.
      We will see what advice they provide us…


  2. Hi Heather,

    The secret sauce in Open EHR (templates) is the same secret sauce as in FHIR (Profiles).

    Of the three models you listed, you can’t possibly eliminate the first type of model – that of legacy data. Legacy data exists and will always exist. And it’s not common for systems to refactor their internals (and historical data) at the behest of an interoperability standard. In FHIR, we do our best to make the leap from legacy to exchange as minimal as possible. This makes it easier for more systems to share data (and hopefully reduces the risk of them sharing). The core resource structures are focused purely on exchange, not best practice. However, by using Profiles on top of those core structures, we can define what best practice is.

    The theory is that if we make it easy for implementers to share and also make it easy to see what best practice is (taking into account that best practice in a refuge camp in sub-Saharan Africa may be a tad different from a teaching hospital in downtown Sydney or Boston), that implementers will gradually migrate towards that best practice.

    With FHIR, you don’t get guaranteed interoperability on all data elements, but you get a high likelihood of interoperability on the most common ones, a decent chance of interoperability on the others and a fall-back of human-readability when things don’t quite work as desired. (Obviously you can guarantee interoprability by ensuring everyone communicating uses exactly the same profiles, which works well in narrow or regulated environments, but is rather challenging to achieve for interoperability in general.)

    From FHIR’s perspective, “best practice” is a context. In order to talk about best practice, you have to be operating under a particular set of assumptions (including that you’re dealing with “practice” at all – as opposed to secondary use, regulatory submissions, etc.). Best practice is not something that typically has global consensus, and even if that’s achieved, it doesn’t necessarily remain stable. As well, best practice tends to be best expressed in narrow circumstances. Attempting to state best practice for something as broad as “Observation” or “Procedure” is non-nonsensical.

    FHIR Resources are designed to be context-agnostic. We don’t care what communication pattern you’re using. We don’t care what country or culture you’re exchanging data within or across. We don’t care if you’re dealing with humans or cows. We don’t care if you’re fighting depression in Alaska, heart disease London or dysentery in Mogadishu. And we don’t care if the data being shared reflects best practice, worst practice or anything in between. The wire format shouldn’t care about any of those things. Caring about those things makes the wire format fragmented, fragile and unstable.

    Contexts (including best practice) are best handled at the Profiling/Templating level. It allows additional rules and rigor to be brought in based on context. Profiles can be introduced and evolve and change without changing the wire format (and thus without breaking existing systems). They can be broad or narrow.

    So with FHIR you end up with two primary models – the system’s internal model and the exchange model (with a relatively narrow gap to cross between them). The “best practice” model sits atop the exchange model extending and constraining it as necessary for context.

    • 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 a 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.


  3. It’s hard to have a constructive debate when people stop listening and learning from past mistakes. Do we need FHIR if all-in-all is just another integration technology?

    FHIR started climbing the hype cycle and HealthIT is all thumbs-up for a “spec” which could bring better outcomes (“value”) from all digital world. Will FHIR justify high hopes?

    Well, right now FHIR spec reminds me most of “The Emperor’s New Clothes” story. Why?
    Essentially it’s not much more then a document repository (IHE XDS) wrapped into REST API.

    a) Content
    Content has a weak “semantic” underpinning and instead of building on “knowledge” builds on
    “integration” paradigm. What’s the difference? Huh, Math would be a funny story if we would base it on integration paradigm – counting sequence might sound more like 1,3,5 – instead of N+1.

    With CIMI work underway I would “urge” to align at least on concepts (two level modelling – Archetype/Template or DCM/Profile if you want – but I think profile != template) instead of having schizophrenic Observation Resource which is all & nothing at the same.

    b) Query

    If you take even the simplest scenario getting documents (compositions) where;
    systolic > 150, diastolic > 110 and temperature > 100

    Well, it’s far, far, far away from being web developer friendly. And it’s a really simple scenario.

    Coming from developer’s prospective building nextgen health applications, … well, FHIR doesn’t show any advantage over “vendor” dependant REST API and brings rather low value proposition.

    Maybe I grow over-expectation for FHIR, but I guess customers are expecting something more this days. Give us something useful with a joy to work with.

    Call for FHIR action, not ammunition to shoot whoever gives constructive criticism.

  4. a) FHIR’s semantic underpinnings are the RIM – whether that’s weak or strong is a matter of opinion (there are a lot of vocal ones out there :>) There’s a full expectation that CIMI’s work (and OpenEHR’s work) will be incorporated into FHIR – but most of it will be at the Profile level, not at the resource level. Resources must be context independent, and few DCMs and archetypes are independent of context.

    b) Even if you formulated this query, you wouldn’t necessarily get the results you wanted. First, the data of interest might not be combined into a Composition at all. Second, what you presumably want is a situation where all measurements happen within close time proximity. That’s not a terribly straight-forward (or even possible) thing to do using the standard REST query parameters, but the Query structure would allow it to be defined and used. Query can also be used with SPARQL and other query mechanisms that might be more amenable to what you’re interested in doing.

    Keep in mind that defining such a query in an environment where the codes, units of measure, etc. are unconstrained (as they must be at the international level) is going to be tricky. Doing it in the context of narrower implementation environments (Profiles) will be easier.

    The benefit over vendor-dependent REST APIs is vendor-independence – which is generally one of the objectives of interoperability. However, vendor independence does carry a price of increased complexity because you can no longer depend on common approaches or terminologies.

  5. Lloyd,
    this is an interesting thing to say:
    “Keep in mind that defining such a query in an environment where the codes, units of measure, etc. are unconstrained (as they must be at the international level) is going to be tricky. Doing it in the context of narrower implementation environments (Profiles) will be easier.”
    Why do you think nothing can be constrained at the international level? It’s already being widely done…
    You are right of course that local codes tend to be applied to more local archetypes and templates, but international ones e.g. LOINC, SCT are more and more commonly included in bindings of national or international archetypes.
    BTW, openEHR templates consist of further layer(s) of archetypes that use ‘slot filling’ and various kinds of removal and mandation to arrive at a final data set. Templates can themselves be templated/reused to as many levels as needed, corresponding to more localisation and/or specialisation. Do FHIR profiles work like that? Is there a published formal definition of profiling? That would be useful, since it will tell us if we can generate FHIR profiles from archetype/templates or not.

    • Hi Tom,
      Constraining at the international level, particularly with the scope of the core structures is difficult because the breadth of the use-cases involved and because of the different needs of different locations. While SNOMED might be great, it’s only great if you’re a member country (or if you’re a poor country who has access to the expertise needed to take advantage of the free licensing available). HL7 (and FHIR) can’t constrain ourselves to just that pool. Differences can happen in other areas too. E.g. is capture of race code mandatory, rare or even illegal?
      Profiles work very much like templates. You can constrain things out, add new things in, take repeating structures and place different constraints on different repetitions, etc. Profiling is handled using the Profile resource ( You might find this presentation helpful too:

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