Practical informatics: Is it safe and sensible to record that a patient has had an adverse/allergic reaction to an unknown substance?
Curious to note that there is very little apparent interest in detailed clinical information models (DCMs) of any brand or flavour in the major Standards Development Organisations (SDO's) - they are effectively Missing In Action when compared to the likes of CDA and IHE profiles. The ISO 13972 DCM specification took a long and tortuous time to travel through the ISO TC 215 processes. Engagement with 13972 during its development, and from what I can observe now it is on the verge of publication has been rather sparse. A further piece of work is now starting in ISO regarding quality criteria for DCMs but it also seems to be struggling to find an audience that understands it, or even cares.
I don't quite understand why the concept of DCMs has not been a big ticket item on the radar of the SDOs for a long time as it is a major missing piece of any standards-based framework. Groups like CIMI are raising awareness, alongside the openEHR work, so momentum is gathering, but for some reason it seems to keep a very understated profile compared to new opportunities like FHIR in HL7.
The work of messages, documents, profiles and terminologies are clearly important for interoperability, but standardisation of clinical content models working closely with terminologies can potentially make the work required to develop messages, documents, and profiles orders of magnitude easier.
Let me test a metaphor on you. Think of each message, document or profile as a sentence and each archetype or DCM as a word, a building block that is one component of each sentence. By focussing on the building a specific sentence, we are working backwards by trying to determine the components, and the outcome is still just that single sentence. However if we start by standardising the words/archetypes, then once they are stable it is relatively simple to construct not only one sentence for a specific purpose, but the potential is a much greater output in which many more additional sentences can be created using a variety of words in different combinations. If we manage the words (archetypes) as core building blocks and get them right, then we allow a multitude of possible sentences (messages/documents/profiles) to proliferate.
The ‘brand’ of archetype/DCM solution does not concern me so much as raising awareness that clinician-led, standardised clinical content is a significant missing and overlooked piece of the international eHealth foundations puzzle.
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.
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.
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."
"...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.
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:
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.
Channelling Bob Dylan? Not quite! But it is interesting to see some emerging HL7 and openEHR activity, at least in this little part of the world – Australia and New Zealand :) Maybe this is a model for the rest of the world - at least food for thought!
For too many long years there appears to have been a palpable barrier between the HL7 and openEHR communities. Some individuals have managed to bridge it, but there has definitely been a reluctance to engage at organisational level. It stems from before my time; I suspect vocal personalities with strong, diverging opinions were at the root. To some, it is a little like a religious argument – where "only my way is the right way"!
Be that as it may - the barrier appears to be softening and became evident to me for the first time back in January last year as I attended the HL7 meeting in Sydney. A full day openEHR workshop was presented by a diverse group of Australian companies plus NEHTA experts; Bob Dolin in attendance, amongst others. Keith Boone tweeted his initial impression of the openEHR approach after I demonstrated our tooling and then blogged about it. My thoughts were captured in my Adventures of a clinician in HL7 post.
Fast forward to 2012…
You may have seen some announcements from New Zealand. Firstly, publication in April of the Health Information Exchange Architecture Building Blocks where they specified "2.3.2 The data definitions of the Content Model shall be formulated as openEHR archetypes" within the "10040.2 HIE Content Model, a framework for the creation of a common set of logical data definitions" document.
And secondly: HL7 New Zealand and the openEHR Foundation signed a Statement of Collaboration - also announced April 2012. Now there's a headline that might have been a surprise to many – HL7 NZ & openEHR clearly intending to work closely together!
Only last Thursday Hugh Leslie & I participated in a seminar, "Bringing the Electronic Health Record to Life," organised by HL7 NZ, Health Informatics New Zealand (HINZ) and the University of Auckland. Prof Ed Hammond, 'the father of HL7', keynoted the meeting: "EHR - The Killer App". In the afternoon mini-tutorials, David Hay presented on FHIR, and Hugh, I and Koray Atalag presented a little about our openEHR work, including clinical knowledge governance and clinician engagement. Koray (a HL7 NZ member and openEHR localisation program coordinator) announced within the meeting that HL7 NZ is the likely organisation to auspice a NZ chapter of openEHR. Now that definitely has to start to change the openEHR/HL7 dynamic somewhat, even if HL7 NZ is a relatively small international affiliate :). The HL7 NZ leadership, to their absolute credit, are certainly not being constrained by any traditional 'turf wars'.
The following day, last Friday, Hugh and I presented a full day workshop on openEHR, again sponsored by HL7 NZ, HINZ and the University of Auckland. As I understand it, this was the first opportunity for the openEHR approach to be socialised with the broader healthIT community in NZ; about 25 in attendance including members of the HL7 NZ Board, vendors, and regional and HealthIT Board reps. The focus was on how openEHR could support the creation of a range of technical artefacts to meet NZ's requirements for CDA messaging (and beyond), generated from a cohesive and governed pool of clinical content models.
Interestingly we had a surprise attendee for the workshop – Ed Hammond joined us for the whole day. I won't presume to guess what Ed has taken away from the day, although he did offer up a comment to the group about the value of exploring use of archetype content directly within CDA.
Post workshop one of the attendees tweeted:
"At #HINZ #openEHR talks last 2 days. openEHR is a fantastic foundation for practical action. Left knowing steps I will take. How cools that!"
And of course, there is an HL7 AU meeting in Sydney early next week entitled "FHIR? CIMI? openEHR? What's the Future of eHealth & mHealth Standards?" The agenda:
- Keynote: Ed Hammond (again) – "FHIR, CIMI and openEHR - What's the Future for eHealth Standards?". [It will be very interesting to hear his opinion after last week's openEHR exposure.]
- Grahame Grieve: "FHIR – What is it? Why has it suddenly become so popular?"
- Hugh Leslie: "Recent developments in openEHR and CDA", and
- I'll be reporting on the CIMI project.
It would be an interesting day to be a fly on the wall! 2 HL7-ers and 2 openEHR-ers addressing an HL7 meeting - all exploring alternatives to the current approaches!
So, keep your eye on the space where HL7 intersects with openEHR – might be some interesting developments.
Within the openEHR community, and definitely within Ocean Informatics where I work, we are certainly finding that significant interest is being certainly generated from many sources about the process of using standardised and governed openEHR clinical content as a means to generate range of technical artefacts, including CDA. The New Zealand national interest and activity is evident, as outlined above. And in addition:
- In Australia, NEHTA has piloted the use of clinician-reviewed archetypes from the NEHTA Clinical Knowledge Manager as the start point for generating a number of the PCEHR technical specifications. This work is ongoing and being extended.
- CIMI, the initiative that grew out of HL7 but is now independent, is seeking to develop an internationally agreed approach to clinical modelling and generation of multiple technical outputs. It has already agreed to utilise openEHR ADL 1.5 as its modelling formalism and is using the openEHR Reference Model as the starting point for developing a CIMI Reference Model. We watch this progress with interest.
- And Brazil's national program has recently reconfirmed its intention to commence using openEHR.
Whether the final solution is openEHR or CIMI or even something else, I think that the advent of standardised clinical models as the common starting point for generation of a range of technical outputs is upon us. Ignore it at your peril. And specifically, I would suggest that HL7 International should be considering very seriously how to embrace this new approach.
Sticking with the quasi-gospel theme, maybe it is now a bit more like Curtis Mayfield's "People Get Ready":
People get ready There's a train a-coming You don't need no baggage Just a-get on board
Let's leave our baggage behind, get on the 'train' together to collaborate and create something that transcends any health IT domain turf war! Don't get left behind...
With the recent public statement from the Clinical Information Modelling Initiative (CIMI) my cynical heart feels a little flutter of excitement. Maybe, just maybe, we are on the brink of a significant disruption in eHealth. Personally I have found that the concept of standardising clinical content to be compelling and hence my choice to become involved in development of archetypes. During my openEHR journey over the past 5 or so years it has been very interesting to watch the changing attitudes internationally - from curiosity and 'odd one out' through to "well, maybe there's something in this after all".
And now we have the CIMI announcement...
So what has been achieved? What should we celebrate and why?
At worst, we have had a line drawn in the sand: a prominent group of thought leaders in the international health informatics domain have gathered and, through a somewhat feisty process, recognised that a collaborative approach to the development of a single logical clinical content representation (the CIMI core reference model) is a desirable basis for interoperability across formalisms. Despite most of the participants having significant investment and loyalty to their own current methodology and flavor of clinical models, they have cast aside the usual 'not invented here' shackle and identified a common approach to an initial modelling formalism from which other models will be derived or developed. Whether any common clinical content models are eventually built or not, naming of ADL 1.5 and the openEHR constraint model as the initial formalism is a significant recognition of the longstanding work of the openEHR Foundation team - the early specifications emerged nearly 20 years ago.
At its idealistic best, it potentially opens up a new chapter for health informatics, one that deviates from the relatively safe path of incremental innovation that we have followed for so many years - the reliance on messages/documents/hubs to enable us to exchange health information. There is an opportunity to take a divergent path, a potentially transformational innovation, where the focus is on the data itself, and the message/document/EHR becomes more simply just the receptacle or vehicle for the data. It could give us a very real opportunity to store lifelong health information; simplify data exchange (whether by messages or documents), aggregation, querying and analysis; and support knowledge-based activities such as decision support - all because we will (hopefully) have non-proprietary, common, agreed and fully defined models of clinical content and known transformations between each formalism.
Progress during the next few months will be telling. In January 2012, immediately before the next HL7 meeting in San Antonio, the group will gather again to discuss next steps.
There is a very real risk that despite best intentions all of this will fade away to nothing. The list of participating organisations, including high profile standards organisations and national eHealth programs, is a veritable Who's Who of international health IT royalty, so they will all come with their own (organisational and individual) work experience, existing modelling resources, hope, enthusiasm, cynicism, political agendas, bias and alliances. It could be enough to sink the work of this fledgling group.
But many are battle-weary, having been trudging down this eHealth path for a long time - some now gradually realising that the glacial incremental innovation is not delivering the long-term sustainable answers required for creating 21st Century EHRs as they had once hoped. So maybe this could be the trigger to make CIMI fly!
I think that CIMI is a very bright spark on the health IT horizon. Let's hope that with the right management and governance it can be agilely nurtured into a major positive force for change. And in the future, when its governance is mature and processes robust, we can integrate CIMI into the formal standards processes.
Best of luck, CIMI. We're watching!
Detailed clinical models are certainly a buzz term in the health IT community in recent years, commonly abbreviated to DCMs. Many people are talking about them but unfortunately, often they are referring to different things. The level of confusion is at least as large as the hype.I sincerely hope that this post helps to lift the veil of confusion just a little...
I've just survived my first HL7 meeting, although amused colleagues tell me that I may not fully recover! ‘Clinician newbie’ to HL7 though I was, for my sins I am becoming increasingly drawn into work within other standards organisations, and my clinical work is no longer with patients but in working with clinicians to develop clinical content models for use in electronic health records. I have some experience of the world of health informatics.
Held relatively nearby in Sydney, it was too good a chance to miss attending an Australian HL7 meeting, and it was an ‘interesting’ experience. The meeting was certainly very casual with a plethora of geeky T-shirts and pony-tails – definitely not the norm at the ISO meetings I’m more familiar with. Some defied this stereotype and still wore their business suits, despite jet-lag and it being a weekend – there are definitely certain individuals that I’ve met over the years who I can only believe must paint the fence in a suit... I particularly remember a certain medical registrar that I worked with many years ago, who always turned up to a resuscitation in Emergency in the middle of the night with a tie perfectly knotted – go figure! But I digress...
I’m told that as the meeting was held outside the US, there was a different flavour of attendee – certainly many from Australia and New Zealand took the opportunity to attend for the first time. I gather many ‘regulars’ didn’t attend and so many of the clinically-related working groups did not meet at all, which was rather disappointing. I spent time in the Patient Care working group and attended the Clinical Interoperability Council. Unfortunately I’m still rather clueless about the remit of the CIC... for clarification in the future perhaps, but clinician-driven approaches to EHR development is a critical way forward, in my opinion.
There was certainly an emphasis on education at this meeting, and it appeared to be very successful with many first-time attendees getting involved, including myself. I attended the Introductory and Advanced tutorials on CDA.
- Without a doubt the absolute highlight was non-work related - the evening ‘networking reception’ held during a sunset cruise on Sydney Harbour (see the photo above). Rather spectacularly, the organising committee somehow arranged for some rather large yachts to breathtakingly race around us just before sunset. Brilliant!
- Sharing a beer, or three, with Keith Boone. I was chuffed when he blogged that he was coming to meet me! And I’m pleased to report that I seemed to have some impact on him after showing some of our collaborative work happening on the openEHR CKM.
- A refreshing open-mindedness towards our work in openEHR. I particularly like the symmetry – I attended Bob Dolin’s Advanced CDA tutorial, and Bob attended our openEHR sessions! We do have potential to learn from each other.
I've definitely been encouraged by some of the HL7 meeting outcomes with respect to openEHR. There was definitely a different attitude towards exploring openEHR/HL7 collaboration:
- A DCM feasiblity demonstration project has been proposed - with input from the Patient Care, Models & Methodology and Templates groups.
- Start with archetypes as the base
- Establish adornments that map these to the V3 Ontology (Structured Vocabulary and RIM)
- Create tools that then consume these to produce useful HL7-V3 artifacts (templates, or such)
- An afternoon was spent discussing openEHR & RIMBAA - focussing on the commonalities between openEHR and HL7 RIMBAA implementation issues
- The opportunity to provide tutorials on openEHR within a formal HL7 meeting – the previous attitudes have been more confrontational than collaborative! Which approach will prevail? Rather than how can we learn from each other! The introductory session in the morning was focused on background and clinical knowledge management. The afternoon had a range of speakers with expertise in application of openEHR/ISO 13606 in the HL7 environment
For the future:
- I'd love to have a chance to engage with the Clinical Interoperability Council - to explore how we can collaborate across technical approaches so that at least as clinicians we can ensure that the clinical content in our desktop EHRs is consistently represented, high quality and 'fit for purpose'. The DCM feasibility project outcome will heavily influence if and when this could productively occur.
- As clinicians we have to ensure our access and input to these technical processes, otherwise we won't end up with systems that support us to provide care to our patients. And I challenge the standards bodies to 'demystify' the technical - to remove the technical barriers that prevent grassroots clinician input and restrict participation to those very few who can bridge the world of software engineering with clinical practice.
Other posts from the meeting:
- Rene Spronk: Ringholm - HL7 and openEHR are cooperating (finally)
- Keith Boone (@motorcycle_guy):