Media-types for various message formats

From HL7Wiki
Jump to navigation Jump to search


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

  • Working group: InM
  • Author: [User:Alexander Henket|Alexander Henket], on behalf of NICTIZ, the Netherlands.
  • Status: DRAFT - subject to changes by the authors

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:

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. Secondly the subtype 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.