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

Difference between revisions of "Revise existing Foundation Vocabulary Introduction"

From HL7Wiki
Jump to navigation Jump to search
Line 12: Line 12:
 
Modern health care communications and data storage makes heavy use of encoded information. In HL7, this is referred to as '''vocabulary'''.  The HL7 standard defines several different type of objects that implement various characteristics of vocabulary.  Whereas other section of the HL7 standard are primarily concerned with structure, vocabulary deals with content.
 
Modern health care communications and data storage makes heavy use of encoded information. In HL7, this is referred to as '''vocabulary'''.  The HL7 standard defines several different type of objects that implement various characteristics of vocabulary.  Whereas other section of the HL7 standard are primarily concerned with structure, vocabulary deals with content.
  
Consistent with the version 3 philosophy of successively constraining an abstract information model,  the least constrained category in vocabulary is a '''Concept Domain'''.  An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more coded elements.*  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 vocabulary or code system.  
+
Consistent with the version 3 philosophy of successively constraining an abstract information model,  the least constrained category in vocabulary is a '''Concept Domain'''.  [[Revised existing Glossary]] An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more coded elements.*  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 vocabulary or code system.  
  
 
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.
 
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.

Revision as of 20:43, 22 August 2007

The current Vocabulary Introduction section is sufficiently ambiguous that it needs to be updated prior to the next ballot.

The Discussion page is to be used for suggested changes:


Introduction

1.1 Overview

Modern health care communications and data storage makes heavy use of encoded information. In HL7, this is referred to as vocabulary. The HL7 standard defines several different type of objects that implement various characteristics of vocabulary. Whereas other section of the HL7 standard are primarily concerned with structure, vocabulary deals with content.

Consistent with the version 3 philosophy of successively constraining an abstract information model, the least constrained category in vocabulary is a Concept Domain. Revised existing Glossary An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more coded elements.* 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 vocabulary or code system.

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.

At the point that message designers and implementers decide on the specific terminology to represent the information payload of a coded element, a value set is bound to the coded element.


The HL7-defined vocabulary domain tables that have been developed for coded class attributes are stored in the HL7 repository, from which a number of views have been extracted to produce the HL7 Vocabulary Domain Listings for the HL7 Reference Information Model (RIM). The views are presented in table format and include the HL7 Vocabulary Domain Values, the HL7 Domain Tables and Coded Attributes Cross-reference. HL7-recognized external vocabulary domains are described in the External Domains list.

The vocabulary domain name and the associated extensibility qualifier for each coded attribute in the RIM are specified in the RIM narrative. This specification occurs as the first line of the attribute's description in the following format:

Vocabulary Domain: "MyVocabularyDomain" (CWE)

There is a link between the vocabulary domain name in the RIM listing and its entry in the HL7 Vocabulary Domain Values table in this listing.


For those domains that are not yet developed, a domain name has been assigned, but the table contains no values and therefore is not listed here.


Tables included in this representation include:


  • The HL7 Vocabulary Domain Values table is organized alphabetically by domain table name or domain name and includes a mnemonic code, concept identifier, print name, and definition/description for each coded value. (Abstract domains are not assigned a code). The first column of the table contains an integer showing the level of indentation (containment) of the element in that row. The second column contains an indented composite element. The indentation shows the containment hierarchy of the concepts, with child concepts indented below their parent. The opening character of the composite entry indicates whether the concept is: specialized (S) and thus is both coded and contains child concepts; abstract (A) which does not have a code of its own but does contains child concepts; or a leaf term (L) which is coded but contains no children. The concept name for abstract and specializable domains follows the opening character of the composite element. The composite element ends with the mnemonic code for specializable and leaf concepts, offset by parentheses.


The remaining columns of these tables show the unique concept identifier for the row, the mnemonic codes and print names for non-abstract concepts, and the definition of the concept.


The order of the rows is an alphabetic sequence of the domain names at each level of indentation, followed by the leaf terms (in code sequence) at the same level. The children of the abstract and specializable domains are indented below their parents.


  • The External Domains table is organized alphabetically by domain table name and includes the domain name, concept identifier, the source code system, a defining expression for extracting the domain from the source system, and a description.


  • The HL7 Domain Tables and Coded Attributes Cross-reference Table is organized alphabetically by domain table name in column one, and lists the coded RIM attribute(s) and/or the data type components that are supported by that vocabulary domain. For RIM attributes, the data types and assigned coding strength are also shown. Both the RIM attributes and the data type components are hyper-linked to the definition in their respective documents.