The crisis in e-health standards IIa

Prev: The crisis in e-health standards II
Next: The crisis in e-health standards III – solutions

Unfinished business

I promised pointers to a solution for how to get out of the standards mire in which we find ourselves today. But first, I will intervene with a short post on missed items, pointed out to me by various (justifiably) miffed people.

The Object Management Group (OMG)

For many people in the clinical arena, the OMG is probably quite peripheral, like the IEEE or W3C. They know that it exists, and that it probably does something important they don’t really understand. What many don’t know is that it has been a major innovator in the ‘standards business’ and also been active in the health vertical. The first is relevant because it is an organisation we can learn from. The OMG started in 1989 and created a standard called CORBA (Common Object Request Broker Architecture), which was essentially about making ‘objects’ talk to each other across the network, or in today’s speak, ‘services’. Indeed today’s favourite mantras, Service-Oriented Architecture (SOA) and ‘web services’ owe a lot to the work done by the OMG. Corba is supposed to be dead, but Richard Soley (OMG CEO) once told me that it is quietly whirring away on hundreds of thousands of machines around the world. Companies like Progress Software also seem unaware of its demise.

In more recent times, the OMG has become the organisation that manages the UML standard, business process and workflow-related standards, and a growing ecosystem of ‘MDA’ (Model-driven Architecture) and software quality standards. The OMG standards of greatest importance to the ICT industry are these infrastructure standards, although there are many in vertical domains as well.

In health, there have been two OMG efforts. The first, starting in the late 1990s, was called Corbamed (later, Health Domain Taskforce, or HDTF), and resulted in a collection of standards including PIDS (Person Identification Service), RAD (Resource access decision service), HILS (Health Information Location Service), COAS (Clinical Observations Access Service) and TQS (Terminology Query Service).  I was present at some of the early meetings during this development and know these specifications well, and can vouch for their high quality of engineering design. (The room was full of professional engineers and IT experts as well, and the coffee seemed to be better, so I had high hopes). Why are these standards not being widely used now? There are three reasons. Firstly, my personal feeling at the time (based on what I understood about health informatics in the a decade ago) was that the Corbamed did not adequately take into account the complex information / knowledge semantic requirements of health. In hindsight (i.e. with another 10 years in the game) I still believe this to be true (in my language, they did not have something like archetypes). However the main reason is more likely to be non-technical. The OMG was not understood by the health domain or the health ICT industry as a provider of vertical standards, certainly not in health; in health, it has been HL7 that has dominated, and through the 1990s to today, the promise of ‘version 3’ of HL7 attracted a great deal more attention. Lastly, they were quite simply ahead of their time: the thinking of the health domain was not ready to understand services.

The second OMG health standardisation effort is recent, and is in fact in partnership with HL7. A group of standards under the umbrella of ‘HSSP’ (Health Services Specification project; home page) was begun in 2006, after much persuasion from Ken Rubin (who somehow still has not gone grey from the pain) and other diehards that HL7 should finally come to grips with ‘services’. It has resulted so far in RLUS (Record Location and Update Service – a COAS equivalent with added update semantics), EIS (Entity Information Service – a PIDS equivalent) and CTS II, a modern version of TQS. These standards benefit from access to more representative (in health domain terms) input from HL7 members as well as other industry specialists. Will they survive? Only time will tell.

What can we learn from the OMG? There are I believe two things:

• Process: the first is that far more important than its standards, it brought in a kind of workable and reasonably timely standards process, I suspect due to the allergic intolerance (like my own) of its founders to the interminable process of ISO, IEC and other such ‘grand bodies’. An OMG proposal has to get from RFP (request for proposal) to adoption in 18 months or less (see process page for details). The submission is made by one or more consortia, usually made up of architects from engineering companies, who work together on the submission, usually implementing it in some way.  As far as I know, it is not a requirement for a submission to be implemented before adoption, but an implementation of some kind usually exists, due to the engineering culture, not to mention market interests, of the participants. In theory, there is a maintenance methodology, although I don’t believe one can raise an issue on the OMG website.
• Quality: as already mentioned, the OMG standards activities attract heavily professional technical participation. In concrete terms, this has meant that standards are formally specified (originally using IDL, interface definition language), properly use object-orientation (not just UML pictures of the same), and even indulge in woefully underused but essential practices as specifying ‘contracts’ and exceptions in services.
  • For the reader with too much time on her hands, you can found out about contracts by looking up Bertrand Meyer, Design by Contract, and the Eiffel language (and if you decide to play with the latter, don’t blame me when you can’t face the programming language you use in your day job again).
  • The down side of the engineering emphasis of the OMG has historically been some weakness in terms of domain representation.

In summary: the OMG is pretty good at turning out a high-quality technical specification in good time.

Standards ‘Harmonisation’

Many standards bodies have a so-called harmonisation group, panel, or other such activity. This is intended to help the body somehow harmonise with other organisations, while maintaining its own competitive edge and mindshare. Harmonisation is usually only taken seriously when either government policy requires it, or some source of funding appears to depend on it.  This is not to say the workers in the trenches don’t have the best interests of the world at heart, but the reality is, these interests are not generally furthered by their efforts.

There are two kinds of harmonisation usually undertaken. The first is what I would call ‘point-to-point’, and involves just creating a bridge between two specific standards or models – often particular message specifications. This is sometimes technically achievable and even comes to fruition occasionally, as in the case of the ‘CCD’, the child of ASTM’s CCR XML-schema, and the HL7 CDA specification. Is it useful? Clearly it sometimes is, since the result is specific, and presumably has some customers at least. Is it sustainable? Almost certainly not.

The second kind of harmonisation is of the grand unified theory flavour of which physicists still dream. In other words, a proper integration of the DNA of the specifications of two organisations. This is in theory possible as well, but only under the following circumstances: if only one organisation has an underlying engineering design framework or methodology, and the other doesn’t, but does have use case-specific schemas or models. In this particular fantasy world, the latter organisation’s specifications could potentially be re-engineered in the technology of the former. Sadly, the world of health IT is not anything like this clean. Most of the major e-health standards organisations – CEN, HL7, ISO (to the extent that it builds anything new, or makes concerted choices in adoption of other standards) and OMG all have underlying technical frameworks of one kind or another. In such circumstances, for at least one organisation, harmonisation quite simply would be like the original European invasion of Mauritius in the 17th century.. from the viewpoint of the dodo.

We can learn from this situation as well, in that it confirms the common sense expectation that merging two different design approaches is unlikely to be possible, or even easy – and that is before we take into account human personalities. The lesson? Start with a good technical framework for the domain, and stick to it.

Conclusions (and a radical opinion?)

Having amassed various evidence in my survey so far, I will indeed provide my idea of a solution to the crisis in the next post.

However, before that, let me make one general observation. Health Informatics is a domain that takes itself seriously. It has very hard problems to solve, some decent conferences, some very good journals, various textbooks, and courses in many universities all the way up to doctoral level. And no end of Extremely Smart People trying to sort it out. And yet, as far as I have been able to ascertain over my 15 years’ of involvement, it lacks the internal structure necessary to any discipline: layering. Chemistry, when I studied it, had many layers of theory on which current thinking was built: the periodic table, a theory of bonding based on quantum positions and energies of electrons, theories of pressure / temperature, the model of oxidisation, and much more. The current science of proteins relies totally on these layers.  Physics is the same: Newtonian mechanics relies heavily on calculus, and provides most of the theory needed for non-light speed activity. Quantum electrodynamics provides the basis for anything electrical, and also tricky stuff in the stars that we can’t quite grasp yet. Biology assumes most of what is in both these fields, and builds its own models of cells (relying on the physics of bilipid membranes, osmosis and chemical energy transmission), organisms and ecosystems. Even ‘new’ fields like sociology and psychiatry have some decent theories of their own.

What happened to Health Informatics? Where are the layers? We assume many underlying computing concepts such as relational theory, object-orientation, ontological modelling, and the many electromagnetic laws underlying the beautiful scanners in our modern hospitals – but they are not built upon. Using equipment based on theories from other domains is not the same as building your own theories on top. The lack of layers is an indicator that health informatics, as a ‘discipline’, has yet to become one: it is still in about the same point of its evolution as general science in the time of Netwon, Boyle, and Hooke, when the theory of phlogiston reigned and the periodic table did not yet exist.

So as an aside to the principal question of this series of posts, I propose a challenge to the (so-called) field of health informatics: define yourself! To be a discipline, you must get out of the quagmire of continual re-invention of new theories and models, and actually assess and choose something on which to base the future. I am sure that this process will generate no fewer sparks than flew between the followers of Lamarck and Darwin, but it is needed if real progress is to be made. If this happens, e-health standards will have something solid to rely on.

Prev: The crisis in e-health standards II
Next: The crisis in e-health standards III – solutions