This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Act.code and Observation.value"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "<div class="subSubSubSection"> <div class="header"> 2.2.2 </div> <div class="body"> The Act.code represents a refinement of the Act.classCode and expresses the specific nat...")
 
Line 36: Line 36:
  
 
<font color="red">The ASSERTION pattern guidance appears to still be valid.  Need to check this more thoroughly.  Do we need guidance for a similar use of the ASSERTION pattern in V2?  I think we probably would, as what would be the alternative?  
 
<font color="red">The ASSERTION pattern guidance appears to still be valid.  Need to check this more thoroughly.  Do we need guidance for a similar use of the ASSERTION pattern in V2?  I think we probably would, as what would be the alternative?  
 +
 +
The ASSERTION pattern seems not to work with null flavors. For null flavors to work something meaningful needs to be in the Act.code attribute. DK
  
 
An open question that I have is whether we should treat V2 and V3 separately or combined?  I am thinking particularly of cases like Observation.code and Observation.value vs. OBX.3 and OBX.5, which seem to be very analogous.  It seems reasonable to me to include this code/value guidance once and make it applicable to both the V2 and V3 cases.  In other cases where the information model structures may differ more, that might not be true and it would be better to treat them separately. RH</font>  
 
An open question that I have is whether we should treat V2 and V3 separately or combined?  I am thinking particularly of cases like Observation.code and Observation.value vs. OBX.3 and OBX.5, which seem to be very analogous.  It seems reasonable to me to include this code/value guidance once and make it applicable to both the V2 and V3 cases.  In other cases where the information model structures may differ more, that might not be true and it would be better to treat them separately. RH</font>  

Revision as of 11:29, 25 July 2012

2.2.2

The Act.code represents a refinement of the Act.classCode and expresses the specific nature of the Act. In the case of the Observation class, the Observation.value expresses the result of the Observation specified by the Act.code.


2.2.2.1

A SNOMED CT expression can be used in the Act.code to represent the nature of the action (e.g. using concepts from the hierarchy). In cases where an observation results in a non-numeric result this can also be represented using a SNOMED CT expression. Actions involving measurement or a property or observation of a specified quality can readily be represented unambiguously using this pair of attributes.


Some kinds of observation are typically expressed in a way that either does not specify the action but merely asserts a result (or finding). In these cases the asserted result is fully specified and does not require a detailed indication of the action taken (e.g. "abdomen tender", "past history of renal colic", etc). SNOMED CT supports representation of these assertions in a single expression using concepts from the [ <<404684003 | clinical finding ] and [ 413350009 | finding with explicit context ] hierarchies. Several different ways of representing the same information thus exist using different combinations of the Act.code and Observation.value. Unconstrained use of the alternatives presents a major challenge for computation of semantic equivalence and that for safe interpretation of observations origination from different applications and users.


2.2.2.2

The following rules are intended to support validation and consistent interpretation of particular combinations of the Observation.code and Observation.value attributes where SNOMED CT is used in either or both of these attributes.

The ASSERTION pattern guidance appears to still be valid. Need to check this more thoroughly. Do we need guidance for a similar use of the ASSERTION pattern in V2? I think we probably would, as what would be the alternative?

The ASSERTION pattern seems not to work with null flavors. For null flavors to work something meaningful needs to be in the Act.code attribute. DK

An open question that I have is whether we should treat V2 and V3 separately or combined? I am thinking particularly of cases like Observation.code and Observation.value vs. OBX.3 and OBX.5, which seem to be very analogous. It seems reasonable to me to include this code/value guidance once and make it applicable to both the V2 and V3 cases. In other cases where the information model structures may differ more, that might not be true and it would be better to treat them separately. RH

  1. In a constrained information model or template that permits or requires the use of SNOMED CT to represent the nature of an Act class clone:
    • the Act.code attribute SHOULD permit the use of the Concept Descriptor (CD) data type.
      • This is required to allow inclusion of post-coordinated expressions using qualifiers where these are appropriate.
    • the Act.code attribute MAY be constrained to a data type that prohibits qualifiers, only if there is known to be no requirement for representation of meanings that might require the use of post-coordinated expressions.
  2. In a constrained information model or template that permits or requires the use of SNOMED CT to represent the result of an Observation class clone:
    • the Vocabulary Domain (or value set) specified for the Observation.code attribute SHALL permit the use of the HL7 code value "ASSERTION".
    • the Observation.value attribute SHOULD permit the use of the Concept Descriptor (CD) data type.
      • This is required to allow inclusion of post-coordinated expressions where these are appropriate.
    • the Observation.value attribute MAY be constrained to a data type that prohibits qualifiers, only if there is known to be no requirement for representation of meanings that might require the use of post-coordinated expressions.
  3. In an Act class instance where the Act.code attribute is a SNOMED CT expression
    • the expression SHOULD represent a type of [ 363787002 | observable entity ], [ <<129125009 | procedure with explicit context ] or [ <<272379006 | event ]
      • Note: [ <<272379006 | event ] concepts are included here as they may be regarded as have context similar to procedures (for example to be continuing or completed). However, this is an open issue on the SNOMED CT Concept Model, since at present no relationship between [ <<272379006 | event ] concepts and context attributes is currently specified.
  4. In an Observation class instance where the Observation.code is the HL7 code "ASSERTION" and the Observation.value is represented by a SNOMED CT expression:
    • the concept represented SHALL be a type of [ <<404684003 | clinical finding ], [ <<413350009 | finding with explicit context ] or [ <<272379006 | event ].
      • Note: [ <<272379006 | event ] concepts are included here as they may in future require representation as assertions that an event occurred or did not occur. However, this is an open issue on the SNOMED CT Concept Model, since at present no relationship between [ <<272379006 | event ] concepts and context attributes is currently specified.
  5. In an Observation class instance where the Act.code attribute is a SNOMED CT expression representing a [ <<404684003 | clinical finding ] or [ <<413350009 | finding with explicit context ], if the Observation.value is omitted, the Observation SHALL be interpreted as semantically equivalent to the same SNOMED CT expression in the Observation.value attribute with the Act.code "ASSERTION" (see point 4 above).
    • This deprecated form of representation is permitted to support backward compatibility with existing implementations.
    • For example:
      • <observation><code code=[ 195967001 | asthma ]/>...</observation>
      • is treated as equivalent to
      • <observation><code code="ASSERTION"/><value code=[ 195967001 | asthma ]/>...</observation>
  6. An Observation class instance in which the Act.code is a SNOMED CT expression representing a [ <<404684003 | clinical finding ] or [ <<413350009 | finding with explicit context ] SHALL NOT contain an Observation.value attribute.
    • If a value attribute is applied to a [ <<404684003 | clinical finding ] there are multiple possible interpretations of what that value means. For example, the possible meanings of a value applied to a clinical finding such as [ 195967001 | asthma ], [ 195114002 | acute left ventricular failure ] or [ 254838004 | carcinoma of breast ] might include severity, stage, duration, certainty, presence or absence. Thus in this context, the meaning of the value is ambiguous and open to misinterpretation. Further more, such misinterpretation might fundamentally alter the intended meaning. The SNOMED CT Concept Model and HL7 attributes provide ways to explicitly state these nuances of meaning. Therefore use of the non-specific value attribute is not appropriate.
    • In contrast, a value applied to an [ <<363787002 | observable entity ] clearly represents the observed quantitative or qualitative value of the specified entity. Similarly a value applied to a [ <<386053000 | evaluation procedure ] clearly represents the quantitative or qualitative result of that measurement.

Should we still allow this following exception for "non-ASSERTION" codes as long as they aren't in conflict? Presumably the answer is yes, again to support backward compatibility with existing implementations, but we should probably consider it again. RH

  1. An Observation class instance in which the Observation.value is a SNOMED CT expression representing a [ <<404684003 | clinical finding ] or a [ <<413350009 | finding with explicit context ] MAY contain an Act.code other than "ASSERTION" provided that the interpretation of the Act.code together with the Observation.value does not yield a meaning that is substantially different from the meaning implied if the Act.code was "ASSERTION". Observations of this type SHOULD be interpreted as having a meaning that is equivalent to the meaning of the same
    • This deprecated form of representation is permitted to support backward compatibility with existing implementations.
    • For example:
      • <observation><code code=[Abdominal examination]/><value code=[Abdomen tender]/>...</observation>
      • does not differ significantly from the asserted observation ...
      • <observation><code code="ASSERTION"/><value code=[Abdomen tender]/>...</observation>
    • In addition, the same Observation class instance can separately be interpreted to determine that an "abdominal examination" was carried out.
      • In the preferred representation this information would be expressed in a separate Act class instance because it relates to a general examination procedure which may have resulted in several distinct assertions.
  2. An Observation class instance in which the Observation.value is a SNOMED CT expression representing a [ <<404684003 | clinical finding ] or a [ <<413350009 | finding with explicit context ] SHALL NOT contain an Act.code which when interpreted with the Observation.value yields a meaning that is substantially different from the meaning implied if the Act.code was "ASSERTION".
    • For example, an Act.code meaning "Past history" or "Family history" may substantially alter the interpretation of a [ <<404684003 | clinical finding ] and should not be used in this way. Instead the SNOMED CT context model should be used to capture these significant differences in meaning.
2.2.2.3

The approach to the use of Act.code in most Act class specializations is fairly straight forward. The exception to this is the Observation class where in some cases the way that the Observation.code and Observation.value attributes are populated and interpreted has led to extensive discussions which are summarized below.


A clinical record consists of statements related directly or indirectly to the health of a patient. Some statements relate to actions taken or requested as part of the provision of care. These actions may include procedures, investigations, referrals, encounters, supply and administration of medication. In the case of these statements, SNOMED CT expressions representing [ <<71388002 | procedure ] concepts provide appropriate content for the Act.code attribute of the relevant Act class specialization. Other statements in a clinical record relate to information found or derived in a variety of ways during the delivery of care. For the purpose, these statements can be referred to as “statements about clinical findings”. The way in which “statements about clinical findings” are represented has been a source of considerable discussion within HL7. This discussion focuses on the way in which the coded representation of such statements is expressed in the Observation.code” and Observation.value” attributes of the Observation class.


Statements about clinical findings can be divided into two categories.


A) Statements about findings in which two facets are clearly distinct


  • (1) The action taken to make the finding (and/or the property about which the property was observed)
  • (2) The result of the observation

Examples:


  • Measurement of serum hemoglobin (1) = 14 g/dl (2)
    • This example follows the formal RIM semantics.
  • Body weight (1) = 75 Kg (2)
    • This example is not in line with strict interpretation of the formal RIM definition in which the Observation.code is the action taken to make the observation. However, it is a more familiar form in real-world clinical statements about many observations. A possible bridge between these two views is to regard the name of the property observed (e.g. [ 27113001 | body weight ]) as implying the action to measure or observe that property (e.g. [ 39857003 | weighing patient ]).

B) Statements about findings that are often captured as a single “nominalized” expression


  • The term "nominalized" is used to indicate a statement reduced to a single name (or term) which can then be coded as a single expression.
  • The fact that a statement is often nominalized does not mean it consists of a single atomic item of information. Many such statements can be readily divided into several identifiable facets. However, unlike statements of type A, there are different views on how the semantics of the facets of these statements might be divided between the “code” and/or “value” attributes of the observation class.

Examples: The following examples are statements that might appear in clinical records. In each case they assert a finding in relation to the “record target”. Each of these examples illustrates a particular aspect of the potential for nominalizing a statement.


Record target …


  • has a fracture of her left femur
  • is complaining of pain in his right knee for the last two days
  • reports that she had a heart attack in January 2001
  • may have pernicious anemia
  • has an aortic ejection murmur
  • has normal visual acuity

Type (A) statements can be readily represented using the Observation class as documented in the RIM. However, a variety of options have been considered for type (B) "nominalized" statements. These options vary in the use they make of the Observation.code and Observation.value attributes.

We may not need to include this historical information any longer? RH

In summary the options considered includedA joint meeting of the HL7 Modeling and Methodology and Vocabulary Technical Committees was asked to rule on the validity of these options. The discussions of these committees led to a decision to clarify the RIM definition of the Observation class. The clarification made clear that both Observation.code and Observation.value should be present and should be interpreted together rather than independently.


  • Using only one of the attributes to represent the nominalized meaning of the statement and omitting the other attribute.
  • Applying a fixed value to one of the attributes and using the other one to represent the nominalized meaning of the statement.
  • Using the value to represent the nominalized meaning of the statement while allowing the other code to operate independently to track the question or process without affecting the meaning of the result to the observation.
  • Creating a separate class for nominalized statement rather than using the Observation class.

As a result the preferred option is for a fixed Observation.code value "ASSERTION" to be used and for the meaning of the nominalized statement to be conveyed in the Observation.value. All other options are deprecated but some of these are permitted for backward compatibility.


The options permitted for backward compatibility are those that are known to be in use and these are supported as far as possible with transformation rules to allow the preferred form to be derived for comparison. There is a practical limitation to the transformation rules where code and value are used independently because it may not be possible to confirm computationally whether the code was intended to significantly modify the meaning of the value.