Connecticut Ave NW, Washington, DC September 30, 2014 David C. Kibbe, MD MBA President and CEO, DirectTrust Luis Maas, MD PhD CTO, EMR Direct Co-Chair, DirectTrust Security and Trust Compliance Wg

Connecticut Ave NW, Washington, DC Agenda for the webinar Overview and context Challenges to Direct exchange interoperability – Policy and trust issues: who is in the trust community, and who is not, and why or why not? – Transport standard issues: what is required, what is optional, and why does this matter? – Message notification issues: why are they needed? – EHR-specific protocols and policies: how do these create interoperability challenges? Discussion

Connecticut Ave NW, Washington, DC We’re here to improve health care, through better coordination and communication. 2. Any technology that enables electronic health information to be exchanged across organizational boundaries and IT system barriers is a form of interoperability. 3. Security, security, security… We cannot afford to fail to protect personal health information before, during, and after transmission over the Internet. Why are we here?

Connecticut Ave NW, Washington, DC Things have been moving very, very fast April 2010  Direct Project launched  Goal: simple, secure, scalable, standards-based way to send health data over the Internet April 2011  Applicability Statement published  “Rules of the Road” Workgroup started  HIEs charged w/ Direct Feb 2013  EHNAC-DirectTrust accreditation program starts  Stage 2 MU program to require Direct in all EHRs by 2014 Mid 2014  DirectTrust HISPs provide service to >28,000 HCOs and provision over 420,000 Direct addresses Direct = secure, identity validated, vendor/app neutral messaging + content May 2012  DirectTrust incorporated as non-profit trade alliance, 501(6)(c)

Connecticut Ave NW, Washington, DC DirectTrust’s membership has doubled in less than a year.

Connecticut Ave NW, Washington, DC DirectTrust’s membership has doubled in less than a year.

Connecticut Ave NW, Washington, DC And the DirectTrust network is growing exponentially

Connecticut Ave NW, Washington, DC Policy and trust issues ? The DirectTrust network is valuable to the extent its membership is voluntary and its members trustworthy. Accreditation and audit establish transparent, achieved security and identity controls, so that further one- off negotiations or contracts are unnecessary, avoiding delays and costs. Options for interoperable transactions via Direct increase at approx N 2 with each new HISP that joins the network. DirectTrust does not prohibit its members from further one-off negotiations and contracts, but network value diminishes with fewer options and more uncertainty.

Connecticut Ave NW, Washington, DC Potential solutions Make it easier and less expensive for organizations to deploy Direct exchange within the DirectTrust community. – Provider directories – Transparency and flexibility around ID proofing in health care Allow market forces to adjust pricing, value, and service. Continue to tolerate small number of one-off agreements. Educate parties as to value of network.

Connecticut Ave NW, Washington, DC Transport standard issues What are the permissible standards for transport of PHI within the 2014 Edition of Standards and Criteria? – Mandatory – “vanilla Direct” = SMTP + attachments = flat – Optional SMTP + XDM messaging format – ZIP archive as attachment, CCDA contained inside XDR - Transmission using SOAP-based transport INSTEAD of SMTP + attachments. Closely related to XDM; usually transmitted by EHR to an XDR-capable HISP and HISP converts to SMTP + XDM – Sender must use one of the certified methods for their EHR to attest – Certification to the optional transports may create disconnects if sender uses an optional method and recipient does not support it – This can create problems when providers attest regarding the 10% of transitions of care objective. – Some EHRs can’t interpret the received XDM messages

Connecticut Ave NW, Washington, DC MDN issues What are processed and dispatched MDNs? – Processed MDN is always required in Applicability Statement. Receiving HISP must send this back to sending HISP after verifying message integrity and trust. – Dispatched MDN indicates that the message has made it all the way to the EHR. Indicates “final delivery” to the intended recipient’s end system. Doesn’t indicate message has been read or understood. The problem: Dispatched MDNs were not made mandatory, and not all systems support them. – The specification requires that if a Dispatched MDN is requested by the sender and the receiving system does not respond to this request, then the sending system must mark the message as a failure, even if the recipient actually received it! – This is causing a lot of interoperability problems. Dispatched MDNs will be required within DirectTrust network by November, 2014.

Connecticut Ave NW, Washington, DC MDN issues How does variability in their use cause interoperability problems? – Requesting Dispatched MDN when recipient does not support – Not all systems support MDNs with NULL envelope sender – Variations in formatting can cause problems processing MDNs Are there quality or safety issues involved? What is reasonable certainty of receipt by intended recipient? – New Edge Protocol Guide: presumption of success; only notification of failures required. – Processed MDN allowable as proxy for final delivery

Connecticut Ave NW, Washington, DC EHR-specific policies Discuss effects on interoperability. NOTE: these are not DirectTrust issues, but they do affect interoperability. – Direct address capitalization: DT members committed to case insensitivity in the addresses. – MIME types for CCDAs: DT preferred practice is application/XML for sending, either application/XML or text/XML for inbound. – Requiring body AND attachment, not allowing one or the other. – Many systems expect a text part before a CCDA – Style sheets: it’s wild out there!! Discourage those that may increase security risk. More input needed from EHRs and their customers. Lessons from DirectTrust interoperability testing – Receive broadly, send narrowly

Connecticut Ave NW, Washington, DC Discussion Answers to questions for the audience: It’s always ok to send an unsolicited Dispatched MDN. DT preliminary recommendation: we’ll be asking our members to indicate in the message body that the message contains attachments. No formal list of EHR’s that have specific problems, such as case sensitivity requirements. But we do have a registry of known problems that people are experiencing. How does “receive broadly, send narrowly” relate to interoperability? – Example: Even if you send only application/xml, by allowing both application/xml and text/xml for incoming CCDAs, you will be able to interoperate with a much larger number of EHRs, since both types are encountered in the field. The meaning of both MIME types is (essentially) equivalent and there is no loss of security by accepting both. Does text body of the message need to be presented to the intended recipient, or just the attachments? Topic for discussion by SATC.

Connecticut Ave NW, Washington, DC Mission and Goals: DirectTrust 15 DirectTrust.org, Inc. (DirectTrust) is a voluntary, self-governing, non-profit trade alliance dedicated to the growth of Direct exchange at national scale, through the establishment of policies, interoperability requirements, and business practice requirements. DirectTrust operates under a two-year Cooperative Agreement with ONC to support its work of creating a national network of interoperable Direct exchange services providers. Security & Trust Framework EHNAC- DirectTrust Accreditation Programs Trust Anchor Bundle And Network Services

Connecticut Ave NW, Washington, DC Discussion David C. Kibbe MD MBA, President and CEO DirectTrust.org