Media-types for various message formats

This is a page of type Category:InM Open 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.