NIST Healthcare Data Interoperability & Productivity Platform

An end-to-end Methodology & Tool Suite supporting Interoperable Healthcare Data Exchange

NIST Healthcare Data Interoperability Productivity Platform (PDF version)

Ensuring interoperable healthcare data exchange is a critical challenge. NIST's Healthcare Data Interoperability Productivity Platform offers a novel solution: an end-to-end methodology and tool suite supporting seamless healthcare data exchange. This platform empowers users to define and specify healthcare data exchange specifications and generate machine-readable artifacts for test plans. A testing infrastructure and framework then leverages these artifacts to automatically create conformance testing tools. This streamlined approach facilitates the development of specifications (implementation guides), test plan creation, and testing tool generation within the HL7 v2 [1] technology space.

This platform achieves its goals through three key components:

• A tool for creating implementation guides and conformance profiles, enabling standardized data exchange specifications.
• A tool for creating test plans, test cases, and associated test data, ensuring comprehensive testing coverage.
• A testing infrastructure and test framework to build testing tools, automating the testing process.

A key innovation of this platform is the "reversed" approach to development. Instead of creating requirements in natural language and then interpreting them for test plans, the requirements are captured directly as computable artifacts. This ensures greater accuracy, reduces ambiguity, and accelerates the development process. This platform ultimately improves patient care, reduces costs, and streamlines processes by facilitating seamless data exchange.

Platform Overview

Figure 1 provides a high-level overview of the methodology. Domain experts develop use cases, determine the corresponding message events, and then define the requirements. Using the methodology, they enter this information into the Implementation Guide Authoring and Management Tool (IGAMT). During this process, domain experts constrain the message events—limiting their scope to only the data required by the specific use case—according to the requirements. IGAMT generates artifacts in Word, HTML, and XML formats. The complete implementation guide, including the narrative and messaging requirements, can be created and exported in Word or HTML. These formats are suitable for ballot submission to standards development organizations like HL7 or IHE (Integrating the Healthcare Enterprises [6]). Each conformance (message) profile can be exported as XML. These XML conformance profiles have several important uses. They provide a machine-computable definition of the message interface, enable message validation, facilitate test case and message generation, and even support source code generation.  

The XML conformance profiles can be imported into the Test Case Authoring and Management Tool (TCAMT). TCAMT is used to create targeted test cases for interactions (profiles) defined in the implementation guide. The output is an additional set of constraints in an XML format.

Credit: Robert Snelick

Fig. 1. NIST HL7 v2 Standards Development and Testing Platform Overview

The NIST platform includes a testing infrastructure, comprised of common utilities used for testing (such as a message validation engine), and a testing framework that provides various testing tool components (such as a communication framework and a profile viewer). Testing tool instances are then created using both the testing infrastructure and framework components, as well as the resource bundle output generated from IGAMT and TCAMT.

The NIST platform empowers end-users to create conformance testing tools efficiently. This streamlined approach can significantly mitigate the challenges currently associated with conformance test tools. These challenges include frequent unavailability, high development costs, difficulties with timely updates, lack of adaptability for local refinements, and lengthy time to market. Furthermore, the platform adds value by enforcing consistent and rigorous rules for requirements specifications.

Background

HL7 (Health Level 7) Version 2 (v2) is the predominant standard for exchanging healthcare administrative and clinical data. Healthcare information systems use the HL7 v2 protocol to develop standardized interfaces for connecting to and exchanging data with other systems. HL7 v2 encompasses a broad spectrum of domains, including Patient Administration, Laboratory Orders and Results, and Public Health Reporting. The base HL7 v2 standard [1] is a framework containing numerous message events. For each event, it provides an initial template (starting point) intended to be constrained for a specific use case. Applying constraints to a message event is known as profiling [2,3]. For example, the VXU V04 (Unsolicited Vaccination Record Update) message event is a generic template for communicating information about a patient’s immunization-related events. The base message template consists mostly of optional data elements. For a given use case, such as "Send Unsolicited Immunization Update for the US Realm" [4], the message template is "profiled." Elements can be designated as required, content can be bound to a set of pre-coordinated codes, and so on. The base message event (e.g., VXU V04) constrained for a particular use (e.g., submitting immunization events) is called a conformance profile [1]. An implementation guide is a collection of conformance profiles organized for a workflow (e.g., submitting, acknowledging, querying, and responding to/for immunization events). In this example, four conformance profiles exist, each with different message events: one for submitting an immunization event, one for sending an acknowledgment, one for querying an immunization history, and one for providing an immunization history. To date, HL7 v2 implementation guides have been created using word processing programs, resulting in ambiguous and inconsistent specification of requirements. This practice has hindered consistent interpretation among implementers, creating an unnecessary barrier to interoperability.

Supporting Automated Validation

IGAMT incorporates an internal model of all HL7 v2 messages for each version of the standard (Figure 2). While HL7 v2 publishes the standard in human-readable text documents, message definitions and accompanying structures are codified into a database available from HL7. IGAMT reads this database and converts the message definitions into its own message model. This model serves as the foundation for all IGAMT functions and features. IGAMT presents the model through a graphical user interface (GUI), enabling users to constrain messages as needed. The user interface provides panels for Messages, Segments, Data Types, Value Sets, Profile Components, Condition Predicates, and Conformance Statements. IGAMT exports the constrained message definition (a profile) as an XML profile instance, ensuring that this instance adheres to the rules of the Profile Schema. Validation is performed by comparing a message instance against the constraints defined in the XML profile. The validation engine interprets the requirements documented in the XML profile and makes corresponding assertions against the message instance, generating a Validation Report. This validation process forms the basis of the conformance test tools.

Credit: Robert Snelick

Fig. 2. IGAMT Message Model and Validation Process

Testing Infrastructure and Framework

NIST has developed an HL7 v2.x testing infrastructure and framework to facilitate the creation of conformance testing tools. The testing infrastructure provides a set of services used by the test tool framework to build specific instances of tools. A test tool can be tailored for a specific need or designed as a general-purpose tool capable of handling multiple implementation guides and profiles. The latter is often implemented as a web application where users can upload implementation guides, conformance profiles, and test plans to generate a test tool. This test tool is created dynamically and can be generated as a byproduct, effectively "free," once the XML profile and associated artifacts have been created (in IGAMT and TCAMT). This process empowers domain experts to create their own test tools. Alternatively, the framework can be leveraged, customized, and installed locally. Using the framework, developers can create customized, specific, or general-purpose web application conformance test tools, and they can access the validation via web services or incorporate validation via a JAR (Java Archive) file or source code. Regardless of the approach, the platform can significantly improve the quality of implementation guides, assist in the creation and maintenance of test plans, expedite the deployment of a validation tool, and, overall, reduce the cost and time of the entire process.

Credit: Robert Snelick

Figure 3: NIST HL7 v2 Standards Development and Testing Platform Architecture

Figure 3 provides a more detailed view of the end-to-end methodology and platform. A key design principle is the reliance on a single source of truth for creating implementation guides and test plans. Modifications are made in one central location and then propagated to associated services, utilities, and tools. IGAMT is a tool used by domain expert authors to define requirements for interface specifications. It exports both human-readable (1) and machine-computable (2) artifacts. A context-free conformance test tool is automatically generated when the IGAMT XML profiles are loaded into the general-purpose validation tool (3). At this level, validation focuses on the technical requirements defined in the profile. No context is associated when validating the message instance against these requirements. This type of validation is known as context-free testing.

Point (4) illustrates the XML profile being input into TCAMT. Test scenarios provide context, essentially a real-world story with associated data. This context generates additional constraints. The profile and context constraints are then loaded into the general-purpose validation tool to automatically create a context-based validation tool (5). Point (6) indicates a human-readable export of the Test Plan.

Point (7) shows that the testing infrastructure and framework components form the basis for the general-purpose validation tool. This tool takes the resource bundle (XML Profile, TCAMT constraint file, etc.) as input to automatically generate a conformance test tool. Points (8) and (9) illustrate the process by which developers can leverage the testing infrastructure and framework to create customized conformance test tools. Point (10) indicates that validation can be accessed through other methods, allowing users to integrate it into their local environments. The platform provides access to tool validation via REST and web services. Additionally, the validation JAR and source code are available. Point (11) indicates that additional constraints can be included, extending beyond typical interface requirements. These can include data quality such as ensuring that a reported vaccine dose is consistent in terms of manufacturer, lot number, and date given.

Addressing Data Quality and Functional Requirements Testing

The intent of HL7 v2 is specifically scoped to defined requirements for exchanging data between applications. The specifications typically do not impose requirements on how the data is processed. Other specifications, in conjunction with the interface specification, may specify such requirements (e.g., IHE integration profiles and functional requirements specifications). In real-world settings, exchange partners need to account for more than just conformance to the exchange requirements. Data quality, business rules, and functional requirements are necessary to satisfy the desired outcome of the use case scenario. Data quality and functional requirements, such as linking patient records, are critical for coherent, clean, and structured data in healthcare information systems. Mechanisms to define such requirements, and testing support that can verify that the complete workflow is implemented as intended, are beneficial.

The generic constraint generation utility in IGAMT can create data quality constraints. Certain business rules can be applied to a message to determine if it meets the requirements necessary for incorporation by the receiver. A simple data quality rule for reporting an immunization record is that the date of administration must be after the date of birth. This constraint is likely never given in an HL7 v2 interface specification; however, data quality rules such as these are important at the local level. Users can create these rules in IGAMT to provide additional validation (point (11) in Figure 3).

TCAMT can create test cases to test functional requirements. For example, a scenario can be crafted in which three different immunization records for the same patient are created from different providers and sent to an immunization information system (IIS). A subsequent query to the IIS to return a complete immunization history can be performed. The response message can be examined to see if the consolidated record contains the expected combined immunization history. TCAMT provides the capability to create such a scenario and the additional content validation constraints. Testing for invalid (or negative) test case scenarios can also be created. The platform provides the capabilities for the tester to create unlimited test scenarios using convenient and powerful tooling.

References

1. Health Level 7 (HL7) Standard Version 2.7, ANSI/HL7, January, 2011, http://www.hl7.org.

2. Healthcare Interoperability Standards Compliance Handbook. F. Oemig, R. Snelick. Springer International Publishing Switzerland, ISBN 978-3-319-44837-4, December 2016. 

3. Principles for Profiling Healthcare Data Communication Standards. R. Snelick, F. Oemig. 2013 Software Engineering Research and Practice (SERP13), WORLDCOMP’13 July 22-25, 2013, Las Vegas, NV.

4. HL7 Version 2.5.1 Implementation Guide for Immunization Messaging; Release 1.5, October 1, 2014. http://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf

5. NIST Resources and Tools in Support of HL7 v2 Standards. http://hl7v2tools.nist.gov/

6. Integrating the Healthcare Enterprise (IHE). http://www.ihe.net