understanding hl7 version 2.5.1 and meaningful use data considerations

Presented By: Rich Murphy, VP, Interface Software July, 2015

HL7: Version 2.5.1 and Meaningful Use data considerations

Topics

•  Brief overview of HL7 v2.5.1

•  Codification Standards and considerations

•  Clinical Document Exchange considerations

•  XML and Clinical Documents

•  Looking forward with FHIR

What is HL7?

HL7 Organization definition: Health Level Seven is one of several American National Standards Institute (ANSI) accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven’s domain is clinical and administrative data. www.hl7.org HL7 develops standards to improve information sharing and provides interoperability to allow information exchange between disparate systems.

HL7 Version 2

•  HL7 version 2 messaging standard was created in 1987

•  The standard has evolved since that time, current version is v2.7

•  95% of US healthcare organizations use HL7 version 2 in some capacity*

•  More than 35 countries have HL7 version 2 implementations in place*

*From HL7.org Primary Standards version 2 product suite brief

HL7 Version 2

•  Version 2.3 approved as ANSI standard in 1997. Most common version in use with healthcare interfacing at this time

•  Version 2.5.1 approved as an ANSI standard in 2007

•  Version 3 approved in 2003 (Reference Information Model Release 1)

•  Version 3 is a complete departure from previous versions and is much more complex

•  Even with version 3, HL7.org envisions version 2 continuing to play a critical role in healthcare interoperability well into the future

Why Use version 2.5.1? •  Required version for Meaningful Use Stage 1

objectives: •  Reportable LABs •  Clinical Document (codified values)

•  Required version for Meaningful Use Stage 2 objectives:

•  Reportable LABs •  Syndromic Surveillance (v2.3 no longer allowed) •  Immunizations (v2.3 no longer allowed) •  Transmit LAB tests/results •  Clinical Document data transfer (codified values)

HL7 Version 2.5.1

Why Use version 2.5.1? •  Required version for Meaningful Use Stage 3

objectives (tentative, still in comment phase): •  Public Health Interfaces (expanded to include bidirectional data transfer for Immunizations)

•  Clinical Documents (codified values) •  LAB Orders Interface (CPOE) •  eDOS (electronic Directory of Services) (LAB test compendium) (CPOE and LAB Results)

HL7 Version 2.5.1

Why Use version 2.5.1? •  In addition to Meaningful use, mandated by many

State agencies as part of grant requirements

•  Growing acceptance in HIE data exchange

•  Interface vendors must conform to receiving system specifications, if these require v2.5.1 these interfaces must be designed to match these requirements for proper communications

•  In order to certify each solution, Interface vendors must confirm to all Meaningful Use requirements, vendors have to be able to send/receive v2.5.1 if they want to operate in the Meaningful Use space

HL7 Version 2.5.1

HL7 Version 2.5.1 Overview

•  Build upon previous versions of HL7 v2 and takes advantage of some of the same core concepts:

•  Messages used as the data transfer mechanism between systems

•  Segments and Fields used to create each message

•  Message Type used to define intent of each message

•  Control Characters/Delimiters/Data Types

•  ACKnowledgments

HL7 Version 2.5.1 Codified Values

Stricter codification standards compared to previous HL7 versions

•  LOINC

•  SNOMED CT

•  UCUM

•  CVX

•  MVX

•  ICD9/ICD10 Procedure Codes

•  ICD9/ICD10 Diagnosis Codes


LOINC

•  Logical Observation Identifiers Names and Codes (www.loinc.org)

•  Global system for identifying tests and observations

•  Used to identify resulted LAB test value in messages

•  Local coding system (ex: MT value) can be sent along with the LOINC code to assist with data mapping between the two systems if needed


SNOMED CT

•  Systematized Nomenclature of Medicine

•  Global clinical content terminology

•  Used with LAB and Microbiology results

•  Organisms (ex: 38907003 = Varicella (chicken pox))

•  Specimen Type (ex: 119297000 = Blood Specimen)

•  Procedures (ex: 252417001 = 24 hour EKG)

•  Can be part of patient Problem List (ex: 418799008 = Symptom)


UCUM

•  Unified Code for Units of Measure

•  Encompasses all units of measure being used in international science, engineering and business

•  Focus is on electronic exchange of these units

•  Used to report units of measure throughout various interfaces

(examples) mL = milliliter ug/mL = microgram per milliliter [degF] = degrees Farhenheit


CVX/MVX

•  CDC Vaccine Administered code set (Immunizations) (ex: 141 = influenza seasonal injectable)

•  CDC Manufacturers of Vaccines codes (Immunizations) (ex: PFR = Pfizer, Inc)

ICD9/ICD10

•  Problem List

•  Public Health Interfaces

•  Clinical Documents

Sample OBX Segment with Codified Values

OBX|7|SN|108-1^Cefotaxime Islt MIC^LN^M600.212^CEFOTAXIME OTHER^L^2.40^5.66||=^0.5^^^|ug/mL^microgram per milliliter^UCUM^ mcg/ml^microgram per milliliter^L^1.1^5.66||S^Susceptible. for microbiology susceptibilities only^HL70078^^^^HL7 v2.5.1|||F|||20150506084800-0500| |1112223334^TESTDR^MARK^^^^^^NPI&2.16.840.1.113883.4.6&ISO^L^ ^^NPI^IL&2.16.840.1.113883.3.229&ISO^^^^^^^|||201505060925-0500||| |IATRIC HEALTH SYSTEM^L^^^^CLIA&2.16.840.1.113883.4.7&ISO^XX ^^^11D0224433|300 SINGLE RIDGE RD^^SOMEWHERE^MA^01001^ ^L^^SPM|1|M51996.110.0300&IL&2.16.840.1.113883.3.229&ISO^ M51996.110.0300&IL&2.16.840.1.113883.3.229&ISO||258580003^Whole blood sample^SCT^BLD^BLOOD^L^20120731^5.66|||||||P^Patient^ HL70369^P^Patient^L^HL7 v2.5.1^5.66||||||20150506084800-0500 |20150506084800-0500||||||||||

Codified Values Impact

What does this mean for vendors?

•  Software products cannot be certified as Meaningful Use compliant unless these match proper specifications (the right data must be sent)

•  Interface vendors need to ensure that all software offerings meet Meaningful Use requirements and must receive certification from an accredited organization for each solution

•  Data validation tools are available and must be used to confirm all data is in acceptable format and model before certification can be scheduled


What does this mean for vendors?

•  National Institute of Standards and Technology (NIST) provides a testing validation tool for this purpose and this is widely used and modified

•  Once certified, vendors can change some items within each offering but must evaluate all change requests to prevent “breaking” an offering

•  All change requests must be reviewed in this light to ensure continued v2.5.1 compliance


What does this mean for vendors? •  Mapping utilities may be needed to map each non codified value to its required codified counterpart

•  Home medications (drug, route, frequency, dose)

•  Allergies (value, severity, type)

•  Problems

•  LOINC/SNOMED/UCUM/CVX/MVX


What does this mean for vendors? Outbound:

•  Data is collected electronically from the Hospital HIS system using that system’s dictionaries/values

•  Mapping utility is applied for fields requiring codified mapping

•  Output is now compliant with necessary data requirements and can be transmitted to receiving system

•  Receiving system may or may not be aware that this mapping took place


Example: HL7 v2.5.1 message created with Meditech standard

source data, IMO mapping and 3rd party mapping process

Meditech Data

IMO Mapping Tables

HL7 Message

3rd Party Mapping

Tables

Final HL7 Output

containing v2.5.1 codified data


What does this mean for vendors? Inbound:

•  Data is received from outside system matching codified data requirements

•  Mapping utility is applied for fields requiring codified mapping to determine local HIS system value to use

•  Output is now compliant with necessary HIS system data requirements


Example: HL7 v2.5.1 message received, 3rd party mapping tables and IMO mapping used to create final Meditech codified

value

HL7 v2.5.1 compliant

message received

3rd party Mapping

Tables

IMO Mapping

tables

Final Meditech data set


What does this mean for vendors? •  We’re seeing mixed adoption so far with vendors

•  Some are ready for v2.5.1 while others are years away

•  Some vendors are not HL7 compliant and are planning on going right to web service and API type programming w/o supporting HL7


What does this mean for Hospital staff?

•  Dictionaries – The following Meditech Dictionaries are impacted and require seasoned staff for data entry to provide the necessary codified content:

•  Customer Defined Queries - Used to capture data values which may not always have a predefined location within Meditech

•  LAB Tests

•  LAB Specimen Type

•  LAB Site

•  Microorganisms

•  Micro Procedures and Source



•  Dictionaries – The following Meditech Dictionaries are impacted and require seasoned staff for data entry to provide the necessary codified content:

•  Nomenclature

•  Antibiotics

•  MIS Provider

•  Other MIS and NMI Dictionaries



•  Mapping

•  Can involve thousands of entries and can take quite a bit of time to complete

•  Needs to be completed before proper testing can begin (timeline impact and consideration)

•  Requires clinical knowledge and expertize to properly complete

•  IMO Mapping – IMO tables are typically used as well to help address the mapping issues but these need to be reviewed, approved and maintained over time.



•  Mapping

•  Hospitals need to be prepared to set seasoned staff aside for a fair amount of time to complete the codified data mapping and data entry, no small effort

•  Hospitals need to be prepared to coordinate these activities months in advance of testing/attestation dates


Impact on Hospital staff (continued):

•  Change requests – Software vendors may be unable to change Meaningful Use certified items once these have been certified to preserve their structure and intent. Each change request needs to be closely reviewed and approved.

•  Timeline coordination – Software vendors may need to provide software updates to be Meaningful Use compliant before testing can begin, this activity needs to be coordinated between all parties and needs to be factored into the larger project timeline

•  Vendor delays can have large timeline consequences (firm go LIVE dates)

Clinical Documents

Clinical Documents:

•  There are many different types of Clinical Documents, these also take advantage of codified data values

•  These are typically made up of sections with each specification defining allowable sections and proper use of these sections for a document to be considered a proper document per spec

•  These are typically created in XML (Extensible Markup Language) with style sheet applied to make each document more human readable

FHIR

Looking forward with FHIR

•  Fast Healthcare Interoperability Resources (FHIR)

•  Next generation standards framework containing significant improvements over previous standards

•  Takes advantage of lessons learned with previous HL7 versions and offerings (v2, v3 Clinical Document Architecture CDA) and the latest web standards

•  Can be used as a stand-alone data exchange standard and can also be used in partnership with prior HL7 standards as there is overlap

FHIR

•  Designed to allow fast and easy implementations!

•  Solutions are created from a set of modular components called Resources

•  All exchangeable content is defined as a Resource

•  The Specification contains general documentation describing how Resources are defined, a list of available Resources as defined by HL7 and Implementation requirements for using these Resources

FHIR

•  The majority of common use cases can be satisfied by using Resources either by themselves or by combining Resources

•  FHIR contains Resource relationships to satisfy the majority of common implementations as well as built-in extension mechanism which allows implementers to expand Resources to cover remaining content as the need arises

FHIR

Advantages with FHIR:

•  Strong focus on implementation and ease of use

•  Concise and easy to understand specification

•  Specification is free for use with no restrictions

•  Interoperability “out of the box”, large set of base resources provided to solve most common healthcare integration challenges

•  Expandability – Items can be added as needed to cover use cases which are not provided in the standard set

•  Strong foundation on web standards

•  Suitable for wide range of contexts requiring healthcare data for integration – mobile apps, cloud based communications, EHR based data sharing, server to server communications in large settings

FHIR

Resources:

•  All Resources share common characteristics:

•  A common way to define and represent them

•  Built from data types that define common reusable patterns of data elements

•  Common set of metadata (version information)

•  Human readable component (documentation) (XHTML)

•  Has a url by which it can be addressed

•  Allowable Resource Types are defined in the specification

•  Identified version which is updated as the content is updated

FHIR

Resources:

•  Represented in either XML (Extensible Markup Language) or JSON (JavaScript Object Notation), end users can decide which implementation to use

•  References – Elements within Resources can contain links to elements contained within other Resources, allowing these to be combined together to build a rich collection of healthcare information to solve complex problems

•  References – These are provided as a url and always flow in one direction from the source Resource to the target Resource

•  Extensibility - Every element in a resource can be expanded (via the specification rules and requirements) to represent additional information above and beyond the basic definition for the resource

FHIR Resources List:

FHIR

RESTful API:

•  Defines a set of operations (interactions) which may be performed on Resources

•  Organizations can choose which of these are supported

read – Read the current state of the Resource update – Update a Resource by its id delete – Delete a Resource history – Retrieve update history for the Resource create – Create a new Resource with a server assigned id search – Search the resource type based on some filter criteria validate – Check that the content would be acceptable conformance – Get conformance statement for the system transaction – Update, create or delete a set of resources

Patient Resource Example

Immunization Resource Example

FHIR Example Use Case 1

Accessing patient health record via a portal or mobile app:

•  RESTful API provided (exposed) by Healthcare organization

•  This would support the search and read operations on these Resources:

•  Patient – to provide demographic info

•  Document Reference – to provide access to patient documents

•  Clinical Resources – to provide patient clinical data

•  Patient portal/mobile app would interact via this API to perform proper patient validation and present the user with the patient’s information as a result of the search/read operation interaction with the Healthcare organization

FHIR Example Use Case 2

Document sharing:

(Using a repository of documents around a patient record via XDS (Cross-Enterprise Document Sharing) framework)

•  DocumentReference Resource – describes a document stored within the network

•  Binary Resource - used to store the actual documents on a FHIR supported server

•  Patient/Practitioner/Organization Resources – used to provide proper identification and indexing links per document

•  SecurityEvent Resource – tracks usage of documents

•  These Resources can be combined to create a Clinical Document query/retrieval mechanism specific to each organization

FHIR

Looking forward with FHIR

•  Application Access to Common Clinical Data Set item for Stage 3 (§170.315(g)(7))

•  Calls for API to be used to provide various patient data to an outside calling system, CMS wants the patient to have access to this data via API

•  FHIR could be used here to accomplish this via Resources (proper Patient Identification, data collection for specific patient, return to calling system via API and logging of actions)

Summary

•  HL7 version 2.5.1 is built upon previous versions and contains many similarities to previous versions but contains stricter codified values

•  HL7 version 2.5.1 is required for several Meaningful Use objectives across all Stages

•  Software vendors must conform to this version for these objectives and must be able to send/receive the correct codified values

•  Some changes may be made to these items solutions without having a negative impact on certification standing or HL7 version requirements

•  But, all changes need to be reviewed to confirm these can be made without negative impact for all parties

Summary

•  Mapping utilities may be required to properly transform each Hospital’s non codified data to the proper v2.5.1 codified data set. Hospital staff will need to be trained on these tools

•  A fair number of Meditech Dictionaries will also require data entry for proper codification. Hospital staff will most likely need to spend a fair amount of time on mapping and Dictionary build activities before testing can begin

•  Clinical expertize and knowledge are required to properly map the required values, this will most likely require seasoned resources from the Hospital to complete

•  These activities need to be coordinated and factored into the larger project plan to allow sufficient time for mapping/testing ahead of project go LIVE

Summary

•  There are many different types of Clinical Documents, these are typically created using pre-defined sections

•  These are typically programmed using XML and a style sheet for easier human readability

•  Fast Healthcare Interoperability Resources (FHIR) is a next generation standards framework containing significant improvements over previous standards

•  FHIR Resources should start to become more common moving forward and are called for as part of Meaningful Use Stage 3 (tentative)

Questions - We Can Help!

Rich Murphy

Vice President, Interface/Integration Division

Iatric Systems, Inc.

(978) 805-4151

[email protected]

Summary

Useful links:

•  http://HL7.org

•  http://HL7.org/fhir

•  www.Loinc.org

•  http://www.ihtsdo.org/snomed-ct (SNOMED CT)

•  http://unitsofmeasure.org/trac/ (UCUM)

•  Twitter: #FHIR

HL7 Version 2.5.1 & Meaningful Use Contact Us

Follow Us:

For more information:

Please contact your Iatric Systems Account Manager Send an email to [email protected] Visit our blog http://new.iatric.com/blog-home

Thank you for attending!

understanding hl7 version 2.5.1 and meaningful use data considerations

Healthcare

use version

time version

common version

current version

lab results hl7 version

primary standards version

meaningful use stage

meaningful use requirements