Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

Many communication constructs have a built-in, or assumed semantic model.

Example:

Rather than having a single coded expression to represent a procedure the HL7 Version 3 class Procedure contains the following coded Attributes .

  • Code (cd);
  • Priority (priority_cd);
  • Reason (reason_cd);
  • Method (method_cd);
  • Procedure_site (procedure_site_cd);
  • Approach_site (approach_site_cd).

Similar constructs occur in other HL7 Version 3 classes (e.g. Observation) and message standards from other sources. However, the HL7 Version 3 Procedure example shown here is probably the best example of a particular dilemma for those communicating with a message that takes some aspects of semantics to the structural level while leaving others to the coding scheme.

Suppose we want to communicate the following procedure:

  • "Emergency removal of foreign body from stomach by incision".

The HL7 Procedure class would allow this to be communicated in several different ways.

These options represent the main type of approach to overlaps. However, in practice the structural model may permit similar information to be recorded in more that one way and SNOMED CT expressions also offer alternatives depending on the extent of normalization of the representation.

The main point is to stress the potential for confusion even when using the same communication structure and the same terminology. This is not a specific problem for SNOMED CT or for a particular message design. Any combination of structural and terminological semantics is susceptible to this issue. Since effective communication of information requires both structure and terminology the challenge is to define an interface between structural and semantic models so that they form part of a common model of meaning .


Feedback