Templates and Vocabulary Bindings

One of the problems that the Structured Documents Workgroup has encountered over the past couple of years is the difficulty dealing with realm specific vocabulary bindings with templates.  The problem is that there isn't a universally accepted vocabulary for clinical terms across the various international realms.  So, building an implementation guide for the Universal Realm is difficult.

We want to be concrete in the selection of value sets used with a particular template that we create, but there's no agreement on the vocabulary to use.  We cannot use fill in the blank for everything because:

A) It's not universally available
B) Some other vocabulary is mandated nationally for that purpose

Et cetera.

So how do we resolve that problem?

I propose the following set of principles:
1.  Templates select a concept domain for a specific list of concepts.
2.  Templates show representative value sets that provide the list of concepts in that domain for a given vocabulary.
3.  Realm specific bindings take over from there.

Let's look at a simple use case: identifying vital signs at a high level
1.  The concept domain is vital signs.  We define it to be a set of codes for recording vital signs (let's stick with the usual ones and not get too creative here, I know we can, but...)
Tempurature
Blood Pressure
Respiration Rate
Pulse
O2 Saturation
2. A representative value set from SNOMED is:
body tempurature (386725007)
diastolic blood pressure (271650006)
systolic blood pressure (271649006)

respiratory rate (86290005)
pulse rate (78564009)
oxygen saturation measurement (104847001)

Another representative value set from LOINC is:
8310-5 BODY TEMPERATURE

8480-6 INTRAVASCULAR SYSTOLIC
8462-4 INTRAVASCULAR DIASTOLIC
9279-1 RESPIRATION RATE

8867-4 HEART BEAT
2710-2 OXYGEN SATURATION

3.  Realm specific bindings determine which of the two value sets are used when the implementation is used in a particular realm.

This isn't so hard.  The really hard part is that we have to be willing to divorce the concrete bindings from the content of universal realm implementation.  As an implementer, what that means is that you have to go to a country specific list of vocabulary specified elsewhere (e.g., an appendix or a realm-specific implementation guide).  This is the so-called "HITSP problem", having to reference multiple documents to get what you need for an implementation.

The HL7 Vocabulary workgroup describes three core concepts in the HL7 Version 3 standard:
Concept Domain

Vocabulary/Terminology/Coding System
Value Set

A value set implements a concept domain by drawing terms from specific coding systems (a value set may contain concepts from different coding systems).  It concretely implements a concept domain.  What is missing here is the notion of a "Concept Set" which better defines a concept domain.  It's like a value set, except that it provides only definitions, not codes.  It's also like a concept domain, except that it is more concrete.

One way to express the contents of a concept set is to use metathesaurus concepts (e.g., from UMLS) to represent the set of concepts in a concept domain.  This doesn't solve the reference indirection problem for implementors directly, but it does allow implementors with access to the metathesaurus to automatically obtain bindings to specific vocabularies.  By replacing the representative value set with a concept set, we can potentially select across multiple vocabularies at the same time.

It's not a complete solution yet; I'm sure there are a few details that need to be worked out, but it is a start in the right direction.

     Keith

P.S.  We still need a US Realm authority in HL7.  That would solve the other half of the problem that Structured Documents has to work around.  Due to the lack of that authority, US Realm guides are balloted by the entirety of the HL7 membership, and all to often, non-US realm specific concerns creep into US realm ballot comments.  Maybe someday we'll resolve that problem.  I keep hoping the replacement RFP for standards harmonization from ONC will move to address that issue.