Recently HSCIC and NHS England published an Interoperability Handbook, intended to help provider CIOs and others steer the difficult waters of obtaining interoperable health IT solutions. The target audience is listed as:

CCG Clinical Leaders, Chief Clinical Information Officers, Chief Information Officers, Directors IMT

so the publication can be understood primarily as an aid to procurement and in-house planning and development of EHR and other clinical information solutions.

I won’t provide a proper analysis of the document here, other than to say that it is likely to be a useful resource for its audience, and a good starting point for ongoing conversations and education in the e-health solutions area within the NHS (even just establishing standard nomenclature in the NHS for talking about the relevant concepts is a worthwhile exercise). Interoperable solutions are a huge engineering enterprise, so hopefully it will be understood that documents like this one act as useful reference points, but in no way replace the needed human resources and competencies to plan and deliver actual solutions.

However, I do have some comments…

One of the things the document does is to identify technical standards for use in the planning, development and procurement activities. Since procurement is widely recognised to be one of the weakest points in the NHS environment (at least in terms of outcomes for broad health data interoperability), understanding and being able to use standards is a crucial part of establishing a platform environment for sustainable health computing.

The discussion on standards is accompanied by the usual comparison table (Appendix A), which in this case maps standards to ‘interoperability framework layers’.

This comparison is what I want to comment on, since it could do with some adjustments to correctly represent the standards in question.

The table as published looks as follows. The framework layers are down the left hand side, and are reasonable as a starter set of analytical headings for this purpose, although I think improvements are possible.

Mapping of current standards to interoperability framework layers

Across the top we have the various standards in use or mooted for use in the NHS, and the table indicates what framework layers, according to HSCIC, each standard addresses.

What are the issues here?

Data Structures

The main area that needs work is the ‘data structures (logical)’ layer. This layer is defined in the document as meaning

‘Used to create consistent data definitions that can be re-used across different implementation standards or technologies.’ (Table 3, p43).

Section 7.6 lists standards considered to support this concept – that is, logical information models that are independent of implementation technologies. openEHR is listed here.

Let’s note, for the avoidance of confusion, that the reason for this is because openEHR (and its ISO counterpart, ISO 13606)  provide a content modelling language and capability, known as ‘archetypes’ that allow modelling of content models based on any underlying information model (specifications here). Now, the openEHR model was designed to reflect key domain (i.e. health data) primitives, and has proved to do so relatively well to date, with the result that hundreds of clinically authored formal content models are available for use in health data systems, e.g. here at the Clinical Knowledge Manager (CKM), also the HSCIC CKM.

My point here isn’t to advertise openEHR; it is to make clear the ‘content modelling’ capability provided by the Archetype formalism is something that enables clinical content to be modelled more or less separately from concrete information models. This is true even in openEHR, even though the one information model (we call it the Reference Model or RM)  is used both for archetyping and data representation. The reason this works is that archetypes use very few RM properties, and represent most clinical data items using free-form tree structures. On the other hand, for data representation, persistence and communication, the rest of the RM, consisting of numerous context items (participations, times, author, places, etc) and machine ids is used.

This argument would apply equally for archetypes based on another reference model designed with the same intention, and in fact, we can talk about the CIMI archetypes, whose RM doesn’t include any of the concrete data representation elements, but does include the generic elements needed for pure archetyping. CIMI may well become relevant, because it is becoming an HL7 Technical Committee, and will be used to inform the modelling of domain content in FHIR.

It’s important to understand that (well-designed) archetypes really are implementation independent. In openEHR, we routinely generate the following implementation specific artefacts from these models:

• canonical RM based ‘Operational Templates’
• message-specific XSDs
• API interface classes
• REST URIs
• query fragments

This isn’t possible from the ‘data structures’ of any of the other standards; on the contrary, the data structures are modelling within the primary implementation formalism, generally some kind of XML.

Now, when we look at the table, the ‘Data Structures (logical)’ row has ticks for HL7v3, FHIR, openEHR and IHE. This isn’t really correct. What the authors of the table were most likely trying to say here are that HL7v3 and FHIR have methods of defining something like ‘templates of content’ (HL7v3 – RMIMs; FHIR – profiles+extensions). This is true, but this capability is separate from the implementation technology independent content modelling capability intended to be documented under the ‘Data Structures’ heading. The table is actually documenting something I would call either ‘profiling’ (HL7’s favourite word) or ‘templating’, which is a useful thing to document. IHE should not have a tick here, because although it is based on something called ‘profiles’, these are to do with selection of elements of other standards to make up a particular case-specific ‘templates’, e.g. a microbiology lab message using HL7v2.5. IHE profiles are not formal or computable – they are just documentary specifications.

The modifications I would therefore make to the table here are:

• The Data Structures (logical) row could be renamed to Content Structures; only openEHR gets a tick here, if the meaning is ‘direct support’ (but as mentioned above, there is in fact nothing stopping the openEHR approach being used with other Information models).
• Add a row called Information Models
  • HL7v3, FHIR, openEHR get ticks here
• Add a row called Templating (or Information Profiling…)
  • HL7v3, FHIR, openEHR get ticks here (IHE doesn’t because it has no formal profiling method)

Querying

The other main issue I have with the table as it stands is that it completely omits what is arguably the most important framework layer: a means of semantic querying of the data, i.e. querying the data using the formal elements of the content models, for example ‘systolic blood pressure’. The authors may intend all querying to be based simply on the use of SNOMED CT, but this won’t work in general, since SNOMED knows nothing about the content structures in which clinical data are reported, only the concept codes of real world referents. Some sort of querying is certainly possible using only SNOMED CT, if all elements of clinical data are ruthlessly coded by applications and users. We are many years from that being the case – SNOMED CT requires years of adjustments (it is only now being aligned with upper ontologies like BFO2 for example), and no current EHR systems routinely code all (or even most) clinical data, other than UK GP systems via READ codes (exceptionally, this subset can be regarded as pretty dependable and clinically safe).

Portable (i.e. DB-schema independent), semantic, querying is one of the innovations of openEHR, which defines the Archetype Query Language (AQL – specification), and many of us believe that this kind of query approach (even if not literally the openEHR one) is the future of querying health data based on content models and terminology. SNOMED CT querying is enabled within AQL, without requiring the merciless coding of the millions of data items recorded by every application. This is because no coding at all is needed to find an ‘instantaneous systolic BP’ or a ‘3 minute Apgar heart score’ if archetypes are used. I’m not saying we shouldn’t code these things (particularly for interoperability purposes from NHS to external data partners), but it’s not needed computationally within environments relying on the same archetypes. Exactly the same argument would apply to PRSB clinical document headings – no SNOMED codes needed here either.

Accordingly, I would add a row to the table for ‘Portable Semantic Querying’.

Information Governance

A minor point in the document is that the Information Governance (IG) heading is being used to cover too much ground. In the table, what is meant in that row is essentially security, privacy and trust capabilities. However, there are many other aspects of IG, that are rightly documented (p44, 45) and I would suggest that this whole area be broken out into a separate major section of the document, with its own ‘standards table’, and there are many relevant standards here.

And the Result is…

My reworking of the table according to the above is as follows.

I have treated IHE as a special case, because it is a ‘profiling’ concept, that re-uses other specific standards (e.g. message definitions, terminology) to construct use-case specific instances of those standards, i.e. specific messages etc. Thus I have inserted a ‘p’ in specific cells in the IHE column to reflect this. A ‘p’ could potentially be added to the ‘Document Headings’ row for IHE as well.

I have also changed the first row to ‘Security & Privacy’ and for now put a ‘?’ for various standards, reflecting the fact that they do have varying support for at least some security and privacy concepts. This framework layer probably needs to be split out into its own full table, and major document section.

In conclusion, I would propose some of the above kinds of changes for a new version of the Interoperability Guide. I would also point to a post I made on Desiderata for Sustainable e-Health Standards, which provides another set of criteria for appraising standanrds, some of which I think are relevant in the Guide.