Monday, June 12, 2006

More Problems in UK Health IT Implementation Efforts

What follows (dating from earlier in the year) has a new relevance given current financial problems with the UK's multi-billion pound Connecting for Health initiative

31 Jan 06 10:54 Failure of due diligence
The LSP contracts were granted in the expectation that P1R2 deployments would begin in December 2004. The contracts were awarded a year or less before this date. EMR's have a development lifecycle of many years. These contracts should not have been awarded on promises, but on working software. P1R2 required systems to transmit clinical data within HL7 Version 3 messages, encoded in SNOMED Terminology and the UK Drugs and Medicines Dictionary. It was manifest that >no< supplier had a working system using any of these. Three years later on it seems none had even performed an adequate impact analysis of switching to these standards. (Even the Johnny-come-lately PACS systems have patchy if any support of the relevant 'spine' standards). In the first two years of NPfIT, even relatively simple 'ADT' (admission, transfer and discharge) transactions using HL7 V3 have proven challenging to implement. Legacy systems will never use these, placing another burden on LSPs to set up and operate heterogeneous messaging infrastructures of inordinate complexity. Contrary to popular belief, SNOMED was never going to drop effortlessly into the ICD-9 'slot' in existing systems. Meanwhile moving to the Drugs and Medicines Dictionary requires fundamental retooling of electronic drug formularies and systems using them. It is also fair to say that HL7 V3, SNOMED and DM+D remain, even now, immature as standards and a 'moving target' for LSP's and suppliers. All the above was known back in 2002-3, understood and documented by hundreds of people in the NHS, system suppliers and informatics community. (post edited by EHI)

31 Jan 06 12:50 What "standards"?
Why are SNOMED CT and the dm+d "immature" and in what sense are they "standards? Looking at the ISB web site, it appears that they have only got to the first hurdle in the standards approval process. It must be almost 7 years now since the SNOMED and Read merger began, a long time even by comparison with the much-maligned Read Codes version 3 project of the mid 1990s in which so many of us clinicians participated. As far as I can see, the issue is with the specification of HL7 v3, SNOMED CT etc as standards for CfH systems in the first place, when they appear not to have reached a stage of testing when their suitability could be confirmed. Let's not forget that the NAO report into the Read Codes showed how difficult developing new clinical codes could be. If the "moving target" of evolving standards is a significant factor in CfH delays, the perhaps it's time to revisit the so-called standards that are being specificed.

02 Feb 06 23:02 HL7 V3 standard
One of the problems with HL7 V3 'standard' is that is was 'farmed' out to the HL7 organisation by the NHS. This is a body of experts who are amateurs ,in the sense that they have 'day jobs' as well. Members of the HL7 organisation attend the meetings but very few, if any, members derive their main income from developing HL7 standards. The 'standards' are voted on by the members and such a process, is long winded and often seems to result in the lowest common denominator as a 'standard' i.e there is no weighting of votes for the expertise of the participant. As HL7 V3 messages are the basis for communications in the new NHS I would have thought it a good idea to get the messaging standardised and working before the s/w systems which depend on the messaging were developed. Then the systems would have been built on a firm foundation. Disasters I fear may be imminent.

08 Feb 06 16:18 SCRAP HL7
RE:"As HL7 V3 messages are the basis for communications in the new NHS I would have thought it a good idea to get the messaging standardised and working before the s/w systems which depend on the messaging were developed. ......." Better never than late. As anyone who is competent in IT messaging knows, If you want to send a message, just send the message. There is no justification for "translation" into a "messaging format" such as HL7, XML, EDIFACT et al. The scrapping of HL7 at this stage would have the advantage of reducing costs and timescales.

08 Feb 06 19:46 HL7 shoots itself in the foot
One of the main troubles with HL7 is that from a practical point of view, it goes out on a limb and is idiosyncratic. The basic metamodel is in UML - lots of people understand UML- it rapidly becoming an IT standard worldwide. So far so good. To produce messages however HL7 V3 goes it's own way. It devises it's own modelling methodology and representation - using MS Visio. It does not even use UML and all the HL7 'symbols' are color coded. Bad luck if you don't have a color printer or are color blind !!! Plus the, would be user/practitioner, must learn a completely new 'symbolology' which is only used by HL7 V3. There is thus a heavy learning curve, and who wants to learn an esoteric modelling language which is only used in the context of HL7 ? Having built your model you then process the Visio 'model' programmatically to produce the XML schema. It is not clear what the precise rules are for this transformation, but much of it seems to produce unnecessarily complex XML. The reliance on Visio and their own modelling symbols renders HL7 V3 unusable in the standard modelling tools for UML, which are well tried and trusted. If anyone had set out to complicate the description and generation of XML messages one couldn't do better than the HL7 V3 committee. They really have shot themselves and others in the foot. The trouble is, that if we continue in this fashion, the taxpayer will not be the only one to suffer.

From http://www.e-health-insider.com/news/item.cfm?ID=1670

2 comments:

Epa said...

With all these issues, do you think the answer would be to drop the HL7 version 3 or fix it as we go.

Gunther Schadow said...

There is no basis here to make any determination of who is to blame for any problems in the NHS project. For someone who seems to be on a defamatory campaign against HL7 (like Don Quixote against windmills) it is of course convenient to pin the problems at NHS on HL7.

First of all, I am taking exception with this entire blog, because it is mostly collecting anonymous hearsay of unknown and unverifiable credibility. Some of the most important informants here make accusations against HL7 which they never stand to back up in a serious dispute (Thomas Beale being the most notorious in this hit-and-run type of defamation.) The reader should know that Thomas Beale has significant financial interest in his OpenEHR product, and unlike most other health care information system vendors he has chosen to throw stones at HL7 rather than participate. All the references to OpenEHR as the better alternative to HL7 is furthering his sales and contracts.

Back to NHS: There has never been a project of such size which was not delayed, significantly delayed, if it didn't right out fail. Even projects of much simpler subject matter, such as automated road-toll collection systems (in Germany and Australia) have been delayed for years and lost huge amounts of money. Medical informatics is of course by orders of magnitude more complex than a road-toll system and its history is full of failures of ambitious projects.

Usually such failures are pinned to managers, that may be unfair sometimes, but pinning it on one piece of technology sees rather far fetched. How does one actually rationally know it's that product's fault? How does one distinguish between a product and its use? In the end it would still be the managers' fault to have allowed the suspect product to be used in the particular way that it was used. And that may just be what's going on with HL7 in the NHS project, if at all it does have any relationship with the cause for delay, which I still doubt.

Let's just contemplate this: the UK government dedicates millions of pounds to create a system that is completely new and has never been there. Instead of starting from ground zero, it could have been smart to begin with smaller-scale projects and tightly managing expectations and technical execution. And who says they wouldn't have had an even bigger failure without HL7? I have witnessed several projects which started out with the rejection of HL7 as too complicated, and which have delayed, failed one by one, in part because they weren't considering the huge amount of experience about health care information management which they can find in HL7 if they care to look.

Some of these projects are still ongoing (with difficulty) and I am marginally related with them, so I can't name them. But for a good dead specimen look at the U.S. Governmental Computerized Patient Record (GCPR). It was done all in UML and Rational Unified Process and the latest OO bells and whistles and yet none of that could prevent the designers from screwing up. It was also characterized by a rejection of HL7, and by an attitude of the designers that they know it all better and that they should mix and match different incompatible standards (CorbaMED was one of them). They also were intoxicated with the SOA dream (and still are.) So, you don't need HL7 to ruin a project, and you can use all the OO that you like and still ruin a project.

If anything the current problems with NHS may be another example for the failure of the waterfall approach to managing complicated software projects. Also, the failure of government general-contracting for intellectually challenging tasks does not work. This is not building a bridge, this is much more complicated, sometimes elusive stuff.

Just consider, British Telecom (BT) is the prime contractor. Why? Have they got much relevant expertise? I don't think so, but depending on how they manage it, they have plenty of ability to skim off money for no value delivered and they can seriously ruin the project by managing it overly complicated. I don't know if any project this size has ever succeeded, with or without HL7.