Procedure.targetSiteCode and Observation.targetSiteCode

2.2.5

The Procedure.targetSiteCode is defined by HL7 as “the anatomical site or system that is the focus of the procedure.” 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."

I don't recall exactly how V2 is handling this. RH

2.2.5.1

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.

2.2.5.2

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.

Do we still feel that these are the recommendations? If we adopt an "information model first" view then we may need to change this. This definitely needs discussion. RH

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

1. The targetSiteCode attribute SHOULD be omitted from any Act instance.
2. 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:

1. The targetSiteCode attribute SHALL be optional in any Act instance.
2. 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

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 ], [ <<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.

2.2.5.3

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.

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.

The notes following the Procedure.targetSiteCode definition are perhaps a little less clear cut. However, they convey a similar general sense.

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.

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 [ <<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 ]
      is defined as a procedure with
      

[ {260686004|method|=129303008|removal - action|
,363700003|direct morphology|=56381008|calculus|
,405814001|procedure site - Indirect|=87953007|ureteric structure|} ]

• • • [ 51607004|total ureterectomy | ]
      is defined as a procedure with ...
      

[ {260686004|method|=129304002|excision - action|
,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 |
      ,405813007 | procedure site - Direct | = 2739003 | endometrial structure | }
      {260686004 | method | = 129419002 | dilation - action |
      ,405813007 | procedure site - Direct | = 71252005 | cervix uteri structure | } ]

So again, I think the question would be, do we maximize the use of the available information model attributes and other constructs first, and then use the terminology capabilities only when the information model has inadequate expressivity (while somehow ensuring that they are in sync), or do we up front choose one or the other as preferred? If we take recommend the first approach, would this be reasonably transformable in the majority (or all) cases to an equivalent "pure SNOMED CT" pre or post-coordinated representation? RH

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.