Abstract
Specifications state requirements for applications and systems. In order to specify these requirements precisely and consistently, conformance constructs are employed. Unfortunately, the set of conformance constructs are not defined sufficiently and uniformly across the spectrum of data exchange standards. A generic concept-level definition of common conformance constructs is presented in this chapter. More detailed definitions related to this information, including comparing and contrasting the variations of the conformance constructs across the assorted standards, also are discussed. The in-depth analysis will help the reader understand the salient facets of these constructs.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
The term vocabulary has a much broader context than stated here.
- 2.
Forbidden elements usually only appear in long-lasting standards where a better way to express certain information will be established later on, or in profiles where the element doesn’t apply to the constraint use case.
- 3.
It must be noted, that “maiden name” is different from “mother’s maiden name”.
- 4.
However, in practice a significant number of code systems are defined for a very limited use case, thus not allowing for re-use. Quite often code systems are invented just because of a lack of time to define appropriate value sets consisting of codes from existing code systems. On the other hand, some code systems such as LOINC and SNOMED CT have broad applicability and opportunity for reuse.
- 5.
Depending on the data exchange standard (see Chaps. 4 and Appendix), this still is common practice.
- 6.
There is a subtle difference between a table consisting of codes and associated descriptions and a code system with concepts, display names, descriptions, formal identification, and other controlling and explanatory detail.
- 7.
This is in conflict with some views in which a binding is only to a value set. However, in the definition of vocabulary in specifications, an association is made at all levels. Whether it is called a binding or not is not the key point, the point that an explicit association is made, is.
- 8.
In this context, vocabulary is used to refer to concept domain, code system, or value set.
- 9.
However, a value set can use an entire code system.
- 10.
To simplify explanation this definition includes meta data and the codes. See recent work in HL7 [5] and discussion to follow in which the Value Set Definition consists of the meta data and information to determine the codes. The generated list is known as the Value Set Expansion.
- 11.
Check marks are used for simplicity and replaced by more detailed usage concepts later on.
- 12.
As mentioned, HL7 v2.x tables are not yet formally code systems, and HL70001 is used here as a simple example. For convenience, HL7 v2 tables are referred to as code systems.
- 13.
The term “Usage” here is not related to the usage of elements (e.g., R, RE, etc.) described earlier in this chapter; See Chap. 7 for details of vocabulary usage.
- 14.
Only for concepts that don’t exist; i.e., a new code can’t be added for an existing concept.
- 15.
Referred to as a value set expansion in HL7 V3 (and as of May 2016, in all of HL7 with the publication of the Value Set Definition specification [5]).
- 16.
In essence a new value set has been created.
- 17.
Note: for this value set the choice was made to list only the included codes in the value set definition.
- 18.
Note: CNE and CWE convey different concepts in v2 versus V3.
- 19.
Conformance statement is an overloaded term. At a low-level it is used for expressing requirements in a specification. At a high-level it is used to express a capability of a system or product; the low-level use is described in this section.
- 20.
For HL7 v2.x, the carriage return character also belongs in this category, requiring a proper escaping. Errors for wrong handling are, in most cases, visible for text fields, allowing the user to enter multiple lines of text.
- 21.
It must be noted that most applications do not account for escaping delimiters, which is the reason for many compatibility issues and the request to constrain the set of delimiters to fixed values.
- 22.
Some databases like mySQL/Maria allow for individual character sets for table columns.
- 23.
In this book, concepts are typically explained in the context of messages, but the concepts apply equally to documents.
- 24.
If the implementation of HL7 v2 ER7 is performed correctly, one can access any field, component or sub-component in a segment—even if it is not defined! As an example, the access to PID-255.3.1 should not fail, but return an empty string. Of course, an interface program will only access the elements it is aware of. A common solution to these problems, however, is to append new elements to existing standard segments, although this behavior is improper; and access to such an element in a message from a trading partner not supporting these additions should not return an error.
- 25.
In newer versions of HL7 v2.x, two new segments (SGH and SGT) are defined that should support marking the beginning and end of a group, implicitly helping in parsing the message structure. Starting with v2.8.1 these segments are used in OMQ_O42 only and not added to older messages for backward compatibility reasons.
References
Adapted from HL7 Version 2.8 Chapter 2B Conformance, Section 2.B.7.4, http://www.hl7.org.
HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide. Release 1 – US Realm DSTU – March 2016 http://www.hl7.org.
HL7 Tables Project Wiki. HL7 Vocabulary and Conformance Working Groups. http://wiki.hl7.org/index.php?title=V2_Code_Table_Project
HL7 Value Set Binding Project Wiki. HL7 Vocabulary and Conformance Working Groups. http://wiki.hl7.org/index.php?title=Binding_Syntax
HL7 Specification: Characteristics of a Formal Value Set Definition, Release 1. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=437
HL7 Implementation Guide for CDA® Release 2: Early Hearing Care Plan (Universal Realm) Draft Standard For Trial Use February 2013.
Hom T. Encoding, http://www.torsten-horn.de/techdocs/encoding.htm
DICOM. Digital Images and Communication in Medicine, http://www.rsna.org/Technology/DICOM/index.cfm
Fast Healthcare Interoperability Resources, http://www.hl7.org/fhir
Health Level 7 (HL7). HL7 Standard Version 2.5, ANSI/HL7 V2.5-2003, June 26, 2003, http://www.hl7.org.
HL7 Version 2: XML Encoding Syntax, Release 1. ANSI/HL7 V2 XML-2003; June 4, 2003; Release 2. ANSI/HL7 V2 XML-2012; 2012.
Health Level 7 (HL7): HL7 Standard Version 3, http://www.hl7.org.
Snelick R: HL7 v2 Value Set Specification Proposal. Profiling Vocabulary in HL7 v2 Implementation Guides. Original September 2013; last update June 2015. http://hl7v2tools.nist.gov (Publications/Presentations and Technical Documents).
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2016 Springer International Publishing Switzerland
About this chapter
Cite this chapter
Oemig, F., Snelick, R. (2016). Conformance Constructs. In: Healthcare Interoperability Standards Compliance Handbook. Springer, Cham. https://doi.org/10.1007/978-3-319-44839-8_5
Download citation
DOI: https://doi.org/10.1007/978-3-319-44839-8_5
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-44837-4
Online ISBN: 978-3-319-44839-8
eBook Packages: Computer ScienceComputer Science (R0)