This wiki has undergone a migration to Confluence found Here

Observation code and value (in event mood)

From HL7Wiki
Jump to navigation Jump to search
3.1.2

A recurring issue for many observation events, regardless of the particular pattern, is determining how to populate observation.code and observation.value. While this is typically straight-forward for laboratory observations, it can get blurry for other types of observations, such as findings and disorders, family history observations, etc.


The intent of this section is to illustrate the acceptable patterns. Subsequent sections do not include all possible permutations of code/value split, and it should be assumed that any of the acceptable patterns described here would be equally applicable.


An HL7 Observation in event mood is analogous to a SNOMED CT [ 404684003 | Clinical Finding ], and an HL7 Observation in event mood with explicit context (such as presence or absence, subject, past or present) is analogous to a SNOMED CT [ 413350009 | Finding with explicit context ]. Noting this, and drawing from section "Codes and Values" above, come the following guiding principles for populating observation.code and observation.value:


  • An implementer shall be able to use SNOMED CT alone, regardless of the approach taken to populate observation.code and observation.value.
  • Acceptable patterns shall be fully transformable amongst each other (by a machine, with no loss of semantics).
  • Acceptable patterns shall not conflict with SNOMED CT's definitions, where only certain hierarchies (e.g. [ 363787002 | Observable entity ], [ 386053000 | Evaluation procedure ]) are defined as being able to take on values (i.e. have an associated observation.value).
  • Acceptable patterns shall not conflict with the RIM, which defines the Act class as "a record of something that is being done, has been done, can be done, or is intended or requested to be done", and defines the Act.code attribute as "a code specifying the particular kind of Act that the Act-instance represents within its class".
3.1.2.1

Based on these guiding principles come the following acceptable patterns:


PATTERN ONE: Observation.code [ (<<363787002 | Observable entity) OR (<<386053000 | Evaluation procedure) ] ; Observation.value = not null (e.g. numeric, nominal, ordinal, coded result).


NOTE: At the time of this writing, the SNOMED Standards Development Organization is debating whether or not Observable entity concepts should be recommended for use in Observation.code.


3.1.2.1.1
<observation classCode="OBS" moodCode="EVN">
  <code code="50373000|Height|" codeSystem="2.16.840.1.113883.6.96">
    <displayName value="Height"/>
  </code>
  <text>Height: 177 cm</text>
  <value xsi:type="PQ" value="1.77" unit="m"/>
</observation>

<observation classCode="OBS" moodCode="EVN">
  <code code="247030006|Eye color|" codeSystem="2.16.840.1.113883.6.96">
    <displayName value="Eye color"/>
  </code>
  <text>Green eyes</text>
  <value xsi:type="CD" code="371246006|Green|" codeSystem="2.16.840.1.113883.6.96">
    <displayName value="Green"/>
  </value>
</observation>	

"2.16.840.1.113883.6.96" is the code system designation for SNOMED CT.


PATTERN TWO: Observation.code = "ASSERTION" (codeSystem="2.16.840.1.113883.5.4"); Observation.value [ (<<413350009 | Finding with explicit context) OR (<<404684003 | Clinical finding) ] .


3.1.2.1.2
<observation classCode="OBS" moodCode="EVN">
  <code code="ASSERTION" 
    codeSystem="2.16.840.1.113883.5.4"/>
  <text>Headache</text>
  <value xsi:type="CD" code="25064002|Headache|" codeSystem="2.16.840.1.113883.6.96">
    <displayName value="Headache"/>
  </value>
</observation>	

In this example, the observation is simply the assertion of a "headache". If there is a need to distinguish between, say, a patient-reported symptom vs. a clinician-asserted diagnosis, more information would need to be present. Thus, while an acceptable pattern is to assert a clinical finding, that may not convey sufficient context for all communication use cases. Likewise, an assertion of a procedure.code (such as for an appendectomy performed 5 years ago) doesn't distinguish between a patient's reported past surgical history vs. information gleaned from chart review, and additional contextual information will be needed in some cases.


3.1.2.1.3
<observation classCode="OBS" moodCode="EVN">
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <text>Presence of headache</text>
  <value xsi:type="CD" code="373573001|Clinical finding present|:246090004|Associated finding|=25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"/>
</observation>	

In this example, a finding with explicit context is used to assert the presence of a headache.