Bags of problems
It seems that there are very few people involved in health information standards that are able to discern the difference between a thing in the singular and things in the plural! Perhaps many people can discern the difference but just don’t realize how difficult it is for computers to discern the difference. So often I see examples of scant regard for the critical differentiation of singular vs. plural in data specifications and clinical terminology.
Why is this such a problem? Well, the issue is fundamental to the design and implementation of clinical information systems and for intersystem communication. Whenever there are collections of items to be captured, stored, processed, communicated or displayed, the software engineer needs to ask herself: do these items represent the same type of concept or object? Can there be two or more identical objects of the same type? Is the order of the items important? The answer to these questions often changes the way a system is designed and implemented. If the software engineer needs to ask these questions, then the information modeller should do so too.
A list of medication orders is not the same as a single medication order. A vital sign is not the same concept as vital signs. In information systems and messages, these concepts need to be treated differently! The information structures need to be different. The operations on those structures need to be different.
The problem has really become dire where poor information specifications have been married to faulty terminologies by people who don’t seem to understand the implementation implications of these fundamental issues. Nowhere is this more evident than with recent HL7 CDA specifications, rushed out in the USA under the name of “meaningful use”. There is an almost anal obsession with “coding” and labelling every piece of data ( often the same data is coded/labelled multiple times!), to the extent that it appears more important to label and code the data item than it is to pay any attention to the actual meaning of the code or label or the actual meaning of the things being labelled, or the relationship to other data items, or to how easy or difficult it might be for every system that may need to parse the document in the future! In one HL7 CDA document I saw no fewer than 7! consecutive different labels/codes introducing the vital sign section of the document.
Now if a computer is trying to parse an HL7 CDA document and it is told that the next section is about “vital signs”, it would be handy to know that there is the possibility that there might be more than one vital sign – that we are referring to a collection of observations, associated with each other in some way. Yet if we turn to SNOMED CT for a code for vital signs, what do we find? We find a veritable chameleon, an hermaphrodite! A single and plural at the same time!
In SNOMED CT, the fully qualified name is “Vital sign (observable entity)”. The preferred term is “Vital signs”. There is also a synonym description “Vital sign”. Now if that is not having a bet each way, I don’t know what is. If we treat the concept as a singular, then SNOMED CT is rather nice, because it provides the specialisations of a vital sign for us, namely Blood pressure, Respiration rate, and Pulse rate. In this case, the 3 specialisations of a vital sign, also happen to correspond to the 3 constituents that make up the often accepted concept of the collection “Vital signs”. Unfortunately, we can’t rely on this in any generic way with SNOMED CT. It just happens to work for vital signs ( err, or did I mean vital sign? ).
It is also interesting to note that nearly all the recent HL7 CDA documents derived from the US Continuity of Care Record and Continuity of Care Document happen to have 4 vital signs, none of which is blood pressure. It seems so many people are blissfully unaware of the importance of actually getting the information modelling right! And that means right clinically, right computationally, and right semantically.
Until we get the fundamentals right, including differentiating singulars from plural, and understanding the fundamental nature of collections of things, in our terminologies and our information specifications, there seems little point in sharing clinical documents with the expectation that our computers can process the atomic data reliably, safely, or even just meaningfully.
Some corrections to this article:-
Firstly, what constitutes a “vital sign” is probably not agreed amongst clinicians.
Secondly, what should be reported in a vitals signs collection might vary from context to context.
Thirdly, SNOMED’s 3 specialisations of “Vital sign” are probably not complete and authoritative. It is impossible to find out what the status of the 3 specialisations actually is!
Fourthly, I had no grounds for saying that SNOMED’s three specialisations of “Vital signs” correspond to the often accepted concept of the collection “Vital signs” .
Fifthly, what the HL7 CCD specifications require for vital signs is difficult to determine, but I can find no specifications or examples that explicitly include “blood pressure”. There are many that document “systolic blood pressure” and “diastolic blood pressure” as distinct, uncorrelated observations. There are also many that optionally include “height”, “body weight”, “head circumference” and “blood oxygen saturation”.
So, it appears there is probably no clinical terminology that can authoritatively tell us what constitutes a collection of “vital signs”.
It also appears that HL7 has no advice on this matter, and it is left to suggestions like this to offer some approach to standardisation, even if only for clinical documents. What a nightmare for semantic interoperability!
How long will it take for the broader e-health community to realise that we need agreed clinical information structures and that a standard set of archetypes offers so much potential to dig us out of this seemingly endless quagmire!?
Eric,
Is there a risk we might be trying to over-engineer all this and that there are some simpler approaches that might get us a good way along that are easier to implement and support? A genuine question – not a statement as I for one am sure I do not know the answer!
David
David,
“Is there a risk we might be trying to over-engineer all this and that there are some simpler approaches that might get us a good way along that are easier to implement and support?”
It is a valid question! But so too is the question “is there a risk we might be trying to under-engineer all this?”
Firstly, I think that such questions should be answered by engineers. Secondly I think it largely boils down to your definition of what is “a good way along”. If all we want is some electronic analogue of paper case notes aggregated across institutional boundaries, then we don’t need structured information. Clinicians could just search through the patient’s EHR looking for relevant information. This would likely be a considerable improvement on the current situation, and would give all participants involved in the patient’s care access to a common set of information.
However, if we want decision support and all the attendant benefits so often cited in business cases, and on your blog, then well structured information ( and supporting infrastructure like terminology services) is required. What we have not seen to date are specifications for system to system communication that provide “well structured information” in the sense that they could achieve these benefits. So, I would describe all the clinical messaging standards to date as “under-engineered”, whilst overly complex to implement and support.
But that’s just one engineer’s perspective.
As a software developer, specialising in the health domain, I don’t really see that the problem is with the failure of Clinical Messaging/Document Standards – or, for that matter RDMB systems and OO models/frameworks – to support the basic collection/member hierarchy. The real issue is that the current implementations have rarely been designed with interoperability as a requirement and so lack the requisite degree of granuality. Blood pressure is a good example because Systolic BP and Diastolic BP are distinct observations and the fundemental unit in the relevant implementation should recognise this. Thereafter, plenty of means of linking these exist (e.g. HL7 v2.4 OBR segments or CDA organizers) – but if multiple observations are stuffed into a single string in DBMS this can only be replicated in the messaging and presentation layers.
I agree with you, Non Runner, that “current implementations” have rarely been designed with interoperability as a requirement”, but the problem is exacerbated by the current clinical messaging and document standards. Just consider blood pressure as specified under HITSP C32 reporting requirements in the USA (I’d cite Australian Standards, but am not aware of any that prescribe blood pressure), where the HL7 v2 based standard says: place blood pressure in a single OBX segment with datatype SN.
The exact same C32 standard also supports reporting in HL7 CDA, this time with the two granular “systolic” and “diastolic” codes as separate observations, but no “blood pressure” parent observation, and thus no way to query the document for blood pressure!!
The fact that there isn’t an Australian Standard that says how to represent blood pressure in HL7, means that there is no chance of interoperability, even if the systems all collected blood pressure to the “requisite degree of granularity”.
HL7 CDA does offer several possibilities for linking observations – namely Organizers, Code Translations, or even EntryRelationships – provided that the relevant Coding System(s) has/have codes for both the parent and child observations. Therefore, I don’t think that the problem rests with CDA, which is a highly flexible standard, but with the coding of the data and (maybe) even the Coding Systems themselves. As for querying a CDA directly, a better approach may be to limit that to populating an Application Data Model and providing a configurable reporting tool that allows end users to group observations where a Coding System does not – possibly according to national standards.