FEHLER! ES WURDEN KEINE EINTRÃ?GE FÜR DAS INHALTSVERZEICHNIS GEFUNDEN.
The Code Tables chapter contains the code tables originally documented in individual chapters of the HL7 Version 2 Standard. In HL7 Version 2.7, a proposal was accepted to move all of the tables to a common document. This separation will allow these artifacts, which are often subject to more frequent change to meet regulatory requirements, to be ballotable on a more responsive schedule than the rest of the standard. The meta-data tables for each table will support harmonization with HL7 Version 3 and Clinical Document Architecture.
As of v 2.7, there will be a migration toward terminology used in Version 3. Version 3 defines Code System and Value Set as follows:
Code System
A Code System is defined as a collection of codes with associated designations, meanings and associations. The persistent representation of a Code System includes meta-data about the code system itself, as well as the contents of the Code System.
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 Concept Code must resolve to one and only one meaning within the Code System. Given this definition, each table in the HL7 Version 2 standard represents a different Code System since Concept Codes are sometimes used in different tables to have different meanings. For example, the Concept Code "M" in the gender Code System means "Male", while "M" in the marital status Code System means "Married".[p.60]
Value Set
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.
HL7 defines four table types, reflecting content ownership: HL7 defined, User-defined, Imported and Externally defined. Local implementation may further constrain these table types.
As of v 2.8 there is work in progress to develop a supplement to the standard that will provide OID assignments and versioning information for those V2 tables that define code sets.  This work is intended to provide support for mapping vocabulary objects between V2 and V3/CDA systems. The target for completion of this supplement is v 2.9.
A user-defined table is a set of values that are locally or site defined. This accommodates certain fields, like PV1-3 - Assigned Patient Location, which will have values that vary from institution to institution. Even though these tables are not defined in the Standard, they are given a user-defined table number to facilitate implementations. HL7 sometimes publishes suggested values that a site may use as a starter set (e.g., Table 0001- Sex). The CWE data type is often used to encode values for these tables. Note that some of these tables (e.g., Table 0302 - Point of Care) may reference common master files.
There are some user-defined tables that contain values that might be standardized across institutions but for which no applicable official standard exists. For these a set of suggested values may be listed in Appendix A. These suggested values appear in the text in a standard box format (e.g., HL7 Table 0062 - Event Reason in Section 3.4.1.4, "Event reason code"). It is recommended that these values be used where applicable within an institution and serve as a basis for extensions as required. These values may, however, be redefined locally. The appropriate functional work group within HL7 solicits suggestions for additional values from institutions that are applying the Standard.
An HL7 table is a set of values defined and published by HL7. They are a part of the HL7 Standard because they affect the interpretation of the messages that contain them. These values may not be redefined locally; however, the table itself may be extended to accommodate locally defined values. This is particularly applicable in the case of HL7 Table 0003 - Event Type. The ID data type is most often used to encode values for HL7 tables. The values are listed in Appendix A. These HL7 tables also appear in the text in a standard box format (e.g., HL7 Table 0003 - Event Type).
HL7 tables can be thought of as universally used tables. This begins to bring this structure in line with v3 terminology.
As of v 2.7, external tables should use the acronym (e.g. UCUM or CVX) that has an explicit table 0396 entry and the table number (implicit 0396 entry in the form of HL7nnnn) will be retired.
External tables may be either "Referenced" or "Imported".
An External table is a set of coded values defined and published by another standards organization. External tables are used to populate fields like FT1-19-Diagnosis Code - FT1. Another example is the encoding of clinical observations using LOINC codes. The CF, CNE and CWE data type are used to represent values for these fields.
External tables arise from applications where the concepts and possibly the codes are established by external agencies due to regulatory requirements or agreements between HL7 and other Standards Developing Organizations.
A referenced table is a set of coded values defined and published by another standards organization. Referenced tables are used to populate fields like FT1-19-Diagnosis Code - FT1. Another example is the encoding of clinical observations using LOINC codes. The CF, CNE and CWE data type are used to represent values for these fields.
The content of a referenced table is not included in the HL7 Standard. The user will need to access the official source.
The data type for the field will be CWE if 1) other tables are allowed in the field or 2) the external table may be locally extended or 3) when the code may be replaced by local text.
The data type for the field will be CNE if 1) no other table is allowed in the field and 2) the external table may not be locally extended and 3) text may not replace the code. A CNE field must have an HL7 defined or external table associated with it. A CNE field may be context sensitive such that a choice of explicit coding systems or value sets might be designated.
An Imported table is a set of coded values defined and published by another standards organization. Imported tables are published by HL7 on behalf of other organizations. Their contents are not subject to approval by HL7 ballot. Such tables will be published with HL7 Standards. However, they may be updated more frequently than HL7 Standards.
Imported tables differ from External tables in that they have been imported into the HL7 standard subject to specific license or copyright requirements of the supplier/author. HL7 users will need to abide by the licensing and copyright requirements of the source when applicable.
Imported Table 0834 - Mime Types is an example of an imported table.
The data type rules apply as defined for the imported table.
A local table is a table with a non-HL7 assigned table identifier and which contains a set of locally or site defined values. It may be locally assigned to local fields in Z segments or to HL7 fields having a CWE data type.
A simple example for code is the ICD-9 code for headache, which is "784.0".
|784.0^Headache^I9^^^^^^general headache^^^^^2.16.840.1.113883.6.42|
A possible ICD-10 equivalent is "G44.1" (the ICD-10 classifications are slightly different).
|G44.1^Headache^I10^^^^^^general headache^^^^^2.16.840.1.113883.6.3|
A common situation with CWE is when the actual concept cannot be properly represented in a particular coding system. Usually this circumstance arises where the concept is expected to be represented in a particular coding system. For the purposes of these examples, we assume that all these examples are for an observation value of type CWE that is bound to the full Snomed-CT valueset (Example OID for the value set = 2.16.840.1.113883.19.11.1 as published 11-June 2007, Real OID for the SNOMED-CT code system = 2.16.840.1.113883.6.96). Important Note: The OID root 2.16.840.1.113883.19 is an HL7 OID used for example-only OIDs and OIDs in this space are never valid in real instances. The OIDs used in these examples that in the OID space 2.16.840.1.113883.6, 2.16.840.1.113883.5 and 2.16.840.1.113883.11 are the correct OIDs for use in production instances.
The simplest case is where the CWE is not represented in the instance at all, or simply represented as no information.
|U^^HL70353|
However this is not a very useful representation - frequently the source system knows more information, and it is still useful to convey that information to the destination system, while still labeling the coding as incomplete.
|^^SCT^^^^^^^^^^^2.16.840.1.113883.6.96|
or it may be encoded as
|^^SCT^^^^^^^^^^^^2.16.840.1.113883.19.11.1^20070711|
Both examples say that the concept cannot be coded in SNOMED. Even more useful is to convey some specific information about the concept, even though it cannot be represented in SNOMED:
|^^SCT^^^^^^Burnt ear with iron. Burnt other ear calling for ambulance^^^^^2.16.840.1.113883.6.96|
It is also possible that the content was first encoded in some other code system than SNOMED, and the source system was unable to encode the value in SNOMED.
|burn^^L96^^^^^^Burnt ear with iron. Burnt other ear calling for ambulance^^^^^2.16.840.1.113883.19.5.2|
In this case, because the type is CWE, local extensions are allowed, and the source system can simply use its own codeSystem (here identified by the OID "2.16.840.1.113883.19.5.2", which is an example OID) to extend the other code system. In fact, the source system can also use a code from another well known code system, such as ICD-9. If ICD-9 had a code "A10.1" which stood for this same concept, then this would be valid:
|A10.1^^I9^^^^^^Burnt ear with iron. Burnt other ear calling for ambulance^^^^^2.16.840.1.113883.6.42|
All these examples have assumed that the attribute is bound to the fictitious value set 2.16.840.1.113883.19.11.1 which is all of SNOMED-CT. If the value set was extended to include the LOINC codes as well, it would no longer be appropriate to encode a failure to code like this:
|^^SCT^^^^^^^^^^^2.16.840.1.113883.6.96|
Since it is not true that the concept could not be coded from SNOMED-CT - it could not be coded in either SNOMED-CT or LOINC. For this reason, it is appropriate to encode the failure to code in the valueSet form:
|^^SCT^^^^^^^^^^^^2.16.840.1.113883.19.11.1^20070711
Expressions generally arise with complex medical terminologies such as SNOMED. For example, SNOMED CT defines a concept "cellulitis (disorder)" (128045006) an attribute "finding site" (363698007) and another concept "foot structure (body structure)" (56459004). SNOMED CT allows these codes to be combined in a code phrase:
128045006:{363698007=56459004}
The full CWE form for this is:
|128045006:{363698007=56459004}^^SCT^^^^^Cellulitis of the foot^^^^^2.16.840.1.113883.6.42|
The SNOMED compositional expression language is currently undergoing comment, and may be found on the IHTSDO website (http://www.ihtsdo.org/fileadmin/user_upload/Docs_01/Technical_Docs/abstract_models_and_representational_forms.pdf). The next two examples are based on SNOMED CT Core Edition 2007-01-31.
This first example is the SNOMED code for "fracture of left tibia". It shows issues associated with grouping and nesting.
31978002|fracture of tibia|: 272741003|laterality|=7771000|left|
Strictly speaking (in normal form) a "fracture of left tibia" is not a "left fracture" of a "tibia bone" but is a "fracture" of the "left" "tibia bone" (that is, the qualification of "left" applies to the bone not to the fracture). Also note in this example that the fracture and bone are grouped - this may look irrelevant but is potentially significant for combined fractures where different morphology may apply to different bones. An alternative rendering for this same concept is:
64572001|disease|:{116676008|associated morphology|=72704001|fracture|,
363698007|finding site|=(12611008|bone structure of
tibia|:272741003|laterality|=7771000|left|)}
The second example shows a more complicated grouping and nesting structure. The SNOMED CT expression for "past history of fracture of left tibia" includes nesting even in its simplest form because the laterality does not apply to the past history but rather to the disorder.
417662000|past history of clinical finding|:246090004|associated finding|=
(31978002|fracture of tibia|: 272741003|laterality|=7771000|left|)
The alternative rendering is even more nested:
243796009|situation with explicit context|:246090004|associated finding|=
(64572001|disease|:{116676008|associated morphology|=72704001|fracture|,
363698007|finding site|=(12611008|bone structure of tibia|:
272741003|laterality|=7771000|left|)}),408729009|finding context|=
410515003|known present|,408731000|temporal context|=410513005|past|,
408732007|subject relationship context|=410604004|subject of record|
These are provided as examples of SNOMED expression syntaxes. A full discussion the merits of the different forms, their relationship and how to work with them can be found in the SNOMED compositional expression language definition referred to above.
It is important to note that the expression syntax and semantic rules are specified by the code system. For instance, in SNOMED CT, there are a defined set of qualifying attributes, and only Findings and Disorders can be qualified with the "finding site" attribute. CWE does not provide for normalization of compositional expressions; therefore, it is possible to create ambiguous expressions. Users should understand that they must provide the additional constraints necessary to assure unambiguous data representation, if they are planning to create compositional expressions using CWE. Otherwise, they risk the inability to retrieve a complete set of all records corresponding to any given query.
ICD-10 allows dual coding. Refer to Section 3.1.3 of the ICD-10 Instruction Manual (2nd Edition, found at http://www.who.int/classifications/icd/ICD-10_2nd_ed_volume2.pdf). While ICD-10 clearly establishes the semantic basis for the dual coding, it does not define an actual literal expression form suitable for use with CWE. In such cases, HL7 defines a suitable literal expression form and assigns an OID to that. The OID for this ICD-10 expression is 2.16.840.1.113883.6.260. The code system specifies that the two ICD-10 codes are separated by a space.
|J21.8 B95.6^^^^^^^^Staph aureus bronchiolitis^^^^^2.16.840.1.113883.6.260
The ICD-10 code J21.8 is "Acute bronchiolitis due to other specified organisms" and the code B95.6 is "Staphylococcus aureus as the cause of diseases classified to other chapters". No value for the dual coding scheme has been assigned in table 0396, so CWE.3 cannot be populated.
Following are the HL7 and User defined tables extracted from the chapters.
The Demo site for our new HL7 Version 2+ (plus) Standard
