Health Device Semantic Interoperability Project (HDESIP)

Concept Presentation for the

Joint meeting of IEEE EMBS 11073 and HL7 Health Care Devices (DEV) WG, at the HL7 Working Meetings

TENTATIVE AND PRELIMINARY – FOR DISCUSSION PURPOSES ONLY

September 26, 2013

transforming healthcare through IT

Objective

1. Obtain Guidance and Constructive Criticism for HDESIP from Attendees of the Joint meeting of IEEE EMBS 11073 and HL7 Health Care Devices (DEV) WG, at the HL7 Working Meetings

2. Recruit collaborators to participate in efforts to drive HDESIP and help make medical devices a key part of Meaningful Use Stage 3 in the US

Background

Emerged in IHE PCD leadership and HIMSS meeting of the minds conference call in the summer of 2013 as Priority Number 1

Following presentation materials are a work in progress developed by Alex Lippitt with major contributions from Paul Schluter, John Garguilo, and the IHE PCD leadership team in general with apologies to them from Alex for any and all naive bumbling and misrepresentation

In the Meantime on Parallel Paths.....

• IEEE• West Health• FDA and Pew Charitable Trusts - UDI

Need to join forces!

The Challenge

• Clinicians recording output from patient medical devices on their scrubs or lab coats is an all too common practice; Clinicians need to do this to retain and access the data obtained from medical devices like vitals monitors, ventilators and infusion pumps as it is not being automatically transferred to their monitoring and EHR systems. The process in non-clinical patient settings, such as patients monitoring vital signs or other indicators at home, has similar challenges. This data, even if monitored, may never make it into a medical record or if entered this data runs an unacceptable amount of transcription errors posing high risk to patient safety. This data is a key link in a true implementation of mHealth and integrated care.

• Electronic medical devices are generally fully capable of recording and transmitting data but the clinical endpoint systems are often unable in real time to consume that data into patient medical records. What data is entered is often entered retrospectively.

Why is this?

• 1) Medical devices use IEEE standards (with FDA approval) to generate electronic data that could be easily transmitted to EHRs using IHE and HL7 standards. However this data needs to be translated into SNOMED or LOINC clinical observation data. Such clinical observations in the EHR must be saved as SNOMED or LOINC. IEEE is not a recognized Meaningful Use nomenclature.

• 2) There is no Meaningful Use mandate for EHRs to electronically interact with medical devices and do clinical observation data coding translation nor is there a process and set of conversion tables for EHRs to accomplish this.

Goal

Our goal is to build a comprehensive bridge between data produced by medical devices and clinical information systems used for monitoring and storing patient electronic health records. Within a short period of time, we want to close this large interoperability gap by making existing components work together. Closing the technology gaps requires some relatively minor integration work using standards that already exist; construction focuses on translating one standard set of terminology to another and making these translations accessible and usable in EHR and other clinical systems.

PROPOSED SOLUTION DISCUSSIONAnd now for the:

Hospital Clinical Device ConnectivityHospital Device

Gateway(s)

Hospital Health

Records

Remote EHRs and

Clinical Montoring

Health Information Exchange

Departmental Devices and Mgmt

Systems

Acute care

Cardiology

Surgery

ER, others …

IHE DECProfiles:

PCD+RTM,PIB, SPD,

ACM, IPEC,PIV,

WCM, IDCO …

HL7 v2.xIHE

ContentProfiles,

XDS, XDR

Note: IHE Profiles shown above were demonstrated at HIMSS13 as trial implementations;IHE DEC PCD-01 Technical Framework “Final Text” became available in Q3 2011.

Internal Hospital Network Including Device

Management and Monitoring

Slide developed and provided by Paul Schluter, GE Healthcare

Vocabulary elements are present in this standard

Ambulatory Clinical Device Connectivity

Direct Connect or Ambulatory Middleware

(options)

EHR and Clinical

Monitoring

Middleware

Departmental Devices and Mgmt

Systems

Primary Care

Ambulatory Specialties

Surgery

Immediate Care

IHE DECProfiles:

PCD+RTM,PIB, SPD,

ACM, IPEC,PIV,

WCM, IDCO …

HL7 v2.xIHE

ContentProfiles,

XDS, XDR

Note: IHE Profiles shown above were demonstrated at HIMSS13 as trial implementations;IHE DEC PCD-01 Technical Framework “Final Text” became available in Q3 2011.

Slide developed and provided by Alex Lippitt HIMSS / IHE, derived from accompanying NIST slidesVocabulary elements are

present in this standard

Personal Health Device Connectivity

Aggregation Manager

Telehealth Service Center

Health Records

Devicesaka Agents

ContinuaWAN

ContinuaHRN

ContinuaPAN

ContinuaLAN

Note: Continua Version 2011 Guidelines available today. The Continua WAN interface uses the IHE DEC PCD-01 transaction over Web Services.

Slide developed and provided by Paul Schluter, GE Healthcare

Vocabulary elements are present in this standard Repeat on other slides

Types of data medical devices can produceType of data Initial coding at

device / gatewayTarget coding (clinical applications) – all come in as IEEE (in addition orders and commands must come in to devices / gateways as IEEE)

Waveform IEEE SNOMED-CT/LOINC conversion preferred (may not be able to do so in some cases).

Numeric Observations (vital signs, physiologic). Includes units of measure, value sets, and physiologic identifiers, but not mechanical numeric observations

IEEE SNOMED-CT/LOINC conversion strongly preferred. Will probably always be missing codes that will need to stay IEEE

Commands & External Control IEEE IEEE. Will probably always be missing codes that will need to stay IEEE

Device Settings IEEE IEEE

Technical Alerts IEEE IEEE

Vital Sign / Physiologic Alerts. IEEE SNOMED-CT/LOINC conversion preferred. Will probably always be missing codes that will need to stay IEEE

Modeling devices – tying related terms together by device including relationships (where used). Work going on now with infusion pumps

IEEE SNOMED-CT/LOINC conversion preferred. Will probably always be missing codes that will need to stay IEEE

CDS – Clinical Decision Support (example – on IEEE side device software provides an “alert” based on multiple data points and trends that patient may be encountering Sepsis)

IEEE (potentially driven by SNOMED_CT/LOINC)

SNOMED-CT/LOINC conversion preferred. Will probably always be missing codes that will need to stay IEEE

Proposed New RTMMS Application

X73Medical devices

New RTMMS

Application(Notes 1+2)

X73 medical device manufacturers (like

Philips, GE) and gateway/middleware

/interface engine vendors (like Capsule,

iSirona, Nuvon)

EMR and clinical

monitoring

Vendor IEEE 11073 or proprietary Messages

Observations/Results and selected alerts/alarms using IEEE coding in HL7 v2.x and IHE messages

Orders (limited, usually standing)

Rosetta Terminology

Mapping System (RTMMS)

(Note 3)(Note 3)

NIST ICSGenerator (Implementation

Conformance Statement Generator)

(Note 4)

Test messages for

Some devices go direct to EMR and clinical monitoring systems

HOW TO GET THIS DONEAnd now for the:

“Enableathon”

• Enableathon name – thanks to Paul Schluter• This is more than just a standards project; in order to

be successful:– Standards and vocabularies need to be harmonized– Federal Meaningful Use regulation needs to be amended

to align interests of vendors with this change.– A number of groups need to be involved:

Success Requires Alignment and Commitment (incomplete)

• ONC – Meaningful Use Stage 3

• EHR Vendors• Medical Device

Community• Data Community

– IEEE– IHTSDO– Regenstrief

• Healthcare Delivery Community

• Federal Regulatory– CMS– FDA

• Federal Deployment– NIST– NLM

• Standards and Profile Community– HL7– IEEE– IHE

And in addition............

• All parties need to be compensated/incented for their efforts

• A project management office with a full time project manager needs to drive the overall effort under the guidance of the Steering/Quality Assurance structure.

• There needs to be a closed loop that drives toward full health IT industry adoption with both a full cycle :– Pilot phase and an– Implementation phase

Guiding Principles and Core Values

• Alignment and Trust – All will win• Focused effort - Incremental / small steps• Low hanging fruit• Inclusive silo buster• Alignment with US initiatives in Cycles 1 and 2 (Meaningful Use Stage

3)• Inclusion of international initiatives in Cycles 1 and 2 for later cycles• Adherence to international standards – IEEE, HL7, SNOMED, LOINC, etc.• Alignment of medical device and EHR / clinical system vendors• Collaboration with other initiatives (for example UDI) to bring medical

device and ambulatory / inpatient /payer /consumer / nursing worlds together

PDCA / PDSA Cycle 1

Development Through IHE Trial Implementation

We are somewhere here

PDSA / PDCA Cycle 2

Implementation under First Wave Meaningful Use Stage 3 Certification

Install Interoperable

products in Clinical Settings

worldwide

Install Interoperable

products in Clinical Settings

worldwide

Demonstrate at aDemonstrate at a

IHE ProcessIHE Call for Proposals Opens

IHE Call for Proposals Opens

Profile Selection by Committees

months 1-5

months 14-18

Publish in IHE’s Product Registry

Test at IHE ConnectathonsIHE Profiles Drafted & Revised

months 6-13

Trial Implementation PostedPublished

For PublicComment

IHE Technical Framework Developed

IHE InternationalDevelopment IHE USA

Deployment

PDSA Cycle 1 - Proposed Fast track through IHE Connectathon New Directions 2014 - Plan

PDSA Cycle 2

PDSA Cycle 1 – Do and Study

Potential Sponsors / Project Management

Sponsor s• IEEE?

• IHE International?• West Foundation Center for

Medical Interoperability?

Project Management• IHE USA

• Kearney & Co?

Key Proposed Stakeholder Leadership

Steering / Quality Assurance • AAMI• ACCE

• Continua• EHRA• HIMSS• HL7

• IHE International• ISO TC 215 W2

External Advisory• Ambulatory representative

• CMS• Consumer representative

• Critical Access Hospital Representative• DOD

• European Union Representative• IDN representative

• FDA CMS• Nursing facility Representative

• ONC (AL/JS)• Payer Representative

• VA• WHO Representative

Proposed Enableathon / Implementation Team

Implementation team - Private• IHE PCD

• IHE USA and subcontractors • EHR vendors • Regenstrief

• IHTSDO / CAP • West Health - Center for Medical Interoperability

Implementation Team - ONC cooperative agreements• NIST • NLM

Key Timing and Other Constraints

• Meaningful Use Stage 3 Proposed Rules Mid November

• Meaningful Use Stage 3 Desire for Proven Solutions

• IHE Cycle• ???

Key Questions Outstanding

1. How build this into MU Stage 3? Emphasis is on proven solutions 2. Assuming collaboration with UDI work and FDA / Pew Charitable Trusts can

we use the alliance to push for structure in the provider segment of the ? 3. How obtain high level Federal support for an end to end, closed loop

project like this?4. Who from a standards and regulatory perspective needs to approve?5. What intellectual property agreements are required? 6. How detailed does proposal need to be to go for funding?7. Who will fund? West Foundation Center for Interoperability?8. Who will commit to what in the implementation?9. How work through IHE process?10. How to obtain EHR and Clinical Monitoring software vendors active

engagement and support?

STRUCTURE TO GET THIS DONEAnd now for the:

Concept Project Execution Timeline Deliverables (work stream rows to be completed)

Months 1 2 - 3 4 5 - 6 7 - 8 9 - 12 13 - 15 16 - 18

Work Streams Organize, Plan, Align, Commit Delivery

Develop baseline, detailed reqs and specs

Review, Approve, Ballot

Build mapping and support process

Develop and test clinical aps

Execute pilots and prepare for deployment

Deploy and study

Wrap up –quality, sustainability

Business Case, Project Organization, Agreements,

Measurement, Sustainability

Requirements , Specifications and

Balloting

Semantic Interoperability Build

and Support

NIST and EHR Application

Development

Testing and Implementation

Deployment and Support

Project Management

Checkpoints, Review, Quality Assurance

Explanation

• Please note the use of the following listed work streams in the previous slide table. These represent the multifaceted work that needs to be completed to gain consensus, design, build and test both a working and a sustainable solution. The capped and bolded components represent the PDSA (Plan / Do / Study / Act) quality cycle though the 18 months projected for the project through two cycles: 1 from inception through the pilots (roughly the first year), and the first wave of true deployment (roughly the last six months):– Project Organization and Agreements (Agree / PLAN)– Requirements , Specifications and Balloting (Require / ACT)– Semantic Interoperability Build and Support (SI Build / DO)– NIST and EHR Application Development (AppDev / DO)– Testing and Implementation (TestImpl / DO)– Deployment and Support (DeplSupp / DO)– Project Management (PM / ALL)– Checkpoints, Review, Quality Assurance (Check /STUDY)

NEXT STEPSAnd now for the:

Pre Funding

Detailed Project Description / Submission of IHE Profile

Proposal

Team and Common Cause Building:HL7, IEEE, NLM, FDA, Pew Charitable Trusts, West Health Center

for Interoperability

Solution Conceptual Design

Project and Ask Definition / Executive Summary

Funding Wrapper – Formal Proposal

Participant Agreements: Detailed Estimates

Proposal Negotiation and Agreement

Meaningful Use Stage 3 Proposed Rule Development

Key Project Roles to be FilledSponsors Requirements and SpecificationsSteering Standards Harmonization – Initial and

OngoingExternal Advisory / Federal Oversight Pilot Device Vendors

Funder / Funders IEEE and SNOMED / LOINC Semantic Interoperability Harmonization

Financial and Clinical Outcomes Projection and Measurement RTMMS build

Survey Baseline and Outcomes Mapping Support and Maintenance

Project Office Implementation Guides and Tools Development

Pilot EHR and Clinical Monitoring Vendors Testing and Certification

Intellectual Property Agreement Clinical Change Management

Application Architecture Quality Assurance

Proposed Next Step(s)

• F2F in Washington DC area (AAMII, HIMSS, other) with collaborators to pull together proposal artifacts:– S+I Initiative Format Charter– IHE Profile Proposal– Proposed Meaningful Use Rule in Conjunction with UDI

Amended Rule– Application Architecture Definition– Testing Scheme Definition– Financial and Health Outcomes Justification– ONC meeting with Doug Fridsma and team to push

forward

EXTRA SLIDES – NOT INCLUDED, NOT UPDATED FOR AWHILE

And now for the:

Key Expected Benefits and Projected Cost• The project as defined will involve baseline measurements and surveys

as well as measurement at the pilot and deployment phases using sample data and interviews where applicable.

• Decreased medical errors and associated reduction in injury and mortality

• Increase in efficiency and lowering of cost in reentry of medical device generated clinical data

• Increased clinician satisfaction related to HealthIT• Increase in the implementation of new medical device to clinical system

connected clinical data functionality and utilization • Project structural and operational deliverable measurements are in plan

as well. We will work to provide a good model project that may be able to provide guidance for future HealthIT projects.

• Cost should be low relative to other Federal Health IT projects:• Estimated project cost to the Federal government and taxpayers is

projected to be in the $1 - $2 million range with minimal incremental ongoing support for standards and IT updates as well as overall oversight

Objectives• Funding of a project to harmonize existing standards, build the translations, and test with EHR /

clinical vendors willing to be included in compensated work to modify their software to access the data translations tables and convert IEEE medical device data to SNOMED and LOINC data for storage patient medical and monitoring records. Mapping should be the responsibility of the receiving clinical application based on tables to be provided by NIST built as part of this project. Medical devices should not be doing the translation/mapping:

– Devices need to be plug and play– Mapping at the device level is very inefficient and risks errors from disparate device

manufacturer mapping efforts; this is not part of what they do now– The IEEE coding should be preserved for monitoring and management uses

• Commitment of the federal agencies involved in completing or monitoring the work (NIST, NLM and FDA) in conjunction with the IHE International PCD (Patient Care Device) Domain

• Successful completion of the project• Approval by the HIT Standards Committee and CMS of a Meaningful Use Stage 3 provision to

require consumers of clinical observation data to accept IEEE coded data from medical devices and

– Translate this data into SNOMED or LOINC as appropriate and store this data as part of standard patient data recording

– Provide the IEEE data as necessary under ISO 11073 for such applications as the IHE PCD Device Observer Reporter

•