Grahame Grieve published an interesting blog a few days ago.
CIMI at the Crossroads
Posted on March 15, 2012 by Grahame Grieve
“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 is one of a number of efforts that have been started to try and define a common format for such specifications; all the previous efforts (mostly going by the name of DCM, “detailed clinical models”) have gotten bogged down in methodology questions and political games of various sorts, and they’ve failed to produce something that people might actually use.
CIMI shows every sign of following the same trail to the same dead end.
From the beginning, the CIMI initiative sought to produce a different outcome from previous efforts by trying to be agnostic on the tribal and political issues that have bedeviled the previous efforts. In particular:
- The membership of CIMI included all the significant players in the space, not only some of them
- The charter always included CIMI providing the capability to express the clinical models in a series of different formalisms (i.e. XML, Java, HL7 v2, EN13606, CDA, openEHR etc) by the provision of some “compiler”
The membership point was really new – and for the first time there was real hope that something might come from this. The first task for CIMI was to choose an internal methodology that would be used as the primary expression of the models. The initiative held a meeting in London in Nov 2011 to choose between the following candidate approaches:
- UML/OCL and associated OMG standards
- 13606-2/ADL 1.4
- ADL 1.5 (http://www.openEHR.org)
- Semantic Web technology (OWL, RDF, Protégé, and associated tools and standards)
- HL7 v3 approach (MIF, HL7 RIM, static models and associated artifacts and tools)
The full blog and comments are found here:
The blog goes on to point out a seeming lack of progress and agreement and some indecision on the part of many on just is the right way forward.
This area excited me ages ago but sadly I have rather gone off the boil as I waited for perceptible progress to emerge.
Here are a few blogs on related areas.
Saturday, December 02, 2006
Health IT – What is in the Way of Progress?
In the last few weeks I have been ruminating on what is in the way, and what are the roadblocks, to improved Health IT deployment and use in Australia.
There is no doubt that this is a multi-factorial issue that involves human, technical and financial aspects. If we consider the current situation there are some clear facts.
1. It is possible to build, deploy and have used computer systems that can assist with the operations, efficiency, safety and quality of hospitals. Suitable systems both from here and overseas are available to suit most of the patient management, clinical and administrative operations of both small, medium and large hospitals. The same can also be said systems to operate diagnostic laboratory and imaging services.
2. The same is true in the provision of support for General Practice and Specialist Office Practice with the market beginning to mature and evidence of significant contestability of system selection emerging. (Medical Director’s market share is no longer more than 2/3 of the market with IBA, Genie and Best Practice making some headway). Recent changes in the Commonwealth Practice Incentive Program is also ensuring more of the available functionality is actually being used.
3. Messaging of pathology and radiology results is being widely deployed via a number of providers (Argus, Medical Objects, HealthLink, Promedicus etc). Referrals to specialists are also gradually beginning to happen electronically – albeit as yet in pretty un-standardised form by and large. At present there is a great deal of prescription printing but very little, if any, in the way of prescription transmission electronically.
4. There has been considerable investment on development of a range of Standards which have facilitated the communication of pathology results at the individual test level using HL7 V2 which has made these results more usable. At present, however, a majority of results are still transmitted using the PIT format.
There is no doubt that this is a multi-factorial issue that involves human, technical and financial aspects. If we consider the current situation there are some clear facts.
1. It is possible to build, deploy and have used computer systems that can assist with the operations, efficiency, safety and quality of hospitals. Suitable systems both from here and overseas are available to suit most of the patient management, clinical and administrative operations of both small, medium and large hospitals. The same can also be said systems to operate diagnostic laboratory and imaging services.
2. The same is true in the provision of support for General Practice and Specialist Office Practice with the market beginning to mature and evidence of significant contestability of system selection emerging. (Medical Director’s market share is no longer more than 2/3 of the market with IBA, Genie and Best Practice making some headway). Recent changes in the Commonwealth Practice Incentive Program is also ensuring more of the available functionality is actually being used.
3. Messaging of pathology and radiology results is being widely deployed via a number of providers (Argus, Medical Objects, HealthLink, Promedicus etc). Referrals to specialists are also gradually beginning to happen electronically – albeit as yet in pretty un-standardised form by and large. At present there is a great deal of prescription printing but very little, if any, in the way of prescription transmission electronically.
4. There has been considerable investment on development of a range of Standards which have facilitated the communication of pathology results at the individual test level using HL7 V2 which has made these results more usable. At present, however, a majority of results are still transmitted using the PIT format.
-----
and here:
Sunday, January 21, 2007
Archetypically Stupid!
Recently (December 1, 2006) the Health Informatics Technical Committee of the International Standards Organisation (ISO) released a draft Standard entitled Health informatics — Electronic health record communication — Part 2: Part 2: Archetype interchange specification. The closing date for comments is in March, 2007.
The draft document is on its way through the various ISO and CEN processes towards being approved as one of the five parts of the TC 215 Standard on Electronic Record Communication. (pr13606).
Overall the Standard – if approved - aims to define how extracts of patient records can be safely and reliably moved between two EHR systems which are compliant with the Standard once approved.
Key to the success of the approach being adopted is the use of an information construct called an Archetype which defines how clinical content within the record is to be laid out and interpreted.
The draft document is on its way through the various ISO and CEN processes towards being approved as one of the five parts of the TC 215 Standard on Electronic Record Communication. (pr13606).
Overall the Standard – if approved - aims to define how extracts of patient records can be safely and reliably moved between two EHR systems which are compliant with the Standard once approved.
Key to the success of the approach being adopted is the use of an information construct called an Archetype which defines how clinical content within the record is to be laid out and interpreted.
-----
Last here:
Sunday, January 28, 2007
Archetypes, Standards and All That Jazz – Part 2.
Well it has been an interesting week since I published my short article on archetypes. Sadly the conversation has gone on in a number of places (for quite sensible reasons) but it is hard to form an overview – much less try to distil what I have learnt and heard from all the discussion.
Before reading further I suggest those interested visit the openEHR site and review the “aus health it” thread, starting at the 21 January, 2007 entry. It can be found at:
http://www.openehr.org/advice/openehr-clinical/maillist.html
Initially, for some reason my e-mail is deferred and then rejected at the site (since I am not a registered member) so following some of the conversation can be a little difficult.
Before reading further I suggest those interested visit the openEHR site and review the “aus health it” thread, starting at the 21 January, 2007 entry. It can be found at:
http://www.openehr.org/advice/openehr-clinical/maillist.html
Initially, for some reason my e-mail is deferred and then rejected at the site (since I am not a registered member) so following some of the conversation can be a little difficult.
-----
Well after at least 5 years it seems pretty hard to discern just what practical and usable progress has been made.
A browse of the last six months this blog shows Dr Heather Leslie and openEHR has been also noticing some areas are more than a little tricky:
See here:
This post is really quite useful in getting to grips with where things are:
Are we there yet?
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.
-----
As far as I can discern the core issue with CIMI and DCMs, and why getting a really workable outcome is proving so difficult is due to the very nature of clinical information and how it is used.
Clinical records, by their very nature, are subtle, filtered, complex, incomplete and always only a partial reflection of the thought processes that have led to their creation.
By their very nature a clinical record is more like a novel or a work of art than a bank record and as such is intrinsically very much harder to make computable.
It seems to me the approach we should be adopting is one which goes from the very simple agreed basics and then moves up to the more complex rather than trying to essentially go top down with frameworks and the like which really just seem to magnify the complexity. I am reminded a little of needed to avoid “Boiling the Ocean” with such endeavours and somehow it seems like that is what is being attempted.
As I recall HL7 has been working for close to two decades on their Reference Information Model (RIM) and openEHR has been at the same task for as long I suspect. I have to say that, given the brainpower and skill applied to the whole area, that major decisive progress and agreement has not emerged after this long suggests the whole problem might just be ‘too hard’ or that we are somehow asking the wrong question.
As a pretty smart mate of mine once said - or quoted someone who said - “some models are useful, but all are incomplete”. I am not at all sure attempting to model clinical intuition and insight is at all helpful and I wonder if, in the interests of making at least some progress, we should re-define the problem to something more doable?
Discussion welcome - hate-mail > null.
David.
10 comments:
Re-defining the problem to something more doable is a sensible place to start. We also need to develop a new paradigm enabling disparate vendors to work harmoniously together and share access to their clients. As you might imagine that is a little more difficult. We also need to add some competent leadership and if the last decade is anything to go by there is not too much of that around.
hi David.
Very famous quote, from a statistician: "Essentially, all models are wrong, but some are useful" (http://en.wikiquote.org/wiki/George_E._P._Box).
This is a difficult question - we got working interoperability on the easy stuff a long time ago. What's left is hard. There's various complete frameworks for understanding clinical information, but none of them have proven generally attractive to the users (app developers or clinical users). Doing it peicemeal leads to things that work but you can't scale, and every one dislikes that.
Maybe it's just a hard problem.
Well I don't agree with Grahame. I don't think we have working interoperability on the "easy stuff" now, let alone "a long time ago".
We have problems sharing information reliably about patients because of identity issues. There are significant hospital systems that don't even collect full patient names. We have no standardised method for representing blood pressure measurements. We are nowhere near being able to share medication information because we don't have an adequate drug terminology installed across systems. Australia doesn't have a standard set of names for pathology tests - not even the common ones.
The more systems we try to embrace in a common sharing of information, the greater the difficulty in achieving interoperability because of the diversity of those systems, and the lower the common denominator we seem to expect and accept. On the other hand, the notion that we can readily connect 100,000 systems across the county and have them all share quality data safely, when most of them have never had to share much data before is infantile.
We have some standards for formatting clinical information for exchange, but they are generally not easy to use. Some, like HL7, are not well engineered to cater for change. The recent experiment in the US for meaningful use stage 2, based on the Consolidated CDA (Clinical Document Architecture) is the ultimate example of this folly, with some thousand or more conformance statements, based on hundreds of document fragment rules (templates), written into a Word document like some complex 19th century French statute.
The existing HL7 v2 standards are heavily reliant on terminologies that are inadequate.
We have never had any proper conformance testing of systems against the v2 standards. Vendors can claim conformance to a particular v2 standard unchallenged. Systems can be conformant without being interoperable, because in order to be interoperable they require proper use of good terminologies, which are 'conveniently' outside of the actual standard. We don't have the infrastructure to test the use of terms adequately in current messages.
In my opinion, too few people really care about interoperability, and most of those who do, are not in a position to do much about it.
We see inordinately expensive systems being purchased with little consideration to their interoperability capabilities, and often ne'er a thought about what might happen to their data in five or ten years time when it's time to "upgrade".
Maybe it's just a hard problem is spot on the mark. So too is the comment of 3/18/2012 06:42:00 PM.
Put the two together and you have the way forward. Get NEHTAs PhDs out of their ivory towers and put them out in the real world where the problem solvers live, eat and breathe these issues every minute of every day.
Gnashing of teeth and wringing of hands - God forbid that NEHTA might have to turn to industry and ask for help on how to approach the problem.
#Eric: What made you think I called those things easy? Actually identifying patients is really hard - it's the IT part that makes it hard. As for the rest, I call them hard problems.
And I don't know what you think we should actually do? Is it your preferred option to throw your hands in the air and declare it too hard? Or to reject all the existing work and start again in some new way?
Or just perhaps, things that are less than perfect are actually useful? (like medicine itself)
Well I agree with everyone which I suspect is pretty much half of the problem. Although I must say I lean a little more toward Eric. I am keen to standardise on what we can and to get some value from that while we work out how to do it better and then move everyone. Fifty years of the quality movement suggests this is the easier path.
> Actually identifying patients is really hard - it's the IT part that makes it hard
sigh. It's NOT the IT part that makes it hard
We need a layered approach with this stuff or the complexity will kill it. We do need basic compliance with existing standards and most of the interoperability problems I see in Australia are due to poor compliance with standards rather than a problem with the standard.
You cannot build complex clinical models unless basic compliance is working well, and solid terminology is in place. AMT is a mess and little has been done to localise SNOMED-CT.
Despite what you say above David, Medical-Objects sends more compliant referrals/clinical reports than lab messages between around 20000 users around Australia so it is happening, despite the nay sayers. We are a long way from needing perfect clinical models, what we need first is compliant high quality messages that can be displayed reliably as well as produced. Until we have that the whole idea of needing complex models is a pipe dream. You can't build a skyscraper until the nuts and bolts actually reliably screw together, or it will fall down in the slightest breeze.
Having said that we do have Clinical Models working well in many internal areas, when we know the underlying infrastructure is reliable.
Andrew, Eric, Michael, each make good sense, and yes, it is NOT the IT part that makes it hard.
The first question that comes to my mind is:
Does Medical Objects work closely with NEHTA and, if so, how much notice does NEHTA take of Medical Object's views?
Andrew, I don't in any way diminish what people like MO have achieved. My sole point is to suggest we build from the ground up and incrementally - as indeed you are - rather than over-reach until we have the foundations well and truly nailed.
I guess there are times for grand strategy and other times for incrementalism. I think the second approach may be seen as working best in the domain under discussion at the present time.
Of course that may change in time - but it does not seem all that likely at present.
David.
Post a Comment