THIS PAGE IS UNDER CONSTRUCTION

Introduction

This is a new-ish classification of standards in e-health I have created based on experience rather than purely academic considerations. Suggestions for improvement are welcome.

For the purposes of this page, 'standard' is taken to be any openly published formal specification in use by multiple parties such as vendors, healthcare providers etc. Four kinds of standards are identified:

Messaging - standards for concrete purpose-specific schemas, messages; such as for particular kinds of re-imbursement, order, lab result etc; These schemas only have one use (although it might be quite wide) and are almost always hand-crafted.
Generic Content - standards for concrete generic schemas, which can carry a wide variety of content
Controlled Generic Content - standards that define concrete generic schemas, plus a formal way of defining content that can be used with these schemas
Semantic Framework - standards that define a semantic framework for defining reusable formal clinical content models within a complete engineering framework of services, layered architecture and distribution.

In the classification below, I have not tried to group entire standards, but rather the pieces that tend to be chosen in various combinations to work together by actual user organisations, typically government health departments. Therefore a given part of a standard (e.g. the CDA part of HL7v3) may appear in more than one place.

Comparison

(this will be replaced by a table soon):

Messaging standards

The underlying idea here is that we cannot do anything about how systems work, so messages are developed for each business interaction between systems.

Characteristics:

Modelling [-]
- every message schema has to be hand built;
- generally limited re-use of elements between messages;
- no reuse at all across implementation technologies, there is no way to use a message definition to generate GUI elements, service interface or other expressions

Interoperability [+]
- functional interoperability is achieved (within the limits of local variations of message implementations)
- semantic interoperability is possible depending on how tightly controlled the definitions and use of coding are
- systems suffer from semantic incoherence from GUI to persistence layers, because their messages are developed and implemented separately from their GUI capture and display, persistence, and service interfaces
- very limited support for querying

Clinician engagement [--]
- usually difficult for clinicians to engage with in order to define content for each new message => messages only approximate requirements
Economics [+]
- inflexible; changed requirements => new message definitions
- relatively low cost of use for a given message, since message structure fully mapped out - implemeters only have to generate prescribed content; no theoretical understanding required
- scalable to some point but with a linear increasing cost and often NxN complexity characteristics
- costs of system building borne separately
Sustainability [-]

Examples

EDIFACT

HL7v2 messages

HL7v3 messages (more generic message production approach, but vastly higher development cost per message compared to HL7v2)

ASTM CCR message (one size fits all approach)

Uncontrolled Generic Content standards

The idea here is still about solving communications between systems, but rather than making each communication its own message or schema, providing a generic approach that can accommodate multiple data configurations representing more or less anything.

Characteristics:

Modelling [++]
- only a single schema required; much cheaper to implement at a basic level
- however no controls on what how content is expressed in the structures defined by the schemas; two implementers are most likely to develop two different configurations to express 'vital signs observations'
Interoperability [+]
- functional interoperability guaranteed (single shared data schema)
- semantic interoperability depends totally on management of content definitions used
- basic querying supported but only useful if content definitions standardised
Clinician engagement [-]
- no direct way for clinicians to engage; clinical modelling usually done (badly) by software developers
Economics [+]
- relatively cheap in limited local contexts
- not scalable
- some software re-use within systems
Sustainability [-]

Examples

EN13606-1 XSD on its own
HL7 CDAr2 XSD on its own (more or less, although it is only partly generic at the Entry level)
openEHR Reference Model expressed as an XSD or other similar format on its own

Controlled Generic Content standards

In this category, the focus is still on controlling interoperability independently of systems - i.e. a better way of doing messages.

Characteristics - as above:

Interoperability [++]
- + high semantic interoperability
- + semantic querying supported
Clinician engagement [++]
- + clinicians can directly engage and build content models for use with schemas
- + modelling governance framework required
- + separate modelling still required for many aspects of systems, particularly GUI and service interfaces
Economics [++]
- higher costs of centralised / regional planning & governance
- lower incremental costs (i.e. cost of deal with each new requirement)
- higher implementation cost per site; some level of theoretical understanding required
- reduced cost of systems due to some software re-use
- highly scalable with a cost characteristic probably of a NlogN shape
- possibility of concrete gains in preventative and personalised health due to ability to do true semantic querying through and across EHRs
Sustainability & scalability [+]

Examples:

EN13606-1 + EN13606-2; caveat: EN13606-1 doesn't provide a direct basis for many useful clinical archetypes; no templates

HL7 CDAr2 + HL7 templates (schema specialisations of CDA main schema; limited reuse)
openEHR RM XSD + archetypes + templates

Semantic Framework standards

The focus here is different: providing an interoperable engineering framework for building systems, integrating systems, making them share information, and computing with the information. Interoperability of all kinds, not just between systems, comes as part of the package.

Characteristics as above:

Modelling [+++]
- + close to true single-source modelling - content and process models done once and their semantics appear in any technology - both in systems and communications
- + ability to automatically generate message schemas rather than hand-build them
- + supports Service-oriented Architectures (SOAs)

Clinician engagement [+++]
- + high engagement because a) clinicians know they only have to model once to get everything, and b) they can see the consequences of the models with GUI simulation.
Economics [+++]
- + lower implementation cost per site - same as for using hand-built messages
- + significantly reduced costs of system due to pervasive re-use of generated artefacts
Sustainability & scalability [++]

Examples:

openEHR abstract RM + archetypes + templates:
openEHR abstract RM ==> generate ==> multiple concrete expressions, including various XSD, database schema, Java code, C# code, and many more;
openEHR operational template (incorporating archetypes & reference model elements) ==> generate ==> Template Data Schema (TDS) e.g. for messaging, display.

The last kind is what we have been working on in openEHR in recent times. It is getting toward the goal of fully semantically informed systems and interoperability engineered within the one framework. Clearly in the above you cannot just compare openEHR with CDA with HL7v2, with whatever else. The overall framework in each case brings significantly different advantages and cost characteristics. Until recently, openEHR was not the cheapest to engage with if you are a single implementer site or company; this has changed due to the TDS; previously message-oriented standards were cheaper to engage with from a single site point of view. However if you are a region or a country, then the cost advantages of a better framework may make a significant difference on national health budgets.

IHE is not included above, because it is really a 'standard' for a transport system and leaves semantics to other standards. It could be used with any of the above types of solutions, so can't really be classified on its own. The same is true for SNOMED CT - it does not on its own provide a solution for health information, but can be used with any of the above to a greater or lesser degree.

Government e-Health Strategy

If health authorities and governments don't realise the qualitative differences, they may not succeed in creating a sustainable e-health framework (i.e. they will simply succeed in creating the only kind that we know of to date, which is one that has to be recreated every few years). One of the main reasons is that they tend to choose standards in a backwards order, i.e. by choosing fixed messages first, perhaps later engaging with content modelling, and hoping that the rest will fall into place. But theory predicts and experience shows that this does not work.

Harmonisation?

Can the various standards be made to work together? There are certainly possibilities (some are easy - e.g. openEHR / 13606). The above typology helps show how they could be integrated and what the costs are likely to be (and therefore what integrations make sense). However, it also shows which standards are not designed within a framework and are unlikely to support holistic, sustainable solutions.

Browser not supported