Laboratory Pilots/Deployment

1. Laboratory Pilots/Deployment June 12, 2012

2. Participants Production/Deployment Project Participants • Allscripts • athenahealth • Cerner • OPTUMInsight • RML • Labcorp • Halfpenny Technologies Pilot I Project Participants • Atlas Development • CAP • Halfpenny Technologies • KHIE • LabLynx Coordination of Effort • Validation Suite • Vocabulary Group • Implementation Guide Analysis • Support Team 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)

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

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.

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

6. Laboratory PilotsCommunity Options for Piloting Option One: Individual Initiative Pilots aka Pilots I • Point of Contact: Bob Dieterle • Details: Participants will pilot LRI LRI LOI 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 eDOS Option Three: eDOS Only Pilots • Point of Contact: Freida Hall • Details: Participants will pilot eDOS LRI LOI eDOS

7. NIST Validation Suite Considerations

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 ReportingWorkgroup June 8, 2012

10. Workgroup Members • LabCorp • Mike Skinner • Don Chase • Quest • Gregory Lovell • Mark Stein • Ken McCaslin (optional) • Methodist Hospital • Thomas Williams • Pathology, Inc • Bob Dowd • 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

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 12 weeks 8-12 weeks tbd

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

13. Concerns with using Direct • 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 specificationallows 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) • UmeshMadan(Microsoft, Direct Project Reference Implementation WG) • Vincent Lewis (GSI Health, EHR/HIE Interoperability WG)

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)

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

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

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

19. Notification requirements for Receiving HISPs • Must provide destination delivery notification messages upon request • Must notify Sending HISP upon successful delivery to a destination by issuing a positive destination delivery notification message (i.e., a “successful delivery” message) • 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)

20. Notification requirements for Sending HISPs • Must request destination delivery notification messages from Receiving HISP • Must notify or indicate back to the Sending system of failure to deliver to Receiving HISP • 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 • 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 • 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

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

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

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

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.

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