You know that not doing Meaningful Use correctly can impact your incentives. In this Webcast you'll learn what is needed to support HL7 v2.5.1 and its impact on Meaningful Use data exchange.

1. Presented By:
Rich Murphy, VP, Interface Software
July, 2015
HL7: Version 2.5.1 and
Meaningful Use data
considerations

2. Topics
• Brief overview of HL7 v2.5.1
• Codification Standards and
considerations
• Clinical Document Exchange
considerations
• XML and Clinical Documents
• Looking forward with FHIR

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

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

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

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

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

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

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

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

11. HL7 Version 2.5.1
Codified Values
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

12. HL7 Version 2.5.1
Codified Values
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)

13. HL7 Version 2.5.1
Codified Values
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

14. HL7 Version 2.5.1
Codified Values
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

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

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

17. Codified Values Impact
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

18. Codified Values Impact
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

19. Codified Values Impact
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

20. Codified Values Impact
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

21. Codified Values Impact
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

22. Codified Values Impact
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

23. Codified Values Impact
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

24. Codified Values Impact
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

25. Codified Values Impact
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:
• Nomenclature
• Antibiotics
• MIS Provider
• Other MIS and NMI Dictionaries

26. Codified Values Impact
What does this mean for Hospital staff?
• 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.

27. Codified Values Impact
What does this mean for Hospital staff?
• 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

28. Codified Values Impact
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)

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

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

31. FHIR
• Currently in the Draft Standard for Trial Use (DSTU)
level. Content has been well reviewed, is considered
ready for use in production systems and currently slated
for Normative (“locked”) release in 2017.
• 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

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

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

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

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

36. FHIR
Resources List:

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

38. Patient Resource Example

39. Immunization Resource Example

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

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

42. 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)
FHIR – What’s All
the FHUSS Webcast
August 11th at 2pm ET
http://bit.ly/1IFT18H

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

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

45. 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)

46. Question? We Can Help!
Rich Murphy
Vice President, Interface/Integration
Division
Iatric Systems, Inc.
(978) 805-4151
Rich.Murphy@iatric.com

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

48. HL7 Version 2.5.1 & Meaningful Use
Follow Us:
For more information:
Please contact your Iatric Systems Account Manager
Send an email to info@iatric.com
Visit our blog http://new.iatric.com/blog-home
Download the on-demand webcast
here: http://bit.ly/1NAMkF1