Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.



See Approve V2 Health Level Seven (HL7) 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:

inm@lists.hl7.org

Table of Contents
outlinetrue

 

Overview

This document contains a proposed starting set of Health Level Seven (HL7) Version 2 (V2) Standard Quality Criteria. This draft for comment ballot is intended to gather comments on this starter set of 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" based on the current Microsoft Word based publishing format.  When future versions are published in a different format, the criteria will be altered to match the new format.

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

  1. Criterion – The chapter SHALL have a defined purpose.
  2. Criterion – The chapter SHALL have a list of trigger events.
  3. Criterion – The chapter SHALL have a list of messages segments defined in the chapter.
  4. Criterion – The chapter SHOULD have examples.
  5. Best Practice - The chapter SHOULD describe implementation considerations including issues that must be addressed in planning an implementation.
  6. Best Practice - The chapter SHOULD describe any outstanding issues.
  7. Criterion – The chapter SHALL be published according to the HL7 V2 Style guide in effect at the time of publishing.
  8. Criterion – Chapter Chairs and Editor(s) SHALL be listed
  9. Criterion - Sponsoring work group(s) SHALL be listed

Context and Use Cases

  1. Criterion - The purpose and audience of the document SHALL be described.
  2. Criterion - The scope (both in and out of scope) of the document SHALL be clearly defined.

Technical Requirements – General

  1. Criterion –A V2 specification SHALL follow the rules defined in the conformance methodology .
  2. Criterion –A V2 specification SHALL NOT make or imply assumptions about
    1. The ownership of data.
    2. Subsequent actions of recipients
    3. Design or architecture of application systems

Technical Requirements – Trigger events

  1. Criterion – Trigger events SHALL be unique across the HL7 V2 standards.

Technical Requirements – Messages

  1. Criterion – Each Message SHALL be defined using the abstract syntax in the Control Section
  2. Criterion – Each message SHALL have a message type that defines its purpose.
  3. Criterion –Each message type SHALL be based on a message structure.
  4. Criterion – Each message structure SHALL have a unique identifier.
  5. Criterion- Each message structure definition SHALL include a narrative description describing the role of the message.
  6. Criterion- Each messages structure MAY contain one or more segment groups
  7. Criterion- 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.
  8. Criterion- The first segment of a segment group defined after Version 2.5 SHALL be required.

Technical Requirements – Segments

  1. Criterion – Each segment SHALL be defined in accordance with the HL7 V2 Style guide in effect at the time of publishing.
  2. Criterion – Each segment SHALL have a unique ID code which SHALL NOT begin with the letter Z.
  3. 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" )
  4. Criterion - New segments, or change in usage of existing segments, SHALL be harmonized across all possible use of the segment(s), and variances documented and approved.

Technical Requirements – Fields

  1. Criterion – Field definitions SHALL comply with the HL7 V2 Style guide in effect at the time of publishing.
  2. Criterion – Field definitions SHALL be sufficiently explained for an implementer or analyst who is not a SME to understand the usage.
  3. 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; if the optionality of fields within a segment changes depending on the trigger event, that optionality SHOULD also be explicitly documented.
  4. Criterion – Field definitions for composite fields SHALL NOT have a length
  5. Criterion –Field definitions SHALL use data types defined in the standard.

Technical Requirements – Data types

  1. Criterion – Data types SHALL be defined in the appropriate section.
  2. Criterion –Data types SHALL NOT be extended with additional components.
    1. If a new data type component is needed, it should be added to the base standard through the HL7 V2 process

Technical Requirements – Value sets

  1. Criterion - Standard text describing the use and construction of value sets SHALL be included.

Technical Requirements – Examples

  1. Criterion - Each use case SHALL contain at least one full example message for each profile
  2. 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)
  3. Best Practice - Segments that are not relevant for the point being made MAY be abbreviated in the context of a full message
  4. 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