Content Container Specification
Health Content Container
Status of this Specification
This specification is in version 1.0, and in in Workgroup Call for Consensus state.
- Updated June 2, 2010 - to point at the discussion thread on content manifest, and remove multipart/sign and multipart/encrypted is the purview of the concrete models and security/trust;
1.0 Endorsements
Content Specification Workgroup Endorsements
Content Specification Implementation Group Endorsements
Content Specification Other Endorsements
IPR Statement
By contributing to this specification, all contributors warrant that all applicable patient or other intellectual policy rights have been disclosed and that any of which contributors are aware of will be disclosed in accordance with the Direct project IPR Policy.
Abstract
This specification provides for a normative way to express envelope metadata and content packaging for information transmitted for NHIN Direct transactions. This specification constrains the normative representation of envelope and content metadata at the edges of transactions (e.g., at the Source to HISP and HISP to Destination sets of transactions in the Direct Abstract Model).
Table of Contents
Introduction
Purpose
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
Synopsis
A Health Content Container SHALL be an Internet Message Format document conforming to RFC 5322.
When explicitly creating a Health Content Container, the message body SHALL be:
When processing a Health Content Container, there are three levels of conformant processing for a Health Content Container:
- Basic processing, which MUST process simple content type bodies and multipart/mixed (where the main body part is multipart/mixed) content type message bodies, including base64 encoded body parts, and properly interpret the associated content type metadata (but need not understand all possible content types) as documented in this specification. Basic processors MUST follow the RFCs in understanding all other multipart not explicitly otherwise understood as multipart/mixed.
- Email processing, which MUST be able to understand a message sent over the ordinary email, including the de facto standard use of multipart/alternative for richtext/html formatted messages, and the de facto standard uses of attachments in ordinary email.
- XDS Metadata processing, which MUST interpret a multipart/mixed format where the body parts are base64 encoded compressed XDM files (XDM zip files)
Multipart is a recursive container specification, in that body parts may themselves be multipart messages. Notwithstanding that, Health Content Containers are RECOMMENDED to be flat, such that the multipart/mixed or multipart/related sections contain only simple content types, and conformant processors are NOT REQUIRED to interpret nested multipart body parts (except as specified for multipart/signed and multipart/encrypted, where the main body part will be a multipart content type). The RECOMMENDED method for transporting highly structured and nested sets of folders and documents is by means of XDM compressed files using the multipart/mixed message body.
Message Headers
The following message headers documented in RFC 5322 are required:
| Header |
Content |
Example |
| from |
Source addressee as a Health Internet Address formatted as an email address |
[[1]] |
| to |
Destination addressee asa Health Internet Address formatted as an email address |
[[2]] |
| orig-date |
As per RFC 5322 |
Thu, 8 Apr 2010 16:00:19 -0400 |
| message-id |
As per RFC 5322, left part constrained to be a GUID, right part the Heath Domain Name |
<db00ed94-951b-4d47-8e86-585b31fe01bf@nhin.sunnyfamilypractice.example.org> |
| in-reply-to, references |
As per RFC 5322 |
|
| cc |
May be used to indicate other addressees who received this exact message. Note that the Source, not the HSP, is responsible to send the individual message copies |
|
| MIME-Version |
Always "1.0" |
The use of other headers, both those specified by RFC 5322 and those commonly used by email clients is optional.
Content Metadata
The Content Metadata at this time is not mandated beyond the Message Headers, use of MIME, and recommendation for XDM packaging. For further discussion about the metadata about the contents such as a manifest see the discussion thread on the Content Package Metadata vs Content Package Manifest
Content Types for Health Data
NOTE: Treat these as placeholders until further review.
HL7 v2
application/edi+hl7
NOTE: is there a need to more precisely describe the HL7 message type (e.g., ADT vs MDM vs ORU vs etc.)?
application/cda+xml
application/ccd+xml
NOTE: is there a need to express the cda template and profile (e.g., HITSP C32)? Perhaps: application/ccd.c32+xml
CCR
application/ccr+xml
XDM compressed files
application/xdm+zip
IANA Considerations
Security Considerations
The Content Packaging attributes may be considered sensitive but are designed to be as minimal as possible and to allow for the use aliases. Further Security Considerations will follow the work of the Security and Trust Workgroup and further specification under the concrete models.
Examples
This section is non-normative.
---- Example of use of multipart/mixed ----
From: [[3]]
To: [[4]]
Date: Thu, 08 Apr 2010 20:53:17 -0400
Message-ID: <db00ed94-951b-4d47-8e86-585b31fe01bf@nhin.sunnyfamilypractice.example.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8837833223134.12.9837473322"
This text is traditionally ignored but can
help non-MIME compliant readers provide
information.
--8837833223134.12.9837473322
Content-Type: text/plain
Attached is a clinical summary from a recent visit for patient John Doe
located at 123 Main Street, Eagan, MN. John will be scheduling with you for
follow-up in relation to his complaints of frequent headaches.
--8837833223134.12.9837473322
Content-Type: application/ccd+xml; name="clinicalsummary-johndoe.xml"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="clinicalsummary-johndoe.xml"
<base64 encoded CCD XML file here>
--8837833223134.12.9837473322
Content-Type: application/pdf; name="clinicalsummary-johndoe.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="clinicalsummary-johndoe.pdf"
<base64 encoded PDF here>
--8837833223134.12.9837473322--
---Example use of multipart/mixed with XDM attachment ---
From: [[5]]
To: [[6]]
Date: Thu, 08 Apr 2010 20:53:17 -0400
Message-ID: <db00ed94-951b-4d47-8e86-585b31fe01bf@nhin.sunnyfamilypractice.example.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8837833223134.12.9837473322"
This text is traditionally ignored but can
help non-MIME compliant readers provide
information.
--8837833223134.12.9837473322
Content-Type: application/xdm+zip; name="johndoe-summary.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="johndoe-summary.zip"
<base64 encoded ZIP file here>
--8837833223134.12.9837473322
---Example use of multipart/signed----
From: [[7]]
To: [[8]]
Date: Thu, 08 Apr 2010 20:53:17 -0400
Message-ID: <db00ed94-951b-4d47-8e86-585b31fe01bf@nhin.sunnyfamilypractice.example.org>
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;
boundary="boundary-signed736223"
--boundary-signed736223
Content-Type: multipart/mixed; boundary="8837833223134.12.9837473322"
This text is traditionally ignored but can
help non-MIME compliant readers provide
information.
--8837833223134.12.9837473322
Content-Type: text/plain
Attached is a clinical summary from a recent visit for patient John Doe
located at 123 Main Street, Eagan, MN. John will be scheduling with you for
follow-up in relation to his complaints of frequent headaches.
--8837833223134.12.9837473322
Content-Type: application/pdf; name="clinicalsummary-johndoe.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="clinicalsummary-johndoe.pdf"
<base64 encoded PDF here>
--8837833223134.12.9837473322--
--boundary-signed736223
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
uhyHhHTujhJhjH77m4HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyG467GhIGfHfYT6jH77n8HHGgoyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhPGfHfYT6ghyHhHUujpfyF4
7GhIHfHfYT64VQbnj354
--boundary-signed736223--
Authors
References
Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119
Resnick, Internet Message Format, RFC 5322
Galvin et al, Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, RFC 1847
Levinson, The MIME Multipart/Related Content-type, |RFC 2387
Freed et al, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,RFC 2045
Freed et al, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,|RFC 2046
NHIN Direct, Health Internet Addressing, Addressing Specification
IHE, Distribute Document Set on Media, ITI TF V2b section 3.32.4.1.2, [9]
Copyright
By contributing to this specification, all contributors agree to license contributions according to the Creative Commons Attribution 3.0 License which is incorporated into this document by reference.