360X Closed Loop Referral Project
Transport Workgroup
Wednesday, September 19, 2012
2PM
Meeting Minutes

Sab first introduces the transport workgroup definitions and outlines each.

Discussion around point #1 (The definition of Transport and Message Content (free form versus
discrete elements) and the role of DIRECT as a deployment strategy, level of maturity):
o
o
o
o
o
o
o
o
o
o
o

Thoughts about the role of transport and what it is required to do; are there direct
implications from the application level, in terms of information content?
Whether or not to separate the application content from the transport function: Sab polls
the group.
By definition, use transport workgroup as vehicle from moving payload from point A to
point B and ensure integrity from end-to-end.
Clarification: will we take the instance of multiple documents as part of the workgroup or
is it too high-level?
Integrity of documents with a Direct message is already covered by Direct specifications;
there is a signature for this aspect.
Therefore, how will we encapsulate these messages in a way that they can be
reconstructed on the other end and be delivered to EMR end point reliably?
How will it be recognized if any documents/messages are missing?
Reference upon use case of when sender makes an error, email is sent without both
documents. Whether or not to send another email with the missing document, or resubmit
each document.
Next step pertains to the recipient and how they reconcile more than one message with
potentially overlapping documents, and how this allows for complete care by provider.
Ultimate there is a consensus that an extra flag is necessary if something is a new
package, an update, an addition, or a replacement to a previous package. Sender is
responsible to a unique container ID for that package.
CONCLUSION: Implementation guide must address means to discern that information
from point to point is complete, without getting too far out of scope and into payload
workflow discussion.
Discussion around Direct being used as the transport means and point #2 (The definition of
failure and failure modes, what defines a payload, its history, loss due to circulation error or
absence of recipient):
o
o
o
o
o
o
If Direct is used, all documents are then put on one message and transported to other
side as one payload.
Questions arise as how the recipient will know that the message is complete?
Suggests leaving this up to Content and Payload Workgroups to decide what content
should be within this message.
As transport layer, we are only responsible for the transport from one end to another.
Attempt to draw lines between payload and transport.
Suggestion: the recipient, upon receiving EHR and notices missing information, sends
response back to sender – again this concludes to be a Content Workgroup issue.
If Direct is used, there will be no missing information. Entire message is verified upon
receipt, if signature fails than it will be automatically returned. Therefore, Direct will
compensate for this concern.
o
o

The discussion builds off of the Direct issues and into point #3 (The topology of message flow
(desktop > HISP > HISP> desktop) or (desktop > HIE > HISP > HISP > HIE > desktop), with
HISP pass through once CA/RA is established per S&I Framework):
o
o
o
o
o
o
o
o

Implementation guide for notification of delivery – explicitly addresses all of these
concerns and should be reviewed.
Next steps after accepting Direct as method: expecting an encapsulated message with a
header and a trailer. The header tells what routing codes are to be to pass directly
through the network from HISP to HISP. The trailer is simply the ending of encapsulated
message to ensure that the contents that have been transmitted have been received.
Direct protocol focuses on this.
Sending into an organization as opposed to a desktop, it is different and will need to be
described.
Are we anticipating that the transport vehicle will have no manipulation of encrypted
content that has been encapsulated?
From HISP to HISP, yes this is anticipated. Direct protocol states that at the time that a
message is being processed, there is the security and trust process where it is encrypted
and signed. It is then moved over to the receiving HISP and does an inverse of the
security and trust process and validates signature (verifies that message was not
manipulated).
Issue: this implies that a HISP does a decrypt function and forces the payload to then be
in the clear and opens patient information an unauthorized user.
Clarification: from HISP to HISP, the message stays encrypted. Inside a HISP, however,
it can be decrypted. The role of the HISP is a Direct service provider, and one service is
taking a message and delivering to final endpoint. However, also has to do security and
trust. Once inside the HISP, is it decrypted and then delivered to final destination. Still,
HISPs are HIPAA-bound entities.
Discussion branches off into HIPAA laws clarification in relation to HISP connectivity.
Clarification that HISP does not have right to “look” at HIPAA-confined data.
Discussion branches off into HISP purpose clarification: HISP is hired to decrypt and
encrypt information; EHRs will eventually be able to have this functionality, but currently
do not.
This stems back into argument on Direct; confusion over breach of trust and poses
concerns about whether Direct should be used as the transport.
Paul intervenes and suggests that within this context, see the HISP as a hosted security and trust
agent; run as a hosted model in which functionality is distributed and there is a secured channel
in which EHR can connect.
o The discussion around someone doing something nefarious is inconsistent.
o Group still maintains some level of concern around this security breach discussion.
o Sab leaves the discussion open for next week to move on from point #3.