Stream: terminology
Topic: Fate of codes outside terminology bindings
Jeremy Rogers (Jan 29 2018 at 21:18):
What, in the general case, should happen to those coded items that will be encountered in current real-world poorly-coded EPRs and that fall outside the terminology binding for the relevant resource?
By way of illustration, consider the Condition.code element and its current 'example' SNOMED CT binding, which suggests a fairly narrow scope: to only < 404684003 |Clinical finding|. This narrow binding would , however, render invalid some volume of clinically significant coded items that we know to be present in real-world Problem Lists.
@Linda Bird of SNOMED International has previously proposed a somewhat more permissive:
< 404684003 |Clinical finding| OR < 413350009 |Finding with explicit context| OR < 272379006 |Event|
..but something like the following would in truth be needed if the Condition.code binding were to cover a fuller gamut of the things that clinicians have empirically already put in their Problem Lists:
< 404684003 |Clinical finding| OR < 413350009 |Finding with explicit context| OR < 71388002 |Procedure| OR < 443938003 |Procedure carried out on subject| OR < 439763000 |Procedure on family member| OR < 57177007 |Family history with explicit context| OR < 272379006 |Event| OR < 48176007 |Social context|
But even that broader binding for Condition.code would still preclude some relatively common but semantically more wildly incorrect miscodes that clinicians are currently permitted - and therefore do - enter through modern-day permissive clinical coding interfaces as the code for the 'problem' before them. For example, codes for pieces of anatomy (e.g for lymphnode) when they really mean an unspecified disorder located at that site (lymphadenopathy); codes for substances (e.g. alcohol) when they really mean disorders caused by their use or exposure (acute alcohol inebriation and/or chronic dependency); codes for forces of nature (high temperature) when they really mean either disorders associated with exposure to those forces (heat stroke) or that the patient are themselves a source of that force (pyrexia).
FHIR implementations could choose to allow all codes that may currently appear in a Problem List to be uncritically passed as a Condition resource ... but then the terminology binding for Condition.code probably should be < 138875005 |SNOMED CT Concept| (!). Or, they could choose to constrain out at least some of the more major 'category error' miscoding choices by enforcing something in the spirit of one or other of the candidate bindings above, and press their colleagues in primary data capture interface implementations to mirror that constraint for new data capture going forward...but this would still mean that some real world historically already coded Problems could not be passed, except if re-coded by the reluctant clinician or possibly when degraded to text only.
This line of reasoning led me to wondering: what middle-ground implementation behaviors could more actively support an incremental transition of terminology binding strengths along the presumed trajectory from example (send what you like; here's a clue) to required ( send only from these) ? For example, if all codes are to be passed initially whether or not they satisfy a prevailing example terminology binding constraint, would it be helpful if senders could flag those that failed to satisfy it? Is there already a standard mechanism for passing this validation failure information in FHIR?
The alternative seems to be either (i) the problem list item is not sent (ii) it is sent but as text only (Condition.code.coding is not populated) or (iii) its sent as a coded item anyway but the receiver must re-run all semantic validation tests if it cares about the answer, and the sender has no operational reason for running them anyway. The first option is clinically untenable. The second assumes that the code is never useful, an assumption that would require clinical sign-off but that can not be proven a priori for the general case. The third option seems a missed opportunity.
Grahame Grieve (Jan 29 2018 at 22:40):
hi Jeremy. Many issues here. Some comments:
- this is a big part of reason why these bindings are only ever example bindings (which means: we don't make any rules, but here's the kind of codes we expect to be used)
- there's also extensible and required bindings.
- I strongly recommend against required bindings for clinical codes for the reasons you've described
- even 'extensible bindings' are problematic
- we also have the concept of 'best practice' bindings - e.g. 'you must use a snomed code' and 'we believe that best practice is a clinical finding'
- there's no standard way to flag codes that fail some applied terminology criteria (typically, the applied criteria vary as the content wombles through the clinical eco-system). There is always extensions, of course
Grahame Grieve (Jan 29 2018 at 22:41):
generally, we say: send all the codes your have (always preserve everything) and when consuming content, use any codes you can.
Grahame Grieve (Jan 29 2018 at 22:42):
as far as I can tell, either you can use a code, or you can't. Whether there's some set of rules that the code is or isn't valid against has no relationship to whether you know how to use it or not
Robert McClure (Jan 31 2018 at 21:04):
Basically this is the age-old question of how to operationalize V3 CWE, or CDA SHOULD, or FHIR Extensible bindings. Graham has provided the pragmatic response that has a lot of "do the best you can" in it plus the possibility of implementing receiver warnings based on these "best practice bindings" that I need to understand. @Grahame Grieve where is this documented? Our Binding Semantics project is still trying to clarify how these "extensional" bindings can be conformance tested and what they allow implementers to do. Many would say that it is simply guidance for a future explicit (think required) value set, but I'm pretty sure implementers want the loosey-goosey function of this. We are working on this here: http://confluence.hl7.org:8090/display/VOC/Vocabulary+Binding+Semantics+%28VBS%29+Project
Grahame Grieve (Jan 31 2018 at 21:47):
I think the best documentation (other than that buried in vocab minutes) is here:
Grahame Grieve (Jan 31 2018 at 21:50):
http://wiki.hl7.org/index.php?title=FHIR_Guide_to_Designing_Resources
Grahame Grieve (Jan 31 2018 at 21:50):
though that doesn't have anything to do about best practice, which probably really hasn't landed anywhere yet
Last updated: Apr 12 2022 at 19:14 UTC
