Question: openEHR and FHIR

Question from Heather Leslie:

How to get more cooperation bw FHIR resource devt & clinically verified openEHR archetypes to shared data roadmap for future?

Answer Questions in response:

Well, my immediate question is, “what does clinically verified mean?” Is there any archetypes that are clinically verified, and how would we know? The openEHR eco-system has several different versions of most archetypes, each with different clinical stake holders involved to a variable degree. Which, if any of them, are clinical verified , and by who? And what does “verified” mean – other than that it’s being used (happily?) in practice?

I’m sure I’ll get vigorous response to these questions on the openEHR blogs – I’ll link to responses from here.

Having said that, I would love to get more involvement between openEHR and HL7 on the design of the clinical resources. The openEHR community has a higher level of clinician involvement, and does tend to have a practical focus, and these are good things that I’d love to link into the FHIR process, and if that drives further convergence between the communities, then that’s even better.

As for a process, well, it’s a good time to kick off a new process – the FHIR DSTU has been published, and we’re back to asking big questions around what changes and improvements that next version of FHIR will have. I would think that the process starts with a mapping between the FHIR resources and the relevant related openEHR archetypes. In fact, a few members of the openEHR community were going to initiate that process themselves, but nothing has eventuated yet. If we focus on the existing resources, and get the process and the concepts sorted out there, then this will automatically grow into proposals for new resources.

If anyone in the openEHR community wants to have a go at that, I and other members of the FHIR community will be happy to review the mappings and help out with the process.






  1. So Grahame, do I understand correctly that you see that there is no role for cooperation in developing the resources, only in mapping between the formalisms after development? Let’s keep reinventing the wheel…

    • Grahame says:

      No, I don’t think that’s what I meant. I suggested this as a place to start, not a place to finish – We need to build trust and good will at several levels, and I don’t want to lock a process down before it starts; that’s not the FHIR way

  2. Not completely on topic but I was triggered by your comment on mapping and I wanted to share how we map OpenEHR archetypes onto a friendly REST API.

    We use OpenEHR to store medical information. In order to create a friendly JSON
    based REST API which others can use, we automatically
    convert the OpenEHR archetype into a REST API. We have a tool which creates a Java object model, the API and the client and server code using the archetypes.

    This way our API is “clinically verified” and based on OpenEHR archetypes.

    Maybe something similar can be used to automatically map OpenEHR archetypes to FHIR?

    Please see for more information.

    Ralph van Etten

  3. Koray Atalag says:

    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…

  4. Lloyd McKenzie says:

    A few things we need to figure out:
    1. FHIR’s scope is intrinsically broader than OpenEHR’s (at least as I understand OpenEHR’s scope). It covers human + veterinary + clinical trials + secondary use/analysis and is intended to support the gamut of behaviors from super simple community systems to cutting edge discipline-specific in-patient systems and everything in between.

    2. FHIR has a bias (in the core spec only) towards “what implementers do”, not necessarily “what implementers should do”. I believe OpenEHR tends to be more biased towards the latter.

    3. OpenEHR also tends to be a bit more focused on “how clinicians see the world”. FHIR is more focused on “how coders see the world”. They’re not that far apart, but they are somewhat different perspectives.

    We can likely bridge those gaps through the use of extensions (some OpenEHR elements will be core, others will be extensions), but it will certainly be a change in approach.

    I am definitely supportive of getting OpenEHR content properly reflected in FHIR, both through mapping and profiling to start. If we can move beyond that, great. Though I expect most clinical resources in the space OpenEHR covers will be “done” within the next 2 years. There just aren’t that many to do.

    • Thomas Beale says:

      Lloyd, openEHR doesn’t yet cover trials territory that well, it’s true. We are working on that. But for the vast majority of clinical content, the structures are the same. E.g. a BP in openEHR normally has ‘subject’ = ‘self’ (not strings, special objects). So it’s automatically pseudonymised at the Entry level. For aggregated use, if you want things like average BPs for some cohort, then a simpler structure is needed; I think we need to show how both structures are modelled and how the latter can be computed from the former.

      With respect to ‘what implementers do’, I think it should be all about that when it comes to REST, mechanics of data interop etc. When it comes to content… I haven’t met the implementer who knows what to do. Even docs outside their normal domain don’t know that much. I think to develop content schemas that won’t fight with data in real systems, real clinical experts and proper tooling is needed.

      A potential starting point for bridging the gaps: the archetype formalism in its latest form (1.5) is very computable. If we can get the right people together, I think we can see how to generate e.g. proto-FHIR artefacts. We already generate XSDs and APIs, so it must be possible.

      • Lloyd McKenzie says:

        Hi Thomas,

        The challenge we’ve had somewhat in the v3 space with clinician-designed models is that they cover the full breadth of all clinical edge cases and also represent absolute leading edge best practice. They’re also extremely complicated, unaligned with anything that’s implemented now, and of little interest to the implementer community.

        The approach that FHIR is trying to take is to focus on what the majority of implementers do now – even if it’s limited and far short of best practice (or even ‘good’ practice). Because that provides the implementation community with their on-ramp. More sophisticated content can then be enabled through extensions.

        Bringing OpenEHR content into FHIR is possible, but we need to bring the implementer perspective into the clinical content to figure out which parts of the clinical content should be “core” (because the vast majority of the implementer community can already do it) and what will need to be extensions (because only a smaller portion of systems currently supports it).

        This approach has definitely caused discomfort within HL7’s clinical community. Suggesting that the “core” won’t reflect best practice doesn’t go over easily. But designing specifications that don’t actually get implemented doesn’t help anyone. FHIR strives to make it easy to implement for the lowest common denominator to participate. It *also* strives to make it easy for the lowest common denominator to up their game, or at least for those who *have* upped their game to be able to share with and through the lowest common denominator without losing their data.

        Note that our intentions with “core” haven’t necessarily been met in all cases. There are likely elements in core that shouldn’t be, and may be some missing that should be. But it’s not primarily clinical appropriateness that will drive the decision of what changes need to be made.

        • Thomas Beale says:

          Hi Lloyd,

          one thing I believe is of little use to anyone is clinical content designed by people with no understanding of it. When the typical IT-specialist misconceptions get baked into systems and products, we lose years, flexibility and end up in an endless chase for ‘the next message’ that will address the deficiencies of the last one.

          Doing it properly isn’t easy, but it’s working in openEHR in production for some years, and also at Intermountain Health, using CEMs: model-based content forward generated into XSDs and APIs and UI forms that are directly used by implementers. The implementers understand these forms of the models because the tag sets/function names are content specific e.g. ‘set_serum_sodium’ and so on.

          This puts the boundary where it should be: clinical people design the semantics, technical people concentrate on proper IT issues, not trying to work out the data points for smoking or lab orders etc.

          My question here is: why not make use of this capability since it’s there? I wonder why FHIR doesn’t look at existing content models from openEHR/13606/Intermountain (and soon, CIMI) and save a lot of time on that, and potentially design better downstream generations (e.g. more efficient XML, or whatever).

          I don’t understand the attraction in having a world with competing definitions for the same content…

          Some examples: have a look at Nehta templates at – left hand side, press the orange ‘T’, then double click on say ‘Prescription’ or ‘NT HHIMS Audiometry report’. These templates are reprocessed directly in to XSDs and APIs, allowing developers to work with them. Also look at (Intermountain’s model portal).

          Not only that, the data are guaranteed to remain queryable by paths extracted from the models (archetypes), independent of which template the data items where captured in. You store once, retrieve 1000 times…

          Lots of good things are happening in FHIR, but I fear that wheel re-invention is also occurring on the content side. Do you think it would be worthwhile looking seriously at marrying these efforts properly?

          • Grahame Grieve says:

            “clinical content designed by people with no understanding of it”. Indeed. But you don’t have to be a clinician to have some understanding.

            “why not make use of this capability since it’s there” – we did. Well, we looked at anything we were given permission to look at. Not all of the things we wanted to or you mention were.

            To be specific, we started with the NEHTA ckm archetype for lab report. The design diverged from the NEHTA one as real world considerations, further requirements, and implementation experience was brought to bear. The NEHTA one didn’t change, and now I would see it as a problem. Would Intermountain change their production CEM because of HL7 experience? Would openEHR?

            It’s fine to say “take advantage of it”, but what does that mean?

          • Thomas Beale says:

            @Grahame: I’m not thinking so much that FHIR should go and look at random archetypes and CEMs once, and ‘take inspiration’. I’m thinking of actually solving the problem of content-based clinical modelling once and for all.

            To do that I think we would (collectively) need to be working off a single model base, which would probably be the CIMI one.

            The CIMI archetypes will be converted from Intermountain, openEHR, 13606 and anywhere else. The CIMI reference model is nearly stabilised, and preliminary model conversions have been demonstrated from Intermountain.

            Very soon there will be a large number of common clinically designed models available in CIMI, all being actively maintained in their source forms. Over time the location of maintenance may move to the CIMI representation.

            From this model base, various downstream generations will occur – XSDs and APIs for use by developers.

            If these two spheres of activity don’t do anything different, there will be two sets of messages/APIs/resources for the same content. That doesn’t seem ideal to me…

          • Lloyd McKenzie says:

            For concepts at the level of set_serum_sodium, that’s not something that will ever be defined as a resource – that’s something that will be defined as a Profile. And I fully expect that the majority, if not all of those will be created by clinicians. Where alignment (or mapping) needs to occur is between the underlying structure – in this case Observation and the corresponding underlying OpenEHR model. And, as noted, we need to figure out what parts of the OpenEHR model should be Core vs. Extension.

            Observation covers everything from lab data to smoking status to pathology measurements to blood pressure, so that alignment may need to happen with multiple aspects of the OpenEHR model.

            (As a side note, the clinical FHIR resources definitely had clinicians involved in the design process.)

          • Thomas Beale says:

            @Lloyd – I’m a bit confused. There are long resource design discussions on things like ‘date of onset’ in Diagnosis, but lab analytes are out of scope? Is there a FHIR doc online explaining the scope rules? I have probably misunderstood something here.

          • Lloyd McKenzie says:

            @Thomas: Lab analytes are in scope. They’re in Specimen. The scope for each resource is supposed to be defined in the opening paragraph or two of text for the resource (though some do a better job of that than others – one of the things we’re hoping to beef up for the next release.)

            But perhaps it’s me that’s not understanding you?

  5. Koray Atalag says:

    Hi Lloyd, thanks for your response.

    I’d challenge (1) saying openEHR’s scope is all of Health, including health information exchange usage but probably scope is not really the issue here.

    (2) I hear FHIR’s motto and it resonates pretty good but I’m not (one being myself) aware of any impositions on implementers using openEHR specs. That said its Reference Model has been criticised and a number of RM has been reinvented – which all prescribe more or less same boundaries in terms of record organisation, data structures and types etc. I think it’d be fair to say FHIR has its own way of defining/constraining (e.g. data types) – maybe to a lesser extent, I don’t know. Implementers will say 😉

    (3) I’d agree with that – we need best of both worlds to create better systems.

    Re your 2 year forecast I’d say it is even pessimistic; so if FHIR continues to grow at such a pace you might even end up covering more areas than what openEHR has. However I’d challenge that it is not the number but the quality – and especially how to manage their evolution over time by not breaking backward semantic compatibility of collected data. I think this is the real value of the Archetype approach. All I am saying is openEHR addresses both information and implementation sides; kind of problem domain vs. solution domain in software engineering world. Where I see the value in working together is the former – get the content right and let the implementers chose how they want to solve the problem.

    Probably getting too academic but I really appreciate FHIR work 🙂

  6. Borut Fabjan says:

    Hi Grahame,

    coming from OpenEHR world I see a clear advantage using two level modelling (templates/archetype) + Health Data Query language.
    Archetype (or DCM in HL7 lingo) represents a knowledge artefact with maximum set of data. Where templates provide a clean mechanism to address assembly & customisation.
    The split plays nicely; clinicians model archetype, IT guys go for templates, developers get an uniform/consistant framework to build clinical apps.

    When reading FHIR spec,

    a) Resources

    – I like the “resource” approach – a more generic approach to address health related “content”.
    – I like the the effort to provide core/common resources models found on most healthcare systems

    The core administrative resources look ok, but with Observations (core healthcare resource) I get worried.
    The core structure tries to be specific (status, bodySite, …) & generic ([0..1]) at the same time.
    You can clearly recognise elements from lab & classic vitals scenarios – mixed in a single “proto” structure – which somehow doesn’t sound like a catchy tune.

    I speculate CIMI will bring some light on modelling but I hoped FHIR to be early-on aligned. As of now FHIR plays baroque tunes.

    b) Health Query

    Putting data “in” is one side of the equation – but getting out it’s a different beast.

    Let’s take some basic example;
    I want to get compositions where
    systolic > 150, diastolic > 110 and temperature > 100

    Pretty common? FHIR requires separate requests for each (observation) resource, and it’s a client responsibility to collect and join all separate results together. Huh?

    In OpenEHR/Archetype Query Language (AQL) you go with;

    select p,t
    from EHR e
    contains composition c
    contains (
    OBSERVATION p#Blood_pressure and
    OBSERVATION t#Body_temperature)
    p#Systolic/magnitude>150 and
    p#Diastolic/magnitude>110 and

    and you get it all on the silver plate. I would love to see FHIR with better Querying capabilities.

    My 5c. I’m glad to answer to Grahame’s invitation on helping improve FHIR.

    • Grahame Grieve says:

      (a) This has been controversial, and is an outcome of some of the things baked into FHIR around how content is handled, and is something we’re going to be looking at hard. Observation is certainly where the focus of profiling will be – and Profile is the equivalent of template in openEHR. I wouldn’t be surprised if openEHR tooling is applicable in that space

      (b) Yes, the FHIR search has some limitations. We’ve constantly searched for the sweet spot that yields the most outcomes for a reasonable amount of work. Clients always ask for more, more, but the core team implements things on both client and server so we know how much they cost before we add them. We agree that there’s more sophisticated search capabilities that we haven’t added. With regard to launching a query like this, the syntax in FHIR is easy:

      GET [root]?_query=aql&aql=select%20p,t%20from%20EHR …

      and the response is a bundle containing all the matching resources. The trick is defining how AQL works against resources. I expect that AQL is dependent on features of the openEHR RM, and that it couldn’t be used against resources without having to be modified, and I’d be very happy if someone looked into that

  7. Borut Fabjan says:

    (b) _query carries arbitrary value with no semantic underpinning – it doesnt bring FHIR any closer to imteroperability.

    I mentioned AQL because it has some interesting concepts which could be applied to FHIR resources. If you remove few reserved keywords it would work pretty much unchanged on FHIR.

    FHIR starts with a bold pitch line – the future of health interoperability. Hmm. We could wrap XDS in a REST API and we would get pretty much the same.

    This is an invitation. If we play like iin the past we will probably get the same results.

  8. Thomas Beale says:

    Some information on AQL: it doesn’t know anything about any particular reference model, it only knows about archetype paths generally. It’s actually very simple: it has a SELECT/FROM/WHERE outer structure, with archetype paths, aliases, the ‘CONTAINS’ operator (= Xpath //) and a few tricks at the leaf level for matching codes and executing functions.

    If you know the archetypes for some content (any RM), you can write AQL queries for it.

  9. Grahame Grieve says:

    Borut: _query is a place to connect to semantics, so we could define _query=aql to mean the openehr semantics. Which keywords would need to be removed, and would they need replacements? As for xds/rest – this is a subset of what FHIR is

    Tom: well, no rm then. But still, archetype paths – is this the same as resource paths? I think we’d need something for managing resource boundaries, since they are not transparent (implementationally)

  10. Lin Zhang says:

    Link to Chinese translation of This post:


Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen


%d bloggers like this: