Prev: The crisis in e-health standards IIa

Stakeholder Aspirations and Needs

Before going so far as to offer a solution to the e-health standards problem, I want to have a look at what we consider to be the requirements that such standards, and indeed health informatics in general is meant to address.

The most typically repeated aspirations I hear regularly from government e-health programmes (which are usually staffed by ‘believers’ in e-health) include the following:

• support a patient-centric shared health record, often a ‘summary’ record. E-health programmes seem to love the idea of centralised summary records, even though most health information transactions are local, and realistic long-distance sharing (e.g. for cancer treatment) most likely needs more than a summary record…
• support interoperability: e-health programmes have varied ideas about this, but the main common idea is that of cross-enterprise shareability of information;
• support ‘decision support‘: this is heavily aspirational; today, all they can hope for is medication interaction checking at the time of prescription; in the future, it might be true guideline-based support for deciding interventions (a few systems like Prodigy in the UK made some progress on this in the past);
• support ‘care pathways‘: this is the idea of being able to track the patient journey across enterprises, so as to know who is currently responsible for care.

If you ask government departments/ministries of health (a different beast altogether: the DoH or MoH of any country is concerned with the economics of healthcare delivery and while they may have set up the country’s  e-health organisation, is typically sceptical of it), their main requirement is:

• make healthcare delivery cheaper, and if possible, fairer, and better.

In 2007, healthcare in the US cost an amazing 16% of GDP, compared to 7% in 1970 [Christensen 2009].  Healthcare in (over-medicated? but universally cared-for) France in 2006 was 11.1% of GDP; for the same year, Australia was 8.7% and Sweden 8.9% [WHOSIS]. Improvements are clearly available in the US; if we believe Christensen, the reason for the difference between the US and other developed countries is ‘the runaway reactor of fee-for-service reimbursement’. Key reasons for the high cost of healthcare everywhere  (i.e. why it is higher than it could be) appear to include:

• over-supply & over-utilisation, for reasons ranging from the logistical (lack of ability to share data) to the venal (why not bill for another unnecessary test? Such easy money…);
• the rising costs of largely preventable serious complications of chronic diseases like cardiovascular disease, diabetes, and cancer, many exacerbated by poor modern lifestyles;
• numerous inefficiencies, including poor business models.

(See NY Time article, 2007, Harvard Business School article 2004, Health.org article 2008 for a few examples; Christensen’s book is also an excellent resource, even if US-centric).

If we were to ask clinicians what they want, at least some of them would say: more direct ability to ‘manage the patient’. Today health professionals of all kinds are more or less locked-in in two ways: by the business structures in which they work, and by inflexible information systems. The latter make it difficult to track patients, particularly across enterprises, and also to change the workflow and data capture in the computer applications they use. Healthcare professionals would like to share information (in a controlled way); and they would like to be able to do more personalised health, but don’t have the ability to a) share and aggregate data for a given patient (i.e. a patient-centric health record) or b) compute with the data with business intelligence tools. Most recognise the EHR as a good idea, if done right.

Healthcare and related professionals in secondary use areas – particularly medical research and public health – have an even more acute need with respect to data: they need it to be shareable, to be aggregated into large cohorts, and to be safely computable. They want open data, and that means open data standards for health information.

What about provider enterprises? Their needs are not the same as clinicians. As economic entities, they provide the place where healthcare is delivered and are mainly concerned with process and efficiencies. From their point of view, unnecessary bed days (e.g. due to adverse events), inefficient business processes and having to renew their IT systems every 5-10 years contribute heavily to costs. They need ICT that works across departments, can support process, and particularly that won’t lock them in to single-vendor monolithic solutions.

What do patients want and need? In the US, they probably want healthcare to be cheaper – unbelievably (at least to me!), ’62 percent of all bankruptcies filed in 2007 were linked to medical expenses.  Of those who filed for bankruptcy, nearly 80 percent had health insurance’. (National Coalition on Health Care article, 2009). In the rest of the developed world, where a reasonably good level of universal healthcare is available, and there is far less reliance on private insurance, direct cost is not as great an issue for the patient as in the US. Key needs for patients in both poor and wealthy parts of the world include:

• not having to fill in the same forms, answer the same questions again and again and again and …;
• for the chronically ill, to be able to have a health record that they themselves can contribute to, and share with their care team;
• avoiding medical errors, which cost lives, cause serious injury, or simply terrible treatment experiences;
• for the public health system to be more responsive: waiting lists are too long in most countries’ public systems;
• privacy: the ability to control who sees what information in their record.

Last but not least, what about solution vendors? Well, it depends. Some large vendors would like to own the whole space, and have minimal interest in standards or openness. Personally, I think the days are numbered for this business model. Many other vendors want a platform, because their expertise is on either one side or the other of the ‘magic horizontal line’, which is to say, that they would ideally like to make front-end applications (like GP desktop systems, nursing applications, applications for booking, radiology…), or, they are in the back-end space, meaning they would ideally make enterprise-capable data platforms and/or services for EHR, administration, demographics, security etc. That this doesn’t happen today is largely because of the lack of a standardised back-end health computing platform – the applications vendors of today are forced to make some attempt at back-end persistence for all their data, whether they want to or not. This has led to a huge proliferation of incompatible systems.

Distilling the Requirements

So what can e-health do about all this? Let’s try to get a better handle on these requirements. Over the last 10 years, I have distilled the technical requirements into the following list:

• Meaning preservation: information needs to be semantically marked so that its meaning is unchanged from the user interface where it is captured, to the back-end storage, and in all later environments, where it will be subject to often unpredictable future uses;
• Sharing: getting the information from source systems to a destination system. This can be achieved with only limited standardisation of the data (e.g. the IHE approach to standard meta-data, or even just sharing PDFs and images),  but it does require open service interfaces;
• Aggregation: merging the disparate information together to create patient-centric data, and also homogenously processible population data. This requires open data specifications;
• Reliable computability: just because you can gather and merge the information doesn’t mean you can safely compute with it; computability requires semantic marking and a semantically-enabled query methodology;
• Adaptability: systems must be continuously adaptable to change the information and processes that are managed by these systems; this requires a flexible architectural framework that avoids the continual 5 year system replacement and data migration-and-loss cycle;
• Openness: to avoid lock-in to proprietary data and applications, the specifications of services, information, content, process and querying need to be separate from vendor systems.

These needs can be summarised in terms of an open health computing platform, consisting of the following:

• openly specified service models, including for the EHR, demographics, terminology, resource location, medications and other reference data, security services etc -> allows us to share data and knowledge;
• openly specified information, consisting of common models of data types, basic data structures, ‘clinical statements’, various kinds of documents, particularly for cross enterprise use: discharge summaries, referrals  -> allowing us to aggregate data;
• openly specified semantic models of content and process, allowing systems to reliably compute on data representing domain level notions like blood glucose measurement, cholesterol result, antenatal examination, prescription;
• openly specified model of querying, allowing the locked-in health information to be retrieved for secondary uses as well as point-of care.

As pointed out above, all of this needs to be within a flexible framework that avoids system rebuilding and deployment every 5 years (not to mention a new phase of e-health programme in every country). There is one other requirement which has emerged strongly among health professionals and informaticists: since there is a lot of ‘modelling’, it is a must that any given model (say of ‘blood pressure’, or ‘ED patient workflow’) be done once only for all uses, whether it be messages, screen forms or any kind of reporting. In other words, single-source modelling. This implies that we should generate, rather than hand-write concrete point-to-point ‘standards’  such as particular message, form or document definitions.

We also mentioned some key economic requirements here, which I would distill as follows:

• in all healthcare systems, there are major inefficiencies due to over-utilisation and errors, which would be reducible if made transparent by being exposed in high-quality health records, shared within and across enterprises;
• there are major inefficiencies in the health business models of today in at least some countries (US is the leading example), including due to the mismatch of fee-for-service and fee-for-outcome work and the provider enterprises; Christensen sees an open EHR as a mandatory enabler of splitting these different businesses apart;
• there is a massive inefficiency in the health computing market, due to the lack of an open platform definition. The general data processing market realised long ago that standardising on SQL was better than sticking with proprietary databases; the health sector must do the same. Society demands a healthcare ‘machine’ that is nicely oiled; what the vendors are giving them is glue and iron filings.

Without going into all the gory details, it is clear that a) a cross-enterprise, patient-centric EHR is needed, and b) vendor solutions that supply it must be based on a common health computing platform.

The above is my description of the long-term project for the health informatics domain. It is clearly not a project for de jure standards bodies – as previously mentioned, they don’t have a proper engineering method, they don’t make use of implementation as a primary means of validation, and they have little or no maintenance capability (evidenced by the general inability to accept or process problem reports, or to quickly issue new releases). And yet, since this platform is to be open, it is clearly a ‘commons problem’ in the sense of Hardin. So while it needs industrial means (i.e. what I mean by ‘engineering’ above), individual industry entities cannot on their own produce the required result.

The structure of the domain

Am I saying there is no longer any need for vendors, i.e. that once this ‘platform’ is built, we have everything we need? Not at all. Just as BMW, Hyundai and Chevrolet build cars that assume standard unleaded fuel, standard wheel sizes, standard air bags and standard spark plugs (ok, I may be showing my age here, but you know what I mean), the rest is up to them. In other words, the information and knowledge I see being part of the open platform described above is still a fraction of all possible elements of a fully manufactured production health information system. So now we have 3 levels of ‘open/closed-ness’:

1. the ‘whole product’: what vendors build, and if left to themselves, are almost completely non-interoperable;
2. the ‘common platform’: what is needed but does not exist today;
3. what can be officially standardised: particular proven elements of the above that are worth setting in stone for long-term use.

Level 2 is more or less non-existent today. Level 1 will always be needed, because we need quality products backed up by capable delivery and support organisations. If level 1 can be ‘civilised’ by level 2, then the long term goals will be met. Level 3 – standards organisations – cannot produce level 2 outputs, so we need a new kind of approach: an organisation that can engineer an open health computing platform.

A Blueprint organisation

In previous posts I have alluded to its characteristics, here I will briefly list them:

How it functions:

• governance:
  • it must be one or more dot-orgs, not dot-coms, and needs cross-industry funding and support;
  • representation of all classes of stakeholder, probably at board level;
  • its outputs must be open for inspection by the public, including for raising issues;
  • it must have a structure that enables technical and domain experts to engage and interact effectively;
• it uses engineering development methods (possibly more ‘agile’ than ‘classical’), i.e.
  • it has dedicated activities for requirements capture, analysis, design, implementation-based validation;
  • it has project teams staffed with technically competent people;
  • project management is taken seriously, particularly with respect to deadlines;
• it has a maintenance capability, including:
  • version management of all artefacts;
  • release management;
  • issue capture and tracking;
• dissemination of all specifications is available in computable as well as documentary form – e.g. schemas, open source software components or libraries;
• a built-in capability to engage domain experts, including the via provision of expert-friendly formalisms and tools, and ability to accept domain models into the overall framework.

What it produces:

• a flexible framework that allows specification and building of models, including:
  • specification definition and publishing tools;
  • tools that enable the building of models of domain content, process, and also queries, by domain experts;
  • software implementation and testing tools;
• abstract, formal specifications that obey ontologies for the domain, including:
  • information model specification(s);
  • service interfaces;
  • a repository of domain models of process and content;
  • a query language / model that is independent of any particular storage system or database;
  • terminologies;
• concrete expressions of the specifications including (in various specific technologies, such as XML-schema, SOAP, programming languages etc):
  • documents;
  • UI components and forms;
  • message definitions;
  • service interface definitions;
• software implementations that validate the specifications and models;
• a conformance-testing framework, defining categories of conformance and a method for testing products against specifications.

In my view, all of the above are mandatory. There are undoubtedly other desirable capabilities.  The bottom line is: no platform, no progress.

And the standards organisations of today?

This is the hard bit. Due to lack of the level 2 organisation above, the numerous people in the health IT domain who want to make progress have limited options, including the current standards organisations. As noted in the first post in the series, some of these people and organisations are trying to create level 2  – whole framework – outputs from within level 3 organisations. Due to the process and culture mismatch, this is mostly failing. Others spend their energies on classic point-to-point specifications like CCR or HL7 messages, which have (respectively) no underlying semantic framework, or one so difficult to use that it is not a candidate for generalised use. Such standards have utility today, but will undoubtedly be incompatible with the health computing platform of the future. How much this matters will depend on the costs of data conversion and/or re-engineering in the future.

Organisations like IHE and HITSP generate point-to-point standards that appear to be actually usable, and are tested. However their strategies may not be sustainable – just think of the combinatorial explosion of bits and pieces from existing standards (already too complicated and messy in their own right), and the propensity to create new kinds of mismatch errors. They certainly won’t lead to a general-purpose open health computing platform, but they may generate enough of what is needed by some organisations in some circumstances to be needed for quite some time.

And the ‘main culprits’ in health – HL7, CEN and ISO? In my view, if you are any kind of stakeholder, with a long-term view of the domain, you won’t get what you want from these organisations. You may get some short term needs satisfied, but even there, you are more likely to want to rely on IHE, HITSP, or CDISC. If your real need is a cross-organisational talking shop, then you will get a lot of value from sending people to the meetings, but you still won’t get results, and I would even say that due to the lack of a coherent specification framework, the situation is likely to get worse, not better.

Recommendations

How can we turn what we have today into what we need for the future? Here is one suggestion. There are three organisations I believe have a good handle on the parts of the overall problem they address. I believe that a concerted and funded approach to supporting a combined e-health forum – either a new .org or some other kind of cross-organisational governance and technical structure – formulated according to the above blueprint, has the best chance of success if we are not to start absolutely from scratch. These organisations are (in no particular order):

• The openEHR Foundation: I believe this organisation has the best handle so far on basic information models and content, and generates both computable specifications and implementations; its domain modelling ADL formalism is a CEN and ISO standard, and it has a growing number of clinical models appearing online;
• The Object Management Group (OMG) [Health vertical]: this organisation has a strong engineering culture and a good process and has a history of producing quality health domain specifications; it is currently being underused in health; they also have the necessary experts to show how to connect models and modelling problems to their cross-industry platforms;
• The International Health Terminology Standards Development Organisation (IHTSDO): this organisation has strong governance, a good handle on terminology and tooling, and participation of world experts.

These are not the only elements needed of course. Experts from all of the other organisations I have mentioned, as well as key universities and companies would be needed. The weakest point is almost certainly in the ontology area (although it needs to be tempered with the needs of implementability and quick delivery).

I am very interested to compare {the costs of standardisation in e-health as it is done today + costs of national e-health organisations in trying to solve the problem} to the costs of creating the above organisation. I suspect the latter would cost far less, has a greater likelihood of producing the platform, and would do it more quickly. It may even be that an organisation like ISO TC215 is a place where this radical project could be discussed and planned.

A secondary recommendation would be to treat ISO TC 215, CEN TC251, HL7 and other such organisations as cross-industry meeting places, and re-orient their activities accordingly. We need such talking shops (that’s how we share and create new ideas) … why not be honest about why we go to these meetings and recognise the real potential of these organisations?

In sum: we have a commons problem … and it is in need of an uncommon solution.

…with sincerest apologies and best respects to all those who participate in and run e-health standards meetings all over the world. It has been a privilege to know you.  Your enthusiasm, expertise, and stoic acceptance of the pain of constant travel deserve better. I hope we can do better.

References

[Christensen 2009] The Innovator’s Prescription. Clayton M Christensen, Jerome H Grossman, Jason Hwang. McGraw-Hill 2009. My friend Tomaž Gornik at Marand, Slovenia insisted I read this book, and he was right. Although US-focussed, most of it is likely to apply health economics in other countries. Its treatment of the EHR is technically somewhat weak, but it recognises the EHR as a key pre-requisite for the reforms they propose.

[WHOSIS] WHO Statistical Information System, accessed 17/Oct/2009.

Prev: The crisis in e-health standards IIa