# Presentation: 695434

## HL7 Conformance Testing with Message Maker

- Robert Snelick
- National Institute of Standards & Technology (NIST)

**rsnelick@nist.gov**
**http://www.nist.gov/messagemaker**

## Overview

- HL7 Version 2 Overview
- Purpose, Definition, and Problems
- Conformance using Message Profiles
- Methodology for producing a precise and unambiguous specification
- Building Message Profiles
- MWB Tool to build XML representation of a message profile
- Testing HL7 Systems (NIST)
- Message Maker tool to build message instances to test HL7 systems for conformance

**Notes:**
The focus is version 2.

## The Big Picture

**HL7**
**Standard**

- MSH|^~\&|REGAEVN|A05|199901PID|1||191919^NK1|1|MASSIE^ENK1|2|MASSIE^I...

**HL7 System**

- <?xml version="1.0"?>
- <HL7v2xConformanceProfile H
- <MetaData Name="CALINX" Or
- <Encodings>
- <Encoding>ER7</Encoding>
- </Encodings>
- <DynamicDef AccAck="NE" Ap
- <HL7MsgType=“ADT"
- EventType=“A01
- <MetaData Name="CALINX" >
- <Segment Name="MSH" LongN
- <Field Name="Field Separator" Us
- </Field>
- <Field Name="Encoding Characters"
- <Reference>2.16.9.2</Reference
- </Field>
- <Field Name="Sending Application"

**Universal design**
**Riddled with optionality**
**Implementation chaos**
**Interoperability difficult**

**Agreement**
**Define constraints**

**Tools to build profiles**
**e.g., MWB (VA)**
**XML representation**

**Messaging**
**Workbench**

**Message**
**Maker**

**Tools to build messages**
**Message Maker (NIST)**
**Automated and adaptable**

**Profile based**
**Suite of test messages**
**Suitable for conformance testing**

**Conformance testing needed**
**Improves reliability and interoperability**
**Testing Framework**

**Test**
**Harness**

**Conforms?**

**Test**
**System**

## What is HL7

- Standards for the exchange, management, and integration of data for clinical care
- HL7 Version 2 is an application level messaging standard
- Deployed in 90% of US hospitals, international use growing
- Messages, for example
- ADT
- Lab order
- Lab results
- “A framework for negotiation”

## HL7 and Healthcare Integration

- HIS

- Billing

- LAB

- L1

- L2

- L3

- L4

- Rx

- Diet

- Cardiology

- RIS

- Scheduling

- Nursing

**HL7**

**HL7**

**HL7**

- R3

- R2

- R1

- Hospital
- Firewall

**DICOM**

**ASTM**

**NCPDP**

**X12**

## HL7 Message Structure

*HL7 Message*

- Segments

- Fields

- Components

- Sub-Components

- Groups

- Groups

- Segments

-  Hierarchical data storage

## Message Definition

| 

ADT^A04^ADT_A01 |
| --- |
| 
MSH |
| EVN |
| PID |
| [  PD1  ] |
| [{ ROL }] |
| [{ NK1 }] |
|    PV1  |
| [  PV2  ]
.
.
. |
| [{ GT1 } ] |
| [{ |
|     IN1 |
|   [  IN2 ] |
|   [{ IN3 }]  |
|   [{ ROL }] |
| }]  |
| [  ACC  ] |
| [  UB1  ] |
| [  UB2  ] |
| [  PDA  ] |

- Group

- Segment

-  Message maps to a real world event (admit a patient)
-  Hundreds of segments and events
-  Segments are defined once
-  Each message selects from a library of segments
-  Think of them as data structures (or classes)

- {} Segment can repeat
- [] Segment is optional

## PID: Patient Identification Segment

| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 4 | SI | O |  |  | 00104 | Set ID - PID |
| 2 | 20 | CX | B |  |  | 00105 | Patient ID |
| 3 | 250 | CX | R | Y |  | 00106 | Patient Identifier List |
| 4 | 20 | CX | B | Y |  | 00107 | Alternate Patient ID - PID |
| 5 | 250 | XPN | R | Y |  | 00108 | Patient Name |
| 6 | 250 | XPN | O | Y |  | 00109 | Mother’s Maiden Name |
| 7 | 26 | TS | O |  |  | 00110 | Date/Time of Birth |
| 8 | 1 | IS | O |  | 0001 | 00111 | Administrative Sex |
| 9 | 250 | XPN | B | Y |  | 00112 | Patient Alias |
| 10 | 250 | CE | O | Y | 0005 | 00113 | Race |
| 11 | 250 | XAD | O | Y |  | 00114 | Patient Address |
| 12 | 4 | IS | B |  | 0289 | 00115 | County Code |
| 13 | 250 | XTN | O | Y |  | 00116 | Phone Number - Home |
| 14 | 250 | XTN | O | Y |  | 00117 | Phone Number - Business |
| ... |  |  |  |  |  |  |  |
| 37 | 80 | ST | O |  |  | 01541 | Strain |
| 38 | 250 | CE | O | 2 | 0429 | 01542 | Production Class Code |

-  Segments contain fields

## Extended Person Name (XPN)

-  **Components: **<family name (FN)> ^ <given name (ST)> ^
- <second and further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^
- <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^** **<name type code (ID) > ^
- <name representation code (ID)> ^ <name context (CE)> ^
- <name validity range (DR)> ^ <name assembly order (ID)>
**Subcomponents of family name:**  <surname (ST)> ^ <own surname prefix (ST)> ^
- <own surname (ST)> ^ <surname prefix from partner/spouse (ST)> ^
- <surname from partner/spouse (ST)>
**Subcomponents of name context:** <identifier (ST)> & <text (ST)> &
- <name of coding system (IS)> &
- <alternate identifier (ST)> & <alternate text (ST)> &
- <name of alternate coding system (IS)>
**Subcomponents of name validity range:**  <date range start date/time (TS)> &
- <date range end date/time (TS)>

## Elements have Attributes

- Usage
- Indicates how the element can be used
- Required, Optional, Not Supported, Conditional, Required or Empty, etc.
- Cardinality
- Indicates how many time the element can appear
- [0..0], [0..1], [1..1], [0..3], [3..5], [0..*]
- Code Sets (Tables)
- Indicates a set of valid values for a given primitive element
- HL7 Table 001 Administrative Sex
- Length
- Indicates the maximum of an element or a compound element

## HL7 Message Framework

- HL7 provides the framework to build messages
- Groups and Messages are defined each time used
- Building Blocks
- Segments, Fields, Components, Sub-Components, Data types, Tables (code sets) are defined once
- Universal Design: Needed for broad support
- Flexible framework for building messages for any given real world use case (e.g., request a blood test)

## The Problem

- Overwhelmingly large with many optional features
- Little agreement on how to define an interface
- Applications didn’t know what to expect
- No two interfaces were alike
- Described as “total chaos” during implementation
- Local Extensions (e.g., Z-segments) complicate matters further
- Interoperability Issues – not plug-and-play
- Two systems could be HL7 compliant but not interoperable
- e.g., sending system could support 10 repetitions of a segment while the receiving systems may only support 5.

## The Solution

- Conformance SIG
- Trading Partner Agreement
- Eliminate optionality (“implementation Specification”)
- Add specificity to existing messages and identify specific scenarios/use cases
- Identify, document, and bridge semantic differences
- Conformance through Message Profiles

## Message Profile Defined

- Refinement of the HL7 Standard
- Provides an unambiguous specification of a standard HL7 message
- Measurable
- What data will be passed in the message
- The format in which the data will be passed
- The acknowledgement responsibilities of the sender and the receiver
- Message instances can be validated against a message profile
- Parts of a Message Profile
- Use case model
- Static Definition
- Dynamic Definition
- Represented as an XML document (HL7 XML)

## Static Definition

**Notes:**
Note that the usage constraints are much tighter in the conformance specification. They are limited to (R, RE, X, C, CE). Cardinality also needs to be explicitly stated.

## Tools for Building Profiles

- Commercial: Orion’s Symphonia, others
- Free: VA’s Messaging Workbench (MWB)

## Message Profile Example (XML)

**<Field Name="SSN Number - Patient" ****Usage="X"**** Min="0" Max="*" Datatype="ST" Length="16" ItemNo="00122">**
**	****<Reference>3.4.2.19</Reference>**
**</Field>**
**<Field Name="Driver's License Number - Patient" ****Usage="R" Min="1" Max="1"**** Datatype="DLN" Length="250" ItemNo="00123">**
**	****<Reference>3.4.2.20</Reference>**
**	****<Component Name="Driver's License Number" Usage="R" Datatype="ST" Length="100">**
**	****</Component>**
**	****<Component Name="Issuing State, province, country" Usage="R" Datatype="IS" Length="10" ****Table="0333">**
**	****</Component>**
**	****<Component Name="expiration date" Usage="R" ****Datatype="DT"**** Length="30">**
**	****</Component>**
**</Field>**
**<Field Name="Mother's Identifier" Usage=“X" Min="0" Max="*" Datatype="CX" Length="250" ItemNo="00124">**
**	****<Reference>3.4.2.21</Reference>**
**	****<Component Name="ID" Usage="X" Datatype="ST" Length="3">**
**	****</Component>**
**	****<Component Name="Check digit" Usage="X" Datatype="ST">**
**	****</Component>**
**	****<Component Name="code identifying the check digit scheme employed" Usage="X" Datatype="ID" Length="3" Table="0061">**
**	****</Component>**

- _Snippet from PID segment_

-  * Provides a roadmap for creating messages *
-  * Input into Message Maker *

- Value needs to be in table 0333

- SSN not supported

- License is required and must appear exactly one time

- Value must be a valid date

## Conformance Testing

- A way to verify implementations of a specification to determine whether or not deviations from the specifications exist (through the use of test suites)
- Standards are not enough to ensure interoperability

- Specification
- (Requirements)

- Conformance Tests

- Implementation

**Notes:**
Tests capture the technical requirements within the specification.
Testing is bound in scope by the specification.
Internal structure of the product-under0test not accessible (black box testing)

Conformance testing is necessary, but not sufficient, for interoperability.
Interoperability: The ability of two or more systems to exchange and use information.
Portability: the ability to move software or applications among different systems.

## Benefits of Conformance Testing

- Increase probability that products are implemented correctly
- Contains required functionality
- Behaves as expected
- Performs functions in a known manner
- Increased likelihood of portability and interoperability
- Portability – the ability to move software or applications among different systems
- Interoperability – the ability of two or more systems to exchange and use information
- Provides a feedback loop for developers
- Increases buyer’s confidence in a product and substantiate seller’s claim
- Not locked into purchasing from a single vendor

## The Need for Dynamic Test Creation

- MSH|^~\&|REGAEVN|A05|199901PID|1||191919^NK1|1|MASSIE^ENK1|2|MASSIE^I...

- MSH|^~\&|REGAEVN|A05|199901PID|1||191919^NK1|1|MASSIE^ENK1|2|MASSIE^I...

- MSH|^~\&|REGAEVN|A05|199901PID|1||191919^NK1|1|MASSIE^ENK1|2|MASSIE^I...

**Notes:**
Need to ensure that applications implement what they agreed to in the Message Profile
Test messages and testing framework are needed
One message profile handles one use case. Health care systems may have hundreds of profiles. Specific tests need to be developed for profile.
Further complicating the problem is that use cases will differ from site-to-site. 
For example, “admit a patient” at hospital A and hospital B will likely have different profiles
Tests need to be developed
Process in tedious and expensive
Often systems go untested and are debugged while in production

## Automated and Adaptable Message Creation 

_**Manual Test Suite**_
** ****tests needed for each profile**
** ****written individually**
** ****meticulous work**
** ****high cost $$$$$**
** ****often tests not performed**

_**Message Maker Test Suite**_
** ****tests needed for each profile**
** ****automatically generated**
** ****easy**
** ****lower cost $$**
** ****increases likelihood tests will be performed**

**Build your own**

**Use Message Maker**

## Message Maker Overview

- Purpose: to automatically and dynamically generate tests for any given profile
- Account for site-specific characteristics and options
- Produce self-adapting test suites
- Development:
- tool to create test messages (Message Maker)
- Reference database of HL7 data items
- framework to send/receive messages, validate, and report
- Capabilities:
- Message Variation
- structure
- constraint attributes
- data content
- validity
- message density
- specific test location and type
- Data Configuration
- Methods to automatically determine test suite
- Multiple encodings (XML, ER7)
- Test Descriptions

## Message Maker Design

- Specification
- Tool (e.g., MWB)

- HL7 V2
- Profile (XML)

**Data Sources**

**NIST HL7**
**Reference**
**Database**

- HL7
- Standard
- DB

- NIST Data
- Repository
- (XML)

- _Testing Options_
-  Usage
-  Cardinality
-  Volume
-  Data Content
-  Length
-  etc.

- Message
- Maker

- Message
- Factory
- (XSLT)

- HL7 Test
- _Messages_
** ****Profile based**
** ****Structurally correct**
** ****Validated**
** ****Varied**
** ****Descriptive**
** ****Suitable basis for **
**conformance testing**

- Testing
- Framework

**Example**
**Values **
**from Profile**

**Default**
**Values**

**Table**
**Values**

## HL7 Test Framework Environment

- HL7 Test
- Messages

- HL7 Implementation
- Under Test (IUT)

- HL7 Test Driver

-  simulates  application
-  controls testing
-  transmits HL7 messages to the IUT

- Remote Tester

-  simulates  application
-  controlled by Test Driver
-  receives and delivers messages with IUT

- HL7 Message