This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Core Properties of V3 Models"

From HL7Wiki
Jump to navigation Jump to search
 
(44 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Preface =
+
= Posting on Wiki WITHDRAWN in Its Entirety =
 +
This document was originally posted for dicussion prior to the first release of the COre Principles document.  Subsequently, this document has gone through four (soon to be five) ballots.  The content on this Wiki page has been entirely superseded and has, therefore been removed.
  
== Notes to Readers ==
+
The Ballot content [http://www.hl7.org/v3ballot/html/infrastructure/coreprinciples/v3modelcoreprinciples.html may be available here].
  
This is the first release of this document. It is intended to
+
[[User:Gwbeeler|GWBeeler]] 14:58, 4 April 2011 (UTC)
provide important background information for implementors
 
trying to implement V3 Static Models, whether they are found
 
in Messages, Documents, or Service Payloads.
 
 
 
== Acknowledgements ==
 
 
 
Authors:
 
* George W Beeler
 
* Grahame Grieve
 
* Ted Klein
 
 
 
= Introduction and Scope =
 
 
 
* a description of the Document at a minimum sufficient for a person unfamiliar with the work to understand the document’s business, scope and relationship with HL7.
 
 
 
* the need for a Specification.
 
 
 
* This specification is a promise (actually, a covenant): what hl7 promises about v3 infrastructure that the implementers can rely on.
 
** because of this, the document will occasionally specify internal procedural rules that are required to support these promises
 
 
 
= Types of HL7 V3 Models =
 
 
 
== Instances ==
 
 
 
The fundamental notion of V3 is that in order to exchange data,
 
systems exchange serialised streams of data that are an "instance"
 
of a v3 model under a set of rules that describe why and when
 
the data is exchanged.
 
 
 
All v3 models are valid of classes linked by associations. The
 
classes and assocations are defined in the RIM. The classes have a
 
series of named attributes which are assigned a type defined in
 
the datatypes. Some attributes are associated with controlled
 
vocabularies which provide clearly defined semantic meaning to
 
the static models. Together, the structural vocabularies, the
 
data types and the RIM classes constitute the reference model.
 
 
 
All v3 instances are instances of the reference model, and conform
 
with the rules of the reference model. V3 models usually also conform
 
to other additional constraint models that describe how the general
 
reference model is used to describe particular administrative or
 
clinical healthcare information.
 
 
 
Instance of v3 models may have any forms of expression and be used
 
in many contexts, such as a message payload in a message associated
 
with an HL7 defined interaction, a CDA document, or a payload as
 
part of a service interaction, etc.
 
 
 
Instances of v3 models are exchanged in the context of a dynamic
 
model that specifies why and when the data is exchanged.
 
 
 
Dynamic models are discussed further below.
 
 
 
=== Serialisation ===
 
 
 
In order for systems to exchange the instances of a v3 model, they
 
need some particular form of representation. As a response to
 
industry demand, HL7 offers a defined representation of the
 
v3 instances in XML, known as the XML ITS. Other forms of representation
 
could be imagined, such as XMI, HUTN, ASN.1 and so forth, but there
 
has not been sufficient demand to justify the creation of alternatives
 
to the standard XML form.
 
 
 
The ITS must define not only how the instance is serialised, but
 
also how the links from the instance to the many models that contribute
 
to defining the meaning of the instance are expressed and/or derived from
 
the serialized representation.
 
 
 
== RIM: Reference Information Model ==
 
 
 
The RIM defines all the classes that are used in v3 instances. The RIM itself
 
is a UML class model; the classes are standard classes in the UML sense, and
 
have associations and attributes as defined in the RIM models. All classes
 
defined in the RIM are specialisations of the base class InfrastructureRoot
 
which defines the attributes that support the core behaviour of V3 models
 
as described in this specification.
 
 
 
The RIM makes extensive use of the two other parts of the V3 reference
 
model, the structured vocabulary and the datatypes. Vocabulary and it's
 
associated concepts are discussed below.
 
 
 
The datatypes define the set of types that may be used to define the
 
value domains and associated semantics of the RIM class attribute.
 
The semantics of the types are defined in the the abstract datatypes
 
(the ITS describes how the datatypes are actually represented when
 
serialized).
 
 
 
A paragraph about structural vocab and the class and mood codes.......
 
 
 
=== How the RIM is maintained ===
 
 
 
* where to find the content
 
** structural vocabularies
 
** datatypes
 
** RIM
 
* that some parts are subject to retrospective change
 
** pay attention to valueset definitions / how published
 
* harmonisation process
 
** technical note about relationship between harmonisation and ballot
 
 
 
== V3 Static Models ==
 
 
 
All other v3 Static Models are statements of constraint against the RIM
 
to which instances of the V3 reference model may be required to conform
 
in a particular context of use.
 
 
 
These models are expressed using a modeling formalism and language
 
developed by HL7 for the purpose. This is fully defined in the HDF
 
and MIF (references....).
 
However this is only one possible form of expression. Other forms of
 
expression have been imagined and proposed or are under development.
 
 
 
Static models may be considered or represented as a direct statement
 
of constraint or as a class model (UML) or some form of typing model
 
(i.e. schema) in their own right. The difference in these two is largely
 
an implementation issue; the semantics are always clear: all instances
 
are instances of the reference model, and all other satic models are
 
constraints on the reference model. The degree of success at representing
 
a static model as a typing model depends on the target platform.
 
 
 
=== DIM : Domain Information Model ===
 
 
 
The first level of constraint is a domain information model. This
 
provides a solution to the information requirements of a particular
 
problem domain. A DIM may have multiple entry points. As such, a
 
DIM is not a directly implementable model, and is a fairly general
 
statement of an domain with fairly general vocabulary bindings.
 
 
 
DIMs are not derived from the RIM, but are developed using constructs that are accessible to experts in the domain in question [(was) may be derived directly from the RIM or from other DIMs (such as
 
the clinical statement pattern).]  One stage of HL7 development, see HDF xxx, is to take a developed DIM and map it to the RIM to create a RIM based model that expresses the same content as the orginial DAM.  Q: How does one decide on the scope of a domain? 
 
Q: Should a DAM reflect the needs of a particular realm? or be in the "universal realm"?
 
 
 
=== CIM : Constrained Information Model ===
 
 
 
CIMs represent a second level of constraint. CIMs must have single
 
entry points, which makes them serialisable. CIMs are therefore
 
suitable for use as implementation constructs on information
 
systems and should be completely specified for this purpose.
 
CIMs are generally focused on narrower problem domain that a DIM.
 
 
 
CIMs are either derived from a DIM directly, or from another CIM.
 
Though technically, a CIM could also be derived from the RIM
 
directly, this is prohibited as a matter of policy to encourage
 
consistent design.
 
 
 
CIM cascades can be as deep as desired, but in most domains HL7
 
only defines a DIM and one layer of CIMs.
 
 
 
Only HL7 or it's affiliates may define and publish CIMs.
 
 
 
=== LIM : Local Information Model ===
 
 
 
Like CIMs, LIMs are a constraint model that has a single entry point.
 
However LIMs differ from CIMs:
 
* LIMs may be derived from the RIM directly as well as DIMs or CIMs (though derivation from the appropriate DIM is recommended)
 
* LIMs may be defined and published by anyone (including HL7 and it's affiliates).
 
* LIMs may be incomplete models (refer to the static model definitions for further information about incomplete models).
 
 
 
LIMs are principally intended to be used as templates, but may be used in other fashion
 
by site or realm agreement.
 
 
 
== Dynamic Model ==
 
 
 
The dynamic model specifies who exchanges information and why, and refers to
 
a set of static model to define the information that is exchanged for a particular
 
scenario. The form of the dynamic model is variable in different uses of V3, and
 
the full expression form is still a subject of further development.
 
 
 
Interoperability Paradigms!
 
 
 
= Realms =
 
 
 
:: rework - this should be a discussion about realms mean in vocab, not what they are.--[[User:GrahameGrieve|GrahameGrieve]] 14:59, 23 February 2008 (CST)
 
 
 
:: begun the rework, please comment.  --[[User:Tklein|Tklein]] 18:07, 23 February 2008 (CST)
 
 
 
Realm (previously also referred to as Context of Use) refers to a named interoperability conformance space, meaning that all static models within a particular Realm share the same conformance binding.  A Realm has a string name which is unique in the HL7 Standards space.  In order to enable conformance, the name of a Realm is carried in a model instance.
 
 
 
In the interest of maximizing interoperability, and making the spaces within which interoperability is maximized as large as possible, Realms are preferred to be large-grained.  The term 'Realm' used in different ways. In the context of HL7 Vocabulary, it is used to indicate a Binding Realm: this manages the bindings/substitutions of value sets to reflect local rules, and is a parameterization permitting internationalization of vocabulary – binding different value sets to the same message design being used in a different country.
 
 
 
There have been a number of Realms defined in HL7.
 
 
 
 
 
== Defined Realms ==
 
 
 
 
 
=== Affiliate Realms ===
 
 
 
Each HL7 International Affiliate has control of a Realm bounded by the geographic scope of that International Affiliate.
 
 
 
 
 
=== Combination Realms ===
 
 
 
There is a need for some Realms that combine more than one country.  North America represents a shared interoperability space for Cancer Registries for both the US and Canada.  This Realm has been created as a combination of the US Realm and the Canadian Realm.  Any Realms may be combined for such a purpose to make an interoperability space that extends beyond one country.
 
 
 
 
 
=== Sub-Realms ===
 
 
 
In some circumstances, a Realm has a requirement to make smaller interoperability spaces within its own borders.  This is discouraged, as it impedes broader interoperability.  However, the mechanisms exist for any Realm to create such a Sub-Realm for models that are used wholly within that smaller subdivision differ from the conformance requirements of models in other Sub-Realms.
 
 
 
 
 
=== Generic Realms ===
 
 
 
Four Generic Realms have been defined that are not specific to an International Affiliate or a geographic area. These generic realms should never appear in instances, they are only used in the standards creation process. All instances must declare a particular realm (or sub-realm) based on the jurisdiction from which they originate or for which they are destined or some third jurisdiction by site-specific agreement.
 
 
 
 
 
==== Universal Realm ====
 
 
 
The Universal Realm constitutes the core HL7 realm which by definition is invariable and fully inherited by all HL7 compliant implementations. I.e. If a Universal Realm binding exists for any domain, all implementations are expected to use the set of codes associated with that binding. No other bindings may exist. Structural elements and most datatypes are examples of contents in this realm. Contents from domain technical committees are not likely to be included in the Universal Realm and when introduced must go through special processes to ensure full international consensus on the constraint to a single binding.
 
 
 
 
 
==== Example Realm ====
 
 
 
The example realm is used for bindings to sets of codes that are known to provide incomplete or non-implementable coverage to the associated domain. They are used to fulfill the example requirement of Concept Domain definition. They may also be used in the construction of realm-independent example instances. Example realms are not needed when Representative Realms exist.
 
 
 
 
 
==== Representative Realm ====
 
 
 
Representative realm bindings are intended to be complete and implementable. However, unlike universal bindings, there is no expectation that all affiliates will choose to adopt the representative realm bound codes. Representative realm bindings provide both a starting point and as a focus for consensus, while recognizing that cultural and political variations between International Affiliates will result in alternative bindings. To qualify for Representative Realm designation, candidate content must be sufficiently comprehensive and internally consistent to be adoptable and implementable by specialized binding realms. A representative realm binding has no official force in an affiliate. The affiliate must explicitly choose to adopt the same set of codes with an Affiliate-specific binding for the representative set of codes to come into effect when determining conformance
 
 
 
 
 
==== Unclassified Realm ====
 
 
 
Since much proposed HL7 machinery will require the explicit specification of a realm, the creation of a realm that can accommodate content that is new and being created or legacy content that has not yet been promoted to one of the three main realms. The Unclassified Realm may also serve as a transition point for content contributed from Specialized Realms. Unclassified realms exist for HL7 administrative purposes and have no effect on implementations
 
Sub-binding Realms
 
 
 
In some circumstances, an International Affiliate might choose to create additional binding realms narrower in scope than the affiliate-wide binding realm. The sub-binding realms might be constructed geographically (regions, states, provinces, etc.) or by type of implementation (e.g. human vs. veterinarian). Sub-binding realms can only be created by International Affiliates.
 
 
 
Note: Because the purpose of binding sub-realms is to allow the use of different code sets for the same message within an affiliate, they can cause interoperability issues within the Affiliate. They should therefore only be introduced after careful consideration of the interoperability consequences.
 
 
 
= Vocabulary =
 
 
 
Coded attributes in Static Models contain Vocabulary, ie they may contain one or more coded concepts drawn from Coding Systems.  The process and mechanisms for assigning collections of these concepts to the coded attributes in the Static Models is described in the Conformance section below.  This section will provide definitions required for the mechanisms implementing Conformance.
 
 
 
== Code System ==
 
 
 
Within HL7, a code system is defined as a collection of coded concepts. each having associated designations and meanings. Examples of code systems include ICD-9 CM, SNOMED CT, LOINC, and CPT. To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system; therefore a concept is uniquely identified by the tuple (codeSystem, code).  A code must be unique within a Code System, but the same string of characters may appear in other code systems associated with a different concept.  Given this definition, each table having enumerated codes in the HL7 Version 2 standard represents a different code system since codes are sometimes used in different tables to have different meanings. For example, “M” in the gender table means Male, while “M” in the marital status table means Married.
 
 
 
Some code systems have 'synonyms', where there more than one code that references the same concept in the code system.  For instance, ISO 3166-1 has one collection of numeric codes representing each country in the world, a second set of 2-character alphabetic codes, and another set of 3-character alphabetic codes.  In ISO 3166-1, the United States of America is represented as "US", "USA" and "840"; each of these can be thought of as a set of synonyms.  In HL7, each of these strings is considered a code; the coded concept is the code system together with the code value. 
 
 
 
A Code System is sometimes referred to as a terminology, an ontology, a vocabulary, or a classification.  In the vocabulary community, these are used for different purposes, and include further differentiation such as reference terminolgies and interface terminologies for those that are used for specific purposes.  In HL7, we refer to any of these as a Code System; the purposes that the coded concepts are used for are specified by the models and the structures within HL7, which may support or require any of these different types of vocabulary collections.
 
 
 
== Concept Domain ==
 
 
 
An HL7 Concept Domain is a named category of like concepts (a semantic type) that will be bound to one or more attributes in a static model whose datatypes are coded.
 
 
 
A Concept Domain is documented by specifying a name, a narrative definition, and three or more examples of concepts that are members of the domain category. This can be accomplished by at least one of the following:
 
 
 
# Including three example concepts as part of the narrative definition;
 
# Binding the domain in the Example Realm to a value set containing at least three example concepts;
 
# Binding the domain in either the Universal or Representative Realm to a value set deemed to contain a complete set of concepts.
 
 
 
The binding process and descriptions of the Universal, Representative, Unclassified and Example Realms are described later in this document.
 
 
 
Concept Domains exist because we want to constrain the intent of the coded element while deferring the association of the element to a specific coded terminology until later in the message development process. Thus, Concept Domains are independent of any specific code system.
 
 
 
:: todo: how to describe/define the message development process. and why "specific vocabulary" - it's not a predefined term. --[[User:GrahameGrieve|GrahameGrieve]] 14:38, 23 February 2008 (CST)
 
 
 
:: not sure where to go with this in terms of how much should be described about the message development process down here in vocabulary..  --[[User:Tklein|Tklein]] 11:12, 10 March 2008 (CDT)
 
 
 
Concept Domains are universal in nature (independent of any realm). The name for a Concept Domain should never contain any reference to a specific realm. Concept Domains are proposed as part of the HL7 standards development process and are approved by the RIM harmonization process. Any conflicts in proposed domains are resolved by the RIM harmonization process.
 
 
 
 
 
 
 
 
 
=== Examples of Concept Domains ===
 
 
 
The HL7 defined Concept Domain HumanLanguage, defines a category of like concepts specifying the “Codes for the representation of the names of human languages.” The HumanLanguage Concept Domain only defines the category for the concepts that represent the different human languages. The actual coded elements for the concepts comprising the content for the HumanLanguage Concept Domain will be defined by different code systems used by different entities.
 
 
 
For example, agencies in the United States may choose to use a code system containing codes that represent the Native American languages, while agencies in New Zealand may find such a Code System inappropriate.
 
 
 
 
 
Figure 1: RIM Attributes and Vocabulary Domains
 
 
 
 
 
* A coded element is any attribute from a v3 static model (RIM, DIM (D-MIM), CIM (R-MIM, HMD, Message Type), LIM (Template, Profile etc.)) or property from a V3 data type model where the type of that attribute or property can be specialized or generalized from the CD (concept descriptor) data type, and collections thereof. Thus, coded attributes are attributes that have a type of concept descriptor (CD), coded simple value (CS), coded value (CV), concept role (CR), coded with equivalents (CE), coded ordinal (CO), character string with code (SC), or physical quantity representation (PQR). Elements with a data type of any (ANY) are also categorized as coded elements because the ANY datatype can be constrained to CD or any of its specializations.
 
 
 
:: why do we have this a bullet point? I'm not even sure what it's trying to accomplish. and I think that while the comment about ANY is potentially true, most people would be confused by it? It's not like we allow a binding on ANY anywhere. Do we? --[[User:GrahameGrieve|GrahameGrieve]] 14:58, 23 February 2008 (CST)
 
 
 
=== Sub-Domains ===
 
 
 
HL7 Concept Domains are defined as a named category of like concepts. The categorization of Concept Domains is hierarchical allowing for further constraint on the breadth of the semantic category covered by the Concept Domain. Such constrained domains are known as “sub-domains”.
 
 
 
Sub-domains allow for further specialization (constraint) on the intended values for a domain.
 
 
 
== Value Sets ==
 
 
 
=== Introduction ===
 
 
 
A Value Set represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
 
 
 
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
 
 
 
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content, and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.
 
Sub-value Sets
 
 
 
A sub-value set is a sub-set of a ”parent” value set.
 
 
 
 
 
=== Value Set Specification ===
 
 
 
Value sets can be specified in two ways, either by enumeration (extension), or definition (intention).
 
 
 
 
 
=== Extensional Value Set Representation (Enumeration) ===
 
 
 
From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an extensional definition is a description of a concept by enumerating all of its subordinate concepts under one criterion of subdivision.
 
 
 
Value sets defined by extension are comprised of an explicitly enumerated set of codes. The simplest case is when the value set consists of only one code.
 
 
 
{| border=1
 
|| Code Value || Description
 
|-
 
|| M || Male
 
|-
 
|| F || Female
 
|-
 
|| U || Unspecified
 
|-
 
|}
 
 
 
 
 
 
 
 
 
More complex variations might relate to hierarchical coding systems such as the following fictitious example:
 
{| border=1
 
|| Code Value || Level || Description
 
|-
 
|| 1123123 || 1 || Education
 
|-
 
|| 1343434 || 2 || Diabetic Education
 
|-
 
|| 1445455 || 2 || Stroke Education
 
|-
 
|| 2135534 || 1 || Counseling
 
|-
 
|| 2344566 || 2 || Emotional
 
|-
 
|| 3456663 || 2 || Daily Living
 
|-
 
|}
 
 
 
 
 
 
 
===Intensional Value Set Definition (Definition)===
 
 
 
From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an intensional definition describes the intension of a concept by stating the superordinate concept and the delimiting characteristics.
 
 
 
Value sets defined by intension are value sets that are defined by a computable expression that can be resolved to an exact list of codes.
 
 
 
For example, an intensional value set definition might be defined as, “All SNOMED CT concepts that are children of the SNOMED CT concept ‘Diabetes Mellitus.’”
 
 
 
Some common strategies used to define intensional values sets include:
 
### Reference a head concept and its subordinate concepts in a hierarchy.
 
### Reference only the concepts subordinate to a head code (and not the head code itself).
 
### Create arbitrarily complex unions, intersections, and exclusions of the two previously described types of value sets.
 
### Other mechanisms, including statements created using a rich expression language.
 
 
 
 
 
===Nested Value Sets ===
 
 
 
When a Value Set Entry references another Value Set, the child value set is referred to as a ''Nested Value Set.''  There is no preset limit to the level of nesting allowed within value sets.  Value sets cannot contain themselves, or any of their ancestors (i.e. they cannot be defined recursively).
 
 
 
Intensional Value Sets can be defined by either fixing the Value Set definition to a specific version of the Code System (when the Code System supports versioning), or by decoupling the Value Set definition from the version of the code system.  This seemingly subtle variation can have very significant impact on the final list of concepts which the Value Set ultimately resolves to.
 
 
 
When the Value Set definition is tied to the version of the Code System, the value set content will remain fixed when instantiated.  When the Value Set definition is independent of Code System version, the content of the Value Set can vary as the Value Set is resolved against different versions of the Code System.
 
 
 
 
 
===Value Set / Code System Relationship ===
 
 
 
Whether specified extensionally, intensionally or both, a Value Set can contain concepts from one or more code systems.  While drawing concepts from multiple code systems in many cases is desirable, care must be taken to ensure that a given meaning is only represented by a code or codes from a single code system.  For example, it would be inappropriate to create value set where a given orderable item like a hematocrit could be represented by a CPT code and also by a LOINC code.  If a single concept (meaning) ends up being represented by more than one code in a Value Set in this manner, it allows for the possibility that the same information can be recorded in two different ways. This can lead to confusion and error in analyzing the recored data.
 
 
 
On the other hand, a value set ''<u>is''</u> allowed to contain more than one code for a given concept as long as both codes are drawn from the same code system. For example, in the UCUM coding system “l” and “L” are both codes for liter.  While this is undesirable, it is permitted for a value set to have both codes as members of the set.  When this occurs, the codes are referred to as ''synonyms''.
 
 
 
===Value Set Versioning ===
 
 
 
Value sets are versioned.  The version of a value set changes when:
 
# For enumerated value sets
 
## Any allowed values are added or deleted
 
# For intensionaly defined value sets
 
## If the logic of the defining expression changes
 
Changes that correct the spelling of terms, or additions of terms that do not add new codes to the value set, do not cause the version to change.
 
 
 
There are multiple strategies for tracking value set versions.  Two of the most common are:
 
# Increment the version number each time a change is made to the value set.
 
# Track add/modification dates for each change to the value set.
 
 
 
By a vote of the Vocabulary TC on September 15, 2006 at the Boca Raton meetings, it was decided that HL7 will reference all value set versions based on effective date and not by available date or by a version number.  This policy has the following implications:
 
# For enumerated value sets maintained by HL7, the activation date and inactivation date for individual codes in the value set must be maintained as part of the value set database.
 
# For intensionally defined value sets in the HL7 value set database, the activation date and superceded date must be recorded (tracked) each time the logic of the definition is changed.
 
# For externally maintained terminologies that have named/numbered releases, a table must be maintained that shows the modification dates for the named/numbered release.
 
# For externally maintained terminologies that maintain modification dates for each individual code change, no additional information is needed.
 
 
 
 
 
 
 
 
 
 
 
Items left to do [tk]:
 
more complete description/definition of Coded attributes in static models
 
  Properties of these coded attributes
 
  Binding to concept domains in the static models
 
  links to the conformance section
 
 
 
= Type Representation =
 
 
 
All HL7 models are constraints on a reference model built from
 
the classes defined in the RIM and the datatypes defined in the
 
abstract datatypes.
 
 
 
This reference model is further constrained by additional
 
constraint models that associate new names for particular
 
constraints on the associations and classes. These constraint
 
models may come from a linear sequence of constraints where
 
each model is an additional constraint on another model (and
 
when the instance conforms to a model it also conforms to the
 
models on which that model is derived), or an instance may
 
conform to multiple different constraints that are not related
 
to each other.
 
 
 
So any given type is an instance of the class or datatype
 
as specified in the reference model, while at the same time
 
conforming to multiple other different design specifications
 
within this cascading hierarchy of models.
 
 
 
All classes and datatypes SHALL declare conformance to a single
 
master type. This requirement exists to ease the path
 
of implementations in common target technologies. The
 
type as a duple: the name of the model, and the name of the
 
type/constraint definition in the model. Both the name of
 
the model and the name of the type may be defined by some
 
applicable design contract rather than expressed directly
 
as an attribute of the class.
 
 
 
ITSs that describe how to represent V3 models SHALL make clear
 
how the both parts of the type may be determined from examination
 
of the instance, and what other resources are required at design
 
and/or runtime to unambiguously resolve the type of the class or
 
datatype.
 
 
 
'''Note''': The InfrastructureRoot class in the RIM defines
 
the notional attribute typeId to represent the type of the
 
class. ITSs are not required to represent this attribute
 
directly; some other method of representation may be chosen
 
that is more appropriate with the base technology and consistent
 
with the way the ITS specifies that the type information is
 
determined from the instance.
 
 
 
For classes, the type need not be the type from a reference model;
 
the context may specify that the expressed type is a name
 
taken from one of the applicable constraining model. As a consequence,
 
there are three types of models applicable to classes:
 
 
 
===  Expressed Models ===
 
 
 
The expressed model is the model that contains the type expressed
 
by the class.
 
 
 
'''Note''': The existing XML ITS fixes the expressed model throughout the
 
instance to be the static model associated with the interaction identifier
 
specified in the root element of the interaction (or from "ClinicalDocument"
 
for CDA). The type of a class is not usually represented directly; instead
 
the names of the associations in the expressed model are used, and the type
 
is determined by implication from the association name. For choices, elements
 
of the type name may be pre-coordinated with the association name in the instance.
 
 
 
'''Note''': Only complete, implementable models with one entry point (CIMs and some LIMs) may be
 
used as expressed models.
 
 
 
=== Implied Models ===
 
 
 
The implied models are specified by the derivations contained in the definition of
 
the expressed model. All expressed models SHALL specify derivations from the RIM.
 
Additional derivations from other models may also be specified.
 
 
 
'''Note''': this means that the RIM is always an expressed or applied model.
 
 
 
'''Implementation Note''': A processor can correlate the instance data against an
 
implied model by reading the full static model for the expressed model and tracing
 
the derivations from the expressed model to the implied model of choice. This can
 
also be done by the developer by hard coding the derivations in the application.
 
HL7 XML ITS schemas also provide a partial link to the RIM level definition. The
 
implied RIM model is of such consequence that a separate pattern for identifying
 
the RIM classes in the instance exists, using structural codes.
 
 
 
=== Applied Models ===
 
 
 
Are other models to which the class conforms to but are not explicit or implicit
 
in the type the the class conforms to. These models are usually known as templates.
 
The applied model may be invoked explicitly in in the instance, or by specifying it
 
in some form of design contract (e.g. interaction profile). Note that it is not
 
necessary to declare all the constraint models that a class conforms to.
 
 
 
'''Note''': The InfrastructureRoot class defines an attribute called templateId which
 
is used to represent the set of applied models that a class conforms to. Like the typeId
 
attribute, the templateId is notional; ITSs may define alternate methods for representation
 
of the applied models.
 
 
 
ITSs that describe how to represent V3 models SHALL make clear
 
how the applied models may be determined from examination
 
of the instance, and what other resources are required at design
 
and/or runtime to unambiguously resolve the applied models.
 
 
 
'''Note''': If an applied model specifies derivations, then the models specified in
 
the derivations are also implied models.
 
 
 
'''Reference''': The templates specification should be consulted for further
 
template related information.
 
 
 
== Datatype Flavors ==
 
 
 
For datatypes, the type must be the type from the reference model; the expressed
 
model is always that specified in the abstract datatypes. This policy exists to ensure that implementations
 
of the datatypes are robust for use in all the environments that V3 is used.
 
 
 
Datatypes may also have additional constraints associated with them. These
 
constraints are referred to as datatype flavors. Datatype flavors are
 
very similar to applied models, but only one flavor can be specified.
 
 
 
'''Reference''': The Refinement, Constraint and Localisation should be
 
consulted for further information about datatypes flavors.
 
 
 
= Null Flavor =
 
 
 
It is common to encounter missing or incomplete information in healthcare. In some
 
circumstances, why, how, or in what way the information is missing or incomplete may have
 
some semantic significance that may make a difference to the workflow or clinical
 
management the depends on the information.
 
 
 
For this reason all datatypes and RIM classes have a property called "nullFlavor"
 
which specifies why the information does not exist, is not known or available, or
 
cannot be expressed in the allowed value domain.
 
 
 
This table summarises the currently accepted values that the nullFlavor property
 
may have it is not null:
 
 
 
-- insert null flavor table here --
 
 
 
A datatype or a class is known as a "null" class if it has a value for it's
 
nullFlavor property. Null values are also known as "exceptional values". Null
 
values are improper values that do not conform to the
 
proper or expected value domain as described by the applicable specification
 
(usually any model that the type claims conformance too - see typing below).
 
The information may either be missing or partially present, or even completely
 
present but not valid with respect to the constraints imposed by the models
 
it conforms to. While null values may not conform to the "proper or expected value domain" as
 
described by the specification, they must nevertheless conform to all the rules
 
specified by the specifications to which they conform, null values SHALL only
 
be used as specified by the models, both in regard to where and how they are used.
 
 
 
In this sense, null is used to create a two level conformance strategy. In some
 
cases, a properly acceptable value domain is defined, and only information
 
that completely conforms to the specified value domain may be provided. In other
 
cases, a properly acceptable value domain is defined, and some information must
 
be provided, but it may not conform to the narrow value domain if it explicitly
 
declares that it does not conform. See the conformance section for further details.
 
 
 
== Note about the name nullFlavor ==
 
 
 
The property is named nullFlavor because of the similarities between the concept
 
of a null value and the concept and behaviour of null in implementation technologies,
 
particularly SQL and OCL. As in SQL and OCL, the value null is in the value domain
 
of the all the types, and nulFlavors will generally propagate through operations
 
such as comparison (i.e. the result of a comparison operation between a null value
 
and some other value is null).
 
 
 
However there are some important differences between the implementation of nulls
 
in such technologies and the HL7 nullFlavor. Most notably, in most implementation
 
technologies, a null instance has no further information associated with it (some
 
variation of the concept of a null pointer). This is not true of the HL7 concept
 
of null; if a datatype or class is null, the nullFlavor property is not null, and
 
any of the other properties might not be null.
 
 
 
Note: the nullFlavor property functions in a reverse sense to the data type or
 
class; if the value is not null the nullFlavor will be null, and if the value
 
is null, then the nullFlavor is not null - it will specify an actual nullFlavor
 
that provides more detail as to in what way or why no proper value is supplied.
 
 
 
Note: In OCL, null is an instance of OclVoid which is a super type of all types.
 
nullFlavor is not modelled the same way in HL7: a null value is still a valid
 
instance of a particular type (see types below). If a true null is encountered
 
in an implementation environment (i.e. the class is not represented in the XML
 
when using the XML ITS, or is present with an xsi:nil="true" attribute), it is
 
semantically equivalent to a null-value of NI, and all other properties not
 
related to nullFlavor will also have nullFlavor NI.
 
 
 
== Implementation Considerations ==
 
 
 
When performing operations upon null values, the semantic meaning of the nullFlavor
 
SHALL be considered. This is particularly important for equality. The only case
 
where non-proper (NULL) values may be equal is where both values have a nullFlavor
 
of NA and all other properties equal. In all most other cases, the outcome of
 
comparing NULL values is also null. However, there are exceptions based on the
 
semantic meaning of nullFlavor. For instance, in the datatypes, although direct
 
comparison of two values with nullFlavor PINF is always null (NI), two intervals
 
with the equal low bounds and high bounds of PINF will return true, since they
 
specify the same set. Similarly, comparison of NINF and PINF is always False.
 
 
 
The "actual value" refers to the value of the information itself, rather than the
 
information as represented in the type itself. These two may diverge when the
 
information provided is incomplete, such as when an expression is provided. The
 
null flavor "other" is used whenever the actual value is not in the required
 
value domain: this may occur, for example, when the value exceeds some
 
constraints that are defined in too restrictive a manner. For example, if the
 
value for age is 100 yrs, but the constraining model specifies that the age
 
must be less than 100 years, the age may still be specified, provided that
 
the model does not make the attribute mandatory.
 
 
 
<value nullFlavor="OTH" value="120" unit="yr"/>
 
 
 
Some of the null flavors are not generally applicable to all circumstances. The
 
nullFlavors NINF, PINF, QS, and TRC SHALL only be used in associated with
 
datatypes that are a specialisation of the QTY type. The nullFlavor UNC SHALL
 
only be used with any data type that has an originalText, and when UNC is used
 
the originalText property SHALL be populated. The nullFlavor DER SHALL only
 
be used with the EXPR type, and an expression SHALL be provided.
 
 
 
NOTE: NULL-flavors are potentially applicable to any class, any data type, and
 
any property of a data value. Where the difference of null flavors is not
 
semantically significant, ITS are not required to represent them. (this is usually
 
appropriate for structural attributes in the RIM classes, and simple properties
 
of the datatypes).
 
 
 
= Update control =
 
 
 
HL7 Static models are used to represent information about
 
the real world when it is exchanged between systems. The
 
objects in the instance represent real world concepts about which a certain
 
amount of information is known.
 
 
 
'''Snapshot''': A methodology in which the sending system includes all the data it has into the message with no specific indications of which data items were added, replaced, or removed. The term was chosen because the source system sends a “snapshot” of the objects as it knows them.
 
 
 
Snapshot is typically used when information is exchanged between systems where the destination
 
system is not known, or where it is not clear how much information
 
the destination system already has about the real world concept.
 
 
 
When a receiving application processes an object that is represented using
 
a snap shot, and it already has information about the real world
 
concept that matches this object, the application should match
 
objects in the instance with the information it already has,
 
and then appropriately process the information from the message to the information it has on file
 
(for instance, in some cases it would make sense to merge all the attributes and associations of the objects).
 
 
 
Potential Advantages:
 
* Can be easier for senders to implement
 
* Many sending systems implement Version 2 messages in this fashion
 
Potential Disadvantages:
 
* Typically more complicated for receivers to process appropriately
 
* Easier for relevant data to be deleted
 
 
 
'''Update mode''': A methodology in which the message designer specifies the allowable update mode values for items within the message and the message sender specifies the specific update mode value for items for items within the message.
 
 
 
However in some contexts, the destination system is well known and there
 
is an implicit or explicit contract between the source and
 
destination systems that ensures the information the destination system
 
holds is well known to the source system. In such contexts, it is
 
possible to only send the changes that have occurred on the source
 
system or should occur on the destination system. These
 
changes may be additions, deletions, and revisions to existing data.
 
This practice is known as "update" mode.
 
 
 
Another use for update mode is where the source application includes
 
all the same data items in the message specification as it would for
 
snapshot node, but marks each value for each data item in the message
 
specification that indicates whether it is added, replaces another item,
 
or has not changed.
 
 
 
Where update mode can be used, it offers several advantages.
 
Potential Advantages (depending how it is used):
 
* reduced instance size
 
* The receiver does not need to compare data to determine what changes the sender has made
 
* Where the receiver gathers data from multiple sources, it does not need to store ‘images’ of data received from a particular sender to ensure that it can adequately compare to the previously sent data when determining changes
 
* reduced processing time
 
* simpler implementation decision making
 
* Conveys important information for how the sending system has processed the information
 
* Query responses are able to document accountability information in terms of what changes were performed (see accountability below).
 
 
 
Potential Disadvantages:
 
* update mode offers the opportunity for two systems to get information out of sync, so modellers and implementors should always be careful.
 
* Typically requires for effort for the source system
 
 
 
The normal mode for V3 instances is snapshot; update mode is
 
only allowed when the [[constraining model]] design specifically allows
 
update mode.
 
 
 
Update Control interpretation depends on the context of the message type:
 
 
 
# When used in a message driven by a state-transition notification or a state-transition fulfillment request trigger event (where the focal class is an object owned by the sending system), the update control represents the change that occurred on the sending system as a result of the state change associated with the trigger event. The recipient is not bound to make the same changes as those done on the sending system.
 
# When used in a message driven by a state-transition request trigger event (where the focal class is an object owned by the receiving system), the update control represents the change that is desired by the sending system as a result of that trigger event. If the recipient accepts the request, they must make the requested changes.
 
# When used in a query response message, the update control represents the most recent change that has occurred to the sender’s object within back to a specified time. The committee may allow the time from which changes are reported to be specified by a query parameter or fixed by the query definition. If not otherwise specified, the start time is the first time the system became aware of the object.
 
 
 
= Referencing Objects =
 
 
 
When the destination system is well known and there is an implicit or explicit
 
contract between the source and destination systems that ensures the information
 
the destination system holds is well known to the source system, the destination
 
system may simply wish to refer to an object rather than providing full details
 
of the object. Rather than updating the object in either snapshot or update mode,
 
the destination system should use the information provided to identify an
 
existing instance of data.
 
 
 
It is not necessary for the destination system to already have information, only
 
for the system or the appropriate users to know how to locate the information
 
that the reference pertains to.
 
 
 
For this reason the concept of referencing objects is more widespread than the
 
use of update mode. Nevertheless, the concept of reference is tightly related to
 
the concept of update mode - an object will either be passed in as a snapshot,
 
an update, or a reference.
 
 
 
Although complex scenarios involve mixes of these modes can be envisaged, HL7
 
does not support mixing these in order to keep the processing complexity from
 
getting out of control. If an object is passed a reference, there SHALL be no
 
expectation that any updates to the object may occur. If an object is represented
 
using update Mode, any information provided as part of the object that has no
 
associated update instructions SHALL be ignored.
 
 
 
= Identifying Objects =
 
 
 
Whether an object is being conveyed using snapshot mode, update mode,
 
or as a reference, the key first step for most processing systems
 
is to correctly locate an existing record for the concept that
 
the object represents, if one exists.
 
 
 
In order to accomplish this, the system must correctly identify the
 
object. In most cases, the identification will be implicit or explicit
 
in the contracts that control the system communication. However in some
 
cases it will be necessary for the source system to clearly
 
identify the attributes that should be used to identify the object.
 
 
 
For example, a source system may wish to indicate which of several
 
identifiers associated with an object should be used to identify
 
the object. In this case, the semantic properties of the identifier
 
itself - scope and reliability - are generally preferred as the criteria
 
for choosing which identifier should be used, but in a few cases it
 
may be necessary to clearly identify a particular information.
 
 
 
Another case is where the source systems does not know the relevant
 
identifiers for the object, but is able to define some key criteria
 
for identification of the concept. For instance, the source system
 
may know that the patient had an episode of care on a given date, but
 
not the identifier assigned to the episode of care by any relevant
 
system.
 
 
 
Source systems are able to clearly identify the attributes of an
 
object that it expects should be used to identify the object correctly.
 
 
 
The general implication of these rules is that when an object
 
is sent using update mode or as a reference, only the information
 
that is required in order to correctly identify the object is sent,
 
along with any specific updates for update mode, and that all the
 
information provided should be clearly labelled. However it isn't
 
always clear how much information is required to correctly identify the
 
reference, so additional useful information is always allowed. Generally
 
it would be expected that this additional information would be of
 
use in some human intervention procedure if automated resolution of
 
the reference failed.
 
 
 
Data types are not subject to identification - the full value of the
 
datatype is itself the identity of the value.
 
 
 
In the absence of any explicit agreement or information in the
 
instance, the default method for resolving identity is that all of
 
identifiers in the objects id field must match the record on the
 
destination system.
 
 
 
= Update Mode =
 
 
 
HL7 provides a single property called updateMode to support the concepts
 
defined in Update Control, Referencing Objects, and Identifying Objects.
 
 
 
'''Note''': a more appropriate name might be useCode, but the property name
 
is updateMode for backwards compatibility reasons.
 
 
 
'''Note''': The updateMode property actually applies to associations and attributes,
 
not to classes and datatypes, though it is formally defined on the types.
 
 
 
The value of the updateMode property identifies how the attribute or
 
association contributes to the processing of the instance. HL7 models
 
strictly control the use of the updateMode attribute; it may only
 
be populated with a value that the [[constraining model (internal reference)]]
 
allows. If there is no value, then the constraining model should be consulted
 
for guidance on how the instance should be processed.
 
 
 
The updateMode property can have one of the following values:
 
 
 
{| class="wikitable"
 
|-
 
! Code
 
! Name
 
! Description
 
|-
 
| A
 
| Add
 
| The item was (or is to be) added, having not been present immediately before. ''(If it is already present, this may be treated as an error condition.)''
 
|-
 
| D
 
| Delete
 
| The item was (or is to be) removed (sometimes referred to as deleted). ''If the item is part of a collection, delete any matching items.''
 
|-
 
| R
 
| Replace
 
| The item existed previously and has (or is to be) revised. ''(If an item does not already exist, this may be treated as an error condition.)''
 
|-
 
| AR
 
| Add or Replace
 
| The item was (or is to be) either added or replaced. --''[Delete: (This option is included to support one specific case, discussed below. Its general use is discouraged, the preferred methodology is to use the combination of the individual Add and Replace values.)]''--
 
|-
 
| N
 
| No Change
 
| There was (or is to be) no change to the item. This is primarily used when this element has not changed, but other attributes in the instance have changed.
 
|-
 
| U
 
| Unknown
 
| It is not specified whether or what kind of change has occurred to the item, or whether the item is present as a reference or identifying property. ''(replaces: It’s not specified whether the item was (or is to be) added, revised, or not changed.)''
 
 
 
|-
 
| ''REF''
 
| ''reference''
 
| ''This item provides enough information to allow a processing system to locate the full applicable record by identifying the object.''
 
 
 
|-
 
| ''K''
 
| ''Key''
 
| ''This item is part of the identifying information for this object.''
 
 
 
|}
 
 
 
Notes:
 
 
 
# Portions requiring harmonisation proposals in italics
 
# R and AR may not be applied to multiple attribute values within a DSET, BAG or LIST. If a single attribute value is marked with a R is used to update a collection, the single value replaces all the items in the collection
 
# REF may only be applied to associations, not attributes.
 
# U is semantically equivalent to a nullFlavor of NI. However due to some methodological issues in V3, a specific code is required to in some circumstances.
 
# If an item is deleted from a collection, all matching items should be deleted from the collection
 
 
 
== Model Designer Guidance ==
 
 
 
This section is intended for people designing static models, typically HL7 domain committees.
 
 
 
When designing a model, a committee may allow UpdateMode to be used on attributes and associations identified by the committee. To enable UpdateMode, the committee must select the set of permitted updateMode values.
 
 
 
In addition to identifying the allowed set of values, the committee may also choose to identify a ‘default’ updateMode for the attribute or association. This is the updateMode that will be assumed by the receiver if none is specified in the instance.
 
 
 
updateMode of “Replace” is not permitted on Entity.id, Role.id, Participation.id and Act.id attribute. If an identifier was captured erroneously, the incorrect submission should be nullified and the record resubmitted with the correct identifier. If a new identifier has been issued, replacing the old identifier, this should be handled as a supersedes or replaces relationship between the class with the old identifier and the class with the new identifier.
 
 
 
If no UpdateMode set is enabled for an attribute or association, it is the same as if the UpdateMode were set to ‘Unknown’. The effective behavior is that of ‘Snapshot’. I.e. the current element value is specified with no indication of whether it was changed or not.
 
 
 
The allowed UpdateMode set available for RIM attributes is empty by default. This means that committees must specifically enable UpdateMode by declaring an allowed set of Update Modes within their design for each attribute or association in their DIM where they want them to be used. Once an UpdateMode set has been defined in the DIM, any derived models (CIM, serialized static models or serialized message models). I.e. Update Modes may be removed from the allowed set, but never added.
 
 
 
If a committee defines update modes for a particular attribute or association, implementers must support the allowed update mode set to be conformant. (Failure to support the complete set defined by the committee may result in interoperability problems.) Implementers should be able to document what update modes they support in their conformance profile, but failure to support those identified by the committee that defined the artifact is considered non-conformant.
 
 
 
The committee does not need to define a default update mode, and may define a default at any derived model. Once a default is defined, it may not be removed or changed in any subsequently derived models. I.e. if a default is defined in an R-MIM, it may not be changed or removed in serialized static models or Message Types derived from that R-MIM. Because of this restriction, committees are discouraged from defining a default UpdateMode at the DIM level.
 
 
 
Update modes should not be specified in templates, as they are intended to be used across multiple different static models that make their own rules about use of updateMode.
 
 
 
Notes:
 
 
 
# UpdateMode is not a concept that should appear in all, or even in most models developed by committees. It should be treated as an ‘advanced modeling concept’, and only employed in models where the facilitator is certain that the concept is needed to adequately reflect the needs identified by their committee. Furthermore it should only be enabled on those attributes or associations where there is an identified need. When a facilitator has identified a perceived requirement for UpdateMode in their model, they are encouraged to bring the requirement to the Modeling and Methodology Technical Committee for review.
 
# UpdateMode will primarily be used for trigger events where the state transition is “revise” and for query responses; however, it may be appropriate in other circumstances. Committees are encouraged to discuss additional patterns for usage so that they may be reflected in this document.
 
# UpdateMode should not be enabled in Transmission or ControlAct wrappers.
 
# There is no way to Remove a single element from a BAG where there are multiple matching elements because there is no means to indicate which occurrence within the bag is to be removed.
 
# Id attributes should never be sent with an UpdateMode of Replace. If such a use-case arises, it will addressed as a future methodology change.
 
# Classes that do not carry an id attribute cannot be identified at all.
 
 
 
= Accountability =
 
 
 
In addition to using update Mode to describe the changes
 
that have happened or should happen, instances can also
 
carry accountability information relating to the information
 
in the message, both associations and attributes. The
 
accountability information can include the time range during
 
which the information was or is valid, and a link to the
 
control act associated with the value. The control act can
 
describe who made the change, when the change was made, what
 
application made the change, and some context for the change
 
in the overall dynamic model.
 
 
 
:: GG: is that last bit true - can you infer anything about the dynamic model from the controlAct?
 
 
 
Generally, this form of accountability history is used in
 
registry-type systems where there is a strong need for the
 
receiver to establish the authority on which a particular
 
piece of data is being changed. Understanding the details
 
can be important in helping a receiver make the determination
 
whether they wish to adopt the change.
 
 
 
Accountability information will be handled by using the HXIT
 
generic type extension. This extension will be applicable to both attributes and to associations. To provide support for accountability information in addition to a time stamps, the HXIT extension will be modified to allow for the presence of either a simple time stamps or a ControlAct.id reference. The reference will allow the changes to an individual attribute or association to be associated with the ControlAct that changed it. The ControlAct can be used to convey such information as event time, author, authoring organization, data-enterer, reason, and any other accountability information deemed to be important.
 
 
 
When working with interactions triggered by a state-transition notification, a state-transition request or a state-transition fulfillment request, the individual ControlAct classes associated with the changes to each attribute or association will be sent as ‘Components’ of the ControlAct in the ControlAct wrapper. When working with query response interactions, the ControlAct classes will be attached to the focal class of the query response via a subject association.
 
 
 
Multiple associations and attributes may reference a single ControlAct, or each may reference a separate one.
 
 
 
Committees must explicitly enable exposing the Accountability History link for a given attribute or association.
 
 
 
= Identification =
 
 
 
One of the founding principles of V3 models is the importance
 
or properly identifying objects and concepts correctly.
 
 
 
== Global Uniqueness ==
 
 
 
All identifiers must be globally unique to prevent false
 
positive comparisons between identifiers.
 
 
 
Globally unique identifiers may be achieved by use of either
 
UUIDs or OIDs. UUIDs are globally unique by virtue of the method
 
of their generation. OIDs are globally unique if the OID registration
 
procedures defined by ISO are followed. A series of local identifiers
 
may be made globally unique by prefixing them with a common global
 
identifier.
 
 
 
The II type has a root, which must be populated, and an extension,
 
which is optional. Together, the root and extension must be globally
 
unique following the logic described above.
 
 
 
'''Note''': there are few specific situations where only a local
 
identifier is available. A typical example is on a point of care
 
device. In these cases, either the context of use assigns a global
 
identifier root, or the identifier is incomplete (some flavor of
 
null).
 
 
 
== OID registry ==
 
 
 
For some concepts, it is not enough that they must be globally
 
unique; the identification must be consistent between a group of
 
systems exchanging v3 instances. Some concepts must be consistently
 
identified within a realm, such as SSN in USA.  Some concepts,
 
notably HL7 defined concepts and some key global things such as
 
ISO standards and ICD-N and SNOMED terminologies need to be consistently
 
identified by pretty much all systems producing and consuming V3 instances.
 
 
 
The only way to produce common consistent identification of these various
 
kinds of objects is to maintain a central system where these identification
 
concepts are registered. HL7 maintains an OID registry for this exact purpose.
 
Any identifiers of interest to HL7 implementers may be registered on the HL7
 
OID registry, which include:
 
* those issued by HL7 that refer to objects or concepts defined by HL7
 
* those issued by HL7 that refer to externally defined objects or concepts
 
* externally issued identifiers that refer to externally defined objects or concepts
 
 
 
Note: The presence of an OID on the HL7 OID registry does not mean that HL7
 
claims responsibility for the concept of object identified, only that it is
 
of interest to some HL7 customer. If the OID is in the HL7 OID branch
 
then HL7 has issued the OID, and accepts responsibility for working
 
with the owner of the object or concept to maintain the identification of the
 
concept.
 
 
 
HL7 assigns an OID to each of its code systems, as well as to external standard
 
coding systems that are being used with HL7 and HL7 Affiliate specifications.
 
In addition, HL7 assigns OIDs in its branch for HL7 users and vendors upon their request. HL7
 
also assigns OIDs to public identifier-assigning authorities both U.S. nationally
 
(e.g., the U.S. State driver license bureaus, U.S. Social Security Administration,
 
HIPAA Provider ID registry, etc.) and internationally (e.g., other country's Social
 
Security Administrations, Citizen ID registries, etc.).
 
 
 
The HL7 registered OIDs SHALL be used for these organizations, regardless whether
 
these organizations have other OIDs assigned from other sources.
 
 
 
:: This needs revision consistent with a recent email exchange between Ted and Grahame to describe a deprecation lifecycle to be used in the conflict resolution procedures discussed below. --[[User:GrahameGrieve|Grahame Grieve]] 23:42, 21 February 2008 (CST)
 
 
 
=== OID Conflict Resolution ===
 
 
 
When assigning OIDs to third parties or entities, HL7 investigates whether an OID is
 
already assigned for such entities through other sources. It this is the case, HL7
 
records the OID in the registry, but HL7 does not assign a duplicate OID in the HL7
 
branch. If possible, HL7 notifies a third party when an OID is being assigned for
 
that party in the HL7 branch.
 
 
 
Though HL7 exercises considerable diligence before assigning an OID in the HL7 branch
 
to third parties, given the lack of a global OID registry mechanism, it's not possible
 
to make absolutely certain that there is no preexisting OID assignment for such
 
third-party entity. Also, a duplicate assignment can happen in the future through
 
another source. If such cases of duplicate assignment become known to HL7, HL7 works
 
to resolve this situation.
 
 
 
== HL7 OID branch ==
 
 
 
The HL7 root OID is 2.16.840.1.113883. All OIDs that HL7 assigns are
 
issued within the space defined by this OID. This OID has immediate
 
sub-spaces as summarised in this table:
 
 
 
{| class="wikitable"
 
|-
 
! Identity
 
! Use
 
|-
 
| 0
 
| HL7 Root OID
 
 
 
|-
 
| 1
 
| HL7 registered internal objects (other than published documents and organizational bodies)
 
 
 
|-
 
| 2
 
| HL7 organizational bodies and groups HL7 Groups
 
 
 
|-
 
| 3
 
| External groups that have been issued an HL7 OID root for their own use
 
 
 
|-
 
| 4
 
| Registered externally maintained identifier systems
 
 
 
|-
 
| 5
 
| HL7 Internal Coding Systems
 
 
 
|-
 
| 6
 
| Registered external coding systems (with an HL7 issued OID)
 
 
 
|-
 
| 7
 
| HL7 published documents (standards, tutorial slides, implementation guides, databases, published RIM graphic billboards, etc)
 
 
 
|-
 
| 8
 
| HL7 OID registered documentation products and artifacts
 
 
 
|-
 
| 9
 
| HL7 Registered conformance profiles
 
 
 
|-
 
| 10
 
| HL7 Registered Templates
 
 
 
|-
 
| 11
 
| HL7 defined and registered Value Sets
 
 
 
|-
 
| 12
 
| HL7 Version 2.x tables as code systems
 
 
 
|-
 
| 13
 
| HL7 Imported value set Coding Systems (imported tables)
 
 
 
|-
 
| 19
 
| HL7 Examples Root used for published examples; meaningless identifier, not to be used for any actual entities
 
 
 
|}
 
 
 
= V3 Conformance =
 
 
 
what goes here? what goes in RCL?
 
 
 
What goes here is foundational material: what is the notion of conformance, and what is it's
 
architecture. How to use it, further considerations etc, belong in RCL. (so RCL
 
has same relationship to this spec as templates, RIM, and datatypes)
 
 
 
== Cardinality & Optionality ==
 
 
 
 
 
=== Testing Considerations ===
 
 
 
== Vocabulary Conformance ==
 
 
 
:  note this is the first set of pasted material, and is now all of the material from the value set binding document.  I have not yet cleaned it up, nor put in the changes from San Antonio. --[[User:Tklein|Tklein]] 18:32, 23 February 2008 (CST)
 
 
 
Vocabulary Conformance consists of defining collections of vocabulary that must be used in coded attributes, identifying the coded attributes and models in which they are located, and declaring the circumstances under which those collections must be used.  Collectively, these are called Vocabulary Binding.
 
 
 
 
 
===Vocabulary Binding===
 
 
 
In order to be implemented and meet conformance, static models containing components intended to contain a coded element must be associated with a value set that can be resolved to all legal values that may be carried in that model component. Such an association is referred to as a vocabulary binding.
 
 
 
 
 
'''Value Set / Concept Domain Relationship'''
 
 
 
There are two mechanisms of binding an attribute or data type property to a value set that HL7 has agreed to support:
 
 
 
''Model Binding:'' this is binding a coded attribute or data type property in a static model directly to a value set. In this case, the concept domain of the ancestor model governs the semantics of the binding. That is, the contents of the value set bound in the child model must be consistent with the concept domain definition in the parent model. Where the corresponding attribute or property in the parent model is a value-set or is a domain which has been bound to a value-set, the value-set bound to the child model attribute or property must be the same or a proper constraint of the parent model value-set.
 
 
 
''Context Binding:'' this is binding a coded attribute or data type property to a collection of data including concept domain and realm that is resolved at runtime to a specific value set by a terminology server. In this case the concept domain and realm are used as keys by a terminology server to resolve the concept domain reference to a single version of a value set. This type of binding is used primarily when the precise desired value set to be bound is not knowable at message design time. Because the realm associated with the instance is identified within the instance, it is possible for a receiver who knows the message specification (and thus the concept domain) to determine the appropriate value-set to validate against.
 
 
 
===Static and Dynamic Binding===
 
 
 
Value set binding can be static or dynamic. ''Static binding'' means that the allowed values of the value set do not change automatically as new values are added to a value set. That is, the binding is to a single version of a value set. ''Dynamic binding'' means that the intent is to have the allowed values for a coded item automatically change (expand or contract) as the value set is maintained over time. This means that for dynamic binding, the binding is to the most current version of the value set in the terminology server at a given point in time.
 
 
 
A static binding is fully specified when the binding references a specific version (date) as well as the value-set OID/unique name
 
 
 
Dynamic binding is fully specified when the binding only references the value-set OID/unique name and does not specify a version date.
 
 
 
'''Un-bound domains'''
 
 
 
In some situations, a Concept Domain referenced in an implementable HL7 static model might not have an applicable binding for the affiliate making use of the model (no universal binding and no Affiliate binding for that affiliate). In that case, the domain is considered to be un-bound. The determination of the set of codes to use remains subject to site-specific negotiation until such time as an applicable binding is created for that affiliate or universally.
 
 
 
'''Additional notes on domains and value-sets'''
 
 
 
'''Concept Domain and Value Set Naming Conventions'''
 
 
 
HL7 concept domains, and value sets will be named according to the following rules:
 
 
 
* All concept domains and value sets will use “camel back” style names.
 
* The name will be restricted to the basic 26-character alphabet and the digits 0-9 using ASCII characters. White space (tabs, spaces), punctuation (periods, commas, colons, semicolons, parentheses, quotes, etc.), underscore, hyphens or other separators are not allowed in the name.
 
* The leading character must be upper-case alpha
 
* Concept domain and concept sub-domain names should be accurate labels for the virtual concepts that they contain.  Concept domain and concept sub-domain names should never include realm or code-system specific information.  The concept domain name should also be independent of the RIM attribute where possible, so that the concept domain can be re-used with different attributes.  For example, a concept domain should be called “HumanGender” rather than “PatientGender” so that the same domain could be bound to the “GuarantorGender” attribute.
 
* Value sets should be named by combining the name of the concept domain and/or other use context that will uniquely identify the value set.
 
 
 
--66.18.217.179 23:13, 13 April 2007 (PDT)Question - can't a value-set be bound to multiple concept domains? If so, wouldn't it be appropriate to name the value-set independent of the concept domain?
 
 
 
* For example, the following would be appropriate names:
 
Concept Domain: HumanGender
 
Value Set: HumanGenderUSRealm
 
 
 
Concept Domain: Country
 
Value Set: CountryFIPS
 
 
 
'''HL7’s Implementation of value sets'''
 
 
 
Value Set can be referenced as either Abstract or Specializable. If a value set is referenced as abstract, the “navigational concept" - the root concept of which all other concepts in the value set are specializations - is not selectable. If specializable, the root concept (head code) is selectable, meaning that highest level concept can be selected without further refinement.
 
 
 
NOTE: Being Abstract or Specializable is not a property of Value Set itself, but is an indication that for any specified context, the Value Set should be referenced as either Abstract or Specializable. --66.18.217.179 23:13, 13 April 2007 (PDT)Question: If Abstract or Specializable isn't a characteristic of the value-set, and it's not declarable as part of the binding, how is it established? Fundamentally, I think this IS a construct of the value-set definition. Two value-sets defined by referencing the same concept and all specializations, one defined as abstract and the other as specializable would be two distinct value-set definitions
 
 
 
 
 
Figure 2 Value Sets
 
 
 
 
 
'''X-Domain (X-Value Set) [Deprecated]'''
 
 
 
“X-Domain” is a misnomer. A more proper name would be “X-Value Sets”, since they are really HL7 defined value sets or sub Value Sets. X-Domains came into existence to address a muddling between the Code System hierarchy and Value Sets. Earlier versions of the vocabulary maintenance tools didn’t distinguish between a Value Set that referenced concepts X, Y and Z and a concept code with subtypes X, Y and Z. The prefix “X-” was added to Value Sets that were intended to represent simple collections, not conceptual hierarchies. A rule was established that new concept codes couldn’t be introduced within an “X-” domain. They first had to be entered elsewhere in the coding scheme hierarchy and then added separately to the “X-” domain. As time permits, all X-Domains will be replaced by Value Sets. --66.18.217.179 23:13, 13 April 2007 (PDT)Comment: Guidance is required on names. At the moment, we continue to use the lower-case x prefix when creating value-sets for structural code systems
 
 
 
 
 
===Value Set Binding in Implementation Guides===
 
 
 
'''Assumptions'''
 
 
 
1. All value sets shall be defined in the HL7 value set database and/or a realm specific value set database that conforms to the HL7 value set design and structure. Value set definitions created by realm affiliates will be kept in the HL7 value set database. Value sets are not defined directly in an implementation guide, they are identified in the implementation guide by reference to the definition of the value set that exists in a value set database.
 
 
 
2. The person or organization that creates and adds the value set to the HL7 value set database shall be responsible for insuring that the content of the value set is maintained.
 
 
 
3. An OID shall be assigned to every value set. OIDs for value sets in the HL7 owned Realms (Universal, Example, and Representative) should be registered in the HL7 OID registry. A value set can optionally be assigned a name. If a value set is maintained in the HL7 value set database and has a name, the name shall be globally unique within the value set namespace, and the name shall be chosen in such a manner as to be descriptive in a globally unique namespace. The value set name shall be different from the name of the Vocabulary Domain. (E.g. “Human Language” would not be an appropriate value-set name, while “USRecognizedIsoHumanLanguages1993” would be an appropriately descriptive name. Value set OIDs and names are unchanging (static) over time.
 
 
 
4. An implementation guide shall identify a value set by reference to its OID. The globally unique name can be included for readability.
 
 
 
5. The creators of an implementation guide may make local names for value sets. If the implementation guide uses local names for value sets, then the implementation guide shall include a table that shows the cross reference from the local name to the OID. Where possible, the globally unique name of the value set from the HL7 value set database will be used as the local name. Local names for the value sets must be unique only within the implementation guide.
 
 
 
6. The implementation guide may contain a copy of the value set definition to facilitate easy review and balloting. The value set definition could be the expression for an intensionally defined value set, or all or part of an enumerated value set. The definition included in the implementation guide is a copy for documentation purposes only, and is not the source of truth for the definition of the value set.
 
 
 
7. For purposes of this discussion, if any part of a value set is intensionally defined, the whole value set is considered to be intensional.
 
 
 
8. A new value set shall be created when the construction policy or versioning policy needs to be different. If, for a similar set of codes, one group needs an enumerated value set and another group needs an intensionally defined value set, two value sets shall be created. The two needs cannot be met by a single value set. This situation might occur if one group wants to control orderable drugs by creating their own formulary list, and a different group wants drugs to be orderable as soon as they become part of a nationally maintained database. These divergent needs can only be met by defining two separate value sets, even though both value sets would contain codes for orderable drugs.
 
 
 
9. Traceability of value set contents over time means that one can determine for a given coded attribute or data type property in a message the exact set of codes that constituted the value set at the time the data was created. Traceability can only be accomplished if, for each coded attribute in the data, the effective date of the value set that was used in data creation is known. (Note: There is currently no field in current message or coded data type specifications to allow communication of the identity and version of the value set in messages. The requirement for traceability needs to be discussed further and the use case for traceability confirmed with the membership of HL7. We may want to add the value set and value set effective date as optional elements of coded data types.)
 
 
 
10. In situations where old and new data are sent using the same message definition and the value set bindings are different in the different eras, the terminology server will use the creation date of the data as one of the parameters for selecting the correct value set for a given message. (Note: There is currently no field in current messages that requires the communication of data creation date in messages. In most cases, Act.author.time would work as a valid surrogate for data creation date.)
 
 
 
11. A degenerate case of Model Constrained static binding exists where there is a need for binding a particular coded attribute to a specific single code. Rather than creating a value set consisting of a single code value, and developing all the supporting administrative machinery, this binding may be accomplished as Single-code binding, which is Model Constrained static binding to a specific code drawn from a specific code system, with optional inclusion of the version date.
 
 
12. There are many kinds of static models that can or will exist in the future, including R-MIMs, CMETs, templates and profiles. All of these models may include binding to concept domains and/or value sets. A given attribute value must conform to all of the value set bindings expressed in all static models or to run time bindings that are applicable for that instance of data. Note that it is possible that different translations present within the attribute may be used to satisfy the binding expectations of different static models.
 
 
 
===Binding Strategies and Syntax===
 
 
 
'''Strategy for Dynamic Model Binding of Value sets'''
 
 
 
This method is used when binding a dynamic value set to a coded attribute or data type property in a static model at design time. Dynamic Model Binding for both extensionally and intensionally defined value sets (native or imported) is accomplished by referencing the OID or the name (or both) of the value set in the binding statement.
 
 
 
 
 
'''Strategy for Static Model Binding of Value Sets'''
 
 
 
This method is used when binding a static value set to a coded attribute or data type property in a static model at design time. Static Model Binding for both extensionally and intensionally defined value sets (native or imported) is accomplished by referencing the value set OID or name (or both) and the effective date of the value set in the binding statement.
 
 
 
 
 
'''Strategy for Model Binding to a Single Code'''
 
 
 
This method is used when binding a single code to a coded attribute or data type property in a static model at design time. The binding is accomplished by stating the code, the code system OID or name (or both) and optionally the effective date of the code system version. --66.18.217.179 23:13, 13 April 2007 (PDT)Question:What's the point of referencing the code system version. When you reference a code, you reference the code independent of version. In an instance, there's no guarantee you'll ever know the version. The semantics of a code are not allowed to change from version to version
 
 
 
 
 
'''Strategy for Context Binding to a Single Code'''
 
 
 
This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a single code in a code set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific coded value:
 
 
 
* The identity of the static model
 
* The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+)
 
* The concept domain that is bound to the coded attribute or data type property
 
 
 
--66.18.217.179 23:13, 13 April 2007 (PDT)Question:What's the point of repeating the concept domain? It's not needed to achieve the binding, and could be FAR broader than the code you're constraining to.
 
 
 
* The binding-realm within which the data exchange is to occur
 
* The code, the code system OID or name (or both) and optionally the effective date of the code system version
 
 
 
--66.18.217.179 23:13, 13 April 2007 (PDT)Question: As above
 
 
 
 
 
'''Strategy for Dynamic Context Binding of Value Sets'''
 
 
 
This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a dynamic value set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific value set:
 
 
 
The identity of the static model The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+) The concept domain that is bound to the coded attribute or data type property --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above The binding-realm within which the data exchange is to occur The OID or name (or both) of the value set
 
 
 
The first three properties are part of the model binding statement for the model. The last two properties are part of the Situation Constrained statement contained in the terminology server. The Binding-Realm is passed in a message instance wrapper (RealmCode); the concept domain, the realm, and the value set must be available to the terminology server, and may be included in an implementation guide. --66.18.217.179 23:13, 13 April 2007 (PDT)RealmCode may be asserted at more than just the root wrapper. There are use-cases where a single message instance will contain content drawn from multiple binding-realms. At the moment, it can be asserted for any class, though MnM has discussed restricting its assertion to model boundaries only (e.g. start of a payload wrapper or CMET).
 
 
 
'''Strategy for Static Context Binding of Value Sets'''
 
 
 
This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a static value set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific value set:
 
 
 
The identity of the static model The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+) The concept domain that is bound to the coded attribute or data type property --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above The binding-realm within which the data exchange is to occur The OID or name (or both) of the value set The effective date of the value set
 
 
 
The first three properties are part of the model binding statement for the model. The last three properties are part of the Situation Constrained statement. The Binding-Realm is passed in a message instance wrapper (RealmCode); the concept domain, the realm, the value set, and the effective date must be available to the terminology server, and may be included in an implementation guide
 
Syntax for Model Constrained Binding of Value Sets to Attributes in Static Models
 
General description of the syntax and reserved words
 
 
 
The key words "SHALL", "SHOULD", and “MAY” in this syntax are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. Furthermore,
 
 
 
SHALL equates to CNE as defined in other HL7 documents SHOULD equates to CWE as defined in other HL7 documents
 
 
 
The keywords "DYNAMIC" and "STATIC" shall be interpreted as defined above. For CDA, pathName is a standard XPath statement. The name of the immediate containing structure is assumed to be known and is not explicitly stated in the pathName.
 
 
 
For V3 messaging, pathname should be a fully qualified reference to an attribute in the static model. [Note: We need a standard syntax for making a fully qualified pathName.] --66.18.217.179 23:13, 13 April 2007 (PDT) Suggest (ClassName.attributeName[.datatypePropertyName]+) :>
 
Narrative Syntax for Model Constrained dynamic binding:
 
 
 
The value for (“pathName of coded element”) (SHALL | SHOULD) be selected from ValueSet ([valueSetOID] | [valueSetName] [OR ([valueSetOID] | [valueSetName]]) DYNAMIC
 
 
 
ValueSetOID or valueSetName must be present. No value set name can be named “DYNAMIC” or “OR”.
 
 
 
If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.
 
 
 
Examples of Dynamic Model Binding:
 
 
 
The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode DYNAMIC.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode OR ValueSet 1.2.34.1.26 SnomedCtDocumentTypeCode DYNAMIC.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode DYNAMIC.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 DYNAMIC.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHOULD be selected from ValueSet LoincDocumentTypeCode DYNAMIC.
 
 
 
 
 
Table form for Model Constrained dynamic binding
 
{| BORDER=1
 
|| ELEMENT IDENTIFICATION || STRENGTH || VALUE SET OID || VALUESETNAME || FLEXIBILITY
 
|-
 
|| CLINICALDOCUMENT/CODE || SHALL || 2.16.840.1.113883.11.217892 || LOINCDOCUMENTTYPECODE || DYNAMIC
 
|-
 
|| CLINICALDOCUMENT/CODE || SHALL || 2.16.840.1.113883.11.XXXXX || SNOMEDCTDOCUMENTTYPE CODE || DYNAMIC
 
|-
 
|| CLINICALDOCUMENT/CODE || SHOULD || 2.16.840.1.113883.11.217892 || LOINCDOCUMENTTYPECODE || DYNAMIC
 
|-
 
|| CLINICALDOCUMENT/CODE || SHALL || 2.16.840.1.113883.11.217892 ||  || DYNAMIC
 
|-
 
|| CLINICALDOCUMENT/CODE || SHOULD ||  || LOINCDOCUMENTTYPECODE || DYNAMIC
 
|-
 
|}
 
 
 
 
 
 
 
''''Narrative Syntax for Static Model binding:''''
 
 
 
The value for (“pathName of coded element”) (SHALL | SHOULD) be selected from ValueSet ([valueSetOID] | [valueSetName] [OR ([valueSetOID] | [valueSetName]]) STATIC (valueSetEffectiveDate)
 
 
 
ValueSetOID or valueSetName must be present.  No value set name can be named “STATIC” or “OR”.
 
 
 
If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.
 
 
 
ValueSetEffectiveDate will be specified with the literal syntax for the XML ITS of the HL7 Version 3 Point in Time (TS) data type.
 
 
 
''Examples of Static Model Binding:''
 
 
 
The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode STATIC 20061017.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode OR ValueSet 1.2.34.1.26 SnomedCtDocumentTypeCode STATIC 20061017.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode STATIC 20061017.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 STATIC 20061017.
 
 
 
Or
 
 
 
The value for “ClinicalDocument/code” SHOULD be selected from ValueSet LoincDocumentTypeCode STATIC 20061017.
 
 
 
Table form for Static Model Binding
 
{| border=1
 
|| Path || Strength || Value Set OID || Name || Flexibility || Effective
 
Date
 
|-
 
|| ClinicalDocument/code || shall || 2.16.840.1.113883.11.217892 || LoincDocumentTypeCode || static || 20061017
 
|-
 
|| ClinicalDocument/code || shall || 2.16.840.1.113883.11.XXXXX || SnomedCtDocumentTypeCode || static || 20061017
 
|-
 
|| ClinicalDocument/code || should || 2.16.840.1.113883.11.217892 || LoincDocumentTypeCode || static || 20061017
 
|-
 
|| ClinicalDocument/code || shall || 2.16.840.1.113883.11.217892 ||  || static || 20061017
 
|-
 
|| ClinicalDocument/code || should || 1.2.34.1.25 || LoincDocumentTypeCode || static || 20061017
 
|-
 
|}
 
 
 
 
 
 
 
''''Narrative Syntax for Single-code binding (Static Model Binding to one exact code) ''''
 
 
 
The value for (“pathName of coded element”) SHALL be (code [“displayName”] codeSystemOID [codeSystemName] STATIC [effective date]
 
 
 
The effective date SHALL be specified when it is necessary for distinguishing the proper meaning of the code.
 
 
 
No code system name can be “STATIC”.
 
 
 
''Example for Static Model Binding to one exact code''
 
 
 
The value for “ClinicalDocument/code” SHALL be 42134-7 “DischargeSummary” 2.16.840.1.113883.6.1 LOINC STATIC 20061017.
 
 
 
Table form for Static Model Binding to one exact code
 
{| border=1
 
|| Path || Strength || code || codeSystemOID || codeSystemName || Flexibility || Effective
 
Date
 
|-
 
|| ClinicalDocument/code || shall || 42134-7 || 2.16.840.1.113883.6.1 || LOINC || static || 20061017
 
|-
 
|}
 
 
 
'''Syntax for Context Binding of Value Sets to Concept Domains in Static Models'''
 
 
 
''''General description of the syntax and reserved words''''
 
 
 
Context Binding involves splitting the binding operation into a step that is done at design time, and a step that is done later, at message instance generation time.  At model design time, a coded attribute or datatype property is bound to a concept domain.  There is no flexibility to this binding, but subdomains may be created and attributes bound accordingly as the design is further constrained as described in the V3 Vocabulary Conformance section of the HL7 V3 Standard.  At the time of message instance generation, all coded attributes or datatype properties are either Model Bound to value sets, or Context Bound to an explicit concept domain.
 
 
 
Part of the implementation statement for a particular model will describe the Realm-specific binding of a concept domain to a value set, in much the same way that a coded attribute is bound to a value set in Model Binding.  Therefore, in the Context Binding syntax there are two statements: the first is the binding of a code attribute or datatype property to a concept domain, and the second is the binding of the concept domain to a value set.  The statements must be separate as they are defined at different times and generally by different stakeholders.
 
 
 
The key words "SHALL", "SHOULD", and “MAY” in this syntax are to be interpreted as described in the <u>HL7 Version 3 Publishing Facilitator's Guide</u>.  Furthermore
 
 
 
SHALL equates to CNE as defined in other HL7 documents
 
SHOULD equates to CWE as defined in other HL7 documents
 
 
 
The keywords "DYNAMIC" and "STATIC" shall be interpreted as defined above.
 
 
 
 
 
''''Narrative Syntax for concept domain Dynamic Context Binding:''''
 
 
 
The VocabularyDomain for (“pathName of coded element”) (SHALL ) be (DomainName)
 
The ValueSet for (DomainName) in (RealmName) (SHALL | SHOULD) be ([valueSetOID] | [valueSetName] | [OR ([valueSetOID] | [valueSetName]])  DYNAMIC.
 
 
 
If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.
 
 
 
''Example for concept domain Dynamic Context Binding:''
 
 
 
The ConceptDomain for “DocumentType/code” SHALL be MyDocumentType
 
The ValueSet for MyDocumentType in NorthAmerica SHALL be 2.16.840.1.113883.11.217892  LoincDocumentTypeCode DYNAMIC.
 
 
 
Or
 
 
 
The ConceptDomain for “DocumentType/code” SHALL be MyDocumentType
 
The ValueSet for MyDocumentType in NorthAmerica SHALL be 2.16.840.1.113883.11.217892  LoincDocumentTypeCode Or 2.16.840.1.113883.11.XXXXX  SnomedCtDocumentTypeCode DYNAMIC.
 
 
 
 
 
Table representation of Dynamic Context Binding information in the terminology server:
 
{| border=1
 
|| Model || Path || Domain || Realm || Value Set OID || ValueSetName || Flexibility
 
|-
 
|| TPLTCD3 || DocumentType/code || MyDocumentType || NorthAmerica || 2.16.840.1.113883.11.217892 || LoincDocumentTypeCode || Dynamic
 
|-
 
|}
 
 
 
 
 
Note that the leftmost three columns are the model binding elements, and the rightmost five columns are the context binding elements (the concept domain is the common element)
 
 
 
''''Narrative Syntax for concept domain Static Context Binding:''''
 
 
 
The VocabularyDomain for (“pathName of coded element”) (SHALL) be (DomainName)
 
The ValueSet for (DomainName) in (RealmName) (SHALL | SHOULD) be ([valueSetOID] | [valueSetName] | [OR ([valueSetOID] | [valueSetName]])  STATIC (valueSetEffectiveDate).
 
 
 
If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.
 
 
 
''Example for concept domain Static Context Binding:''
 
 
 
The VocabularyDomain for “DocumentType/code” SHALL be MyDocumentType.
 
The value set for MyDocumentType in NorthAmerica is 2.16.840.1.113883.11.217892  LoincDocumentTypeCode STATIC 20061017
 
 
 
Or
 
 
 
The VocabularyDomain for “DocumentType/code” SHALL be MyDocumentType.
 
The value set for MyDocumentType in NorthAmerica is 2.16.840.1.113883.11.217892  LoincDocumentTypeCode OR 2.16.840.1.113883.11.XXXXX  SnomedCtDocumentTypeCode STATIC 20061017
 
 
 
Table representation of Static Context Binding information in the terminology server:
 
 
 
{| border=1
 
|| Model || Path || Domain || Realm || Value Set OID || ValueSetName || Effective
 
Date || Flexibility
 
|-
 
|| TPLTCD3 || DocumentType/code || MyDocumentType || US || 2.16.840.1.113883.11.217892 || LoincDocumentTypeCode || 20061017 || Static
 
|-
 
|}
 
 
 
 
 
Note that the leftmost three columns are the model binding elements, and the rightmost six columns are the context binding elements (the concept domain is the common element).
 
 
 
 
 
 
 
 
 
 
 
 
 
Other items to be covered:
 
* coding strength
 
 
 
 
 
    :  should the section on Domains be here rather that up in the vocabulary section?  --[[User:Tklein|Tklein]] 18:21, 23 February 2008 (CST)
 
 
 
=introduction to how RIM & datatypes fit together=
 
 
 
 
 
= todo =
 
 
 
from dt ballot: Explain to people how to avoid having non-null empty bags when desired.  (same for list and set)
 

Latest revision as of 15:00, 4 April 2011

Posting on Wiki WITHDRAWN in Its Entirety

This document was originally posted for dicussion prior to the first release of the COre Principles document. Subsequently, this document has gone through four (soon to be five) ballots. The content on this Wiki page has been entirely superseded and has, therefore been removed.

The Ballot content may be available here.

GWBeeler 14:58, 4 April 2011 (UTC)