View source for Using SNOMED CT in HL7 Version 3; Implementation Guide, Release 1.5

= Using SNOMED CT in HL7 Version 3; Implementation Guide, Release 1.5 =
       
{| border="1"
|-
|[[Image:hl7_idle_logo.gif|Not Balloting this Cycle]]<br>
HL7 V3 TERMINFO<br>
HL7 Version 3 Implementation Guide: Using SNOMED CT, Release 1<br>
Last Ballot: DSTU Ballot 4 - May 2009
                  
|}                                                                            
{| border="1"
|-
|Responsible Group
|Vocabulary Work Group<br>
HL7
                  
|-
|Project Leader &amp; Principal Contributor
|Edward Cheetham<br>
NHS Connecting for Health
                  
|-
|Principal Contributor
|Robert H. Dolin, MD<br>
Kaiser Permanente
                  
|-
|Principal Contributor &amp; Editor
|David Markwell, MB BS<br>
The Clinical Information Consultancy Ltd
                  
|-
|Contributor
|Jane Curry<br>
Health Information Strategies
                  
|-
|Contributor
|Davera Gabriel, RN<br>
University of California, Davis Health System
                  
|-
|Contributor
|Robert Hausam<br>
TheraDoc
                  
|-
|Contributor
|Beverly Knight<br>
Canada Health Infoway
                  
|-
|Contributor
|Alan Rector<br>
Manchester University
                  
|-
|Contributor
|Kent Spackman<br>
Oregon Health Sciences University
                  
|-
|Contributor
|Ian Townend<br>
NHS Connecting for Health
                  
|-
|Vocabulary Co-Chair
|Chris Chute<br>
Mayo Clinic/Foundation
                  
|-
|Vocabulary Co-Chair
|Russ Hamm<br>
Apelon
                  
|-
|Vocabulary Co-Chair
|Stanley Huff, MD<br>
Intermountain Health Care
                  
|-
|Vocabulary Co-Chair
|Ted Klein<br>
Klein Consulting, Inc.
                  
|-
|Vocabulary Co-Chair
|Cecil Lynch<br>
OntoReason, LLC
                  
|-
|Former TermInfo Project Leader
|Sarah Ryan<br>
HL7
                  
|-
|Former Project Leader
|Ralph Krog<br>
NASA/NSBRI
                  
|} 
HTML Generated: 2011-12-04T17:57:44

 
HL7® Version 3 Standard, &copy; 2009 Health Level Seven® International All Rights Reserved.

 
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat &amp; TM Off.<br>
Use of these materials is governed by HL7 International's [[IP Compliance Policy]].

 
----
 
<div  class="toc">       
{| border="1"
|-
|[[View Revision Marks]][[Hide Revision Marks]]
|}<br>
</div> 
== Table of Contents ==
<br>
[[Preface]]<br>
1 [[Introduction and Scope]]<br>    1.1 [[Purpose of the guide]]<br>    1.2 [[Overview]]<br>    1.3 [[Future Work]]<br>    1.4 [[Scope]]<br>    1.5 [[How to read this document]]<br>    1.6 [[Documentation conventions]]<br>    1.7 [[Background]]<br>        1.7.1 [[Semantic interoperability of clinical information]]<br>        1.7.2 [[Reference Information Model]]<br>        1.7.3 [[Clinical Statements]]<br>        1.7.4 [[Coding and Terminologies]]<br>        1.7.5 [[SNOMED CT]]<br>            1.7.5.1 [[Logical concept definitions]]<br>                1.7.5.1.1 [[SNOMED CT definition of 'fracture of femur']]<br>            1.7.5.2 [[Formal rules for post-coordinated expressions]]<br>                1.7.5.2.1 [[Expression representing 'Compression fracture of neck of femur' in SNOMED CT compositional grammar]]<br>                1.7.5.2.2 [[Expression representing 'Compression fracture of neck of femur' in CD datatype]]<br>            1.7.5.3 [[A logical model for representation of semantic context]]<br>            1.7.5.4 [[Rules for transformation and comparison of alternative representations]]<br>            1.7.5.5 [[Consequences of SNOMED CT expressivity]]<br>        1.7.6 [[Guidance]]<br>    1.8 [[Requirements and Criteria]]<br>    1.9 [[Asserting Conformance to this Implementation Guide]]<br>        1.9.1 [[Use of the templateId element to assert conformance to this guide]]<br>
2 [[Guidance on Overlaps between RIM and SNOMED CT Semantics]]<br>    2.1 [[Introduction]]<br>    2.2 [[Attributes]]<br>        2.2.1 [[Act.classCode]]<br>            2.2.1.1 [[Potential Overlap]]<br>            2.2.1.2 [[Rules and Guidance]]<br>            2.2.1.3 [[Discussion and Rationale]]<br>        2.2.2 [[Act.code and Observation.value]]<br>            2.2.2.1 [[Potential Overlap]]<br>            2.2.2.2 [[Rules and Guidance]]<br>            2.2.2.3 [[Discussion and Rationale]]<br>        2.2.3 [[Act.moodCode]]<br>            2.2.3.1 [[Potential Overlap]]<br>            2.2.3.2 [[Rules and Guidance]]<br>            2.2.3.3 [[Discussion and Rationale]]<br>        2.2.4 [[Act.statusCode]]<br>            2.2.4.1 [[Potential Overlap]]<br>            2.2.4.2 [[Rules and Guidance]]<br>            2.2.4.3 [[Discussion and Rationale]]<br>        2.2.5 [[Procedure.targetSiteCode and Observation.targetSiteCode]]<br>            2.2.5.1 [[Potential Overlap]]<br>            2.2.5.2 [[Rules and Guidance]]<br>            2.2.5.3 [[Discussion and Rationale]]<br>        2.2.6 [[Procedure.approachSiteCode and SubstanceAdministration.approachSiteCode]]<br>            2.2.6.1 [[Potential Overlap]]<br>            2.2.6.2 [[Rules and Guidance]]<br>            2.2.6.3 [[Discussion and Rationale]]<br>        2.2.7 [[Procedure.methodCode and Observation.methodCode]]<br>            2.2.7.1 [[Potential Overlap]]<br>            2.2.7.2 [[Rules and Guidance]]<br>            2.2.7.3 [[Discussion and Rationale]]<br>        2.2.8 [[Act.priorityCode]]<br>            2.2.8.1 [[Potential Overlap]]<br>            2.2.8.2 [[Rules and Guidance]]<br>            2.2.8.3 [[Discussion and Rationale]]<br>        2.2.9 [[Act.negationInd]]<br>            2.2.9.1 [[Potential Overlap]]<br>            2.2.9.2 [[Rules and Guidance]]<br>            2.2.9.3 [[Discussion and Rationale]]<br>        2.2.10 [[Act.uncertaintyCode]]<br>            2.2.10.1 [[Potential Overlap]]<br>            2.2.10.2 [[Rules and Guidance]]<br>            2.2.10.3 [[Discussion and Rationale]]<br>        2.2.11 [[Observation.interpretationCode]]<br>            2.2.11.1 [[Potential Overlap]]<br>            2.2.11.2 [[Rules and Guidance]]<br>            2.2.11.3 [[Discussion and Rationale]]<br>        2.2.12 [[Representation of Units]]<br>            2.2.12.1 [[Potential Overlap]]<br>            2.2.12.2 [[Rules and Guidance]]<br>            2.2.12.3 [[Discussion and Rationale]]<br>        2.2.13 [[Dates and Times]]<br>            2.2.13.1 [[Potential Overlap]]<br>            2.2.13.2 [[Rules and Guidance]]<br>            2.2.13.3 [[Discussion and Rationale]]<br>    2.3 [[ActRelationships]]<br>        2.3.1 [[Observation Qualification Using ActRelationships]]<br>            2.3.1.1 [[Potential Overlap]]<br>            2.3.1.2 [[Rules and Guidance]]<br>            2.3.1.3 [[Discussion and Rationale]]<br>        2.3.2 [[Representing Compound Statements and Relationships between Statements]]<br>            2.3.2.1 [[Potential Overlap]]<br>            2.3.2.2 [[Rules and Guidance]]<br>            2.3.2.3 [[Discussion and Rationale]]<br>    2.4 [[Participations]]<br>        2.4.1 [[Subject Participation and Subject Relationship Context]]<br>            2.4.1.1 [[Potential Overlap]]<br>            2.4.1.2 [[Rules and Guidance]]<br>            2.4.1.3 [[Discussion and Rationale]]<br>        2.4.2 [[Specimen Participation in Observations]]<br>            2.4.2.1 [[Potential Overlap]]<br>            2.4.2.2 [[Rules and Guidance]]<br>            2.4.2.3 [[Discussion and Rationale]]<br>        2.4.3 [[Product and Consumable Participations in Supply and SubstanceAdministration]]<br>            2.4.3.1 [[Potential Overlap]]<br>            2.4.3.2 [[Rules and Guidance]]<br>            2.4.3.3 [[Discussion and Rationale]]<br>    2.5 [[Context Conduction]]<br>        2.5.1 [[Structures which propagate context in HL7 models]]<br>            2.5.1.1 [[Potential Overlap]]<br>            2.5.1.2 [[Rules and Guidance]]<br>            2.5.1.3 [[Discussion and Rationale]]<br>
3 [[Common Patterns]]<br>    3.1 [[Introduction]]<br>        3.1.1 [[Observations vs. Organizers]]<br>        3.1.2 [[Observation code and value (in event mood)]]<br>            3.1.2.1 [[Acceptable patterns for Observation code/value]]<br>                3.1.2.1.1 [[Observation code/value: observable entity with result]]<br>                3.1.2.1.2 [[Observation code/value: assertion of a clinical finding]]<br>                3.1.2.1.3 [[Observation code/value: assertion of a clinical finding with explicit context]]<br>        3.1.3 [[Source of information]]<br>            3.1.3.1 [[Acceptable patterns for source of information]]<br>                3.1.3.1.1 [[Current observation is directly referenced from something previously recorded.]]<br>                3.1.3.1.2 [[Informant is the father]]<br>                3.1.3.1.3 [[Source is patient-reported symptom]]<br>                3.1.3.1.4 [[Source is direct examination of patient]]<br>                3.1.3.1.5 [[Source is direct examination of radiograph]]<br>    3.2 [[Allergies and Adverse Reactions]]<br>        3.2.1 [[Allergies coded with Substance/Product value set]]<br>        3.2.2 [[Allergies coded with Findings value set]]<br>    3.3 [[Assessment Scale Results]]<br>        3.3.1 [[Glasgow Coma Score assessment scale result pattern]]<br>    3.4 [[Observation, Condition, Diagnosis, Concern]]<br>        3.4.1 [[Assertion of a clinical finding]]<br>        3.4.2 [[Context-dependent (administrative) assertion of a diagnosis]]<br>        3.4.3 [[Example of a problem list containing concerns]]<br>    3.5 [[Family History]]<br>        3.5.1 [[Family history, with explicit Subject Relationship Context]]<br>        3.5.2 [[Family history, without explicit Subject Relationship Context]]<br>    3.6 [[Medications and Immunizations]]<br>        3.6.1 [[Pharmacy: Atenolol 50mg tablet, take 1 per day.]]<br>        3.6.2 [[Informant: Atenolol 50mg tablet, taking 1/2 per day.]]<br>
4 [[Normal Forms]]<br>    4.1 [[SNOMED CT Normal Forms]]<br>    4.2 [[Transformations to Normal Forms]]<br>
5 [[SNOMED CT vocabulary domain constraints]]<br>    5.1 [[Introduction]]<br>    5.2 [[Approach to Value Set Constraint Specifications]]<br>        5.2.1 [[How the Value Sets are Presented]]<br>        5.2.2 [[Why these Value Set Constraints are Useful]]<br>            5.2.2.1 [[General Partitioning of SNOMED CT]]<br>            5.2.2.2 [[Starting Point for SNOMED CT Model-based Value Set Specifications]]<br>        5.2.3 [[Why the Value Set Constraints are Incomplete]]<br>            5.2.3.1 [[False Negatives - Rejection of Valid Expressions]]<br>            5.2.3.2 [[False Positives - Acceptance of Invalid Expressions]]<br>    5.3 [[Constraint Specifications]]<br>        5.3.1 [[Specifications]]<br>            5.3.1.1 [[Observation]]<br>            5.3.1.2 [[Procedure]]<br>            5.3.1.3 [[Substance Administration]]<br>            5.3.1.4 [[Supply]]<br>            5.3.1.5 [[Organizer]]<br>            5.3.1.6 [[Entity]]<br>        5.3.2 [[Notes]]<br>            5.3.2.1 [[moodCode influences]]<br>            5.3.2.2 [[Translations]]<br>            5.3.2.3 [[Inactive SNOMED CT concepts]]<br>
[[Endnotes]]<br>
<div  class="body"> 
<div  class="subSection"> 
<div  class="header"> 
=== Preface ===
 
</div> 
</div> 
----
 
<div  class="subSection"> 
<div  class="header"> 1
</div> 
<div  class="body"> 
<div  class="subSubSection"> 
<div  class="header"> 1.1
</div> 
<div  class="body"> 
The purpose of this guide is to ensure that HL7 Version 3 standards achieve their stated goal of semantic interoperability
when used to communicate clinical information that is represented using concepts from SNOMED Clinical Terms® [[[1]]](SNOMED CT).

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.2
</div> 
<div  class="body"> 
The guide has been developed by the HL7 TermInfo Project (a project of the HL7 Vocabulary <font color="red">Work Group</font>). The guide
is the result of a consensus process involving a wide range of interested parties.

 
* The HL7 Clinical Statement Project and the various Technical Committees contributing to that project.
* The SNOMED International Standards Board and Concept Model Working Group.
* Vendors and providers actively implementing HL7 Version 3 with SNOMED CT.
* NHS Connecting for Health in the United Kingdom.
* Other organizations and including Members of the International Healthcare Terminology Standards Development Organisation (IHTSDO)                               which took over ownership of SNOMED Clinical Terms in April 2007.
 
The guide takes account of:

 
* The SNOMED CT Concept Model including those elements concerned with the representation of context.
* The structure and semantics of the HL7 Reference Information Model (RIM).
 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.3
</div> 
<div  class="body"> 
At the January 2009 TermInfo meeting, future work for the committee was considered. The primary candidate for future work
is an implementation guide addressing the use of SNOMED CT and LOINC. This work would address the use of both Clinical and
Lab LOINC and SNOMED CT within HL7 V3 and CDA artifacts.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.4
</div> 
<div  class="body"> 
The primary scope of this implementation guide is to provide guidance for the use of SNOMED CT in the HL7 V3 Clinical Statement
pattern. The intent is to guide implementers in the construction of instances based on models derived from that pattern. These
include models covering the representation of clinical information from the perspective of various HL7 domains including Structured
Documents (CDA release 2), Patient Care, Orders and Observations and models using the Clinical Statement CMET [[[2]]]

 
The guidance in this document should also be applied to the use of SNOMED CT in other HL7 V3 models that share features with
the Clinical Statement model, unless domain specific requirements prevent this.

 
While other code systems (such as LOINC or ICD9) may be required or even preferable in some situations, these situations are
outside the scope of this guide. Where a particular constraint profile requires the use of other code systems, that profile
should complement and not contradict recommendations stated here.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.5
</div> 
<div  class="body"> 
Following this introduction (Section 1), the implementation guide 'Using SNOMED CT in HL7 Version 3' contains both normative
and informative sections.

 
Section 2 (normative) provides detailed guidance on dealing with specific overlaps between RIM and SNOMED CT semantics. It
contains normative recommendations for use of SNOMED CT in relevant attributes of various RIM classes including Acts, ActRelationships
and Participations. It also contains a subsection providing recommendations on Context conduction. Each subsection in consists
of:

 
* A brief introduction to the item;
* An explanation of the potential overlap;
* A statement of rules and guidance on usage;
* A supporting discussion and rationale.
 
Section 3 (informative) provides a set of examples and patterns for representing common clinical statements. The approaches
taken are consistent with the normative statements in Sections 2 and 5, as well as work being done within HL7 domain committees.

 
Section 4 (informative) describes normal forms, including their use with SNOMED CT. It also discusses considerations for transformations
between various common representations and SNOMED CT or HL7 RIM based normal forms.

 
Section 5 (normative) contains a number of constraints on SNOMED CT Concepts applicable to relevant attributes in each of
the major classes in the Clinical Statement pattern. These normative constraints are presented as a series of tables in section
5.3. This section also summarises the benefits and weaknesses of the constraints offered (see also Appendix E).

 
Appendix A (informative) provides a general discussion of the potential overlaps between an information model and a terminology
model and the pros and cons of various possible approaches to managing these overlaps.

 
Appendix B (reference) provides references to relevant documents including SNOMED CT specifications and also outlines the
compositional grammar used to express many of the examples in this document.

 
Appendix C (informative) notes the changes to this document since its the last ballot draft.

 
Appendix D (informative) identifies known open issues in SNOMED CT that limit the completeness and consistent application
of some of the guidance in this document.

 
Appendix E (informative) provides a more detailed discussion of approaches to normative constraints on SNOMED CT and identifies
the need for further development of formal vocabulary rules to support this.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.6
</div> 
<div  class="body"> 
In this document references to SNOMED CT concepts and expressions are represented using the SNOMED Compositional Grammar.
An extension to this grammar is used in this document to represent constraints on use of SNOMED CT concepts and expressions.
The extended grammar is explained in [[SNOMED CT Compositional Grammar - extended]], together with references to the SNOMED CT source material related to the underlying logical model.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.7
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.1
</div> 
<div  class="body"> 
One of the primary goals of HL7 Version 3 is to deliver standards that enable semantic interoperability. Semantic interoperability
is a step beyond the exchange of information between different applications that was demonstrated by earlier versions of HL7.
The additional requirement is that a receiving application should be able to retrieve and process communicated information,
in the same way that it is able to retrieve and process information that originated within that application. To meet this
requirement the meaning of the information communicated must be represented in an agreed, consistent and adequately expressive
form.

 
Clinical information is information that is entered and used primarily for clinical purposes. The clinical purposes for which
information may be used include care of the individual patient and support to population care. In both cases there are requirements
for selective retrieval of information either from within a single patient record or from the set of records pertaining to
the population being studied. Meeting these requirements depends on consistent interpretation of the meaning of stored and
communicated information. This requires an understanding of the varied and potentially complex ways in which similar information
may be represented. This complexity is apparent both in the range of clinical concepts that need to be expressed and the relationships
between instances of these concepts.

 
Delivering semantic interoperability in this field presents a challenge for traditional methods of data processing and exchange.
Addressing this challenge requires an agreed way to represent reusable clinical concepts and a way to express instances of
those concepts within a standard clinical record, document or other communication.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.2
</div> 
<div  class="body"> 
The HL7 Version 3 Reference Information Model (RIM) provides an abstract model for representing health related information.
The RIM comprises classes which include sets of attributes and which are associated with one another by relationships. Details
of the RIM can be found in the Foundation section of the HL7 Version 3 Publication (see [[RIM]]).

 
Documentation of RIM classes, attributes and relationships and the vocabulary domains specified for particular coded attributes
provide standard ways to represent particular kinds of information. The RIM specifies internal vocabularies for some structurally
essential coded attributes but also supports use of external terminologies to express more detailed information.
SNOMED CT is one of the external terminologies that may be used in HL7 communications.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.3
</div> 
<div  class="body"> 
The RIM is an abstract model and leaves many degrees of freedom with regard to representing a specific item of clinical information.
The HL7 Clinical Statement project is developing and maintaining a more refined model for representing discrete instances
of clinical information and the context within which they are recorded.

 
The HL7 Clinical Statement pattern is a refinement of the RIM, which provides a consistent structural approach to representation
of clinical information across a range of different domains. However, neither the RIM nor the Clinical Statement pattern place
any limits on the level of clinical detail that may be expressed in a structured form. At the least structured extreme, an
HL7 Clinical Document Architecture (CDA) document may express an entire encounter as text with presentational markup, without
any coded clinical information. An intermediate level of structure might be applied when communicating a clinical summary
with each diagnosis and operative procedure represented as a separate coded statement. Requirements for more comprehensive
communication of electronic health records can be met by using the Clinical Statement pattern to fully structure and encode
each individual finding and/or each step in a procedure.

 
The Clinical Statement pattern is the common foundation for the CDA Entries in HL7 Clinical Document Architecture release
2 and for the clinical information content of HL7 Care Provision messages. Details of the Clinical Statement pattern can be
found in the Common Domains section of the HL7 Version 3 Publication (see [[clinical statements]]).

 
Even within the constraints of the Clinical Statement pattern, similar clinical information can be represented in different
ways. One key variable is the nature of the code system chosen to represent the primary semantics of each statement. The other
key variable is the way in which overlaps and gaps between the expressiveness of the information model (clinical statement)
and the chosen terminology are dealt with.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.4
</div> 
<div  class="body"> 
The scope of clinical information is very broad and this, together with the need to express similar concepts at different
levels of detail (granularity), results in a requirement to support a huge number concepts and to recognize the relationships
between them.

 
Several candidate terminologies have been identified at national and international levels. HL7 does not endorse or recommend
a particular clinical terminology. However, HL7 is seeking to address the issues raised by combining particular widely-used
terminologies with HL7 standards.

 
This guide focuses on the issues posed by using SNOMED Clinical Terms® (SNOMED CT) with HL7 clinical statements. It includes
specific advice on how to specify communications that use SNOMED CT to provide the primary source of clinical meaning in each
clinical statement.

 
Although this guide is specifically concerned with SNOMED CT, it is likely that similar issues will be encountered when considering
the use of other code systems within HL7 clinical statements. Therefore some of the advice related to general approaches to
gaps and overlaps is more widely applicable.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5
</div> 
<div  class="body"> 
SNOMED CT is a clinical terminology which covers a broad scope of clinical concepts to a considerable level of detail. It
is one of the external terminologies that can and will be used in HL7 Version 3 communications. SNOMED CT has various features
that add flexibility to the range and detail of meanings that can be represented. These features summarized below are documented
in detail in documents listed in [[SNOMED CT Reference materials]].

 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.1
</div> 
<div  class="body"> 
Each SNOMED CT concept is defined by relationships to one or more other concepts. The following example illustrates the type
of logical definitions that are distributed as part of SNOMED CT.

 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.1.1
</div> 
<div  class="body">
<pre>
[ 71620000 | fracture of femur ] is fully defined as... 
   116680003 | is a | = 46866001 | fracture of lower limb | ,
   116680003 | is a | = 7523003 | injury of thigh | ,
     116676008 | associated morphology | = 72704001 | fracture | ,
     363698007 | finding site | = 71341001 | bone structure of femur |

</pre>

</div> 
</div> <blockquote> 
'''Note: '''This example and many of the other illustrations in this document are expressed using the SNOMED CT compositional grammar.
Where relevant this document also uses proposed extensions to this grammar to represent constraints on use of SNOMED CT concepts
and expressions. The extended grammar is explained in [[SNOMED CT Compositional Grammar - extended]], together with references to the SNOMED CT source material.

 </blockquote> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.2
</div> 
<div  class="body"> 
When a SNOMED CT concept is used to record an instance of information, it can be refined in accordance with the SNOMED CT
Concept Model to represent more precise meanings.

 
* For example, it might be necessary to record a "compression fracture of the neck of the femur".
** SNOMED CT does not contain a concept identifier for this specific type of fracture at this precise location. However, the                                                 post-coordination rules allow refinement of the "finding site" and "associated morphology" attributes in the definition of                                                 the concept "fracture of femur" (see above example).
** Therefore the required information can be recorded by refining the concept "fracture of femur" with the site "neck of femur"                                                 and the morphology "compression fracture".
*
 
The result of a refinement is referred to as a ''post-coordinated expression''. A post-coordinated expression conforms to an abstract logical model specified the "SNOMED CT Guide to Abstract Logical Models
and Representational Forms" (see [[SNOMED CT Reference materials]]). The same guide also specifies a compositional grammar for representing these expressions in a way that is both human-readable
and computer-processable (see also [[SNOMED CT Compositional Grammar - extended]]). The example below uses this grammar to represent a post-coordinated expression for "compression fracture of neck of femur".

 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.2.1
</div> 
<div  class="body">
<pre>
71620000|fracture of femur|:
   116676008|associated morphology|=21947006|compression fracture|
   ,363698007|finding site|=29627003|structure of neck of femur|
</pre>

</div> 
</div> 
The composition grammar illustrated above is only one of the possible representational forms for a post-coordinated expression.
These expressions can also be accommodated within the HL7 Concept Descriptor (CD) data type which may be applied to various
coded attributes in HL7 specification. For example, the SNOMED CT expression indicating a "compression fracture of neck of
femur" can be represented as shown in the following example:[[]]

 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.2.2
</div> 
<div  class="body">
<pre>
&lt;code code="71620000|fracture of femur|:116676008|associated morphology|=21947006|compression fracture|,363698007|finding site|=29627003|structure of neck of femur|" 
      codeSystem="2.16.840.1.113883.6.96"/&gt;
</pre>

</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.3
</div> 
<div  class="body"> 
SNOMED CT "clinical finding" and "procedure" concepts have assumed (default) contexts which apply if they are used in a record
without an explicit context.

 
* The default context for a [ &lt;&lt;404684003 | clinical finding ]  is that the finding is asserted to be ''present'' in the person who is the ''subject of the record'' at the ''current time'' (or at a specified time).
** E.g. When the concept [ 233604007 | pneumonia ] is used in a clinical record it is assumed to mean that ''pneumonia ''was ''found to be present'' in the ''subject of the record ''either at an explicitly ''stated ''effective time or at the ''current time'' when the statement was made.
*
* The default context for a "procedure" is that the procedure is asserted to have been ''done'' to the person who is the ''subject of the record'', at the ''current time'' (or at a specified time).
** E.g. When the concept [ 80146002 | appendectomy ] is used in a clinical record it is assumed to mean that an ''appendectomy ''was ''done ''on the ''subject of the record'' either at an explicitly ''stated ''effective time or at the ''current time'' when the statement was made.
*
 
The default context for a [ &lt;&lt;404684003 | clinical finding ] can be overridden by an explicit representation of context. Alternative
contexts include:

 
* Finding contexts such as: present, absent, unknown, goal, risk, etc.
* Subject relationship contexts such as: family member, mother, father, sibling, contact, etc.
* Temporal contexts such as: past, current, recent, etc.
 
The default context for a [ &lt;&lt;71388002 | procedure ] can be overridden by an explicit representation of context. Alternative
contexts include:

 
* Procedure contexts such as: requested, planned, in progress, done, not done, not to be done, etc.
* Subject relationship contexts: as above for findings
* Temporal contexts: as above for findings.
 
Explicit context may be represented either in a pre-coordinated form using a concept that is a subtypes of [ &lt;&lt;243796009 |
situation with explicit context ] or by using a post-coordinated expression.

 
* The following concepts provide examples of pre-coordinated concepts that include explicit context:
** [ 297243001 | family history of pernicious anemia ]
** [ 160274005 | no family history diabetes ]
** [ 399211009 | past history of myocardial infarction ]
** [ 168748001 | mammography requested ]
** [ 165017002 | lung function testing not done ]
*
* The following expressions illustrate ways in which in post-coordination can be applied to represent explicit context:
** [ 281666001 | family history of disorder | : 246090004 | associated finding | = 84027009 | pernicious anemia ]
** [ 417662000 | past history of clinical finding | :246090004 | associated finding | = 22298006 | myocardial infarction ]
** [ 413350009 | finding with explicit context | : 246090004 | associated finding | = 282144007 | able to walk | , 408729009                                                 | finding context | = 410518001 | goal ]
*
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.4
</div> 
<div  class="body"> 
SNOMED CT expressions can be compared by applying "normal form" transformations that make use of logical concept definitions.
These transformations generate the same normal form when applied to two expressions that logically have the same meaning.

 
* When the transformation rules are applied to either of the following two expressions:
** [ 297243001 | family history of pernicious anemia ]
** [ 281666001 | family history of disorder | : 246090004 | associated finding | = 84027009 | pernicious anemia ]
* the following normal form is generated
** 243796009 | situation with explicit context | :<br>  {246090004 | associated finding | = 84027009 | pernicious anemia | :<br>    ,408729009 | finding context | = 410515003 | known present | ,<br>    408731000 | temporal context | = 410512000 | current or specified | ,<br>    408732007 | subject relationship context | = 303071001 | person in the family | }
*
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.5.5
</div> 
<div  class="body"> 
The expressivity of SNOMED CT is one of its strengths. However this also leads to cases where overlaps may occur with semantics
that may also be represented by an information model such as the HL7 RIM. For example:

 
* a single SNOMED CT coded expression can represent a meaning that the HL7 RIM could also represent using a combination of several                                           coded attributes or related classes;
* HL7 RIM semantics may modify the default assumptions about the meaning of a SNOMED expression;
* HL7 RIM semantics may contradict the meaning expressed by a SNOMED CT expression.
 
There is a requirement for clear rules and guidance on these overlaps to minimize the risk that alternative representational
forms, may lead to duplication, ambiguity and erroneous interpretation.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 1.7.6
</div> 
<div  class="body"> 
The guide identifies gaps between these models and areas in which they overlap. It provides coherent guidance on how these
gaps can be bridged and the overlaps managed to meet the common goal of semantic interoperability.

 
The guide identifies options for use of SNOMED CT concepts, in both pre and post-coordinated forms in various attributes of
HL7 RIM classes. The primary focus is on the RIM class clones used in the HL7 Clinical Statement pattern. However, the general
principles of the advice are also applicable to many RIM class clones used in constrained information models that form part
of other HL7 specifications and standards.

 
In some situations, the features of HL7 Version 3 and SNOMED CT dictate a single way to utilize these two models together.
Where this is true, the guide contains a single recommended approach which is normative, based on referenced pre-existing
standards.

 
In other situations, there are several possible ways to combine HL7 and SNOMED CT to resolve a gap or overlap. In these cases,
the advantages and disadvantages of each option are evaluated. The next section explains the criteria used in this evaluation.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.8
</div> 
<div  class="body"> 
The intent of this section is to describe the requirements and criteria used to weigh various instance representations in
order to arrive at the recommendations in this specification.

 
As discussed above, there are situations where there are several possible ways to combine HL7 and SNOMED CT to resolve a gap
or overlap. In these cases, the advantages and disadvantages of each option are evaluated using the criteria stated here.
The guide recommends against approaches that have a disproportionate balance of disadvantages and are unlikely to deliver
semantic interoperability. In some cases, the guide contains advice on several alternative approaches and the recommended
approach may be based on prior implementation in accordance with criterion 4 below.

 
The following criteria have been identified to address these requirements:

 
# Understandable, Reproducible, Useful: Normative statements and recommendations in this guide:
#* Must be widely understandable by implementers who are familiar with the use of SNOMED CT and HL7 V3.
#* Must be able to be applied consistently.
#* Must cover common scenarios, but need not cover all conceivable cases of SNOMED/HL7 overlap.
#
# Transformable into a common "Model of Meaning": Normative statements and recommendations in this guide should result in instance                               representations that can be converted, by following a set of computationally tractable rules, into a single normal form (known                               as the "Model of Meaning"). [[[3]]]
#* Where this implementation guide supports multiple representations of the same meaning, they are all transformable to one another                                     and/or into a single Model of Meaning.
#* Representations that can be reused consistently in many contexts (problem list, family history, chief complaint, medical history,                                     documentation of findings, final diagnosis, etc.) are preferred to representations that are specific to a particular context.
#* Representation of data, precisely in the form in which it was captured in the application of origin (also referred to as the                                     "Model of Use"), is not recommended unless the representation is transformable into a common Model of Meaning.
#
# Practical: Tractable tooling/data manipulation requirements
#* We can confirm with tools that an instance conforms to the recommendations.
#* Existing tools and applications, either in their current form or with reasonable enhancements, can produce the recommended                                     instances.
#* Model does not require a combinatorial explosion of pre-coordinated concepts. For example, the model should not require the                                     creation of the cross product of "Allergic to" and all drugs and substances.
#
# Not superfluous: Where more than one approach appears to be viable and broadly equal in respect of the criteria above a single                               approach is recommended to avoid unnecessary divergence.
#* Where one approach has already been successfully implemented and the other has not, the implemented approach is recommended.
#* Optionality is restricted where possible to simplify the delivery of semantic interoperability.
#
 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 1.9
</div> 
<div  class="body"> 
This specification defines constraints on the use of SNOMED CT in an HL7 V3 instance. HL7 V3 provides a mechanism to reference
a template or implementation guide that has been assigned a unique identifier, by referencing the guide's identifier in the
InfrastructureRoot.templateId field. The formal identifier for this guide is ''''2.16.840.1.113883.10.5'.'''

 
The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that
the HL7 V3 instance not only conforms to the base specification, but in addition, conforms to constraints specified in this
implementation guide.

 
<div  class="subSubSubSection"> 
<div  class="header"> 1.9.1
</div> 
<div  class="body">
<pre>
&lt;V3Instance&gt;
  &lt;templateId root='2.16.840.1.113883.10.5'/&gt;
  ...
&lt;/V3Instance&gt;

</pre>

</div> 
</div> 
'''NOTE: '''The normative constraints in this guide are expressed in a technology-neutral formalism. The key words '''"SHALL"''', '''"SHALL NOT"''', '''"SHOULD"''', '''"SHOULD NOT"''', '''"MAY"''', and '''"NEED NOT"''' in this document are to be interpreted 
					as described in the [[HL7 Version 3 Publishing Facilitator's Guide]]. Various options for computable representations are under consideration and non-normative example implementations may be
provided in the future.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSection"> 
<div  class="header"> 2
</div> 
<div  class="body"> 
<div  class="subSubSection"> 
<div  class="header"> 2.1
</div> 
<div  class="body"> 
When used together SNOMED CT and HL7 often offer multiple possible approaches to representing the same clinical information.
This need not be a problem where clear rules can be specified that enable transformation between alternative forms. However,
unambiguous interpretation and thus reliable transformation depends on understanding the semantics of both the RIM and HL7
and guidelines to manage areas of overlap or apparent conflict.

                                                  
{| border="1"
|+Key to phrases used in this section
|-
!Phrase
!Meaning
!Examples
|-
|''[RimClass]'' class
                                 
| 
The HL7 Version 3 Reference Information Model class named ''[RimClass]''.

 
|"Act class" - refers to the RIM class Act as specified in the RIM.
|-
|''[RimClass]'' class specialization
                                 
| 
Any class in the RIM that is a specialization of the named ''[RimClass]''.

 
|"Act class specialization" - refers to any RIM class that is model as specialization of Act in the RIM. For example, the "Observation
                                    class".<br>
|-
|''[RimClass]'' class clone
                                 
|A class in a constrained information model (e.g. an DMIM, RMIM, HMD or template) that is derived from one of the following:
                                    
* the named ''[RimClass]''
* a ''[RimClass]'' class specialization.
 
|"Observation class clone" - refers to any design time constraint on the Observation class. <br>
This may be part of a domain model, a message design specification or template.
                                 
|-
|''[RimClass]'' class instance
                                 
|An instance of information structured in accordance with one of the following:
                                    
* the named ''[RimClass]''
* a ''[RimClass]'' class specialization
* a ''[RimClass]'' clone.
 
|"Act class instance" - refers to an instance of run time information structured in accordance with either the Act class or
                                    any specialization or constraint applied to the Act class.
                                 
|-
|''[RimClass]''.''[Attribute]''
|The named ''[Attribute]'' in any of the following:
                                    
* the named ''[RimClass]''
* a ''[RimClass]'' class specialization
* a ''[RimClass]'' clone
* a ''[RimClass] ''instance
 
|"Act.code" refers the "code" attribute of either the Act class itself or of an Act class specialization (.e.g. Observation,
                                    Procedure).<br>
In contrast, "Observation.code" refers specifically to the "code" attribute of an Observation class.
                                 
|-
|SNOMED CT expression
|One or more SNOMED CT concept identifiers used to represent meaning.
|See the examples for "Pre-coordinated expression" and "Post-coordinated expression" in the following two rows.
|-
|Pre-coordinated expression
|A SNOMED CT expression containing only one SNOMED identifier. In an HL7  attribute any of the coded data types can be used
                                    to represent a pre-coordinated expression.
                                 
| 
&lt;value code="195967001|asthma|" codeSystem="2.16.840.1.113883.6.96"/&gt;

 
|-
|Post-coordinated expression
|A SNOMED CT expression containing more than one SNOMED identifier. In an HL7 attribute the Concept Descriptor (CD) data type
                                    is used to represent a post-coordinated expression.
                                 
| 
&lt;value codeSystem="2.16.840.1.113883.6.96" code="195967001|asthma|:246112005|severity|=24484000|severe|"/&gt;

 
|} 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 2.2
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.1
</div> 
<div  class="body"> 
The Act.classCode is a structural code which specifies the general nature of the Act. Its values are drawn from the HL7 ActClass
vocabulary table.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.1.1
</div> 
<div  class="body"> 
The Act.classCode has the effect of specializing the Act class and, as a result, constrains the vocabulary domains that apply
to other coded attributes of that class. If a SNOMED CT expression is used to encode the values of one or more of these other
attributes, the meaning of the expression must be appropriate to the constrained vocabulary domain.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.1.2
</div> 
<div  class="body"> 
The vocabulary domain constraints applicable to specific SNOMED CT encoded attributes of different HL7 classes are specified
in [[SNOMED CT vocabulary domain constraints]].

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.1.3
</div> 
<div  class="body"> 
The rationale for the vocabulary domain constraints applicable to particular HL7 classes are discussed in [[SNOMED CT vocabulary domain constraints]]. This is supplemented by [[Detailed aspects of issues with a vocabulary specification formalism]], which discusses different ways in which constraints may need to be expressed to take account of the SNOMED CT terminology
model.

 
</div> 
</div> 
</div> 
</div> 
<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 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.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.2.1
</div> 
<div  class="body"> 
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 [ &lt;&lt;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.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.2.2
</div> 
<div  class="body"> 
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.

 
# 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.
#
# 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.
#
# 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 ], [ &lt;&lt;129125009 | procedure with explicit context                                                 ] or [ &lt;&lt;272379006 | event ]
#** Note: [ &lt;&lt;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 [ &lt;&lt;272379006 | event ] concepts and context attributes is currently specified.
#*
#
# 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 [ &lt;&lt;404684003 | clinical finding ], [ &lt;&lt;413350009 | finding with explicit context                                                 ] or [ &lt;&lt;272379006 | event ].
#** Note: [ &lt;&lt;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 [ &lt;&lt;272379006 | event ] concepts and context attributes is currently specified.
#*
#
# In an Observation class instance where the Act.code attribute is a SNOMED CT expression representing a [ &lt;&lt;404684003 | clinical                                           finding ] or [ &lt;&lt;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:
#** &lt;observation&gt;&lt;code code=[ 195967001 | asthma ]/&gt;...&lt;/observation&gt;
#** ''is treated as equivalent to ''
#** &lt;observation&gt;&lt;code code="ASSERTION"/&gt;&lt;value code=[ 195967001 | asthma ]/&gt;...&lt;/observation&gt;
#*
#
# An Observation class instance in which the Act.code is a SNOMED CT expression representing a [ &lt;&lt;404684003 | clinical finding                                           ] or [ &lt;&lt;413350009 | finding with explicit context ] SHALL NOT contain an Observation.value attribute.
#* If a value attribute is applied to a [ &lt;&lt;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 [ &lt;&lt;363787002 | observable entity ] clearly represents the observed quantitative or qualitative                                                 value of the specified entity. Similarly a value applied to a [ &lt;&lt;386053000 | evaluation procedure ] clearly represents the                                                 quantitative or qualitative result of that measurement.
#
# An Observation class instance in which the Observation.value is a SNOMED CT expression representing a [ &lt;&lt;404684003 | clinical                                           finding ] or a [ &lt;&lt;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:
#** &lt;observation&gt;&lt;code code=[Abdominal examination]/&gt;&lt;value code=[Abdomen tender]/&gt;...&lt;/observation&gt;
#** ''does not differ significantly from the asserted observation ...''
#** &lt;observation&gt;&lt;code code="ASSERTION"/&gt;&lt;value code=[Abdomen tender]/&gt;...&lt;/observation&gt;
#*
#* 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.
#*
#
# An Observation class instance in which the Observation.value is a SNOMED CT expression representing a [ &lt;&lt;404684003 | clinical                                           finding ] or a [ &lt;&lt;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 [ &lt;&lt;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.
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.2.3
</div> 
<div  class="body"> 
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 [
&lt;&lt;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 &#8220;statements about clinical findings&#8221;. The way in which &#8220;statements
about clinical findings&#8221; 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&#8221; and Observation.value&#8221;
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 &#8220;nominalized&#8221; 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 &#8220;code&#8221; and/or &#8220;value&#8221; 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 &#8220;record target&#8221;. Each of these examples illustrates a particular aspect of the potential for nominalizing
a statement.

 
''Record target &#8230;''

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

 
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.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.3
</div> 
<div  class="body"> 
The Act.moodCode is a structural code which is defined as "a code distinguishing whether an Act is conceived of as a factual
statement or in some other manner as a command, possibility, goal, etc". Its values are drawn from the HL7 ActMood vocabulary
table.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.3.1
</div> 
<div  class="body"> 
The values specified in the ActMood vocabulary partially overlap with SNOMED CT representations of [ 408729009 | finding context
] and [ 408730004 | procedure context ].

 
* SNOMED CT [ 408729009 | finding context ]:
** Represents an assertion that the [ 246090004 | associated finding ] is: present, absent, a goal, a risk or an expectation.
** May also represent an assertion that the presence or absence of a finding is unknown, possible or probable.
** Applies to:
*** any SNOMED CT expression that represents a [ &lt;&lt;404684003 | clinical finding ].
*** any SNOMED CT expression that represents either a [ &lt;&lt;71388002 | procedure ] or an [ &lt;&lt;363787002 | observable entity ] provided                                                       that the expression is combined with a relevant result or value.
**
** Is relevant to instances of HL7 Observation classes expressed in "event", "goal", "expectation" and "risk" moods.
*
* SNOMED CT [ 408730004 | procedure context ]
** Represents an assertion that the [ 363589002 | associated procedure ] is: "requested", "planned", "started", "done", "cancelled",                                                 "not done", "not to be done" or one of several more specific [ &lt;&lt;408730004 | procedure context ] values.
** May also represent an assertion that it is not known whether the procedure has been done.
** Applies to any SNOMED CT expression that represents a [ &lt;&lt;71388002 | procedure ] (except where that expression is combined                                                 with a relevant result value).
** Is relevant to:
*** instances of various HL7 Act classes including Procedure, SubstanceAdministration and Supply.
*** instances of the HL7 Observation class except in "intent" moods (including "request" and other subtype of "intent").
**
*
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.3.2
</div> 
<div  class="body"> 
The following rules ensure validation and consistent interpretation of particular combinations of moodCode and SNOMED CT context.
They also specify the context a particular moodCode value applies to a SNOMED CT expression that does not include an explicit
representations of context.

 
# The moodCode SHALL be present in all Act class instances [[[4]]]
# If the ''code'' attribute of an instance of the Observation class, with a moodCode that is neither "intent" (INT) nor a subtype of "intent",                                           is populated with a SNOMED CT expression, this expression MAY include an explicit representation of [ 408729009 | finding                                           context ].
#* If the expression does not include an explicit [ 408729009 | finding context ], it SHALL be interpreted as having the default                                                 context specified for the relevant moodCode in [[HL7 Act.moodCode mapping to default context for SNOMED CT findings]].
#* If the expression includes an explicit [ 408729009 | finding context ], the context SHALL be compatible with the constraints                                                 specified for the relevant moodCode in [[HL7 Act.moodCode constraints on explicit context for SNOMED CT findings]].  Any Act class instance does not conform to these constraints SHALL be regarded as an error.
#
# If the ''value'' attribute of an instance of the Observation class is populated with a SNOMED CT expression, this expression MAY include an                                           explicit representation of [ 408729009 | finding context ].
#* If the expression does not include an explicit [ 408729009 | finding context ], it SHALL be interpreted as having the default                                                 context specified for the relevant moodCode in [[HL7 Act.moodCode mapping to default context for SNOMED CT findings]].
#* If the expression includes an explicit [ 408729009 | finding context ], the context SHALL be compatible with the constraints                                                 specified for the relevant moodCode in [[HL7 Act.moodCode constraints on explicit context for SNOMED CT findings]].  Any Act class instance does not conform to these constraints SHALL be regarded as an error.
#
# If the ''code'' attribute of an instance of any Act class (except Observations included in points 2 or 3 above) is populated with a SNOMED                                           CT expression, this expression MAY include an explicit representation of [ 408730004 | procedure context ].
#* If the expression does not include an explicit [ 408730004 | procedure context ], it SHALL be interpreted as having the default                                                 context specified for the relevant moodCode in [[HL7 Act.moodCode mapping to default context for SNOMED CT procedures]].
#* If the expression includes an explicit [ 408730004 | procedure context ], the context SHALL be compatible with the constraints                                                 specified for the relevant moodCode in [[HL7 Act.moodCode constraints on explicit context for SNOMED CT procedures]].  Any Act class instance does not conform to these constraints SHALL be regarded as an error.
#
# If a SNOMED CT expression includes an explicit statement of context this SHALL be validated by the rules stated above and                                           SHALL be interpreted as a restatement or refinement of the meaning specified by the moodCode. The meaning of the SNOMED CT                                           context SHALL NOT be interpreted as an independent compounding semantic modifier.<br>
<blockquote>''For example''<br>
moodCode="RQO" and code=[ 408730004 | procedure context | = 385644000 | requested ]<br> This means "requested". It does not mean a "request to request".                                           </blockquote> <blockquote><br>
moodCode="INT" and code=[ 408730004 | procedure context | = 385650005 | organised ]<br>  This means "organized". It does not mean an "intention to organize".                                           </blockquote> <blockquote><br>
moodCode="INT" and value=[ 408729009 | finding context | = 410518001 | goal ]<br> This is an error. It does not mean an "intention to set a goal".                                           </blockquote>
 
[[HL7 Act.moodCode mapping to default context for SNOMED CT findings]] shows the mapping from moodCode to the default [ 408729009 | finding context ] for concepts that are subtypes of [ 404684003
| clinical finding ]. [[HL7 Act.moodCode mapping to default context for SNOMED CT procedures]] shows the mapping from moodCode to default [ 408730004 | procedure context ] for concepts that are subtypes of [ &lt;&lt;71388002
| procedure ].

 
[[HL7 Act.moodCode constraints on explicit context for SNOMED CT findings]] shows the [ 408729009 | finding context ] validation constraints for SNOMED CT expressions based on the moodCode of the containing
Act class instance. [[HL7 Act.moodCode constraints on explicit context for SNOMED CT procedures]] shows the [ 408730004 | procedure context ] validation constraints for SNOMED CT expressions based on the moodCode of the
containing Act class instance.

 
In these tables the symbol "&lt;&lt;" preceding a value indicates that either the value or any subtype of the value is permitted.

 
The context values in these tables are based on the following assumptions about other attributes in the same Act class instance:If
any these assumption do not apply then refer to the referenced sections for further information.

 
* the HL7 negationInd is omitted from the Act class instance (see [[Act.negationInd]])
* the HL7 uncertaintyCode is omitted from the Act class instance (see [[Act.uncertaintyCode]])
* the HL7 statusCode in the Act class instance has a value that does not influence the context (see [[Act.statusCode]])
                            
{| border="1"
|+HL7 Act.moodCode mapping to default context for SNOMED CT findings 
|-
!moodCode
!Mood Name
!Finding context
|-
|EVN
|Event
|[ 410515003 | known present ]
|-
|
                                             GOL
                                          
|Goal
|[ 410518001 | goal ]
|-
|
                                             RSK
                                          
|Risk
|[ 410519009 | at risk ]
|-
|
                                             EXPEC
                                          
|Expectation
|[ 410517006 | expectation ]
|}                             
{| border="1"
|+HL7 Act.moodCode constraints on explicit context for SNOMED CT findings
|-
!moodCode
!Mood name
!Finding context
|-
|EVN
|Event
|[(&lt;&lt;36692007 | known |)<br>
OR<br>
                                             (&lt;&lt;261665006 | unknown |)]
                                          
|-
|
                                             GOL
                                          
|Goal
|[ &lt;&lt;410518001 | goal ]
|-
|
                                             RSK
                                          
|Risk
|[ &lt;&lt;410519009 | at risk ]
|-
|
                                             EXPEC
                                          
|Expectation
|[ &lt;&lt;410517006 | expectation ] 
|}                                            
{| border="1"
|+HL7 Act.moodCode mapping to default context for SNOMED CT procedures
|-
!moodCode
!Mood name
!Procedure context
|-
|EVN
|Event
|[ 385658003 | done )<br>
OR<br>
(''values dependent of Act.statusCode - see note'' )]
                                          
|-
|INT
|Intent
|[ 410522006 | pre-starting action status ]
|-
|RQO
|Request
|[ 385644000 | requested ]
|-
|PRP
|Proposal
|[ 385643006 | to be done ]
|-
|PRMS
|Promise
|[ 385645004 | accepted ]
|-
|ARQ
|Appointment request
|[ 385644000 | requested ]
|-
|APT
|Appointment
|[ 416151008 | scheduled ]
|} <blockquote> 
'''Note: '''For more information on statusCode dependent values see [[HL7 statusCode impact of defaults and constraints applicable to procedure context for Acts in "event" mood]]

 </blockquote>                                           
{| border="1"
|+HL7 Act.moodCode constraints on explicit context for SNOMED CT procedures
|-
!moodCode
!Mood name
!Procedure context
|-
|EVN
|Event
|[ (&lt;&lt;410523001 | post-starting action status)<br>
OR<br>
[[]]''(values dependent of Act.statusCode - see note )'' ]
                                          
|-
|INT
|Intent
|[ &lt;&lt; 410522006 | pre-starting action status ]
|-
|RQO
|Request
|[ &lt;&lt; 385644000 | requested ]
|-
|PRP
|Proposal
|[ (&lt;&lt; 385649005 | being organized |)<br>
OR<br>
(&lt;&lt; 385643006 | to be done |) ]
                                          
|-
|PRMS
|Promise
|[ &lt;&lt;385649005 | being organized ]
|-
|ARQ
|Appointment request
|[ &lt;&lt; 385644000 | requested ]
|-
|APT
|Appointment
|[ &lt;&lt; 385649005 | being organized ]
|} 
For more information on statusCode dependent values see [[HL7 statusCode impact of defaults and constraints applicable to procedure context for Acts in "event" mood]]

 
[[HL7 MoodCodes that have no direct relationship to finding or procedure context]] lists Act.moodCodes that have no direct relationship to SNOMED CT context attributes. While no constraints are specified
for these moodCodes, some combinations may be irrational or open to misinterpretation. Therefore, caution should be used when
combining these moodCodes with explicit representations of SNOMED CT context.

                       
{| border="1"
|+HL7 MoodCodes that  have no direct relationship to finding or procedure context
|-
!moodCode
!Name
|-
|DEF
|Definition
|-
|SLOT
|Resource slot
|-
|EVN.CRT
|Event criterion
|-
|OPT
|Option
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.3.3
</div> 
<div  class="body"> 
The Act.moodCode is a mandatory component all HL7 Act classes. Therefore this HL7 representation is required irrespective
of whether SNOMED CT context representations are used.

 
SNOMED CT [ 408729009 | finding context ] and [ 408730004 | procedure context ] value hierarchies include more specific meanings
than those associated with the Act.moodCode. Therefore, the SNOMED CT representation cannot be prohibited without resulting
in loss of information.

 
For example, Act.moodCode cannot be used to express various:

 
* SNOMED CT [ 408730004 | procedure context ] values, including [ 410536001 | contraindicated ] and [ 385661002 | considered                                           and not done ].
* SNOMED CT [ 408729009 | finding context ] values, including [ 410596003 | likely outcome ] and [410605003 | confirmed present                                           ].
 
The SNOMED CT context model permits default context values to be applied, based on the surrounding information model. Therefore,
inclusion of SNOMED CT context can be specified as optional, provided there are explicit rules (such as those in [[HL7 Act.moodCode mapping to default context for SNOMED CT findings]] and [[HL7 Act.moodCode mapping to default context for SNOMED CT procedures]]) for deriving default context values from the moodCode and, where relevant, from other HL7 Act class attributes.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.4
</div> 
<div  class="body"> 
The Act.statusCode is defined "a code specifying the state of the Act". This definition is further elaborated by the state-machine
diagram for the Act class in the RIM documentation and the ActStatus vocabulary.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.4.1
</div> 
<div  class="body"> 
The interaction between statusCode and SNOMED CT semantics varies according to the nature of the statusCode and the value
of the Act.moodCode.

 
* The most general HL7 Act.statusCode values ("NORMAL", "OBSOLETE" and "NULLIFIED") relate to whether the Act class instance                                           is currently valid. These states do not result in any overlaps with SNOMED CT semantics.
* Other states overlap with aspects of SNOMED CT semantics in a manner that is to some extent dependent on the mood of the Act.
 
Unlike the other attributes discussed in this section the value of the statusCode may progress over time. Thus the fact that
a "request" was aborted implies that a request was made, as well as indicating that the request was not acted upon. Therefore,
the impact of a Act.statusCode on SNOMED CT semantics depends on whether the concern is to know what steps were taken or to
know whether a step was completed.

 
The relevance of statusCode is fairly clear cut when the Act.moodCode value is "EVN", since this implies an actual occurrence.
In these cases, the statusCode pertains to whether the event is complete and thus directly to the SNOMED CT [ 408730004 |
procedure context ].

 
In other moods, this relationship is less clear. For example, the Act.statusCode applies to an Act with moodCode "RQO" refers
to the status of the request, whereas the [ 408730004 | procedure context ] refers to the progress of the concept specified
by the [ 363589002 | associated procedure ].

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.4.2
</div> 
<div  class="body"> 
The following rules deal only with cases where the Act.statusCode has a clear effect on the meaning of an Act class instance
in a particular mood. Other rules or guidelines, based on similar principles, may be added in the future.

 
# Act class instances SHALL be interpreted taking account of the Act.statusCode and the way particular values of this attribute                                           when combined with the Act.moodCode may alter the default or permitted [ 408730004 | procedure context ] values.
# In the case of an Act in "event" mood the defaults and constraints specified in [[]] and [[]] should be modified in accordance with statusCode as shown in  [[HL7 statusCode impact of defaults and constraints applicable to procedure context for Acts in "event" mood]].
                                             
{| border="1"
|+HL7 statusCode impact of defaults and constraints applicable to procedure context for Acts in "event" mood
|-
!statusCode
!Default procedure context
!Procedure context constraints
|-
|new
|[ 410522006 | pre-starting action status ]
|[ &lt;&lt;410522006 | pre-starting action status ]
|-
|active
|[ 410523001 | post-starting action status ]
|[ &lt;&lt;410523001 | post-starting action status ]
|-
|complete
|[ 385658003 | done ]
|[ &lt;&lt;385658003 | done ]
|-
|held
|[ 385642001 | under consideration ]
|[ &lt;&lt;385642001 | under consideration ]
|-
|cancelled
|[ 89925002 | cancelled ]
|[ &lt;&lt;89925002 | cancelled ]
|-
|suspended
|[ 385655000 | suspended ]
|[ &lt;&lt;385655000 | suspended ]
|-
|aborted
|[ 385657008 | abandoned ]
|[ &lt;&lt;385657008 | abandoned ]
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.4.3
</div> 
<div  class="body"> 
The HL7 statusCode changes throughout the life cycle of an Act in its specified mood, until it reaches an end-state. Consideration
of the impact of a statusCode on aspects of semantics depends on whether the requirement is to know 'what steps were taken'
or 'whether a step was completed'. Thus the fact that a "request" was aborted implies that a request was made, as well as
indicating that the request was not taken through to normal completion.

 
The statusCode values "new", "active", "held", "completed", "cancelled", "suspended", "nullified" and "obsolete" track the
progress of the Act in its specified mood. The semantic relevance of statusCode in "event" mood is more clear cut than in
other moods.

 
* For example, statusCode="completed"
** when applied to an Act with moodCode="ENV" implies [ 408730004 | procedure context =  385658003 | done ]
** when applied to an Act with moodCode="RQO" implies that the act of request has been completed.                                                 It does ''not ''mean that the requested action has been completed.
*
 
The statusCode values "NORMAL", "OBSOLETE" and "NULLIFIED" relate to the validity of a particular representation of an Act
class instance. These states do not result in any overlaps with SNOMED CT semantics because the meaning of an Act class instance
is no longer relevant if it has been "NULLIFIED" or marked as "OBSOLETE".

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.5
</div> 
<div  class="body"> 
The Procedure.targetSiteCode is defined by HL7 as &#8220;the anatomical site or system that is the focus of the procedure.&#8221; The
Observation.targetSiteCode is defined as "a code specifying detail about the anatomical site or system that is the focus of
the observation if this information is not already implied by the observation definition or Act.code."

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.5.1
</div> 
<div  class="body"> 
SNOMED CT finding concepts have a defining attribute that specifies the [ 363698007 | finding site ] and similarly SNOMED
CT procedure concepts have a defining attribute that specifies the "procedure site". The post-coordination rules that apply
to SNOMED CT permit refinement of these defining attributes. The resulting post-coordinated expressions can be represented
in a single coded attribute using the HL7 Concept Description (CD) data type.

 
The result of this is that there are two completely overlapping approaches to the representation of sites associated with
observations and procedures.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.5.2
</div> 
<div  class="body"> 
The following rules avoid redundancy and the risk of misinterpretation by restricting the use of targetSiteCode in Act class
instances. There are two sections dealing with information models which 1) contain only SNOMED content and 2) allow multiple
terminologies to be used.

 
If an Act.code or Observation.value contains only SNOMED-CT content then the following shall apply:

 
# The targetSiteCode attribute SHOULD be omitted from any Act instance.
# If necessary the specific site applicable SHOULD be represented as part of the SNOMED-CT expression (in Act.code or Observation.value)                                           by refining the [[relevant site attribute]] as part of a pre post-coordinated expression.
 
If an Act.code or Observation.value contains SNOMED-CT content as one permitted code system then the following shall apply:

 
# The targetSiteCode attribute SHALL be optional in any Act instance.
# If the targetSiteCode attribute is present in an Observation or Procedure class instance in which the Act.code or Observation.value                                           is expressed using SNOMED-CT then:
#* The targetSiteCode SHALL also be represented using SNOMED-CT
#* The targetSiteCode SHALL be the same as, or a subtype of, the value of the [[relevant site attribute]] as specified in the SNOMED-CT expression
#* The targetSiteCode SHALL be treated as equivalent to a restatement or refinement of the [[relevant site attribute]] in the SNOMED-CT expression
#* If the value of the targetSiteCode attribute is incompatible with the above rules then this SHALL be interpreted as an error
#
 <blockquote> 
'''Note: '''The ''relevant site attribute'' depends on the SNOMED CT Concept Model for the type of procedure or finding. It may be one of the following: [ 363698007
| finding site ], [ &lt;&lt;363704007 | procedure site ], [ 405813007|procedure site - Direct ] or [ 405814001|procedure site -
Indirect ]. In some cases, "procedure morphology", "direct morphology" or "indirect morphology" may also provide more specific
site related information.

 </blockquote> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.5.3
</div> 
<div  class="body"> 
The notes following the definition of Observation.targetSiteCode make it clear that the intent is not to repeat a site implied
by the Act.code.

<blockquote>Most observation target sites are implied by the observation definition and Act.code, or Observation.value. For example, "heart
                                          murmur" always has the heart as target. This attribute is used only when the observation target site needs to be refined,
                                          to distinguish right and left etc.
                                       </blockquote>  
The notes following the Procedure.targetSiteCode definition are perhaps a little less clear cut. However, they convey a similar
general sense.

<blockquote>Some target sites can also be "pre-coordinated" in the Act definition, so that there is never an option to select different
                                          body sites. The same information structure can handle both the pre-coordinated and the post-coordinated approach.
                                       </blockquote>  
Therefore, if the Procedure.code or Observation.code specifies the site to a sufficient level of detail, there is no requirement
to include a separate targetSiteCode attribute. When using SNOMED CT post-coordination to refine the site, the Act.code specifies
the site to the same level of detail as can be achieved using the targetSiteCode.

 
SNOMED CT offers additional features which make it significantly more expressive than the targetSiteCode:

 
* Specific subtypes of the [ &lt;&lt;363704007 | procedure site ] attribute distinguish between the direct and indirect targets of                                           a procedure. One use of this is to ensure that removal of a something from an organ does not classify as a type of removal                                           of that organ.
** For example:
*** [ 287742007|ureter calculus removal ]<br>    is defined as a procedure with<br>
[ {260686004|method|=129303008|removal - action|<br>
,363700003|direct morphology|=56381008|calculus|<br>
,405814001|procedure site - Indirect|=87953007|ureteric structure|} ]
*** [ 51607004|total ureterectomy | ]<br>    is defined as a procedure with ...<br>
[ {260686004|method|=129304002|excision - action|   <br>
,405813007|procedure site - Direct|=302511008|entire ureter|} ]
**
*
* Explicit grouping of attributes allows representation of multiple sites associated different actions in a single procedure.
** For example
*** The procedure [ 11401008 | dilation and curettage of uterus ] involves dilatation of one site (cervix uteri) and curettage                                                       of another (endometrium) so it is defined as a procedure with the following two relationship groups ...
*** [  {260686004 | method | = 129319001 | curettage - action |     <br>   ,405813007 | procedure site - Direct | = 2739003 | endometrial structure | } <br>  {260686004 | method | = 129419002 | dilation - action |    <br>   ,405813007 | procedure site - Direct | = 71252005 | cervix uteri structure | }  ]
**
*
 
The recommendation to use the SNOMED CT representation of site is based on the added expressivity. Omission of the HL7 targetSiteCode
attribute is recommended to avoid the redundancy and the potential for conflicts between the two forms of representation of
site. However, while the use of these HL7 attributes is deprecated, it is permitted to support use in environments that do
not support SNOMED CT post-coordination. In this case, requiring these attributes to be encoded using SNOMED CT and interpreted
as refinements of the relevant SNOMED CT attributes, enables a simple transformation to the recommended form.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.6
</div> 
<div  class="body"> 
The Procedure.approachSiteCode is defined by HL7 as "the anatomical site or system through which the procedure reaches its
target (see targetSiteCode)."

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.6.1
</div> 
<div  class="body"> 
SNOMED CT procedure concepts have a defining attribute that specifies the [ 424876005 | approach ] and has a comparable meaning.
The post-coordination rules that apply to SNOMED CT permit refinement of this defining attribute. The resulting post-coordinated
expressions can be represented in a single coded attribute using the HL7 Concept Description (CD) data type.

 
The result of this is that there are two completely overlapping approaches to the representation of approaches associated
with procedures.

 
While HL7 models SubstanceAdministration as a separate class from Procedure, the SNOMED CT concept [ 432102000 | administration
of therapeutic substance ] is a subtype of procedure. Therefore the [ 424876005 | approach ] attribute can also be applied
to refine SNOMED expressions that encode the action associated with SubstanceAdministration. Therefore, this overlap also
applies to that class.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.6.2
</div> 
<div  class="body"> 
The following rules avoid redundancy and the risk of misinterpretation by restricting the use of the approachSiteCode in Procedure
and SubstanceAdministration class instances. There are two sections dealing with information models which 1) contain only
SNOMED content and 2) allow multiple terminologies to be used.

 
If a Procedure.code or SubstanceAdministration.code contains only SNOMED-CT content then the following shall apply:

 
# The approachSiteCode attribute SHOULD BE omitted from any Act instance.
# If necessary the specific site applicable SHOULD be represented as part of the SNOMED-CT expression (in Procedure.code or                                           SubstanceAdministration.code) by refining the relevant site attribute as part of a pre or post-coordinated expression.
 
If a Procedure.code or SubstanceAdministration.code contains SNOMED-CT content as one permitted code system then the following
shall apply:

 
# The approachSiteCode SHALL be optional in any Act instance.
#
#* The approachSiteCode SHALL also be represented using SNOMED-CT
#* The approachSiteCode SHALL be the same as, or a subtype of, the value of the relevant site attribute as specified in the SNOMED-CT                                                 expression
#* The approachSiteCode SHALL be treated as equivalent to a restatement or refinement of the relevant site attribute in the SNOMED-CT                                                 expression
#* If the value of the approachSiteCode attribute is incompatible with the above rules then this SHALL be interpreted as an error
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.6.3
</div> 
<div  class="body"> 
The notes following the Procedure.approachSiteCode definition suggest that the intent is not to repeat the approach if it
is fixed by the nature of the procedure specified by the Act.code.

<blockquote>Some [ 424876005 | approach ]  sites can also be "pre-coordinated" in the Act definition, so that there is never an option
                                          to select different body sites. The same information structure can handle both the pre-coordinated and the post-coordinated
                                          approach.
                                       </blockquote>  
Therefore, if the Procedure.code or SubstanceAdministration.code specifies the [ 424876005 | approach ] to a sufficient level
of detail, there is no requirement to include a separate approachSiteCode attribute. When using SNOMED CT post-coordination
to refine the [ 424876005 | approach ] , the Act.code can specify the approach to the same level of detail as can be achieved
using the approachSiteCode attribute.

 
The vocabulary domain specified for approachSiteCode is ActSite which is the same as the vocabulary domain for targetSiteCode.
In contrast SNOMED CT uses a specific value hierarchy for approaches which is different from the one used for [ 363698007
| finding site ] or [ &lt;&lt;363704007 | procedure site ]. The distinction is that an approach is a route used to reach a target
site rather than a specific structural landmark that represents a point on or part of that route.

 
The example values in the approachSiteCode include a mixture of approaches (e.g. "trans-abdominal approach" and "retroperitoneal
approach") which fit the idea of approach as used by SNOMED CT. However, references to the punctured area of skin or structural
landmarks have a significantly different semantic quality. Many sites are never the names of routes, several routes may pass
through a single site and a route may pass through several sites. Therefore attempts to combine SNOMED CT and HL7 representations
of approach may result in confusion rather than clarity.

 
The recommendation to use the SNOMED CT representation of [ 424876005 | approach ] is based on the more appropriate range
of values available for this attribute, and on the fact that many procedure concepts pre-coordinate an implied or explicitly
stated approach. Omission of the HL7 approachSiteCode attribute is recommended to avoid the redundancy and the potential for
conflicts between the two forms of representation of site. However, while the use of these HL7 attributes is deprecated, it
is permitted to support use in environments that do not support SNOMED CT post-coordination. In this case, requiring the approachSiteCode
attributes to be encoded using SNOMED CT and interpreted as refinements of the SNOMED CT [ 424876005 | approach ] , enables
a simple transformation to the recommended form.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.7
</div> 
<div  class="body"> 
The Procedure.methodCode is defined by HL7 as &#8220;identifies the means or technique used to perform the procedure&#8221;. The Observation.methodCode
is defined as &#8220;a code that provides additional detail about the means or technique used to ascertain the observation.&#8221;

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.7.1
</div> 
<div  class="body"> 
SNOMED CT concepts have a defining attribute that specifies the [ 260686004 | method ] used. SNOMED CT "evaluation procedure"
concepts, which may be used to specify the nature of an observation, have a defining attribute that specifies the [ 370129005
| measurement method ]. SNOMED CT [ 404684003 | clinical finding ] concepts, which may be used as values of a nominalized
observation or assertion, have a defining attribute that specifies the [ 418775008 | finding method ]. The post-coordination
rules that apply to SNOMED CT permit refinement of this defining attribute. The resulting post-coordinated expressions can
be represented in a single coded attribute using the HL7 Concept Description (CD) data type.

 
The result of this is that there are two overlapping approaches to the representation of methods associated with observations
and procedures.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.7.2
</div> 
<div  class="body"> 
The following rules avoid redundancy and the risk of misinterpretation by restricting the use of the methodCode in Procedure
and Observation class instances. There are two sections dealing with information models which 1) contain only SNOMED content
and 2) allow multiple terminologies to be used.

 
If an Act.code or Observation.value contains only SNOMED-CT content then the following shall apply:

 
# The methodCode attribute SHOULD be omitted from any Act instance.
# If necessary the method applicable SHOULD be represented as part of the SNOMED-CT expression (in Act.code or Observation.value)                                           by refining the [[relevant method attribute]] as part of a post-coordinated expression.
 
If an Act.code or Observation.value contains SNOMED-CT content as one permitted code system then the following shall apply:

 
# The methodCode attribute SHALL be optional in any Act instance.
# If the methodCode attribute is present in an Observation or Procedure class instance in which the Act.code or Observation.value                                           is expressed using SNOMED-CT then:
#* The methodCode SHALL also be represented using SNOMED-CT
#* The methodCode SHALL be the same as, or a subtype of, the value of the [[relevant method attribute]] as specified in the SNOMED-CT expression
#* The methodCode SHALL be treated as equivalent to a restatement or refinement of the [[relevant method attribute]] in the SNOMED-CT expression
#* If the value of the methodCode attribute is incompatible with the above rules then this SHALL be interpreted as an error
#
 <blockquote> 
'''Note: '''The ''relevant method attribute'' depends on the SNOMED Concept Model in respect of the type of procedure or finding. It may be one of the following: [ 260686004
| method ], [ 418775008 | finding method ] or [ 370129005 | measurement method ].

 </blockquote> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.7.3
</div> 
<div  class="body"> 
The notes following the definition of Observation.methodCode make it clear that the intent is not to repeat a method implied
by the Act.code.

<blockquote>
                                          In all observations the method is already partially specified by simply knowing the kind of observation (observation definition,
                                          Act.code) and this implicit information about the method does not need to be specified in Observation.methodCode.
                                       </blockquote>  
The notes following the Procedure.methodCode are less explicit about avoidance of duplication. However, they do suggest that
code systems might be designed with relationships between procedures and possible method &#8211; which is exactly how SNOMED CT
is designed. What the note does not take into account is that the terminology may also specify a way to represent a specific
method with the procedure in a single code or expression.

<blockquote>
                                          '&#8230;  a code system might be designed such that it specifies a set of available methods for each defined Procedure concept'
                                       </blockquote>  
Therefore, if the Act.code or Observation.value specifies the method to a sufficient level of detail, there is no requirement
to include a separate methodCode attribute. When using SNOMED CT post-coordination to refine the method, the Act.code or Observation.value
specifies the method to the same level of detail as can be achieved using the methodCode.

 
The notes on methodCode use "open" and "laparoscopic" procedures as examples of differences in method. SNOMED CT makes this
same differentiation using another defining attribute [ 260507000 | access ]. This highlights the potential for confusion
from using both SNOMED and HL7 representations of method.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.8
</div> 
<div  class="body"> 
The Act.priorityCode is defined by HL7 as &#8220;a code or set of codes (e.g., for routine, emergency), specifying the urgency under
which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.&#8221;

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.8.1
</div> 
<div  class="body"> 
The semantics of this attribute potentially overlaps with SNOMED CT &#8220;[ 260870009 | priority ]&#8221; attribute which "... refers
to the priority assigned to a procedure".

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.8.2
</div> 
<div  class="body"> 
The following rules recommend specific uses for the HL7 and SNOMED CT representations of priority. There are two sections
dealing with information models which 1) contain SNOMED content and 2) allow multiple terminologies to be used.

 
In all cases:

 
# Act class clones SHALL include the priorityCode attribute if there is a requirement for expressing the urgency of a request,                                           tracking and auditing services based on requested prioritization or any other aspects of workflow management related to priority.
# Act class clones ''need not ''include the priorityCode attribute if the only requirement for indicating priority relates to distinguishing differences between                                           the nature of the procedure itself based on priority (see example below).
# In Act class instances the Act.priorityCode attribute SHALL be used where it has a specific functional role in relation to                                           the purpose of a communication.
#* For example, to prioritize a request for a service or to track the priority under which a service was scheduled and carried                                                 out.
#
 
In cases where SNOMD-CT is used.:

 
# In Act class instances, the relevant SNOMED CT priority attribute SHOULD be included in the expression in the Act.code or                                           Observation.value if the priority significantly alters the nature of the statement.
#* The priorityCode SHALL be the same as, or a subtype of, the value of the relevant priority attribute as specified in the SNOMED-CT                                                 expression
#* For example, an [ 274130007 | emergency cesarean section ] is a significantly different procedure when compared with an [                                                 177141003 | elective caesarean delivery ].
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.8.3
</div> 
<div  class="body"> 
At face value the Act.priorityCode and the SNOMED CT [ 260870009 | priority ] attribute appear to have similar meanings. However,
the way in which these are used appears to differ significantly. These aspects of priority can vary independently of one another.
Two requests for the same procedure can assert different priorities for processing them based on perceived clinical need or
other factors. On the other hand, some emergency procedures are carried out directly without a specific request and thus without
the normal workflow associated with prioritization.

 
* The SNOMED CT attribute is used to specify the defining characteristic that distinguishes an elective procedure from an emergency                                           procedure. Like any defining attribute it can also be used to refine or qualify a procedure that is specified without references                                           to its urgency.
* The HL7 priorityCode is generally used to communicate priority in relation to workflow management and audit. One obvious use                                           case for this is to allow request for a service to indicate the priority assigned to it by the requester.
 
The use of a distinct information model attribute (i.e. Act.priorityCode), which is applicable to all services, makes the
priority more readily accessible to workflow management. It does not require the SNOMED CT expression to be parsed to determine
the priority of a request or action. In addition, it allows consistent handling of priority when some services are represented
using SNOMED CT while others are represented using different code systems.

 
The use of a representation of priority that is integrated with the definition model of the associated concept is more useful
from the perspective of clinical record retrieval. The description logic model of SNOMED CT ensures the computational equivalence
of a procedure concept defined as an emergency and a post-coordinated expression in which [ 260870009 | priority | = 25876001
| emergency ] is added to the more general procedure concept.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.9
</div> 
<div  class="body"> 
The Act.negationInd is defined by HL7 as &#8220;An indicator specifying that the Act statement is a negation of the Act as described
by the descriptive attributes&#8221;.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.9.1
</div> 
<div  class="body"> 
The semantics of this attribute overlaps with:

 
* SNOMED &#8220;[ 408729009 | finding context ]&#8221; values indicating absence of a specified finding.
* SNOMED CT &#8220;[ 408730004 | procedure context ]&#8221; values indicating that a specified procedure was not done.
 
This overlap leads to a potential ambiguity since a combination of negationInd with a contextual representation of absence
might be interpreted either as:

 
* double negation (i.e. "finding ''X'' is ''not'' absent" which is equivalent to "finding ''X'' is present")
* restatement or emphasis of the negative resulting from a mapping between the two ways to indicate negation or absence (i.e.                                           "negative observation: finding ''X'' is absent" which means "finding ''X'' is absent").
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.9.2
</div> 
<div  class="body"> 
The following rules avoid the risk of misinterpretation by prohibiting use of the negationInd in Act class instances that
are encoded using SNOMED CT.

 
# In a constrained information model or template the negationInd attribute SHOULD be omitted from:
#* any Act class clone in which SNOMED CT is the only permitted code system for the Act.code attribute.
#* any Observation class clone in which SNOMED CT is the only permitted code system for the Observation.value attribute.
#
# In a constrained information model or template, the negationInd attribute SHALL be optional if it is included in:
#* an Act class clone in which SNOMED CT  is one of the permitted code systems for the Act.code attribute.
#* any Observation class clone in which SNOMED CT is one of the permitted code systems for the Observation.value attribute.
#
# The negationInd attribute SHOULD be omitted from any Act class instance in which the Act.code attribute is expressed using                                           SNOMED CT.
#* Negative assertions about an Act (e.g.  "procedure not done", "substance not to be administered" ) SHOULD be represented,                                                 as part of the SNOMED CT expression in the Act.code attribute, by including the appropriate explicit [ 408730004 | procedure                                                 context ] (e.g. [ 3385660001 | not done ] or [410521004 | not to be done]).
#
# The negationInd attribute SHOULD be omitted from any Observation class instance in which the Observation.value attribute is                                           expressed using SNOMED CT.
#* Assertions of negative Observations (e.g. absence of a specified finding) SHOULD be represented, as part of the SNOMED CT                                                 expression in the Observation.value attribute, by including the appropriate explicit [ 408729009 | finding context ].
#
# The negationInd attribute MAY be included in an Act class instance where the SNOMED CT expression represents a [ &lt;&lt;71388002                                           | procedure ]  with no explicit [ 408730004 | procedure context ] or a [ &lt;&lt;129125009 | procedure with explicit context ] with                                           [ 408730004 | procedure context | = 385658003 | done ]
#* This approach is not recommended but is permitted to allow simple negation in systems that do not support the SNOMED CT context                                                 model. If it is used, it SHALL be interpreted as equivalent to the specified [ 363589002 | associated procedure ] with [ 408730004                                                 | procedure context | = 3385660001 | not done ].
#
# The negationInd attribute MAY be included in an Observation class instance where the SNOMED CT expression represents a [ &lt;&lt;404684003                                           | clinical finding ] with no explicit [ 408729009 | finding context ] or a [ &lt;&lt;413350009 | finding with explicit context ]                                           with the [ 408729009 | finding context = 410515003 | known present ].
#* This approach is not recommended but is permitted to allow simple negation in systems that do not support the SNOMED CT context                                                 model. If it is used, it SHALL be interpreted as equivalent to the specified [ 246090004 | associated finding ] with a [ 408729009                                                 | finding context | =  410516002 | known absent ].
#
# If the negationInd attribute is present in an Act class instance in which either the Act.code or Observation.value is expressed                                           using SNOMED CT, it SHALL be interpreted as an error unless the conditions noted in points 5 and 6 above apply.
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.9.3
</div> 
<div  class="body"> 
The Act.negationInd is an optional RIM attribute which negates the meaning of an Act. This negation is unnecessary in cases
where SNOMED CT is used because the context attributes can be used to specify the absence of a finding or the fact that a
procedure has not been done. Including both representations introduces potential for serious misinterpretation of combinations
including the following:

 
* Double negative
** If negationInd is true and the SNOMED CT [ 408729009 | finding context | =  410516002 | known absent ] the double negative                                                 would be &#8220;not known absent&#8221; (i.e. &#8220;present&#8221;).
** If negationInd is true and the SNOMED CT [ 408730004 | procedure context | = 3385660001 | not done ] the double negative would                                                 be &#8220;not not done&#8221; (i.e. &#8220;done&#8221;).
** For the avoidance of potential ambiguity this option is explicitly prohibited by rules in this document.
*
* Indication or emphasis of negation
** HL7 negationInd indicates the presence of negation and the SNOMED CT context provides more details of the nature of the negation.
** Implies that if negationInd is true and the Act is coded with SNOMED CT an appropriate negated SNOMED CT finding or procedure                                                 context value (e.g. [ 410516002 | known absent ] or [ 3385660001 | not done ]) should also apply.
** Might imply that if  a negated SNOMED CT finding or procedure context value (e.g. [ 410516002 | known absent ] or [ 3385660001                                                 | not done ]) is applied the negationInd should be true.
*
* Restatement of negation
** HL7 negationInd and SNOMED CT negative contexts apply as alternatives and when combined serve to restate the negation
** Implies that if only negationInd is present a mapping table is required to the relevant SNOMED CT context to enable consistent                                                 interpretation. This mapping table would need to specify combinations of moodCode and negationInd. For example, negationInd=true                                                 with moodCode=&#8220;EVN&#8221; the would imply [ 408730004 | procedure context | = 385660001 | not done ], whereas negationInd=true with                                                 moodCode=&#8220;RQO&#8221; might imply [ 408730004 | procedure context | = 410521004 | not to be done ].
*
 
The simplest way to avoid these possible misunderstandings is to omit the negationInd attribute and allow the SNOMED CT context
attributes to provide information about absent findings and procedures that have not been done. However, to meet requirements
to support some simple negation in systems that do not support the SNOMED CT context model, use of negationInd is permitted
where it cannot be misinterpreted . The only cases where no risk of misinterpretation are where the SNOMED CT context is either
unspecified or explicitly states the default values [ 410515003 | known present ] or [ 385658003 | done ]. The negationInd
can be used to switch these defaults to the appropriate negated values such as [ 410516002 | known absent ] and [ 385660001
| not done ].

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.10
</div> 
<div  class="body"> 
The Act.uncertaintyCode is defined by HL7 as &#8220;a code indicating whether the Act statement as a whole, with its subordinate
components has been asserted to be uncertain in any way.&#8221; The values of this attribute in the HL7 vocabulary are "stated with
no assertion of uncertainty" (N) and "stated with uncertainty" (U).

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.10.1
</div> 
<div  class="body"> 
The semantics of this attribute overlaps with SNOMED CT [ 408729009 | finding context ] values [ &lt;&lt;410590009 | known possible
] and its subtypes including [ 410592001 | probably present ] and [ 410593006 | probably not present]. This provides different
ways to express the uncertainty of a finding and ambiguity about the impact of combining these two representations in a single
Act class instance.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.10.2
</div> 
<div  class="body"> 
The following rules avoid the risk of misinterpretation by prohibiting use of the uncertaintyCode in Act class instances that
are encoded using SNOMED CT. There are two sections dealing with information models which 1) contain only SNOMED content and
2) allow multiple terminologies to be used.

 
If an Act.code or Observation.value contains only SNOMED-CT content then the following shall apply:

 
# The uncertaintyCode attribute SHOULD be omitted from any Act instance.
# If necessary the uncertainty applicable SHOULD be represented as part of the SNOMED-CT expression by refining the relevant                                           context attribute as part of a post-coordinated expression.
 
If an Act.code or Observation.value contains SNOMED-CT content as one permitted code system then the following shall apply:

 
# The uncertaintyCode attribute SHALL be optional in any Act instance.
# If the uncertaintyCode attribute is present in an Act class instance in which the Act.code or Observation.value is expressed                                           using SNOMED-CT then:
#* The uncertaintyCode SHALL also be represented using SNOMED-CT
#* The uncertaintyCode SHALL be the same as, or a subtype of, the value of the relevant context attribute as specified in the                                                 SNOMED-CT expression
#* The uncertaintyCode SHALL be treated as equivalent to a restatement or refinement of the relevant context attribute in the                                                 SNOMED-CT expression
#* If the value of the uncertaintyCode attribute is incompatible with the above rules then this SHALL be interpreted as an error
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.10.3
</div> 
<div  class="body"> 
The SNOMED CT [ 408729009 | finding context ] values provide a more specific way to express uncertainty about the presence
or absence of a finding. This is therefore preferred over the use of the optional uncertaintyCode attribute.

 
The SNOMED CT [ 408730004 | procedure context ] does not contain values to represent "possibly done" or "probably done". As
a result there is no obvious way to express uncertainty about whether a procedure has been done. This may be relevant if an
informer reports something like "I think I had a tetanus vaccination but I am not sure". The current advice is to treat such
information as an Observation about past history, rather than adding uncertainty value to the [ 408730004 | procedure context
] value hierarchy. However, this issue has been raised with the SNOMED Concept Model Working Group and the advice may be revised
if after further consideration the [ 408730004 | procedure context ] value set is expanded.

 
The HL7 UVP (Uncertain Value - Probabilistic) data type was considered as this as another HL7 approach to representation of
uncertainty. The UVP data type is defined as "A generic data type extension used to specify a probability expressing the information
producer's belief that the given value holds." The data types specification adds that "How the probability number was arrived
at is outside the scope of this specification." There is some potential for overlap as the UVP data type is a "generic data
type extension". This means it can be applied to any other data type, and hence to any HL7 attribute. This data type may
be applied to attribute values associated with a SNOMED CT code. For example, to express uncertainty associated with the value
of a particular measurement. However, use of UVP to apply a specific level of uncertainty to a SNOMED CT concept in an Act
should be avoided.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.11
</div> 
<div  class="body"> 
The HL7 RIM defines Observation.interpretationCode as:

 
A qualitative interpretation of the observation.<br>
						Examples: Normal, abnormal, below normal, change up, resistant.<br>
Usage Notes: These interpretation codes are sometimes called "abnormal flags," however, the judgment of normalcy is just one
of the interpretations, and is often not relevant. For example, the susceptibility interpretations are not about "normalcy,"
and for any observation of a pathologic condition, it does not make sense to state the normalcy, since pathologic conditions
are never considered "normal."

 
The value of including an observation interpretation is to be able to say:

 
(a) &#8220;The hemoglobin measurement is 18g/dl and this is abnormally high (when compared with the reference range).&#8221;<br>
or<br>
(b) &#8220;This Streptococcus pneumoniae isolate has been tested for susceptibility to Penicillin G and has been found to be resistant.&#8221;

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.11.1
</div> 
<div  class="body"> 
There are multiple scenarios that may result in overlap, particularly with data recorded in Observation.code or Observation.value.

 
# Within HL7 v3
#* From a modeling perspective, the &#8220;interpretation&#8221; of a value (i.e. laboratory test result, etc.) is an additional &#8220;higher                                                 level&#8221; observation that is made on the results (raw data) from a particular investigation.  This additional observation can,                                                 and likely in some cases does, carry the full semantics of an &#8220;observation&#8221; (including author, author time, etc.), and thus                                                 may be represented by an additional instance of an Observation class.  Alternatively, and more commonly, the result of this                                                 additional observation is represented using the interpretationCode attribute within the original Observation class (which                                                 is essentially a lightweight or &#8220;shortcut&#8221; method for representing this data).  There is the potential for conflict and/or                                                 ambiguity between these two approaches.
#* In some situations, current practice in V3 laboratory messaging (parallel to the common usage in V2) has been to use the Observation.interpretationCode                                                 in place of, rather than in conjunction with Observation.value.  This typically occurs in laboratory antimicrobial susceptibility                                                 messaging (see the Streptococcus susceptibility to Penicillin G example above).
#
# Between HL7 v3 and SNOMED CT
#* The SNOMED-CT concept model for Clinical Findings provides the [ 363714003 | Interprets ] and [ 363713009 | Has interpretation                                                 ] attributes. The latter represents similar notions to those intended for use by the HL7 Observation.interpretationCode attribute.                                                 An example of the use of these attributes is:                                                 									<br>
<br>                                                 									[ 165558001 | Platelet count abnormal ]                                                 									<br>
<br>                                                 									Includes, in its reference definition:                                                 									<br>
<br>                                                 									363714003 | Interprets |=61928009 | Platelet count |,<br>                                                 									363713009 | Has interpretation |=263654008 | Abnormal |
#* Whether primitively represented or defined according to the above scheme, SNOMED CT contains many pre-coordinated &#8216;Finding&#8217;                                                 concepts, that include notions similar to those expressed as &#8216;interpretations&#8217;, for example:                                                 <br>
<br>                                                 [ 110368006 | Decreased estrogen level]<br>                                                 [ 102659003 | Normal glucose level ]<br>
<br>                                                 It is therefore possible to represent, using a SNOMED CT &#8216;Finding&#8217; in Observation.value, notions such as &#8216;normality&#8217;, &#8216;abnormality&#8217;,                                                 &#8216;resistance&#8217;.
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.11.2
</div> 
<div  class="body"> 
Given the complexities described in &#8216;discussion and rationale&#8217;, it is not currently possible to provide normative guidance
on the use of Observation.interpretationCode. In particular, it is not possible to provide guidance on the prohibition of
Observation.interpretationCode where SNOMED CT is the only permitted code system for the Act.code.

 
However, the following guidance (with caveats) can be provided:

 
* In a constrained information model or template that permits or requires the use of SNOMED CT to represent the nature of an                                           Observation class clone, or in which SNOMED CT is one of the permitted code systems for the Observation.value attribute, Observation.interpretationCode                                           SHALL be optional.
* In any Observation class instance in which the Act.code or Observation.value attribute is expressed using SNOMED CT, and Observation.interpreationCode                                           is present, it shall take its value from the following ranges in SNOMED CT:<br>
<br>
((&lt;&lt;281296001 | result comments |) OR (&lt;&lt;260245000 | findings values |))<br>
* Unless explicitly specified by model designers or communicating parties, SNOMED CT findings that represent &#8216;interpretation&#8217;                                           notions are not prohibited from use. It is possible, therefore, that receiving systems and analytic queries that wish to detect                                           &#8216;interpretation&#8217; notions may also need to test the SNOMED CT concept carried as Observation.value.
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.11.3
</div> 
<div  class="body"> 
Relevant to this topic, an HL7 Observation will currently support the representation of three notions:

 
* The thing being observed (in Observation.code)
* The result of the observation (in Observation.value)
* The interpretation of the result of the observation (in Observation.interpretationCode)
 
Either primitively represented or modeled using the &#8216;has interpretation&#8217; attribute, SNOMED CT will support the representation
of the following notions:

 
* The thing being observed (in Observation.code)
* The thing being observed and interpretation of the result of the observation (in Observation.value)
 
There is therefore incomplete overlap in &#8216;interpretation&#8217; representation, and incomplete expressivity of SNOMED CT to support
all aspects of representation (a SNOMED CT Expression cannot exhaustively communicate the result of an observation and its
interpretation).

 
Evidence suggests that Observation.interpretationCode is currently used, and it is not possible currently to provide a SNOMED
CT-only representation to allow its prohibition.

 
Neither is it possible, currently, to enhance normalization rules to support equivalence detection between &#8216;interpretations&#8217;
communicated in Observation.value or in Observation.interpretationCode.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.12
</div> 
<div  class="body"> 
The HL7 Observation.value attribute allows units to be applied to a physical quantity, range or ratio. The HL7 datatypes specification
recommends the use of UCUM (Unified Code for Units of Measure [[[5]]]) to express units in the PQ (physical quantity) datatype.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.12.1
</div> 
<div  class="body"> 
SNOMED CT contains concepts that represent most of the widely used units and these overlap with the UCUM representation. These
SNOMED CT concepts could be represented in the translation sub-element of the PQ datatype. However, this would introduce redundancy
and the potential for conflict between the alternative representations.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.12.2
</div> 
<div  class="body"> 
The following guidance is intended to reduce the need for redundant representation of units and maximize the opportunity for
automated unit conversion.

 
# Wherever possible the unit element of the HL7 PQ (physical quantity) data type SHOULD be encoded using the appropriate UCUM                                           representation and not using a SNOMED CT concept identifier [[[6]]].
# In the case of informal units, which have no standard UCUM representation, a SNOMED CT concept identifier MAY be used in the                                           translation sub-element of the unit element.
#* Examples of informal units include "capsules" or "tablets". In these case the unit "1" (the UCUM symbol meaning "the unity")                                                 SHOULD be used and the SNOMED CT representation of the nature of the counted unit MAY then be used.
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.12.3
</div> 
<div  class="body"> 
Use of UCUM representation simplifies interoperability using HL7 messages. The UCUM specification also supports translation
between different types of units. It is possible to map from SNOMED CT concepts to UCUM in all cases except those where an
informal unit is specified. On the other hand, since the UCUM representation is an expression syntax it can be used to represent
an almost unlimited range of complex units in a formal mathematical manner. Many of the units that can potentially be represented
in UCUM have no pre-coordinated equivalent in SNOMED CT. SNOMED post-coordination does not currently support the type of mathematical
formalism that UCUM offers.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.13
</div> 
<div  class="body"> 
The HL7 Act class includes two attributes related to the temporal situation of an action (Act.effectiveTime, Act.activityTime [[[7]]]). In addition, each participation in an Act may have an associated time (for example, author.time or performed.time). Each
of these times can be expressed either as a point-in-time or a period of time.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.13.1
</div> 
<div  class="body"> 
The SNOMED CT [ 408731000 | temporal context ] distinguishes between findings or procedures that are recorded as part of "past"
history and those that are recorded as [ 15240007 | current ]. It also allows a distinction to be made between a specified
point or period in time (e.g. and a more general unspecified time (e.g. [ 410588008 | past - unspecified ]). The [ 408731000
| temporal context ] potentially affects the interpretation HL7 date and time attributes.

 
When a SNOMED CT expression (or concept definition) includes an explicit representation of [ 408731000 | temporal context
], the effectiveTime might be interpreted either as "the time at which the ''situation ''applied" or "the time at which the ''focus concept'' applied". Guidance is needed to avoid this potentially misleading ambiguity.

 
* For example, the definition of the concept [407553003 | history of - glandular fever] includes:
** [ 246090004 | associated finding | = 271558008 | glandular fever  | , 408731000 | temporal context | = 410513005 | past ]
*** The concept [407553003 | history of - glandular fever] represents a ''situation.''
*** The value of the associated finding attribute is the ''focus concept '' (i.e. the concept [ 271558008 | glandular fever ]).
**
** When an Observation asserts the value [407553003 | history of - glandular fever], the effectiveTime might be interpreted as:
*** The time when the ''focus concept ''applied  (i.e. the time in the past when they actually had glandular fever);
*** The period of time during which the ''situation ''applied (i.e. the period of time during which they had a "history of glandular fever" (i.e. a period of time from when they                                                       first had glandular fever with no upper bound or extending until death);
*** The time during an episode of care when the ''situation ''was recognized (i.e. a period starting when "history of glandular fever" was first recorded as part of the record of this                                                       episode of care);
*** The time during which the ''situation ''was considered clinically relevant (i.e. a period of time based on a clinical judgment of the significance of a past history                                                       of glandular fever to the currents longer term health).
**
*
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.13.2
</div> 
<div  class="body"> 
The following rules clarify the impact of [ 408731000 | temporal context ] on interpretation of HL7 data and time attributes
associated with an Act class instance.

 
# If a SNOMED CT expression includes an explicit [ 408731000 | temporal context ] value, the effectiveTime SHALL be interpreted                                           as applying to the time at which the focus concept applied.
#* The focus concept is the value of the [ 246090004 | associated finding ] or [ 363589002 | associated procedure ] in the SNOMED                                                 CT expression or concept definition.
#** For example, the Act.effectiveTime for [ 407553003 | history of - glandular fever ] is the time, in the past, when they had                                                       glandular fever.
#*
#* If the [ 408729009 | finding context ] indicates negation (e.g. [ 408729009 | finding context | = 410516002 | known absent                                                 ]), the Act.effectiveTime refers to the point in time or period or time during which the focus concept was known to be absent
#* Similarly, if the [ 408730004 | procedure context ] has a negative value such as [ 3385660001 | not done ] the Act.effectiveTime                                                 refers to the point in time or period or time during which the focus concept was not done.
#** For example, the Act.effectiveTime for [ 165139002 | endoscopy not carried out ] represents the time at which, or period during                                                       which, an endoscopy was not done.
#*
#
# If the SNOMED CT expression in an Act class instance specifies [ 408731000 | temporal context | = ([ 410584005 | current -                                           specified |) OR ( 410587003 | past - specified )]:
#* the Act.effectiveTime attribute SHALL be present and its value SHALL be interpreted as the clinically relevant point or period                                                 in time at which the focus concept applied or is intended to apply.
#
# If the SNOMED CT expression in an Act class instance does not explicitly specify [ 408731000 | temporal context ] or explicitly                                           specifies [ 408731000 | temporal context | = ( 410512000 | current or specified | ) OR ( 15240007 | current | ) OR ([ 410585006                                           | current - unspecified |)]:
#* the Act.effectiveTime attribute SHOULD be included and, if present, its value SHALL be interpreted as the clinically relevant                                                 point in time or period during which the associated finding procedure applied or is intended to apply.
#** If the Act.effectiveTime represents a period of time with an upper bound either set in the future or omitted, this indicates                                                       that the focus concept continues (or is expected to continue) to apply beyond the time when it was recorded.
#*
#* If the Act.effectiveTime attribute is omitted (or contains a null flavor), the Participation.time value stated for a performer                                                 MAY be regarded as an approximation to the clinically relevant time.
#
# If the SNOMED CT expression in an Act class explicitly specifies [ 408731000 | temporal context = ((410513005 | past |) OR                                           ( 6493001 | recent |))]:
#* the Act.effectiveTime attribute MAY be included and, if present, its value SHALL be interpreted as the clinically relevant                                                 point or period in time to which the focus concept applied or is intended to apply.
#* the Participation.time value stated for an author SHALL be regarded as the time at which it was asserted that this procedure                                                 or observation was carried out in the past.
#
# If the SNOMED CT expression in an Act class instance explicitly specifies [ 408731000 | temporal context | = 410588008 | past                                           - unspecified ]:
#* the Act.effectiveTime attribute SHALL NOT be included as this would contradict the asserted [ 408731000 | temporal context                                                 ].
#* the Participation.time value stated for an author SHALL be interpreted as the time at which it was asserted that this procedure                                                 or observation was carried out in the past.
#
# If the SNOMED CT expression in an Act class explicitly specifies [ 408731000 | temporal context | = 410589000 | all times                                           past ]:
#* the Act.effectiveTime attribute SHOULD NOT be included but, if present, it SHALL only specify the upper bound of a period                                                 of time.
#** Note: The [ 408731000 | temporal context | = 410589000 | all times past ] is used with [ 408729009 | finding context | =                                                       410516002 | known absent ] to assert a negative past history or a negative family history (e.g. [ 266882009 | no family history                                                       or ischemic heart disease ]). Negative assertions of this type imply that at [ 410589000 | all times past ] the focus concept                                                       did not apply. It is reasonable to combine this with the upper bound of a period of time, as the finding may be true at some                                                       future point in time (e.g. the patient may now be diagnosed as having asthma, although they have no past history of asthma).                                                       However, it would be contradictory to specify a point in time value or a lower bound for a period of time.
#*
#* the Participation.time value stated for an author SHALL be interpreted as the time at which it was asserted that at all times                                                 past this Observation applied.
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.2.13.3
</div> 
<div  class="body"> 
In most cases, following the general rules specified by the HL7 RIM allow unequivocal interpretation of the meaning of the
Act.effectiveTime and associated Participation.time values. However, there are several possible interpretations of Act.effectiveTime,
in relation to a SNOMED CT expression which includes an explicit past history temporal context (i.e. [ 408731000 | temporal
context &lt;&lt; 410513005 | past ]). Therefore, the rules specified above require that the relative time as specified by the SNOMED
CT [ 408731000 | temporal context ] and any specific point or period of time expressed in Act.effectiveTime should be consistent
with one another. The rules do not permit the effectiveTime and [ 408731000 | temporal context ] to be interpreted in a combinatorially
manner. Thus if the [ 408731000 | temporal context | = 410513005 | past ] the Act.effectiveTime, if stated, must be the point
or period in the past when the finding applied.

 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 2.3
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.1
</div> 
<div  class="body"> 
Constrained information models specified by some Domain committees use an ActRelationship to allow one Observation to qualify
the meaning of another Observation. For example, to specify the severity of an abnormal observation.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.1.1
</div> 
<div  class="body"> 
SNOMED CT includes qualifiers that allow refinement of meaning using post-coordinated expressions. As a result, the use of
an additional Observation class is unnecessary and introduces alternative ways to represent the same meaning.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.1.2
</div> 
<div  class="body"> 
The following rules are specified to simplify interpretation by minimizing unnecessary variability in representation.

 
# A constrained information model or template that permits use of SNOMED CT as one of the permitted ways to represent the result                                           of an Observation, MAY include related Observation classes included to permit qualification of the meaning of an Observation                                           but inclusion of these qualifying class SHALL NOT be required.
# A constrained information model or template that requires use of SNOMED CT to represent the result of an Observation SHALL                                           NOT include any related Observation classes included to permit qualification of the meaning of an Observation.
# An Observation class instance in which the Observation.value is represented by a SNOMED CT expression SHALL NOT include any                                           related qualifying classes but SHOULD encode the relevant qualifications as part of the expression.
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.1.3
</div> 
<div  class="body"> 
It is important to reduce the scope for unnecessary alternative representation of the same information. Tight coupling of
the qualification to the primary result of the observation is likely to reduce the risk of misinterpretation.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.2
</div> 
<div  class="body"> 
In the HL7 clinical statement model the ActRelationship class is used to express links or associations between different clinical
statements. These linkages may be of different types expressed using the typeCode attribute. Examples of typeCode values include
"contains", "pertain to", "caused by", and "reason for".

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.2.1
</div> 
<div  class="body"> 
SNOMED CT provides a variety of attributes that can be used to represent relationships between different concepts in a post-coordinated
expression. These post-coordinated expressions have the potential to represent some association that might alternatively be
represented using ActRelationships. For example, the attributes [ 42752001 | due to ] could be used to construct expressions
such as [ 49218002 | hip pain |: 42752001 | due to | = 
396275006 | osteoarthritis ], which could also be represented using two separate Observations linked by an ActRelationship
with the typeCode "caused by".

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.2.2
</div> 
<div  class="body"> 
There is no absolute rule about when to express linkage in the terminology and when to use linkage mechanisms in the RIM (e.g.
ActRelationships). However, the following guidance should be followed:

 
* A single identifiable observation, assertion or procedure SHOULD usually be represented by a single Act class instance containing                                           an appropriate SNOMED CT expression.
* A single Act class instance SHOULD be used to represent an integral combination of facets applicable to a single identifiably                                           observation, assertion or procedure. Some examples of integral combination are shown below. The common feature of these is                                           that together they represent a finding with a distinct pattern and a shared life history.
** A combination of findings is a part of a single recognizable condition
*** E.g. "Headache preceded by visual disturbance".
**
*
** A disorder is specialized by a specific cause
*** E.g. "Pneumonia due to streptococcus pneumoniae".
**
*
** The nature of a disorder is determined by another condition
*** E.g. [ 4855003 | diabetic retinopathy ].
**
*
** A temporal or causative relationship between two concepts in which one is a specific symptom or diagnostic criterion for the                                                 other.
*** E.g. [ 51771007 | postviral fatigue syndrome ], "Shortness of breath after moderate exercise".
**
*
** A single recognized procedure involves two or more distinct but related actions:
*** E.g. [86477000 | total hysterectomy with removal of both tubes and ovaries ], "Reduction and fixation of a fracture"
**
*
* Post-coordinated SNOMED CT expressions SHOULD NOT be used to artificially combine distinct observations, assertions and procedures                                           into a single Act class instance.
** The line between integral combinations of items and distinct items is not clear-cut. However, as a general rule two items                                                 SHOULD be considered to be distinct if
*** they are capable of being independently validated (i.e. the accuracy of one statement is not dependent on the accuracy of                                                       the other)
*** their life histories differ and are independent of one another
*** the relationship between them is a matter of judgment rather than fact
**
*
* Distinct observations, assertions and procedures SHOULD be  represented by separate Act class instances related to one another                                           by appropriate ActRelationships.
** Multiple distinct findings in a patient that may or may not be associated with one another or with some more general problem.
*** E.g. A collection such as "chest pain" with "shortness of breath" finding of "tachycardia" and "ECG abnormality" interpreted                                                       as "Myocardial infarction".
**
*
** Multiple conditions occur contemporaneously (or in sequence) where the nature of individual conditions is specific to the                                                 presence of the other condition.
*** E.g. "AIDS" and "gastro-enteritis"
**
*
** Multiple distinct procedures incidentally performed at the same time or during the same hospital stay.
*
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.3.2.3
</div> 
<div  class="body"> 
In general SNOMED CT expressions (whether pre-coordinated or post-coordinated) are most appropriate for expressing multiple
facets of a single logical concept. On the other hand, HL7 ActRelationships are more appropriate for making associations between
multiple distinct observations or procedures. However, this boundary is fuzzy and there are many situations in which either
approach may have equal merit.

 
The use of SNOMED CT attributes may result in arbitrarily complex statements that wrap multiple distinct findings within a
single terminological expression. In these cases, the use of separate coded statements linked by Act Relationships is preferable.
On the other hand, use of multiple statements linked by ActRelationships to represent a single composite finding or procedure
may result in loss of the natural clinical term used by a clinician within a collection or linked classes.

 
Even when the guidelines above are followed, there will be grey areas. In an ideal world rule would be devised to compute
equivalence between single Act class instances containing a post-coordinated SNOMED CT expressions and multiple Act class
instances. While this is theoretically possible, there are several practical obstacles. The HL7 vocabulary for the ActRelationship.typeCode
attribute differs from the range of values for linkage attributes in SNOMED CT. Simple precise or close mappings exist for
some values but more work is needed before we can assert full semantic interoperability between the two representations. In
addition, while a single instance post-coordinated representation has a single life-history the individual instances in multiple
class representation may have separate life histories and separate associations with other contextual information.

 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 2.4
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.1
</div> 
<div  class="body"> 
The HL7 participation type &#8220;subject&#8221; relates a finding or procedure to a subject who may or may not be the subject of the
record. This allows specific named individuals to be identified as the subject of an Act. It can also be used to associate
a related person by specifying their relationship rather than by identifying them. For example [ 303071001 | person in the
family ], [ 72705000 | mother], [ 70862002 | contact person], etc.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.1.1
</div> 
<div  class="body"> 
The SNOMED CT [ 408732007 | subject relationship context ] attribute provides a mechanism for indicating that the subject
of a procedure or finding is a person (or other entity) related to the subject of the record. This facility is used to define
some SNOMED CT concepts (e.g. "family history of asthma" has [ 408732007 | subject relationship context ] = [ 303071001 |
person in the family ]). The same attribute can also be used to create post-coordinated expressions. For example, it can be
used to express a family history of a disorder without requiring the a concept that expresses a family history of that particular
disorder. Unlike the HL7 "subject" participation, the SNOMED CT mechanism does not directly support reference to an identified
person.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.1.2
</div> 
<div  class="body"> 
The following rules are specified to encourage explicit recording of the [ 408732007 | subject relationship context ] in order
to minimize risks of overlooking this aspect of the information.

 
# When using SNOMED CT to represent an observation or procedure that applies to a subject other than the record target, the                                           appropriate [ 408732007 | subject relationship context ] SHOULD be specified in the SNOMED CT expression.
#* For example "family history" should be represented using an expression that specifies the [ 408732007 | subject relationship                                                 context ] as [ 303071001 | person in the family ].
#
# The HL7 subject participation MAY also be used and SHALL be used if there is a requirement to specifically identify an individual                                           subject.
# If the HL7 subject participation is used in addition to the SNOMED CT representation of [ 408732007 | subject relationship                                           context ], the Role.code of the role that is the target of the subject SHOULD be represented using SNOMED CT with the value                                           applied to the [ 408732007 | subject relationship context ] or with a subtype of that value.
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.1.3
</div> 
<div  class="body"> 
These recommendations leave some situations in which either approach may be used. Therefore, to compute equivalence, a map
between the values used in the code attribute of the associated subject role is required. The simplest option would be to
specify that when the classCode attribute of the HL7 Role specifies "personal relationship" the code attribute should have
a value from the SNOMED CT [ 408732007 | subject relationship context ] hierarchy.

 
Ambiguity may be introduced if the information is coded using a concept with explicit [ 408732007 | subject relationship context
] and also has an association to a specific subject. For example, if the concept [ 160303001 | FH: diabetes mellitus ] is
stated in an observation linked to a person other than the subject of the record, this could mean either (a) "the patient
has a family history of diabetes, in the named family member" or (b) "the identified subject has a family history of diabetes".

 
Specific recommendations on this should be included in communication specifications. Where a communication pertains to an
individual patient interpretation (a) is recommended. However, specific instances of the subject participation in a communication
about a group of patients may need to specify interpretation (b).

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.2
</div> 
<div  class="body"> 
The HL7 participation type &#8220;specimen&#8221; relates an observation to the specimen on which an observation was made (or is to be
made). The specimen participation allows type of specimen or an actual identifiable specimen to be specified.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.2.1
</div> 
<div  class="body"> 
Some SNOMED CT [ &lt;&lt;386053000 | evaluation procedure ] and [ &lt;&lt;363787002 | observable entity ] concepts indicate the type of
specimen that is the subject of the measurement or observed property. Refinement is possible using the [ 116686009 | has specimen
] attribute to specify particular specimen types for any relevant procedure. Therefore, there is a potential overlap between
two approaches to representation of the nature of the specimen.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.2.2
</div> 
<div  class="body"> 
# When using SNOMED CT to record an observation that applies to a specimen the nature of the specimen MAY be expressed separately                                           using the Entity.code of the entity playing the role that is the target of the specimen participation
#* This type of representation may be appropriate in cases where it is also necessary to identify the specimen and where a single                                                 specimen is the subject of multiple different observations.
#* When using this form of representation:
#** The type of specimen SHOULD be expressed using an appropriate SNOMED CT concept in the Entity.code attribute.
#** If the SNOMED CT expression used in Observation.code specifies a value for the [ 116686009 | has specimen ] attribute, the                                                       value of this attribute SHALL be either the same as or less specific than the value used in the Entity.code.
#*
#
# Alternatively, a specific SNOMED CT concept or expression MAY be used to specify the nature of the observation including the                                           type of specimen.
#* This form MAY be appropriate to simple recording of result in a clinical record but does not allow the specific instance of                                                 the specimen to be identified.
#
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.2.3
</div> 
<div  class="body"> 
The recommendations on representation of specimen take account of the current incomplete set of investigation codes available.
Recent experience in the UK suggests that the first approach above, using the Entity.code is a more flexible basis for requesting
and reporting laboratory investigation using SNOMED CT.

 
The guidance on use of SNOMED CT in the Entity.code attribute is intended to avoid conflicts or ambiguity that may result
from representing the values of [ 116686009 | has specimen ] and Entity.code using different coding systems.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.3
</div> 
<div  class="body"> 
The HL7 ''product'' Participation associates a specified material (via an appropriate Role) with the instance of the Supply class instance that
delivers this material to a subject. Similarly the "consumable" associates a specified material (via an appropriate Role)
with the instance of the SubstanceAdministration class instance that delivers this material to a subject. In both these cases,
the relevant Act class instance itself only needs to specify the action involved and does not need to indicate the nature
of the material supplied or administered.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.3.1
</div> 
<div  class="body"> 
In SNOMED CT concepts that are subtypes of [ 432102000 | administration of therapeutic substance] can also specify the nature
of the substance administered. Refinement of any particular type of administration is possible by applying values to the
"direct substance" attribute to represent administration of any pharmaceutical product. Therefore, there is a potential overlap
between two approaches to representation of the nature of the substance administered.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.3.2
</div> 
<div  class="body"> 
# When using SNOMED CT to communicate about the supply or administration of a substance the nature of the substance SHOULD be                                           specified in the Entity.code of the Entity associated with the Role that is the target of the relevant ''product'' or ''consumable'' Participation. When using this form of representation:
#* the Act.code of the SubstanceAdministration class instance SHOULD be coded using a SNOMED CT concept that is a subtype of                                                 [ &lt;&lt;432102000 | administration of therapeutic substance ], but which does not specify a [ 363701004 | direct substance ].
#* the nature of the substance administered SHOULD be expressed using an appropriate SNOMED CT concept in the Entity.code attribute                                                 of Entity playing the Role that is the target of the relevant participation.                                                 <blockquote>Example: SubstanceAdministration.code= [ 36673005 | intradermal injection ] with associated Entity (via a ''consumable'' Participation and an appropriate ''Role''), in which Entity.code=[ &lt;&lt;82573000 | lidocaine ] OR                                                 </blockquote>
#
# When using SNOMED CT to summarize information about a particular type of medication (e.g. use of a local anesthetic during                                           a procedure), a SNOMED CT expression that includes information about the nature of the substance administered MAY be used.                                           However, this form SHOULD NOT be used for communicating about the prescription, supply or personal administration of medication.                                           <blockquote>Example: SubstanceAdministration.code=[ 36673005 | intradermal injection | 363701004 | direct substance | &lt;&lt; 82573000 | lidocaine                                              ]                                           </blockquote>
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.4.3.3
</div> 
<div  class="body"> 
The first approach follows the form recommended by the Pharmacy TC and endorsed by the Clinical Statement pattern and other
domain committees. The alternative approach may be relevant for summary notes related to certain types of treatment but is
not appropriate for prescribing or medication management as it does not provide a reference to a specific quantifiable amount
of the substances administered nor does it allow reference to batch numbers and detailed product information.

 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 2.5
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.5.1
</div> 
<div  class="body"> 
HL7 Version 3 includes specific attributes, which indicate whether context propagates across Participation and ActRelationship
associations. The rules associated with these attributes determine whether the target Act of an ActRelationship shares the
participations and other contextual attributes of the source Act and whether these can be substituted by alternative explicit
values within the target Act.

 
<div  class="subSubSubSection"> 
<div  class="header"> 2.5.1.1
</div> 
<div  class="body"> 
Propagation of context is valuable and in some cases almost essential, as it reduces the need to duplicate contextual information.
However, it is not entirely clear whether and if so how this propagation of context applies to coded information in each Act
instance. Safe interpretation of clinical information requires a common understanding of where contextual information represented
using SNOMED CT if either Act.code or Observation.value propagates to related Acts based on the context propagation rules.
For example, several Observations coded using SNOMED CT disorder concepts might be related as component parts of an Organizer
labeled with the SNOMED CT code "family history of disorder". If the coded context propagated it might seem to express a family
history, if not these might be part of the personal medical history of the subject of record.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.5.1.2
</div> 
<div  class="body"> 
The following rules are specified to minimize the risk of ambiguity due to loss of contextual information.

 
# SNOMED CT contextual information SHOULD NOT be assumed to propagate between Acts and SHOULD therefore be restated in each                                           expression.
#* For example, each SNOMED CT expression in a collection of statements representing family history, SHOULD represent the relevant                                                 [ 408732007 | subject relationship context ]. This context SHOULD NOT be assumed to propagate from an Organizer (or other                                                 containing Act) to its constituent Observations or from one Observation to another.
#
# In specific cases where there is clear advantage is allowing specific aspects of SNOMED CT context to conduct, this behavior                                           SHALL be explicitly documented in a manner that ensures reproducible interpretation.
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 2.5.1.3
</div> 
<div  class="body"> 
It is not clear how context conduction is intended to apply to contextual information that is represented in concepts within
an Act. If this type of context is assumed to propagate it would mean that the meaning of a single Observation might be fundamentally
altered by a related Act (or potentially by a chain of several different related Acts). This type of dependency presents significant
risks, since different systems may be unable to reproducibly determine the composite meaning. Therefore, it seems safest to
recommend restatement of the essential aspects of context as defined by the SNOMED CT context model rather than permitting
this context to conduct.

 
There may be some specific cases, where a tightly coupled set of Acts are expected to behave as a block with regard to the
surrounding context and where some or all aspects of context represented using SNOMED CT also need to be conducted. In these
cases the potential for misinterpretation needs to be considered and appropriately documented.

 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSection"> 
<div  class="header"> 3
</div> 
<div  class="body"> 
<div  class="subSubSection"> 
<div  class="header"> 3.1
</div> 
<div  class="body"> 
Common patterns are clinical statements that are used frequently, often in many different specifications, 
for a wide variety of communication use cases. The patterns shown here are based upon the Principles 
and Guidelines defined above, and represent informative examples, unless otherwise stated. 
			 [[[8]]]

 
'''NOTE: '''The approach taken in the development of these patterns is to build upon the modeling work being done within HL7 domain committees.

In many cases, the patterns presented here are small subsets of more complete domain models, often greatly simplified so as
to illustrate certain principles. 
Actual instances must conform to the particular HL7 V3 specification being communicated.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.1
</div> 
<div  class="body"> 
The RIM defines the abstract ActClass "ActClassRecordOrganizer" as a navigational structure or heading used to group a set
of acts sharing a common context. Record organizers include 
					such structures as folders, documents, document sections, and batteries. The Clinical Statement model includes an Organizer
class, whose class code can be valued with 
					an ActClassRecordOrganizer subtype. Where the Organizer class is used, the value of Organizer.code '''MAY''' be drawn from the 
					SNOMED CT [ (&lt;&lt;419891008 | Record artifact | ) OR (&lt;&lt;386053000 | Evaluation procedure | ) ] hierarchies. [[[9]]]					
					.

 
It is often the case that there is a close correspondence between a particular kind of clinical statement (e.g. a blood pressure
reading) and the organizer where the clinical statement is commonly found (e.g. a vital signs section). The patterns presented
here are irrespective of and not dependent on the organizer in which they are found. Thus, the pattern for allergies and adverse
reactions should be used regardless of any organizers they may or may not be contained in; and any distinction between a finding
vs. disorder vs. diagnosis needs to be made explicit in the clinical statement itself, without reliance on the containing
organizer. Stated in another way, a clinical statement needs to be a correct assertion by itself, when viewed outside the
organizer. [[[10]]]

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.2
</div> 
<div  class="body"> 
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".
 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.2.1
</div> 
<div  class="body"> 
Based on these guiding principles come the following acceptable patterns:

 
'''PATTERN ONE: '''Observation.code [ (&lt;&lt;363787002 | Observable entity) OR (&lt;&lt;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.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.2.1.1
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="50373000|Height|" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Height"/&gt;
  &lt;/code&gt;
  &lt;text&gt;Height: 177 cm&lt;/text&gt;
  &lt;value xsi:type="PQ" value="1.77" unit="m"/&gt;
&lt;/observation&gt;

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

</pre>

</div> 
</div> 
"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 [ (&lt;&lt;413350009 | Finding with explicit context) OR (&lt;&lt;404684003 | Clinical finding) ] .

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.2.1.2
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" 
    codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Headache&lt;/text&gt;
  &lt;value xsi:type="CD" code="25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Headache"/&gt;
  &lt;/value&gt;
&lt;/observation&gt;	

</pre>

</div> 
</div> 
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.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.2.1.3
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Presence of headache&lt;/text&gt;
  &lt;value xsi:type="CD" code="373573001|Clinical finding present|:246090004|Associated finding|=25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"/&gt;
&lt;/observation&gt;	

</pre>

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

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3
</div> 
<div  class="body"> 
Another recurring issue for many clinical statements is the representation of how the information in that statement was
obtained (e.g. patient-reported symptom, gleaned from chart review, physical exam finding). Whether or not the source of information
needs to be included in a particular communication is outside the scope of this guide, but in some cases, such as the recording
of patient medications, knowing the source of the information can have significant clinical implications, and since there
are overlaps in HL7 and SNOMED CT representations, the topic is addressed in this guide.

 
Common sources include: [1] Previously recorded information (e.g. a patient-authored questionnaire, a problem list entry,
a lab report); [2] Informant (e.g. the patient, a witness); [3] Direct examination (e.g. a physical examination finding, a
radiographic finding, an automated specimen analysis).

 
Various ways by which the source of information can be represented include:

 
*                                     SNOMED CT defining attributes (whether pre- or post-coordinated)
** [ 418775008 | Finding method ]: Used to indicate the method by which a finding was ascertained.
*
** [ 419066007 | Finding informer ]: Used to indicate the informant of a finding.
*
** [ 260686004 | Procedure method ]: Used to indicate the method by which a procedure is performed.
*
** [ 370129005 | Measurement method ]: Used to indicate the method by which an observable entity or evaluation procedure is performed.
*
* RIM attributes
** Procedure.methodCode: Identifies the means or technique used to perform the procedure.
*
** Observation.methodCode: A code that provides additional detail about the means or technique used to ascertain the observation.
*
* RIM participants
** Informant (INF): A source of reported information.
*
* RIM act relationships
** Excerpt (XCRPT): The source is an excerpt from the target.
*
** Verbatim excerpt (VRXCRPT): The source is a direct quote from the target.
*
 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3.1
</div> 
<div  class="body"> 
Patterns for the common sources listed above include:

 
'''PATTERN ONE:''' Source is previously recorded information.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3.1.1
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;id root="3568dbe1-8f49-11da-a72b-0800200c9a66"/&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Headache, per problem list&lt;/text&gt;
  &lt;value xsi:type="CD" code=" 25064002|Headache|"  codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Headache"/&gt;
  &lt;/value&gt;
  &lt;actRelationship typeCode="XCRPT" 
    contextConductionInd="false"&gt;
    &lt;actReference classCode="OBS" moodCode="EVN"&gt;
      &lt;id root="201877f1-8f49-11da-a72b-0800200c9a66"/&gt;
    &lt;/actReference&gt;
  &lt;/actRelationship&gt;
&lt;/observation&gt;	

</pre>

</div> 
</div> 
This pattern uses an actRelationshipType of "XCRPT" to indicate that there is a new observation which represents an excerpt
of previously recorded information. The ActReference class is used here as the target, but other clinical statement act choices
could also be used. Context conduction to the ActReference class is blocked by setting contextConductionInd to "false".

 
'''
PATTERN TWO: Source is informant.'''

 
The distinction between the excerpt relationship in the prior figure and an informant participant discussed here can be blurry,
such as when a clinician is drawing upon the patient's recollection and a prior record of medication use to determine the
current medication usage. An informant (or source of information) is a person who provides relevant information, whereas an
excerpt is a sub portion of some other act.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3.1.2
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Father says that the patient has a headache.&lt;/text&gt;
  &lt;value xsi:type="CD" code="25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Headache"/&gt;
  &lt;/value&gt;
  &lt;informant typeCode="INF"&gt;
    &lt;relatedEntity classCode="PRS"&gt;
      &lt;code code="66839005|Father|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName value="Father"/&gt;
      &lt;/code&gt;
    &lt;/relatedEntity&gt;
  &lt;/informant&gt;
&lt;/observation&gt;

&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Father says that the patient has a headache.&lt;/text&gt;
  &lt;value xsi:type="CD" code="25064002|Headache|:419066007|Finding informer|=66839005|Father|" codeSystem="2.16.840.1.113883.6.96"/&gt;
&lt;/observation&gt;
</pre>

</div> 
</div> 
The first example uses an Informant participant to indicate that the observation is gleaned through the record subject's father,
and the second example expresses the same thing using the finding informer attribute in a post-coordinated expression.

 
The first example is particularly useful where there is a need to identify or provide additional specifics about the informant
participant. Where both informant participant and finding informer are present, the former should be the same as or a specialization
of the latter.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3.1.3
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Patient states he has a headache&lt;/text&gt;
  &lt;value xsi:type="CD" code="25064002|Heachache|:419066007|Finding informer|=116154003|Patient|" codeSystem="2.16.840.1.113883.6.96"/&gt;
&lt;/observation&gt;	

</pre>

</div> 
</div> 
This example shows the use of the finding informer attribute to indicate that the patient is the source of the information.

It will commonly be the case that a V3 instance will assert an informant participant, which will propagate to nested observations.
Therefore it won't often be necessary to directly assert a finding informer of patient.

 
'''PATTERN THREE:''' Source is direct examination.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3.1.4
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="77989009|Measurement of skin fold thickness|:370129005|Measurement method|=5880005|Physical exam|" codeSystem="2.16.840.1.113883.6.96"/&gt;
  &lt;text&gt;Skin fold thickness is 7cm&lt;/text&gt;
  &lt;value xsi:type="PQ" value="7" unit="cm"/&gt;
&lt;/observation&gt;
</pre>

</div> 
</div> 
This pattern uses the SNOMED CT measurement method attribute to qualify a measurement procedure concept, indicating that
the observation was determined via physical exam.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.1.3.1.5
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;  
  &lt;text&gt;Hilar mass on chest CT&lt;/text&gt;
  &lt;value xsi:type="CD" code="309530007|Hilar mass|:418775008|Finding method|=169069000|CT chest|" codeSystem="2.16.840.1.113883.6.96"/&gt;
  &lt;actRelationship typeCode="SUBJ" contextConductionInd="false"&gt;
    &lt;observation classCode="DGIMG" moodCode="EVN"&gt;
    &lt;id root="9cc8b460-8f47-11da-a72b-0800200c9a66"/&gt;
      &lt;code code="169069000|CT chest|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName value="CT chest"/&gt;
      &lt;/code&gt;
    &lt;/observation&gt;
  &lt;/actRelationship&gt;
&lt;/observation&gt;	

</pre>

</div> 
</div> 
This pattern uses the SNOMED CT finding method attribute to qualify a finding concept, indicating that the finding was determined
via CT chest. To relate the finding to the actual CT scan being observed, the example uses an act relationship of type "SUBJ",
with blocked context conduction.

 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 3.2
</div> 
<div  class="body"> 
Both SNOMED CT and HL7 differentiate an isolated reaction event from the condition of being allergic or intolerant. For
instance, the following hierarchy is present in SNOMED CT (Jan 2007 release):

 
* [ 404684003 | Clinical finding ]
** [ 420134006 | Propensity to adverse reactions ]
*** [ 106190000 | Allergy ]
**** [ 416098002 | Drug allergy ]
***
**
*
** [ 281647001 | Adverse reaction ]
*** [ 416093006 | Allergic reaction to drug ]
**
*
 
Different SNOMED CT value sets may apply, depending on the application context. Potential value sets include:

 
* '''Substance/Product value set: ''' [[[11]]] Values drawn from [ 105590001 | Substance ] and/or [ 373873005 | Pharmaceutical / Biologic product ] hierarchies, might be                               used where the context is the recording of substances to which the patient is allergic (e.g. a data entry box labeled "ALLERGIES"). [[[12]]]
* '''Findings value set: '''					                               Values drawn from [ 413350009 | Finding with explicit context ] and/or [ 404684003 | Clinical finding ] hierarchies, might                               be used where the context is an encounter diagnosis or a problem list.
 
'''NOTE: '''The HL7 Patient Care Technical Committee is developing a formal model for allergy tracking, which supports the representation
of the sequential determination of primary and secondary observations relating to discovery and analysis of adverse reactions.
The examples provided here are greatly simplified so as to illustrate certain aspects of SNOMED CT implementation.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.2.1
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Allergy to PCN manifesting as hives&lt;/text&gt;
  &lt;value xsi:type="CD" code="106190000|Allergy|:246075003|Causitive agent|=373270004|Penicillin - class of antibiotic - (substance)" codeSystem="2.16.840.1.113883.6.96"/&gt;
  &lt;actRelationship typeCode="MFST" inversionInd="true" contextConductionInd="true"&gt;
    &lt;observation classCode="OBS" moodCode="EVN"&gt;
      &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
      &lt;value xsi:type="CD" code="247472004|Hives|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName value="Hives"/&gt;
      &lt;/value&gt;
    &lt;/observation&gt;
  &lt;/actRelationship&gt;
&lt;/observation&gt;

</pre>

</div> 
</div> 
Where the clinician fills in both the substance/product and the reaction, context can propagate across the MFST relationship.
The manifestation should not be post-coordinated with the allergic disorder (i.e. this guide recommends against a single post-coordinated
expression such as "penicillin allergy manifesting as hives").

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.2.2
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;value xsi:type="CD" code="91936005|Allergy to penicillin|" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Allergy to penicillin"/&gt;
  &lt;/value&gt;
  &lt;text&gt;Allergy to PCN&lt;/text&gt;
&lt;/observation&gt;	

</pre>

</div> 
</div> 
In this case, the selected finding indicates the condition of being allergic.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 3.3
</div> 
<div  class="body"> 
An assessment scale is a collection of observations that together yield a summary evaluation of a particular condition. Examples
include the Braden Scale (used for assessing pressure ulcer risk), APACHE Score (used for estimating mortality in critically
ill patients), Mini-Mental Status Exam (used to assess cognitive function), APGAR Score (used to assess the health of a newborn),
and Glasgow Coma Scale (used for assessment of coma and impaired consciousness.)

 
Assessment scales share certain features, which are described here as part of a recommended pattern:

 
# Assessment scales have one or more component observations that can be taken in aggregate to provide an overall score (e.g.                               [ 248241002 | Glasgow Coma score ]).
# Assessment scale component observations can be represented as a question and answer (e.g. [ 248240001 | Motor response ] =                               "3") or as a finding (e.g. [ 85157005 | Decorticate posture ]). Either or both of these representations may need to be communicated,                               depending on the use case.
 
The following Figure shows a sample Glasgow Coma Scale and result. A score is given for each of three types of neurological
responses. A Coma Score of 13 or higher indicates a mild brain injury, 9 to 12 is a moderate injury and 8 or less a severe
brain injury.

                                                                                                
{| border="1"
|+Glasgow Coma Scale
|-
!Glasgow Coma Scale
                                 							
                              
!Value
!Score
|-
!Eye Opening
|-
|spontaneous
|4
| 
|-
|to speech
|3
| 
|-
|to pain
|2
|2
|-
|no response
|1
| 
|-
!Motor Response
|-
|obeys verbal command
|6
| 
|-
|localizes pain
|5
| 
|-
|flexion-withdrawal
|4
| 
|-
|flexion-abnormal
|3
|3
|-
|extension
|2
| 
|-
|no response
|1
| 
|-
!Verbal Response
|-
|oriented and converses
|5
| 
|-
|disoriented and converses
|4
| 
|-
|inappropriate words
|3
| 
|-
|incomprehensible sounds
|2
|2
|-
|no response
|1
| 
|-
!Glasgow Coma Score
!7
|}  
<div  class="subSubSubSection"> 
<div  class="header"> 3.3.1
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt; 
  &lt;code code="248241002|Glasgow coma score" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Glasgow coma score"/&gt; 
  &lt;/code&gt;
  &lt;derivationExpr/&gt; 
  &lt;value xsi:type="INT" value="7"/&gt; 
  &lt;actRelationship typeCode="DRIV"&gt; 
    &lt;observation classCode="OBS" moodCode="EVN"&gt; 
      &lt;code code="288598006|verbal response|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName value="verbal response"/&gt; 
      &lt;/code&gt;
      &lt;value xsi:type="INT" value="2"/&gt; 
    &lt;/observation&gt; 
  &lt;/actRelationship&gt; 
  &lt;actRelationship typeCode="DRIV"&gt; 
    &lt;observation classCode="OBS" moodCode="EVN"&gt; 
      &lt;code code="248240001|Motor Response|" codeSystem="2.16.840.1.113883.6.96"gt;
        &lt;displayName value="Motor Response"/&gt; 
	  &lt;/code&gt;
      &lt;value xsi:type="INT" value="3"/&gt; 
      &lt;actRelationship typeCode="XFRM"&gt; 
        &lt;observation classCode="OBS" moodCode="EVN"&gt; 
          &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
          &lt;value xsi:type="CD" code="85157005|Decorticate posture|" codeSystem="2.16.840.1.113883.6.96"&gt;
            &lt;displayName value="Decorticate posture"/&gt;
          &lt;/value&gt;
        &lt;/observation&gt; 
      &lt;/actRelationship&gt; 
    &lt;/observation&gt; 
  &lt;/actRelationship&gt; 
&lt;/observation&gt; 

</pre>

</div> 
</div> 
The aggregate observation is modeled as a component of the assessment procedure. The &lt;derivationExpr&gt; can contain a formal
language expression specifying how the value is computed. Component observations are nested under the aggregate observation,
linked with a "DRIV" (is derived from) relationship. Where a component observation needs to be communicated in different formats,
each format is a discrete observation, linked by a "XFRM" relationship.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 3.4
</div> 
<div  class="body"> 
'''NOTE: '''The HL7 Patient Care Technical Committee is developing a formal model for condition tracking. The examples provided here are
greatly simplified so as to illustrate certain aspects of SNOMED CT implementation.

 
Observations, Conditions, Diagnoses, and Concerns are often confused, but in fact have distinct definitions and patterns.

 
* "Observation" and "Condition": An HL7 observation is something noted and recorded as an isolated event, whereas an HL7 condition                               is an ongoing event. Symptoms and findings (also know as signs) are observations. The distinction between "seizure" and "epilepsy"                               or between "allergic reaction" and "allergy" is that the former is an observation, and the latter is a condition.<br>
<br>
SNOMED CT distinguishes between "Clinical Findings" and "Diseases", where a SNOMED CT disease is a kind of SNOMED CT clinical                               finding that is necessarily abnormal:<br>
<br>
** [ 404684003 | Clinical finding ]
*** [ 64572001 | Disease ]
**
* <br>
The SNOMED CT finding/disease distinction is orthogonal to the HL7 observation/condition distinction, thus a SNOMED CT finding                               or disease can be an HL7 observation or condition.<br>
<br>
*                               "Diagnosis": The term "diagnosis" has many clinical and administrative meanings in healthcare
** A diagnosis is the result of a cognitive process whereby signs, symptoms, test results, and other relevant data are evaluated                                     to determine the condition afflicting a patient.
*
** A diagnosis often directs administrative and clinical workflow, where for instance the assertion of an admission diagnosis                                     establishes care paths, order sets, etc.
*
** A diagnosis is often something that is billed for in a clinical encounter. In such a scenario, an application typically has                                     a defined context where the billable object gets entered. <br>
<br>
*
* "Concern": A concern is something that a clinician is particularly interested in and wants to track. It has important patient                               management use cases (e.g. health records often present the problem list or list of concerns as a way of summarizing a patient's                               medical history).
 
Differentiation of Observation, Condition, Diagnosis, and Concern in common patterns:

 
* "Observation" and "Condition": The distinction between an HL7 Observation and HL7 Condition is made by setting the Act.classCode                               to "OBS" or "COND", respectively. The distinction between a SNOMED finding and SNOMED disease is based on the location of                               the concept in the SNOMED CT hierarchy. There is no flag in a clinical statement instance for distinguishing between a SNOMED                               CT finding vs. disease.<br>
<br>
* "Diagnosis":
** Result of a cognitive process: Could potentially be Indicated by post-coordinating a SNOMED CT finding method attribute with                                     a procedure such as "cognitive process".
*
** Directs administrative and clinical workflow: These use cases typically rely more on the context in which the diagnoses are                                     entered (e.g. where an order set has a field designated for the admission diagnosis). In such a case, the distinction of a                                     (particular kind of) diagnosis is that it occurs within a particular organizer (e.g. a condition within an Admission Diagnosis                                     section is an admission diagnosis from an administrative perspective).
*** Something that is billed for: The fact that something was billed for would be expressed in another HL7 message. There is nothing                                           in the pattern for a diagnosis that says whether or not it was or can be billed for. <br>
<br>
**
*
* "Concern": The HL7 Patient Care Technical Committee is developing a formal model for condition tracking. In that model, a                               problem (which may be an Observation, a Procedure, or some other type of Act) is wrapped in an Act with a new Act.classCode                               &#8220;CONCERN&#8221;. The focus in this guide is on the use of SNOMED CT, whereas the Patient Care condition tracking model is the definitive                               source for the overall structure of a problem list.
 
It should be noted that the administrative representation of a diagnosis and the representation of a concern break the rules
from section &#8206;3.1.1 Observations vs. Organizers, in that these designations are based on context, whereas the designation
of something as an Observation vs. Condition is inherent in the clinical statement itself.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.4.1
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Headache&lt;/text&gt;
  &lt;value xsi:type="CD" code="25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Headache"/&gt;
  &lt;/value&gt;
&lt;/observation&gt;

</pre>

</div> 
</div> 
The observation is asserting a clinical finding of "headache".

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.4.2
</div> 
<div  class="body">
<pre>
&lt;act classCode="DOCSECT" moodCode="EVN"&gt;
  &lt;code code="8646-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/&gt;
  &lt;title&gt;Hospital Admission Diagnosis&lt;/title&gt;
  &lt;text&gt;Hospital admission diagnosis of headache&lt;/text&gt;
  &lt;actRelationship typeCode="COMP"&gt;
    &lt;observation classCode="OBS" moodCode="EVN"&gt;
      &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
      &lt;value xsi:type="CD" code="25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName="Headache"/&gt;
      &lt;/value&gt;
    &lt;/observation&gt;
  &lt;/actRelationship&gt;
&lt;/act&gt;
</pre>

</div> 
</div> 
That a given diagnosis is, for instance, an Admission Diagnosis, can be asserted by wrapping the observation within a particular
organizer.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.4.3
</div> 
<div  class="body">
<pre>
&lt;act classCode="DOCSECT" moodCode="EVN"&gt;
  &lt;code code="11450-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/&gt;
  &lt;title&gt;Problem List&lt;/title&gt;
  &lt;text&gt;
    &lt;list&gt;
      &lt;item&gt;Headache&lt;/item&gt;
      &lt;item&gt;Osteoarthritis of knee&lt;/item&gt;
    &lt;/list&gt;
  &lt;/text&gt;
  &lt;actRelationship typeCode="COMP"&gt;  
    &lt;act classCode="CONCERN" moodCode="EVN"&gt;
      &lt;actRelationship typeCode="SUBJ"&gt;
        &lt;observation classCode="OBS" moodCode="EVN"&gt;
          &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
          &lt;value xsi:type="CD" code="25064002|Headache|" codeSystem="2.16.840.1.113883.6.96"&gt;
            &lt;displayName value="Headache"/&gt;
          &lt;/value&gt;
        &lt;/observation&gt; 
      &lt;/actRelationship&gt;
    &lt;/act&gt;
  &lt;/actRelationship&gt;
  &lt;actRelationship typeCode="COMP"&gt; 
    &lt;act classCode="CONCERN" moodCode="EVN"&gt;
      &lt;actRelationship typeCode="SUBJ"&gt;
        &lt;observation classCode="OBS" moodCode="EVN"&gt;
          &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
          &lt;value xsi:type="CD" code="239873007|Osteoarthritis of knee|" codeSystem="2.16.840.1.113883.6.96"&gt;
            &lt;displayName value="Osteoarthritis of knee"/&gt;
          &lt;/value&gt;
        &lt;/observation&gt;
      &lt;/actRelationship&gt;
    &lt;/act&gt;
  &lt;/actRelationship&gt;
&lt;/act&gt;
</pre>

</div> 
</div> 
That a given clinical statement is a part of a condition tracking structure can be asserted by containing the clinical statement
within the concern act, using the mechanism defined by the HL7 Patient Care Technical Committee, as shown here.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 3.5
</div> 
<div  class="body"> 
As noted above (see section 2.2.5 Participations), the HL7 "subject" participant overlaps in meaning with the SNOMED CT
Subject Relationship Context.

 
Where a family member has a condition, regardless of whether the observation code contains an explicit Subject Relationship
Context, the subject of the observation is the family member, and not the patient. Where the observation code does include
an explicit Subject Relationship Context, the subject participant can also be used where needed to provide further information
about the subject.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.5.1
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Family history of cancer in father&lt;/text&gt;
  &lt;value xsi:type="CD" code="275937001|Family history of cancer|:408732007|Subject relationship context|=9947008|Biological father|" codeSystem="2.16.840.1.113883.6.96"/&gt;
&lt;/observation&gt;

</pre>

</div> 
</div> 
This observation uses an explicit SNOMED CT Subject relationship context attribute to represent the fact that the subject
of the observation is the father.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.5.2
</div> 
<div  class="body">
<pre>
&lt;observation classCode="OBS" moodCode="EVN"&gt;
  &lt;code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/&gt;
  &lt;text&gt;Family history of cancer in father&lt;/text&gt;
  &lt;value xsi:type="CD" code="363346000|Cancer|" codeSystem="2.16.840.1.113883.6.96"&gt;
    &lt;displayName value="Cancer"/&gt;
  &lt;/value&gt;
  &lt;subject typeCode="SBJ"&gt;
    &lt;relatedEntity classCode="PRS"&gt;
      &lt;code code="9947008|Biological father|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName="Biological father"/&gt;
      &lt;/code&gt;
    &lt;/relatedEntity&gt;
  &lt;/subject&gt;
&lt;/observation&gt;	

</pre>

</div> 
</div> 
This example is equivalent to the preceding example, using the subject participant rather than the SNOMED CT Subject relationship
context attribute to represent the fact that the subject of the observation is the father.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 3.6
</div> 
<div  class="body"> 
Areas of overlap between HL7 and SNOMED CT include the source of information, as described above (see 3.1.3 Source of information).
This is particularly important for medications, where one needs to differentiate what a patient is actually having administered
vs. what is being dispensed. The former is typically gleaned from the patient, family member, or the medication administration
record for an inpatient. The latter is often gleaned from a pharmacy application.

 
Another area of overlap between HL7 and SNOMED CT includes the method and route by which a substance is administered. Various
ways by which this information can be represented include:

 
* SNOMED CT defining attributes (whether pre- or post-coordinated)
** [ 260686004 | Procedure method ]: Used to indicate the method by which a procedure is performed.
** [ 410675002 | Route of administration ]: Used to indicate the route by which a substance is administered.
*
* RIM attributes
** SubstanceAdministration.code: A code further describing the type of administration.
** SubstanceAdministration.routeCode: The method of introducing the therapeutic material into or onto the subject.
*
 
The following patterns post-coordinate within SubstanceAdministration.code to represent the route of administration. Within
a particular realm, or as required by a particular implementation, there may also be a need to populate SubstanceAdministration.routeCode,
possibly with values drawn from a required and non-SNOMED CT value set.

 
The level of detail by which an administered substance is known can vary greatly, particularly when dealing with patient recollection.

				SNOMED CT has both a [ 105590001 | Substance ] hierarchy and a [ 373873005 | Pharmaceutical / Biologic Product ] hierarchy,
and may have realm-specific drug extensions that include manufacturer-specific product codes. Concepts from the Substance
hierarchy 
'''SHOULD NOT''' be used to code an administered substance.

 
In the following examples, the pharmacy is dispensing atenolol 50mg tablets with instructions to take one tablet per day,
whereas the patient's daughter says that only a half-tablet per day is being ingested.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.6.1
</div> 
<div  class="body">
<pre>
&lt;substanceAdministration classCode="SBADM" moodCode="INT"&gt;
  &lt;code code="432102000|Administration of therapeutic substance|:410675002|Route of administration|=26643006|Oral route|" codeSystem="2.16.840.1.113883.6.96"/&gt;
  &lt;text&gt;Atenolol 50mg tablet, take 1 per day&lt;/text&gt;
  &lt;effectiveTime xsi:type="PIVL_TS"&gt;
    &lt;period value="24" unit="h"/&gt;
  &lt;/effectiveTime&gt;
  &lt;doseQuantity value="1"/&gt;
  &lt;consumable typeCode="CSM"&gt;
    &lt;manufacturedProduct classCode="MANU"&gt;
      &lt;manufacturedLabeledDrug classCode="MMAT" determinerCode="KIND"&gt;
        &lt;code code="318420003|Atenolol 50mg tablet|" codeSystem="2.16.840.1.113883.6.96"&gt;
          &lt;displayName value="Atenolol 50mg tablet"/&gt;
        &lt;/code&gt;
      &lt;/manufacturedLabeledDrug&gt;
    &lt;/manufacturedProduct&gt;
  &lt;/consumable&gt;
  &lt;actRelationship typeCode="XCRPT" contextConductionInd="false"&gt;
    &lt;actReference classCode="SBADM" moodCode="EVN"&gt;
      &lt;id root="b3440e50-8f48-11da-a72b-0800200c9a66"/&gt;
    &lt;/actReference&gt;
  &lt;/actRelationship&gt;
&lt;/substanceAdministration&gt;
</pre>

</div> 
</div> 
This act represents an excerpt from a pharmacy application.

 
<div  class="subSubSubSection"> 
<div  class="header"> 3.6.2
</div> 
<div  class="body">
<pre>
&lt;substanceAdministration classCode="SBADM" moodCode="EVN"&gt;
  &lt;code code="432102000|Administration of therapeutic substance|:410675002|Route of administration|=26643006|Oral route|" codeSystem="2.16.840.1.113883.6.96"/&gt;
  &lt;text&gt;Atenolol 50mg tablet, taking 1/2 per day&lt;/text&gt;
  &lt;effectiveTime xsi:type="PIVL_TS"&gt;
    &lt;period value="24" unit="h"/&gt;
  &lt;/effectiveTime&gt;
  &lt;doseQuantity value="0.5"/&gt;
  &lt;consumable typeCode="CSM"&gt;
    &lt;manufacturedProduct classCode="MANU"&gt;
      &lt;manufacturedLabeledDrug classCode="MMAT" determinerCode="KIND"&gt;
        &lt;code code="318420003|Atenolol 50mg tablet|" codeSystem="2.16.840.1.113883.6.96"&gt;
          &lt;displayName value="Atenolol 50mg tablet"/&gt;
        &lt;/code&gt;
      &lt;/manufacturedLabeledDrug&gt;
    &lt;/manufacturedProduct&gt;
  &lt;/consumable&gt;
  &lt;informant typeCode="INF"&gt;
    &lt;relatedEntity classCode="PRS"&gt;
      &lt;code code="66089001|Daughter|" codeSystem="2.16.840.1.113883.6.96"&gt;
        &lt;displayName value="Daughter"/&gt;
      &lt;/code&gt;
    &lt;/relatedEntity&gt;
  &lt;/informant&gt;
&lt;/substanceAdministration&gt;

</pre>

</div> 
</div> 
This act represents information gleaned from the patient's daughter.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSection"> 
<div  class="header"> 4
</div> 
<div  class="body"> 
Every application has its own data entry screens, workflow, internal database design, and other nuances, and yet despite this,
we talk of semantic interoperability. In order to achieve interoperability, and enable a receiver to aggregate data coming
from any of a number of applications, it must be possible to compare data generated on any of these applications. In order
to compare data, it helps to imagine a canonical or normal form. If all data, regardless of how it was captured, can be converted
into a common form, it becomes possible to compare.

 
To that end, we differentiate the "model of use" from the "model of meaning", where the former represents the way in which
the data was captured, and the latter represents a common representation. All representations recommended in this guide can
be converted into a common model of meaning. This common model of meaning can be expressed in a SNOMED CT normal form and/or
a RIM Normal Form, thereby enabling data comparisons.

 
<div  class="subSubSection"> 
<div  class="header"> 4.1
</div> 
<div  class="body"> 
The text below is taken from the introduction to the document 'SNOMED CT Transformations to Normal Forms', and outlines the
purpose of transformations and the general method of transformation. This document, and its companion ' SNOMED CT Abstract
Models and Representational Forms' can be found at [[http://www.ihtsdo.org/our-standards/technical-documents/]]. From the perspective of integration of SNOMED CT expressions in HL7 communications the assumption is that in most cases
a "close to user" form will be stored and communicated. The normal form transformation provides a method that enables consistent
comparison of these expressions with one another and with retrieval queries.

 
The purpose of generating normal forms is to facilitate complete and accurate retrieval of pre and post-coordinated SNOMED
CT expressions from clinical records or other resources.

 
The approach described is based on the description logic definitions of SNOMED CT concepts which are used when recording clinical
statements in an electronic records system. Using this approach, expressions that are authored, stored and/or communicated
in a relatively informal close-to-user form are logically transformed into a common normalized form. In this normalized form
it is possible to apply simple rules to test subsumption between expressions.

 
The simplest case of a valid close-to-user expression is a single conceptId, and the approach described can be applied to
these simple pre-coordinated expressions, as well as to more complex expressions that include multiple conceptIds and refinements
(qualifiers).

 
Likewise, transformations and normalisations can be both simple and complex, however the general principle is that the normalisation
process will restate a SNOMED CT expression in terms of the 'primitive' Concepts with which it is associated in the reference
data. By example, the SNOMED CT Concept [ 80146002 | appendectomy ] would, in essence, transform under normalisation to [
71388002 | procedure |: { 260686004 | method |= 129304002 | excision - action |, 405813007 | procedure site - Direct |= 66754008
| appendix structure | } ] ("a procedure that consists of excising an appendix").

 
The approach to normalization may be applied to the specific SNOMED CT expressions but may also be extended to take account
of contextual information derived from the information model in which the expression is situated. Therefore, the normal form
may include SNOMED CT context information, even if this is not present in the initial SNOMED CT expression. As such the result
of transformation of [ 80146002 | appendectomy ] is a simplification (the additional contextual/situation information is missing),
but it is hoped that the example sufficiently illustrates the principle of normalisation.

 
The algorithm extends earlier work on canonical forms as follow:

 
* Normalizes fully-defined values within definitions or expressions producing nested expressions that are fully normalized.
* Merges refinements stated in an expression with definitional relationships present in the definitions of the concepts referenced                               by the expression.
* The merge process takes account of refinements that may not be grouped or nested in a manner that precisely reflects the structure                               of a current (or future) concept definition.
* This avoids the need to add, store and communicate potentially spurious detail from current definitions to the expression                               recorded by a user or software application.
* Takes account of context rules including soft default context and a preliminary approach to moodCode mapping and handling                               of procedures with values (present in algorithm but not yet easily visible in test environment).
 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 4.2
</div> 
<div  class="body"> 
The requirements for full normalization of alternative representation using different combinations of SNOMED CT and HL7 RIM
artifacts requires an agreed comprehensive reference normal form. This is beyond the scope of this document. However, the
rules and guidance in [[Guidance on Overlaps between RIM and SNOMED CT Semantics]] provide the foundations for specifying some of the more common transformation requirements.

 
In particular the following types of transformation may be required

 
* Transforming deprecated patterns using the Observation.code and Observation.value to the preferred pattern. See [[Act.code and Observation.value]] and [[Observation code and value (in event mood)]]
* Transforming based on moodCode and statusCode to apply specified contexts to SNOMED CT expressions, where these expression                               do not state an explicit context. See [[Act.moodCode]] and [[Act.statusCode]].
* Transforming any deprecated uses of the negationInd attribute to an appropriate SNOMED CT expression that explicitly state                               appropriate "finding context" or "procedure context". See [[Act.negationInd]].
* Transforming any information in specific HL7 methodCode, targetSiteCode and approachSiteCode attributes into the appropriate                               refinements of the associated SNOMED CT expression. See [[Procedure.methodCode and Observation.methodCode]], [[Procedure.targetSiteCode and Observation.targetSiteCode]] and [[Procedure.approachSiteCode and SubstanceAdministration.approachSiteCode]].
* Transforming the representation of "subject" participation and SNOMED CT "subject relationship context" into a single coherent                               form. See [[Subject Participation and Subject Relationship Context]].
 
Additional documentation on this topic will be added based on experience of use of this specification.

 
</div> 
</div> 
</div> 
</div> 
<div  class="subSection"> 
<div  class="header"> 5
</div> 
<div  class="body"> 
<div  class="subSubSection"> 
<div  class="header"> 5.1
</div> 
<div  class="body"> 
This section presents general guidance regarding which SNOMED CT concepts are suitable for use as values for specific attributes
of the main classes of the Clinical Statement pattern. These value set constraints are presented at a fairly high level, by
partitioning of SNOMED CT into a number of major concept classes that relate to the Vocabulary Domains of that apply to the
relevant HL7 attributes.

 
In most cases, these value sets are supersets of the values used in the constrained models in [[Common Patterns]] (any exceptions to this are indicated).

 
For reasons introduced in this section and explored in greater detail in [[Detailed aspects of issues with a vocabulary specification formalism]], a complete solution to value set representation is not presented in this Guide. The nature of and rationale for the approach
taken is given in the following sections.

 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 5.2
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.1
</div> 
<div  class="body"> 
The value set specifications are presented as tables in the following general structure:

                  
{| border="1"
|-
|'''Class Name:''' The Clinical Statement pattern class is identified here
                                       		
                                    
|'''Class Code: ''' If relevant, distinct classCodes are identified here
                                       						
                                    
|-
|'''Attribute Name:''' The relevant attribute(s) is/are identified here
                                       		
                                    
|-
|'''Narrative description of vocabulary domain:'''<br>
The relevant narrative description of the vocabulary domain is identified here.
                                       		
                                    
|-
|'''Value set representation:'''<br>
Value sets are identified here, using the SNOMED CT compositional grammar extended for the purpose of this Implementation
                                       Guide as described in Appendix B/&gt;.
                                       		
                                    
|-
|'''Notes:'''<br>
                                       							Any notes relevant to this className+classCode+attributeName value set specification are made here.
                                       						
                                    
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.2
</div> 
<div  class="body"> 
Specifications of the "simple" form provided in this section have some limitations but they serve two important purposes described
in the following sub-sections.

 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.2.1
</div> 
<div  class="body"> 
A large clinical terminology, such as SNOMED CT, represents a number of lexically similar concepts which are grammatically,
linguistically or semantically distinct. This phenomenon is particularly pronounced if the terminology is considered without
any kind of partitioning. The coarse-grained partitioning specified by these constraints simplifies and clarifies decisions
about which of a set of superficially similar SNOMED CT concepts are appropriate to particular HL7 vocabulary domains.

 
For example, consider a vocabulary domain specification that is intended to represent "an adverse event in reaction to a drug".
The simple value set constraints in this specifications exclude these inappropriate alternatives and thus provided a helpful
guide for value set developers.

 
* The most suitable SNOMED CT concepts to represent such an event would be those subsumed by [ &lt;&lt;62014003 | adverse reaction                                           to drug ].
* However from a lexical perspective other less appropriate concepts may appear to be suitable. For example
** The reference to "adverse drugs reaction" may suggest use of subtypes of the procedure concept [ &lt;&lt;396079007 | assessment                                                 of adverse drug reactions ].
** The reference to "drug" may suggest concepts in the use of subtypes of [ &lt;&lt;373873005 | pharmaceutical / biologic product ]                                                 or [ &lt;&lt;410942007 | drug or medicament ].
*
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.2.2
</div> 
<div  class="body"> 
The [[Schematic Illustrations of SNOMED CT Expressions]] identify the "clinical kernel" or primary clinical "focus concept" that may exist alone or as part of a contextualized expression.
In most cases, the simple value set constraints in this specification apply to this clinical focus concept. In combination
with the SNOMED CT concept model these constraints form a foundation for more detailed "complete" value set specifications
(as explored in [[Detailed aspects of issues with a vocabulary specification formalism]]).

 
Simple value set constraints can be regarded as a set of subsumption clauses related by OR logic. Each clause permits the
inclusion of a focus concept that is subsumed by a specified concept. In contrast, a more complete specification would check
normal form transformations of candidate expressions against a variety of subsumption and role-based restrictions. In addition
a complete specification require support of a full set of logical operators between clauses (i.e. OR, AND, NOT).

 
For example, consider a value-set constraint which indicates that the "focus concept" must be a kind of [ &lt;&lt;404684003 | clinical
finding ].

 
* The concept model indicates that a [ 404684003 | clinical finding ] concept
** can be refined by name/value pairs with attribute names such as [ 363698007 | finding site ], [ 246112005 | severity ], [                                                 116676008 | associated morphology ] etc.,
** can be the value to the attribute name [ 246090004 | associated finding ]
*** as part of the definition or refinement of a [ 413350009 | finding with explicit context ]
*** as part of post-coordinated expression that includes the [ 404684003 | clinical finding ] within a context wrapper.
**
*
 
* A comprehensive notation for value sets that allow subtypes of [ 404684003 | clinical finding ] may therefore also need to                                           indicate whether any limitations apply either to the refinement or situation in which the concepts are used.
** The context wrapper may, for instance, be used to communicate negation and uncertainty and may thus be required to support                                                 some types of information. However, it may also be necessary to constrain the use of context in a manner that is relevant                                                 to the Act.moodCode or other attributes and association in the HL7 representation.
*
 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.3
</div> 
<div  class="body"> 
A simple approach to value set constraints is inevitably incomplete when applied to SNOMED CT as a result of two features
supported by SNOMED CT.Both these SNOMED CT features are useful for the detailed coded capture of clinical data. However,
they create a challenge for value set representation that cannot be fully met by the simple approach used in this specification.
As outlined in the following sections, the inadequacy of the simple approach introduce the risks of false-positive and false-negative
results.

 
# The ability to create, and the requirement to communicate, post-coordinated SNOMED CT expressions.
# the ability to use pre-coordinated expressions referring to concept that are subtypes of  [ 243796009 | situation with explicit                                     context ] [[[13]]].
 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.3.1
</div> 
<div  class="body"> 
Two different aspects of SNOMED CT post-coordination ("attribute refinement" and "context/situation wrapping") may result
in the valid expressions being rejected by "simple" value sets tests.

 
''Example of "attribute refinement" false negative:''

 
The concept [ 82764005 | operation on duodenum ] could be refined by applying more specific values to its [ 260686004 | method
] and [ 363704007 | procedure site ] attributes.

 
If the value for [ 260686004 | method ] is refined to [ 129304002 | excision - action ] and the value for [ 363704007 | procedure
site ] to [ 181247007 | entire duodenum ], the resulting expression means "excision of the entire duodenum" and we would expect
this to mean the same as "total excision of duodenum". This expression would be inappropriately rejected by a "simple" value
set test of the instruction [ &lt;&lt;173848007 | total excision of duodenum ] (i.e. "include 'total excision of duodenum' any sub-types").

 
* This false negative arises because [ 82764005 | operation on duodenum ] is not a subtype of [ 173848007 | total excision of                                           duodenum ].
* In order to obtain the appropriate result, a more complex test must be performed. This involves comparison of the normal forms                                           of the two expressions.
 
''Example of "context/situation wrapping" false negative:''

 
The concept [ 373573001 | clinical finding present ] can be refined by applying a more specific value to its attribute [ 246090004
| associated finding ].

 
If the value for [ 246090004 | associated finding ] is refined to [ 404640003 | dizziness ], the resulting post-coordinated
expression means "dizziness present". This expression would be inappropriately rejected by a "simple" value set test of the
instruction [ &lt;&lt;404640003 | dizziness ] (i.e. "include 'dizziness' and any sub-types").

 
* This false negative outcome is because [ 373573001 | clinical finding present ] is not a subtype of [ 404640003 | dizziness                                           ].
* In order to obtain the appropriate result, a more complex test must be performed. This involves comparison of the normal forms                                           of the two expressions, taking account of the default context of a SNOMED CT 'finding'.
 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.2.3.2
</div> 
<div  class="body"> 
A potential pattern of false positive value set testing would result from attempts to augment the "simple" value set specifications
to include corresponding "context/situation" Concepts. The absence (by design) of an exhaustive set of "context/situation"
Concepts corresponding to each "finding" or "procedure" Concept means that on many occasions only the specification of a more
general "situation" Concept will guarantee that desirable Concepts will be included, but at the expense of allowing multiple
false positives.

 
''Example of pre-coordinated "situation" false positive:''

 
Consider a value set designed to include "respiratory disorders". To avoid rejecting concepts which include explicit context,
a simple value set might include [ &lt;&lt;413350009 | finding with explicit context ] as well as [ &lt;&lt;50043002 | disorder of respiratory
system ]. Such a clause would include the relevant respiratory findings, including those with explicit context. However, it
would also inappropriately include other findings with explicit context (i.e. non-respiratory finding with explicit context).

 
Failure to include [ &lt;&lt;413350009 | finding with explicit context ] would result in false negatives as illustrated in the previous
section.

 
* In order to obtain the appropriate result, a more complex test must be performed. This involves restricting the inclusion                                           of subtypes of [ 413350009 | finding with explicit context ] to those with a value for [ 246090004 | associated finding ]                                           that are in the set specified by [ &lt;&lt;50043002 | disorder of respiratory system ].
 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSection"> 
<div  class="header"> 5.3
</div> 
<div  class="body"> 
The "simple" value set constraints are provided as a set of tables, covering the major classes of the Act and Entity Choice
boxes.

 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1.1
</div> 
<div  class="body">                  
{| border="1"
|-
|'''Class Name:''' Observation
                                             		
                                          
|'''Class Code: OBS'''
|-
|'''Attribute Name:''' Observation.value 
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
An act that is intended to result in new information about a subject. The main difference between observations and other acts
                                             is that it has a value attribute that is used to state the result of the assessment action described in Act.code.
                                             		
                                          
|-
|'''Simple representation:'''<br>
((&lt;&lt;404684003 | clinical finding |) OR (&lt;&lt;413350009 | finding with explicit context |) OR (&lt;&lt;272379006 | event |))
                                          
|-
|'''Notes:''' Where Observation.code = ASSERTION.
                                             								<br>
An alternative approach (now deprecated) is for the same value set to be communicated in Observation.code where the attribute
                                             Observation.value is not present in the Observation class instance.
                                             								<br>
<br>
As indicated in section 2.2.2.2 subheading 7, the situation may arise in which Observation.value is a SNOMED CT expression
                                             from the set specified in the 'simple representation' field of this table and Act.code is represented by a code other than
                                             "ASSERTION". For such an approach can only be safely used if 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". Without
                                             exhaustive scrutiny of SNOMED CT's content it is not possible to identify that set of codes that can safely be used in this
                                             way in Act.code.
                                             								<br>
|} 
A further alternative representation is needed to communicate record entries where SNOMED CT content has been used to represent
Observation.code and Observation.value is present. Observation.value may be a numeric, nominal or ordinal result, so itself
may come from SNOMED CT also:

                  
{| border="1"
|-
|'''Class Name:''' Observation
                                             		
                                          
|'''Class Code: OBS'''
|-
|'''Attribute Name:''' Observation.code
                                             								<br>
'''Attribute Name:''' Observation.value
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
An act that is intended to result in new information about a subject. The main difference between observations and other acts
                                             is that it has a value attribute that is used to state the result of the assessment action described in Act.code.
                                             		
                                          
|-
|'''Simple representation for Observation.code:'''<br>
((&lt;&lt;386053000 | evaluation procedure |) OR (&lt;&lt;363787002 | observable entity |))
                                             								<br>
'''Simple representation for Observation.value (where SNOMED CT-encoded):'''<br>
((&lt;&lt;281296001 | result comments |) OR (&lt;&lt;260245000 | findings values |))
                                             		
                                          
|-
|'''Notes:''' As noted in Section 3, editorial debate continues regarding whether or not [ &lt;&lt;363787002 | observable entity ] concepts should
                                             be recommended for use in Observation.code; It should also be noted that the Observation.value specification is limited to
                                             those values specified by the SNOMED CT concept model as suitable targets for the [ 363713009 | has interpretation ] attribute.
                                             This specification would currently disallow/exclude the value [ 371246006 | green color ] used in Example 1 of Section 3.
                                             								<br>
<br>
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1.2
</div> 
<div  class="body">                  
{| border="1"
|-
|'''Class Name:'''<br>
Procedure
                                             		
                                          
|'''Class Code: PROC'''<br>
|-
|'''Attribute Name:'''<br>
Procedure.code
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. 
                                             		
                                          
|-
|'''Simple representation:'''<br>
((&lt;&lt;71388002 | procedure |) OR (&lt;&lt;129125009 | procedure with explicit context|)) AND (!432102000 | Administration of substance|)
                                             AND (!&lt;243704004 | provision of appliances|) AND (!&lt;183253002 | provision of medical equipment |) AND (!&lt;404919001 | wheat-free
                                             diet) AND  (!&lt;223456000 | provision of a special diet) AND (!&lt;440298008 | Dispensing of pharmaceutical/biologic product |))
                                             		
                                          
|-
|'''Notes: '''in order to prevent overlap, this specification includes the negated clauses to exclude the value set of "Substance administration"
                                             and "Supply".
                                             								<br>
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1.3
</div> 
<div  class="body">                  
{| border="1"
|-
|'''Class Name:'''<br>
SubstanceAdministration
                                             		
                                          
|'''Class Code:'''<br> SBADM
                                          
|-
|'''Attribute Name:'''<br>
SubstanceAdministration.code
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
Introducing or otherwise applying a substance to the subject
                                             		
                                          
|-
|'''Simple representation:'''<br>
416118004 | administration |) optionally: &lt;&lt;432102000 | administration of therapeutic substance |
                                             		
                                          
|-
|'''Notes:''' In Release 1 of this guide, and n order to support a tighter standardization of this class and ensure that the "substance"
                                             administered was only represented in the related Material Entity, SNOMED CT content that explicitly explicitly referred to
                                             substances (for example 39543009|administration of insulin (procedure)|) were excluded (by a specification that limits to
                                             the codes offered and none of the subtypes. <br>
<br> In response to examples that have been identified where specific subtypes of 432102000 | Administration of substance (procedure)
                                             | are required for use in  SubstanceAdministration.code, the looser optional constraint is offered to provide access.
                                             Nevertheless, the intent of the guide (to ensure that the the "substance" administered was only represented in a related Material
                                             Entity) still holds to enable consistent analysis. 
                                             								<br>
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1.4
</div> 
<div  class="body">                  
{| border="1"
|-
|'''Class Name:'''<br>
Supply
                                             		
                                          
|'''Class Code:'''<br> SPLY
                                          
|-
|'''Attribute Name:'''<br>
Supply.code
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
The provision of a material by one entity to another
                                             		
                                          
|-
|'''Simple representation:'''<br>
((&lt;&lt;243704004 | provision of appliances|) OR (&lt;&lt;183253002 | provision of medical equipment |) OR (&lt;&lt;404919001 | wheat-free
                                             diet|) OR  (&lt;&lt;223456000 | provision of a special diet|) OR (&lt;&lt;440298008 | Dispensing of pharmaceutical/biologic product |))
                                             		
                                          
|-
|'''Notes:'''Possibly incomplete. Currently SNOMED CT has no abstract notion of the "supply/provision of material", so whilst diet and
                                             appliances, equipment and pharmaceutical/biologics are supported, it is still possible that some cases are not supported.
                                             								<br>
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1.5
</div> 
<div  class="body">                  
{| border="1"
|-
|'''Class Name:'''<br>
Organizer
                                             		
                                          
|'''Class Code:'''<br> ORGANIZER
                                          
|-
|'''Attribute Name:'''<br>
Organizer.code
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
Organizer of entries. Navigational. No semantic content. Knowledge of the section code is not required to interpret contained
                                             observations. Represents a heading in a heading structure, or "organizer tree".
                                             		
                                          
|-
|'''Simple representation:'''<br>
((&lt;&lt;419891008 | record artifact |) OR (&lt;&lt;386053000 | evaluation procedure |))
                                          
|-
|'''Notes: '''[ &lt;&lt;386053000 | evaluation procedure ] is included to allow the naming of batteries with Laboratory procedure terms.
                                             								<br>
|} 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.1.6
</div> 
<div  class="body"> 
The following very general SNOMED CT value set for using the Entity.code attribute is outlined below. In any specific model
this set should be appropriately constrained.

                  
{| border="1"
|-
|'''Class Name:'''<br>
Entity
                                             		
                                          
|'''Class Code:'''<br> ENT
                                          
|-
|'''Attribute Name:'''<br>
Entity.code
                                             		
                                          
|-
|'''Narrative description of vocabulary domain:'''<br>
A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.
                                             		
                                          
|-
|'''Simple representation:'''<br>
((&lt;&lt;410607006 | organism |) OR (&lt;&lt;373873005 | pharmaceutical / biologic product |) OR (&lt;&lt;260787004 | physical object |) OR
                                             (&lt;&lt;105590001 | substance |) OR (&lt;&lt;123038009 | specimen |) OR (&lt;&lt;308916002 | environment or geographical location |)).
                                             		
                                          
|-
|'''Notes:''' (1) A more sophisticated division of SNOMED CT Entities is needed to reconcile with the coarse-grained specializations of
                                             Entity within the HL7v3 Specification (e.g. LivingSubject, Place, Manufactured Material...).
                                             								<br>
(2) the SNOMED CT class [ 123038009 | specimen ] could be viewed as merging both the Entity and the specimen "role", however
                                             it is included in this specification, on the understanding that the "specimen" role would be restated within the Clinical
                                             Statement pattern-conformant specification. 
                                             							
                                          
|} 
</div> 
</div> 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.2
</div> 
<div  class="body"> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.2.1
</div> 
<div  class="body"> 
A comprehensive notation for all SNOMED CT &#8216;findings and procedures" value sets is logically &#8216;wrapped" in the SNOMED CT context/situation
wrapper, and indeed the context/situation wrapper would be used to communicate negation and uncertainty in message designs
where SNOMED CT is the only permitted code system. In more "complete" value set constraint specifications therefore, it can
be expected that the moodCode values found in message instances should influence the corresponding valid "finding and procedure
context" values. Details of the recommended mappings are provided in [[Act.moodCode]]

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.2.2
</div> 
<div  class="body"> 
A value set constraint can be applied to any coded content where the codeSystem is SNOMED CT. This includes cases where original
encoding is SNOMED CT or where the SNOMED CT encoding is based on a translation from another codeSystem. Thus the value set
constraints may be tested against the original encoding or translation sub-element in an instance of the HL7 Concept Description
(CD) data type.

 
</div> 
</div> 
<div  class="subSubSubSection"> 
<div  class="header"> 5.3.2.3
</div> 
<div  class="body"> 
New record entries should be made using SNOMED CT concepts with an active status. However it is possible that communications
may contain SNOMED CT content that, while active at the time of entry, have subsequently been rendered inactive in the reference
data(e.g. as a result of recognition or errors such as duplication or ambiguity). In these cases value set testing SHOULD
include analysis of information contained in the SNOMED CT history data. Such data will assist in establishing the relationship(s)
between inactive concepts and active concepts. If it can be demonstrated that an inactive concept has an appropriate historical
relationship to a value set valid active concept, and if the specification does not explicitly exclude inactive concepts,
then the inactive concept should be regarded as valid for communication.

 
For example, consider the concept [ 274638001 | asthenia ], which is now marked as an inactive duplicate in SNOMED CT. This
concept may have been active in the past, and may thus have been used in the creation a record entry. This historical record
entry may subsequently be communicated (perhaps as part of a record extract), by which time the concept has been marked as
inactive. If this is encountered it is possible (by analysis of the SNOMED CT history data) to identify the [ 168666000 |
SAME AS ] relationship to the active concept [ 13791008 | asthenia ]. Assuming the message specification does not explicitly
exclude inactive concepts it is then possible to test the (active) concept for suitability in the message instance and accept
it as valid.

 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
<div  class="subSection"> 
<div  class="header">

=== Endnotes ===
 
</div> 
</div> 
# [[[source]]] SNOMED Clinical Terms and SNOMED CT are registered trademarks of the International Healthcare Terminology Standards Development                   Organisation ([[IHTSDO]]). Prior to April 2007 the IP rights to SNOMED CT were owned by the College of American Pathologists (CAP) and for this reason                   some materials referenced by this document may still be badged with CAP Copyright. However, as far as the authors of this                   document are aware, ownership of all these materials has been transferred to the IHTSDO.
# [[[source]]] The Clinical Statement CMET is a proposed replacement for the Supporting Clinical Information CMET which is based on the Clinical                   Statement pattern.
# [[[source]]] This implementation guide does not recommend a particular model of meaning. See [[Normal Forms]] for more details.
# [[[source]]] The requirement for moodCode to be present may be met either by explicit inclusion or by a default specified in an HL7 model.
# [[[source]]] http://aurora.rg.iupui.edu/UCUM
# [[[source]]] Translation to from SNOMED CT to UCUM representations is supported by a mapping table developed by the UK NHS. It is anticipated                   that this will be maintained in future as part of SNOMED CT.
# [[[source]]] A third time attribute, Act.availabilityTime is related to the system availability of the information rather than the action                   itself.
# [[[source]]] These patterns assume the use of SNOMED CT. While other code systems (such as LOINC or ICD9) may be required or even preferable                   in some situations, these situations are outside the scope of this guide.
# [[[source]]] The Organizer class can be used to communicate batteries. Therefore measurement procedures representing batteries can be used.
# [[[source]]] The organizer may have contextual components (e.g. participants or act relationships) which propagate to nested observations.
# [[[source]]] SNOMED distributes an allergen subset, drawn from Substance and Product hierarchies.
# [[[source]]] Note that it may not be possible in this context to differentiate an allergic reaction from the condition of being allergic,                   since the data entry field only accepts substance and product values.
# [[[source]]] Note that the naming in SNOMED CT"s documentation/data has recently been updated - "context-dependent categories" in the data                   have been renamed "situation with explicit context". In this guide these concepts are referred to as [ &lt;&lt;243796009 | situation                   with explicit context ] or the more specific [ &lt;&lt;413350009 | finding with explicit context ] and [ &lt;&lt;129125009 | procedure                   with explicit context ].
         
{| border="1"
|-
|[[View Revision Marks]][[Hide Revision Marks]]
|
|} 
</div> 
</div>