What needs fixing in e-health?

or, e-health seen through the prism of an ancient pantheon of gods…

Grahame Grieve’s recent blog entry on the HL7 Fresh Look Task Force seems a good excuse for me to have another big picture look at e-health. The fact that HL7 is doing this indicates two things at least: that it thinks something is wrong in the HL7 organisation, and that it thinks something is not going right in e-health in general. That’s good to see. HL7 has been the single most influential standards body in e-health for at least 15 years. It has spent massive effort in the last decade on an effort called HL7v3, or ‘version 3’. This effort has not been a resounding success, indeed the evidence indicates the opposite. I have historically been one of the strongest critics of the technical architecture of this effort, so my statements here won’t come as any surprise. To give credit where it is due however, I have come to see that HL7 was trying to the right kind of thing, just that they lacked the appropriate expertise to do it. Solving the challenges in the area of e-health is no mean feat, and maybe some of them are unsolvable, so take that statement as a commiseration rather than a criticism.

One thing HL7 has created (whether intentionally or not) is professional networks, intellectual discussion groups and friendships. The value of this cannot be overstated: in my view, almost all good ideas come from dialectic processes, and dialectic processes cannot exist with only one person in the room. If I managed to make any contribution to e-health myself, it is largely due to having not only learned a great deal from people I met on the way (many at HL7 meetings) but from discussions and sometimes furious debates with them.

Where do we go from here? Well, if HL7 is asking that question of itself, I don’t mind putting my 2 pennies in.

The most basic questions that such organisations can ask of themselves are: why are we here? Are we needed? Put another way, is there some important challenge that our industry needs solved, where we can help? What is this challenge? My distillation (after 17 years of massochistic involvement in the e-health area) of what modern healthcare wants in terms of IT is the following:

  • (at least some) shareable health information (whether it be lab, EHR, reimbursement) – why? Because in modern healthcare, a patient is seen by numerous professionals and institutions. Coordinating that demands a ‘memory’ facility of some kind – i.e. an ICT infrastructure that can record and share the information needed to coordinate the care.
    • => leading to a notion we call interoperability
  • (at least some) computable health information: information that is not only comprehensible to humans on the screen, but comprehensible to computer applications. Why? Because there are vast oceans of health data, too much for humans to process, from which great human and economic value could be obtained, if only it were amenable to computation. Some of it already is, in a basic way. Viable processing of claims, lab results, bookings and recalls relies on IT support. So too does business intelligence, decision support and forensic medical research.
    • => leading to the notion of semantics in health data.

Combined, these two are often captured in the rallying cry semantic interoperability. This notion hides a whole world of complexity – of data formats, workflows, order entry, terminology and so on. I won’t go into all that here. Let’s just agree that there is a challenge called semantic interoperability in health, and that it would be good for humankind if we could do something about it. There are two other crucial requirements, but I won’t mention them just yet. Read on…

Now what do we do about this? The way to see things I now believe, is as follows. There are two spheres of activity:

  • the intellectual design domain (IDD): where all the standards meetings take place, where the formalisms, specifications and models are defined, where terminology is created, where use cases are described and recorded. This domain is fun because it is intellectually stimulating, involves a lot of travel, lack of sleep, foreign beer and all the pleasures of the meetings of minds (not necessarily like minds, but we love bitterly fought intellectual battles as well, as a motor loves rocket fuel… just ask: would Newton have been happer if Hookes had not been around? Unlikely)… the IDD is like a debating society sitting in the clouds of heaven. The debaters, lounging around in their cloud-armchairs are essentially all thinking about one thing: what what the universe down below look like if we changed this law, or added that one?
  • the domain of operational reality (DOR): a.k.a. the daily grind, the place of pain…. where all real healthcare takes place, where all the hospitals and clinics and homes and carers and patients exist, where all the vendors deploy their solutions. This is earth, where heaven’s laws define the rules of operation.

The general idea is that a lot of smart people in heaven work out some laws of the universe, and pass them down to earth (via national e-health programmes and vendors; see below), whose hapless denizens rejoice in and/or suffer the results. If there seems to be too much suffering or complaining, those in heaven go back to their design workshop and create some better laws, and hand those out. Or not. And so on.

Some things to note about this universe:

  • there can only be one heaven, else those on earth will be paralysed with indecision;
  • earth-dwellers are only simple beings; they cannot (don’t have time to) understand the intricacies of thought of the gods in heaven; if they are to understand the laws, they must be delivered in their language, not that of the gods;
  • time works differently in the two domains. One day in heaven may correspond to many years on earth… this is because the massively complex systems of earth have a great deal of inertia, and injecting change is itself, complex, messy, time-consuming and sometimes unpredictable.

National e-health programmes are somewhere between heaven and earth, demi-gods acting as a kind of conduit between higher deities and their own pieces of earth below – some country or jurisdiction. Their role is to make decisions about which laws should be applied and where. To confuse things more, vendors – those who create operational solutions implementing the laws (or not) – can be considered as some kind of lowly demons (not forgetting that being a minor, smiling demon is still way more powerful than being a regular earth-dweller) – they have enough power to subvert / pervert / invert / revert / ignore some aspects of laws, resulting in significant perturbations in the space-time fabric where their solutions are deployed. Not all of the perversions are to be derided: many are likely to be significant improvements on the designs of the gods…

People working in e-health have generally worked at some time or other in both places, and therefore know that both contain massive complexity. Complexity in the intellectual design domain is to do with models and formalisms … essentially it all boils down to mathematical complexity of one kind or another (note that here ‘mathematics’ mostly corresponds to mathematical logic, of the kind used in computer programming, ontology design etc). It is necessary, because we know that simplistic models are insufficient to deal with the second kind of complexity…

People working on earth – in real hospitals, with real vendor systems, see a different kind of complexity, one that is biomedical, sociological, political and economic at the same time. I would designate this as system complexity i.e. the kind of complexity that is both innate and emergent in complex systems – whether sick human beings, care facilities or national healthcare systems.

One of the great (but implicit) challenges for people in health informatics, particularly those in national programmes, is that they are trying to deal with both kinds of complexity at once. They get involved in building hugely complex mathematical frameworks for use in the hugely complex real world.

This gets us close to where the real problems lie. How complex should the design work in heaven be? How much of the complexity on earth can be safely ignored? Should the gods in heaven design the uber-framework to beat all frameworks (which might take forever, consigning generations of earthlings to unremitting pain) or something smaller? How small a framework would be useful? In what order should the complex problems on earth be dealt with by those in heaven? And so on ad infinitum… and of course, I am not even going to mention the problem of cooperation, other than to say: in both a pantheistic heaven, and on earth, it don’t come easy… (see Grahame’s posts on interoperability as a people problem and the e-health community).

Now we need to consider the two requirements I ignored earlier.  Those in the intellectual design domain, if they look closely at what happens on earth, will realise that not only is earth complex, but it is always changing – the complexity really is like the controlled chaos of a boiling cauldron, or a vast forest ecosystem. So they must design for constant change. This leads to two requirements in their architecture:

  • flexibility: the capability for the poor victims on earth to actually make changes at run-time to the laws delivered from on high – in other words, the framework must have flexibility and adaptability built-in in its delivered components;
  • sustainability: the architectural framework devised in heaven, given its own innate complexity (and the costs and time – even to the gods – involved in its creation) must itself be adaptable in the long term, rather than having to be replaced by a new framework every millenium or so.

Oops. I nearly forgot the third key requirement: both the heaven-built framework and its deployment on earth must be economic. Unfortunately this little universe is a zero-sum game…

Most of the above may be obvious to people in health informatics. However, I believe there are two key observations whose importance most have under-estimated (including myself, for much of the time), which could help both HL7 and health informatics in general. The first is that to obtain semantic interoperability, flexibility and sustainability – economically – you need a very smart design framework, of a minimum level of complexity. Building a trivial XML-based one (a moment’s play between games of 4D chess for the challenge-starved occupants of heaven) will solve just one or two problems on earth. Solving more problems on earth will require other trivial – but different – frameworks. The denizens of earth have only a limited interest in gods who keep making life hard for them. They may go and get better gods….

On the other hand, due to the previously mentioned inertia of earth’s systems, there is only a very limited rate at which change can be absorbed. Earth-dwellers do want something rather than nothing, but they need it in manageable pieces.

I would summarise this as: those in heaven should build a single, comprehensive, sustainable framework, from which can be delivered a stream of small, useful artefacts.

What does this mean practically? It means building a ‘proper’ rather than a trivial architecture in the intellectual design space, with the following properties:

  • existential:
    • there is only one of them (single heaven principle)
  • technical:
    • semantic interoperability (basic need)
    • flexibility on earth (continuous change principle)
    • sustainability in heaven (economic reality principle)
  • delivery:
    • deliverable in the language of earth (simple beings principle)
    • deliverable in small, palatable pieces to earth (inertia principle)

Translated into concrete e-health categories:

  • existential:
    • we only have room for one, international e-health interoperability architectural framework. Specific bits of this can be denoted as ‘standards’. The thing as a whole is not a standard, and cannot be; it is an engineering framework;
  • technical:
    • the framework must enable single-source modelling of domain content and concepts (aka information and terminology); it must also have a practical reference model, so that ‘normal computing’ can be done with the data;
    • flexibility must exist in the delivered artefacts, enabling them to be to be adapted seamlessly to a reasonable number of variations on the basic theme the artefact was designed to address;
    • the costs of the framework must plateau out and reduce in a 5-10 year timeframe;
  • delivery:
    • what is delivered must be directly usable by normal programmers and developers – it must be in the form of (almost) normal software interfaces, XML schemas, GUI forms, and other things considered normal in mainstream IT;
    • rather than delivering a huge ‘national e-health bus’ or ‘spine’, small things like single schemas for a national discharge summary should be delivered early on. Later, more complex schemas, and basic services can follow. The dream of a national e-health bus should be realised as an emergent result, not a centrally planned imposition.

Note that one of my conclusions is that what should be delivered early on could just be simple message definitions (obviously I am assuming a sufficient minimum of security etc). However, these are not the manually built messages of HL7 nor ASTM (CCR), rather they are fully generated schemas, derived from the underlying model framework. Similarly, GUI form elements (perhaps an evolution of the MS/NHS CUI) would be derived in the same way. The derived artefacts could be designated standards if desired. Also early on would be some simple services supporting demographics, notification, document-sharing etc. So clearly IHE is doing something useful today with XDS, PIX, PDQ and many other services. However, IHE is not model-based and is not sustainable in the long run in its current form.

We need to learn from today’s HL7s, IHEs, ASTMs and other concrete experiences in order to build any new intellectual edifice for solving real world problems. That means being sanguine rather than religious about their shortcomings, and actually contemplating the need to rope off a separate space (heaven 2.0) in which the next generation of intellectual design that really does address real needs (on earth 2.0) can be constructed. Possibly fairly quickly from what exists today, if the right people are involved and not too many of them.

This entry was posted in Computing, Health Informatics and tagged , , . Bookmark the permalink.

2 Responses to What needs fixing in e-health?

  1. Pingback: How could HL7 refresh? « Woland's cat

  2. Pingback: We don’t need no Semantic Interoperability | Health Intersections Pty Ltd

Leave a Reply

Your email address will not be published. Required fields are marked *