RECOMMENDATION ID1:
Recommendation for HL7 RIM and/or
Vocabulary Changes
For Harmonization During: March 2010
C21-01
Sponsor’s Draft3:
Sponsored by2: Vocabulary WG
Sponsor’s Status4 Approved
Date Approved by Sponsor: January 19, 2010
Editor/ Author: Ted Klein
PROPOSALNAME: Add Reference Realm
Class Model Change
Datatypes Change
Structural Vocabulary Change
Other Vocabulary Change
SUMMARY RECOMMENDATION
As part of the decision on Reference Terminology for binding guidance, the Vocabulary
Workgroup voted in Phoenix to introduce a Reference Realm to HL7 v3.
VOCABULARY OBJECTS CHANGE SUMMARY
None of these are impacted – this is one new Realm.
Abbrev. Description
# to add
D
Concept Domains
S
Code Systems
C
Concept Codes in a Code System
V
Value Sets
B
Context Bindings
# to remove
# to change
POSITION OF CONCERNED ORGANIZATIONS:
ORG
RECOMMENDATION APPROVAL STATUS
AFFECTED ELEMENTS OF INTEREST TO ORG
Vocab WG
Endorsed: WG voted to add this at
For future use.
the PHX WGM.
MnM
Pending
ISSUE:
From the Phoenix Vocabulary WG minutes:
Background: the original objective was to be agnostic to code systems in order to
not 'offend' any of the players. This has proven to be a poor process, as there is a
need to understand that there is a need for consistent representation of the content of
Discussion
We need to do something different in how we create models and the terminology
rather than one set of people who create the models and imagining a magic link to
the terminology.
Need methodology where we make a statement and say we have these preferred
terminologies and the models and the terminology are made together with people
1
identifier by which proposal is known to sponsor
must be sponsored by an HL7 TC, the HL7 International Committee, an HL7 SIG, or an ANSI or ISO
accredited SDO
3
for sponsor tracking only; not for Harmonization identification
4
for sponsor tracking only, Sponsor’s status must be “Approved” for submission to Harmonization
2
Recommendation for HL7 RIM Change (continued)
who have authority to change the model/terminology requirements and ensure that
the required solution can be supported.
Internationally: there will be cases where countries legislate for a specific code set
which may not be the preferred set. A country may choose to not use the preferred
code system –this could be considered not compliant, but these countries may have
their own realm standards to which they are compliant.
This is particularly relevant in the clinical environment. There is a need to
understand the boarder between the clinical domains and other domains. IN the
context of harmonisation there is the issue that the modelling process must
understand some of the technical requirements to support the right use of
terminology in the context of an HL7 model. Taking the knowledge of how this
should occur out of those few who know and understand harmonisation, but to
extend to those who do the models.
We need a way to make clear what the modeller had in mind. There is a need for a
reference value set (as a proposed requirement of the modelling elements) so that the
model in ballot includes a full and complete example value set that could be used to
implement the solution.
IHTSDO has expressed the idea that in order to use SNOMED-CT you have to use
an information model that IHTSDO has reviewed and identified that you can use
SNOMED-CT in the information model and this is how they should be used safely.
Example: the need to differentiate between the service and the delivery of the
service
How to ensure that the terminology used fits with the model. Though it is important
not to be overly prescriptive, we still must ensure accurate meaning representation.
Preferred value set but you may have alternative value sets.
Rather than a conformance statement is really a warrantee criterion of the modellers.
We cannot assure you that if you deviate you will be able to accurately transfer
meaning. Eg: if some organisations use icd and others use SNOMED-CT they can
be mapped but retention of precise meaning is not able to be assured. (and in this
instance will definitely not be assured).
We are saying YOU NEED TO DO THIS – think about the terminology and code
system and the type of information you want to communicate – you are required to
state what your preferred terminology is in order to meet that need. The modellers,
in the context of a specific use, identify the terminology required to meet this need.
The objective is to make this requirement much clearer to implementers and decision
makers.
It was decided that explicit recommendations that make this clearer are appropriate.
CURRENT STATE:
There is no mechanism to communicate this effectively from the modelers to those making
jurisdictional decisions on value set binding (context binding).
Recommendation for HL7 RIM Change (continued)
OPTIONS CONSIDERED:
This could be implemented with the vocabulary declaration as distinct from the binding and create
a lot of the value we require coupled with a policy that requires that the static model is not
complete until the code system is specified, or when implementing in a particular realm there may
be a reference context. Eg: intended to be used with SNOMED-CT (disorders) there may be
process guidelines for those who have to implement where the reference binding exists, then this
is the starting point max value set, they may constrain down from there. Note that the solution in
the Vocabulary Declaration pertains to a single model element, but is Universal, whereas the Reference
Realm solution pertains to all elements specifying a particular Concept Domain but for a particular Realm.
RATIONALE:
Both of these have been added to Core Principles. The outcome of the May ballot may rescind
this item.
RECOMMENDATION DETAILS:
Add new Reference Realm.
Definition: The Reference Binding Realm exists to provide a reference for those model
elements where the integrity of the semantics for the modeling style chosen is tightly
coupled to a particular terminology. This is generally of highest importance in clinical
models where semantic issues may be introduced through dissonance between the HL7
static model design and a robust terminology model, such as that underlying SNOMEDCT. When model designers wish to indicate that a particular coded element for a
particular model may have this kind of semantic issue, a subDomain should be created,
and a binding to a Value Set, which specifies the terminology that the designers had in
mind for use when creating the particular model, in the context of the Reference Binding
Realm. An instance of a model (at implementation time) never specifies the Reference
Binding Realm; this is used for documentation and knowledge about the model design
only; a Realm that wishes to use the Value Set specified in the Reference Binding should
create a binding in their Realm to that Value Set.
When a jurisdictional authority wishes to assert a specific Value Set for use in their
Binding Realm for a particular Concept Domain, they should take into consideration any
Reference binding that may exist for that Domain in order to understand any semantic
representation issues that may arise (or be resolved) with their specific choice of Value
Set(s) for their binding.
Note that this Reference Context Binding, once made, is in place for all coded elements
that have been constrained to the specified Concept Domain, and may cover multiple
models. Use of this realm in a binding should be judicious, or should only be used for
those highly constrained Concept Domains that are used only within a specific model.
The Reference Binding Realm should never be identified in an implemented model
instance. It has no "parent" Binding Realm.
DISCUSSION:
The two approaches to solving this issue have different scopes, but can be made to accomplish
essentially the same thing (In the context binding space by having a Reference Binding, or in the
model space by having the prose recommendation in
VocabularyDeclaration.TerminologyGuidance).
Recommendation for HL7 RIM Change (continued)
ACTION ITEMS:
Harmonization committee to apply the change to the HL7 Vocabulary.
RESOLUTION:
Vocabulary Submission Checklist:
The following identifies the pieces of information that must be included or identified for the
different types of vocabulary harmonization actions. It is included here for convenience in order
to make certain the proposal is complete; this is not intended to be ‘filled in’, but are things that
must be checked and/or considered when making the proposals. Any of these that are not
included or done must be done during the application of the harmonization proposals after the
meeting, and thus may not be deduced correctly if not explicit. Each of these needed pieces of
information is REQUIRED for that particular operation.
New Concept Domain:
Parent Domain if the new Domain is not at the root
Definition, plus three examples of concepts which would be in the same semantic category
labeled by the Domain OR an Example binding. NOTE: these are not coded concepts, ie
codes from a codeSystem
The name of the new Domain should follow the current practice pattern for naming
Modify Concept Domain:
New Parent if hierarchy change
Evaluation or Disposition of existing bindings
Impact on any models if name is to be changed
Remove Concept Domain:
Disposition of existing bindings
Removal comment
New Code Systems
Whether they are HL7-maintained or External, OID if one exists
Description
Full name (title) and short name (with no spaces or punctuation)
Modify Code System:
Only descriptions or full names may be modified; for content see Concept Codes
Deprecate/Delete Code System:
Disposition of existing value sets built on it, along with their existing bindings
Identification of what it is being superceded by
Deprecation comment
New Concept Codes:
The code system they are to be added to
The extensional value set(s) they are to be added to, if any
Their parent, if they are not at the root of the code system
Whether or not they are abstract (selectable)
Mnemonic, or code value (try to follow any pre-existing practice pattern)
Description
Print Name (try to follow any pre-existing practice pattern)
Deprecation/Deletion of Concept Codes:
The code system they are to be removed from
The new parent for any child concepts they may have had
The extensional value set(s) that they should also be removed from, if any
Deprecation comment
Modify Concept Codes:
The code system it is in
Modified description (if that is the modification)
Change to/from abstract (if that is the modification)
Change position of code in hierarchy – identify old/new parent, and any impacts on child
codes
Recommendation for HL7 RIM Change (continued)
New Value Set:
Name (without spaces); must fit the current practice pattern of naming style
Name (Title)
Optional Description
Code System it is based on (primary)
Extensional vs. Intensional
Definition expression/contents list
Deprecate/Delete Value Set:
Disposition of existing bindings, both Model and Context
Identification of other value sets that include the one to be deleted
Modify Value Set
Updated Print Name, with identification of Model bindings affected
Updated defining expression/contents list
New Context Binding
Name of Domain plus Name of Value Set plus OID of Value Set (if present) plus Context
Modify Context Binding
Name of Domain plus Name of Value Set plus OID of Value Set (if present) plus New
Context
Removal of Existing Context Binding
Name of Domain plus Name of Value Set plus OID of Value Set (if present) plus Context
Note that you must follow up name changes to Concept Domains or Value Sets that are
done during the harmonization meeting are applied to any bindings that have been
specified in the Static Model (using the RMIM designer tool) so that the binding will
point to the new name of the object.
Recommendation for HL7 RIM Change (continued)
Recommendation Details: Template for Vocabulary Proposal
EXISTING CONTEXT: positions the proposal within the HL7 vocabulary, and provides related
descriptions necessary for understanding and evaluating the proposal. Use as many levels as
necessary in each hierarchy illustrated.
RIM_nnnn
Concept Code (conceptID = xxxxxx)
Concept Code (conceptID = xxxxxx)
Concept Code (conceptID = xxxxxx)
Description [optional]: provide existing description for any concept for which description
is to be changed, or where specifics in the description are critical to understanding the
proposed change. Descriptions may occur at multiple levels, but are illustrated in this
template only once.
Parent (RoleClass / ActClass / EntityClass  choose one) [required for roleCode,
actCode, and entityCode concepts]: give the full hierarchy for the classCode to which the
code belongs.
Concept Code for classCode (conceptID = xxxxxx)
Concept Code for classCode (conceptID = xxxxxx)
Concept Code for classCode (conceptID = xxxxxx)
Description of classCode: provide existing description only for the classCode to
which the code belongs
Value Set [optional]: for any concept for which a valueSet change is proposed, list (or
describe) existing value sets of interest in evaluating the proposal.
RECOMMENDATION: freeform description of the recommended changes, making reference to
the Existing Context as appropriate.
Always provide conceptID when mentioning any existing concept.
For all new concepts and values, provide:
Concept Code
Concept Name (print name)
Concept Description