HL7 Vocabulary

Modern health care communications and data storage makes heavy use of encoded information. In HL7, this is referred to as vocabulary. The HL7 standards define several different type of objects that implement various characteristics of vocabulary. Whereas other elements of the HL7 standards 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. [Revise and link Master Glossary]: An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more attributes in a static model or properties in datatypes where the data types of those attributes or properties are coded or potentially coded. Concept Domains exist because we want to constrain the intent of a coded element while deferring the association of the element to a specific coded terminology until later in the standards development or implementation 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.

A list of intended values for a concept domain or sub-domain is referred to as a value set. A value set consists of one or more coded concepts. These are the possible concept codes that can be carried in an HL7 Version 3 message in a coded data type . When a value set is associated with given concept domain or sub-domain, this is called "binding". Different value sets can be associated with the same concept domain in different circumstance.

A concept code is only unique within a particular context. As an example, "M" may stand for male in one context and married in a second. The context in which a concept is defined is called a code system. Many code systems already exist in the medical domain, such as ICD-9, SNOMED-CT, etc. Whenever possible, HL7 reuses existing concept codes rather than developing their own.

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 concept domain that was the previous constraint for the coded element, and that value set is asserted as the new constraint for the coded element.

The HL7-defined vocabulary 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 Listings for the HL7 Reference Information Model (RIM). The views are presented in table format and include the HL7 Concept Domains, Code Systems (including, HL7-maintained systems and external systems referenced by HL7), HL7-defined Value Sets, and a Cross Reference between Concept Domains and Coded Attributes.

The Concept 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:

Concept Domain: "MyConceptDomain" (CWE)

There is a link between the concept domain name in the RIM listing and its entry in the HL7 Concept Domain table in this listing.

The Vocabulary that has been defined and bound to models is presented below. There are three primary groups of data that is drawn from the HL7 Vocabulary store. Each set of data consists of an index, with a listing linked to the actual vocabulary entries. Each of those entries is presented in tabular form, specific to the type of vocabulary item being displayed. Each of the sections below contains a guide section immediately below the index which describes in detail the column layout and any keywords and display conventions used for that set of tables. The three index sections are:

• HL7 Concept Domains. This content is organized alphabetically by domain name, and indicates whether the domain has been specialized into one or more sub-domains.

• HL7 Supported Code Systems. This content is organized alphabetically by code system name, and indicates whether the coding system support a RIM attribute with a "coded simple" (CS) data-type, in which case the full content of the code system is expressed here, and the code system contents are subject to ballot as part of a RIM ballot.

• HL7 Value Sets. There are a very large number of HL7 value sets, and the organization of this section is an attempt to improve upon a simple alphabetic listing of thousands of names, many of which are cryptic. Most value sets are based solely or primarily upon one single code system, so this content index is a list of underlying code systems, and is organized alphabetically by the code system that the value set is primarily based on. In cases where a value set includes codes from more than one code system, it may be accessed from either one of the code system entries in this index.

For each of these indexes, clicking on an entry will direct you to a tabular set of data about that entry.

This table provides a handy "index" to the HL7-defined Concept Domains. Only the top level Concept Domains are listed here. Many Concept Domains are specializations of these more general domains, and can be found by first hyper-linking to their ancestor. All concept domains that have a specializations beneath them are shown in bold in this table. The more specific listings are in a single file. For each concept domain, that file shows:

• its textual definition;
• its specializations and generalizations, if any;
• any RIM attributes for which it provides a constraint, along with their data types in parentheses; and
• any value set bindings that are defined for it.

Each of the links in the index above will display the Concept Domain Table for the Concept Domain clicked. Each of the tables is separate, and generated one per Concept Domain. There is one row in the table for the Concept Domain that is in the index, and an additional row for each sub-domain (if any) that has been defined. This continues for deeper levels in those cases where another sub-domain has been defined to further constrain a sub-domain. Each table contains information about the Concept Domain in each column; the columns are numbered in the descriptions below. Note that the column headings for the tables are shown in parentheses.

1. Level (Lvl)

   This column indicates what sub-domain level the row is describing. The first row in each table is '0', indicating that this row is for the parent domain, as listed in the Concept Domain Index. A '1' in this column indicates a sub-domain one level down from the parent, a '2' indicates a sub-domain of a level-1 sub-domain, and so forth.

2. Name and Binding (Concept Domain Name Value Set Binding)

   This column shows the name of the Concept Domain and its Context Bindings, if any. The name is in regular text, and the name of the value set is in italics. Immediately following the name of the value set is the name of the binding context in parentheses and the coding strength of that binding, as either 'CNE' or 'CWE'. For those Concept Domains with a value set Context Bound to the "unclassified" context, it is displayed as (nos); this is an indication that the binding is under discussion in the responsible workgroup, and has not yet had the binding finalized to a Binding Realm. The value set name is hyperlinked to the value set entry in the Value Set Tables. Note also that there are a few entries with a value set OID in italics enclosed in square brackets; this is shown when the value set has no content in its definition. Note that in most of these cases, the name of the value set is the same as the concept domain.

3. Attribute Domain Binding (RIM Attribute)

   This column identifies the RIM attribute (and its data type) that is constrained by the Concept Domain. The name of the RIM attribute is hyperlinked to the attribute in the RIM in this set of documents. The entry in parentheses is the data type, which in every case is a 'CD' or one of its specializations that can carry coded data in V3. Note that in most cases, there is an attribute only for the level 0 Concept Domain; most sub-domains are used in the constraint process in modeling, and are constraints on attributes that have been constrained from the RIM attribute. Also note that in most cases a Concept Domain constrains only a single RIM attribute.

4. Documentation (Definition/Description)

   This column contains all the documentation that has been captured about this Concept Domain. There is a Definition of the Domain, followed by a Discussion or a Description. Note that in some cases there is only the text "Description still needed", which is self-explanatory. In other cases, the cell in the table is blank, indicating that there is no documentation on file for this Concept Domain. The Description may contain Constraints, Examples, and other items of documentation to assist the reader in the understanding of the meaning and use of the Concept Domain.

This table provides a handy "index" to the HL7-supported Code Systems. This list is alphabetically ordered by code system name, and shows all code systems that are identified in the HL7 vocabulary store. Some of these code systems are HL7 authored and maintained, and have their entire code content available here. These are shown in bold in this table. Note that a few externally curated vocabularies that are redistributed by HL7 by agreement with the code system author are also fully available here. Each of these internally maintained code systems is listed in an indivudal html document, one code system per file. These may be accessed by clicking on the hyperlinked name of the coding system in the list. The remaining (externally maintained) code systems are listed together in a separate document, with none of their coded content. Any code system, whether internally maintained or not may be referenced by various value set definitions (see next section).

Each of the links in the index above will connect to a table with the contents of the code systems as archived in the HL7 Vocabulary store. The list above is alphabetical by code system name. Those code system names that are in bold typeface are those that have their codes stored within the HL7 Vocabulary store. This means either that they are code systems authored and maintained by HL7 through the harmonization and balloting process, or they are code systems whose coded content has been mirrored in the HL7 Vocabulary store for convenience. The other code systems are those that are externally maintained, and their entries here are used for various bindings in the models and to the Concept Domains. In these cases, the content is not available in the HL7 Vocabulary store; the terminology publishers of these must be contacted for a copy of their content.

Each of the code system tables is displayed with four columns; the column heading and their display details are described below; the column headings are in parentheses. There is once concept code (coded term) on each row in a table.

1. Hierarchy level and selectability type (Lvl-Typ)

   The first piece of data in this column is an integer indicating the hierarchical depth of the code value on this row. This is followed by a hyphen and an upper case letter which is one of the following:

   • L Leaf; a term that has no children in the specialization hierarchy, and is selectable in the HL7 tooling, and therefore deemed to be a leaf.
   • A Abstract; a term that has children in the specialization hierarchy, but is not, itself, selectable in the HL7 tooling and therefore deemed abstract.
   • S Specializable; a term that has children in the specialization hierarchy, and is also selectable in the HL7 tooling and therefore deemed specializable.
   
   
   
2. Code/Term and Value Set Head Code reference (Concept Code Head Code-defined Value Set)

   This column contains the string value of the concept code. In those cases where this concept code is also used as a 'head code' for a value set that is defined as a 'head code and all its children' type of value set, then the name of the value set is shown in the same cell as the coded term, but in italics and placed beneath it. The named value set is also hyperlinked to the value set in the value set tables. For ease of readability of the hierarchies, there is a dot (period, 0x2E) for each level deeper in the hierarchy prepended to the code value.

3. Coded Concept Display Name (Print Name)

   This is the string that is associated with the coded concept term, and is the primary english designation for the concept.

4. Coded Concept Definition, Properties and Relationships

   This is the definition of the coded concept plus any assigned properties and relationships. The properties provide additional values that describe or qualify the concept. The relationships define semantic links between this concept and other concepts. The two most common concept relationships are the "Specializes" and "Generalizes" relationships that define the sub-type hierarchies within a code system Note that many concepts do not not have these definitions.

These tables provide a handy "index" to the HL7 Value Sets. Because there are over 1,800 Value Sets, and because there is no a priori hierarchy or ordering for these, they have been arbitrarily segregated into groups according to those code systems from which they draw values. (This means that for a few value sets, the value set definition will appear multiple times, once for each code system from which it draws values.)

The value set groupings also reflect they way the value set definitions are aggregated into html files. The first table in this group is a list of those Code Systems that have supporting Value Sets. It will link you further down into the document where the specific Value Sets for that Code System are listed.

The value set listing consists of a navigational aide (in the table above) which lists the code systems having content that is used in value sets. The underlying data is currently organized by code system; each file of tables and definitions contains all of the value set definitions for those value sets drawing content from the identified and linked code systems. For those code systems that have content used in only one value set, the page that this link will navigate to will have just the the information table defining that value set. For those code systems that are used in multiple value sets, the top of the value set definitions file contains a table alphabetically listing all of the value sets drawing content from that coding system; the link will navigate to this table of value sets contained in the file. Clicking on a value set name in that second table will bring the reader to the table of information containing the definition of that value set.

The information block describing the value set begins with the value set name followed by the value set OID in square brackets. Following that is a summary of the code systems having content included in the value set. This summary is numbered, with an increasing integer for each additional code system having content participating in the value set. That is followed by the code system name, which is hyperlinked to the table entry for the code system that can also be accessed from the preceding section. Last on that line is the code system OID in square brackets.

If there are Context Bindings defined for this value set, they are listed next. This binding section starts with the line "Context Bindings to concept domain(s):", and is followed by the bindings, one per row. Each binding is the name of the Concept Domain (which is hyperlinked to the entry in the Concept Domain tables), followed by the phrase "in Realm:", followed by the binding realm for the binding and the coding strength of that binding (CNE or CWE). Note that when the Binding Realm has been set to 'unclassified' (indicating that a decision on the binding is still pending work group action), the word "undetermined" is used instead of the name of the Binding Realm.

Below that is the description of the value set as provided by the authors of the value set (some value sets are missing descriptions which need to be added at some future date).

Following the description of the value set is table of data describing the content definition for the value set. This table has five columns showing information for each of the defining statements making up the value set definition, each of which is on its own row in this table. The content definition is presented in a grouped fashion to hopefully make it more understandable to the reader. The definition consists of a list of "content blocks" each one of which follows the same type of format. A content block may also include an additional content block, which has the same type of format, including being able to include another content block; in this way the definition is inherently recursive, as the Value Set Model is designed to support. A properly defined value set has no cycles in its recursive structure.

The table containing the value set definition renders this recursive structure accurately, but obviously suffers from the limitations of rendering a recursive nested structure as a linear tabulated list. Special characters, indenting, and hyperlinking attempt to ameliorate these limitations. The keywords, special characters, definitions, and other information rendered in each of these columns are described below. The numbers identify the column in the table, with the heading text of the column in parentheses.

1. Definition Depth (Lvl)

   This is an integer that indicates the depth of a definition statement, and assists the reader in visualizing constructs such as nested value sets, included transitive closure sets, statements in a particular content block, etc. The number always starts at zero, which can be thought of as the definition 'root' of the value set. The integers can be used to identify each of the 'content block' definitions. Note however that the integers refer to the nesting level of the recursive structure and references; a particular content block will cover a range of integers, and thus must be thought of as 'greater than nn' rather than equal to a particular number.

2. Content Type (Content Type)

   This column defines the type of content in a definition statement. It contains a number of key phrases that indicate how the content declared in the remaining columns is incorporated into the value set. Some of these phrases are flags in the definition expression, and some are links to sets of included codes. Note that each entry in this column is preceded by one or more dots (' .') to give a visual aid for the depth of the defining entry, one dot per level of depth. The key phrases that may appear in this column are:

   content This is the root entry for the value set; for those based on multiple code systems, this entry is the first code system in the value set definition. This is always used in the first row of the table, depth 0 (zero). There is only ever one single row in the table with this label. The rows following this row are the content definition for the first content section. This first row with this keyword serves as the header for the initial content block. Note that the value set definition is recursive; content blocks are contained within other content blocks. Therefore the content block that is headed by this keyword in the definition for the entire value set, all other definitions are 'nested' within it. Any particular instance of content can only contain child elements from one of the following five types, and only one of these types, codeBasedContent, can repeat. (Note that this restricted list of five sub-types also applies to the elements unionWithContent. intersectionWithContent, and excludedContent discussed under combinedContentbelow.)

   1. codeBasedContent This sub-type indicates that a specific code from the coding system is to be included in the value set. The identity of the code system from which the code is drawn is defined in the final row labeled with a Definition Depth of one less than the level of this row (indicating the 'current' code system set of content); the code system's definition is inherited by all rows in a content block. The specific code is defined in the 'Primary Reference' column. There may be an arbitrary number of codeBasedContent rows in a content block; there is one for every individual code that is explicitly listed to be included in the content block. The identification of the precise code is on this same row. Note that although each of these rows identifies a single code from a single coding system, a property of 'transitive closure' (identified in the 'Qualifiers/Identifiers' column) can result in a collection of codes for this one rows as the tree in the coding system hierarchy is followed.
      
      
   2. propertyBasedContent This sub-type is a header of a set of zero to many rows that will each be an include or exclude specification based on the properties of the concepts and or the properties of the code, as defined with the coding system in the vocabulary store. Each of the rows in the list will have the element statement in this Concept Type column; these statements are:
      
      
      • includeWithConceptProperty The set of codes resulting from evaluating the property of the concept will be included in the value set. The property referenced will be identified in the 'Primary Reference' column. An expression with the value to be evaluated against the property will be in the 'Qualifiers/Identifiers' column.
        
        
      • excludeWithConceptProperty The set of codes resulting from evaluating the property of the concept will be excluded from the value set. The property referenced will be identified in the 'Primary Reference' column. An expression with the value to be evaluated against the property will be in the 'Qualifiers/Identifiers' column.
        
        
      • includeWithCodeProperty The set of codes resulting from evaluating the property of the code will be included in the value set. The property referenced will be identified in the 'Primary Reference' column. An expression with the value to be evaluated against the property will be in the 'Qualifiers/Identifiers' column.
        
        
      • excludeWithCodeProperty The set of codes resulting from evaluating the property of the code will be excluded from the value set. The property referenced will be identified in the 'Primary Reference' column. An expression with the value to be evaluated against the property will be in the 'Qualifiers/Identifiers' column.
        
        

      Note that the exact syntax of the expressions and arguments for these definition statements will be enumerated later (there are currently no value sets that use this type of defining statement in the HL7 vocabulary store).

   3. codeFilterContent This sub-type identifies a row that uses an expression to define a collection of codes. The expression is listed in the 'PrimaryReference' column. There may be only one row of this type in a content block. The definition of the filter is on the same row, and is an expression in a form supported by the coding system. This expression is shown in the 'Primary Reference' column, with the expression language shown in parentheses following the expression. If the expression in the database is not a proper expression in one of the designated expression languages, it will be shown as a "comment" in one of the languages and will be prefaced with the phrase "invalid expression." in this circumstance an OpenIssue is also registered against the parent content type.
      
      
   4. valueSetReference This sub-type indicates that another value set is being referenced in this definition. The name of the included value set is in the 'Primary Reference' column, and the OID of the value set is enclosed in square brackets in the 'Qualifiers/Identifiers' column, and the value set name is hyperlinked to the table for the included value set within this value set definitions file. Note that occasionally there is no hyperlink to the named value set; in these cases, the value set referenced has no content (may be a dangling reference, an incomplete definition, or other kind of error). In these cases, there is also no value set content definition table for such a referenced value set.
      
      
   5. combinedContent This sub-type indicates that the rows following it are the content definition of an additional set of content making up the value set. Each of the rows following this sub-type (or the content keyword above) might be one of several different kinds of definition statements that must be evaluated to derive the list of coded concepts defined by the value set. Each of the level numbers greater than the number of the row with this label are individual statements of content that are part of this content block, and must be combined for the codes from the specified coding system. There is only one row with this sub-type in a content block, and this serves as the header for a content block.

      When an additional block of content which starts with this 'combinedContent' sub-type is to be included in a value set, there are additional keywords that may appear in this second column which apply only to how a particular content block is to be combined with the value set when evaluating its content. The row immediately following the row with the 'combinedContent' keyword must contain one of the following keywords to indicate how the content specification is to be combined into the value set. Note that in a content block which is headed with a 'combinedContent' row, each of the other content definition rows using the sub-types 'codeBasedContent', 'valueSetReference', 'propertyBasedContent', 'codeFilterContent' or a nested 'combinedContent' will be preceded by a row with one of the following three keywords in the first column, again indicated how the content defined by that row is to be combined to create the set of codes making up the resolved value set. The three keywords defining the combination strategies are:

      • unionWithContent This keyword indicates that the following statement row is to be joined as a union with the previous content. The word 'union' is used in its set connotation, since a value set usually can be treated as a 'set' in the mathematical sense. The code system which the content drawn from is always defined in the 'Code System' column in one of these rows.
        
        
      • intersectionWithContent This keyword indicates that the following content definition row be joined with the value set by taking the set intersection of its evaluated list of codes and combining it with the evaluated list of codes from the preceding definition statements in this value set definition.
        
        
      • excludeContent This keyword is used when an exclusionary definition statement is used in the value set definition. It is most commonly used when a 'tree' of codes is included (eg codeBasedContent with transitive closure) and the top code of the tree is not to be included. It may also be used when arbitrary lists of codes are to be excluded from a collection of content that is included with an earlier 'union' entry.
        
        
3. Coding System (Code System)

   This column identifies the name of the coding system for the included content for the content block. It is populated for each entry type of 'content' or 'unionWithContent' and contains no values for other rows. The name is hyperlinked to the code system entry in the code system tables (see previous section).

4. Specific Included Content (Primary Reference)

   This column identifies the precise element that is to be operated on when evaluating the contents of the value set. For rows of type 'codeBasedContent', this contains the code value from the current code system. When it holds the name of a code from the current code system in the content block, the code name is hyperlinked to the specific row in which the code appears in the code system tables. For rows of type 'valueSetReference', this column contains the name of the value set, which is hyperlinked to the corresponding entry in this section of value set tables. For other types of rows, this may contain the name of a concept property or a code property. For those rows that do not have a reference to a vocabulary object (such as 'combinedContent') or refer to a coding system only (which is held in the 'Code System' column), this column is not populated.

5. Additional Data (Qualifiers/Identifiers)

   This column contains additional specification information used in the value set definition entries. This column usually contains expressions and arguments that are used in conjunction with the content definition in the 'Content Type' column, but there also may be specific keywords and phrases used to indicate certain control flags being set in the value set definition, and there may be some entries where other types of defining expressions have been entered into the value set definition by the value set authors. This column may also contain an OID in square brackets, which is generally only present for entries of type "valueSetReference", although most entries of this type are completely unstructured. One of the specific keywords used is:

   • Relationship: Generalizes With: TransitiveClosure

     This indicates that a transitive tree walk of the hierarchy starting at the code identified in the 'Primary Reference' column must be performed to collect a set of codes for this entry,. This key-phrase is used only for entries of type 'codeBasedContent', is on the same row as a specific coded term, and should be interpreted to mean that the value set includes all of descendant concepts of that coded term.

The management process for HL7 vocabulary content provides a two stage approach for the removal (effectively the deletion) of elements such as concept domains, code systems, concepts within a code system and value sets.

If an element is known or assumed to have been used to define a formal HL7 specification such as a data type, document or message, tht first stage of removal is to "deprecate" the further use of the arifact in question for defining new specifications. This provides a "warning" to users of the deprecated content to change ther specifications so as to no longer be dependent upon the deprecated content.

The second stage is to actually retire or delete the content from the defined vocabulary content.

In order to provide a clear picture of valid vocabulary content, the Vocabulary Work Group and the Publishing Work Group agreed to exclude the listing of deprecated material (except for deprecated concepts) in the primary displays of vocabulary content. In order to make this exclusion clear, they further agreed to provide a table of all of the deprecated concept domains, code systems and value sets, along with the vocabulary release in which that deprecation took effect. The following table is that list.