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.
The following points summarise my conclusions on all this and the more general Health environment. They are based on private e-mails, the list above and the blog content and comments.
For some reason the topic is quite a 'hot button'. Despite that, all I am really saying is that I believe there are sufficient uncertainties regarding the successful deployment of archetypes to mean more work is required before ISO ballots and standardisation are undertaken. I must say I did not expect the idea to be quite so controversial (the article received four times the usual number of page views in less than two days).
1. Despite concerns regarding interoperability and so on, there is no doubt that there exist a number of commercial providers who offer very usable hospital and ambulatory care systems. In the hospital arena one only needs to think of EPIC, Cerner, McKesson, MiSys, IBA Health and a range of others. In the ambulatory care environment the Certification Commission for Healthcare Information Technology (CCHIT) (www.cchit.org) has certified a range of Ambulatory Systems (over 30 at last count) ensuring quite rich functionality is also available in that sector. This, when combined with experience in Australia, the UK and Scandinavia, makes it quite clear some reasonable level of ambulatory practice automation is more than feasible.
Incrementally more difficult certification criteria, year on year, as applied in the US, will ensure both functionality and interoperability improve over time for both ambulatory and hospital systems. The very recent announcements from Healthcare Information Technology Standards Panel (HITSP) (www.ansi.org/hitsp), as well as the January 2007 IHE Connectathon, only confirms a quite rapid march towards both improving functionality as well as practical, standards based interoperability.
The problem is not that these systems do not work to improve both safety and efficiency but that as yet they are not widely implemented. This bears repeating, the problem is not system capability but the level of deployment.
2. There have been very considerable successes achieved in the Health Sector with messaging technologies including EDIFACT and HL7 V2.x. To date – in the messaging arena - HL7 V3.0 and EN13606 are still in the process of development and tools and implementations are by no means common.
I do not believe standardisation is appropriate for these and other development technologies at this time and feel the Draft Standard for Trial Use (DSTU) approach is preferable by far, until such time as proven, demonstrable, properly scaled, implementations are available.
Use of a DSTU style of progress provides developers and implementers with clear directional guidance and allows progress to be made while preserving flexibility ;more so if the outcomes are less than ideal for modifications to be made.
This being said I do appreciate a “chicken or egg” argument, especially a point made regarding the failure of commercial use and investment until something becomes a Standard. However I believe the OMG / W3C / DSTU approach requiring implementation before finalisation is still to be preferred
3. The transfer (or communication) of a partial or complete Electronic Health Record (EHR) from one system to another system of a different origin, while preserving both the information and the meaning and context of the patient data is a non-trivial task. Even so, it is still an important and very useful objective. The effort to enable communications of patient information between just two providers in the GP2GP program in UK makes it abundantly clear that this is a non-trivial task. Further, as noted above, more general standards in this area are still under development.
4. At another level again there are a number of attempts to develop approaches which will ultimately lead to a standardised way of storing and retrieving longitudinal EHR information which may have been captured over a patient's lifetime. Clearly, for this to be made to work it is crucial to create a methodology that associates clinical observations and activity with its meaning unambiguously, and to be able to reliably document clinical encounters using a consistent approach that does not change over the life of the record.
It is also intended that different implementations of the standardised approach should be able to reliably and safely understand, interpret, process and fully utilise a clinical record from another system – providing so called 'semantic interoperation' if done correctly. Both the openEHR project(www.openehr.org) and HL7 V3.0 (www.hl7.org) aim to achieve this (with minor variations as to scope).
Both approaches have adopted what is called 'two layer' modelling where a basic reference data model is supported by a descriptive mechanism (called an archetype or template) which defines the information content and how it is represented. The outcome of this approach is that as many archetypes as are needed (to represent and describe the information required in a clinical record) can be developed separate from the basic data model which defines the EHR's overall framework. A requirement for this approach to work is that as well as knowing the basic data model, each system must utilise a common set of archetypes or templates to attach the clinical meaning and values to the data.
It is worth noting that the open MRS (Medical Record System) (www.openMRS.org) also implements a two layer concept based model. This system has been used successfully to create purpose-built systems for managing limited clinical domains (such as HIV in Africa). To date I am not aware of any significant production systems based on the other architectures (although I am assured they are coming soon!).
5. It is now becoming clear that the efforts of ONCHIT in the US are bearing considerable fruit (see http://www.dhhs.gov/healthit/), as I believe are those of the UK's Connecting for Health Program (see http://www.connectingforhealth.nhs.uk/)to say nothing of a range of private sector initiatives (Kaiser Permanente Health Connect for example and the ONCHIT trials of prototypes for the US National Health Information Network). This work is really starting to get there, looks to be picking up pace, and is likely, overtime, to simply and pragmatically move forward gathering major benefits while exploiting the proven (and not the experimental) already available Standards. I know where I will be looking for the evidence of real impacts on people's lives and indeed where much of it can be found (see last paragraph).
Sadly, the strategy free zone we call NEHTA is slipping further behind, as best as can be determined, due to a the lack of committed government support and the usual problems associated with herding the fractious States into any coherence.
Where this leaves me is with a quite clear view that very useful Health IT systems are available today and that a dual approach of supporting appropriate and promising R&D needs to be blended with dramatically more energetic investment and deployment of systems which are already known to work and for which the evidence as to their value is quite unarguable.
My priority is, with so much benefit possible and so many lives able to be saved by simply “getting on with it” I think it is vital there is as much more energy focussed on dissemination of what works today than there is on the development of the hoped for 2009 model for Health IT.
This view is very much confirmed by the Health Affairs Online Theme Issue On Rapid Learning Through Health IT referred to in my blog article of the 27th January 2007. The gap between what we are doing today and the good that is possible is huge and must be addressed at a gallop not a dawdle.
David.
Note that the OMG requirement for an implementation happens as the last step in the process and only requires a vendor to claim they have a conformant implementation. There is no real verification of the claim AFAIK.
ReplyDeleteHi,
ReplyDeleteFrom the OMG P&P Manual (definitions section):
Available Specification
An Adopted Specification which has been through the finalisation
process, and with at least one Member able to demonstrate an
implementation.
Key word seems to be "demonstration" not a claim alone.
David.
We heartily endorse the strategy of progressive implementation of systems to validate standards-based approaches. It works well for us as we move forward with HL7 V3 components templates, and OpenEHR archetypes to do real things things in health informatics. It is only doing this that uncovers the nuances that will confound any agency that attempts to mandate a standard before it earns that exalted status. There is good reward for these strategies and each new implementation breaks new ground and contributes to progress. Our view is that part of the NEHTA strategy should be to balance the theoretical with the reality by investing in trial and real projects that prove the ground as they traverse it. Perhaps fewer consultancies and more pragmatism.
ReplyDelete