The PITO EMR-to-EMR Data Transfer & Conversion Specification (E2E-DTC ): Experiences in Developing and Piloting A C

1. Accelerating Change The PITO EMR-to-EMR Data Transfer & Conversion Specification (E2E-DTC):Experiences in Developing and Piloting A Consolidated CDA Specification May 28, 2013 Ottawa

2. Image Source:www.quitehealthy.com Disclosures PITO & GPi

3. Faculty/Presenter Disclosure • Faculty: Marc Koehn • Relationships with commercial interests: • Employee of Gordon Point Informatics Ltd. • Faculty: Carol Rimmer • Relationships with commercial interests: • Employee of BC Medical Association, Physician Information Technology Office PITO & GPi

4. Disclosure of Commercial Support • This program has received financial support from The BC Medical Association and the Government of BCin the form of direct project funding through the PITO office. • Potential for conflict(s) of interest: • Gordon Point Informatics Ltd. developed and has leveraged a software tool to produce Consolidated CDA Guides mentioned in this presentation. PITO & GPi

5. Mitigating Potential Bias • The proprietary software tool is not the focus of the presentation; other tools will be noted. PITO & GPi

6. Outline • What is PITO? • Why this project? • What did we do? • What is the result? • What’s next? PITO & GPi

7. What is PITO? PITO & GPi

8. What is PITO? • Set up by the BC Medical Association (BCMA) and the BC government as part of their 2006 agreement. Currently have a mandate to March 2014. • PITO’s primary responsibility is to support the adoption and use of electronic medical records (EMRs) in physicians’ offices across BC. • PITO assists physicians during pre-implementation planning, implementation, and post-implementation, and coordinates the disbursement of IT funds to physicians as defined in the agreement. PITO & GPi

9. What is PITO? • PITO has four primary goals: • Adoption • Capacity • Solutions • Impact • Post-Implementation support is focused on achievement of meaningful use. PITO & GPi

10. What is PITO? *Excludes WIC, Psychiatry, and MDs *Excludes inpatient, pathology, radiology, locum, within 2 years of retirement hospitalist, and retired physicians • Visit http://www.pito.bc.ca/ for more information 5024 Target Physicians 79% On EMR 6808 Eligible Physicians 59% On EMR PITO & GPi

11. EMR-to-EMR Data Transfer & Conversion Specification (E2E-DTC) Why this Project? PITO & GPi

12. Why this Project? • Locked Data = Barrier to Collaborative Care • Gaps in EMR data standards as well as a general lack of thorough vendor adoption risks locking critical clinical data insideEMR systems • This continues to presenta barrier to effective clinicalcollaboration as well asEMR migration PITO & GPi

13. Why this Project? • To address this issue, PITO sought the development of a strategy to establish – by adoption, adaptation or, if necessary, development –a specification to support: • Transfer of data when a physician changes from one EMR system to another (“Conversion”); • Transfer of data when a patient moves from one family physician to another, or one long-term specialist physician to another; e.g. a diabetic transferring from one endocrinologist to another (“Transfer”); and • Transfer of data with a referral or consult request and report, to populate or update the records of the receiving physician (“eReferral”). PITO & GPi

14. Phase I – Environmental Scan: Options & Recommendations Phase II – Collaborative Specification Development Phase III – Implementation: Pilots, Vendor Incentives, etc. What did we do? PITO & GPi

15. Phase I – Environmental Scan:Options & Recommendations • Option analysis report • Initially completed in Early 2011 / Refreshed October 2011 • Environmental Scan • Reviewed key specifications • Alberta's ToPD and CoPDspecifications (collectively referred to as TCoPD); • Vancouver Island Health Authority's Electronic Medical Summary (e-MS); • The Data Portability Requirements (Appendix B) of OntarioMD's Clinical Management Systems (CMS) Specification; • HL7's & ASTM International’s Continuity of Care Document (CCD) specifications; and • England’s National Health Service’s (NHS) GP-2-GP specification. • ASTM International was formerly known as the American Society for Testing and Materials (ASTM) • Other pan-Canadian Specifications including CIHI PHC and Infoway standards • Other initiatives (e.g. BC Interior Health “EHR Integration – CCD Standard for Results Distribution”) • BC Vendor and Stakeholder dialogue • Established key recommendations • Various recommendations pertaining to collaboration and engagement • Specific technical recommendations … PITO & GPi

16. Phase I – Environmental Scan: Options & Recommendations T/CoPD PITO & GPi

17. Phase I – Environmental Scan:Options & Recommendations • Key Take-Away Points • Beg, borrow and steal … but make “incremental” improvements • Take the best from other specs • Fix issues • Don’t invent things that don’t need inventing • Move forward • Think “platform and foundation” … Focus on today but build for the future PITO & GPi

18. Phase II – Collaborative Spec Development • Rapid Timeline • December 2011 – May 2012 • Full Collaboration • Established Clinical and Vendor Stakeholder Panels • Reviewed requirements with stakeholders based on specific subject areas • Adjusted Specification Strategy to focus on “document paradigm” – given practical advice from conversion experts, stakeholders and other key examples in the market place PITO & GPi

19. Phase II – Collaborative Spec Development • Tooling and Development • Briefly Assessed CDA tools including • TrifoliaWorkBench • Model Driven Health Tools (MHDT) for CDA • … but not … DECOR (Data Elements, Codes, OIDs and Rules) Infrastructure • Devised a prototype constraint tool for better control over the model and the output • Built Draft Specificationusing the tool PITO & GPi

20. Phase II – Collaborative Spec Development • Key Take-Away Points • Involve vendors / developers as early as possible • Use tools to improve the “state of the art” of building and publishing specifications • Consider a framework, such as CDA, which has adoption, market traction and – perhaps most importantly – provides an on-ramp that positions for “progressively deeper” data exchange over time! PITO & GPi

21. Phase III – Implementation • Initial Users • UBC/UVIC Primary Care Informatics LEAD Lab – also working with the BC Physician Data Collaborative PDC • Nanaimo Division of Family Practice eReferral Pilot • Prince George eReferralPilot • … others … PITO & GPi

22. A Consolidated CDA Specto support a range of use cases Positive developer feedback What is the result? PITO & GPi

23. Key Outcomes to cover • A “new” approach to CDA Development • … with a fairly comprehensive clinical content model. • Constructive early feedback from developers • … to allow change / improvement. PITO & GPi

24. Brief Detour – What is CDA … • The Clinical Document Architecture (CDA) is: • a document markup standard for the structure and semantics of an exchanged "clinical document". • documentation of observations and other services. • A CDA document is a defined and complete information object that can exist outside of a message, and can include text, images, sounds, and other multimedia content. • CDA hits the “sweet spot” – CDA encompasses all of clinical documents. A single standard for the entire EHR is too broad. Multiple standards and/or messages for each EHR function may be difficult to implement. CDA is “just right”. • Implementation experience - CDA has been a normative standard since 2000, and has been balloted through HL7's consensus process. CDA is widely implemented. • Gentle on-ramp to information exchange - CDA is straight-forward to implement, and provides a mechanism for incremental semantic interoperability. • Level 1 – Structured Header + Blob • Level 2 – Structured Header + Sections • Level 3 – Structured Header + Structured Sections • Improved patient care - CDA provides a mechanism for inserting evidence-based medicine directly into the process of care (via templates), making it easier to do the right thing. Heavily abridged from HL7 Materials! PITO & GPi

25. A Use-Case-Driven, Canadian focused Consolidated CDA Spec • Uses the HL7 Clinical Document Architecture (CDA) template model • Forces consistency across several “document” specifications that are intended to support a variety of uses cases including EMR-to-EMR conversion, Patient Transfer, and other diverse data exchanges via either a General Episodic Document or an Unstructured Document (e.g. PDF). • Adheres to the latest global best practice in thestructure and design of Clinical Document Architecture (CDA) specifications • Leverages the style approach used by the IHE / HL7 Consolidated CDA guideemerging from the US Health Story project (http://www.healthstory.com/index.html) • Establishes explicit, testable conformance criteria. • See http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258 • Follows HL7 RIM to offer a degree of consistency with pan-Canadian standards • Note that this is imperfect given compatibility issues between CDA R2 and message based specifications) • Tooling driven for precision, comprehensiveness, and traceability! PITO & GPi

26. That is Tooling-Enabled … • Precision  • Maintainability  • PresentationFlexibility  Text Segments Tooling • Guide structure • Templates • Constraints • RoseTreeLinkedVocabulary • ImplementationspecificValue Sets • Etc. IG Data Fully Generated Formal Structure PITO & GPi

27. That covers a broad range of EMR content … • Advance Directives [42348-3] • Alerts • Allergies & Intolerances - Reaction List [48765-2] • Appointments & Scheduling [56446-8] • Billing • Care Plan / Reminders / Tasks [56851-9] • Clinically Measured Observations • Current Medications • Developmental Observations • Devices [46264-8] • Encounter History & Notes [46240-8] • Family History [10157-6] • Immunizations List [11369-6] • Investigative Procedure History • Laboratory Results & Reports • Medical History [11348-0] • Medical Imaging Results & Reports • Medications & Prescriptions - Medication List • Orders & Requests • Problems & Conditions - Problem List • Purpose • Reproductive Observations • Risk Factors [46467-7] • Surgical Procedure History [10167-5] • Treatment History • Specific document templates defined: • EMR Conversion Document • Patient Transfer Document • Generic Episodic Document, and • Unstructured Document • e.g. container for other content such as PDF. First two are targeted at the respective use cases. The last can be used to support any process (e.g. eReferral). • These document specs build on a library of common Section, Section Entry, Entry and Data Type templates … Section Templates PITO & GPi

28. … and tries to follow best practices of alignment and precision … • Header aligned with (but slightly expanded from) BC Interior Health specification - a parallel project covering a different set of use cases • Consistently enumerated, testable Constraint Statements against the formal CDA R2 model • Explicit Vocabulary Bindings that leverage HL7, Infoway/Standards Collaborative & (soon) PHC RefSets through integration • Purposeful use of formal conformance language while retaining developer friendly tabular views • Integrated XML examples • Comprehensive cross-referencing and “hot links” PITO & GPi

29. Initial Learning • LEAD Lab Feedback • Pinpointed challenges to certain parts of the specification • Many QA points but also some issues; key among these was “Medication” model and gaps in various vocabulary areas • Billing data exchange is likely an unexpected gap • Nanaimo Feedback • Level 1 only … with minor changes identified to header • Works … and is almost live in production! • Other Realities • The world has moved forward with the introduction of, for example, PHC RefSets … PITO & GPi

30. What’s Next? PITO & GPi

31. Next Steps? • Specifications are available through PITO web site • a Revision that addresses feedback from early adopters and adds new terminology details will be published shortly together with “test/sample” documents • Technical support mechanism for vendors has been established • additional funding for vendor implementation has been established • Initial projects are continuing and … • There are currently 4-6 eReferral Pilots in the early stages of implementation that will further leverage and test the specifications PITO & GPi

32. Acknowledgements • PITO Oversight • Jeremy Smith • Carol Rimmer • Clinical Panel • Anita Basic • Dr. Rob Carruthers • Dr. Bill Clifford • Dr. Bruce Hobson • Cathy Korn • Trina Langille • Dr. Willie Pewarchuck • Dr. Andre du Toit • Dr. Andre de Wit • Phase II Vendor Participants • Rachel Barker (Intrahealth Canada Limited) • Shamir Mithani (Intrahealth Canada Limited) • Jack Pannekoek (Med Access Inc.) • Toni Foster (Osler Systems) • Sean Hillier (Wolf Medical Systems) • GPi Team • Marc Koehn • Helen Stevens • Iqbal Sian • Patrick Loyd • Dr. Karim Keshavjee • Dr. Ahmad Zbib • Dr. Ray Simkus • Bradley MacDonald PITO & GPi

33. More Information? Marc KoehnGordon Point Informatics Ltd.Marc.Koehn@GPInformatics.com +1-250-216-0803 Carol Rimmer BC Physician Information Technology Office Carol.Rimmer@pito.bc.ca +1-604-638-5775 gordon pointinformatics www.gpinformatics.com PITO & GPi

34. Guide Examples Appendix PITO & GPi

35. Specification Overview Clear guidance on what sections a particular type of document MAY, SHOULD or SHALL contain Indicates the whether a section SHALL, SHALLNOT or MAY be included. Indicates the type of section template that SHALL, SHOULD or MAY be applied Example template Object Identifier (OID) in a conforming document instance. Constraint statements shown are illustrative only PITO & GPi

36. Specification Overview Consistent Formats for all templates Developer Friendly tabular view Hot linked, formal constraint statements Hot linked, formal vocabulary bindings Constraint statements shown are illustrative only PITO & GPi

37. Specification Overview • Linked vocabulary • Consolidated, developer-friendly view showing key info (e.g. OIDS) • Guides can include all, none or a sample set of values based on a simple field in the tool Sample PITO & GPi