Why is it taking so long?

I have been working in Health Informatics my entire career as a doctor and I plan to see interoperable health records somewhere in the world before I retire (don’t worry I have more than 10 years to go). Where to concentrate my time? Australia? It may well take some time to recover from the past 5 years. The UK is trying much harder, but the environment is hostile and legalistic and only those companies with massive purses or undue cunning are surviving (actually these features are necessary but not sufficient). Denmark and Sweden are taking up the archetype approach of the new ISO standard much championed by my close colleague Dipak Kalra, who like me, has been very involved in developing the openEHR specifications. Other countries, like Australia, are betting on HL7 CDA and IHE for access. Actually, we need messages, stand-alone documents and service protocols. And, it is now being realised, standard expression of clinical content. This is something that openEHR is good at but it is not clear that it is necessary until people really start to share information. It is interesting that openEHR, with its development largely in Australia, began to be taken seriously in countries like the UK and the Netherlands who had already embraced HL7 version 3 and CDA.

There are two broad visions of the e-health future that people now embrace:

  1. A world where every vendor goes out and builds a system just how they want and makes it do everything that their users want. “Nothing should get in the way of that”. Other users and patients can then get access to this information and share it via messages. “Just tell us what you want and we will give it to you”. Vendors and clinicians spend years configuring these systems: all unique and each working with a variety of messages that are sent in the local environment.
  2. A world where there is a standard format for personal health information and a standard service interface for reading and writing that information. How personal health information is actually stored behind the service is up to the vendor of that EHR service. There will be bells and whistles to go with each flavour. Application vendors will write their applications based on the standard EHR and configuration will be done in a collaborative and cooperative space. Hospitals and even general practices (if they wish) will be able to have their records independent of any clinical application. Patients will too! Clinicians take a key role in determining what content is required and how it may be structured effectively and efficiently to “boost” their performance. At times, data to be collected will be for the person’s long term benefit, such as determination of risk of stroke or other preventable catastrophe. Other times, it will be structured to ensure the best possible outcome for the patient, such as an emergency presentation of chest pain.

I have chosen to work on the second approach since 1986. Why am I working on this when the first is the massively dominant approach at the moment? The answer is: because I believe it will get there first. “How?” you might ask. Simply because the first approach cannot deliver. Imagine if we worked in a world with thousands of word processor applications — actually hundreds of thousands — which did whatever you needed to allow you to write things that were important to you in just the way you wanted. And then each vendor could get together and agree how to use XML or other standards to extract the paragraphs about your family, those about your medication, or those with pictures so you could share them with colleagues doing the same sort of work. Each of these messages would be specific to that type of information and ideal for exchanging these. We could even have special messages for sending information about more complex groupings of the information in these agreed messages — which could be slightly different if required in different jurisdictions. Does it sound plausible? Well, if you consider the complexity of health information compared to word processing documents, then you begin to realise why it is not attractive to me.

So where to start? The first problem is to agree about what is needed clinically, how to allow structure and narrative to coexist in a manner that helps clinicians find relevant information. To do this we must be sure that the critical things that computers need to provide the functionality we seek are done in a consistent manner throughout. The rest, in openEHR, is in the archetypes: the clinical statements or models of what is to be recorded and how it may be structured. These statements are formal and can be used, in the first instance, to provide system developers in our current setting with a very helpful indication of what is required and what will be shared.

The approach allows us to decide what we want to share and how to structure the information. Once we have decided upon the information that we want to share, we can involve a broad range of clinicians, consumers and other users in what we might want to say in a structured way about this thing that is to be shared. These requirements can be pulled together in a collaborative manner over the web using the new openEHR Knowledge Manager to provide an inclusive and maximal data set. This can be tailored later for local use. Ian McNicoll has discovered in his work with clinicians in the UK NHS that they find it easy to say what they don’t want in a data set but find it much more difficult to say what they do want when presented with a blank sheet. The “maximal dataset” archetypes provide the ideal starting point. The natural sponsors for specifying content are national jurisdictions and the international clinical community. The engagement of clinicians is crucial: it must work for them or it will not be used.

What is next? Well, hospitals and jurisdictions can now choose to hold their records in a standard format; not just an exchange but at the heart of their system. Their purchasing then requires applications to read and write to their records, just like a locum clinician is expected to use the clinic’s record system. But now they can bring in an intensive care application best suited to their needs, the ophthalmologists can use their own application with all the features they require and the gastroenterological researcher can even collect their research data in the clinical environment (after all 95% of it is straightforward clinical data). So far this has only happened twice, but this year it looks like more will take the step. After all, if we are to have any progress we need early adopters. If the collective “configuration” is available through shared sets of clinical archetypes then system developers can choose to build their product on a standardised EHR. The benefit is that all the transformations required can be cooperatively determined with shared tools and the evolution of the information is not their responsibility. There are now 3 clinical application vendors taking this approach in Australia and 2 in the Netherlands. These applications then become the choices for the hospitals and others with standardised health records.

There is another important benefit to agreeing upon the logical record and archetypes. For the last 30 years or so we have been trying to use terminology effectively. Initially ICD and ICPC provided terms suitable for classifying morbidity and reasons for encounter. The UK and the College of American Pathologists were more ambitious and have brought their diverse individual efforts together to provide a very large bag of medical phrases and a proposal of how to string these together to provide unambiguous meaning. The fact is that free floating terminology will always be potentially ambiguous and determining the meaning of phrases that are constructed from such a large set needs considerable computing power. I have no doubt that it is an intellectually satisfying task and does what Galen, the pioneering project in the field, described as “making the impossible very difficult”.

Archetypes provide a context for terminology and massively reduce both the processing demands and requirements. This is being acknowledged by many thought leaders, particularly those who are trying to work with current messaging technologies. An archetype agreed by clinicians in a few minutes which is quite unambiguous can send SNOMED CT experts into a frenzy trying to determine which codes relate to which part of the archetype. If we want system developers to use SNOMED CT any time soon in their products then it is beholden on us to make this feasible and empowering for communication and automatic processing.

Agreeing on a “logical record architecture” and a significant set of archetypes (in the hundreds) provides a foundation for health informatics that has not been available to this point. It will take a while before the real benefits are obvious. It will, after all, be like having Microsoft Word files — even if you use Open Office or whatever. Different tools and applications will be able to work on the consistent platform; not just any arbitrary platform but the platform of consistent representation of personal health information. Decision support can now work on information captured at different locations, population data is available in a straightforward manner and the representation of clinical data is no longer conjured in small backrooms of thousands of hospitals around the world. Health care’s greatest asset in providing quality health care, the longitudinal health record, can be available in a manner that suits the environment and the patient it supports; the patient may choose to hold it on a memory stick or phone, in a secure EHR bank, or with their general practitioner or favoured provider. It may be distributed in large part for convenience or due to privacy concerns. Importantly, it may hold different summaries at different points of care or different types of users. And all of this is multilingual from the ground up.

Australia was on the brink of taking this route — “common sense” pulled us back. With Denmark and Sweden now joining the UK and pursuing this path and with changes at the helm at many levels in Australia, it might be time to look over the precipice again. It feels safer when you jump with others.

Declared interest

  • Director of the openEHR Foundation.
  • CEO of Ocean Informatics who make a living supporting the uptake of openEHR.

Posted in Australian eHealth

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.