Direct Project HITSC Presentation

1. Direct Project HITSC Presentation October 2010

2. Direct Project A project to create the set ofstandardsand services that with a policy framework enable simple, directed, routed, scalable transport over the Internet to be used for secure and meaningful exchange between known participants in support of meaningful use

3. Why Direct Project? Current methods of health information exchange are inadequate. Communication of health information among providers and patients still mainly relies on mail or via fax • Slow, inconvenient, expensive • Health information and history is lost or hard to find in paper charts Current forms of electronic communication may not be secure • Off-the-shelf e-mail clients do not encrypt information Meaningful use stages • Need to meet physicians where they are now • Both Direct and the current Nationwide Health Information Network model will be needed to support nationwide health information exchange

4. Direct Project Organization Implementation Group (60+ organizations, 200+ participants) Security and Trust WG Communications WG Documentation and Testing WG Implementation Geographies WG Reference Implementation WG Best Practices WG The Direct Project represents over 60 organizations and over 200 participants. • Members participate in the Implementation Group and one or more of 6 workgroups.

5. Close to 200 Implementation Group Participants in over 60 organizations • Alere • Allscripts • American Academy of Family Physicians • Atlas Development • Axolotl • CareSpark/MobileMD/Serendipity Health • Cautious Patient • Cerner • Clinical Groupware Collaborative • CSC • eClinicalWorks • Emdeon • Epic • FEI • GE • Google • Greenway Medical Technologies • Harris Corporation • High Pine Associates • HLN Consulting, LLC • IBM • ICA • Indiana State Department of Health • Inpriva • Intel • Kryptiq • LabCorp • Massachusetts eHealth Collaborative • MedAllies • Medical University of SC • Medicity • MedNet • MedPlus/Quest Diagnostics • Microsoft • Mirth Corporation • MOSS • NextGen • NIH NCI • NIST • NYC Dept. of Health and Mental Hygiene’s PCIP • Oregon HIE Planning Team • Redwood MedNet • RelayHealth • Rhode Island Quality Institute • Secure Exchange Solutions • Siemens • South Carolina SDE • Surescripts • Techsant Technologies • TN State HIE • VA • VisionShare

6. Direct Project High-Level Project Plan Aug 2010 Sept 2010 Immediate Next 90 Days Short Term 3 to 9 months Long Term 9 to 36 months Draft Specification Complete Transition to an SDO Ongoing Maintenance Initial Pilot Implementation Expansion of Pilots Wide-Scale Deployment Evaluation for inclusion by NHIN and ONC Endorsement Evaluation by HITSC HITPC Tiger Team Framework and Policy Review Feedback to NHIN Governance Feedback on initial lessons learned Ongoing Review and Feedback Immediate Initiatives Short Term Initiatives Long Term Initiatives

7. Direct Project Real-World Implementation Direct Project will be demonstrated in real-world pilots across the country MedAllies (NY) VisionShare (MN) Rhode Island Quality Institute (RI) Redwood MedNet (CA) Medical Professional Services (CT) CareSpark (TN) VisionShare (OK) • Direct Project is architected for rapid adoption by: • Thousands of hospitals • Hundreds of thousands of physicians • Millions of providers • Tens (or hundreds?) of millions of patients • Many other stakeholders in healthcare

8. Key Positive Lessons From Direct • Focused problem-solving around a particular business case drives engagement • Asking participants to commit to implementation and pilots drives positive behavior and focus • The policy tools at ONC's disposal work to engage industry broadly • Aligning federal partners, states with private companies generates more value than the sum of its parts • Open source reference implementations are a key tool to promote standards adoption by lowering the total industry cost to achieve the value chain • Communities are awesome things…

9. Key Improvement Lessons From Direct • Implementation group grew too large, too fast • In future, set the commitment bar even higher and have firm limits on number of participants • Driving to code and driving to implementation drive focus • Set earlier milestones to set work to code and pilot test • US HIT standards world has fundamental philosophical splits: E.g., quality first or liquidity first? • Define the problem better, get clearer about national priorities, establish shared policy context • Consensus is challenging • First two improvements would have helped • Choose your own adventure: trust the community OR establish independent trusted review

10. Direct: A test of “trust the community” • Pre-July “findings” • Need to support structured and unstructured content, often in the same transaction • XDR/XDS had implementation support in many modern EHRs • XDR needed modifications to separate transport metadata from content metadata • XDR and XDM has strong support for comprehensive content packaging with package-level metadata but we couldn’t expect the broadest range of providers to produce such packaging • Something more ubiquitous needed to support the broadest community of providers (strong support for SMTP + web-apps at the edge) • Trust model required relatively sophisticated approach to encryption and signatures (mutual TLS not sufficient)

11. Direct: A test of “trust the community” • In July, we had a choice of three alternatives: • XDR (SOAP) as backbone + SMTP/XDR at the edge • REST as backbone + REST/SMTP/XDR at the edge • SMTP as backbone + SMTP/XDR at the edge • After weeks of negotiation, community chose: • SMTP as backbone but XDR end to end if known support and trust model • SMTP and XDR at the edge • So…. • “Genius of the And” and triumph of the community? • Mushy middle and design by committee?

12. Measures of engagement • Since consensus, we’ve seen strong community engagement, as measured by reference implementation code commits, active edits to the wiki (less quantitative: energy in calls, active planning for pilots, etc.) • Significant announcements, seeing specifications built into EHR, HIE products and services • Interesting tests of both SMTP and XDR backbones

13. Answers to common objections • Choice of SMTP is a step backwards from structured content, HITSP-endorsed standards • Both SMTP and SOAP transport can carry structured (e.g., CCD, HL7 v2) OR unstructured content (e.g., text, PDF) • HITSP-endorsed XDR (over SOAP) and XDM (over SMTP) also carry content packaging metadata (i.e., package manifest) • SMTP means spam, identity spoofing, privacy risks, etc. • S/MIME gives strong assurance (with appropriate identity assurance and certificate issuance) in sender and receiver • S/MIME-based encryption means only intended receiver or authorized delegate can view PHI • Certificate distribution is a hard problem • Yes, but unavoidable without a centralized trust model • Mitigate through DNS distribution, HISP architecture (delegate encryption, verification duties) in the short term

14. Four Steps to Universal Addressing Successful implementation and adoption of Direct relies on four key steps. 1 2 3 4 Reference Implementation Pilot Demonstrations Vendor Adoption Policy Guidance Reference Implementation: Solid, simple set of code and strong documentation. Pilot Demonstrations: Successful incorporation of reference implementation and lessons learned which show that anyone can easily adopt Direct. Vendor Adoption: Base interfaces available for purchase and code and software installed in all HIT exchange products. Policy Guidance: Strong base for privacy, security, transparency standards lead to more tractable scaling for PKI, trust

15. Questions?