Constraint Specifications
The "simple" value set constraints are provided as a set of tables, covering the major classes of the Act and Entity Choice boxes.
Class Name: Observation
|
Class Code: OBS |
Attribute Name: Observation.value
| |
Narrative description of vocabulary domain: 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: ((<<404684003 | clinical finding |) OR (<<413350009 | finding with explicit context |) OR (<<272379006 | event |)) | |
Notes: Where Observation.code = ASSERTION.
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.
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. |
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:
Class Name: Observation
|
Class Code: OBS |
Attribute Name: Observation.code
Attribute Name: Observation.value
| |
Narrative description of vocabulary domain: 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: ((<<386053000 | evaluation procedure |) OR (<<363787002 | observable entity |)) Simple representation for Observation.value (where SNOMED CT-encoded):
| |
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.
|
Class Name: Procedure
|
Class Code: PROC |
Attribute Name: Procedure.code
| |
Narrative description of vocabulary domain: An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject.
| |
Simple representation: ((<<71388002 | procedure |) OR (<<129125009 | procedure with explicit context|)) AND (!432102000 | Administration of substance|) AND (!<243704004 | provision of appliances|) AND (!<183253002 | provision of medical equipment |) AND (!<404919001 | wheat-free diet) AND (!<223456000 | provision of a special diet) AND (!<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". |
Class Name: SubstanceAdministration
|
Class Code: SBADM |
Attribute Name: SubstanceAdministration.code
| |
Narrative description of vocabulary domain: Introducing or otherwise applying a substance to the subject
| |
Simple representation: 416118004 | administration |) optionally: <<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.
|
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. |
Class Name: Supply
|
Class Code: SPLY |
Attribute Name: Supply.code
| |
Narrative description of vocabulary domain: The provision of a material by one entity to another
| |
Simple representation: ((<<243704004 | provision of appliances|) OR (<<183253002 | provision of medical equipment |) OR (<<404919001 | wheat-free diet|) OR (<<223456000 | provision of a special diet|) OR (<<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. |
Class Name: Organizer
|
Class Code: ORGANIZER |
Attribute Name: Organizer.code
| |
Narrative description of vocabulary domain: 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: ((<<419891008 | record artifact |) OR (<<386053000 | evaluation procedure |)) | |
evaluation procedure ] is included to allow the naming of batteries with Laboratory procedure terms.
|
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.
Class Name: Entity
|
Class Code: ENT |
Attribute Name: Entity.code
| |
Narrative description of vocabulary domain: A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.
| |
Simple representation: ((<<410607006 | organism |) OR (<<373873005 | pharmaceutical / biologic product |) OR (<<260787004 | physical object |) OR (<<105590001 | substance |) OR (<<123038009 | specimen |) OR (<<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...). (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. |
A comprehensive notation for all SNOMED CT ‘findings and procedures" value sets is logically ‘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
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.
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.