DirectTrust All Members Meeting

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
1101 Connecticut Ave NW, Washington, DC 20036
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
1101 Connecticut Ave NW, Washington, DC 20036
Why are we here?
1. 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.
1101 Connecticut Ave NW, Washington, DC 20036
Things have been moving
very, very fast
Direct = secure, identity validated, vendor/app neutral messaging + content
April 2010
April 2011
May 2012
Feb 2013
Mid 2014
 Direct Project
 Goal: simple,
secure, scalable,
way to send
health data
over the
 Applicability
 “Rules of the
Road” Workgroup
 HIEs charged
w/ Direct
 DirectTrust
incorporated as
non-profit trade
alliance, 501(6)(c)
 EHNAC-DirectTrust
program starts
 Stage 2 MU
program to
require Direct
in all EHRs
by 2014
 DirectTrust HISPs
provide service
to >28,000 HCOs
and provision
over 420,000
Direct email
1101 Connecticut Ave NW, Washington, DC 20036
DirectTrust’s membership has doubled in
less than a year.
1101 Connecticut Ave NW, Washington, DC 20036
DirectTrust’s membership has doubled in
less than a year.
1101 Connecticut Ave NW, Washington, DC 20036
And the DirectTrust network
is growing exponentially
1101 Connecticut Ave NW, Washington, DC 20036
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 oneoff negotiations or contracts are
unnecessary, avoiding delays and costs.
• Options for interoperable transactions
via Direct increase at approx N2 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.
1101 Connecticut Ave NW, Washington, DC 20036
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.
1101 Connecticut Ave NW, Washington, DC 20036
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 email
– 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
1101 Connecticut Ave NW, Washington, DC 20036
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.
1101 Connecticut Ave NW, Washington, DC 20036
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
1101 Connecticut Ave NW, Washington, DC 20036
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
1101 Connecticut Ave NW, Washington, DC 20036
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.
1101 Connecticut Ave NW, Washington, DC 20036
Mission and Goals: DirectTrust, 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
1101 Connecticut Ave NW, Washington, DC 20036
Trust Anchor
And Network
David C. Kibbe MD MBA, President and CEO
[email protected]
1101 Connecticut Ave NW, Washington, DC 20036

similar documents