Modular Specification Project
Recommendations to the Direct Community
Minor Error Corrections and Clarifications
Office of the National Coordinator for Health Information Technology
Version 1.0
December 19, 2011
Prepared By:
ONC Specification Modularization Team
Contents
A.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Minor Error Corrections and Clarifications..................................................................................................... 3
1 .................................................................................................................................................................. 3
2 .................................................................................................................................................................. 3
3 .................................................................................................................................................................. 3
4 .................................................................................................................................................................. 3
5 .................................................................................................................................................................. 3
6 .................................................................................................................................................................. 3
7 .................................................................................................................................................................. 4
8 .................................................................................................................................................................. 4
9 ................................................................................................................ Error! Bookmark not defined.
10 ................................................................................................................................................................ 4
11 ................................................................................................................................................................ 5
12 ................................................................................................................................................................ 5
Change Log
Version
1.0
Date
12/19/2011
Changed By
Deloitte
Description
Initial documentation
A. Minor Error Corrections and Clarifications
1. 1
RTM 45
Applicability Statement for Secure Health Transport 2.6 Digest Algorithms
“STAs MAY support more secure Digest Algorithms, as listed as SHOULD+ in RFC 5751 section 2.2”
Comment: RFC 5751 section 2.2 is “SignatureAlgorithmIdentifier,” section 2.1 “DigestAlgorithmIdentifier” is the
correct reference for this statement.
2. 2
RTM 48
Applicability Statement for Secure Health Transport 2.7 Encryption Algorithms
“STAs MAY support more secure Encryption Algorithms, as listed as SHOULD+ in RFC 5751 section 2.1”
Comment: RFC 5751 section 2.1 is “DigestAlgorithmIdentifier,” section 2.2 “SignatureAlgorithmIdentifier,” is the
correct reference for this statement.
3. 3
RTM 51
Applicability Statement for Secure Health Transport section 3.0 Message Disposition Notification
“That is, even if disposition notification was not specifically requested, the STA MUST confirm receipt.”
Comment: Mod Spec added clarifying text “….the STA MUST confirm receipt with a disposition notification
message”
4. 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.
5. 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.
6. 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.
7. 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.
8. 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>mailto:entity1@direct.example.org</direct:from>
<direct:to>mailto:entity2@direct.example.org</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">
9. 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
headers are not available.”
10. 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.
11. 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
12. 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.