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.


If the code is present in the message an error SHALL NOT be raised. *

X Not-Supported The code SHALL NOT be supported.


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.



S Strawberry

W Watermelon



Base Name Fruit Extensibility Open




Base Type HL7

13

(A3) Extension of Base Standard HL7 Table - Closed

VALUE SET – P1_HL70000 – P1_FRUIT – EXTENDED


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


Name P1_Fruit Allowable Data Types ID


Identifier P1_HL70000 Stability Static


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



S Strawberry

W Watermelon






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


Format Option 1






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







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









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










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.





Format Option 1






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.


Code Code Description CommentA Apple R B Banana R C Cantaloupe R

G Grape R Added in Profile

M Mango R Added in Profile



Format Option 2







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).





Format Option 1







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.





Format Option 1







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.



Base Name Fruit Extensibility Closed - Optional



Source HL7 Version 2.5.1 Delta Exact - Optional

Base Type HL7



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.



Base Name Fruit Extensibility Closed - Optional



Source HL7 Version 2.5.1 Delta Exact - Optional

Base Type HL7



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


G Green R

B Blue R

Y Yellow O

P Pink X

O Other R

TABLE 0000 – IMPLEMENTATION B


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


G Green R

B Blue R

Y Yellow Supported

P Pink X

O Other R

TABLE 0000 – COLOR – PROFILED TABLE


G Green R

B Blue R

Y Yellow O

P Pink X

O Other R

TABLE 0000 – IMPLEMENTATION B


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



S Strawberry

W Watermelon


Name Fruit Allowable Data Types IS, ID (should be ID now??)





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.


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.


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


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.


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]


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


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


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


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)


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)


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)


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


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)


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


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

hl7 v2 vocabulary specification v alue set classification proposal

Documents

source implementation

standard implementation

resulting implementation

requirements of capabilities

local requirements

extraneous requirements

site specific requirements

given use case