This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Transmission Attachment

From HL7Wiki
Revision as of 19:02, 10 January 2007 by GrahameGrieve (talk | contribs) (→‎Resolution)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Definition: One or more attachment classes are associated with the Batch and the Message class. Attachment classes may also occur at other places in the static models. The class contains arbitrary attachments of data blocks to which can be referred to from the interior of the Transmission. There are no constraints as to what may be contained in an attachment.

Open issue: there's still no formal guidance from the HL7 how to handle attachements in the implementations. Although TW has the attachment class, you are not required to use it; i.e. you can use the mechanisms offered by Messaging Protocols in ebXML etc. It still has not been documented how one references an attachment class.

Attachment Model

The Attachment model under discussion has Attachment classes distributed throughout the body of messages where the individual Attachment instances contain an ED which may either:

  • contain the binary contents of the attachment (a Defining Attachment); or
  • use the reference attribute within the ED (a Referring Attachment) to point to the instance which actually contains the binary content.

Defining Attachments may appear within the body of the message/HL7 content, the transmission wrapper, within some other message or repository, or as mime segment (although the latter mechanism is discouraged is it may not be supportable across all transports).

For Referring Attachments, the reference attribute will contain a URI to identify the Defining Attachment which contains the referred content and in some cases to also indicate the protocol and source to access to retrieve the attachment when it is not contained within the same HL7 information package as the Referring Attachment class.

Generic URI structure

The structure of a URI (URL/URN) is: scheme : pattern string

The scheme is a tag, which may or may not be registered, for which there is a described architecture for the pattern string. The pattern string implements or uses the scheme specific architecture to convey the scheme specific information.

Examples:

  1. http://www.hl7.org/webpage.asp - The scheme is "http", the pattern string is "//www.hl7.org/webpage.asp" and the pattern string is understood to refer to a web site (the first element after the "//" and a document hierarchy thereafter.
  2. cid:123456ABCDE - The scheme is "cid" (MIME Content Id), the pattern string "123456ABCDE" contains the text of the Content-ID of the Mime part in a MIME document.

Other well defined schemes such as mailto, ftp, etc are referenced in the HL7 datatypes.

Newly proposed URI

A new unregistered scheme is proposed to address the situation where a Referring Attachment needs to identify a Defining Attachment Class instance within this or another message. Each Defining Attachment will have an ID of type II which contains a root and optionally an extension.

Scheme: hl7iiref, Pattern String: root[:extension]

  • this scheme name is suggested as it extends the hl7-org conventional use with the "idref" specific use identifier.
  • the pattern allows for ready parsing of the id root and extension of the referred class id

example: reference="hl7iiref:2.1.16.3.9.12345.2.39.3:ABC123" would refer to the Attachment Class root="2.1.16.3.9.12345.2.39.3" extension="ABC123"

There is tremendous flexibility available from the URI RFC for scheme naming and pattern specification, so the INM committee may prefer different style for either element, but fundamentally the result will be the same. The amended style above is more in keeping with the existing OID URI (urn:oid:1.2.3.4).

Resolution

--GrahameGrieve 12:43, 10 January 2007 (CST)

Motion (Grahame/Doug): Document 2 uri syntaxes

  • hl7attref is a URL that refers to an attachment in the same instance
  • hl7iiref is a URI refers to some identified object (locating this may be difficult)

Further,

  • document the dangers of general use of hl7iiref with recommendations not to rely on it,
  • document specific use cases for which it was defined.
  • thou SHALL use hl7attref when local attachments are referred to


Note from Mark: It's a thing of beauty to have a full syntax including assigningAuthorityName and isDisplayable in the syntax as well