Health Level Seven (HL7) See Version 2 (V2) Standard Quality Criteria
...
Co-Chair and Editor:
...
Anthony Julian
Mayo Clinic
...
Co-Chair
...
Nick Radov
United HealthCare Services, Inc
...
Co-Chair
...
Sandra Stuart
Kaiser Permanente Information Technology
...
Sponsoring Work Group:
...
Infrastructure and Messaging
...
List Server:
...
| Table of Contents | ||
|---|---|---|
|
Overview
This document contains a proposed starting set of Health Level Seven (HL7) Version 2 (V2) Standard Quality Criteria. Once finalized, the V2 Management Group will be responsible for evaluating the degree to which all HL7 V2 standards meet these criteria.
Need
In 2017, the HL7 Standards Governance Board (SGB) established the following precept for HL7 Product Quality:
For each family, methodology determines what the quality criteria are, and the management groups establish a plan to ensure the criteria are applied.
As part of the establishment of the V2 Product Family the InM Work Group was identified as the V2 methodology group and assigned the task of developing the set of quality criteria for V2 related products to be implemented by the V2 Management Group.
Note to Balloters
The HL7 V2 standard is currently divided into a number of "chapters". Each chapter defines content for a specific healthcare domain.
When commenting on the Criteria, please be as specific as possible. For instance:
- Provide suggested wording if you want to see proposed criteria revised
- Provide the text for any proposed new criteria you believe are missing
- Please provide a clear rationale for why you are requesting a particular change
Explanation of Quality Criteria
The quality criteria are broken into related sets of criteria applying to particular portions of a HL7 V2 standard. This includes criteria concerning the title page and front matter, messages/segment groups/segments, value sets and terminology and examples. There are two types of quality criteria identified:
- Criterion - These are quality criteria with which all HL7 V2 standards SHALL (or SHALL NOT) conform.
- Best Practice - These are quality criteria with which all HL7 V2 standards SHOULD (or SHOULD NOT) conform.
V2 Standard Quality Criteria
Document Metadata
Criterion – The chapter SHALL have a defined purpose.
- Criterion - The chapter SHALL have a list of message types defined in the chapter.
- Criterion –The chapter SHALL have a list of trigger events defined in the chapter.
- Criterion –The chapter SHALL have a list of message segments defined in the chapter.
- Criterion - The chapter SHALL NOT duplicate message segment definitions for segments defined in other chapters.
- Criterion – The chapter SHALL be published according to the HL7 V2 Style guide in effect at the time of publishing.
- Criterion – Chapter Chairs and Editor(s) SHALL be listed
- Criterion - The chapter SHALL list the Sponsoring work group(s).
- Best Practice – The chapter SHOULD have examples.
- Best Practice - The chapter SHOULD describe implementation considerations including issues that must be addressed in planning an implementation.
- Best Practice - The chapter SHOULD describe any outstanding issues.
Context and Use Cases
- Criterion - The purpose and audience of each use case in the chapter SHALL be described.
- Criterion - The scope (both in and out of scope) of each use case in the chapter SHALL be clearly defined.
Technical Requirements – General
- Criterion –A V2 specification SHALL follow the rules defined in the most current version of the conformance methodology specification <<link here once standalone Conformance document is available>> .
- Criterion –A V2 specification SHALL NOT make or imply assumptions about
- The ownership of data.
- Subsequent actions of recipients
- Design or architecture of application systems
Technical Requirements – Trigger events
Definition: A trigger event is a real-world event that creates the need for data to flow. A trigger event code is an identifier
- Criterion – Trigger events SHALL be unique across the HL7 V2 standards. e.g. A03, R01
- Criterion - A trigger event code SHALL NOT be associated with more than one message type.
Technical Requirements – Messages
- Criterion – Each Message SHALL be defined using the abstract syntax defined in Chapter 2: section "Message representation."
- Criterion – Each message SHALL have a message type that defines its purpose. E.G. ADT, ORU
- Criterion – Each message structure SHALL have a unique identifier which is named by the message type, underscore, trigger event. E.G. ADT_A03, ORU_R01.
- Criterion - Each message structure SHALL NOT be required to be unique across multiple trigger events within a message type.
- Criterion - Each messages structure SHALL be restricted for use withing the defined message type. E.G. Structure ORU_R01 CAN NOT be used in a message of type ADT.
- Criterion - Each message structure definition SHALL include a narrative description describing the role of the message.
- Criterion - While there is no mandate for segment groups, when one or more segment groups are defined each segment group SHALL have a unique name within the message structure with uppercase letters, numbers or underscores following the XML specification for element names which SHALL NOT change over time.
- Criterion -The first segment of a segment group defined after Version 2.5 SHALL be required.
Technical Requirements – Segments
- Criterion – Each segment SHALL be defined in accordance with the HL7 V2 Style guide in effect at the time of publishing.
- Criterion – Each segment SHALL have a unique ID code which SHALL NOT begin with the letter Z.
- Criterion - Each new segment SHALL require an action code and unique identifier (See Control chapter, "Protocol for interpreting repeating segments or segment groups in an update Message" )
- Criterion - New segments, or changes in the usage of existing segments, SHALL be harmonized across all possible use of the segment(s), and variances documented and approved by the methodology group - Infrastructure and Messaging.
Technical Requirements – Fields
- Criterion – Field definitions SHALL comply with the HL7 V2 Style guide in effect at the time of publishing.
- Criterion – Field definitions SHALL be sufficiently explained for an implementer or analyst who is not a SME to understand the usage.
- Best Practice - For Versions 2.3 and higher: the optionality of fields SHOULD be explicitly documented in the segment field definitions that follow each segment definition table;including explicit documentation of optionality based on trigger event.
- Criterion – Field definitions for composite fields SHALL NOT have a length
- Criterion – Field definitions SHALL use data types defined in the standard.
Technical Requirements – Data types
- Criterion – Data types SHALL be defined in the Data Types section.
- Criterion - Data types SHALL not be redefined based on use case.
- Criterion –Data types SHALL NOT be extended with additional components in field definitions.
- If a new data type component is needed, it SHALL be added to the base standard through the HL7 V2 proposal process.
- Criterion - Standard text describing the use and construction of value sets SHALL be included.
- Criterion - Vocabulary SHALL be created or extended according to the rules in Chapter 2.c "Code Tables".
Technical Requirements – Examples
- Criterion - Each use case SHALL contain at least one full example message for each trigger event.
- Best Practice - "message snippets" SHOULD NOT be used unless the example can be unambiguously located within the message structure and can be interpreted without knowledge of content in other parts of the message (eg. a snippet of the Visit segment group is appropriate when the message structure contains only a single Visit segment group)
- Best Practice - Segments that are not relevant for the point being made MAY be abbreviated in the context of a full message
- Criterion - Example messages SHALL be prefaced with standardized text indicating that they should not be used for the purposes of coding and are only for the purposes of better understanding the requirements