Observation.category

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.

Observation.code

https://www.hl7.org/fhir/valueset-observation-codes.html#expansion

<<363787002|Observable entity|

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"

UNRESOLVED....revisit

Observation.Value.valueCodeableConcept

<<362981000|Qualifier value|

MINUS <valueset for Observation.Interpretation> ?

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

Observation.dataAbsentReason

DataAbsentReason (Extensible)

2019-04-16: seems to be out of scope of SNOMED CT

Observation.interpretation

Observation Interpretation Codes (Extensible)

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,

Observation.bodySite

SNOMED CT Body Structures (Example)

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?

Observation.method

Observation Methods (Example)

Current HL7 list specifies: < 272394005 (Technique) OR < 129264002 (Action) OR < 386053000 (Patient evaluation procedure)

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.type

Observation Reference Range Meaning Codes (Preferred)

The value set is maturity=0 and binding strength is Preferred, so alternatively we can develop our own SNOMED CT value set from scratch.

However, the added value of using SNOMED CT here is... limited.

Observation.referenceRange.appliesTo

Observation Reference Range Applies To Codes (Example)

<<415229000|Racial group (racial group)| OR <<248153007|Male| OR <<248152002|Female| OR <<77386006|Pregnant|

Likely, missing race/ethnicity codes will not be added to SNOMED CT

Observation.component.code

LOINC Codes (Example)

See above.

Observation.component.value[x].valueCodeableConcept

Observation.component.dataAbsentReason

DataAbsentReason (Extensible)

Observation.component.interpretation

Observation Interpretation Codes (Extensible)