Mod Spec Phase 2 Recommendations for XD
Minor Error Corrections and Clarifications
4.
RTM 99
XDR and XDM for Direct Messaging 4.3 Transport conversion from SMTP to SOAP
“The Web Services address is used to identifier the SOAP endput for the XDR message.”
Comment: The Web Services address is used to identify the SOAP endpoint for the XDR message.
KW: Typo of identifier and endput - agree that these typo corrections are correct
JHall: Agree
5.
RTM 140
XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata
“confidentialityCode ….When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-150…”
Comment: The correct table to reference is table 2-151.
KW: Agreed
JHall: Agree
6.
RTM 143
XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata
“formatCode…. Implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-152…”
Comment: The correct table to reference is table 2-153.
KW: Agreed
JHall: Agree
7.
RTM 144
XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata
“healthcareFacilityTypeCode…. When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-146…”
Comment: The correct table to reference is table 2-147.
KW: Agreed
JHall: Agree
8.
RTM 92, example
XDR and XDM for Direct Messaging 4.1 SOAP headers in support of addressing
<direct:addressBlock xmlns:direct="urn:direct:addressing"
env:role="urn:direct:addressing:destination"
env:relay="true">
<direct:from>[[1]]</direct:from>
<direct:to>[[2]]</direct:to>
</direct:addressBlock>
Comment: Mod Spec corrected typo in example
<direct:addressBlock xmlns:direct="urn:direct:addressing"
direct:role="urn:direct:addressing:destination"
direct:relay="true">
KW: I don't know.
JHall: I agree with the proposed correction of the namespace of role and relay from "env" to "direct". The remainder of the example containing the from, to, and close of addressBlock within the current XD spec are fine.
9.
RTM 106
XDR and XDM for Direct Messaging 4.4 Transport conversion from SOAP to SMTP
“The SMTP TO and RCPT FROM commands MUST carry the recipients and sender of the transaction, which SHOULD be taken from the SOAP header values, if available, or the metadata SubmissionSet.author and SubmissionSet.intendedRecipient values, if SOAP headers are not available.”
Comment:
- see comment A:4 for RCPT TO and MAIL FROM clarification
SubmissionSet.author maps to MAIL FROM and SubmissionSet.intendedRecipient maps to RCPT TO, however the values as written in the spec are in the wrong order. Implementers might inerperate the wrong mapping. Spec team included the following modification: “The RCPT TO and MAIL FROM commands MUST carry the recipients and sender of the transaction, which SHOULD be taken from the SOAP header values, if available, or the metadata SubmissionSet.author (for MAIL FROM) and SubmissionSet.intendedRecipient (for RCPT TO) values, if SOAP
KW: I can't comment on the change from SMTP TO=>RCPT TO or RCPT FROM=>MAIL FROM. Other than those changes the addition of the () remarks (for MAIL FROM) and (for RCPT TO) is a change I approve of.
JHall: The appropriate SMTP commands are "MAIL FROM" and "RCPT TO". I agree with the proposed modification.
10.
RTM 94
8.0 Examples ExampleA-simple-text-to-XDR.txt and ExampleB-attachment+text-to-XDR.txt
<a:Action s:mustUnderstand="1">
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
</a:Action>
Comment: The examples use the urn “urn:ihe:iti:2007:ProvideAndRegisterDocumentSet” but IHE Vol 2b Section 3.41 uses the value: "urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b” Mod Spec corrected the example so they use the value specified by IHE.
KW: Agreed
JHall: Agree
11.
RTM 106
XDR and XDM for Direct Messaging 4.4 Transport conversion from SOAP to SMTP
“The SMTP TO and RCPT FROM commands MUST carry the recipients and sender of the transaction, which SHOULD be taken from the SOAP header values, if available, or the metadata SubmissionSet.author and SubmissionSet.intendedRecipient values, if SOAP headers are not available.”
Comment: This passage implies that the SOAP headers are not required
KW: That is correct, the SOAP headers carrying this information are not required. The transport is always SOAP but the special headers added by this specification are not required.
12.
RTM 95
XDR and XDM for Direct Messaging 4.3 Transport conversion from SMTP to SOAP
“Addressing lists MUST be taken from SMTP TO and RCPT FROM SMTP commands.”
RTM 106
XDR and XDM for Direct Messaging 4.4 Transport conversion from SOAP to SMTP
“….The SMTP TO and RCPT FROM commands MUST carry the recipients and sender of the transaction…”
Comment: "SMTP TO" and "RCPT FROM SMTP" are not mentioned in the underlying RFC specifications (RFC 5321). The examples in the Direct specs include:
“MAIL FROM: <drjones@direct.sunnyfamily.example.org>
RCPT TO: <drsmith@direct.happyvalley.example.com>”
The Spec Team received the guidance “RFC's have the RCPT TO and MAIL FROM commands which is what should be used.” The Mod Spec includes the corrected commands in requirements 95 and 106.
KW: I don't know.
JHall: I agree that these references need correction. The appropriate SMTP commands are "MAIL FROM" and "RCPT TO".
General Recommendations
4. confidentialityCodes
RTM 140
XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata
confidentialityCode : “Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., ETH, HIV, PSY, SDV)”
Comment: The list of codes is not exhaustive but may be interpreted as exhaustive by implementers. The Mod Spec appended the list (e.g., ETH, HIV, PSY, SDV, etc) to convey that this is not the complete list.
KW: I disagree, e.g. is "for example" and implies an incomplete list. Adding etc. is confusing in an example. Suggest that you change "e.g." to "for example" to help those who don't understand what e.g. means. If this is still not enough we could say instead "for example, avoid using codes similar to ...)
JHall: KW's points and suggestions are valid.
5. Optionality of XDR/XDM Conversions
RTM 90
XDR and XDM for Direct Messaging 3.0 Interaction Patterns
“The following table shows the cases of conversion that SHALL be performed. {conversion table}”
Comment: The use of the word SHALL implies that an organization needs to implement all 6 conversions to be compliant with the spec. This was left as-is in the Mod Spec, but implementation guidance was added that conversions were dependant on an implementer’s individual use cases.
KW: Need more detail, can you provide examples of a conversion listed that would not be required in a individual use case?
7. uniqueId and sourceID should be a UUID that is FORMATTED as an OID
RTM 152 (document entry) and 161 (submission set)
XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata and 6.2.2 Submission Set Metadata
uniqueID “Implementations SHOULD use a unique ID extracted from the content, if a single such value can be determined. If not, implementations SHOULD use a UUID URN, generated for the transaction. This value must be different than the uniqueId specified on the Document.”
RTM158
XDR and XDM for Direct Messaging 6.2.2 Submission Set Metadata
sourceID “Implementations SHOULD use a UUID URN mapped by configuration to sending organization”
Comment: During the Mod Spec process, NIST raised the point that IHE requires the uniqueID and sourceID to be an OID while the Direct specs require uniqueID and sourceID to be a UUID. During a call with members of the Direct community on 10/25/2011 consensus was reached that uniqueID and sourceID should be a UUID formatted as an OID.
We added the additional highlighted text in our RTM: “… SHOULD use a UUID URN formatted as an OID….”
KW: Agreed
JHall: Agree
8. IHE Supplement - Metadata-Limited Document Sources
RTM 173, 174
XDR and XDM for Direct Messaging 6.2.1 Document Entry Metadata and 6.2.2 Submission Set Metadata
Comment: The IHE supplement for Metadata-Limited Document Sources includes a new attribute limitedMetadata which “Indicates whether the Document Entry was created using the less rigorous requirements of metadata as defined for the Metadata-Limited Document Source. The Document Entry is flagged using an ebRIM Classification with a classificationScheme of urn:uuid:ab9b591b-83ab- 4d03-8f5d-f93b1fb92e85.”
Mod spec created two new requirements to include limitedMetadata in the Document Entry and Submission Set Metadata definitions.
The supplement can be found at [3]
KW: Agreed
9. IHE Change Proposal 524 – authorTelecommunication
RTM 162
XDR and XDM for Direct Messaging 6.3 Special Considerations and Extensions
Comment: The CP provides a place for a telecommunications address for the sender and receiver in the metadata through the authorTelecommunication attribute. Mod Spec made reference to this CP in our underlying specs section.
The CP can be found at [[4]]
KW: Agreed
10. Message signing and encryption
RTM 34 - 48
XDR and XDM for Direct Messaging 2.4 Signed and Encrypted Health Content Containers
Comment: This section does not explicitly state that a message must be encrypted and signed from the Direct system point of origin to the Direct system recipient. The MDN section of the spec explicitly states that a MDN must be encrypted. Spec team added the requirement “All messages MUST be signed and encrypted, from the original message sender to the original message receiver.”
KW: I don't know.
JFM:There is no way to change the transport/messaging technology and still use transport/messaging encryption in an end-to-end way. S/MIME is a totally different cryptographic bundling than TLS/SOAP/WSS. Therefore the ‘intermediary’ that does the conversions must be trusted to not inspect or copy the content when it is decrypted. (Note this is very similar to what happens inside a full-service-HISP). The security model on either side is defined by the technology choice. Yes the XDR side should use appropriate secure transports according to the deployment model used (just like on the client side of a full-service-HISP). In my view the Direct-to-XDR is just another HISP specification, where what the HISP does outside of the Direct communication is ‘inside-the-box’. Hence why the Direct-to-XDR should focus only on the conversion and not on the continued transport inside of XDR space.Note if end-to-end security is truly desired, then I would recommend the IHE-DEN profile. It does encryption in a totally transport independent way..
11. Conversion requiring ‘more significant metadata'
RTM 135 & IG
XDR and XDM for Direct Messaging 6.1.2 Minimal Metadata Definition
The use of Minimal Metadata is required when converting from a transport with minimal metadata, RFC 5322 without an XDM attachment, to a transport requiring more significant metadata. Conversion in the other direction retains all the metadata available by coding the content in an XDM package where the receiver can ignore the metadata if preferred.
The use of minimal metadata covers the following cases:
The system creating the XDR/XDM transaction does not have access to full XDS metadata, including cases where
The original content was created with a system that does not store all relevant metadata items as discrete values (e.g., e-mail client sending a text message with PDF attachment)
The original content was received by the XDR creating system encrypted
The system creating the XDR/XDM transaction is not able to or by policy prefers not to examine the content to construct available metadata
The content payload does not conform to XDS Metadata expectations, including cases where:
The payload is not patient specific (e.g., summary level quality reporting)
Comment: In this case, a “transport requiring more significant metadata” can only be SOAP+XDR as there is no conversion required between MIME and XDM. Following SME guidance, the Mod Spec called out conversion to XDR as the only transport requiring more data. The highlighted XDM references were removed and the following text was added “…..to a transport requiring more significant metadata, SOAP+XDR.”
KW: XDM needs the same level of metadata as XDR so I don't agree with your SME. Perhaps I am missing something.
Language clarification
1. ‘STA v. Implementation’
Applicability Statement for Secure Health Transport, general
XDR and XDM for Direct Messaging, general
The Applicability Statement for Secure Health Transport Spec defines Security/Trust Agent (STA) as a “Message Transfer Agent, Message Submission Agent or Message User Agent supporting security and trust for a transaction conforming to this specification.” Many of the requirement statements in the spec reference the STA by name.
The XDR and XDM for Direct Messaging spec does not mention the STA at all. Instead its requirement statements include reference to "Implementations." The term implementation is not defined.
Comment: It is unclear if the terms STA and Implementation are intended to be the same entity (the Mod Spec interpreted them to be the same entity). It may be confusing for an implementer if consistent terminology is not used in both specs or an explanation is not provided describing the differences.
KW: I don't know.
JFM: The XDR and XDM for Direct messaging didn't differentiate between the different component parts as it was unnecessary to expose internal architecture. I would recommend some term be defined for the thing that is executing the XDR and XDM for Direct Messaging conversions. This could be the word 'Implementation'.