This is an issue which has emerged in the COVID-19 work but is familiar to me from UK GP systems.
In theory the inferencing and relationships in SNOMED-CT should allow us to use any synonym in place of the defining concept.
e.g in the current COVID symptoms
‘Sore throat’ is actually a synonym 2164213014 for the fully-specified name162397003 | Pain in throat (finding) | is the
as it should be possible for the underlying system to query for 162397003… and get any of the codes which are synonyms of … 162397003.
However in practice, this has been difficult for systems to engineer for fast querying responses so that current practice in UK is to carry any synonym codes alongside the defining concept code (in out world as a mapping) with th
See the FHIR UK Condition Care-connect profile for an example.
Perhaps this is just a historical artefact that more modern systems can handle easily? Or is it just good practivce that we should follow - and if we do decide to carry both, how dod we organise the values, because actually
the value I would argue clinically should be what I want me, colleagues and patients to see - ‘difficulty breathing’
but arguably the definig_code/code_string should actually be the concept_code.
Either way open to interpretation and we need to agree an approach, as it will be critical in querying. Arguably the FHIR codeableConcept make this a little easier (if a little less precise) since the list of mappings is flatter.
2 Likes
Ideally, the concept code should be used to record the symptom.
As SNOMED CT does, there should be a Description table holding those concept -synonym relationships for this purpose.
In addition, maybe it’s a NLP question if symptoms are described only by free text.
As SNOMED CT does, there should be a Description table holding those concept -synonym relationships for this purpose.
This is the issue. We currently have the ability to carry mutliple mappings against a particular defining_code (and text value).
The question is where should the concept code and text value go as opposed to a description code and text value.
The defining_code is intended to capture the meaning intended by the clinician and the related text-value, the text selected by the clinician, but in SNOMED-powered systems these may not be the same thing.
So a clinician selects ‘Breathlessness’ as a descriptionID which is a synonym of the FSN267036007 | Dyspnea (finding) |
What should we record as the text-value - ‘Breathlessness’ or ‘Dyspnea (finding)’ or ‘Dyspnea`’ or are any synonyms acceptable - in which case, if we add a SNOMED-CT term as a default value in a template, we really need ot realz the rule that a text_value must be identical to the the default text value, since this makes internationalisation impossible.
The alternative (as suggested in the UK) is that the defining_code carries the conceptId along with the FSN, and if a descriptionID was used to enter the data , this is carried as a mapping.
My view is that we should not enforce validation on the text-values associated with a defining_code - let this be the record of what was actually seen on the screen (or predefined in the application).
Indeed, clinicians’ selection of the textual representations should be respected and faithfully kept with the data instance. And it should be reasonable to mandate the concept code (if available) rather than the description ID.
[Supp.] The role of such a support seems like HL7 CDA/FHIR’s Narrative
Resource instances that permit narrative SHOULD always contain narrative to support human-consumption as a fallback.
http://build.fhir.org/narrative.html#Narrative
And more specifically, it’s more like the element ‘text’ within the FHIR’s Datatype CodeableConcept .
http://build.fhir.org/datatypes-definitions.html#CodeableConcept.text
However, we don’t have to encoding the concept (i.e., assigning the ) concept code manually if any feasible AI means could be used for this.
But do we need to record the descriptionID (if that was originally chosen).
Agree the mode of data-entry (AI vs. manual vs. preset) does not really matter.
The argument in the UK for carrying the descriptionID (as a mapping) as well as the conceptID, is to potentially spot mapping errors, particularly as the UK GP systems were transitioning from READ codes to SNOMED.
Do our models of openEHR Archetypes and/or Templates have any attributes to support something like such description IDs?