Despite some wins, the transition to EHRs has generally been much slower than we anticipated, much harder than we imagined, and it is not hard to argue that interoperability of granular health data remains frustratingly elusive.
I attended the inaugural openEHR meetings in China last week - this is how I introduced openEHR…
True or false: if we want to achieve any degree of semantic interoperability in our clinical systems we need to standardise the clinical content, keeping it open and independent of any single implementation or messaging formalism?
With the increasing burden of technical engagement resulting from the incredible expectations generated by FHIR globally, perhaps the clinical content specification should be outsourced to... the clinicians first of all, ensuring that the clinical content can be represented in a technical format for implementation.
For many years I have borrowed an analogy using Lego building blocks rather than the notion of generic 'shapes' - that if we get the foundation building blocks agreed and fit for use in our EHRs (ie clinical archetypes), then they can be re-used in multiple contexts and combined in any permutation or combination to represent the clinical documentation that we need.
The outcome of a program of coordinated clinical content standardisation provides a long term and sustainable national approach to developing, maintaining and governing jurisdictional health data specifications. It can form the backbone for a national health data strategy and is a key way to ensure that clinicians contribute their expertise to jurisdictional eHealth programs.
My presentation delivered remotely from Australia to the Arctic Conference on Dual-Model based Clinical Decision Support & Knowledge Management in Tromsø, Norway today.
I've been asked for the classic 'elevator pitch': How does a non-openEHR expert, non-geek explain the notion of developing a library of archetypes to their colleague or boss?
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.
How should we model questionnaires in our health data? This is something that @ianmcnicoll and I have grappled with for years. We have reached a conclusion in recent times, and our approach, perhaps rather controversially, is not to model them! Yes, you read me right - as a general principle, don't archetype questionnaires.
Now of course there will be some situations where there are standardised and ubiquitous questionnaires and perhaps it will be reasonable to lock these down as fixed data elements and value sets in an archetype, and maybe even govern them within a CKM environment.
But... Consider the number of questionnaires out 'in the wild' at any point in time. Should each of these be archetyped?
Let's think it through. If there are 5000 questionnaires in the world (and clearly there are way more questionnaires than that out in the health ecosystem) then we would need a corresponding whopping 5000 archetypes. And, as we all know, no two questionnaires will be alike even if they have a common parent document - it is always human nature to 'tweak' each one for local use because 'our situation' is unique. It's just the way it is. The consequences are that any data captured using the myriad of archetypes, even though they may be similar, the data will not be interoperable. We will have a huge number of archetypes with a huge variation in content and intent - not a lot of upside from my point of view.
Another alternative could be to define a generic archetype pattern for a questionnaire, and re-use that. In fact we tried this back in 2007 with our work in the NHS - you can see a reasonable example here. The resulting questionnaire pattern is pretty simple and relies on using the templating layer to document the questions, and either templating or use of a terminology subset to record the answers. The equivalent FHIR resource appears similar in principle and intended use. This kind of pattern provides a common framework for a questionnaire but really doesn't give us a lot more interoperability for questionnaire data - the actual questionnaire content will vary enormously and the results can still be chaotic.
So, still somewhat clunky and awkward - not an elegant solution at all.
Then we got to thinking: Do we always need to actually record the questions and their answers in the EHR? This is a critical question. Sometimes the answer is yes, but most often I think we will find that we don't need to record the actual question and (often) check box response. What we really want to record is the outcome, the real health information meaning.
Think about the practical aspects of this...
Clinicians have a systematic questioning process for history taking - we all have a similar pattern but ask subtly different questions - resulting in zillions of permutations and combinations and levels of granularity. Questions could range from: "Have you had any abdominal symptoms?" to "Have you had any nausea, vomiting, reflux, abdominal pain, diarrhoea, constipation etc" to whatever combination is relevant for a given clinician in a given clinical situation. Many will ask the same kind of question slightly differently. Every resulting questionnaire will be slightly different.
And what do they record? They don't record each question and corresponding Yes/No answers in their paper health records. They record the positive responses or the relevant negatives, and/or maybe a quick note that there were no positive responses to systematic questioning about current symptoms, problems, past history, family history etc.
So we need to ask ourselves: Do we need to record the exact question, the potential alternative answers and the actual answer?
If the answer is yes, then it is a very good reason to lock in the questionnaire in an archetype, or at least a template.
If the answer is no, then what is the best way to record the relevant data - the relevant positives and the relevant negatives. For example, with abdominal pain - record the details about their diarrhoea and colicky pain in the right lower abdomen, PLUS that the patient has NEVER had an Appendicectomy.
So I'm suggesting that we need to record the positive presence of something identified in the questionnaire, for example a symptom, diagnosis or previous procedure, and the positive absence of related things. In this case, record the details about the diarrhoea and abdominal pain as the positive presence of symptoms using the Symptom archetype and positive exclusion of a previous Appendicectomy procedure in the Exclusion of Procedure archetype. We don't need to record the actual question and corresponding Yes/No answer.
So our current approach in Ocean is to use the software UI as the means to display the checklist or questionnaire, but only record in the electronic health record any relevant answers - both the positive presence of symptoms, signs, diagnoses, procedures and tests etc, and also the positive exclusion of any of these things - all using standardised archetypes.
Lets face it, it is not often that we ever go back to look at the raw questionnaire data again. So now we tend not to record the raw data (with some exceptions, where it may be required or useful) but use a transform so that a patient's or clinician's positive tick in a box for 'Past History of Epilepsy?' will be converted into a positive statement of 'Epilepsy' within an EHR, using the Diagnosis archetype. Any additional 'other' free text or 'details' or 'date of diagnosis' from the questionnaire can be captured using other relevant data fields for the Diagnosis archetype. The benefit from this approach is that this data can then be potentially re-used into the future as part of a comprehensive Problem List, not just buried as a ticked check box within a questionnaire from years ago, perhaps never to see the light of day ever again.
Consider the questionnaire as what it really is - just a clinical communication tool, a checklist. It is absolutely not the best means to record, persist and re-use good quality health data. What we really want to record in a consistent way are those critical pieces of health information in a formal archetype so that the data can be utilised for long term health records, decision support, exchange or analysis. Recording the check boxes answers from a questionnaire don't really do that job!
I received my Walking Jacket at the reception desk of my Italian hotel. I'd just paid an exorbitant amount of tax in exchange for receive my jacket from the Italian Postal Service for my trusty, favourite jacket to be turned into a disruptive artwork by @ReginaHolliday. I first wore it to the Medical Informatics Europe Conference in Pisa in August 2012 and then to the ISO TC 215 meeting in Vienna the following September. I'd heard about Regina and her family's story some time before, my awareness raised purely through the twitter community, and then finding images of her 73 cents mural. I finally met her at HIC12, the Australian health informatics conference in Sydney in early August.
Regina was a keynote speaker and during her HIC address, many in the audience were clearly moved. It is the only presentation that I have seen in the health IT environment that received a standing ovation – powerful stuff. It polarised people. Most loved it and felt inspired; some thought it inappropriate in a healthIT conference – go figure!
Regina and I talked one night at dinner. She offered to paint me a jacket. I felt a bit like a fraud – I have no special patient data faux pas story to tell. My involvement in health IT stems from having a long-term engagement with the health system from the tender age of 5; about how that influencing my decision to become a doctor; and my subsequent, almost accidental, slip sideways into health informatics. Nowadays my work focus is firmly on getting health data right, working collaboratively with international clinicians to agree on common definitions about how to represent clinical content in electronic health records.
And yet here is my jacket – a favourite that I bought way back in 2000 for my first foray out of clinical practice and into the corporate world - my first step into health informatics. I hadn't worn it for a while and Regina's painting has given it a new lease of life. It now has its own story - having travelled to the US to be painted, on to Europe to be worn for the first time in Italy and Vienna, and now back home to Australia.
Regina hasn't explained the image to me. I've asked … and waited. She promised to blog about it, but I think I'll be waiting a while. In her gallery of jackets that tell personal stories, mine is number 176.
So let me share what I think it portrays…
I was hit by a car when I was five years old. As a result I started my first day of school on crutches and in plaster from my waist to my right ankle – that young girl on crutches and wearing a caliper is me. Mini-me!
That accident resulted in some permanent problems and I ended up experiencing a series of operations during my childhood and early teenage years. Way too much time was spent in hospital than was healthy, but I still remember telling my orthopaedic surgeon that I wanted to be a Nurse. I remember him saying 'Rubbish. You shouldn't do that much walking. You should be a Doctor, instead"! Maybe it planted a seed. I don't remember it influencing my decision to enter medicine, but that is where I found myself. I'm not sure that as a young intern and resident years we walked less than the nurses – my memory is we never stopped running!
I practiced medicine for over 15 years, gradually side-stepping into health informatics as I joined my husband in developing, marketing, selling, supporting one of the first prescribing systems in Australia. He was the geek GP, passionate to combine his love of clinical practice with technology. I merely agreed to support him in his venture, having absolutely no idea what I was getting myself into.
That kickstarted the health informatics chapter of my life – 17 years duration to date - which has propelled my husband and myself jointly into the world of business, from cottage industry to large corporate consulting firms, and travel to some extraordinary places.
The adult woman in Regina's image is also me – as the 'omowizard'. This has become my online persona, largely now related to Twitter and blogging. 'omowizard' originated from a love of Tolkien and seeking a Hotmail account back in 2000. Gandalf was taken, as was the 'white wizard'. So given my laundry responsibilities for my young family at the time, I became whiter than white – the Omo wizard. For those unaware, Omo is a brand of clothes washing powder that at the time claimed to wash clothes 'whiter than white'! I never dreamed anyone else would ever have to know or understand that, not even when I experimented on Twitter for the first time as @omowizard. Now it is probably too late to change :)
In the painting I am standing in isolation on a very tall, narrow, bleak pillar. I'm not quite sure what that is representing. Some have suggested a reference to Sauron's tower in Lord of the Rings, but maybe that's too fanciful! I certainly don't have any magic powers. My youngest child informed me recently that I have a strong maternal death stare as a superpower, but I don't think that counts. Maybe it represents the approach that we have been using to standardise the clinical content for health records. It is known as openEHR and although I have been heavily involved in developing the clinical modelling side of it – building archetypes and training others. It has stood in isolation for many years and outside of the mainstream approaches to health IT, but in recent years has become recognised and is gaining increasing recognition as a significant contributor towards the goal of semantic interoperability. Only Regina knows the answer to this one!
The ribbons or strands entwining around the tower are really interesting to me. The main one rippling across the tower reads: "A house divided against itself cannot stand". This appears to be a direct reference to Jesus' words in Matthew 12:25 – "He knew what they were thinking and told them, "Every kingdom divided against itself is destroyed, and every city or household divided against itself will not stand." (NIV 2012). Abraham Lincoln used the phrase in a speech to Republican candidates at the Republican State Convention on June 16, 1858 relating to the danger of slavery-based disunion. Apparently it is still used sometimes in political speeches, calling for unity and working together for a common goal.
The lowest ribbon says simply, 'openEHR'; the one immediately to its right, 'HL7'; and just above it, 'Standards and Interoperability'.
I had described the approach that we are taking with our openEHR clinical modelling to Regina as one in which we are engaging with clinicians and domain experts to verify that the computable definitions that we are building in openEHR systems are fit for purpose. It is a collaborative approach that is crowdsourcing clinical expertise using the Clinical Knowledge Manager tool. For many years there had been little engagement with the HL7 community as a whole, although recently there appear to have been a softening of the lines of political demarcation. Those not constrained by political blinkers can see there could be significant mutual benefit from openEHR content definitions being used within HL7 constructs. Who knows if this will eventuate? And then there are other opportunities such as the CIMI and FHIR projects… Collaborating is the key.
So I interpret the ribbons yielded by the omowizard as another way of Regina calling for collaboration and collective action in healthIT. It seems that she is portraying me as a coordinator of some of the standardisation occurring in healthIT around the archetype work – using the @omowizard's twitter and blogging being one of the means to coordinate and share the passion, perhaps!
I love the painting but in trying to interpret it, it is not a comfortable image for me. I don't like being the focus. I am certainly enjoying my small bit part in the openEHR clinical modelling and health IT standards world. I have come to openEHR when it was relatively immature. We are seeing it grow and become established, but it is definitely not my idea or vision. I'm just one of number who have had the exciting opportunity of being a facilitator for something that I believe will make a difference.
I hope that when I wear this jacket it will trigger some discussions that might further progress in sharing health information and impacting the provision of health care – that is reason enough to wear it.
Thankyou, Regina. My jacket is a piece of art that is beautiful to look at; It is a powerful statement when understood in context of its origins; and is potentially a disruptive force when considered as part of the larger international Walking Gallery movement. I look forward to more opportunities to wear it at home in Australia and in my travels.
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...
Grahame Grieve posted CIMI at the Crossroads recently. I can't disagree with a lot of the content, but maybe I'm a bit more of an optimist as I draw some slightly different conclusions. Grahame is totally right about what it has achieved so far:
- a significant membership roll that has never been achieved before
- a significant agreement of an initial approach to clinical models - a primary formalism of ADL 1.5/AOM with a commitment to support transformation to isosemantic UML models in a spirit of inclusivity and harmonisation.
And as he points out, the notion that the modelling methodology was chosen independently of the Reference Model is somewhat disconcerting.
"...the decision to choose ADL/AOM as the methodology, while deferring the choice of reference model. While I understood the political reality of this decision, choosing an existing methodology (ADL/AOM) but not the openEHR reference model committed CIMI to building at least a new tooling chain, a new community, and possibly a new reference model.
The cost of this is high; so high that the opportunity created by the foundation of CIMI may likely founder if we see another attempt to reinvent the health IT wheel, yet again.
There are many opinions, and everyone at the CIMI table has their own bias, history, experience. Organisational and personal investment in each existing solutions are high. No one wants to throw away their efforts and 'start again'; everyone wants their work to be the successful and sustained.
The CIMI community do need to make an objective decision if it is to move forward. It may not be result which wins a popularity contest. It is very likely that some members will walks away and keep working as they always have; maybe intending to return when a more mature solution is on offer.
In his paragraph on the pros and cons of openEHR, Grahame very eloquently states:
This is the first choice: pick the least worst established clinical modelling paradigm.
"Least worst" - Thanks Grahame! You could turn that around: the 'best' available so far, where there is no perfect solution!
But it's not a bad principle - to take the least worst and make it better!
The chair of the openEHR board, Sam Heard proposed the following to the openEHR community back in October 2011:
“If the CIMI group chooses to use ADL as the formalism then the openEHR community is prepared to explore the Foundation governance arrangements with the CIMI group and align the two efforts using the structures that are mutually agreed.
Changes to ADL and the openEHR Reference Model may be part of the process to meet the collective needs, and alignment of the shared RM and a reviewed RM for ISO 13606 would also be a major goal. ADL 1.5 would be submitted to ISO as part of this alignment.”
Seems sensible to me - start with a robust candidate and modify/enhance it to meet the collective needs. The latest version of the openEHR RM is clearly one candidate. It has evolved significantly from the 2005 version which forms the basis of ISO 13606. Given that ISO 13606 (parts 1-5) is due for revision this year, perhaps we have a great opportunity for harmonisation. The openEHR community is already starting to develop a proposal for the revision, but a greater achievement would be to align all of these efforts into a new 13606/openEHR/CIMI specification.
This is a difficult task that we are trying to solve. We know that because it has not been solved before.
This is definitely not the first crossroad that CIMI has encountered - don't underestimate the effort that has brought the group to this point - and it will definitely not be the last. What will determine success is keeping the end goal front and centre in CIMI's decision-making; cutting ruthlessly through the political and personal agendas; putting pragmatism ahead of perfection; and a willingness to compromise in order to move forward.
It may not be possible. It could be a hell of a ride. I still think it has the potential make a hell of a difference.
We have had the technology for a purpose-built openEHR-compliant 'plug & play' platform for some time; standalone applications have been built, but just recently it appears that the practical reality of an multi-application platform is also about to happen. "We have the technology. We have the capability..." Stay tuned.
...Reminds me of my 1970's hero, Steve Austin, the Six Million Dollar Man. With apologies to Steve:
"We have the technology. We have the capability to make the world's first universal health platform. openEHR will be that platform. Better than ever before. Robust health data...application independent...semantically interoperable!"
No, but we are definitely moving in the right direction... Conversations are happening that were uncommon generally, and downright rare in the US only 18 months ago. I've been rabbiting on for some time about the need for a 'universal health record - an application-independent core of shared and standardised health information into which a variety of 'enlightened' applications can 'plug & play'; thus breaking down the hold of the proprietary and 'not invented here' approach of proprietary clinical applications with which we battle most everywhere today.
So it was pleasing to see Margalit Gur-Arie's recent blog post on Arguments for a Universal Health Record. While I'm not convinced about the reality a single database (see my comments at the end of Margalit's post), I wholeheartedly endorse the principle of having a single approach to defining the data - this is a very powerful concept, and one that may well become a pivotal enabler to health IT innovation.
In addition, Kevin Coonan has started blogging in recent days - see his Summary of DCMs regarding principles of Detailed Clinical Models (aka DCMs). Now I know that Kevin's vision for an implementable HL7 DCM is totally different to the openEHR DCMs (=archetypes) that I work with. But we do agree on the basic principles about the basic attributes of these models that he has outlined in his blog post - it is quite a good summary, please read it.
Now these two bloggers are US-based - and this is significant because in the US there has been a huge emphasis on connecting between systems and exchange of document-based health information up until recent times. I view their postings as indicative of a growing trend toward the realisation that standardisation of clinical content is a necessary component for a successful health IT ecosystem in the (medium-longterm, sooner the better) future.
Note that "Detailed Clinical Models", is the current buzz phrase for any kind of model that might be standardised and shared but is also used very specifically for the HL7 DCMs currently in the midst of an interminable ballot process and the Australian national program's DCMs, which are actually openEHR archetypes being used as part of their initial specification process. "Detailed Clinical Models" is being used in many conversations rather blithely and with many not fully understanding the issues. On one hand it is positively raising awareness of our need to standardise content and on the other hand, it is confusing the issue as there are so many approaches. See my previous post about DCMs - clarifying the confusion.
It is worth flagging that there has been considerable (and I would also venture to say, rather premature) effort put in by a few to formalise principles for DCMs in the draft ISO13972 standard (Quality Requirements and Methodology for Detailed Clinical Models), currently out for ballot. My problem with this ISO work is that the DCM environment is relatively immature - there are many possible candidates with as many different approaches. It is also important to make clear that having multiple DCMs compliant with generic principles outlined in an ISO standard may mean that the quality of our published silos of "DCM made by formalism X" and "DCM made by formalism Y" models might be of higher quality, but it definitely will not solve our interoperability issues. For that you need a common reference model underpinning the models or, alternatively, a primary reference model with known and validated transformations between clinical model formalisms.
The more recent evolution of the CIMI group is really important in this current environment. It largely shares the principles that Kevin, openEHR and ISO13972 espouse - creation of standardised and shareable clinical content models, bound sensibly to terminology, as the basis for interoperability. These CIMI models will be computable and human readable; they will be based on a single Reference Model (yet to be finalised) and common data types (also yet to be finalised), and utilising the openEHR Archetype Definition Language (ADL) 1.5 as its initial formalism. Transformations of the resulting clinical models to other formalisms will be a priority to make sure that all systems can consume these models in the future. All will be managed in a governed repository and likely under the auspice of some kind of an executive group with expert teams providing practical oversight and management of models and model content.
Watch for news of the CIMI group. It has a influential initial core membership that embraces multiple national eHealth programs and standards bodies, plus all the key players with clinical modelling expertise - bringing all the heavy lifters in the clinical modelling environment into the same room and thrashing out a common approach to semantic interoperability. They met for 3 days recently prior to the HL7 meeting in San Antonio. The intent (and challenge) is to get all of this diverse group singing from the same hymn book! I believe they are about to launch a public website to allow for transparency which has not been easy in these earliest days. I will post it here as soon as it is available.
Maybe the planets are finally aligning...!
I have observed a significant change in the mind sets, conversations and expectations in this clinical modelling environment, over the past 5 years, and especially in the past 18 months. I am encouraged.
And my final 2c worth: in my view, the CIMI experience should inform the ISO DCM draft standard, rather than progressing the draft document based on largely academic assumptions about clinician engagement, repository requirements and model governance - there is so much we still need to learn before we lock it into a standard. I fear that we have put the cart before the horse.
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!
The following public statement has been released by the Clinical Information Modelling Initiative today:
The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November - 1 December 2011, the group agreed on the following principles and approach.
- CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.
- CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.
- CIMI is committed to transparency in its work product and process.
- ADL 1.5 will be the initial formalism for representing clinical models in the repository.
- CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
- Modifications will be required and will be delivered by CIMI members on a frequent basis.
- A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language.
- A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.
- Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.
- A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January.
Representatives from the following organizations participated in the construction of this statement of principles and plan:
- B2i Healthcare www.B2international.com
- Cambio Healthcare Systems www.cambio.se
- Canada Health Infoway/Inforoute Santé Canada www.infoway-inforoute.ca
- CDISC www.cdisc.org
- Electronic Record Services www.e-recordservices.eu
- EN 13606 Association www.en13606.org
- GE Healthcare www.gehealthcare.com
- HL7 www.hl7.org
- IHTSDO www.ihtsdo.org
- Intermountain Healthcare www.ihc.com
- JP Systems www.jpsys.com
- Kaiser Permanente www.kp.org
- Mayo Clinic www.mayoclinic.com
- MOH Holdings Singapore www.mohh.com.sg
- National Institutes of Health (USA) www.nih.gov
- NHS Connecting for Health www.connectingforhealth.nhs.uk
- Ocean Informatics www.oceaninformatics.com
- OpenEHR www.openehr.rog
- Results4Care www.results4care.nl
- SMART www.smartplatforms.org
- South Korea Yonsei University www.yonsei.ac.kr/eng
- Tolven www.tolven.org
- Veterans Health Administration (USA) www.va.gov/health
In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (email@example.com)
The Clinical Information Modelling Initiative (#CIMI) is currently meeting in London. It comprises a significant group of healthcare IT stakeholders and was formed some months ago as an initiative by Dr Stan Huff. After a number of face to face meetings and email list exchanges, the intent is that at the end of this 3 day meeting there will be an agreed decision on a common clinical content modelling formalism/methodology for our Electronic Health Records. For background, from Sam Heard’s email to the openEHR email list on November 2, 2011:
The main topic I want to address is the international initiative to develop a standardised clinical modelling methodology. This has some IHTSDO secretarial support and is led by Dr Stan Huff of Intermountain Healthcare, a former HL7 Chairperson and co-founder of LOINC, who has been advocating a model-based approach for many years. The current approach at Intermountain has been influenced by openEHR and uses a two-level modelling approach. Stan has established a leadership group through trust and reputation, which includes a variety of agencies who have been working in the area and national eHealth programs or major initiatives who are interested in consuming the models. It has grown out of an HL7 Fresh Look initiative and is currently known as the Clinical Information Modelling Initiative (CIMI).
The group has committed to determining a single formalism for clinical modelling and ADL and openEHR are on the list of alternatives which is as follows:
- Archetype Object Model/ADL 1.5 openEHR
- CEN/ISO 13606 AOM ADL 1.4
- UML 2.x + OCL + healthcare extensions
- OWL 2.0 + healthcare profiles and extensions
- MIF 2 + tools HL7 RIM – static model designer
Proponents of the five different approaches have been presenting to members of the group, who have a variety of experience in these matters. Fourteen organisations will cast a vote on the formalism to use including openEHR, Singapore, UK NHS, Results 4 Care, HL7, Canada Infoway, 13606 Association, Tolven, CDISC, GE/Intermountain, US Departments, CDISC, SMArt and Mitre.
At the preliminary vote, held recently on November 20, the two most popular options were openEHR ADL 1.5 and UML.
Today CIMI will vote on a proposal for either ADL 1.5 or UML to be adopted as the initial common formalism for use, and determine a road map for coordinated development of semantically interoperable clinical models into the future. The potential impact of this is huge and exciting. It could be a disruptive change in health IT.
We hold our collective breath!
Thomas Beale (CTO of Ocean Informatics and chair of the Architecture Review Board of the openEHR Foundation) posted these two paragraphs as part of the background for his recent Woland's Cat post - The Null Flavour debate - part I. It is an important statement that I don't want to get lost amongst other discussion, so I've reposted it here:
An initial comment I will make is that there is a notion that openEHR is ‘about defining systems’ whereas HL7 ‘is about interoperability’. This is incorrect. openEHR is primarily about solving the information interoperability problem in health, and it addresses all information, regardless of whether it is inside a system or in a message. (It does define some reference model semantics specific to the notion of ‘storing information’, mainly around versioning and auditing, but this has nothing to do with the main interoperability emphasis.)
To see that openEHR is about generalised interoperability, all that is needed is to consider a lab archetype such as Lipid studies in the Clinical Knowledge Manager. This archetype defines a possible structure of a Lipids lab test result, in terms of basic information model primitives (Entry, History, Cluster, Element etc). In the openEHR approach, we use this same model as the formal definition of this kind of information is in a message travelling ‘between systems’, in a database or on the screen within a ‘system’. This is one of the great benefits of openEHR: messages are not done differently from everything else. Neither is interoperability of data in messages between systems different from that of data between applications or other parts of a ‘system’.