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.

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.

9 thoughts on “Stop the #healthIT ‘religious’ wars

  1. hi Heather

    Let’s do… .what exactly? You asked what we could do, and I gave an answer as to where we could start. You didn’t like that, but I don’t know what the path is, only where the journey starts.

    And you didn’t answer my questions:
    – what does clinically validated mean?
    – which archetypes are clinically validated? how do you know?
    – can our communities tolerate each other when the going get’s tough?

    And the going will get tough when the difference in perspective (intraoperability vs interoperability – see, or what Koray calls “inside vs outside” above) kicks in

    And finally, the big questions: who’s going to do the work? Who’s going to pay for it?

    • Hi Grahame,

      Lets start with a conversation about how to do this work better and smarter, rather than direct us to map to your work. That’s not collaboration. That’s just more ‘reinventing the wheel’ and patching between the data silos – thus perpetuating our existing problems.

      Freely available, the archetypes in all 5 of the CKMs are a public resource and it would be a shame for the FHIR models not to leverage this collective knowledge as much as possible. There still needs some work to indicate which archetypes are best to use in this increasingly federated approach, but I’m happy to point the FHIR modellers to the most mature archetypes that are available. And if there are gaps identified in the FHIR model development then any contributions to the archetyes would be welcomed.

      I can show you the clinician (and other domain expert) review processes that underpin the openEHR methodology for archetype development that allow grassroots clinicians to participate and ensure that the data used in their EHRs are fit for purpose – but you’ve also participated in this, including taking an editorial role. You’ve experienced, first hand, the collaboration within the maximal (rather than minimal) data set for universal use case mindset – it is quite different to trying to achieve minimal data sets. Correct me if I’m wrong but I don’t recall you having a particularly horrendous experience as an DCM/archetype Editor for NEHTA.

      There is no doubt that there are not as many archetypes published as we’d like, as this process as this hasn’t been adequately resourced by any group to date. However there are significant moves afoot that will hopefully see this change in the next few months, not least the commencement of the Norwegian and Slovenian national program activity in archetype development and review, leveraging and adding to that work done by the international openEHR community and by NEHTA.

      Is it possible to imagine a future where any archetypes developed might be transformed to an iso-semantic FHIR resource in CKM? What if we let the archetypes be a resource for the clinicians to engage with, and the FHIR resources be one of the formalisms for implementation…? Horses for courses!

      The potential interoperability vs intraoperability issue is mitigated by the two level modelling notion – the openEHR notion of templates allow for either approach to operate, with the clinician-led archetypes providing a road map for future intraoperability, while allowing current vendor systems to map their existing systems to simpler templates, or even legacy archetypes where necessary. The archetypes underpinning the PCEHR CDA messages are a good example of this in practice – no one remodelled their primary care systems in order to participate,. The archetypes are effectively a bridge between data in current systems and the ideal data that clinicians determine that they need for direct patient care, message exchange, data aggregation/analysis, CDS, secondary use etc.

      Who will do the work and who will pay is irrelevant if there is no collaboration conversation taking place? The answer to both is probably the same as now – the same people currently modelling in splendid isolation and the same payers (or, rather, lack of them). But if we can change the conversation, maybe there will be more interest in resourcing this work.

      • FHIR does not do with minimal or maximal data sets. There’s a lot of confusion about this – clinicians in particular think we only do 80% of useful fields. No, what we do is what the bulk of systems (mythical 80%) implement. In a highly organised domain with good business agreement, this is a maximal data set.

        I don’t think openEHR does a maximal data set either – if some stakeholder (that is not a paymaster) comes and asks for some thing that only they do, do you add it? When I was involved, the answer would have been no, I think. However I think that many openEHR archetypes are maximal in a different direction. For instance, how many clinicians really collect all the features of the full BP archetype? We’ve learnt that defining all them in the base standard generates real pushback. I think in openEHR where there’s expectation of an expert involved, that works well. But it won’t work in a standard.

        I am working now in the downstream adoption process. I do not think that the archetype / DCM / CDA stack as interoperability with no modifications to underlying systems has worked that well, actually. I don’t think that there’s any meaningful sense in which the archetypes act as a bridge in that stack, though I don’t know that it says very much about archetypes.

        I do think that it matters who’s going to do the work, and who’s going to pay. Unless it’s done by a few key people on either, it won’t matter. And neither you nor I can afford to bankroll it.

        I don’t think you understood about the mapping. You seem to think that I regard that as an end-state. I don’t. I think of it as fact finding – a place to start – what are the real differences that matter, and what would we do about them?

        One last question: is is possible to adapt CKM so that it uses a FHIR RM instead of the openEHR RM? – slightly different data types, and everything would be an element or resource (no cluster etc)

      • Grahame,

        No, openEHR is aiming for a maximal philosophy – it is an ideal, inclusive and embracing as much content as is pragmatic. The intent is to work towards maximal as much as possible, avoiding the controversial minimal data set arguments or defining an arbitrary 80%.

        We don’t get pushback on the maximal dataset because we use templates to constrain the maximal down to the useful for a given clinical scenario. We just express your 20% in a way that supports interoperability, not as an undefined extension. That layer is critical to enabling governed ‘maximal’ data sets but still allow the clinical flexibility required via templates – this is critical. Govern the archetypes like hell, and let the templates express the clinical requirements in implementations. Pretty much the opposite to what you are trying to do.

        Of course it matters who pays – but at present they are funding your work and this work in different directions when in fact the clinical practice providing the requirements is identical. Makes no sense.

        It is always possible to rework CKM to use a different RM or to be RM agnostic – we have been having that discussion with CIMI, but it is not trivial and will be a major rework. The CKM approach is indeed a much better governance methodology for CIMI archetypes or FHIR resources or other DCMs – I totally agree.



        I still don’t see what your criteria for the 80% is? Can you clarify

      • The 80% is based on “What data elements do 80% of all implementations within the space covered by a resource’s scope actually support?” A simpler way of phrasing it is “What do most systems currently do?” If most systems do it, it’s part of the core resource. If fewer than “most systems” do it, it becomes an extension. The scope of resources is human + veterinary, community + inpatient, research + direct care, etc.

        Extensions are defined and used in profiles which take resources and provide more context to them – narrower by geography, type of care, etc. That’s where most of the development work in FHIR will occur. Creating the resources is just the first step. It gives you a basic level of interoperability on the easy things and it sets the wire format for all interoperability. Profiles flesh things out and allow you to define “best practice” or even “maximal” sets.

        The governance on resources is the ballot process. The governance on profiles is variable. They could be balloted through HL7. They could be published by HL7 without balloting. They could be vetted by IHE. They could be directly published by OpenEHR. They can be created by professional associations. They can be created by healthcare delivery organizations. Anyone who wants to create profiles is free to do so under whatever governance frameworks they find useful. It’ll be up to the market to determine what profile and governance approach is most useful and which profiles will actually see up-take. (My expectation is that those that focus on ease of implementation and data capture over clinical comprehensiveness are likely to see broadest use.)

  2. On the assumption that we’d be able to create some seamless way of using mature c,inical requirements models (whether Archetypes or DCMs or anything else) as input for the creation of Resources:

    1. There would need to be a process to identify the mature Archetypes/DCMs (note I’m purposefully not using the words ‘clinically validated’);
    2. There would need to be a process to determine what the 80% is (as indicated by Grahame). Requirements models tend to be all inclusive, and HL7 has learned from HL7 v3 that this will yield a standard that is ‘too hard’ to implement;
    3. There would need to be a process for implementers to state that the resource (in addition to the elements derived from the clinical reuirements model) should contain additional elements, even as part of the base 80%. Real (current) implementations may deal with things differently than as expressed/identified as part of the clinical requirements;

    All of this is governance, and not a technical issue. Governance that will span two different organizations, that each have different decision making processes.

    FHIR (again) is an opprtunity to bridge/unify healthIT standards. Religious schisms, like code forks (not wishing to put those two on a par, but you catch my drift) are plenty, “joins” are few and far between – they are certainly not impossible however.

    • Thanks Rene,

      I don’t understand the arbitrary 80% rule for FHIR and any extension is by definition non-interoperable. openEHR uses the two level modelling to make the level of complexity exposed for clinical use manageable at implementation. Slots in each archetye could be used to allow these extensions – we often do that anyway as part of generic design patterns and specifically for localisation purposes.

      I’d also note that at present the clinical engagement or any verification process for FHIR resources is not easy, nor are there transparent governance processes to support it, as I understand it. Please correct me if I’m wrong.


      • All FHIR resources are subject to balloting – with participants from the clinical community as wel as other communities. As such a tried and tested governance process.

        The point of your first section eludes me – by definition FHIR tries to identify those elements most common in current implementations; as such there is an implementation model with universal scope, with additional extensions for local (regional, country wide, project) scope. My point is that we need a governance process to determine what’s in the ‘universal 80%’ is, versus what would be an extension.

        How one expresses that 80% in one clinical requirements modeling methodology or another is a different question, which is more of a technicality.I’m sure we can flag the 80% in OpenEHR models, DCM or CIMI. *what* 80%, that’s the issue.

      • Rene,
        We are not dealing with high powered specifications here, we are dealing with clinical content which needs a completely different, agile and responsive governance process. What works for 13606 or 18308 or 21090 is way too heavy handed, over engineered and glacial for the requirements for clinical information models.

        If that is what will be used to govern every tiny piece of clinical content, then we will be in trouble.

        And there is much more to governance than balloting…


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