The Future of HL7 Version 2 Product Family

Refactoring HL7 Version 2 Product Family

HL7 Version 2+ Release 2015
V2+ R2015

Status / Draft
Author / Frank Oemig
Version / 04
Date / June19th, 2015

Contents

1Introduction

1.1Problem Set

2Proposal

3Solution

3.1Classification

4Proposed New Structure

4.1Chapter Layout

5Additional Changes

5.1Attribute (Segment) Tables

5.2Message Structure Representation

5.3Vocabulary Model

6Update Process

1Introduction

The 1st normative ballot for HL7 v2.8.2 took place Nov./Dec. 2014. The proposal database for v2.9 is closed. So the question must be raised what will come after v2.9? Will it be v2.10?

1.1Problems

In different committees (Vocabulary, CGIT, InM, Publishing) we have discussed some requests which target an improvement of v2.x:

Chapters are mixed from its contents, but with v2.x there is no chance to assign new numbers.
Additional specifications, e.g. v2.xml and HTTP, are available at different locations.
Enhanced vocabulary management and maintenance
Improved conformance methodology
Separating the chapters into smaller chunks for an easier editing
Some chapter numbers (e.g. “4A”) are problematic in their handling
Up to date Message examples

2Proposal

Harmonize the current set and align with future needs without loosing compatibility with the v2 family:

Refactoring HL7 Version 2 Product Family

In other words, even if we enhance the way the standard is written, message compatibility is given:

3Solution

The current chapters are split into different categories, resulting in new chapter numbers. The primary purpose is to decouple different aspects for a faster editorial process, also allowing for separate publication cycles.

3.1Classification

This table should help to understand the different groups of contents. The proposed new chapter are oriented towards the old number to have at least some similarities:

Group / Explanation / Content / Chapter Numbers
A / - / Table of Contents, Introduction, Glossary / 1, 2, 3
B / V2 Basics / Control, foundational segments (MSH, etc.) / 4-9
C / V2 Encoding / Encoding: ER7, XML, (JSON ?) / 10-19
D / V2 Conformance / 2B / 20, 21
E / V2 Vocabulary / 2C / 22
F / Transport / FTP, NFS, MLLP, HTTP / 23-29
G / V2 Data Types / 2A / 30, 31
H / V2 (Domain) Content / 3, 4, 4A, … / 40-70
I / - / Appendices: eBNF, Segments, Index / 97-99

4Proposed New Structure

Old Chapter / Content / Group / New Chapter / Content / Comment / Gene-rated
A / 1 / ToC
1 / Introduction / A / 2 / Introduction
2 / Control / B / 4 / Control, ..
C / 10 / Encoding: ER7
V2.xml / C / 11 / Encoding: XML
- / - / C / 12 / Encoding: JSON
2.14 / E / 5 / Basic segments: MSH, ..
2A / Datatypes / G / 23 / Datatypes (Details)
- / G / 24 / Datatype Cheatsheet (Quick Reference for Developers), 1 page only / X
2B / Conformance / D / 20 / Conformance
D / 21 / Schema
2C / Tables / E / 22 / Vocabulary / X
3 / Pat. Admin. / H / 30 / Patient Administration
4 / Orders / H / 40 / Orders / Split?
4A / Pharmacy / H / 41 / Pharmacy
4A.7-9 / H / 42 / Vaccination
5 / Query / B / 50 / Query Basics
H / 51 / Query Definitions
6 / Financial Mngmt. / H / 60 / Financial Management
7 / Observations / H / 70 / Observations
7.7-7.9 / H / 71 / Clinical Trials
7.10-7.13 / H / 72 / Product Experience
7.14-7.17 / H / 73 / Waveform
7.18 / H / 75 / Specimen
7.19 / 79 / Special Tables / Where to place?
8 / Master Files / B / 52 / Master Files
9 / Med. Records / H / 34 / Medical Records
10 / Scheduling / H / 32 / Scheduling
11 / Pat. Referral / H / 33 / Patient Referral
12 / Pat. Care / H / 34 / Patient Care
13 / Clin. Lab. Autom. / H / 74 / Clin. Lab. Automation
14 / App. Mngmt. / H / 53 / App. Management
15 / Pers. Mngmt. / H / 31 / Personnel Management
16 / eClaims / H / 61 / eClaims
17 / Mat. Mngmt. / H / 62 / Material Management
A / Tables, Segments, Fields, … / H / 98 / Appendix: Segments, Fields / X
B / LLP / F / 25 / MLLP
- / HTTP / F / 26 / HTTP
C / eBNF/BNF grammar / C / 97 / Appendix: eBNF/BNF / X
D / Glossary / A / 3 / Glossary
E / Index / I / 99 / Appendix: Index / X

4.1Chapter Layout

The chapters should get a new layout:

Introduction
Message Structures
Events
Segments

5Additional Changes

The refactoring can be used to get rid of other problems as well:

The message structures are repeated. This is especially true for ADT. This introduces a lot of editorial workload with different message structure definitions.
The datatypes are repeated with each field definition. This should replaced by a one page printout which can be used as a quick reference guide.
Columns of the attribute tables should be enhanced

5.1Attribute (Segment) Tables

Several years ago, the way attribute tables are presented have been discussed because they lead to long-lasting discussions:

“Repetition” vs. “cardinality”
“Required but may be empty” vs. “optional “

This leads to pulling out the old discussion again:

Old representation:

SEQ / LEN / C.LEN / DT / OPT / RP/# / TBL# / ITEM# / ELEMENT NAME
1 / 1..4 / SI / R / 01612 / Set ID - IAM

New representation:

SEQ / LEN / C.LEN / DT / Must Support / Card. / Cond. / TBL# / ITEM# / ELEMENT NAME
1 / 1..4 / SI / Y / 01612 / Set ID - IAM

1.1.1Value Set for “Must Support”

Value / Description / V2.x compliance / Specialization in profiles
Y / Must support this element, i.e. a development must handle this element / “R”, “RE” / Y
N / Element is forbidden / “W”, “B”, “W” / N
O / Optional / “O” / O, Y, N

1.1.2Value Set for “Cardinality”

Value / Description / V2.x compliance / RP/#
0..0 / Forbidden / “W”, “B”
0..1 / Optional / “RE”, “O”
0..n / Optional, repeating n-times / “RE”, “O” / “Y”/n
0..* / Optional, repeating / “O” / “Y”
1..1 / Required / “R”
1..n / Required, repeating n-times / “R” / “Y”/n
1..* / Required, repeating / “R” / “Y”
n..m / Does not occur yet

1.1.3Representation of Conditions

As a first approach, the conditions from the previous version should be cited. Afterwards they can be adapted to OCL or another reasonable language.

5.2Message Structure Representation

The message structure can also be enhanced a little bit by introducing a “must support” column. This helps to introduce this notion for better implementations. This way one can express that an application must be capable to support a specific segment, e.g. the ERR segment in the following example.

The same way the introduction of group names (with opening and closing brackets) in the left most column would allow for introducing a cardinality column thus reflecting the message structure in the same way as attribute tables, but the benefit is not that overwhelming.

Old representation:

ACK^A01^ACK: General Acknowledgment

Segments / Description / Status / Chapter
MSH / Message Header / 2
[{ SFT }] / Software Segment / 2
[ UAC ] / User Authentication Credential / 2
MSA / Message Acknowledgment / 2
[{ ERR }] / Error / 2

New representation:

ACK^A01^ACK: General Acknowledgment

Segments / Description / Must Support / Status / Chapter
MSH / Message Header / Y / 2
[{ SFT }] / Software Segment / 2
[ UAC ] / User Authentication Credential / 2
MSA / Message Acknowledgment / Y / 2
[{ ERR }] / Error / Y / 2

5.3Vocabulary Model

With the update to version 2.9 the (old) chapter 2C is generated from a database. No further manual maintenance of this document is necessary. The representation can thus be enhanced per discussion to closer relate it to HL7 V3 and FHIR.

6Update Process

Quite a lot of the work can be supported by scripts. However, manual processing is necessary:

# / Procedural Step / Comment / Estimation / resposnsible
1 / Copying and splitting the chapters according to the new structure / 0,5 da / Frank
2 / Assigning new chapter numbers / 0,5 day / Frank
3 / Updating Headlines, footers and document metadata / 0,5 day / Frank
4 / Restructuring the Documents internally according to new guidance / 2 days / Frank + WG
5 / Updating the sections according to new layout / requires new input or WG internal discussions… / ? / WG
6 / Reformatting the attribute tables / by macro / 1 day / Frank
7 / Reformatting the segment tables / by macro / 1 day / Frank
8 / Introducing the new message pair tables / This should have been done already / WG
9 / Generating new TOC and Appendix / 0,5 day / Frank