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

Difference between revisions of "Transmission Attachment"

From HL7Wiki
Jump to navigation Jump to search
(new page)
 
Line 1: Line 1:
One or more attachment classes are associated with the Batch as well as the Message class.
+
'''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.
  
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.
+
==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:
 +
# ''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.
 +
# ''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="urn: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).

Revision as of 06:17, 25 May 2006

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.

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="urn: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).