|
|
| (One intermediate revision by the same user 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)
| |
| − | | |
| − | For HL7, with respect to Vocabulary, '''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. This is also commonly referred to as a ''Binding Realm'', especially where other types of realms are being discussed. 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.
| |
| − | | |
| − | :: Rename this to 'coded element' and put in the definition from the misplaced footnote below; this will improve the definition and make it consistent with the text in the ballot Foundation section. --[[User:Tklein|Tklein]] 14:03, 12 March 2008 (CDT)
| |
| − | | |
| − | == 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
| |
| − | [[Image:VSdocFig1.jpg]]
| |
| − | | |
| − | | |
| − | | |
| − | * 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)
| |
| − | | |
| − | :: This was a footnote in the original document, and it came in as streaming text inline when the paste was done - that is not a bullet, it is a footnote mark. The asterisk was by a former reference to a 'coded element' in the original document, which was removed when we modified the nomenclature to 'coded attribute' in this document. I left this in here because I don't know if we want to keep any of this text somewhere in this document if not in this Vocabulary section; the salient point is that vocabulary is bound in lots of different kinds of models, not just the RIM ones. You can completely remove this if you'd like, or slide it in somewhere else where it might be more appropriate. This should most likely be part of the discussion on 'coded attributes' in the 'to do' list below. --[[User:Tklein|Tklein]] 11:22, 10 March 2008 (CDT)
| |
| − | | |
| − | === 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.
| |
| − | | |
| − | Note that this implies that all value Set specifications must be able to be machine-resolved at a point in time to their contained coded concepts. Another implication is that an HL7 Terminology Service must be able to perform this resolution on any valueSet definition in HL7.
| |
| − | | |
| − | | |
| − | | |
| − | === 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.
| |
| − | | |
| − | 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 whenever it is 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. Note that the resolved content of an intensionally defined value set may change without the value set version changing if the version of the underlying code system(s) are not specified, and those code systems change the coded concepts that are included within the value set.
| |
| − | | |
| − | === 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). Any child value set that is references by this nesting may be either intentinally defined or extensionally defined. For any value set that includes child value sets, if any of the child value sets are intentionally defined, then the containing ('parent') value set is considered to be intentionally defined.
| |
| − | | |
| − | === Sub-value Sets ===
| |
| − | | |
| − | A sub-value set is a sub-set of a ”parent” value set. It is a constraint on the content of a value set such that there are no coded concepts contained in the sub-valueSet that are not also contained with the "parent" valueSet.
| |
| − | | |
| − | ===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 recorded 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.
| |
| − | | |
| − | = Static Models =
| |
| − | Static models are a key artifact in HL7 v3 standards. They define the data that is allowed to be exchanged, persisted or otherwise acted upon. All HL7 v3 static models are strictly derived from a single core reference model called the Reference Information Model (RIM). Through a refinement process, additional static models are produced that more closely approach implementation requirements. These include:
| |
| − | * Domain Information Model (DIM aka DMIM): This style of model represents the information of interest to a particular healthcare domain or topic area. DIMs can have multiple entry points. DIMs can be constructed that represent constraints on previous DIMs. DIMs are generally informative rather than normative as they cannot be implemented directly.
| |
| − | * Constrained Information Model (CIM aka RMIM, HMD or MT): This style of model is serializable and has a single entry. CIMs can be constructed that represent constraints on previous CIMs. CIMs can be normative and are the focus of most HL7 v3 standards.
| |
| − | * Localized Information Model (LIM aka static profile or template): This style of model is identical to a CIM, but has the caveat that it is not intended to be implemented directly. Instead, it is intended to be applied to an implementation of a parent CIM.
| |
| − | | |
| − | Static models can be represented in three different ways, though there are limitations by model type on whether all three mechanisms are possible:
| |
| − | * Flat: In this representation, the model is portrayed as a flat list of classes and associations. No nesting is represented
| |
| − | * Serialized: In this representation, the model is represented in a nested hierarchy, beginning with the root or focal class and traversing associations to cover the entire model. The RIM and most DIMs cannot be serialized due to the presence of multiple entry points.
| |
| − | * Derived: In this representation, the model is represented as a set of constraints on a previous 'parent' model. Knowledge of the parent model is required to make use of the derived model. The RIM cannot be a derived model because there is no 'parent' to the RIM.
| |
| − | | |
| − | == Entry Points ==
| |
| − | All static models have at least one entry point. Entry points identify where serialization is allowed to start. I.e. What classes can be "root" or "focal" classes in a model.
| |
| − | | |
| − | == Classes ==
| |
| − | Classes in HL7 v3 behave the same as classes in any other UML model. They can have attributes and associations. They define the types of objects that may be present in instances, including constraints on those objects. Class specifications can be either ''complete'' or ''incomplete''. Complete classes show all the attributes and associations that belong to that class. Conformant implementations cannot use any attributes or associations not found on the class definition. Incomplete classes show some of the attributes and associations that belong to the class. Conformant implementations must obey the constraints on the attributes and associations listed, but are free to have any other associations or attributes provided those attributes and associations are supported by the RIM.
| |
| − | | |
| − | == Abstract Classes and Choices ==
| |
| − | Some classes are 'abstract' meaning they cannot be implemented directly. Instead they define common properties or characteristics held by their child specialization classes. In the RIM, these abstract and generalization-specialization relationships are represented using typical UML conventions. In all other static model types, abstract classes are represented as "choice" structures. This means that when an instance is constructed, the implementer must choose from among the non-abstract children of the abstract class when determining how to populate the instance. Abstract classes outside the RIM are not allowed to define attributes, though they may have associations. All attributes are found on the concrete specializations. It is possible to have "choices of choices" where an abstract class may be specialized by other abstract classes. Eventually all abstract classes must have non-abstract children.
| |
| − | | |
| − | == Interfaces ==
| |
| − | In some models, there's a need to reference content defined outside the model. In these situations, the model can reference one of two types of interfaces. These interfaces behave in much the same way as choices - they can have inbound associations and can be specializations of abstract classes (i.e. they can be one of the options in a choice structure). However, interfaces are not allowed to have outbound associations. The set of allowed interfaces that can be referenced in a model is defined by an interface definition file (sometimes called "CMETInfo.txt"). This file provides the name and characteristics of the interfaces allowed in a given context. Different interface definitions can exist at the universal, affiliate and other levels of implementation. This allows localization of interface requirements. When making associations to an interface, only associations that are allowed for that "type" of interface in the RIM are supported. For example, a "Participation" class can have an association to an interface with a type of "Act", but not to one with a type of "Entity" because Participations aren't allowed to connect to Entities in the RIM.
| |
| − | | |
| − | === CMETs ===
| |
| − | CMETs are re-usable model "chunks" intended to be referenced from other models. Every CMET interface is bound to a single implementation model in the interface definition file. (It's possible that the implementation model referenced might change over time and/or vary in the interface definition files of different realms). When a CMET is referenced, the designer generally knows exactly what model content will be used, but accepts that design responsibility for that content rests elsewhere and it may change independently of their own model.
| |
| − | | |
| − | === Stubs ===
| |
| − | Stubs are "exit points" to models that allow open ended content to be referenced. This is primarily seen in HL7's use of "wrappers", where a generic model is defined that "wraps" another model. The specific linkage of what model should be inserted at the stub interface is determined during the design of the dynamic model where all of the stubs are bound to other models. For example, in a query response interaction, the transmission wrapper "stub" is bound to a particular control act wrapper. Within the control act wrapper, the query definition and payload "stubs" are bound to the appropriate static models defining the payload and query definition for that interaction.
| |
| − | | |
| − | HL7 methodology (though not yet tooling) allows for CMETs to contain stubs. These are called parameterized CMETs. This allows for CMETs to common structures like patient or provider without including them in CMET model itself. When the CMET is referenced, the model invoking the CMET then binds the stubs within the CMET to classes (or interfaces) declared in the model referencing the CMET.
| |
| − | | |
| − | Unlike CMETs, there isn't a single static model bound in the interface definition file. Instead, two models are referenced. The first identifies the "maximum" set of content that can be conveyed within models bound to the stub. For unconstrained stubs, such as "query response payload", this maximum model could be the RIM. The second model, which is optional, identifies the minimum set of data that must be present within any model bound to the stub. This allows the designer to enforce the presence of certain characteristics such as ids, etc.
| |
| − | | |
| − | == Associations ==
| |
| − | Associations represent the linkage between classes and interfaces in a static model. When serializing a model, serialization occurs by performing a depth-first traversal of all the associations of the classes in a model, starting with the entry point class. In serializable models, all associations must be defined such that they are only traversable in a single direction. In the RIM and some DIMs, associations may be traversable in multiple directions.
| |
| − | | |
| − | === Association traversal names ===
| |
| − | In HL7 static models, the traversal name of an association determines the name of the elements representing that object. Traversal names are frequently influenced by the name of the class the association connects to. When associations are made to abstract classes (choices) or to interfaces (CMETs or Stubs), this naming process becomes a bit more complex.
| |
| − | | |
| − | Choices: Because element names are needed for each of the possible options in a choice structure, an association will have a distinct traversal name for every class in the choice hierarchy. This includes choice hierarchies that pass through interface boundaries. (E.g. a reference to a CMET which itself is rooted in a choice structure.)
| |
| − | | |
| − | CMETs: The association traversal name is determined by the root class of the static model bound to the CMET name in the interface definition file. Because the static model can change over time and by realm, the association traversal name can change as well.
| |
| − | | |
| − | Stubs: The association traversal name is determined by the root class of the model bound to the stub. Because this is not known at design time, the association traversal name uses the stub name in the formal naming algorithm. However, at implementation time once the stub binding is known, the traversal name is changed to the appropriate name based on the root element of the static model bound to the stub.
| |
| − | | |
| − | = 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 in the 9834 series of standards 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. 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 and namespaces, regardless whether
| |
| − | these organizations have other OIDs assigned from other sources.
| |
| − | | |
| − | HL7 will also assign an OIDs in its branch for HL7 users and vendors upon their request. When this is done, the registration authority (RA) for all OIDs under this assigned OID is delegated to the person or organization so assigned. The understanding is that they will have sole responsibility for further OID assignment below their new 'root' and will perform such assignment consistent with the ISO standards governing OIDs. Any objects that are subsequently assigned by these RA delegates may be registered in the HL7 OID registry. Once this is done, then the OID so registered shall be used to identify the object in subsequent HL7 messages.
| |
| − | | |
| − | In some cases, technical errors are made during the OID assignment and registration processes; this should be infrequent, and identified and corrected rapidly. Occasionally however, an OID that has been registered for some time must be retired, and must be replaced with the one that solves the technical difficulty. In these cases, the erroneous OID entry shall be identified as 'Deprecated', and the OID that replaces it shall be identified in the OID registry. After a period of 2 years, the deprecated OID will be set to 'Retired', but the entry and its noted replacement shall remain in the HL7 OID registry.
| |
| − | | |
| − | :: 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)
| |
| − | | |
| − | :: Dunno if this is good enough, change it as you see fit. --[[User:Tklein|Tklein]] 13:21, 10 March 2008 (CDT)
| |
| − | | |
| − | == 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 as Registration Authorities
| |
| − | | |
| − | |-
| |
| − | | 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
| |
| − | |-
| |
| − | | 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
| |
| − | | Externally authored and curated Value Sets, HL7 registered
| |
| − | | |
| − | |-
| |
| − | | 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 may be named by combining the name of the concept domain and/or other use context that will uniquely identify the value set; this is very helpful when a value set is appropriate for only a single subm-domain (which is most often the case). If a value set is expected to be used in more than one concept domain, then a more general name that clearly identifies the usage of the value set should be created.
| |
| − | * 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.
| |
| − | | |
| − | :: I need to go over this fine point with Stan and Russ - we have gone back and forth over this property being part of the value set definition or part of the binding definition. I think it is now in the value set definition, but need to verify. --[[User:Tklein|Tklein]] 12:34, 10 March 2008 (CDT)
| |
| − | | |
| − | | |
| − | Figure 2 Value Sets
| |
| − | [[Image:VSdocFig2.jpg]]
| |
| − | | |
| − | '''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===
| |
| − | | |
| − | '''Strategy for Dynamic Model Binding of Value sets'''
| |
| − | | |
| − | This method is used when binding a value set to a coded attribute or data type property in a static model at design time where the coded content of the value set is generated by terminology services based upon the binding date. 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; the date of the expansion of the value set is the effective time of the model operation on the value set (such as validation).
| |
| − | | |
| − | | |
| − | '''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. The date of the binding statement is the effective date of the expansion of the value set (for intensionally defined value sets).
| |
| − | | |
| − | | |
| − | '''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
| |
| − | :: the code may be retired from a code system, and there are MANY code systems used in HL7 and in the Healthcare IT community that do not follow the rules, and the semantics of a particular code sometimes does change meaning in these. --[[User:Tklein|Tklein]] 12:49, 10 March 2008 (CDT)
| |
| − | | |
| − | '''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 Context Binding statement contained in the terminology server. The Binding-Realm is passed as part of the context as the message is parsed (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).
| |
| − | :: Without getting into the complexities of multiple-thread environment evaluation whilst evaluating all the wrappers and whatever templates are in effect at the time, should this wording be changed from this latest? It is clear that at any point in the parse, a particular coded attribute will have a particular RealmCode in effect at that moment; that is the one to be passed to the terminology server. How should this be worded so that it is not so confusing? --[[User:Tklein|Tklein]] 12:58, 10 March 2008 (CDT)
| |
| − | | |
| − | '''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.
| |
| − | | |
| − | === Binding Syntax===
| |
| − | | |
| − | ====Syntax for Model 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)
| |
