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.