Media-types for various message formats

This is a page of type Category:InM Closed Action Items.

• Working group: InM
• Author: --[User:Alexander Henket|Alexander Henket] 11:02, 22 December 2008 (UTC), on behalf of NICTIZ, the Netherlands.
• Status: FINAL - for discussion at Orlando 2009

Summary

HL7v2, and HL7v3 messages/documents should have IANA media-types. These media-types are necessary when referring to or attaching these messages to other messages, and can be useful in routing the messages itself through certain systems such as mail systems, but this is not the primary goal. This is a long running issue that has not received closure. Because this issue was never really closed, implementing parties have each come up with their own solutions over the years. This has lead to undesired growth in the number of possibilities one has to deal with when you are operating in multiple environments. This proposal seeks to:

• get definitive consensus within InM on getting official media-types for various HL7 message types
• be input for an InM work item to get the outcome of this proposal registered at IANA

Use case

Media-types are necessary in these circumstances, among other:

• HL7v2: ED data type
• HL7v3: ED data type
• MIME encoded attachments

Background

Media-types have been debated since at least 2000. Most of the debate goes into the granularity of those media-types. I.e. do we say "text/xml", or do we say "application/hl7v231-ORUR01". See also HL7 list threads 1 and 2.

There are no IANA registered types for any HL7 message/document types, so the only existing types are:

• multipart/x-hl7-cdalevel-one for HL7v2 ED data type (introduced in version 2.4, retained for backward compatibility since version 2.6 with preference to use text/xml)
• multipart/x-hl7-cda-level1 for HL7v3 ED data type
• Many variants outside of HL7 specifications:
  • application/x-hl7-cda-level-one+xml MedXml
  • application/x-hl7 Aurora Regenstrief
  • text/x-cda-r2+xml CNIPA Osservatorio Open Source
  • application/edi-hl7 Gunther's HL7TestServer as a variant on RFC1767 recommendation

etc.

Proposal

1. Get consensus on these media-types:

• application/hl7-v2 - HL7v2 pipe delimited
• application/hl7-v2+xml - HL7v2 with XML encoding
• application/hl7-v3+xml - HL7v3 with XML encoding

2. Register those at IANA (e.g. through this link http://www.iana.org/cgi-bin/mediatypes.pl)

Alternatives Considered & Rejected

• Rejected. text/xml for all HL7v2.xml and all HL7v3 instances as per the current specification
  • As quoted by Peter Scholz in the InM list discussion, RFC3023 distinctively points to using at least the application main type.
  • The subtype xml is not discriminating between HL7 and all other XML instances, let alone discriminate between v2 and v3. As Grahame already noticed, this is also not how XHTML was dealth with for example by the W3C

• Rejected. application/edi-hl7 for HL7v2 pipe delimited contents

This would be tempting because it aligns with the media-type brought forward by RFC1767, however, without version it would appear to apply for all HL7 versions. Rejected

• For consideration. application/edi-hl7v2, application/edi-hl7v2+xml, application/edi-hl7v3+xml

Like the previous alternative, this is tempting because it aligns with RFC1767. The author of this proposal would consider this an equally valid alternative.

Discussion

• MIME type for CDA
  • Harry Solomon: Question: should we have a separate media-type for CDA, to be distinguished from the transactional HL7v3 messaging? Should such a media-type be restricted to CDA R2 (or perhaps R2 and subsequent)?
  • Rene Spronk: I don't see a requirement for a separate mime type for CDA. application/hl7-v3 would be sufficient to identify the media type of all RIM/HDF derived artefacts. If we were to create a separate mime type for each and every Message Type in the HL7 v3 publication, we'd need to create thousands. A v3 knowledgable application (given that it is aware from the mime type that it is v3) will be able to determine pretty quickly that it's dealing with CDA (given the name of the root Element) and R2 thereof (its typeId).
  • Harry: The reason for a CDA mime type is preceisely for applications that are not v3 knowledgable. CDA, unlike other v3 artefacts, is intended to be human readable when rendered with a simple style sheet, and thus has a very different intended domain of use than v3 messages. It is intended to be used as a persistent document in contexts outside of HL7v3 transactional messaging (i.e., without trigger events, control wrappers, etc.) It would be useful for non v3-aware data management apps to be able to identify and distinguish CDA documents. (You could equally say that an imaging knowlegable application could readily distinguish JPEG from MPEG images by looking at their content stream headers, and therefore they don't need different mime types.)
  • Alexander: when double-clicking from disk, the media-type is not relevant, only the extension is. When viewing from a website, you can safely send the media-type "application/hl7-v3+xml" as HTTP header. I've just installed Microsoft IIS and instructed it to send this header, and Internet Explorer didn't respond any differently and just rendered the CDA document using the attached stylesheet. I've double checked with Wireshark (a packet sniffer) to verify that the HTTP header for the media-type is actually sent as configured.

Outcome/Motions

• Motion: to ask HL7 to define these three MIME type and to register at IMEA – under the condition that these are only accepted and registered. This would result in a Harmonization proposal after Registration. (Rene/Patrick, INM Q2 2009-01-14, 9-0-0)
• Motion: register application/hl7-sda+xml with IANA, to be (upon acceptance) be used as a mime type for SDA/SPL/CDA with the characteristic that they are human renderable. (René/JD, 2009-01-14 INM Q2, 9-0-0)
• Action Item – Grahame – will take care of the Registration today

20100120 - Registration has happened, and been documented. Closed!