360X Closed Loop Referral Project
Transport Workgroup
Wednesday, October 10, 2012
2PM
Meeting Minutes

Last week we left off discussing trust anchors and trust bundles, and the best practice for
distribution.

Greg picks up the trust anchor discussion from last week:
o
o
o
o

What are the administrative processes with doing exchange of trust anchors?
These decisions are made based off process between organizations making decision to
trust one another based upon agreed upon policies/practices.
How do you actually do an exchange of trust anchors? Directtrust.org and similar
organizations is working towards recommendations this.
Greg concludes by explaining that this exchange must be secure and needs to be
qualified – i.e. secure STP sites or areas of webpages to download from.
Greg opens the floor to other ideas on this point:
o
o
o
o
o
o
o
o
o
o
o
o
o
Sab summarizes last week’s discussion as being between the use of the org cert and the
use of individual certs. The concern was raised that if you have an org cert between
HISPs, then routing to an individual in an HIE behind the HISP could be difficult – so, how
would this be accomplished?
Greg explains that there is a discovery process but to his knowledge, certs are not
involved in the routing process.
Sab clarifies his question on routing: If you have organizational cert and the HISP is
turning this over behind the HIE, since org cert doesn’t have definitive email address of
recipient, is there an intervention within the HIE that can alter the payload?
Dr. Miller seeks clarification on if this use case is EHR to EHR – that could be EHR A to
HISP A -to HISP B to EHR B example.
Sab agrees on this definition of the use case, but when you get to the EHR, is that a
trusted partner and is the destination address authenticated? If so, is it electronically or
by paper?
Dr. Miller explains that it is whatever authentication process would be the same for the
organization and all providers in EHR.
Sab explains that the problem is if you don’t have individualized cert, then it’s impossible
to send an attachment in an email via transport vehicle to end user because you can’t
discern who end user is.
End point is EHR and EHR has an organizational cert for the practice. The plan is to send
it to a department or an individual, but each doctor would have separate address and cert
but also org cert.
Sab agrees and says working HISP to HISP and only receiving org cert at sender end,
and have email address for recipient, it’s impossible to attach email front end for the org
cert. The certs appear to have different information.
Greg seeks clarification on basic process the org cert has within routing process.
Sab explains in org cert you do not have destination address on the front end.
Greg explains that this isn’t how Direct works.
Sab explains that any intervening operating environment behind a HISP has to decode
any information with respect to header/transport, and then the integrity of the message is
altered and a risk for breach is created.
o
o
o
o
o
o
o
o
o


Greg explains that this will come up when we discuss edge protocols.
Peter explains that there needs to be a distinction between Direct and HISPs – if you look
at Direct implementation consensus of 2010 there are many examples, but they all
should be interoperable.
Bringing up a business layer mechanism, i.e. HISP, which is not interoperable with Direct
individual certs, this breaks interoperability. Only way to get it back is to decrypt a
message that has been encrypted: not possible.
Paul explains the difference is that the provider has a relationship with the org that is
doing this work on their behalf. Example: an admin assistant opening a letter and giving it
to them.
Sab explains that feedback from providers indicate they don’t want this information to be
handled this way. If any info in the payload that deals with protected information, it
becomes a legal violation.
Dr. Miller clarifies that what we are discussing is once it gets to the edge system. At the
edge system, a lot of admin activities happen based on information in the message.
Providers themselves do not do these activities and expect that this would have
happened before information reaches them.
Sab suspects that once the edge system receives encrypted payload and does the
decrypt function, then this has changed the integrity of the message.
Dr. Miller explains that once it reaches the EHR it becomes decrypted then there are
admin functions that are assigned by oversight with security passwords.
Sab further explains that using a paper process of trust to justify an implementation
increases the risk of a breach.
Paul intervenes in the conversation:
o
o
o
o
o
o
o
o
o
o
o
o
o
Paul explains that Direct implementations should be able to interoperate with other
architectures that are equally acceptable but different.
As a baseline assumption for this project, working objective is to provide interoperability
based on existing standards.
It is not reasonable to say that one architectural model is or isn’t appropriate, this isn’t the
intent of the group. This conversation on Direct applicability statement is more in scope
for Direct project.
The process by which the certification of EHR technology will be possible allows for a
model to have stand-alone EHR with Direct capability, or the functionality can be
distributed.
Dr. Miller comments that calling trusted delegates doing admin functions in support of
patient care a breach is unacceptable.
There are certain workflows that have to be accounted for. As we have working model,
we know about a lot of these and that message needs to be encrypted.
Stephen seeks common ground. End-to-end encryption has one certain level of security.
Non end-to-end encryption has a different level of security.
Nobody is suggesting the HISP ever decrypts a message. I.e. it would be like UPS
opening a package.
That’s what a security and trust agent does – unpackages and repackages.
Dr. Miller specifies in their HISP this is only Meta data, not HPI. This is not true
elsewhere.
Transport standards specification must clearly articulate this so there is no
misrepresentation.
Dr. Beller explains that if in fact there is no decrypting in the HISP, there’s no reason to
enforce HIPAA. If it’s, encrypted this is random noise and you cannot get data out of it
except header information. So, you then with a HISP make sure they are HIPAA
compliant because handling non-encrypted data.
Paul agrees that there are cases in which data reaches HISP on behalf of provider and is
unencrypted. Whether this data is exposed through a web portal is based on
model/system integration, then it can be sent – it’s prepackaged.
o
o
o

Paul asks group where this leaves us with respect to this conversation:
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o

It is also possible for payload inside direct message to be encrypted. In terms of the
Direct functionality, where the security and trust agent resides is where this package is
undone. It is also possible for a given HISP to distribute functionality.
The point is where do you define the endpoint, and is that endpoint from the perspective
of the sender what they perceive it to be when they sent the message. Or what type of
trust was required in order to do this.
Sab explains that this gets back to acknowledgment and quality questions: who is
responsible for this?
Pushing all the way to local EHR system within provider, if that provider isn’t exercising
appropriate care, that data won’t be protected there. There is a point in which the sender
has to accept that the recipient is now in control to care appropriately for that data.
From an organizational certificate perspective: once it hits this orgs certificate, it’s their
responsible. There is a clear distinction between the HISP and the other side.
Once it crosses this boundary and is defined, it it’s the orgs responsibility.
Paul posits to extent in which receiver made the decision to do this work on their behalf,
i.e. admin assistant opening mail. This is ultimately the end point.
Direct is a technology that allows for this type of discussion, but the scope of this
workgroup doesn’t have ability to constrain or discuss this further.
Sab suggests that the standard for transport indicate that an individual cert at the edge
point must be the ack point so that the sender receives, from the recipient, a positive
acknowledgement. This is to ensure that we have trusted relationship from sender to
recipient.
Vassil explains that we cannot require individual certs within orgs of physicians. Sab
agrees and explains that it is not individual cert, but the end point of the EHR must have
mail server with individual cert.
Vassil seeks clarification that the point is that it’s not sufficient to know that the message
was delivered to edge point which is the receivers EHR system – there is necessity to
further specify actions that go beyond the knowledge that something was delivered.
Sab explains yes to ensure integrity of information and an acknowledgement that an
authenticated and authorized user received it.
Dr. Miller warns about proposing a workflow that would be dramatically different than
what is used today. I.e. fax -> admin -> ID patient in system -> schedule apt -> send to
physician inbox. These standards will dramatically affect workflow.
Sab agrees with workflow point, but explains that the knowledge of industry threats
should be used to propose standards and protocols that mitigate risks. Making systems
less secure is a major concern.
Vassil emphasizes that when the message is received by the EHR system it is signed for.
Sab asks what the sender gets back in return to demonstrate positive acknowledgement.
Dr. Miller explains that the sender may only want a message of failure, if it occurs, in
return.
Paul emphasizes being clear who recipient was and trust level it was sent at. I.e. if it was
sent to an org with an org cert and that’s all the available, that’s the granularity that you
will get.
Greg explains that we wrote specification to be generic with regard to workflows where
they can do what is appropriate.
It’s not when you’re sending to an org, it is to an address. In the encryption or trust
validation can be done with either and org or user certificate.
Paul explains that when you send the message, you won’t get a response in a more
granular key. Greg agrees.
Paul asks if this addresses concerns:
o
o
o
o
o
o
o
o
o
o
Dr. Beller questions if there is an org using and org cert, the sender would construct an
email with entire individuals address in email address and send to HISP; the HISP knows
by looking at address who the individual is within the org. Does the HISP then apply to
PKI and ship it off to that individual doctor in the hospital? Or to a device that loads it into
EHR?
Based upon when individual cert is received by the HISP – how does this take place?
Paul explains that it depends on the deployment model and the sender’s architecture.
Technically, according to Direct spec, what architecture is on recipient’s side is opaque.
Only see email address. It will get to the end point that is identified by the locater. As long
as there are trust requirements and policies to trust the recipient’s cert, it doesn’t matter
whether it’s org or individual.
Vassil further explains that part of Direct spec is that how the trust between the HISP and
the edge system and how the technology is implemented is completely left up to
implementation. No specification of how the message gets to the receiving system,
whether it is a mailbox or popup or etc. Direct is a transport protocol, but it is not email.
How the message is stored and received is implementation specific.
Is this subject to security assessment? Can it affect security of payload as it moves
around before end point?
This is called edge protocol and there are best practices/recommendations in the
document Paul distributed last week – Last Mile Transport.
It would be unrealistic to expect that the individual doctor at hospital Y would be able to
send an acknowledgment. It would just come from EHR itself that it was received and
forwarded.
This gets into very specific use cases. Greg explains that this point and ONC
specifications behind this can be discussed next week.
Paul agrees that higher level message delivery assurance in the context of today’s
discussion can be further addressed next week.