Secure HL7 transactions using Internet mail (Internet draft)

The document describes the applicability of the Internet standardisation efforts on secure electronic data interchange (EDI) transactions for Health Level-7 (HL7), an EDI standard for Healthcare used world-wide. The document heavily relies on the work in progress by the IETF EDIINT working group. It is in most parts a restatement of the EDIINTs requirements document and application statement 1 (AS#1) tailored to the needs of the HL7 audience. The authors tried to make the document as self consistent as possible. The goal is to give to the reader who is not a security or Internet standards expert enough foundational and detail information to enable him to build communication software that complies to the Internet standards. Even though the authors rely on and promote the respective Internet standards and drafts, they did not withstand from commenting on and criticising the work where they see upcoming problems in use with HL7 or other EDI protocols that have not been in the initial focus of the EDIINT working group. The authors make suggestions to add parameters to the specification of the MIME type for EDI messages in RFC 1767 in order to enhance functionality. The authors give use cases for a larger subset of disposition types and modifiers of message disposition notifications. One key issue where the document goes beyond the current EDIINT drafts is the concept of non-repudiation of commitment to an EDI transaction. Secure EDI transactions should be regarded as "distributed contracts," i.e. not only the sending and receiving of single messages should be non-refutable but also the connection between messages interchanges. In anticipation of this requirement HL7 usually requires a response message to be sent to acknowledge every transaction. The authors therefore have the requirement to securely couple an EDI response message to its request message. Given the current shape of RFC 1767 this is generally possible only if a response message is coupled with an MDN receipt and the combination of both signed by the responder. The document describes a protocol to bundle MDN and response that uses the MIME multi-part/related content type in RFC 2112.