Inca masonry – key to interoperability?
A couple of years ago I had the pleasure of visiting Puka Pukara high above Cusco in Peru. The work in building this fortress demonstrates attention to detail. Each stone is carefully shaped to fit into the overall architecture. Edges are knocked off until each piece forms a part of a cohesive structure.
I was talking to a fellow International Standards expert this week, sharing the challenge of building an architecture out of the host of international and local standards available to represent health and care records and, possibly more importantly, dynamic health and care plans. He said thats its just like Inca Stonework, which took me aback. He is right.
The great thing about standards is that there are so many of them to choose from.
Admiral Grace Hopper
The variety of health and care informatics standards is often a barrier to their use and usefulness. In the NHS we have (as Nationally promoted standards for sharing care record information) EDIFACT, HL7 V2, HL7 V3, HL7 CDA and HL7 FHIR. We then have a wide range of data set specifications with XML schema for transmission.
This list just handles the syntax of sharing information about the health and care of people – it doesn’t address the storage of the record (we have ISO 13606-1 and its derivative the OpenEHR reference model as standard representations and each vendor has their own physical data store and schema) or the clinical models that configure the care record management systems for use in the context of delivering care (ISO 13606-2 Archetypes and proprietary configuration templates). It is these clinical models that bring the care record systems to life.
And still this isn’t enough to share the meaning in a way that empowers computers to support decisions. We need a language for health and care (reference data) with SNOMED CT providing clinical terms, Unified Code for Units of Measure (UCUM) providing computable empirical units, the dictionary of medicines and devices in the UK for regulated products and a wide variety of other standard vocabularies such as ISO 3166 for a list of countries – there are many more such vocabularies out there for different properties.
So how can we shape these different standards to work together. Well, its just like Inca Stonework. Each standard has to be carefully positioned in the right place in the architecture. Before it is placed, the rough edges need honing so that we don’t end up with two standards trying to do the same thing, and we need to make sure there are no gaps.
Great article. I note you mention openEHR. I am sure your very familiar with it but the blog below is a nice summary of the strength of openEHR standards:
Vendor Neutral
Technology Agnostic
Maintainable
Interoperable
Standardized Data
Computable Data Specifications
Versionable Data
Driven by Domain Experts (Clinicians)
Supports any Terminology/Thesaurus/Coding System
Semantically Coherent
https://www.cabolabs.com/blog/article/what_is_openehr-625c50c967a07.html
openEHR is certainly a part of the solution, Kanthan, but its unlikely to be all of the solution.
For example, “Supports any Terminology/Thesaurus/Coding System” is both an advantage and a hindrance. Both openEHR and the English preferred terminology will need shaping so that they play safely together (the Inca stonemasons).
When clinical records migrate from existing systems to openEHR or when openEHR systems are replaced by successor systems the rules to preserve semantics for systems as well as computers to understand the records will need to be defined, assessed for safety and governed.
The old approach of “degrade to text because clinicians understand the words” cannot persist if we are to allow computers to add value to the clinical process.
Thanks Nicholas. Very informative. Looking at the openEHR standards and specifications including its multilayered architecture (RM, Architypes and templates etc) migration of records should not be an issue as the openEHR is a set of specifications and not a piece of software.:
“This level of modifiability of openEHR systems allow to cut the maintenance costs to the minimum, and also can reduce the costs of reengineering, technology migration and data migration, since what’s important in an openEHR environment is the data, not the implementation technology”
openEHR allows the data to be separated from the software application. Its agnostic and vendor neutral. This means “successor systems” would be the software UI/UX etc and the data architecture being openEHR as the standard that persists thus there should be no degradation of meaning.
openEHR seems quite comprehensive to me? What would be the weaknesses of openEHR that would point you away from it? What is the most effective standards(s)?
I’m not “pointed away” from openEHR, Kanthan, but its not the whole solution.
Semantic interoperability has to work for existing and future (non openEHR) data as well as within the openEHR ecosystem, otherwise getting existing records into an openEHR representation or getting openEHR data into a future system become problematic.
As a simple example, GP data holds many records with CTV3 Read Code
ZV140 [V]PH - Penicillin allergyorSNOMED CT 91936005 Allergy to penicillin (finding). These two codes prevalent in many patient records don’t easily fit into the adverse reaction risk archetype since they combine two items into one coded concept – causative agent and allergy. This pre-defining the complex meaning is convenient for the GPs.Its not to say openEHR is wrong – the pattern is the one recommended by the PRSB, but data need careful crafting to maintain semantics. To come up with a long-lived implementation pattern (play book) there are almost certainly parts of SNOMED CT we need to trim away and parts of openEHR too.