Relevant Confluence pages
Resource – concept model mapping
Yellow rows denote SNOMED CT attributes where there is no specific FHIR counterpart.
|Resource element (CodeableConcept)||FHIR ValueSet||Binding Strength||SNOMED CT attribute||SNOMED CT range||Comments|
Is there a use case for providing SNOMED mappings as an alternative to the preferred set of 9?
Unlikely that will be able to draft a 'tidy' mapping to the exact same set of 9 categories, such that if Observation.code, .method, .bodySite and .type are all known then .category can be computed.
2019-04-16: recommend not to use this, but would be allowed. Category can be determined from the code.
OR << 386053000|Evaluation procedure|
AP: What happens to the findings like 'pulmonary oedema' from the findings hierarchy? Is that only a Condition, or can it also be an Observation? Many clinical condition labels are synonyms for the primary clinical symptom or observation that they cause. And many genuine symptoms are certainly observations (that a phenomenon exists), not pathologies
DK: Findings are not the "question" component of the question-answer model - they're a conflation of both question AND answer
AP: But where the conflated answer is typically always "is present"
DK thought binding was overly constrained 28May.
LB: why not also members from <<441742003 Evaluation finding
JC: Because they decompose (in theory) into an Observable+Qualifier pair
|2019-04-16: seems to be out of scope of SNOMED CT|
HL7 valueset (n=48) is extensible, so could add new expressivity as SNOMED codes if there were any gaps in existing list ... but that existing list is already relatively matured and 'metalled' by use, so that seem an unlikely requirement. Many of the existing members of the HL7 valuelist have obvious SNOMED equivalents, so there is scope for a mapping rather than a completely separate SNOMED-only valuelist. Mapping exercise may also reveal some holes in existing SNOMED expressivity.
2019-04-16: gaps could be filled with new SNOMED CT content, e.g. _ObservationInterpretationNormality
2019-06-11: filling Significant low/high,
Similar to Condition.bodySite, use values from << 442083009 (Anatomical or acquired body structure) unless the body site can be determined from Observation.code eg 433776001 |Temperature of toe (observable entity)| uses Inheres In → Toe Structure. Historical issue with difficulty representing multiple body sites (eg primary and secondary tumor sites). Note that Condition resource allows 0..* bodysites.
2019-06-11: Overlaps with | direct site | of the Observables concept model.
Daniel Karlsson can you suggest an observable that uses two body sites?
HL7 "Only used if not implicit in code for Observation.code"
Note that Observables model currently using Technique (attribute) taking a technique qualifier. Actions are used as the value for a method in a procedure so is less appropriate here. JR suggested that this field should be restricted to < 272394005 (Technique) to address use case of concerns of a Pathology department.
Could a patient evaluation procedure be decorated with a technique? Currently only used with observables.
TODO - Link to Observables concept model
How would we link resources together so that the Observation could reference the actual procedure undertaken to make the determination? Likely via the "basedOn" linked to the ServiceRequest.
Similar problem to bodysite with conflict if Technique is used and does not align with Observation.code
|Observation.referenceRange.appliesTo||Observation Reference Range Applies To Codes (Example)|
|Observation.component.code||LOINC Codes (Example)|
|Observation.component.interpretation||Observation Interpretation Codes (Extensible)|