Skip to main content

Secure HL7 Transactions using Internet Mail

Document Type Expired Internet-Draft (ediint WG)
Expired & archived
Authors Gunther Schadow , Mark Tucker , Wes Rishel
Last updated 1999-06-15
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Expired
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


This memo describes the applicability of the Internet standardization efforts on secure electronic data interchange (EDI) transactions for Health Level-7 (HL7), an EDI standard for healthcare used worldwide. This memo 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. We tried to make this 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 we rely on and promote the respective Internet standards and drafts, we did not withstand from commenting on and criticising this work where we see upcoming problems in use with HL7 or other EDI protocols that have not been in the initial focus of the EDIINT working group. We make suggestions to add parameters to the specification of the MIME type for EDI messages [RFC 1767] in order to enhance functionality. We give use cases for a larger subset of disposition types and modifiers of message disposition notifications. One key issue where this memo 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. We 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 combi


Gunther Schadow
Mark Tucker
Wes Rishel

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)