HL7 V2 Vocabulary Specification V alue Set Classification Proposal

1. HL7 V2 Vocabulary Specification Value Set Classification Proposal DRAFT VERSION FOR DISCUSSION PURPOSES HL7 Conformance and Guidance for Implementation and Testing (CGIT) WG Robert Snelick National Institute of Standards and Technology July 10th, 2013 (Draft 8) Contact: robert.snelick@nist.gov

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.

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

8. Usage – System Capabilities Requirements (Constrainable Profile) Bob Y suggests the concept of “A - Allowed” * 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.

9. Classification Summary – HL7 Tables 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 extended Closed – no local extension Version of the value set Ancestry – 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 • 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.

13. (A3) Extension of Base Standard HL7 Table - Closed • 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

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.

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. Format Option 1

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 2

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

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 2

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

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. Format Option 2

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

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

24. Classification Summary – HL7 Tables – w/ Optional Codes 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.

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.

27. Placeholder Slide Provide detail for A3-O to A8-O

28. Superset Concept using Optional Usage Discussion

29. Concerns of Proposed Superset Concept (LOI) • 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 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 HU HU What is displayed to the Physician for the Abnormal Flag for this Lab Result? EHR supports the HL7 Base Standard HL7 Table 0078 Value Set LIS supports the LRI Implementation Guide 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

33. Binding User Table Classifications

34. Classification Summary – User Tables with Binding 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 * 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. 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.

36. (B1) Adoption of Base Standard User Table – Closed • 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) • 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 Systems 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 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. • 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. 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 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. • 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. 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. 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. 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 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. • 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.

47. (E6) External Vocabulary – Unspecified Adoption of Code System - Dynamic 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. • 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.

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