Archetypes and Terminology

Eric Browne - April 2008
This note tries page and sub-pages are to clarify some of the concepts that are used formally and informally to describe the relationship between terminology (particularly SNOMED) and the informational structures represented by Archetypes.

• The first part, #Archetype nodes, values and terms addresses the concepts of terminology binding vs. term binding (labelled 'constraint_binding' vs 'term_binding' in ADL).
• The second part, Archetypes and SNOMED, looks at the 3 primary hierarchies in SNOMED most relevant to observations, namely Observable Entity, Procedure and Clinical Finding.

...

But since it is unlikely in the near future that any one terminology, including SNOMED, will be sufficiently comprehensive, widely accessible, and of sufficient quality to allow term bindings for all data points, there seems little reason to impose this extra overhead during Archetype development. One potential benefit is the association between the name of a given data point (term binding) and the set of permissible values for that same point (terminology binding). Where SNOMED has been chosen as the preferred terminology, such an association may help the terminology binding specification process.

Archetypes and SNOMED

Observations using SNOMED

Most clinical observations have two parts - the name of the thing being observed, and the value or result of the observation. What is being observed is (almost?) always descriptive - the height of a person, the mass concentration of HbA1c in the blood, the level of pain experienced, etc. Thus, these names are candidates for being held in a terminology. So much so, in fact, that HL7 in it's V3 Reference Information Model, calls the name of what is being observed the Observation.code. Not so, the result of the observation. This can be, and often is quantitative. It can be a date or a ratio or one of a host of other datatypes. It can be a compound data structure. Again, in the HL7 V3 Observation class, the result of the observation is Observation.value and has a datatype of ANY. The reason for mentioning HL7 here is that some of the HL7 approach to data representation and messaging has influenced the development of SNOMED. Of particular note is that HL7 has one data structure for recording observations - the Observation class with its code and value just described. The assumption is that data already exists in systems and for clinical communication to another system, each observation needs to be placed into an Observation object and these Observations can be bundled up into a message. There is no notion of predefining different observation structures for different clinical concepts à la Archetypes. Thus, users of HL7 need considerable guidance in how to use SNOMED concepts in HL7
Observation objects (populating the Observation.code, Observation.value and other context-related codes), lest every implementation adopts a different approach, subverting interoperability.

...