In what was almost a throw away line commenting on the recent discussion regarding archetypes
"My view is that the practice of health informatics needs, desperately, to become evidence-based, otherwise we will continue to see hundreds of millions or billions of dollars being poured into the deployment of health information systems based on what is in the sales brochure, or based on tender responses, which tend to be just more elaborate versions of the sales brochures."
Now, while I may disagree that the only current driver of Health IT deployments are sales brochures I find the broad sentiment most compelling. Tim is right in suggesting that the decisions regarding adoption and use of Health IT should be on much the same basis as we seek to consider and manage other Health interventions (drugs, treatment protocols, medical devices and so on).
This led me to consider what such Evidence Based Health Care IT may look like. What follows are my initial thoughts on how the idea could be actualised.
First it would be necessary to decide on the type of evidence that was being sought and in what domain the decisions would be assessed. The health sector has many years experience in the design and execution of clinical trials and there does not seem to me to be any intrinsic reason why such an approach would not be useful.
One can easily envisage trials comparing manual methods of practice with computer supported approaches as well as trials comparing computer systems with varying levels of sophistication in terms of user interfaces, functionality and decision support capability.
An issue which would need to be carefully considered is how, in a trial situation, the quality of the system is distinguished from the skill of the user and possibly patient related factors. We need to recognise that Health IT is much more an enabler of service delivery rather than a provider of services per se and this fact would need to be reflected in the trial design.
Second it would seem reasonable to use the typical types of trial endpoints for evaluation of clinically relevant systems – perhaps modified and controlled in different ways as appropriate. The use of endpoints, such as clinical outcomes, also has the advantage of taking a holistic view of an intervention and not seeing a Health IT intervention purely as a technical exercise – but also as something that involves the patient and the clinician as well as the technology.
Of course it is possible that in some situations there will be the need to consider intermediate outcomes rather than direct impact on morbidity or mortality when considering, for example, differing decision support systems aimed at improving specific clinician behaviours.
Third there is obviously a place for technical trials of different technical approaches to clinical problems evaluated on both technical as well as clinical criteria. In the same vein one would also want, in some circumstances, to ensure parameters such as cost, impact on workflow or efficiency and so on were evaluated as a component of an overall assessment.
Fourth as experience grows one would see, hopefully the emergence of multi centre trials of particular generic interventions and development of appropriate strategies for the conduct of systematic reviews of important interventions. Later expertise would also be encouraged to develop in cost benefit assessments of the different interventions using criteria rather more closely modelled on the Pharmaceutical Benefits Review Committee than what is done by the Therapeutics Good Administration where the focus is more on safety rather then efficacy and clinical outcomes.
Fifth it is important to consider how best the human side of Health IT deployment and use can be researched and practical trials conducted to come up with the best ways to manage system selection, clinician resistance to change, workflow alterations and so on.
Sixth one could consider the establishment of a Cochrane Collaboration like clearing house to make widely available the outcomes of both sponsored research, systematic reviews and so on – as well as Health IT guidelines to assist organisations move forward with an evidence based Health IT Agenda
Last it might make some sense to have at least some research that looks back on failures and disasters (something much beloved of IT project managers) to come up with evidence based guidelines on what tends not to work in the process of selection and deployment of apparently well considered Health IT interventions and systems.
I recognise that it could be said that what is being suggested is little more than what is classically referred to as Health Technology Assessment (HTA). I would suggest the focus on the deployments of, and the evaluation and trial of Health IT against clinical objectives using an experimental model moves a good deal beyond traditional HTA.
Overall, I can see there could be a case built for establishing an academic centre for the development, evaluation and implementation of Evidence Based Health IT.
What do others think? A good idea?
David.
Wednesday, January 24, 2007
Evidence Based Health IT – What a Good Idea!
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.
Without going into too much detail an example of how the Archetype is intended to be used can be better understood as follows.
Assume we wish to place a patient’s blood pressure into an Electronic Health Record (EHR).
In the context of a defined and identified individual patient, an identified healthcare provider (the observer) and the date and time of the observation, it is possible to use an Archetype which has the concept name of ‘blood pressure’. This permits recording of the systolic and diastolic blood pressure values along with associated information (e.g. is this blood pressure part of an assessment for postural hypotension where body position is important or is this blood pressure measured with a described cuff size, etc). Given the detail that may be needed to handle electronic measurements, continuous or 24 hour measurements and so on, the possible complexity becomes obvious if a single archetype is required to handle the concept of ‘blood pressure’. (I guess the response from proponents of Archetypes would most likely be that this would be handled by higher level assemblages of Archetypes, but clearly the downside of this approach is the ultimate number of Archetypes needed).
All the actual data entered is intended to be stored, along with the patient and Archetype identifying information, in an EHR system that can access, when requested, the Archetype ‘framework’ into which the recorded values have been placed. This allows the re-creation of the ‘whole’ of the observation, as needed, in any compliant system. An individual patient record can of course be made up of many data elements (described and constrained by many different Archetypes) to build up a fuller and more complex EHR record.
The benefit claimed for this approach is that any computer system which can locate and ‘interpret’ the correct Archetype can accurately re-present and re-use the EHR information (i.e. provide semantic interoperability between EHR systems). The importance of finding the correct Archetype to utilise becomes obvious here as using a different version of an Archetype, or the wrong Archetype, could be very problematic. This has a range of obvious consequences around the need for effective naming and version control conventions.
Why am I bothering to comment on this somewhat obscure standards balloting event?
The answer is that I simply do not believe use of Archetypes is ready for ‘prime-time’, especially as a global standard, until a vast amount more work is done.
My specific concerns are as follows:
1. The draft standard admits it is unclear how many Archetypes are needed for a successful general purpose EHR and the amount of work needed to create them.
To quote:
Archetype Repositories
“The range of archetypes required within a shared EHR community will depend upon its range of clinical activities. The total set needed on a national basis is presently unknown, but there might eventually be several thousand archetypes globally. The ideal sources of knowledge for developing such archetype definitions will be clinical guidelines, care pathways, scientific publications and other embodiments of best practice. However, “de facto” sources of agreed clinical data structures might also include:
• the data schemata (models) of existing clinical systems;
• the lay-out of computer screen forms used by these systems for data entry and for the display of analyses performed;
• data-entry templates, pop-up lists and look-up tables used by these systems;
• shared-care data sets, messages and reports used locally and nationally;
• the structure of forms used for the documentation of clinical consultations or summaries within paper records;
• health information used in secondary data collections;
• the pre-coordinated terms in terminology systems.
Despite this list of de facto ways in which clinical data structures are currently represented, these formats are very rarely interoperable. The use of standardised archetypes provides an interoperable way of representing and sharing these specifications, in support of consistent (good quality) health care record-keeping and the semantic interoperability of shared EHRs.
In the longer term, it is anticipated that the involvement of national health services, academic organisations and professional bodies in the development of archetypes will enable this approach to contribute to the pursuit of quality evidence-based clinical practice. In the future regional or national public domain libraries of archetype definitions might be accessed via the Internet, and downloaded for local use within EHR systems.”
What is clear here is that not only do we not know how many are needed, but that no-one knows, and more importantly the needed Archetypes do not exist anywhere on the planet!
If one considers the number of diagnostic tests, types of observations and so on that exist I believe “several thousand” is just hopeful guesswork. Of course who is going to develop and pay for all the work required is a separate question.
2. The writers of the quotation above seem to me to be conceiving Archetypes at a level (clinical guidelines and the like) above where Archetype development and definition is needed (i.e. at the level of individual observations and investigations). Only once these basics are developed and stable can construction of the more advanced information constructs and uses begin.
3. It is also obvious that without a global reference source for Archetypes (as well as global governance mechanisms and the required technical, development and managerial infrastructure) the stated goal of sharable, interoperable EHR extracts is little more than a pipe dream. This reference source does not exist and is unlikely to anytime soon. The prospect of local divergent Archetype repositories dotted all around the world, resulting in all sorts of interoperation difficulties, is too horrible to contemplate.
4. There is no reference implementation of a system deploying even a slightly comprehensive set of Archetypes to prove the conceptual and performance capability of Archetype based systems. There seems to me to be little doubt that scalability of Archetype services could be a significant issue.
5. There seems to be some evangelical thrust on the part of Standards Australia (and possibly NEHTA) to spread the use of Archetypes globally (as a special pestilential and mind befuddling treat for the rest of the world) when the local investment in their development and deployment has been minimal, to say the least. If they really think Archetypes are such a great idea putting ‘the money where their mouths are’ would be a good idea!
6. The literature supporting the contemporary use of Archetypes in the draft standard comprises a total of four citations predominantly by only two people.
7. The HL7 Template Special Interest Group is still working (as of October 2006) to resolve how CEN Archetypes and HL7 Templates can be harmonised in ways that make them interoperable whilst recognising that many of the conceptual and operational problems with Archetypes exist just as significantly in the HL7 Template proposals.
8. It seems to me there are much more basic and important things to be standardised before attacking a problem of this complexity which has not been applied or asked for by the real world. Getting basic clinical information available at local points of care reliably and improving care-coordination with the simplest of care records would be a very good start rather than developing this misguided, over-engineered and over-complex standard which I doubt will be seriously considered by more than 50 people and which I suspect will never be actually implemented as intended by its creators. To posit adoption of this Standard without describing the governance, provisioning and funding of the necessary Archetype sever infrastructure is naïve in the extreme.
To be creating 150+ page specification documents on the basis of what seems to be a conceptually ‘good idea’ and to then, without proven reference implementations, launch such documents on an unsuspecting world is downright dangerous.It is likely to hamper more useful and important e-Health developments globally, as an overly complex mess is sorted out – if that is possible.
It is really time for the proponents of Archetypes to ‘put up or shut up’. This is way to serious to just allow this proposed standard to wander though the approval processes without some very hard questions being asked.
Until reference implementations exist and are working and harmonisation with other standards (HL7 etc) is finalised and demonstrable all involved really need a ‘cold shower’ as our politicians are so keen on saying.
David.
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.
Without going into too much detail an example of how the Archetype is intended to be used can be better understood as follows.
Assume we wish to place a patient’s blood pressure into an Electronic Health Record (EHR).
In the context of a defined and identified individual patient, an identified healthcare provider (the observer) and the date and time of the observation, it is possible to use an Archetype which has the concept name of ‘blood pressure’. This permits recording of the systolic and diastolic blood pressure values along with associated information (e.g. is this blood pressure part of an assessment for postural hypotension where body position is important or is this blood pressure measured with a described cuff size, etc). Given the detail that may be needed to handle electronic measurements, continuous or 24 hour measurements and so on, the possible complexity becomes obvious if a single archetype is required to handle the concept of ‘blood pressure’. (I guess the response from proponents of Archetypes would most likely be that this would be handled by higher level assemblages of Archetypes, but clearly the downside of this approach is the ultimate number of Archetypes needed).
All the actual data entered is intended to be stored, along with the patient and Archetype identifying information, in an EHR system that can access, when requested, the Archetype ‘framework’ into which the recorded values have been placed. This allows the re-creation of the ‘whole’ of the observation, as needed, in any compliant system. An individual patient record can of course be made up of many data elements (described and constrained by many different Archetypes) to build up a fuller and more complex EHR record.
The benefit claimed for this approach is that any computer system which can locate and ‘interpret’ the correct Archetype can accurately re-present and re-use the EHR information (i.e. provide semantic interoperability between EHR systems). The importance of finding the correct Archetype to utilise becomes obvious here as using a different version of an Archetype, or the wrong Archetype, could be very problematic. This has a range of obvious consequences around the need for effective naming and version control conventions.
Why am I bothering to comment on this somewhat obscure standards balloting event?
The answer is that I simply do not believe use of Archetypes is ready for ‘prime-time’, especially as a global standard, until a vast amount more work is done.
My specific concerns are as follows:
1. The draft standard admits it is unclear how many Archetypes are needed for a successful general purpose EHR and the amount of work needed to create them.
To quote:
Archetype Repositories
“The range of archetypes required within a shared EHR community will depend upon its range of clinical activities. The total set needed on a national basis is presently unknown, but there might eventually be several thousand archetypes globally. The ideal sources of knowledge for developing such archetype definitions will be clinical guidelines, care pathways, scientific publications and other embodiments of best practice. However, “de facto” sources of agreed clinical data structures might also include:
• the data schemata (models) of existing clinical systems;
• the lay-out of computer screen forms used by these systems for data entry and for the display of analyses performed;
• data-entry templates, pop-up lists and look-up tables used by these systems;
• shared-care data sets, messages and reports used locally and nationally;
• the structure of forms used for the documentation of clinical consultations or summaries within paper records;
• health information used in secondary data collections;
• the pre-coordinated terms in terminology systems.
Despite this list of de facto ways in which clinical data structures are currently represented, these formats are very rarely interoperable. The use of standardised archetypes provides an interoperable way of representing and sharing these specifications, in support of consistent (good quality) health care record-keeping and the semantic interoperability of shared EHRs.
In the longer term, it is anticipated that the involvement of national health services, academic organisations and professional bodies in the development of archetypes will enable this approach to contribute to the pursuit of quality evidence-based clinical practice. In the future regional or national public domain libraries of archetype definitions might be accessed via the Internet, and downloaded for local use within EHR systems.”
What is clear here is that not only do we not know how many are needed, but that no-one knows, and more importantly the needed Archetypes do not exist anywhere on the planet!
If one considers the number of diagnostic tests, types of observations and so on that exist I believe “several thousand” is just hopeful guesswork. Of course who is going to develop and pay for all the work required is a separate question.
2. The writers of the quotation above seem to me to be conceiving Archetypes at a level (clinical guidelines and the like) above where Archetype development and definition is needed (i.e. at the level of individual observations and investigations). Only once these basics are developed and stable can construction of the more advanced information constructs and uses begin.
3. It is also obvious that without a global reference source for Archetypes (as well as global governance mechanisms and the required technical, development and managerial infrastructure) the stated goal of sharable, interoperable EHR extracts is little more than a pipe dream. This reference source does not exist and is unlikely to anytime soon. The prospect of local divergent Archetype repositories dotted all around the world, resulting in all sorts of interoperation difficulties, is too horrible to contemplate.
4. There is no reference implementation of a system deploying even a slightly comprehensive set of Archetypes to prove the conceptual and performance capability of Archetype based systems. There seems to me to be little doubt that scalability of Archetype services could be a significant issue.
5. There seems to be some evangelical thrust on the part of Standards Australia (and possibly NEHTA) to spread the use of Archetypes globally (as a special pestilential and mind befuddling treat for the rest of the world) when the local investment in their development and deployment has been minimal, to say the least. If they really think Archetypes are such a great idea putting ‘the money where their mouths are’ would be a good idea!
6. The literature supporting the contemporary use of Archetypes in the draft standard comprises a total of four citations predominantly by only two people.
7. The HL7 Template Special Interest Group is still working (as of October 2006) to resolve how CEN Archetypes and HL7 Templates can be harmonised in ways that make them interoperable whilst recognising that many of the conceptual and operational problems with Archetypes exist just as significantly in the HL7 Template proposals.
8. It seems to me there are much more basic and important things to be standardised before attacking a problem of this complexity which has not been applied or asked for by the real world. Getting basic clinical information available at local points of care reliably and improving care-coordination with the simplest of care records would be a very good start rather than developing this misguided, over-engineered and over-complex standard which I doubt will be seriously considered by more than 50 people and which I suspect will never be actually implemented as intended by its creators. To posit adoption of this Standard without describing the governance, provisioning and funding of the necessary Archetype sever infrastructure is naïve in the extreme.
To be creating 150+ page specification documents on the basis of what seems to be a conceptually ‘good idea’ and to then, without proven reference implementations, launch such documents on an unsuspecting world is downright dangerous.It is likely to hamper more useful and important e-Health developments globally, as an overly complex mess is sorted out – if that is possible.
It is really time for the proponents of Archetypes to ‘put up or shut up’. This is way to serious to just allow this proposed standard to wander though the approval processes without some very hard questions being asked.
Until reference implementations exist and are working and harmonisation with other standards (HL7 etc) is finalised and demonstrable all involved really need a ‘cold shower’ as our politicians are so keen on saying.
David.
Thursday, January 18, 2007
NEHTA and Secure Messaging – Comments Round Two.
Late last Thursday (11 Jan, 2007) Andrew Shrosbree who is the Technical Architect of ArgusConnect Pty Ltd (http://www.argusconnect.com.au) chose to comment on a request from Tom Bowden (Our First Guest Blogger) in the GP_TALK e-mail list for comments on the technical usability and quality of NEHTA’s document “Technical Architecture for Implementing Services Concepts and Patterns Version 1.0 – 21 December 2006 For Comment.”
Given ArgusConnect’s emerging role in the e-Health Secure Messaging environment in Australia, and the fact that ArgusConnect is being used by a number of GPs and Specialists all over the country, I asked Andrew if I could reproduce the essence of his comments in this blog for the interest of my readers who may not see the e-mail list. He agreed.
The following is the message Andrew submitted:
“Dear Tom
I want to second your request for an assessment by people in our industry of NEHTA's latest specification for secure messaging.
Having reviewed “Technical Architecture for Implementing Services Concepts... "I concur with David More's assessment. The most appropriate phrase from David's blog is "obvious and self evident". To paraphrase my last comments on this list regarding NEHTA's progress, WHERE'S the MEAT?
NEHTA's efforts are not much good to us until they start addressing genuine implementation issues. At the NEHTA conference we were promised code examples and prototypes for the Web Service interfaces, yet instead all we get is more verbiage telling us what we already know. I don't need another lecture about why we should be using this technology, or what a service is. What I'd like to see is some working pieces of code. I don't deny the need for rigour and clear definition of concepts, but when are they going to move along?
My favourite piece of verbiage in the specification is "Information can be modelled and represented in many different ways. This technical pattern recommends that information can be represented using the XML infoset and encoded using the syntax of XML. It also recommends the use of XML Schema to describe those XML documents"
Really? Such language reminds me of Jimmy Carter explaining sagely that "Inflation is caused by many strange and complicated things interacting in strange and complex ways". Um, thanks Jimmy. Anyone else? Anyone?
One concern I do have concerning the content of the specification is the frequent reference to how "the GP Program" will directly access IHI and HPI services. This fails to acknowledge how messaging is actually performed - by third party communication providers, not by the clinical software vendors. If NEHTA is assuming that vendors can be relied on to implement all this stuff then somebody is living in a different universe.
Message providers have been using Web Services for quite a while now (haven't we?) and we may as well continue as usual: forging ahead while we wait for NEHTA to come up with something tangible for us to use as a benchmark against what we have out there, already working in the field.
Finally, I don't quite agree that the specification forms a "roadblock" or in any way impedes progress. Irrelevancy is, well, irrelevant. Nothing it proposes is controversial, wrong, or particularly onerous. Perhaps the development team at NEHTA is run by somebody who worked previously at Foxtel. We are being fed reruns instead of anything new.
I'd like something more for my subscription fee.
Andrew”
It seems from this and the earlier comments from Tom Bowden that there is a soundly based belief that NEHTA is failing to provide the leadership, guidance and impetus for which it was created and for which it has had a reasonable period of time to 'get its act together'.
While it is personally gratifying to have one's judgement of the value of this aspect of NEHTA's work validated by its most obvious customers and stakeholders it is quite unacceptable that, after issuing documents covering the NEHTA desired Technical Architecture of Secure Messaging on 02 Feb, 2006, the industry and the potential users of such services have to wait for a release document which contains little improvement of value.
That NEHTA can work for almost a calendar year and make such little progress does not bode at all well for the other projects for which we have yet to see some deliverables.
The opportunity costs of NEHTA's failure to make any substantial progress is very large and the Australian public deserve a great deal better.
It would not surprise me if NEHTA’s lack of progress actually emerged as an issue in the upcoming Federal Elections.
David.
Given ArgusConnect’s emerging role in the e-Health Secure Messaging environment in Australia, and the fact that ArgusConnect is being used by a number of GPs and Specialists all over the country, I asked Andrew if I could reproduce the essence of his comments in this blog for the interest of my readers who may not see the e-mail list. He agreed.
The following is the message Andrew submitted:
“Dear Tom
I want to second your request for an assessment by people in our industry of NEHTA's latest specification for secure messaging.
Having reviewed “Technical Architecture for Implementing Services Concepts... "I concur with David More's assessment. The most appropriate phrase from David's blog is "obvious and self evident". To paraphrase my last comments on this list regarding NEHTA's progress, WHERE'S the MEAT?
NEHTA's efforts are not much good to us until they start addressing genuine implementation issues. At the NEHTA conference we were promised code examples and prototypes for the Web Service interfaces, yet instead all we get is more verbiage telling us what we already know. I don't need another lecture about why we should be using this technology, or what a service is. What I'd like to see is some working pieces of code. I don't deny the need for rigour and clear definition of concepts, but when are they going to move along?
My favourite piece of verbiage in the specification is "Information can be modelled and represented in many different ways. This technical pattern recommends that information can be represented using the XML infoset and encoded using the syntax of XML. It also recommends the use of XML Schema to describe those XML documents"
Really? Such language reminds me of Jimmy Carter explaining sagely that "Inflation is caused by many strange and complicated things interacting in strange and complex ways". Um, thanks Jimmy. Anyone else? Anyone?
One concern I do have concerning the content of the specification is the frequent reference to how "the GP Program" will directly access IHI and HPI services. This fails to acknowledge how messaging is actually performed - by third party communication providers, not by the clinical software vendors. If NEHTA is assuming that vendors can be relied on to implement all this stuff then somebody is living in a different universe.
Message providers have been using Web Services for quite a while now (haven't we?) and we may as well continue as usual: forging ahead while we wait for NEHTA to come up with something tangible for us to use as a benchmark against what we have out there, already working in the field.
Finally, I don't quite agree that the specification forms a "roadblock" or in any way impedes progress. Irrelevancy is, well, irrelevant. Nothing it proposes is controversial, wrong, or particularly onerous. Perhaps the development team at NEHTA is run by somebody who worked previously at Foxtel. We are being fed reruns instead of anything new.
I'd like something more for my subscription fee.
Andrew”
It seems from this and the earlier comments from Tom Bowden that there is a soundly based belief that NEHTA is failing to provide the leadership, guidance and impetus for which it was created and for which it has had a reasonable period of time to 'get its act together'.
While it is personally gratifying to have one's judgement of the value of this aspect of NEHTA's work validated by its most obvious customers and stakeholders it is quite unacceptable that, after issuing documents covering the NEHTA desired Technical Architecture of Secure Messaging on 02 Feb, 2006, the industry and the potential users of such services have to wait for a release document which contains little improvement of value.
That NEHTA can work for almost a calendar year and make such little progress does not bode at all well for the other projects for which we have yet to see some deliverables.
The opportunity costs of NEHTA's failure to make any substantial progress is very large and the Australian public deserve a great deal better.
It would not surprise me if NEHTA’s lack of progress actually emerged as an issue in the upcoming Federal Elections.
David.
Tuesday, January 16, 2007
AusHealthIT's First Guest Blogger Article!
After a recent article reflecting on the recent NEHTA release of an outline of the technical specifications for secure messaging I was approached by Mr Tom Bowden, the CEO of HealthLink – asking if he could provide a comment in the form of his view as to a sensible 'roadmap' for secure health messaging in Australia.
I thought this was a very good use of the blog and so readily agreed. The article I have been forwarded is reproduced below.
Before handing over to Tom can I also say that Dr Ian Colclough has also been hard at work and has written a comprehensive comment to the earlier post (8 January, 2007) on “Why Implementation Matters”. I commend this also for your careful review. Just click on the comments tag at the bottom of the article.
With that said – over to Tom Bowden.
David.
Imagine a health sector in which nearly all of a General Practice's clinical and administrative communications are electronic. Doctors provide better patient care and they spend nearly an hour less per day on administration. Cutting through the paper-war makes the profession much more financially rewarding and enjoyable. With a universal communications framework available, the government can readily develop and implement national vaccination and screening systems, prepare for pandemics and possible bio-terrorism and speed up implementation of much-needed sector reforms.
Unfortunately if you are a GP in Australia, imagining the above scenario will be close as you get to achieving it in the near future. Australia's track-record in health sector automation (e-health) is among the worst in the developed world. Using another approach, Holland, New Zealand, and some of the Scandinavian countries have almost entirely connected their primary-care sectors. While they haven't solved every problem known to mankind, their family doctors' routine clinical and administrative communication is now all electronic. For example, in New Zealand a doctor is more than three times as likely to use an electronic service to perform a routine task as his or her Australian counterpart
Why is Australia's health system so substantially lacking in this important respect?
The answer is perhaps not one that you would expect; nevertheless, it is quite a simple one. In countries with well developed communications systems, automation of pathology services has been the initial platform upon which a wide range of electronic services has been built. Because of the large volume of information flowing between general practices and laboratories, automation of pathology messaging provides the best opportunity to initiate electronic communications. Beginning with pathology result delivery, a number of countries, including Holland, Denmark, New Zealand and to a lesser extent Canada have been able to build extremely useful standards-based e-health frameworks. These countries have used the opportunity to learn about and implement standards-based communications systems and to build the capacity of the practice and patient management systems that they link. In Australia however, the major pathology companies developed their own individual non standards-based systems for delivering pathology results.
Unfortunately the emergence of the Pathology Information Transfer (PIT) result delivery format as a de-facto standard has severely hampered adoption of internationally supported messaging standards within the Australian health sector. While Australia has a small number of half-hearted implementations of Health Level Seven (HL7), there has been nothing like the uptake of secure messaging seen in other countries. For instance, we now have a range of incompatible HL7 pathology report delivery implementations; approximately one for each major laboratory group.
By far the majority of results are still delivered using the PIT format. As well as being a proprietary, non standards-based message format, a PIT message is unable to be usefully incorporated within an electronic medical record (EMR). A PIT message can only be displayed in its entirety and stored as an object. By contrast, separate data elements of each HL7 message can potentially be incorporated into the EMR of the recipient, which permits the monitoring and display of trends, alerts the clinician to developing problems and significantly enriches the patient's medical record.
Without a reasonable base-level of standardisation in use in the Australian health sector, there is little opportunity to add further standards-based types of communication. The lack of activity has meant that there is a shortage of expertise in communications standards use and thus great difficulty implementing standards compliant services. Furthermore, Practice Management System applications vendors have gained little or no understanding of how to implement communications related capabilities within their application software and thus build better, more useful systems and richer EMRs that are capable of utilising the incoming clinical data.
The really sad thing is that Australia has already spent huge amounts of effort and money developing many of the standards, support services, systems and capabilities needed to do the job. The basic tools to enable there to be a connected health sector do exist; they are just not being used properly.
Unfortunately, instead of drawing upon and utilising pre-existing effort, the National e-Health Transition Agency (NEHTA) is using very little of the immense amount of work that was already underway prior to its formation. NEHTA's wish to start with a clean slate is in some ways understandable given some of the structural difficulties that met them. However, based upon the present rate of progress, it is likely to be some years before we see any implementable results.
Strategic Options
Clearly there has to be a better way of achieving useful results, so let us look at the broad strategic options. Around the world the health sector connectivity issue is being tackled using three contrasting approaches;
1. Implement a nationally funded state-run infrastructure, as is happening in the United Kingdom. This is typically expensive, slow and controversial as a nationally implemented 'one size fits all' communications system is imposed upon the sector.
2. Take a hands off approach, fund development of a few standards and hope that the sector will work together to make things happen. This has been the approach used in the Australian health sector for the past twelve years, since the commencement of electronic communications here. Judging by the results, it has clearly failed and should be discontinued. This approach provides too much opportunity for interested parties to drive the agenda to meet their own individual profit objectives, rather than strive for the good of the sector as a whole.
3. Work in partnership with specialised system integrators and service providers to implement international standards and champion the cause of connectivity. This is the approach that has worked very successfully in Scandinavia and New Zealand where small, specialised service organisations are given government backing and modest financial incentives to ensure that automation actually occurs.
Option Three is the approach most likely to succeed. Highly effective sector integration of the kind enjoyed by other countries will occur when a clear course of action is agreed upon and the task given to organisations whose success is based upon achievement of successful integration outcomes.
Action Is Urgently Needed
To get results I believe NEHTA needs to:
1. Recognise and involve sector participants.
Foster the establishment of an integration community. Encourage the participation of sector players in whose interest it is to make the transition from paper-based to electronic processes, such as Divisions of General Practice, specialised system integrators, practice management system vendors, and industry associations. All of these parties need to work together - not be kept at arms length - to get results.
2. Implement what we already have, properly.
Properly implement existing core HL7 messaging standards (AS 4700.2 and AS4700.6). These are the core messaging standards required to automate 40-60% of all general practice messaging. These internationally recognised, proven standards presently exist in Australia, but they are not properly implemented. The current quality of integration poses significant risks to patients. Industry bodies should be encouraged to demand fully certified implementation.
3. Define ONE standard for each purpose and rigorously enforce it.
Ensure rigorous policing of standardisation to prevent proliferation of different non-standard formats. The Australian Healthcare Messaging Laboratory (AHML) exists to certify all messages. All software organisations and industry players should be required to obtain AHML certification. Immediately, AHML should lead the process of making all laboratories use a common implementation of HL7 (AS 4700.2).
4. (Re)Engage and fully support a single national authentication framework.
Agree upon and implement an easy to use, dependable national authentication framework. This is critical for success. The Australian Health e-Signature Authority (HESA) was set up specifically for this purpose; NEHTA has however not embraced what HESA has done. HESA has since been merged with Medicare Australia. Further work needs to be done with HESA to ensure that the HESA certificates etc are easier to implement and support. (Much has already been done to improve the usability of HESA certificates but this work has since been mothballed.)
5. Tie payment to certified use of standards.
Tie funding policy to the communications strategy. It is important that the payment incentives to all health sector players, especially GPs, hospitals and laboratories, are tied to certified use of communications and security standards. International experience shows that tying payment of incentives to outcomes is an extremely successful way of implementing new communication systems.
6. Focus on achieving simple and measurable steps in the context of a practical, consultative National e-Health Plan.
Ensure that we succeed in walking before we try to run. Beginning with simple readily implementable formats and standards that will deliver day-to-day benefits is key to building momentum. In the health IT integration business success breeds success.
7. Set ambitious but achievable targets and ensure they are met.
Tackle the project in a down-to-earth, business-like manner. Set aggressive adoption targets. Reward participants for hitting milestones with incentive payments, tax-breaks or whatever else will motivate them. Provide disincentives to parties that are dragging the chain.
Conclusion
It's all about setting firm, clear targets and providing the leadership - and incentives - to ensure that targets are met.
At present a number of key influencers have a clear incentive to maintain control of proprietary communications frameworks and thus protect their referral streams and income.
To get real results, this must be turned around. Those parties who can and will help the sector make the transition from paper-based to electronic communications should be supported and where appropriate provided with incentives to do so.
Those who stand in the way of true sector integration need to be reined in and either provided with incentives to change, or prevented from continuing to obstruct progress.
Swift, decisive action in line with the above recommended steps could see Australian GPs, the wider health sector and ultimately the Australian public enjoying the benefits of proper health sector automation within 3 to 6 months.
Let's do what we can to make that happen.
Statement re Potential Conflict of Interest
Tom Bowden is CEO of HealthLink Ltd, an integration services provider operating in Australia, New Zealand and Canada.
I thought this was a very good use of the blog and so readily agreed. The article I have been forwarded is reproduced below.
Before handing over to Tom can I also say that Dr Ian Colclough has also been hard at work and has written a comprehensive comment to the earlier post (8 January, 2007) on “Why Implementation Matters”. I commend this also for your careful review. Just click on the comments tag at the bottom of the article.
With that said – over to Tom Bowden.
David.
A Connected Health Sector
– However Can We Get There From Here? –
– However Can We Get There From Here? –
Imagine a health sector in which nearly all of a General Practice's clinical and administrative communications are electronic. Doctors provide better patient care and they spend nearly an hour less per day on administration. Cutting through the paper-war makes the profession much more financially rewarding and enjoyable. With a universal communications framework available, the government can readily develop and implement national vaccination and screening systems, prepare for pandemics and possible bio-terrorism and speed up implementation of much-needed sector reforms.
Unfortunately if you are a GP in Australia, imagining the above scenario will be close as you get to achieving it in the near future. Australia's track-record in health sector automation (e-health) is among the worst in the developed world. Using another approach, Holland, New Zealand, and some of the Scandinavian countries have almost entirely connected their primary-care sectors. While they haven't solved every problem known to mankind, their family doctors' routine clinical and administrative communication is now all electronic. For example, in New Zealand a doctor is more than three times as likely to use an electronic service to perform a routine task as his or her Australian counterpart
Why is Australia's health system so substantially lacking in this important respect?
The answer is perhaps not one that you would expect; nevertheless, it is quite a simple one. In countries with well developed communications systems, automation of pathology services has been the initial platform upon which a wide range of electronic services has been built. Because of the large volume of information flowing between general practices and laboratories, automation of pathology messaging provides the best opportunity to initiate electronic communications. Beginning with pathology result delivery, a number of countries, including Holland, Denmark, New Zealand and to a lesser extent Canada have been able to build extremely useful standards-based e-health frameworks. These countries have used the opportunity to learn about and implement standards-based communications systems and to build the capacity of the practice and patient management systems that they link. In Australia however, the major pathology companies developed their own individual non standards-based systems for delivering pathology results.
Unfortunately the emergence of the Pathology Information Transfer (PIT) result delivery format as a de-facto standard has severely hampered adoption of internationally supported messaging standards within the Australian health sector. While Australia has a small number of half-hearted implementations of Health Level Seven (HL7), there has been nothing like the uptake of secure messaging seen in other countries. For instance, we now have a range of incompatible HL7 pathology report delivery implementations; approximately one for each major laboratory group.
By far the majority of results are still delivered using the PIT format. As well as being a proprietary, non standards-based message format, a PIT message is unable to be usefully incorporated within an electronic medical record (EMR). A PIT message can only be displayed in its entirety and stored as an object. By contrast, separate data elements of each HL7 message can potentially be incorporated into the EMR of the recipient, which permits the monitoring and display of trends, alerts the clinician to developing problems and significantly enriches the patient's medical record.
Without a reasonable base-level of standardisation in use in the Australian health sector, there is little opportunity to add further standards-based types of communication. The lack of activity has meant that there is a shortage of expertise in communications standards use and thus great difficulty implementing standards compliant services. Furthermore, Practice Management System applications vendors have gained little or no understanding of how to implement communications related capabilities within their application software and thus build better, more useful systems and richer EMRs that are capable of utilising the incoming clinical data.
The really sad thing is that Australia has already spent huge amounts of effort and money developing many of the standards, support services, systems and capabilities needed to do the job. The basic tools to enable there to be a connected health sector do exist; they are just not being used properly.
Unfortunately, instead of drawing upon and utilising pre-existing effort, the National e-Health Transition Agency (NEHTA) is using very little of the immense amount of work that was already underway prior to its formation. NEHTA's wish to start with a clean slate is in some ways understandable given some of the structural difficulties that met them. However, based upon the present rate of progress, it is likely to be some years before we see any implementable results.
Strategic Options
Clearly there has to be a better way of achieving useful results, so let us look at the broad strategic options. Around the world the health sector connectivity issue is being tackled using three contrasting approaches;
1. Implement a nationally funded state-run infrastructure, as is happening in the United Kingdom. This is typically expensive, slow and controversial as a nationally implemented 'one size fits all' communications system is imposed upon the sector.
2. Take a hands off approach, fund development of a few standards and hope that the sector will work together to make things happen. This has been the approach used in the Australian health sector for the past twelve years, since the commencement of electronic communications here. Judging by the results, it has clearly failed and should be discontinued. This approach provides too much opportunity for interested parties to drive the agenda to meet their own individual profit objectives, rather than strive for the good of the sector as a whole.
3. Work in partnership with specialised system integrators and service providers to implement international standards and champion the cause of connectivity. This is the approach that has worked very successfully in Scandinavia and New Zealand where small, specialised service organisations are given government backing and modest financial incentives to ensure that automation actually occurs.
Option Three is the approach most likely to succeed. Highly effective sector integration of the kind enjoyed by other countries will occur when a clear course of action is agreed upon and the task given to organisations whose success is based upon achievement of successful integration outcomes.
Action Is Urgently Needed
To get results I believe NEHTA needs to:
1. Recognise and involve sector participants.
Foster the establishment of an integration community. Encourage the participation of sector players in whose interest it is to make the transition from paper-based to electronic processes, such as Divisions of General Practice, specialised system integrators, practice management system vendors, and industry associations. All of these parties need to work together - not be kept at arms length - to get results.
2. Implement what we already have, properly.
Properly implement existing core HL7 messaging standards (AS 4700.2 and AS4700.6). These are the core messaging standards required to automate 40-60% of all general practice messaging. These internationally recognised, proven standards presently exist in Australia, but they are not properly implemented. The current quality of integration poses significant risks to patients. Industry bodies should be encouraged to demand fully certified implementation.
3. Define ONE standard for each purpose and rigorously enforce it.
Ensure rigorous policing of standardisation to prevent proliferation of different non-standard formats. The Australian Healthcare Messaging Laboratory (AHML) exists to certify all messages. All software organisations and industry players should be required to obtain AHML certification. Immediately, AHML should lead the process of making all laboratories use a common implementation of HL7 (AS 4700.2).
4. (Re)Engage and fully support a single national authentication framework.
Agree upon and implement an easy to use, dependable national authentication framework. This is critical for success. The Australian Health e-Signature Authority (HESA) was set up specifically for this purpose; NEHTA has however not embraced what HESA has done. HESA has since been merged with Medicare Australia. Further work needs to be done with HESA to ensure that the HESA certificates etc are easier to implement and support. (Much has already been done to improve the usability of HESA certificates but this work has since been mothballed.)
5. Tie payment to certified use of standards.
Tie funding policy to the communications strategy. It is important that the payment incentives to all health sector players, especially GPs, hospitals and laboratories, are tied to certified use of communications and security standards. International experience shows that tying payment of incentives to outcomes is an extremely successful way of implementing new communication systems.
6. Focus on achieving simple and measurable steps in the context of a practical, consultative National e-Health Plan.
Ensure that we succeed in walking before we try to run. Beginning with simple readily implementable formats and standards that will deliver day-to-day benefits is key to building momentum. In the health IT integration business success breeds success.
7. Set ambitious but achievable targets and ensure they are met.
Tackle the project in a down-to-earth, business-like manner. Set aggressive adoption targets. Reward participants for hitting milestones with incentive payments, tax-breaks or whatever else will motivate them. Provide disincentives to parties that are dragging the chain.
Conclusion
It's all about setting firm, clear targets and providing the leadership - and incentives - to ensure that targets are met.
At present a number of key influencers have a clear incentive to maintain control of proprietary communications frameworks and thus protect their referral streams and income.
To get real results, this must be turned around. Those parties who can and will help the sector make the transition from paper-based to electronic communications should be supported and where appropriate provided with incentives to do so.
Those who stand in the way of true sector integration need to be reined in and either provided with incentives to change, or prevented from continuing to obstruct progress.
Swift, decisive action in line with the above recommended steps could see Australian GPs, the wider health sector and ultimately the Australian public enjoying the benefits of proper health sector automation within 3 to 6 months.
Let's do what we can to make that happen.
Statement re Potential Conflict of Interest
Tom Bowden is CEO of HealthLink Ltd, an integration services provider operating in Australia, New Zealand and Canada.
Sunday, January 14, 2007
How Many Times Does This Sort of Thing Need to Happen?
If ever there was going to be an independent report that would focus NEHTA’s mind on the need to change direction this is it!
Last week the following article (selected quotes below) appeared in the Toronto Star. The full article can be found at the following URL:
http://www.thestar.com/Business/article/168761
Report slams e-health agency
“Smart Systems is not offering good value to taxpayers, consultancy says”
.....
The agency responsible for Ontario's electronic health infrastructure is poorly regarded in the health-care community, lacks strategic direction, and has not been held properly accountable by Queen's Park, according to an operational review conducted by Deloitte Consulting.
"Given the increased urgency for substantive progress with e-health in Ontario, an aggressive agency-turnaround plan is required," concludes the 100-page report, the outcome of an internal review launched a year ago by Health Minister George Smitherman.”
…..
“The agency, which employs more than 300 people, was created in 2002 and has since received $458 million from Ontario taxpayers as part of its mandate to electronically link and support the province's 150,000 health-care providers.”
…..
“Among the review's findings:
• There has been "little or no meaningful progress" with the creation of an emergency health record for Ontarians, though it was recognized there was "ambiguity" with the agency's role in this area.
• The network designed to link health-care providers is "below standard" when it comes to practices for monitoring performance and security.
• Assessing the agency's performance versus the government's expectations is difficult because "well-defined expectations, deliverables and measurable performance targets have not been established and documented by the ministry for SSHA."
• The Smart Systems' secure email service has fallen well short of expectations, as only a third of the 60,000 accounts that have been installed are being used.
• Though the agency is expected to host sensitive health information, "privacy policies are incomplete and not widely understood" and "many of the procedures necessary to provide guidance and direction have not been developed or are in draft form." In certain instances, "processes are ad hoc, undefined or undocumented."
• Security of patient information was also questioned, as Deloitte said it wasn't clear who was responsible for defining and implementing security controls and technologies. "As a result, sensitive information may not be protected consistently throughout its lifecycle."
A copy of the full report can be downloaded from:
http://www.ssha.on.ca/operationalreview/index.asp
All in all it would be difficult to say the money has been well spent so far.
The Smart Systems for Health Agency (SSHA) was intended to be a provider of connectivity services and standards for the health sector in Ontario, Canada – the largest province in the country with a population of a little over 13 million.
The mandate which the Agency was given in 2002/3 covered the following:
“The mandate at the time highlighted six products to support the priority initiatives identified within the SSHA regulation:
−Managing the private network;
−Providing a secure messaging service and online directories;
−Security infrastructure;
−Physical facilities;
−Voluntary emergency health record;
−Data and technology standards.”
A little later (2004/5) a role in application delivery for the sector was added. All the while the SSHA has been “pursuing a long-term goal of creating a voluntary EHR to allow health care professionals to access patients’ lifetime health histories. To achieve this goal, EHRs will need to connect many sources of information as well as currently independent applications and databases. Establishing electronic connections to allow information from different sources, applications and databases to be shared is the focus of SSHA’s efforts at this time.”
The parallels with NEHTA’s present role and activities are quite uncanny.
The five recommendations from Deloittes to the Ontario Health Ministry (among a large number of internally focussed recommendations) make it clear just what the key problems have been:
• “Finalize and approve the Ontario e-Health Strategy
• Strengthen e-Health program management
• Establish enabling legislation/regulation for SSHA
• Strengthen e-Health privacy policy
• Enhance communication and collaboration between MOHTLC and SSHA”
Essentially a secure messaging environment and a technical infrastructure has been created in the absence of an e-Health Strategy, implementation plan, privacy policy and effective communication with the key clients. Additionally the core role of the SSHA in servicing the health sector has been lost – along with over $A500 million it would seem.
Just how similar does all this seem to the way NEHTA is proceeding at present (developing infrastructure in a strategic vacuum and the like) and how different is the outcome likely to be unless a Deloitte like review is undertaken as a matter of some considerable urgency?
I do see light at the end of this tunnel and it is that of an oncoming train!
David.
Last week the following article (selected quotes below) appeared in the Toronto Star. The full article can be found at the following URL:
http://www.thestar.com/Business/article/168761
Report slams e-health agency
“Smart Systems is not offering good value to taxpayers, consultancy says”
.....
The agency responsible for Ontario's electronic health infrastructure is poorly regarded in the health-care community, lacks strategic direction, and has not been held properly accountable by Queen's Park, according to an operational review conducted by Deloitte Consulting.
"Given the increased urgency for substantive progress with e-health in Ontario, an aggressive agency-turnaround plan is required," concludes the 100-page report, the outcome of an internal review launched a year ago by Health Minister George Smitherman.”
…..
“The agency, which employs more than 300 people, was created in 2002 and has since received $458 million from Ontario taxpayers as part of its mandate to electronically link and support the province's 150,000 health-care providers.”
…..
“Among the review's findings:
• There has been "little or no meaningful progress" with the creation of an emergency health record for Ontarians, though it was recognized there was "ambiguity" with the agency's role in this area.
• The network designed to link health-care providers is "below standard" when it comes to practices for monitoring performance and security.
• Assessing the agency's performance versus the government's expectations is difficult because "well-defined expectations, deliverables and measurable performance targets have not been established and documented by the ministry for SSHA."
• The Smart Systems' secure email service has fallen well short of expectations, as only a third of the 60,000 accounts that have been installed are being used.
• Though the agency is expected to host sensitive health information, "privacy policies are incomplete and not widely understood" and "many of the procedures necessary to provide guidance and direction have not been developed or are in draft form." In certain instances, "processes are ad hoc, undefined or undocumented."
• Security of patient information was also questioned, as Deloitte said it wasn't clear who was responsible for defining and implementing security controls and technologies. "As a result, sensitive information may not be protected consistently throughout its lifecycle."
A copy of the full report can be downloaded from:
http://www.ssha.on.ca/operationalreview/index.asp
All in all it would be difficult to say the money has been well spent so far.
The Smart Systems for Health Agency (SSHA) was intended to be a provider of connectivity services and standards for the health sector in Ontario, Canada – the largest province in the country with a population of a little over 13 million.
The mandate which the Agency was given in 2002/3 covered the following:
“The mandate at the time highlighted six products to support the priority initiatives identified within the SSHA regulation:
−Managing the private network;
−Providing a secure messaging service and online directories;
−Security infrastructure;
−Physical facilities;
−Voluntary emergency health record;
−Data and technology standards.”
A little later (2004/5) a role in application delivery for the sector was added. All the while the SSHA has been “pursuing a long-term goal of creating a voluntary EHR to allow health care professionals to access patients’ lifetime health histories. To achieve this goal, EHRs will need to connect many sources of information as well as currently independent applications and databases. Establishing electronic connections to allow information from different sources, applications and databases to be shared is the focus of SSHA’s efforts at this time.”
The parallels with NEHTA’s present role and activities are quite uncanny.
The five recommendations from Deloittes to the Ontario Health Ministry (among a large number of internally focussed recommendations) make it clear just what the key problems have been:
• “Finalize and approve the Ontario e-Health Strategy
• Strengthen e-Health program management
• Establish enabling legislation/regulation for SSHA
• Strengthen e-Health privacy policy
• Enhance communication and collaboration between MOHTLC and SSHA”
Essentially a secure messaging environment and a technical infrastructure has been created in the absence of an e-Health Strategy, implementation plan, privacy policy and effective communication with the key clients. Additionally the core role of the SSHA in servicing the health sector has been lost – along with over $A500 million it would seem.
Just how similar does all this seem to the way NEHTA is proceeding at present (developing infrastructure in a strategic vacuum and the like) and how different is the outcome likely to be unless a Deloitte like review is undertaken as a matter of some considerable urgency?
I do see light at the end of this tunnel and it is that of an oncoming train!
David.
Thursday, January 11, 2007
Clinical Research Information Now More Freely Available on the Internet.
Good news for all those interested in the free exchange of medical research information in the last few days.
According to the Financial Times (FT) of the 10th of January, 2007
“UK PubMed Central yesterday went live offering 600,000 biomedical digital articles from leading academic journals, with financial support from the Wellcome Trust, the Medical Research Council and medical research charities.”
This new source of medical research information can be found at the following URL:
http://www.ukpmc.ac.uk
The FT says that it is operated by the British Library in conjunction with the University of Manchester and the European Bioinformatics Institute.
It will receive about $A10m in funding over five years from about 10 different sponsors.
What is most interesting is that, despite the complaints of the academic publishing interests, any medical research that is funded in whole or in part by the UK Government is to be made available, for free, on the internet within six months of its publication in final peer reviewed form.
Given that apparently 90% of medical research in the UK has an element of Government funding this is a major step forward for access to the clinical research literature.
The site is a twin of a site run by the US National Institutes of Health which can be found this URL:
http://www.pubmedcentral.nih.gov/
This site has similar content and also publishes research which is funded in whole or part by the US Government under similar rules. It has been operational for a few years and has proved invaluable.
The concept of making freely available medical literature funded from the public purse is an idea whose time has surely come. Researchers like their work to be easily accessible so it can be used and we all, as interested citizens, can see what our dollars are funding!
Let us hope Australia quickly follows suit.
David.
According to the Financial Times (FT) of the 10th of January, 2007
“UK PubMed Central yesterday went live offering 600,000 biomedical digital articles from leading academic journals, with financial support from the Wellcome Trust, the Medical Research Council and medical research charities.”
This new source of medical research information can be found at the following URL:
http://www.ukpmc.ac.uk
The FT says that it is operated by the British Library in conjunction with the University of Manchester and the European Bioinformatics Institute.
It will receive about $A10m in funding over five years from about 10 different sponsors.
What is most interesting is that, despite the complaints of the academic publishing interests, any medical research that is funded in whole or in part by the UK Government is to be made available, for free, on the internet within six months of its publication in final peer reviewed form.
Given that apparently 90% of medical research in the UK has an element of Government funding this is a major step forward for access to the clinical research literature.
The site is a twin of a site run by the US National Institutes of Health which can be found this URL:
http://www.pubmedcentral.nih.gov/
This site has similar content and also publishes research which is funded in whole or part by the US Government under similar rules. It has been operational for a few years and has proved invaluable.
The concept of making freely available medical literature funded from the public purse is an idea whose time has surely come. Researchers like their work to be easily accessible so it can be used and we all, as interested citizens, can see what our dollars are funding!
Let us hope Australia quickly follows suit.
David.
Monday, January 08, 2007
Implementation Really Matters!
In the article before this I wrote:
“A unifying flaw in all these documents is the lack of any reference implementations to confirm any of this is useful or valuable to even the minutest extent. Standards organisations have, I believe, a responsibility to prove what they propose works and can be successfully implemented before expecting it to be adopted. All this is a long way from passing that test.”
I feel this point is so important that it should be expanded upon.
Over the last decade or so we have seen the apparent emergence of a range of specifications in the Health IT area which have progressed through various standards processes and organisations but which have yet to achieve significant numbers of real-world implementations.
Major international examples include the original and later CEN/ISO EN13606, HL7 V3.0, openEHR, possibly SNOMED CT and I am sure there are others.
It is not clear just why these processes are so slow – but in part it must be related to issues of complexity, resourcing and other less obvious factors such as change management etc.
On the other side of the coin we have groups such as Integrating the Health Enterprise (IHE), the Object Management Group (OMG) and the Internet Engineering Task Force (IETF) whose processes emphasise that real world, fully scaled, implementation is vital to final acceptance of a standardisation proposal.
The practical implication of this stance is that theory does not get too far ahead of practice so that evolutionary, rather than revolutionary, change is achieved. Also, of critical importance in the health sector, is the fact that the intangible issues (user resistance, impracticality etc) and unanticipated consequences are recognised early and managed.
An invaluable model that brings together and demonstrates all these approaches is the Healthcare Services Specification Project (HSSP).
Details can be found at http://hssp.wikispaces.com/
In essence this project is bringing together health and hard technical skills in a planned way to deliver a set of web services which will powerfully enable and facilitate projects such as US National Health Information Infrastructure and Australia’s HealthConnect should it ever get properly off the ground.
A hallmark of the work being undertaken is the approach of developing Draft Standard(s) for Trial Use (DSTU). Only once it has been shown that the standard works as expected and achieves it stated goals does it become a formal standard.
Those interested should visit the following URL for a comprehensive range of explanations and information.
http://hssp.wikispaces.com/HSSP.Navigator
It seems clear to me that the structured engineering approach being adopted here is much more likely to solve the issues around having effective standardised solutions than the non-implementation and non ‘proof of concept’ focused approach being presently adopted by NEHTA.
I wonder how aligned NEHTA’s yet to be released technical detail in areas like identity and terminology services is to the HSSP Project?
The Health Informatics Association of Australia (HISA) is also to be congratulated for working to extend the practical approaches used by IHE into Australia. This step will also help to move Health IT from the theoretical into the operational phase in Australia.
Can I suggest we are only ever going to see significant progress in E-Health space when the discipline of real world implementation and operation is applied to the worryingly large number of current Health IT Standards proposals and specifications which seem to be overly complex and out of practical control.
David.
“A unifying flaw in all these documents is the lack of any reference implementations to confirm any of this is useful or valuable to even the minutest extent. Standards organisations have, I believe, a responsibility to prove what they propose works and can be successfully implemented before expecting it to be adopted. All this is a long way from passing that test.”
I feel this point is so important that it should be expanded upon.
Over the last decade or so we have seen the apparent emergence of a range of specifications in the Health IT area which have progressed through various standards processes and organisations but which have yet to achieve significant numbers of real-world implementations.
Major international examples include the original and later CEN/ISO EN13606, HL7 V3.0, openEHR, possibly SNOMED CT and I am sure there are others.
It is not clear just why these processes are so slow – but in part it must be related to issues of complexity, resourcing and other less obvious factors such as change management etc.
On the other side of the coin we have groups such as Integrating the Health Enterprise (IHE), the Object Management Group (OMG) and the Internet Engineering Task Force (IETF) whose processes emphasise that real world, fully scaled, implementation is vital to final acceptance of a standardisation proposal.
The practical implication of this stance is that theory does not get too far ahead of practice so that evolutionary, rather than revolutionary, change is achieved. Also, of critical importance in the health sector, is the fact that the intangible issues (user resistance, impracticality etc) and unanticipated consequences are recognised early and managed.
An invaluable model that brings together and demonstrates all these approaches is the Healthcare Services Specification Project (HSSP).
Details can be found at http://hssp.wikispaces.com/
In essence this project is bringing together health and hard technical skills in a planned way to deliver a set of web services which will powerfully enable and facilitate projects such as US National Health Information Infrastructure and Australia’s HealthConnect should it ever get properly off the ground.
A hallmark of the work being undertaken is the approach of developing Draft Standard(s) for Trial Use (DSTU). Only once it has been shown that the standard works as expected and achieves it stated goals does it become a formal standard.
Those interested should visit the following URL for a comprehensive range of explanations and information.
http://hssp.wikispaces.com/HSSP.Navigator
It seems clear to me that the structured engineering approach being adopted here is much more likely to solve the issues around having effective standardised solutions than the non-implementation and non ‘proof of concept’ focused approach being presently adopted by NEHTA.
I wonder how aligned NEHTA’s yet to be released technical detail in areas like identity and terminology services is to the HSSP Project?
The Health Informatics Association of Australia (HISA) is also to be congratulated for working to extend the practical approaches used by IHE into Australia. This step will also help to move Health IT from the theoretical into the operational phase in Australia.
Can I suggest we are only ever going to see significant progress in E-Health space when the discipline of real world implementation and operation is applied to the worryingly large number of current Health IT Standards proposals and specifications which seem to be overly complex and out of practical control.
David.
Thursday, January 04, 2007
Media Management, Real Progress or NEHTA Trying to Justify Their Existence?
Good heavens! There I was just calming down for a relaxed Christmas and suddenly a flood of new documents are released by NEHTA. And what a fascinating grab bag it is too!
Cynical soul that I am, I must say that the arrival of all this largesse on the second last business day before Christmas did make me wonder if the holiday period was being used as a cover to slip material out which might need to avoid scrutiny.
A more charitable interpretation is that NEHTA was concerned that I may have been bored over Christmas and wanted to keep me busy!
What was released? There were three documents.
The first document is entitled “Technical Architecture for Implementing Services Concepts and Patterns Version 1.0 – 21 December 2006 For Comment.”
The purpose of the document is said to be:
“This document describes the technical concepts and patterns for service implementation within the national E-Health Infrastructure. These technical concepts and patterns form the basis for a Technical Architecture of the national E-Health Infrastructure.
The national E-Health Infrastructure is the infrastructure that is being developed by the National E-Health Transition Authority (NEHTA) to support electronic health in Australia.”
The document is also intended to provide guidance as to how to develop systems which will make up the national E-Health Infrastructure.
Bluntly, this 27 page document is a joke. All it offers is a Services Orientated Architecture tutorial and a recommendation that information flowing between the various services be modelled as follows:
“Information can be modelled and represented in many different ways. This technical pattern recommends that information can be represented using the XML infoset and encoded using the syntax of XML. It also recommends the use of XML Schema to describe those XML documents.
This technical pattern ensures that the data works natively with Web services. Other forms of data can be used with Web services. However, they would have to be represented as binary data which is encoded inside an XML wrapper.”
It then concludes with a set of totally obvious and self evident architectural principles – as an Appendix – but offers no framework as to how these are to be implemented and no use cases so the implications can be understood.
This is another “get no one anywhere” effort from NEHTA.
The second document is entitled “NATIONAL PATHOLOGY TERMINOLOGY Draft National Reference Lists – Pathology Request and Results” and comes with two spreadsheets of the SNOMED CT codes, the fully specified term and the NEHTA preferred term and some linkages.
The most amazing thing about this release is that – while being at best half done -NEHTA is claiming it is a major step forward and at the same time saying this is not ready for use!
“NEHTA has delivered Release 1 of a national pathology terminology, comprised of draft National Pathology Request and Result Reference Lists for comment. It is important to note that these Reference Lists are not yet considered suitable for implementation.
These Lists are the first step towards the development of a national, standard pathology terminology, for use in all general practice, pathology and clinical information systems.”
Worse it just dismisses all the work done with AusPath by airily saying LOINC is not supported – despite being at the heart of ELINCS – the pathology messaging approach now being adopted and supported by HL7 in the USA! What is it NEHTA knows that HL7 does not I wonder? Some detailed report of the analysis that led to a decision of this importance is surely warranted?
There is also some evidence of haste in the completeness of content and spelling in some areas.
All in all this could have waited for release until it had been properly quality controlled, spelling normalised and Australianised and tested in a trial implementation or two prior to public release. Given the resources available to work on this area I would expect more refined and developed products.
The third document is entitled National Discharge Summary Data Content Specifications Version 1.0 – 21/12/2006. Staggeringly this document has been under-development for well over three years – first as part of the HealthConnect program and now (since 2004) as a NEHTA initiative. The time taken, for what should have been a relatively straightforward task, is a true reflection of the lack of focus and direction that exists in the E-Health sector under NEHTA’s leadership.
NEHTA described the document thus:
“This document describes a specification for standardising the content of a discharge summary. The specification is a template that divides the discharge summary into sections based upon topic-specific data groups such as medications, problems/ diagnoses, diagnostic investigations, etc. The template is part of the care record summary suite of specifications that NEHTA is developing for the Australian health informatics community. One of NEHTA’s goals is to standardise the suite of priority care record summaries and their data content to achieve semantic interoperability amongst healthcare provider systems.”
The document runs to 374 pages (or so) and defines a Discharge Summary Template of genuinely biblical complexity. While the rest of the world works to simplify clinical communication of key information (as seen in the recent design changes to the UK shared record and in developments like the Care Record Summary (HL7) and the Continuity of Care Record (ASTM) in the USA) NEHTA has been investing time and effort in rampant, essentially unimplementable information modelling overkill.
Frankly I have no idea how anyone could persuade busy interns to promptly and correctly fill in forms of this planned complexity – no matter what the incentive. This will simply not be used in my view – defeating its noble purpose.
There is a critical need for the simplest of basic information communication between hospitals and practitioners – about the amount of information that can sensibly fit on an A4 page – not this over engineered monster.
The adage of “walk before you run” is ringing in my ears as I type.
Frankly I admire the dedication and work ethic of those who have put this together – despite its obvious lack of practicality. Pity about the out of touch leadership who sponsored such a brave, but ultimately what I believe will be a fruitless, exercise. Let’s get this excellent team to review where the US and the UK have headed for sound and practical reasons and quickly come up with a basic sharable specification that has some hope of being implemented. For heaven’s sake let’s master walking before we try and run!
It can be done! This is shown by New Zealand where they now have approx 2.5 million summaries going out to GPs annually, using an HL7 2.2 standard. I understand this is now being upgraded to V2.4 after six years of getting momentum and use with a very basic standard. Seems like the Kiwis have a jump on us in more than Rugby.
A unifying flaw in all these documents is the lack of any reference implementations to confirm any of this is useful or valuable to even the minutest extent. Standards organisations have, I believe, a responsibility to prove what they propose works and can be successfully implemented before expecting it to be adopted. All this is a long way from passing that test.
All in all this looks to me like the response to a command from on high to “get as much as possible out before Christmas to show the last two and a half years have not been wasted”. What do you think?
David.
Cynical soul that I am, I must say that the arrival of all this largesse on the second last business day before Christmas did make me wonder if the holiday period was being used as a cover to slip material out which might need to avoid scrutiny.
A more charitable interpretation is that NEHTA was concerned that I may have been bored over Christmas and wanted to keep me busy!
What was released? There were three documents.
The first document is entitled “Technical Architecture for Implementing Services Concepts and Patterns Version 1.0 – 21 December 2006 For Comment.”
The purpose of the document is said to be:
“This document describes the technical concepts and patterns for service implementation within the national E-Health Infrastructure. These technical concepts and patterns form the basis for a Technical Architecture of the national E-Health Infrastructure.
The national E-Health Infrastructure is the infrastructure that is being developed by the National E-Health Transition Authority (NEHTA) to support electronic health in Australia.”
The document is also intended to provide guidance as to how to develop systems which will make up the national E-Health Infrastructure.
Bluntly, this 27 page document is a joke. All it offers is a Services Orientated Architecture tutorial and a recommendation that information flowing between the various services be modelled as follows:
“Information can be modelled and represented in many different ways. This technical pattern recommends that information can be represented using the XML infoset and encoded using the syntax of XML. It also recommends the use of XML Schema to describe those XML documents.
This technical pattern ensures that the data works natively with Web services. Other forms of data can be used with Web services. However, they would have to be represented as binary data which is encoded inside an XML wrapper.”
It then concludes with a set of totally obvious and self evident architectural principles – as an Appendix – but offers no framework as to how these are to be implemented and no use cases so the implications can be understood.
This is another “get no one anywhere” effort from NEHTA.
The second document is entitled “NATIONAL PATHOLOGY TERMINOLOGY Draft National Reference Lists – Pathology Request and Results” and comes with two spreadsheets of the SNOMED CT codes, the fully specified term and the NEHTA preferred term and some linkages.
The most amazing thing about this release is that – while being at best half done -NEHTA is claiming it is a major step forward and at the same time saying this is not ready for use!
“NEHTA has delivered Release 1 of a national pathology terminology, comprised of draft National Pathology Request and Result Reference Lists for comment. It is important to note that these Reference Lists are not yet considered suitable for implementation.
These Lists are the first step towards the development of a national, standard pathology terminology, for use in all general practice, pathology and clinical information systems.”
Worse it just dismisses all the work done with AusPath by airily saying LOINC is not supported – despite being at the heart of ELINCS – the pathology messaging approach now being adopted and supported by HL7 in the USA! What is it NEHTA knows that HL7 does not I wonder? Some detailed report of the analysis that led to a decision of this importance is surely warranted?
There is also some evidence of haste in the completeness of content and spelling in some areas.
All in all this could have waited for release until it had been properly quality controlled, spelling normalised and Australianised and tested in a trial implementation or two prior to public release. Given the resources available to work on this area I would expect more refined and developed products.
The third document is entitled National Discharge Summary Data Content Specifications Version 1.0 – 21/12/2006. Staggeringly this document has been under-development for well over three years – first as part of the HealthConnect program and now (since 2004) as a NEHTA initiative. The time taken, for what should have been a relatively straightforward task, is a true reflection of the lack of focus and direction that exists in the E-Health sector under NEHTA’s leadership.
NEHTA described the document thus:
“This document describes a specification for standardising the content of a discharge summary. The specification is a template that divides the discharge summary into sections based upon topic-specific data groups such as medications, problems/ diagnoses, diagnostic investigations, etc. The template is part of the care record summary suite of specifications that NEHTA is developing for the Australian health informatics community. One of NEHTA’s goals is to standardise the suite of priority care record summaries and their data content to achieve semantic interoperability amongst healthcare provider systems.”
The document runs to 374 pages (or so) and defines a Discharge Summary Template of genuinely biblical complexity. While the rest of the world works to simplify clinical communication of key information (as seen in the recent design changes to the UK shared record and in developments like the Care Record Summary (HL7) and the Continuity of Care Record (ASTM) in the USA) NEHTA has been investing time and effort in rampant, essentially unimplementable information modelling overkill.
Frankly I have no idea how anyone could persuade busy interns to promptly and correctly fill in forms of this planned complexity – no matter what the incentive. This will simply not be used in my view – defeating its noble purpose.
There is a critical need for the simplest of basic information communication between hospitals and practitioners – about the amount of information that can sensibly fit on an A4 page – not this over engineered monster.
The adage of “walk before you run” is ringing in my ears as I type.
Frankly I admire the dedication and work ethic of those who have put this together – despite its obvious lack of practicality. Pity about the out of touch leadership who sponsored such a brave, but ultimately what I believe will be a fruitless, exercise. Let’s get this excellent team to review where the US and the UK have headed for sound and practical reasons and quickly come up with a basic sharable specification that has some hope of being implemented. For heaven’s sake let’s master walking before we try and run!
It can be done! This is shown by New Zealand where they now have approx 2.5 million summaries going out to GPs annually, using an HL7 2.2 standard. I understand this is now being upgraded to V2.4 after six years of getting momentum and use with a very basic standard. Seems like the Kiwis have a jump on us in more than Rugby
A unifying flaw in all these documents is the lack of any reference implementations to confirm any of this is useful or valuable to even the minutest extent. Standards organisations have, I believe, a responsibility to prove what they propose works and can be successfully implemented before expecting it to be adopted. All this is a long way from passing that test.
All in all this looks to me like the response to a command from on high to “get as much as possible out before Christmas to show the last two and a half years have not been wasted”. What do you think?
David.
Subscribe to:
Posts (Atom)