Connecting for Health: The Common Framework HIMSS’ RHIO Federation Webinar

1. Connecting for Health: The Common Framework HIMSS’ RHIO Federation Webinar Wednesday April 17th, 2006 Carol Diamond MD, MPH Managing Director, Markle Foundation Clay Shirky, Chair Connecting for Health Technical Subcommittee and Adjunct Professor, New York University

2. What is Connecting for Health? • Broad-based, public-private collaborative of more than 100 diverse stakeholders • Founded and supported by Markle Foundation,with additional support from Robert WoodJohnson Foundation • Purpose of Connecting for Health: To catalyze changes on a national basis to create an interconnected, electronic health information infrastructure to support better health and healthcare

3. Areas of Focus • Technology Standards and Adoption • Policy Framework for Successful Implementation • Role of the Consumer They all matter and they are all necessary

4. How Did We Get Here? • In June 2004 we released: Achieving Electronic Connectivity in Healthcare: A Preliminary Roadmap from the Nation's Public and Private-Sector Healthcare Leaders • The Roadmap defined a technical approach for health information exchange based on a set of foundational policy and technical principles • A key recommendation of the Roadmap was to test the “theory” in a real world setting

5. The Design Principles • Designed to safeguard privacy—imposed the requirement first and then designed the functional architecture • This approach is harder and requires resisting “if only” thinking. • It does not produce the easiest or simplest technical solutions • You can’t build first and worry about the policies later…

6. Connecting for Health Prototype Goals • Develop a policy and technical framework that enables information sharing to happen for high quality patient care while protecting the privacy and security of personal health information. • Identify what needs to be common for interoperability and what does not. • Design and develop the documentation and the materials for communities on issues such as access, control, privacy and security. • Share and disseminate broadly in order to continue to learn !!!

7. Who Developed the Prototype and the Common Framework? • Connecting for Health Steering Group • Policy Subcommittee: Co-Chairs Bill Braithwaite and Mark Frisse • Technical Subcommittee: Chair: Clay Shirky • Three communities and teams: • Boston: MA-SHARE and technical partner CSC • Indianapolis: Regenstrief Institute and Indianapolis Health Information Exchange (IHIE) • Mendocino: Mendocino HRE and technical partner Browsersoft, Inc.

8. What is the Common Framework? A secure nationwide health information exchange network will be enabled by the general adoption of a set of specific, critical tools, including technical standards for exchanging clinical information, explicit policies for how information is handled, and uniform methods for linking information accurately and securely.

9. Connecting for Health: Policy Principles Openness Purpose Specification Remedies Accountability Collection Limitation Security Data Integrity Use Limitation Individual Participation and Control

10. Connecting for Health: Technology Principles • Make it “Thin” • Avoid “Rip and Replace” • Separate Applications from the Network • Decentralization • Federation • Flexibility • Privacy and Security • Accuracy Common Framework, p.5

11. Common Framework, pp.8-10

12. Sample Technical Documents (T2)

13. Sample Policy Documents Sample policy language CFH Recommended policy From P8 – Breaches, p. 4 From M2 – Model Contract, p. 10

14. The Common Framework Resources • All materials available without charge at www.connectingforhealth.org • Discussion forum for registered users at www.healthit.ahrq.gov • Software code available from regional sites: Regenstrief, MAShare, OpenHRE • Email to info@markle.org

15. Clay Shirky Chair, Connecting for Health Technical Subcommittee

16. Design Principles • Decentralized • Federated • No “Health ID” • Bottom up and top down • Decoupled development • Scalable and evolvable • No 'rip and replace’ • Auditable

17. Architecture is Federated and Decentralized: Once records are located, health information flows peer-to-peer

18. The architecture supports point of care information sharing and population-based reporting

19. Three Standard Interfaces • Centralize record locations • Publish local record locations to RLS (Pink) • Query institution+MRN from RLS (Orange) • Retrieve clinical data directly from sources (Green) • Working Test Among Three Networks (MA, IN, CA)

20. Core Problem

21. Two Questions: “Where are records for Patient X, and how can I get them?” How Can Connecting For Health Standardize Among Various Actors, So Queries Will Be Interoperable?

22. Break the Problem Down • Location of Records • Disambiguation of Identity<>Record • Transport of Records • Aggregation of Records

23. 1. Location: Namespaces Problem of Global Uniqueness Globally Unique Institutions IDs + Locally Unique Record Numbers = Globally Unique Record IDs Examples: John.Smith@IBM.com HHS.gov/help.html GeneralHospital/MRN:457398457

24. 2. Disambiguation: Probabilistic Match on Demographics • Assume No National Health ID • Use Only Demographics / No Clinical Data • Design Standard Patient ID Form • Name/DOB/Gender/Zip/SSN/etc • HL7 2.4/3.0 • Extensible and Customizable • Pluggable Matching Algorithm • Optimized To Minimize False Positives

26. Patient Match • Incoming PID Fields Matched Against DB • Algorithm Tuned to Local Conditions • False Positives Tuned to < 1 in 100,000

28. 4. Aggregation: Architectural Flexibility MA Model Aggregation at the Client IN Model Aggregation at the Server CA Model Aggregation in the Network

32. What Is the NHIN?

33. NHIN: Network of Networks • A Sub-Network Organization (SNO): • Implements the Common Framework • Runs an RLS Internally • Provides an Inter-SNO Bridge for All External Traffic

34. NHIN: Network of Networks • A SNO Queries Other SNOs When It Knows: • An Institution Where The Patient Received Care • An Region Where The Patient Received Care • Same Query Formatted For All Remote SNOs • Only Need Location of ISBs

35. Applications Work With Standard Data

36. Authentication against specific entity

37. Patient demographic entry

38. Query options

39. Viewer results display

40. Viewer results display -- more

41. What is available?

42. Technical Documentation: 3 Categories • Background on Record Locator Service Design • Background on Data “Cleanliness” • NHIN Message Implementation Guide • Record Locator Service/Inter-SNO Bridge • Standards Guides • Medication History: Adapted NCPDP SCRIPT • Laboratory Results: ELINCS 2.0, with modifications • Test Interfaces: CA, IN, MA • Code base: CA, IN, MA