Transmission Attachment

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).

(Grahame) ED.reference involves "availability". The spec says: By agreement, it is permissable to use a URI in place of a URL. In these cases, it is still expected that the resources identified is accessible by some agreed method. well, we clarified in a technical correction that this is not by agreement, but nevertheless, the "expectation" is that if we define iiref: as a uri, the resources identified will be accessible by some means. I'm not sure that the information provided in the wiki page can reasonably be said to allow the data to be accessed. That is the real source of my unease.

Discussion

(Grahame) This is supported by the current data types. I don't like the idea that we need to define our own uri format, nor the fact that it doesn't differentiate between in this instance and elsewhere. (and if elsewhere, where?)

• (Grahame) I love references within the same message - for that there is a multiplicity of possible reference methods for which we do not need to define our own URI ;-)
  • (Rene) OK, define one of one of solutions as the one to use and we'll be done AFAIK. I'm not aware of any documented solution right now. The only reference we have is an URI or II, and ED has limited options in terms of what it can be constrained to.
• references between messages is many orders of magnitude harder.
  • Referencing between two messages in 1 batch is essentially the same issue as referencing something in another message. A unique ID is sufficient. This thing will be somewhere in my transmission stream. Business rules can deal with how one dereferences the ID, or whether one can only reference something that has been sent already etc.