SNOMED on FHIR Meeting (TB) - Tuesday 21 August 2018

Daniel Karlsson Here's the material I presented at the end of tonight's call. It presents candidate ECL expressions that are intended to identify all SNOMED codes within the current UK release of SNOMED that, clinically speaking, would be expected to count and be returned as a flavour of one or other 'vital sign' that must therefore be sent using the core 'vital signs' profile of the FHIR Observation resource.

For each flavour of vital sign so presented, the general pattern of the corresponding ECL expression is:

An inclusion clause to identify an entire relevant subbranch of the taxonomy of SNOMED  Observable Entities, followed by a MINUS exclusion clause that excludes those subflavours of the Observable that are not, in fact, vital sign measurements. The latter typically includes codes for e.g. the reading you'd like the patient to achieve in future (e.g. in response to treatment) but which they presumably do not yet have, and other codes for the highest and lowest readings either permitted or actually seen during some unstated interval of time. But there are also other more idiosyncratic exclusions, depending on what non-vital flavours of the relevant biometric parameter currently have codes in the international edition or its UK extension.

Amongst other questions raised by this extended thought experiment is a pure practical engineering issue: how should intrinsically changeable definitions of semantically 'covering' terminology bindings be most efficiently bound to individual machine readable encodings of the relevant FHIR resources. ECL expressions similar to those suggested here could be copied directly into the resource encoding, but that would require a new release of the resource encodings whenever the ECL had to change. Alternatively all such ECL expressions could always be held terminology-server-side as SNOMED Intensional RefSets, and so all FHIR resource encodings would then represent the SNOMED terminology binding element of their construction only by means of a RefSet identifier, whose actual definition from one month to the next - and subsequent operational expansion against some nominated SNOMED substrate into a fixed list of codes selected from that substrate - would have to be handed off to a terminology service. This would insulate the FHIR resource encodings from changes to the bindings required by SNOMED's own evolution, but potentially adds a new maintenance overhead on e.g. NRCs