HL7 V2 Vocabulary Specification V alue Set Classification Proposal
description
Transcript of HL7 V2 Vocabulary Specification V alue Set Classification Proposal
HL7 V2 Vocabulary SpecificationValue Set Classification ProposalDRAFT VERSION FOR DISCUSSION PURPOSES
HL7 Conformance and Guidance for Implementation and Testing (CGIT) WG
Robert SnelickNational Institute of Standards and Technology
July 10th, 2013 (Draft 8)
Contact: [email protected]
2
Background Statements The purpose of the implementation guide is to describe the requirements of an implementation based on a given use case. All
requirements need to be directly tied back (and supported) by the use case. This includes the specification of “value sets”. Extraneous requirements must not be specified in the implementation guide that does not cover an aspect described in the use case (including codes in a value set since they may imply support for certain functionality).
Implementers that claim conformance to this guide (or aspects of the guide as allowed) are obligated to implement all requirements as stated regardless if it meets their business practices or not. They are not obligated to claim conformance to the guide. Once they do make a claim of conformance, they are indicating that they are capable of supporting all requirements. Purchasers of such system are provided, in essence, a contract of what they have bought. In practice, a certain client may not want or use all capabilities provided. A vendor may later on deal with customers that only need support for a given subset of capabilities. This is fine; the implementation can be configured as needed. It is good practice that the vender/purchaser document what those requirements are. The system capabilities may also be extended as allowed by the standard (implementation guide). The resulting implementation again should be documented (as a conformance profile or profile component).
If the use case needed by the vendor is slightly different than the use case described in the implementation guide, site agreements can be made. This constitutes another profile or profile component. Such components may or may not be compliant with the source implementation guide (in all cases, this should be documented). Extensions to the implementation guide are expected to be made to meet site specific requirements. Extensions should be in compliance with the implementation guide; otherwise interoperability is at risk. The scope of certification testing is to ensure a certain level of capabilities. This provides purchasers with a degree of confidence in the capabilities of the product. The implementation guide provides one source of that documentation.
Local requirements (or lack of need of requirements) should not be considered in the development of the implementation guide. What is to be considered in the development of an implementation guide are the requirements for an implementation in general and not any particular site installation implementation. The purpose is to define the requirements of capabilities of the implementation based on the stated use cases (this is the scope).
The implementation guide provides a collection of value sets. A value set describes the allowable values a particular data element may be populated with. Based on the context, the appropriate value is selected. Implementation guide (conformance profiles) will draw upon a number of sources to build the collection of value sets. These can come from tables defined in the version 2 standard, code systems, external vocabularies such as LOINC, and other sources. The value sets have a number of associated attributes including implementation and operational requirements as well how such value sets can be specified in further specifications.
This document focuses on how the collection of value sets is specified and based on how it is specified what it means to the implementers (and therefore the testers).
3
Key Premises• The scope of the value sets specified in the implementation guide pertain to the use case
the implementation guide is targeting. It does not include codes that a system may typically use to handle other use cases (although these codes are likely to be implemented by the system). Configuration setting can be enacted to target specific profile requirements.
• The key point is that the implementation guide only specify codes that are relevant to the use case(s) the implementation guide is targeting. Implementers should not have to determine which codes apply and which codes do not. The implementation guide scope is the use case(s) provided in the guide.
• From the implementation guide perspective we want to specify the implementation and operational requirements the value set is placing on the implementers
• The key term here is value set; this supersedes the origin of the underlying vocabulary concept (be it an HL7 or User table, code system, external value set, etc.) it was derived from
• The only thing that matters from the implementation guide perspective are the requirements the value set places on the implementation with respect to the particular message profile specification it is bound to
• Data type bindings are irrelevant (well mostly/probably) since they do not provide support to handle all the possible combinations of specification required
• The perspective taken is for the sender requirements. The Receiver requirement in all cases is to “SHALL support and process all codes in the value set without error”. (TODO: change perspective for implementations in total)
4
Notes• Often value sets that are made more restrictive seem to break
“compatibility/interoperability” rules. However, since we are creating value sets from the code systems (tables) then this is not the case.– For example, HL7 Table 0104 Version ID. Obviously for a profile indicating that the message
version supports version 2.5.1, all other values (e.g., 2.2) are inappropriate.– The key point, as mentioned on the previous slide, is that in the specification of the guide we
are creating a value set from the code system (it is the code system that can’t be restricted).– We can dictate in the implementation guide the set of codes that are appropriate for the
particular use case(s) were are interested in.
• In the specification that follows, the phrase “SHALL implement” can refer to the system configuration setting. Therefore, if a particular code is not specified for a profile but is in other profiles the “SHALL not implement or send” only applies for the particular profile. Such functionality can be achieved by the application configurations.
• When referring to optional with respect to codes; this simply means that derived profiles (e.g., local site agreement) can agree to support a particular concept. If they do agree then the code specified in the table as optional SHALL be used. It does not mean that implementers can unilaterally decide to support the concept. Trading partner agreement must be established; otherwise interoperability is not achievable.
5
Summary of Findings• In the specification of an implementation guide the concept of value set is used to define the
codes that must be supported. The underlying source/mechanism for which the value set is created from becomes nearly irrelevant. The specified value set is the source of truth for defining the value set requirements.
• The codes in the value set places requirements on implementations, therefore they must be supported and are subject to testing.
• Only the concepts that are relevant for the given use case are specified in the value set (this is important, see previous bullet point).
• The designation of a the data type becomes nearly irrelevant as the definitions of the data type currently do not support the array of classifications of value sets needed. HL7 may want to consider just two data types (simple and complex coded elements).
• A value set classification system is created to support the vast array of possibilities in which a value set can be specified. The classification system is determined by a number of attributes. Some of the attributes imply certain conformance requirements.
• Each value set definition is assigned a classification (which clearly states the requirements, use, and changeability of the value set in derived profiles). The classification of a value set specifies the conformance requirements.
• The concepts provided in this slide deck need to be boiled downed into a set of concepts (all related and harmonized with other HL7 vocabulary concepts). That is, the classifications may go away and we’re left with a set of value set attributes which imply the range of concepts we want to express.
Value Set Specification Templates for Constrainable Profiles“Note: Key term here is Constrainable Profile”Implementation profiles have not been considered, although a similar analysis can be provided.
7
Value Set Properties Property Description Values/Examples
Base Name Name of as given in the base standard or implementation guide (derived specification) String
Name Name of the value set String
Base Identifier Identifier of as given in the base standard or implementation guide (derived specification) OID, UID, string, etc.
Identifier Identifier of the value set OID, UID, string, etc.
Sources Code system(s) or value sets String/HL7 V2.5.1, LN, SCT, etc.
Base Type Type of table (value set) as defined by HL7 V2.x [HL7, User, External, Imported]
Delta Change from the base standard or implementation guide (derived specification) [Exact, Extended, Restricted, Extended/Restricted]
Allowable Data Types
Data types that are appropriate for an element that links this value set to the element. [ID, IS, CE, CNE, CWE]
Extensibility Indicates if value set can be extended or not in a derived profile. Closed means that the value set can’t be extended in a derived profile; Open means that it can.
[Closed, Open]
Stability Indicates if value set is fixed as defined in specification or can change over time even if specification will not change.
[Static, Dynamic]
Version Version of the value set. Dynamic value sets are allowed to change although specification is fixed.
String or Null
8
Usage – System Capabilities Requirements (Constrainable Profile)Usage Name Conformance
R Required The system SHALL support the code and SHALL have the functional capabilities to support the use case implied by the code.
Conformance Assessment
If the concept being expressed is represented by the code, then the code SHALL be sent.
O Optional Designates that the code in a derived profile may be agreed upon to be R-Required.
Conformance Assessment
If the code is present in the message an error SHALL NOT be raised. *
X Not-Supported The code SHALL NOT be supported.
Conformance Assessment
The system SHALL NOT support the code. If the code is present an error SHALL be raised.
Base Usage Allowable Usage in Derived Profile
R R
O R and X (most likely for Implementation Profile)?
X X
* Our testing perspective here is at the constrainable profile level, however, we are testing an implementation that may have decided to support the optional code (based on the requirements in a derived profile). Therefore, if we see the code we can’t make a definitive determination. The same principle applies to value set that are open and don’t explicitly mark codes with optional usage.
Bob Y suggests the concept of “A - Allowed”
9
Classification Summary – HL7 TablesID Classification DescriptionA1 Adoption of Base Standard HL7 Table – Closed Use base table exactly and forbid extension.
A2 Adoption of Base Standard HL7 Table – Open Use base table exactly and allow extension.
A3 Extension of Base Standard HL7 Table - Closed Extended base table and forbid further extension.
A4 Extension of Base Standard HL7 Table – Open Extended base table and allow further extension.
A5 Restriction of Base Standard HL7 Table – Closed Constrained base table and forbid extension
A6 Restriction of Base Standard HL7 Table – Open Constrained base table and allow extension
A7 Restriction and Extension of Base Standard HL7 Table – Closed Constrained and extended based table and forbid further extension
A8 Restriction and Extension of Base Standard HL7 Table – Open Constrained and extended based table and allow further extension
Boil down to what is needed in the guide: Value set level attributes
Dynamic – contents controlled by an external (owning) organization and is modified outside of according to it’s own schedule
Static – fixed set of values
Open – can be locally extendedClosed – no local extension
Version of the value setAncestry – do we need to know where the values come from?
10
• Value set level attributes– Dynamic – contents controlled by an external (owning)
organization and is modified outside of according to it’s own schedule
– Static – fixed set of values•
– Open – can be locally extended– Closed – no local extension
• – Internal– External
11
(A1) Adoption of Base Standard HL7 Table – Closed
VALUE SET – HL70000 – FRUIT – BASE STANDARD
Code Code Description CommentA Apple B Banana C Cantaloupe
S Strawberry
W Watermelon
Attribute Value Attribute Value
Name Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed
Identifier HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Exact
Base Type HL7
The value set adopts the base standard HL7 table exactly. The value set is not extendable in any derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. (Added during 07/09/13 call – Specified by the element usage
IF RE, then if a code is sent, it SHALL be from this value set)
12
(A2) Adoption of Base Standard HL7 Table – Open The value set adopts the base standard HL7 table exactly. The value set is extendable in a derived profile. The system SHALL support all codes in the value set and MAY support additional codes. Additional codes that may be supported are determined in a derived profile (e.g., by site agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. If the value set is extended in a derived profile then a new name and identifier SHALL be created.
VALUE SET – HL70000 – FRUIT – BASE STANDARD
Code Code Description CommentA Apple B Banana C Cantaloupe
S Strawberry
W Watermelon
Attribute Value Attribute Value
Name Fruit Allowable Data Types ID
Base Name Fruit Extensibility Open
Identifier HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Exact
Base Type HL7
13
(A3) Extension of Base Standard HL7 Table - Closed
VALUE SET – P1_HL70000 – P1_FRUIT – EXTENDED
Code Code Description CommentA Apple B Banana C Cantaloupe
G Grape Added in Profile
M Mango Added in Profile
S Strawberry
W Watermelon
The value set adopts the base standard HL7 table and extends the table. The value set is not extendable in any derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. A new name and identifier SHALL be created for the table
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Extended
Base Type HL7
14
(A4) Extension of Base Standard HL7 Table – Open The value set adopts the base standard HL7 table and extends the table. The value set is extendable in a derived profile. The system SHALL support all codes in the value set and MAY support additional codes. Additional codes that may be supported are determined in a derived profile (e.g., by site agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. If the value set is extended in a derived profile then a new name and identifier SHALL be created.
VALUE SET – P1_HL70000 – P1_FRUIT – EXTENDEDCode Code Description CommentA Apple B Banana C Cantaloupe
G Grape Added in Profile
M Mango Added in Profile
S Strawberry
W Watermelon
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Open
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Extended
Base Type HL7
15
(A5) Restriction of Base Standard HL7 Table – Closed (Option 1) The value set of the base standard is restricted (constrained). The value set can not be extended in a derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. Unsupported (restricted) elements (e.g., S) SHALL not be supported and SHALL not be sent (Those removed from derived table). A new name and identifier SHALL be created for the table. Best Practice: Use when base table is large and relatively few are selected for the value set. This might be the case when the
concepts are orthogonal.
VALUE SET – P1_HL70000 – P1_FRUIT – RESTRICTION
Code Code Description CommentA Apple B Banana C Cantaloupe
Format Option 1
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained
Base Type HL7
16
(A5) Restriction of Base Standard HL7 Table – Closed (Option 2) The value set of the base standard is restricted (constrained) The value set can not be extended in a derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. Unsupported (restricted) elements (e.g., S) SHALL not be supported and SHALL not be sent. A new name and identifier SHALL be created for the table. Best Practice: Use when the base table is relatively small and a select few are omitted (prohibited). This might be the case when
the concepts are related (describe functionality) but not relevant for the targeted use case and it is important that they are explicitly omitted..
Format Option 2VALUE SET – P1_HL70000 – P1_FRUIT – RESTRITION
Code Code Description Usage CommentA Apple R B Banana R C Cantaloupe R
S Strawberry X Forbidden for use in Profile
W Watermelon X Forbidden for use in Profile
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained
Base Type HL7
17
Note
• Are we breaking the HL7 standard by constraining HL7 tables?• Consider table 0354• This is an HL7 table that is constrained. However, the HL7 Table is a
code system which I believe is what HL7 is saying can’t be constrained.• Here we are defining a value set and selecting codes from the HL7
table (code system).• This is the assumption we are making when defining the value sets in
an implementation guide• The value set must meet the requirements of the use case (this
overrides the perceived usage of HL7 tables as defined by the standard).
• In some cases the HL7 table makes no sense to support wholly (e.g., table 354 – Event codes – ORU is only valid for the profile)
• How does the data type come into play then? (TDB)
18
(A6) Simple Restriction of Base Standard HL7 Table – Open (Option 1) The value set of the base standard is restricted (constrained). The value set is extendable in a derived profile. A new name and identifier SHALL be created for the table. The system SHALL support all codes in the value set and MAY support additional codes. Additional codes that may be supported are determined in a derived profile (e.g., by site agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. If the value set is extended in a derived profile then a (another) new name and identifier SHALL be created. Question: How to prevent prohibited codes back in?
Format Option 1
VALUE SET – P1_HL70000 – P1_FRUIT – RESTRICTION
Code Code Description CommentA Apple B Banana C Cantaloupe
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Open
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained
Base Type HL7
19
(A6) Simple Restriction of Base Standard HL7 Table – Open (Option 2) The value set of the base standard is restricted (constrained). The value set is extendable in a derived profile. A new name and identifier SHALL be created for the table. The system SHALL support all codes in the value set and MAY support additional codes. Additional codes that may be supported are determined in a derived profile (e.g., by site agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. If the value set is extended in a derived profile then a new name and identifier SHALL be created. Question: How to prevent prohibited codes back in?
Format Option 2VALUE SET – P1_HL70000 – P1_FRUIT – RESTRITION
Code Code Description Usage CommentA Apple R B Banana R C Cantaloupe R
S Strawberry X Forbidden for use in Profile
W Watermelon X Forbidden for use in Profile
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Open
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained
Base Type HL7
20
(A7) Restriction/Extension of Base Standard HL7 Table – Closed (Option 1) The value set of the base standard is restricted (constrained). The value set of the base standard is extended. The value set is not extendable in a derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. Unsupported (restricted) elements (e.g., S) SHALL not be supported and SHALL not be sent (Those removed from derived table). A new name and identifier SHALL be created for the table.
VALUE SET – P1_HL70000 – P1_FRUIT – RESTRICTION
Code Code Description CommentA Apple B Banana C Cantaloupe
G Grape Added in Profile
M Mango Added in Profile
Format Option 1
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained and Extended
Base Type HL7
21
(A7) Restriction/Extension of Base Standard HL7 Table – Closed (Option 2) The value set of the base standard is restricted (constrained). The value set of the base standard is extended. The value set is not extendable in a derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. Unsupported (restricted) elements (e.g., S) SHALL not be supported and SHALL not be sent. A new name and identifier SHALL be created for the table.
VALUE SET – P1_HL70000 – P1_FRUIT – RESTRICTION
Code Code Description CommentA Apple R B Banana R C Cantaloupe R
G Grape R Added in Profile
M Mango R Added in Profile
S Strawberry X Forbidden for use in Profile
W Watermelon X Forbidden for use in Profile
Format Option 2
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained and Extended
Base Type HL7
22
(A8) Restriction/Extension of Base Standard HL7 Table – Open (Option 1) The value set of the base standard is restricted (constrained). The value set of the base standard is extended. The value set can be extended in a derived profile. A new name and identifier SHALL be created for the table. The system SHALL support all codes in the value set and MAY support additional codes. Additional codes that may be supported are determined in a derived profile (e.g., by site agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. If the value set is extended in a derived profile then a (another) new name and identifier SHALL be created. Unsupported (restricted) elements (e.g., S) SHALL not be supported and SHALL not be sent (Those removed from derived table).
VALUE SET – P1_HL70000 – P1_FRUIT – RESTRICTION
Code Code Description CommentA Apple B Banana C Cantaloupe
G Grape Added in Profile
M Mango Added in Profile
Format Option 1
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Open
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained and Extended
Base Type HL7
23
(A8) Restriction/Extension of Base Standard HL7 Table – Open (Option 2) The value set of the base standard is restricted (constrained). The value set of the base standard is extended. The value set can be extended in a derived profile. A new name and identifier SHALL be created for the table. The system SHALL support all codes in the value set and MAY support additional codes. Additional codes that may be supported are determined in a derived profile (e.g., by site agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. If the value set is extended in a derived profile then a (another) new name and identifier SHALL be created. Unsupported (restricted) elements (e.g., S) SHALL not be supported and SHALL not be sent.
VALUE SET – P1_HL70000 – P1_FRUIT – RESTRICTION
Code Code Description CommentA Apple B Banana C Cantaloupe
G Grape Added in Profile
M Mango Added in Profile
Format Option 1
Attribute Value Attribute Value
Name P1_Fruit Allowable Data Types ID
Base Name Fruit Extensibility Open
Identifier P1_HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Constrained and Extended
Base Type HL7
24
Classification Summary – HL7 Tables – w/ Optional CodesID Classification Description
A1-O Adoption of Base Standard HL7 Table – Closed - Optional Use base table exactly, allow extension by optional codes only, and forbid further extension.
A2-O Adoption of Base Standard HL7 Table – Open - Optional Use base table exactly, allow extension by optional codes, and allow extension.
A3-O Extension of Base Standard HL7 Table – Closed - Optional Extend base table, allow extension by optional codes only, and forbid further extension.
A4-O Extension of Base Standard HL7 Table – Open - Optional Extend base table, allow extension by optional codes, and allow extension.
A5-O Restriction of Base Standard HL7 Table – Closed - Optional Constrained base table, allow extension by optional codes only, and forbid further extension. Optional code declaration can be from base HL7 table or external.
A6-O Restriction of Base Standard HL7 Table – Open - Optional Constrained base table, allow extension by optional codes only, and allow further extension. Optional code declaration can be from base HL7 table or from an external source.
A7-O Restriction/Extension of Base Standard HL7 Table – Closed - Optional
Constrained and extended based table, allow extension by optional codes only, and forbid further extension. Optional code declaration can be from base HL7 table or external.
A8-O Restriction/Extension of Base Standard HL7 Table – Open - Optional
Constrained and extended based table, and allow further extension. Optional code declaration can be from base HL7 table or from an external source.
Optional Code Declaration = In a derived profile, if agreed upon to support the concept represented by the optional code then the code shall be supported and sent when the concept represented by the code is appropriate.
25
(A1-O) Adoption of Base Standard HL7 Table – Closed - Optional The value set adopts the base standard HL7 table exactly. The value set is extendable in a derived profile but only in the manner specified by optional codes. The system SHALL support all codes in the value set and MAY support optional codes (by agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. The optional codes that may be supported are determined in a derived profile (e.g., by site agreement) If a concept specified with optional usage is supported in derived profile then the code specified SHALL be
used to signify that concept. Not sure about how to handle the name/identifier. At this point requirements are the same, so I’d say no
name change. But if in derived profile the code is made required then name change is required.
Attribute Value Attribute Value
Name Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed - Optional
Identifier HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Exact - Optional
Base Type HL7
VALUE SET – HL70000 – FRUIT – BASE STANDARD
Code Code Description Usage CommentA Apple R B Banana R C Cantaloupe R
P Pineapple O The Pineapple concept can be supported in a derived profile.
S Strawberry R
W Watermelon R
26
(A2-O) Adoption of Base Standard HL7 Table – Open - Optional The value set adopts the base standard HL7 table exactly. The value set is extendable in a derived profile in two ways:
optional codes (known), if the concept is to be supported then the optional code SHALL be used in a derived profile. extended codes (unknown), the value set is extendable in a derived profile.
The system SHALL support all required codes in the value set and MAY support optional and extended codes (by agreement). If the concept being expressed is represented in the value set, a code from the value set SHALL be sent. The optional and extended codes that may be supported are determined in a derived profile (e.g., by site agreement) If a concept specified with optional usage is supported in derived profile then the code specified SHALL be used to signify that
concept. If the value set is extended (by optional or extended codes) in a derived profile then a new name and identifier SHALL be created.
Attribute Value Attribute Value
Name Fruit Allowable Data Types ID
Base Name Fruit Extensibility Closed - Optional
Identifier HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Exact - Optional
Base Type HL7
VALUE SET – HL70000 – FRUIT – BASE STANDARD
Code Code Description Usage CommentA Apple R B Banana R C Cantaloupe R
P Pineapple O The Pineapple concept can be supported in a derived profile.
S Strawberry R
W Watermelon R
27
Placeholder Slide
• Provide detail for A3-O to A8-O
Superset Concept using Optional Usage Discussion
29
Concerns of Proposed Superset Concept (LOI)
TABLE 0000 – COLOR – ORIGINAL TABLE
Code Code DescriptionR Red
G Green
B Blue
Y Yellow
P Pink
O Other
TABLE 0000 – IMPLEMENTATION A
Code Code Description UsageR Red R
G Green R
B Blue R
Y Yellow Supported
P Pink X
O Other R
TABLE 0000 – COLOR – PROFILED TABLE
Code Code Description UsageR Red R
G Green R
B Blue R
Y Yellow O
P Pink X
O Other R
TABLE 0000 – IMPLEMENTATION B
Code Code Description UsageR Red R
G Green R
B Blue R
Y Yellow Not Supported
P Pink X
O Other R
Original table is from standard Profiled table (superset) disallows code P Profiled table requires code R,G, B, and O Profiled table optional allows code Y “System A chooses to support and send code Y because it is capable of doing so (it is ready)” “System B chooses not to support code Y (it is not ready)”
30
Questions about the “Proposed Superset Concept”
TABLE 0000 – COLOR – ORIGINAL TABLE
Code Code DescriptionR Red
G Green
B Blue
Y Yellow
P Pink
O Other
TABLE 0000 – IMPLEMENTATION A
Code Code Description UsageR Red R
G Green R
B Blue R
Y Yellow Supported
P Pink X
O Other R
TABLE 0000 – COLOR – PROFILED TABLE
Code Code Description UsageR Red R
G Green R
B Blue R
Y Yellow O
P Pink X
O Other R
TABLE 0000 – IMPLEMENTATION B
Code Code Description UsageR Red R
G Green R
B Blue R
Y Yellow Not Supported
P Pink X
O Other R
Table 0000-Color is specified for use with element ABC Element has usage of R and cardinality of 1..1 System A sends code “Y” to System B. Is System A conformant? Note: System B only knows that R,G,B, and O are required and may reject message What does System B do with code “Y”; it business logic does not handle “Y” What is the semantic meaning of code “O” in the view of System A? What is the semantic meaning of code “O” in the view of System B? Do they have the same semantic meaning? No! (This may be very important in some cases).
31
What Happens when Applied to Interpretation Codes?
LIS EHR
HL7 TABLE 0078 INTERPRETATION CODES (V2.5.1)
Value Description CommentL Below low normal H Above high normal LU Low Urgent Between L and LL
HU High Urgent Between H and HH
LL Below lower panic limits HH Above upper panic limits … …
HL7 TABLE 0078 INTERPRETATION CODES (V2.5.1)
Value Description CommentL Below low normal H Above high normal LL Below lower panic limits HH Above upper panic limits … …
HU HU
What is displayed to the Physician for the Abnormal Flag for this Lab Result?
LIS supports the LRI Implementation Guide HL7 Table 0078 Value Set
EHR supports the HL7 Base Standard HL7 Table 0078 Value Set
• Assuming we allowed the “superset” concept for interpretations (which we don’t for LRI)• BTW, I believe the OID in the LRI guide is not longer valid since the code system has been changed which therefore
changes the semantic meaning of the terms
32
Summary
• Concept of “superset” is an over-simplification• As described (or as I heard it in the LOI calls) is incorrect and needs to
be restated• Issue is “may” support and “may” send without prior agreement with
trading partner or development of another profile is problematic• If the concept (usage) of “O-optional” is to be used then to me it can only
mean that in further agreement in profiling (which may be site agreement) that optional codes may be supported but need to be agreed upon (the optional code states if you do decide to support this concept then you SHALL use this code)– What I heard was that one party could decide to support and send where as the other
could opt not to support
• It may be applicable in some instances where the concepts are orthogonal– Although it needs to be decided upon on a case by case basis and certainly depends
on the purpose of the element– Also, it is not clear to me when for a require element an optional code is sent
• If terms are related then the semantic meaning may be changed
Binding User Table Classifications
34
Classification Summary – User Tables with BindingID Classification Description
B1 Binding Adoption of Base Standard User Table – Closed Use base table exactly and forbid extension.
B2 Binding Adoption of Base Standard User Table – Open Use base table exactly and allow extension.
B3 Binding Extension of Base Standard User Table - Closed Extended base table and forbid further extension.
B4 Binding Extension of Base Standard User Table – Open Extended base table and allow further extension.
B5 Binding Restriction of Base Standard User Table – Closed Constrained base table and forbid extension
B6 Binding Restriction of Base Standard User Table – Open Constrained base table and allow extension
B7 Binding Restriction/Extension of Base Standard User Table – Closed Constrained and extended based table and forbid further extension
B8 Binding Restriction/Extension of Base Standard User Table – Open Constrained and extended based table and allow further extension
Binding User Tables: Value Sets that originated from HL7 User. The codes given in the value set places requirements (as specified) on implementations.
The concept of “Optional” can be applied in the same manner it has been applied to the “A#-O” classifications. This is not shown in this slide deck.
35
User Tables
• User tables as defined in the HL7 standard are suggested values and may be used as given, constrained, extended, replaced, redefined.
• In essence User tables provides guidance and no requirements (anything goes).
• In IGs, often User tables are made to be definitive (binding requirements)*. That is, requirements are defined. In this regard, value sets are created that and when bound to data elements are binding requirements.
• In terms of requirements, User tables with binding requirements are equivalent to the value set derived from HL7 tables. In essence, User tables can no longer be thought of “User Tables” as defined in the HL7 standard. At this point in the specification they are equivalent to the value set that are derived from HL7 tables (in short both are binding value sets).
• For constrainable profiles, there may be some User tables that are left undefined because these are truly defined at the site (e.g., room numbers). These value sets are unspecified and open. At this level requirements are undefined.
* I should say the intent is that they are binding, however, often this is never explicitly stated. For example, HL70001 is given in an IG but it still is a User Table and if you read the
requirements as written, they are still only suggested values and implementations can use any values they’d like and still be considered conformant. Therefore, IGs need to make it clear that the table is now a value set and it is defined and it has binding requirements.
36
(B1) Adoption of Base Standard User Table – Closed
VALUE SET – HL70000 – FRUIT – BASE STANDARD
Code Code Description CommentA Apple B Banana C Cantaloupe
S Strawberry
W Watermelon
Attribute Value Attribute Value
Name Fruit Allowable Data Types IS, ID (should be ID now??)
Base Name Fruit Extensibility Closed
Identifier HL70000 Stability Static
Base Identifier HL70000 Version
Source HL7 Version 2.5.1 Delta Exact
Base Type HL7 Binding Yes
The value set adopts the base standard User table exactly. The value set is not extendable in any derived profile. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent.
37
Placeholder Slide
• Add slides for B2 to B8• In essence, the specification for these slides are the same as
A1-A8 (except that the source is from a User Table instead of an HL7 table
38
Classification Summary – User Tables with non-Binding• There is no classification for Non-Binding User Tables in an implementation
guide• There are no requirements for Non-Binding User Tables beyond identification of
the value set (table) name and identifier (a placeholder).• User tables can be specified in the implementation guide but it is not
recommended• If they are, they SHALL reside in the informative section of the implementation
guide• Specification should only be to link a particular value set (table) identifier with a
data element• User tables can be identified but place no requirements on the implementation
(these are determined in a derived profile). That is, a Non-Binding User Table is not testable.
• Non-binding User Tables can be thought of an unspecified value set in which all possible codes are optional
• The suggested values (if any) given in the standard have no standing in regards to the profile. If the table is not defined as a Binding Value Set then the user table in the standard is completely irrelevant since the derived profile will state the requirements.
39
Specification of a Value Set (derived from a User Table)
TABLE X-X. VALUE SET/CODE SYSTEM SUMMARYName Code System
IDSource Unique Identifier Comments
Administrative Sex HL70001 HL7 Version 2.5.1 To be determined To be defined in a derived profile.
• In the HL7 message the code system if used for a CNE or CWE data type SHALL be HL70001(note: need different example since PID.8 is “IS” DT).
• In the specification of the message profile (XML) the value set (table id) SHALL be the unique identifier (whatever that may be)
• In a derived profile, when the non-binding user table is made binding then it is done so by selecting one of the Binding User Table classifications.
• An element that is assigned to the value set identified, SHALL follow the rules as described in the selected Binding User Table classification.
• Implementation profiles does not have the concept of a non-binding user table.
40
Classification Summary – External Code SystemsID Classification Description
E1 Complete Adoption of Code System - Static Use code system exactly and forbid modification (fixed set-bound to a specific version).
E2 Complete Adoption of Code System - Dynamic Use code system exactly and support modification as determined by the owner of the code system. Version information must accompany code system in message.
E3 Restricted Code System - Static Value set is subset of a code system.
E4 Combined Value Set - Static Value set is created from more than one code system.
E5 Unspecified Adoption of Code System - Static A code system is specified however a specific subset is not given. All codes have an effective usage of O-Optional. Derived profiles (e.g., site agreements) shall determined the supported subset. The version in which the subset can be created is fixed (Static).
E6 Unspecified Adoption of Code System - Dynamic A code system is specified however a specific subset is not given. All codes have an effective usage of O-Optional. Derived profiles (e.g., site agreements) shall determined the supported subset. The subset (value set) can be dynamically modified.
Note: The extensibility (open/closed) property can also be applied to each of these classifications.
41
(E1) External Vocabulary – Complete Adoption of Code System - Static
The value set adopts the external code system exactly (i.e., the code system becomes the value set). The code system is specified externally. The source of truth is the referenced code system. The code system is fixed to a specific version (i.e., the set of values are static). All codes have an effective usage of R-Required. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent.
Attribute Value Attribute Value
Name FIPS 5-2 Allowable Data Types CNE, CWE
Base Name FIPS 5-2 Extensibility Closed
Identifier Stability Static
Base Identifier Version ?????
Source NIST Delta Exact
Base Type External
For the data element in which the code system is bound to, if an appropriate code from the code system describes the concept then a code from the code system SHALL be supported and sent.
VALUE SET – FIPS 5-2 – STATE – EXTERNAL
Code Usage Reference CommentAll Codes R http://www.itl.nist.gov/fipspubs/fip5-2.htm
Note: The extensibility (open/closed) property can also be applied to each of this classification.
42
(E2) External Vocabulary – Complete Adoption of Code System - Dynamic
The value set adopts the external code system exactly(i.e., the code system becomes the value set). The code system is specified externally. The source of truth is the referenced code system. The value set is determined by the current version of the referenced code system (which may change). All codes have an effective usage of R-Required. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent.
Attribute Value Attribute Value
Name CVX Allowable Data Types CNE, CWE
Base Name CVX Extensibility
Identifier Stability Dynamic
Base Identifier Version ?????
Source CDC Delta Exact
Base Type External Reference http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx
For the data element in which the code system is bound to, if an appropriate code from the code system describes the concept then a code from the code system SHALL be supported and sent.
VALUE SET – FIPS 5-2 – STATE – EXTERNAL
Code Usage Reference CommentAll Codes R http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx
Note: The extensibility (open/closed) property can also be applied to each of this classification.
43
(E3) External Vocabulary – Restricted Code System The value set restricts/constrains the external code system. The code system is specified externally. The source of truth is the referenced code system. The code system is fixed to a specific version (i.e., the set of values are static). All codes have R-Required usage. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. Note: This implies that all other codes have usage X and SHALL not be supported or sent.
Attribute Value Attribute Value
Name Facility / Visit Type (Syndromic Surveillance)
Allowable Data Types CNE
Base Name Extensibility Closed
Identifier 2.16.840.1.114222.4.11.3401 Stability N/A
Base Identifier Version 1
Source Delta Exact
Base Type External Code System NUCC
Reference http://phinvads.cdc.gov/vads/ViewValueSet.action?id=58EC5C40-F815-E011-87A0-00188B39829B
VALUE SET – 2.16.840.1.114222.4.11.3401- FACILITY / VISIT TYPE (SYNDROMIC SURVEILLANCE)
Code Code Description Comment261QE0002X Emergency Care [Ambulatory Health Care Facilities\Clinic/Center] 261QM2500X Medical Specialty [Ambulatory Health Care Facilities\Clinic/Center] 261QP2300X Primary Care [Ambulatory Health Care Facilities\Clinic/Center]
261QU0200X Urgent Care [Ambulatory Health Care Facilities\Clinic/Center]
Note: The extensibility (open/closed) property can also be applied to each of this classification.
44
(E4) External Vocabulary – Combined Value Set The value set is constructed from more than one code system. Adoption of code system may be complete or subset. The value set is no longer bound to the code systems it is made up of (i.e., it is it’s own entity). All codes have R-Required usage. The system SHALL support all codes in the value set and SHALL support only the codes in the value set. A code from the value set SHALL be sent. The code system SHALL be explicitly stated in the value set.Attribute Value Attribute Value
Name Observation Identifier (Syndromic Surveillance) Allowable Data Types CNE, CWE
Base Name Extensibility Closed
Identifier 2.16.840.1.114222.4.11.3589 Stability
Base Identifier Version
Source Delta
Base Type External Code System LONIC, PHINQUESTION
Reference http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.3589
VALUE SET – 2.16.840.1.114222.4.11.3589- OBSERVATION IDENTIFIER (SYNDROMIC SURVEILLANCE)
Code Code Description Code System Comment
8661-1 Chief complaint:Find:Pt:Patient:Nom:Reported LN
… … LN
SS001 Treating Facility Identifier PHINQUESTION
SS002 Treating Facility Location PHINQUESTION
SS003 Facility / Visit Type PHINQUESTION
Note: The extensibility (open/closed) property can also be applied to each of this classification.
45
Code System Defined – Specific Codes Unspecified - Static• In some circumstances implementation guides will specify a code system or
code systems that is to be used for a data element but will not specify specific values (i.e., a specific value set). That is, no values are explicitly specified.
• The intent for such data elements is to require a code from the code system(s) but the actual codes are not specified.
• Therefore, the set of codes required to be implemented are determined in a derived profile (e.g., by site agreement).
• Such a table can be thought of as having all elements as Optional that need further specification.
• Vendors will build to their capabilities or to the needs of various customers. However, for any given interface an exact specification of concepts supported must definitively be determined in an implementation profile.
• For LONIC (LRI) an eDOS can be used to establish the in-scope concepts that are supported.
• Important: When a code system is specified for use in a particular element, if the concept being expressed can be described by the specified code system then a code from the code system SHALL be used. That is, in the derived profile implementers do not have the liberty to use local codes when a “standardized” code is available.
46
(E5) External Vocabulary – Unspecified Adoption of Code System - Static
An external vocabulary is specified but no explicit codes are given. The code system is fixed to a specific version (i.e., the set of values are static). All codes have an effective usage of O-optional Derived profiles will select from the specified code system to create the value set. The system SHALL have the capability of supporting any (or one) of the codes in the specified vocabulary. Once determined, if the concept being expressed is represented in the value set, a code from the value set
SHALL be sent. If the concept is needed in the profile, the code SHALL come from the named vocabulary. Testing Issue: Customization of test cases may be needed to test the spectrum of implementations.Attribute Value Attribute Value
Name LOINC Allowable Data Types CNE, CWE
Base Name LONIC Extensibility
Identifier Stability Static
Base Identifier Version
Source LOINC Version X.X Delta
Base Type External
No explicit codes are given, only the code system is specified. Therefore, the supported concepts and codes are determined in derived profiles that meet the requirements of the use case(s) described in the derived profile. The use case(s) (specific) are contained by the use case(s) (general) described in the base (parent) profile. Derived profiles can be site agreements. For the data element in which the code system is bound to, if an appropriate code from the code system describes the concept then a code from the code system SHALL be supported and sent. All derived profiles shall determined the supported subset.
VALUE SET – LONIC – LAB RESULTS– EXTERNAL
Code Usage Reference CommentAll Codes O http://loinc.org/
47
(E6) External Vocabulary – Unspecified Adoption of Code System - Dynamic
An external vocabulary is specified but no explicit codes are given. The code system is determined by the current version of the referenced code system (which may change). All codes have an effective usage of O-optional Derived profiles will select from the specified (current) code system to create the value set. The system SHALL have the capability of supporting any (or one) of the codes in the specified vocabulary. Once determined, if the concept being expressed is represented in the value set, a code from the value set
SHALL be sent. If the concept is needed in the profile, the code SHALL come from the named vocabulary. Testing Issue: Customization of test cases may be needed to test the spectrum of implementations.Attribute Value Attribute Value
Name LOINC Allowable Data Types CNE, CWE
Base Name LONIC Extensibility
Identifier Stability Dynamic
Base Identifier Version
Source LOINC Version X.X Delta
Base Type External
No explicit codes are given, only the code system is specified. Therefore, the supported concepts and codes are determined in derived profiles that meet the requirements of the use case(s) described in the derived profile. The use case(s) (specific) are contained by the use case(s) (general) described in the base (parent) profile. Derived profiles can be site agreements. For the data element in which the code system is bound to, if an appropriate code from the code system describes the concept then a code from the code system SHALL be supported and sent. All derived profiles shall determined the supported subset.
VALUE SET – LONIC – LAB RESULTS– EXTERNAL
Code Usage Reference CommentAll Codes O http://loinc.org/
48
Discussion: Sender and Receiver Requirements• Take for example the requirement for supporting LOINC codes for
laboratory resulted tests. What impact does the specification of LOINC have on the sender and receiver implementations?
• Does requiring codes 718-7, 2093-3, 2571-8, 2085-9, and 2089-1 for Hemoglobin, Cholesterol, Triglyceride, Cholesterol in HDL, and Cholesterol in LDL require that all LISs have the capability to support these tests?
• What does the EHR have to be able to support? Is it much easier to state that the EHR has to support all since it is a “generality” requirement (since they are to incorporate/display the results which is the same requirement across the spectrum of LOINC codes—or is it?), where as for the Lab (sender) it is specific functionality (Equipment)? Most labs won’t cover the entire spectrum (is this an accurate statement?).
• How does/can the lab compendium come into play when specifying value set requirements?
• When specifying requirements do we want to distinguish between what an implementer (EHR, I guess in this case) SHALL support as opposed to what the EHR is configured to support at particular site installations?
49
Open and Closed Value Sets
• This concept determines whether a value set can be extended in derived profile (specification).
• Closed– The value set is fixed in derived profiles. Closed does not mean that the
value set can’t be extended or modified in a revision or errata to the implementation guide. At that point it is a new entity.
• Open– The value set may be extended in a derived profile. Therefore, local sites
have the latitude to extend to meet their requirements that aren’t specified in the base (parent) specification.
• It is important to note that derived profiles can break such rules if they want to leverage the utility (for their related but different requirement; it is best to document this as a profile component) of the implementation guide. However, this is a profile (specification) compliance violation and systems that implement will be found non-conformant to the base (parent) specification.
50
Open/Closed Value Set Conformance Assessment• Open – The concept is not apply to implementation profiles.• Open – If the concept being expressed is
51
Static and Dynamic Value Sets
• From HITSP C80• Value Set Binding:
– This attribute will record whether the value set is bound to data elements statically or dynamically. A statically bound value set has its values fixed until a new version of the value set is released. Extensional Value Sets are typically statically bound. A dynamically bound value set has its definitions fixed, but the values in the set may vary as new versions of the code system upon which they are based are released. Intensional values sets are often dynamically bound. When statically bound, an intensional value set must specify the version of the code system being used before the members of the value set can be computed.
• What does it mean?– Static means it doesn’t changed and implementers know that it will remain
for this version of the specification. That is, the value set is fixed.– Dynamic means that the value set can change with new versions and the
implementers are expected to modify implementations to stay in synchronization with the value set. For purposes of testing is their a lag time? Testing tools would also have to stay synchronized.
Value Set Specification for Multiple Profiles
53
Specification of a Value Set for Multiple Profiles• The implementation guide will often cover multiple use cases
and therefore multiple interactions• For each interaction there may be a particular message type
and various uses of the message type• In this case, the value set must be specified such that only the
codes that apply to the interaction (message) are given• This can be accomplished using the value set usage codes
and additional columns indicating the profile
VALUE SET – P1_HL70000 – P1_FRUIT – EXTENDED
Code Code Description Profile 1 Profile 2 Profile 3 CommentA Apple R X R B Banana R X R C Cantaloupe R X R
G Grape R X R
M Mango O R R
S Strawberry O R R
W Watermelon R X R
Definitions, Reference, and Discussion
55
Vocabulary Data Type Elements – Coded Elements CE – Coded Element
This data type transmits codes and the text associated with the code. CF – Coded Element with Formatted Values
This data type transmits codes and the formatted text associated with the code. This data type can be used to transmit for the first time the formatted text for the canned text portion of a report, for example, a standard radiological description for a normal chest X‑ray. The receiving system can store this information and in subsequent messages only the identifier need be sent. Another potential use of this data type is transmitting master file records that contain formatted text.
CNE – Coded no-exceptions Specifies a coded element and its associated detail. The CNE data type is used
when a required or mandatory coded field is needed. The specified HL7 or externally defined table must be used and may not be extended with local values. Text may not replace the code. A CNE field must have an HL7 defined or external table associated with it. It must be specified in the standard.
CWE – Coded with-exceptions Specifies a coded element and its associated detail. The CWE data type is used
when 1) more than one table may be applicable or 2) the specified HL7 or externally defined table may be extended with local values or 3) when text is in place, the code may be omitted.
56
CNE - Coded no-exceptions
Specifies a coded element and its associated detail. The CNE data type is used when a required or mandatory coded field is
needed. The specified HL7 or externally defined table must be used and may not be
extended with local values. Text may not replace the code. A CNE field must have an HL7 defined or external table associated with it. It
must be specified in the standard.
Conformance Summary All the concepts that can be expressed by this element are defined in the
value set. The system SHALL support all codes in the value set and SHALL support only
the codes in the value set. A code from the value set SHALL be sent. The value set is not extendable in any derived profile (i.e., CNE implies
closed). A code SHALL be sent for this element. Text MAY be sent in addition to the code.
57
CWE – Coded with-exceptions
Specifies a coded element and its associated detail. The CWE data type is used when 1) more than one table may be applicable or
This is the value set (which can contain values from one or more table or code system
2) the specified HL7 or externally defined table may be extended with local values or This would be applicable to value set with the “Open” property
3) when text is in place, the code may be omitted. I would the think the reverse would be true and write as follows: If the concept is expressed by a code in the specified value set, then a code from the value set
SHALL be used.
Conformance Summary If the concept being expressed by a code in the specified value set, then a code
from the value set SHALL be used. The value set may be extended in a derived profile. If the value set does not expressed the appropriate concept then the code
SHALL be omitted and text SHALL be used ISSUE: Where does the text go, CWE.2 (or CWE.5) or CWE.9? There is
conflicting guidance in standard.
58
CWE Data Type in LRI
• The definition of the CWE data type has been effectively changed by the data type flavor
• Does it matter anymore what the data type base is?• Does it make sense to change the data type? For example,
CWE CNE. Does the standard allow for this?• Does the set of current data types express all the concepts
needed to support all the value set specification variations?TABLE 2‑3. CODED WITH EXCEPTIONS – CODE REQUIRED – (CWE_CR)
Component Name DT Usage Value Set Comments Identifier ST R Text ST RE It is strongly recommended that text be sent to accompany any identifier. Name of Coding System ID R HL70396 Alternate Identifier ST RE The alternate identifier (from the alternate coding system) should be the closest
match for the identifier found in CWE_CR.1. Alternate Text ST RE It is strongly recommended that alternate text be sent to accompany any
alternate identifier. Name of Alternate Coding System ID C(R/X) HL70396 Condition Predicate: If CWE_CR.4 (Alternate Identifier) is valued Coding System Version ID O Alternate Coding System Version ID O Original Text ST RE Original Text is used to convey the text that was the basis for coding.
59
Vocabulary Data Type Elements - Tables
ID – Coded Value for HL7 Defined Tables The value of such a field follows the formatting rules for an ST field
except that it is drawn from a table of legal values. There shall be an HL7 table number associated with ID data types. An example of an ID field is OBR-25-result status. This data type should be used only for HL7 tables. The reverse is not true, since in some circumstances it is more appropriate to use the CNE or CWE data type for HL7 tables.
IS – Coded Value for User-Defined Tables The value of such a field follows the formatting rules for a ST field
except that it is drawn from a site-defined (or user-defined) table of legal values. There shall be an HL7 table number associated with IS data types. An example of an IS field is the Event reason code, "Event reason code". This data type should be used only for user-defined tables. The reverse is not true, since in some circumstances, it is more appropriate to use the CWE data type for user-defined tables.
60
Table Types HL7
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). Do we mean SHALL NOT?
User 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, that 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 IS 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.
External 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, the encoding of clinical observations using LOINC codes. The CE, CF, CNE and CWE data type are used to represent values for these fields.
Local 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.
61
Tables Discussion—Chapter 2B Conformance
The allowed code sets (table) for many fields within the HL7 Standard are specified as user-defined (data type IS) or HL7-defined (data type ID) values.
In these cases, the exact allowed code set shall be specified. These values shall be defined according to the specified scope of use for the message profile by vendors, provider, or within a realm.
Coded Entry (CE, CF, CWE, and CNE) type fields are specified as being populated based on coding systems. For each of these fields, the specific coding system used shall be identified. Compliant applications are required to use the specified coding system, but may also use an alternate coding system as supported by the data type (See the example within each data type definition). Here there is no statements about creating value set from this code systems when it
is appropriate to constrain the code system. For the ID (HL7) and Is (User) tables this statement is made.
No indication that a CWE can be profiled to CNE Is it written in the standard that you MAY or SHALL NOT?
62
Allowable Constraints
Implementation Profile
Base Data Type
Proposed Allowable Constraint
BaseExtensible
Base Table Types
CNE CNE No HL7, External
CWE CWE, CNE Yes HL7, Local, External
ID ID, CNE Yes HL7
IS IS, CWE, ID, CNE Yes User (Local?)
Constrainable Profile
Base Data Type
Proposed Allowable Constraint
BaseExtensible
Base Table Types
CNE CNE No HL7, External
CWE CWE, CNE Yes HL7, Local, External
ID ID, CNE Yes HL7
IS IS, CWE, ID, CNE Yes User (Local?)
63
Allowable Table Mappings
Data Type Allowable Tables
CNE HL7, External, User, Local
CWE HL7, External, User, Local
ID HL7
IS User
Summary of standard Is this correct?
64
Extending a Value Set
• When a “table” is extended, what is the code system of the codes that are added?
• Can go back to source and officially add it?• Could be local?• Needs new identifier?• Only applies to CNE and CWE
65
To Do
• Provide the conformance assessment for each of the classifications (message validation)
• Provide verification assessment for profiles (profile comparison-applies to open/delta combinations only)
• Boil down the classifications to a set of concepts and rules• Provide classification for implementation profiles. Probably the
classification will exist, but only selected ones will apply for implementation profiles.
LRI Table Analysis and Classification
67
Overview and Purpose• The goal is to classify the value set in alignment of the implementation and
use expectations• Codes *shall* only be specified if it meets the requirements of the use case• We are not determining code sets, but rather value sets. That is, what are
the allowable values for the profile or profiles defined in the implementation guide.
• This does not necessarily preclude additional codes to be used for related use cases. The classification of the value set determines that.
• It is important to remember that the purpose (scope) of the implementation guide to specify the necessary requirements to meet the expectations of the use cases described in the implementation guide and nothing more.
• Vendors make a claim of conformance to the implementation guide shall follow the requirements entirely
• Not all requirements can be completely specified at the implementation guide level (constrainable profile level)
• Use case refinement (as allowed by the implementation guide) are necessary (e.g., Laboratory Resulted Tests supported and therefore the relevant LONIC codes)
68
HL7 TABLE 0065 – SPECIMEN ACTION CODE (V2.7.1) TABLE 4‑3. HL7 TABLE 0065 SPECIMEN ACTION CODE (V2.7.1)
Value Description Comment
A Add ordered tests to the existing specimen R
G Generated order; reflex order R
L Lab to obtain specimen from patient R
O Specimen obtained by service other than Lab R
X O
Y O
Z O
Option 1) OPEN – Other 3 values from 0065 are also allowed, plus others
Option 2) CLOSED Option 3) OPEN – Add whatever.
Classification: (A1) Restriction of Base Standard HL7 Table – Closed
Value Set Level Open/Closed – Means that additional values can be added from …. Internal/External Dynamic/Static
Value Level
69
• Suggestion:– Mark all Value Sets as OPEN where the value set contains nothing but
orthogonal – List all Required values– All other elements are OPTIONAL, requiring trading partners to agree on
values first (different definition of OPTIONAL on fields/segments)• Perhaps call it ALLOWED to avoid confusion.
– ?List all Not Supported values?
• Different
70
HL7 TABLE 0076 – MESSAGE TYPE (V2.5.1)
Classification: None Recommendation: Remove the table all together and disassociate the table number from the
element. This is a constant value; replace with conformance statements. For ORU profiles, CS-1: MSH.9.1 (Message Code) SHALL contain the constant value ‘ORU’ For ACK profiles, CS-2: MSH.9.1 (Message Code) SHALL contain the constant value ‘ACK’ Remove the reference of table 0076 from the data type entry Note, this is an HL7 table. It is important to recognize that we are not changing table 0076. We are
in essence creating a value set from it. This is in alignment with the standard (I think….).
TABLE 4‑4. HL7 TABLE 0076 MESSAGE TYPE (V2.5.1)
Value Description Comment
ORU Unsolicited transmission of an observation message ACK General acknowledgment message
TABLE 2‑20. MESSAGE TYPE (MSG)
SEQ Component Name DT Usage Value Set Comments
1 Message Code ID R HL70076 (constrained)
2 Trigger Event ID R HL70003
3 Message Structure ID R HL70354 (constrained)
71
HL7 TABLE 0078 – INTERPRETATION CODES (V2.5.1)
Classification: (B3) Binding Extension of Base Standard User Table - Closed Recommendation: Change element data type to ID—not really sure about this since it probably
won’t cover all cases—best to stick to classification attributes; need to associate a different identifier (name) with the value set since it is different.
The values LU and HU are added to the values listed in the V2.5.1 User Defined table to support the LRI use case. No further extensions are allowed. HL7 has been requested to add these values to a future V2 base standard version.
TABLE 4‑5. HL7 TABLE 0078 INTERPRETATION CODES (V2.5.1)
Value Description CommentL Below low normal H Above high normal LU Low Urgent Between L and LLHU High Urgent Between H and HHLL Below lower panic limits HH Above upper panic limits < Below absolute low-off instrument scale > Above absolute high-off instrument scale N Normal (applies to non-numeric results) A Abnormal (applies to non-numeric results)
AA Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)
null No range defined, or normal ranges don't apply U Significant change up D Significant change down B Better—use when direction not relevant W Worse—use when direction not relevant S Susceptible. Indicates for microbiology susceptibilities only. R Resistant. Indicates for microbiology susceptibilities only. I Intermediate. Indicates for microbiology susceptibilities only. MS Moderately susceptible. Indicates for microbiology susceptibilities only. VS Very susceptible. Indicates for microbiology susceptibilities only.
72
HL7 TABLE 0123 – RESULTS STATUS (V2.5.1)
Classification: (A5) Restriction of Base Standard HL7 Table - Closed
Table 4‑6. HL7 Table 0123 – Result Status (V2.5.1)
Value Description CommentA Some, but not all, results available C Correction to results F Final results; results stored and verified. Can only be changed with a corrected result. I No results available; specimen received, procedure incomplete O Order received; specimen not yet received P Preliminary: A verified early result is available, final results not yet obtained R Results stored; not yet verified S No results available; procedure scheduled, but not done X No results available; Order canceled.
73
HL7 TABLE 0125 – VALUE TYPE (V2.5.1)
Classification: (A5-O) Restriction of Base Standard HL7 Table – Closed - Optional
Table 4‑7. HL7 Table 0125 – Value Type (V2.5.1)
Value Description Usage Data Type Flavor Comment
CE Coded Entry R When sending text data in OBX-5, use either the ST, TX or FT data types.
CWE Coded with Exceptions R CWE_CROData type to be used where it is important to communicate the coding system and coding system version with the coded result being reported. Pre-adopted from Version 2.6.
This Implementation Guide has specially constrained versions of the CWE data type in Section 2.2 through 2.4. The CWE_CR format shall be used for OBX-5. When sending text data in OBX-5, use either the ST, TX or FT data types.
CX Extended Composite ID With Check Digit O Varies Use the appropriate CX flavor (CX-GU or CX-NG or base standard) depending on
the format of the observation value and as agreed to between the sender/receiver.
DT Date R
ED Encapsulated Data O When using the Source Application ID component it should use the HD data type formatting considerations outlined in the base standard, not the constrained HD definitions in this IG.
FT Formatted Text (Display) R Field using the FT data type to carry a text result value. This is intended for display. The text may contain formatting escape sequences as described in the data types section. Numeric results and numeric results with units of measure should not be reported as text. These should be reported as NM or SN numeric results, with the units of measure in OBX-6.
NM Numeric R Field using the NM data type to carry a numeric result value. The only non-numeric characters allowed in this field are a leading plus (+) or minus (-) sign. The structured numeric (SN) data type should be used for conveying inequalities, ranges, ratios, etc. The units for the numeric value should be reported in OBX-6.
RP Reference Pointer O When using the Application ID component it should use the HD data type formatting considerations outlined in the base standard, not the constrained HD definitions in this IG.
SN Structured Numeric R Field using the SN data type to carry a structured numeric result value. Structured numeric include intervals (^0^-^1), ratios (^1^/^2 or ^1^:^2), inequalities (<^10), or categorical results (2^+). The units for the structured numeric value should be reported in OBX-6.
ST String Data R Field using the ST data type to carry a short text result value. Numeric results and numeric results with units of measure should not be reported as text. These shall be reported as NM or SN numeric results, with the units of measure in OBX-6.
TM Time R The timezone offset shall adhere to the use of the TimeZone Offset profile.
TS Time Stamp (Date & Time) R TS_0 The timezone offset shall adhere to the use of the TimeZone Offset profile and associated discussion if the granularity involves hh or “more”.
TX Text Data (Display) R Field using the TX data type to carry a text result value this is intended for display. Numeric results and numeric results with units of measure should not be reported as text. These should be reported as NM or SN numeric results, with the units of measure in OBX-6.
74
HL7 TABLE 0203 – IDENTIFIER TYPE (V2.7.1)Table 4‑8. HL7 Table 0203 – Identifier Type (V2.7.1)
Value Description Comment
AM American Express
AN Account number
ANC Account number Creditor
AND Account number debitor
UPIN Medicare/CMS (formerly HCFA)_s Universal Physician Identification numbers
VN Visit number
VS VISA
WC WIC identifier
WCN Workers_ Comp Number
XX Organization identifier
More here…
Classification: (A1) Adoption of Base Standard HL7 Table - Closed
75
HL7 TABLE 0291 – SUBTYPE OF REFERENCED DATA (V2.7.1)Table 4‑9. HL7 Table 0291 – Subtype Of Referenced Data (V2.7.1)
Value Description Comment
Source RFC 2046
MIME media subtypes established in accordance with RFC 2046 (http://ietf.org/rfc/rfc2046.txt) and registered with the Internet Assigned Numbers Authority (http://www.iana.org/numbers.html). Note that the MIME media subtype values are case-insensitive, in accordance with RFC 2045.
x-hl7-cda-level-one HL7 Clinical Document Architecture Level One document Not supported.
Classification: ?????
76
HL7 TABLE 0301 - UNIVERSAL ID TYPE (V2.7.1)
Classification: Suggest to use table on following slide.
TABLE 4‑10. HL7 TABLE 0301 - UNIVERSAL ID TYPE (V2.7.1)
Value Description Usage Comment
CLIA Clinical Laboratory Improvement Amendments. Allows for the ability to designate organization identifier as a "CLIA" assigned number (for labs) RE
DNS An Internet dotted name. Either in ASCII or as integers C(X/O)Condition Predicate: If Component GU is used on the field using this value set
GUID Same as UUID. C(X/O)Condition Predicate: If Component GU is used on the field using this value set
CEN The CEN Healthcare Coding Scheme Designator. (Identifiers used in DICOM follow this assignment scheme.) C(X/O)
Condition Predicate: If Component GU is used on the field using this value set
HL7 Reserved for future HL7 registration schemes C(X/O)Condition Predicate: If Component GU is used on the field using this value set
ISO An International Standards Organization Object Identifier RUsed as the Universal ID Type in the CNN, EI and HD data types.
L,M,N These are reserved for locally defined coding schemes. C(X/O)Condition Predicate: If Component GU is used on the field using this value set
Random
Usually a base64 encoded string of random bits. The uniqueness depends on the length of the bits. Mail systems often generate ASCII string _unique names," from a combination of random bits and system names. Obviously, such identifiers will not be constrained to the base64 character set.
C(X/O)
Condition Predicate: If Component GU is used on the field using this value set
URI Uniform Resource Identifier RUsed as the Universal ID Type in the RP data type
UUID The DCE Universal Unique Identifier C(X/O)Condition Predicate: If Component GU is used on the field using this value set
x400 An X.400 MSH format identifier C(X/O)Condition Predicate: If Component GU is used on the field using this value set
x500 An X.500 directory name C(X/O)Condition Predicate: If Component GU is used on the field using this value set
77
HL7 TABLE 0301 - UNIVERSAL ID TYPE (V2.7.1)
Classification: GU A5 NG/others A5-O ?????
TABLE 4‑10. HL7 TABLE 0301 - UNIVERSAL ID TYPE (V2.7.1)
Value DescriptionGU Profile
NG/OtherProfile?
Comment
CLIA Clinical Laboratory Improvement Amendments. Allows for the ability to designate organization identifier as a "CLIA" assigned number (for labs) RE RE What does RE mean in this context? Should be
R?
DNS An Internet dotted name. Either in ASCII or as integers X O
GUID Same as UUID. X O
CEN The CEN Healthcare Coding Scheme Designator. (Identifiers used in DICOM follow this assignment scheme.) X O
HL7 Reserved for future HL7 registration schemes X O
ISO An International Standards Organization Object Identifier R RUsed as the Universal ID Type in the CNN, EI and HD data types.
L,M,N These are reserved for locally defined coding schemes. X O
Random
Usually a base64 encoded string of random bits. The uniqueness depends on the length of the bits. Mail systems often generate ASCII string _unique names," from a combination of random bits and system names. Obviously, such identifiers will not be constrained to the base64 character set.
X O
URI Uniform Resource Identifier R RUsed as the Universal ID Type in the RP data type
UUID The DCE Universal Unique Identifier X O
x400 An X.400 MSH format identifier X O
x500 An X.500 directory name X O
78
HL7 TABLE 0353 – CWE STATUS CODES
Classification: (A1) Adoption of Base Standard HL7 Table – Closed Why the usage column? The binding of the element to the table in the element definition will set the
requires for where table 0353 can be used. I don’t think it needs to be restated here.
Table 4‑11. HL7 Table 0353 – CWE Status Codes
Value Description Usage Comment
U Unknown R
UASK Asked but Unknown R
NAV Not available R
NA Not applicable R
NASK Not asked R
Usage Note: This table is not constrained for this implementation guide. It is however constrained on where the table can be used. Table HL70353 can be used for coded values except for elements OBX-5 and SPM-4.
79
HL7 TABLE 0354 – MESSAGE STRUCTURE (V2.5.1)
Classification: Suggest to remove table binding and make this a constant via a conformance statement.
Table 4‑12. HL7 Table 0354 (V2.5.1)
Value Description Usage CommentORU_R01 Unsolicited transmission of an observation message R Required for Profiles:
LRI_GU_RU_ProfileLRI_GU_RN_ProfileLRI_NG_RU_ProfileLRI_NG_RN_Profile
ACK General Acknowledgment Message for unsolicited transmission of an observation message
R Required for Profiles:LRI_Acknowledgement_ComponentGU_Acknowledgement_ComponentNG_Acknowledgement_Component
80
HL7 Table 507 – Observation Result Handling (V2.7.1)
Classification: (B3) Binding Extension of Base Standard User Table – Closed Note: v2.7.1 only contains code F and N.
Table 4‑13. HL7 Table 0507 - Observation Result Handling (V2.7.1)
Value Description Comment
F Film-with-patient
N Notify provider when ready
A Alert provider when abnormal Added in profile?
CC Copies Requested Added in profile?
BCC Blind Copy Added in profile?
81
HL7 TABLE 0834 – MIME TYPE (V2.7.1)
Classification: None as listed since the table type in the standard in “undefined”. Maybe this is a problem with the standard since it is given a number and listed in Appendix A.
(B5-O) Binding Restriction of Base Standard User Table – Closed – Optional seems to be most appropriate.
Table 4‑14. HL7 Table 0834 – MIME Type
Value Description Usage Comment
application Application data O
audio Audio data O
image Image data R
model Model data O
text Text data R
video Video data O
multipart MIME multipart package O
82
OBX.3 LONIC3 Observation Identifier CWE_CR R [1..1] Logical
Observation Identification Name and Codes (LOINC)
LOINC shall be used as the standard coding system for this field if an appropriate LOINC code exists. Appropriate status is defined in the LOINC Manual Section 11.2 Classification of LOINC Term Status. If a local coding system is in use, a local code should also be sent to help with identification of coding issues. When no valid LOINC exists the local code may be the only code sent.When populating this field with values, this guide does not give preference to the triplet in which the standard (LOINC) code should appear.
Classification: (E6) External Vocabulary – Unspecified Adoption of Code System - Dynamic