1. Laboratory Pilots/Deployment June 12, 2012 1

2. Participants Coordination of Effort Validation Suite Vocabulary Group Implementation Guide Analysis Support Team 2 Pilot I Project Participants Atlas Development CAP Halfpenny Technologies KHIE LabLynx Pilot II Project Participants Conversations Lab System and EHR Vendor (2) Lab System Vendor (2) EHR Vendor (3) Commercial Laboratories (2) Provider Based Commercial Labs (3) Production/Deployment Project Participants Allscripts athenahealth Cerner OPTUMInsight RML Labcorp Halfpenny Technologies

3. Agenda Updates on Laboratory Activity 1.LRI – DSTU Comment review 2.LOI – -- Status 3.eDOS – Launch 4.Validation Suite Update 5.Vocabulary Workgroup update – Cindy Johns 6.Direct-Lab Reporting Workgroup 7.Next Steps 3

4. LRI Finishing response to DSTU comments Expected completion next couple of weeks Need feedback from Pilots WG on their ballot reconciliation spreadsheet regarding length/conformance length and specific comment items. 4

5. LOI / eDOS Status 5 LOI Charter complete Use Case In process Alignment in process Vocabulary work in process eDOS Kick off June 19th

6. Laboratory Pilots Community Options for Piloting 6 Option One: Individual Initiative Pilots aka Pilots I Point of Contact: Bob Dieterle Details: Participants will pilot LRI LRI LOI eDOS LRI LOI eDOS Option Three: eDOS Only Pilots Point of Contact: Freida Hall Details: Participants will pilot eDOS eDOS Option Two: “Pilots II” Point of Contact: Bob Dieterle & Freida Hall Details: Participants will pilot LRI AND LOI with the option to additionally pilot eDOS LRI LOI

7. NIST Validation Suite Considerations Reporting Scenarios 1)Preliminary Report 2)Partial Report 3)Final Report 4)Cumulative Report (for recurring draws?) 5)Corrected Report / Amended Report 6)Cancel due to ………….. (e.g. specimen quality) 7)Error conditions (e.g. R, RE, C,CE misuse invalid syntax) 8)Reflex Testing 9)Add-on Tests/results 10)Addenda Report (is this a valid HL7 report type/status? 7 Test Types 1)Single numeric result with reference rangeA1 2) Single alpha result from limited response list (e.g. Positive, Negative, …)A2 3)Panel testing with combinations of 1) and 2)A1&A2 4)Textual ResultsA4 5)PDF as payloadA4 6)Textual with tabular dataA4 7)Combinations of 1) and 2) e.g. susceptibility MIC and InterpA3 Errata 1)NTE 2)PID text 3)Multiple OBR 4)Addon 5)Multiple OBR 6)Additional OBX 7)Reflex testing 8)Multiple OBR 9)Additional OBX 10)Add OBX for specific result types from order (e.g. total urine volume) 11)Multiple testing locations 12)Non-standard abnormal flags

8. Needed from all participants Testers and feedback for current version of Validation Suite tool http://lri.sipilotdevelopment.org/lri-dstu/ Volunteers for 1-on-1 Webex testing –Especially EHR systems –Validation Suite to be ready in June 2012

9. Direct – Laboratory Reporting Workgroup June 8, 2012

10. Workgroup Members ONC –Robert Dieterle –John Hall –John Feikema CAP –Ron Ranauro –Julie Cantor-Weinberg –Mary Kennedy –Andrea Pitkus –Gilan Saadawi –Gregory Gleason CLIA –Judith Yost –Harriet Walsh –Karen Dyer –Ann Snyder –Daniel Cajigas 10 LabCorp –Mike Skinner –Don Chase Quest –Gregory Lovell –Mark Stein –Ken McCaslin (optional) Methodist Hospital –Thomas Williams Pathology, Inc –Bob Dowd

11. Effort Sequence and Timeline Establish issues workgroup Develop and agree on issues, if any Review issues with ONC ONC review of issues with CMS/CLIA Expand workgroup to address mitigation Develop “comprehensive” mitigation list Prioritize by specific metrics (time, cost, impact) Review prioritized list with ONC and create final list ONC review of mitigation approach with CMS/CLIA Effort, implement and test 11 12 weeks 8-12 weeks tbd

12. Electronic Laboratory Results Reporting via Direct Terminal or portal EHR Lab report Print Image LIS or HIS system Laboratory Physician office HIE (Optional) HL7 over VPN or SOAP SMTP / MIME (Public Internet) HISP - A HISP - B E-Mail Server Security Agent E-Mail Server Security Agent SOAP/XD, Other Edge Protocols Web Services SMTP/MIME, SOAP/XD, Other Edge Protocols HL7 over VPN or SOAP 12 Multiple paths are possible depending on the specific implementation of Direct Direct (SMTP / SMIME)

13. Concerns with using Direct 13 Timely and predictable acknowledgement of delivery success or failure –Under CLIA, labs are responsible for delivering reports to the Final Report Destination, and must know when report delivery has succeeded or failed –Existing mechanisms for report delivery provide timely and predictable acknowledgement of success and failures Direct Project’s Applicability Statement for Secure Health Transport specification allows for acknowledgements of delivery success or failure, but does not require them –Security/Trust Agents (STAs), such as HISPs, that receive a Direct Message MUST acknowledge successful receipt and trust verification of a Message by sending a Message Disposition Notification (MDN) with a processed disposition (i.e., a processed MDN) –STAs / HISPs MAY issue other notifications under other conditions but are not required to do so

14. Lab Reporting Over Direct Subgroup: Members Andre Hebert (Harris) Bob Dieterle (ONC) Christine Phillips (Harris) Greg Meyer (Cerner, Direct Project Reference Implementation WG) Joe Lamy (ONC) John Hall (ONC, Direct Project) Lin Wan (OptumInsight) Paul Tuten (ONC, Direct Project Implementation Geographies WG) Roy Tharpe (Harris) Sean Kelly (GSI Health, EHR/HIE Interoperability WG) Seonho Kim (ApeniMED) Umesh Madan (Microsoft, Direct Project Reference Implementation WG) Vincent Lewis (GSI Health, EHR/HIE Interoperability WG) 14

15. Lab Reporting Over Direct Subgroup: June 7 Meeting Focus was May 30 Lab Summit and feedback received for Implementation Guide Feedback was positive in tone – overall feeling was that Guide was overdue No questions or comments received that require material changes to the Guide –One typo noted in Section 2.3: SHOULD should read SHALL in first bullet (since corrected) –Request for diagrams to further illustrate notification flows (accepted by group, under development) 15

16. Implementation Guide for Destination Delivery Notification in Direct Guide details how to implement timely, predictable acknowledgement of positive or negative delivery within a Direct context –Section 1 – What constitutes a delivery “success” or “failed” notification and how to request such notifications –Section 2 – Responsibilities of HISPs around these notifications –Section 3 – Implementation considerations of note –Section 4 – Use cases 16

17. Notification in a single HISP environment (both parties using same HISP) In a single HISP environment, the HISP positively knows when delivery to a destination (i.e., Receiver’s system or inbox) has succeeded or failed Requirement: Must notify or indicate back to the Sending system successful or failed delivery to the destination 17

18. Notification in a dual-HISP environment The Sender and Receiver (e.g., lab and ordering provider) may be using two different HISPs, a Sending HISP and Receiving HISP The Sending HISP on its own cannot tell when delivery to the destination (i.e., Receiver’s system or inbox) has succeeded, so each of the HISPs – Receiving and Sending – have certain requirements that must be met 18

19. Notification requirements for Receiving HISPs 1.Must provide destination delivery notification messages upon request 2.Must notify Sending HISP upon successful delivery to a destination by issuing a positive destination delivery notification message (i.e., a “successful delivery” message) 3.Must notify Sending HISP upon failure to deliver to a destination by issuing a negative destination delivery notification message (i.e., a “failed delivery” message) 19

20. Notification requirements for Sending HISPs 1.Must request destination delivery notification messages from Receiving HISP 2.Must notify or indicate back to the Sending system of failure to deliver to Receiving HISP 3.Must notify or indicate back to the Sending system failed or successful delivery to the destination based on any received positive or negative destination delivery notification messages 4.Must notify or indicate back to the Sending system failed delivery to the destination if no processed MDN has been received from Receiving HISP within a reasonable timeframe 5.Must notify or indicate back to the Sending system failed delivery to the destination if no destination delivery notification messages have been received from Receiving HISP within a reasonable timeframe 20

21. Electronic Laboratory Results Reporting via Direct Terminal or portal EHR Lab report Print Image LIS or HIS system Laboratory Physician office HIE (Optional) HL7 over VPN or SOAP SMTP / MIME (Public Internet) HISP - A HISP - B E-Mail Server Security Agent E-Mail Server Security Agent SOAP/XD, Other Edge Protocols Web Services SMTP/MIME, SOAP/XD, Other Edge Protocols HL7 over VPN or SOAP 21 Multiple paths are possible depending on the specific implementation of Direct Direct (SMTP / SMIME)

22. Laboratory Pilot/Deployment Overview  The goal of the Laboratory Pilot/Deployment effort is to create reference implementations (e.g. production or pre-production versions) of the laboratory results, orders and test compendium transactions based on the specifications in the LRI, LOI, and eDOS implementation guides. The purpose of these reference implementations is to:  Verify the specifications in the implementation guides in an operational setting to determine and document any exceptions, errors, or omissions that will facilitate the future revisions of the guide.  Validate and enhance the validation tools that will be used to aid in certification testing of these interfaces  Verify interoperability of the these reference implementations outside of the proposed ecosystems  Take the reference implementations to production use/deployment in 2012/2013 22

23. Ecosystem  Each participant will propose a complete ecosystem for reference implementation purposes  The recommended ecosystem should consist of a laboratory, LIS/interface vendor (may be in-house effort), provider organization, and EHR vendor  To the extent third parties integrators are required to create and/or support the reference implementation, they will be considered part of the proposed ecosystem  If participants are unable to assemble the entire ecosystem, Laboratory Pilot/Deployment leadership will assist in making introductions where possible 23

24. Laboratory Results Interface (LRI)  Each participant shall develop/implement and test a production or pre-production interface compliant with the Draft Standard for Trial Use (DSTU) version of the LRI IG for the exchange of laboratory results between the LIS and EHR.  Utilize the online validation suite to test all supported use cases applicable to the specific ecosystem.  Each laboratory/LIS and EHR should participate in an S&I Laboratory Pilot coordinated virtual interoperability forum to be established among the Laboratory Pilot II participants.  The resulting pre-productions LRI implementations are expected to be taken to production use by the end of 2012 and where possible rolled out to additional implementations in early 2013. 24

25. Next Steps / Questions Next Steps Continue recruiting Production/Deployment participants Work on expanded scenarios for validation suite Establish ecosystems for production/deployment Ask for help if need partner Schedule Calls for coordination every other week at same time next call 6/26 Continue work with Validation Suite Continue participation in LOI and compendium effort based on LOI calendar For questions, please feel free to contact Bob Dieterle: rdieterle@enablecare.usrdieterle@enablecare.us 25