early hearing detection and intervention (ehdi) interoperability pilot project presentation to cdc...
TRANSCRIPT
1
Early Hearing Detection and Intervention (EHDI) Interoperability Pilot Project
Presentation toCDC Health Information Innovation Consortium
byXidong Deng 1
Dina Dickerson 2
August 11, 2015
1. National Center on Birth Defects and Developmental Disabilities, Centers for Disease Control and Prevention2. Oregon Health Authority
EHDI-IS and EHDI HIT Standards • State-based EHDI information systems capable of identifying, matching,
collecting, and reporting data on all occurrent births through the three components of the EHDI process (screening, diagnosis, and early intervention).
Name Type Description Standard System
[1] Newborn Screening Coding and Terminology Guide Data Provides codes and terminology for newborn hearing screening procedures, results, and risk factors for infant hearing loss.
LOINC/SNOMED-CT
[2] HL7 Version 2.6 Implementation Guide: Early Hearing Detection and Intervention (EHDI) Results
Message Standardizes how newborn hearing screening information is transmitted from a point of care device to an interested consumer, such as public health.
HL7 v2
[3] IHE Quality, Research and Public Health Technical Framework Supplement: Newborn Admission Notification Information (NANI)
Message Describes the content needed to communicate a timely newborn admission notification electronically from a birthing facility to public health to be used by newborn screening programs.
HL7 v2, v3 message
[4] IHE Quality, Research and Public Health Technical Framework Supplement: Early Hearing Detection and Intervention
Document Defines how to exchange data required to populate a newborn’s Hearing Plan of Care document.
HL7 CDA R2
[5] HL7 EHR-System Public Health Functional Profile Functional Defines functional requirements and criteria to support public health-clinical information collection, management and exchanges for specific public health programs (domains).
HL7 EHR-S Functional Model
[6] IHE Quality, Research and Public Health Technical Framework Supplement: Quality Measure Execution-Early Hearing (QME-EH)
Quality Describes the content needed to communicate patient-level data to electronically monitor the performance of EHDI initiatives for newborns and young children.
HL7 QRDA
[7] Hearing Screening Before Hospital Discharge (NQF 1354 /CMS31v3)
Quality Electronic clinical quality measure definition for newborn hearing screening quality reporting , adopted by the CMS EHR Incentive Program for Hospitals and Critical Access Hospitals
HL7 HQMF
EHDI Standard-based Information Exchange
EHDI Standards-based Information Exchange
Labor & Delivery
Newborn Hearing Screening Device
State EHDI Information SystemProvider’s EHR System
Hospital EHR System
Federal Reporting
[4][3,4]
[6][5]
[2]
[2] [6]
The IHE EHDI ProfileThe EHDI Profile defines how to exchange data required to populate a newborn’s Hearing Plan of Care document
http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_EHDI.pdfhttp://wiki.ihe.net/index.php?title=PCD_Profile_DEC_Overview
5
A Real Life Audiologist User Story
① ③ ④
⑤
②
⑥
1. Screener enters identifying information into the screening device2. RNs, Audiology students, and support staff perform hearing screenings3. Screener prints results to capture results from equipment4. Nurses and support staff enter screening results into a data flow sheet in the electronic medical record.5. Audiologist also has paper copy of results. 6. The results are entered into the online birth certificate registry.
“Pulling the hearing screening results from the data flow sheet would have the greatest impact on timely reporting and reducing the number of errors. “Heather Durham, Au.D,. CCC-A, FAAADoctor of AudiologyPediatric Audiologist, Newborn Hearing Screening Coordinator, Assistant ProfessorChild Development and Rehabilitation CenterOregon Health and Science University
6
Project Objective
By June 30, 2015, in collaboration with CDC, OZ Systems, Oregon Health Authority (OHA), and OHA’s clinical trading partner, Oregon Health & Science University (OHSU), conduct an implementation of the Integrating the Healthcare Enterprise (IHE) EHDI Profile for the exchange of production hearing screening and care plan data between clinical and public health entities.
EHDI Interoperability Pilot Project Charter, 2015
7
Comparison of Oregon EHDI Pilot Phases 1 and 2
2012-13 Phase 1: Public Health Data Standards Consortium• IHE Profile Early Hearing Care Plan (EHCP)• Epic EHR test harness with simulated hearing screening result data• RFD data capture• EHDI-IS test database
2014-15 Phase 2: Public Health Informatics Institute• IHE Profile Hearing Plan of Care (HPoC)• Epic EHR live data captured via newborn assessment flowsheet• IHE PCD-01 technical framework with EHR as Device Observation Reporter• EHDI-IS live database
8
Phase 2 Project Stages
Stage Lead
Process and content evaluation and mapping OHA
Device observation reporter OHSU
Device observation consumer/ content creator OZ
Content consumer OHA
Standards conformance validation & scenarios Lantana
Data quality testing OHA
Lessons learned All
9
Mapping to HPoC
10
Data flow
Capture & Share Send Receive, Consume & Repackage
Send Receive & Consume
Participant OHSU
VPN
OZ
sFTP
OHA
Role Device Observation Reporter
Device Observation Consumer/ Content Creator
Content Consumer
Content & Rules
Hearing Screening Results
Decision Support Rules
Data Mapping RulesDemographics
Discharge Date
Format Epic EHR HL7 v2 HPoC EHDI-IS
11
Data Flow Detail: OHSU
Screening results message creation
Epic user enters data into Newborn Assessment flowsheet and clicks File
Epic generates HL7 result message carrying screening data
OHSU interface engine transforms HL7 to meet EHDI specifications
OZ receives screening data in HL7 messages
Newborn patient discharge HPoC creation
Epic user discharges newborn patient Epic generates HL7 ADT
discharge message OHSU interface engine transforms HL7 to EHDI result with status of Final
OZ receives Final result and triggers HPoC generation
Data capture and file Epic generated HL7 message (easy)
Interface engine transformed HL7 message to EHDI specifications (difficult)
12
Data Flow Detail: OZ SystemsScreening results and discharge message processing
Receive and store HL7 messages via VPN tunnel into HPoC Mapper
Send ACK or NACK validation message back to sender
Apply logic to determine if HPoC is ready for creation (includes results + discharge data)
If ready send HL7 message to HPoC Builder
Newborn hearing screening HPoC creation
HPoC Builder receives HL7 message from HPoC Mapper and populates CDA template
HPoC Builder generates HPoC
HPoC Builder validates HPoC against national standard
HPoC delivered to OHA via sFTP regardless of validation results
HPoC message sent to OHA Human-readable HPoC
lantanagroup.com13
Scenario Artifacts
0 Preliminary test to validate if testing environment is working as expected.
A Expected case. Epic user enters all the hearing data and hits save. The patient is later discharged.
B Multiple measurements. The Epic user enters the results over time. Maybe over days. This includes data that has been saved and then edited. The patient is later discharged.
C Deleted Measurements. Values are entered and saved, but then the user winds up deleting all values again. The patient is later discharged.
D Discharge without any screening results.
E Results without discharge.
F Results after discharge.
Test Scenarios
lantanagroup.com
Validation Scenarios
14
Outcome Content Artifacts
A1 – 09910001 L: pass R: refer HS1; D; HPoC
A2 – 09910002 L: pass R: refer HS1; D; HPoC
A3 – 09910003 L: pass R: not performed HS1; D; HPoC
A4 – 09910004 L: pass R: not performed HS1; D; HPoC
A5 – 09910005 L: not performed R: not performed HS1; D; HPoC
A6 – 09910006 L: refer R: refer HS1; D; HPoC
B2 – 09920002 L: refer R: pass HS1; HS2; HS3; D; HPoC
C1 – 09930001 L: refer R: refer HS1; HS2; D; HPoC
C2 – 09930002 L: refer R: pass HS1; HS2; D; HPoC
D1 – 09940001 L: no information R: no information D; HPoC
D2 – 09940002 L: no information R: no information D; HPoC
E1 – 09950001 No HPoC NoHPoC HS1; HS2;
E2 – 09950002 No HPoC No HPoC HS1; HS2;
F1 – 09960001 L: no information R: no information D; HPoC; HS1;
F2 – 09960002 L: no information R: no information D; HPoC; HS1;
Quality Review
249 HPoCs created >228 processed >
224 unique records reviewedDemographics (4 fields)
Address (1 field)
Test Results (5 fields)
Child's last name
Child's first name
DOB Gender Address1 Left Outcome Time
Left Result Right Result Left Equip-ment
Right Equipment
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Completeness and Match of OVERS and Epic Data, Selected Fields (N=224)
Percent complete OVERS Percent complete EPIC Match Percent
17
Lessons Learned• Planning
• The goals for a pilot should be clarified as distinct and separate from production-level implementation• Collaboration
• Establish decision-making process and authority during planning phase• Ensure all relevant parties attend team meetings, including EHDI program staff, IT staff, clinicians and EHR vendor representative
• Use shared communication and file-sharing tools
• Testing• Testing scenarios may require time to develop, may be workflow dependent and may require multiple rounds of testing to finalize
• A minimum of one month's production data is needed to identify limitations of the testing scenarios
• Workflow• Clinical workflow improvements should be evaluated, identified and implemented prior to the start of a technology project to ensure data integrity is at its best
• Standard• Need flexibility with the standard to deal with reality of the clinical setting workflow and EHR – this
does not happen in a vacuum
• Overall• Sending newborn hearing screening data to OHA is not a priority for OHSU ITG
18
Recommendations
• Develop testing mode capability that allows test cases to be re-run while preserving test scenario data to ease pilot testing for others
• Move HPoC creation to the State rather than hospitals
• Focus more on improving data quality and less on transport
• Funding and timelines need to be realistic
• Define the minimum/core standards, allow local control of implementation decisions
•National/academic standards specifications should be responsive and flexible to real life – rigidity is not realistic, and need for data trumps fidelity to the model
19
AcknowledgementsOregon Health AuthorityMeuy SwaffordHeather Morrow-AlmeidaTrong NguyenChia-Hua YuClaudia Bingham
Oregon Health & Science UniversityHeather DurhamDoug ClauderTom Drury
OZ SystemsTeresa FinitzoSarah ShawKen Pool
Public Health Informatics InstituteJim JellisonTrish Miller
Lantana Consulting GroupLisa Nelson
CDCJohn EichwaldMarcus Gaffney
