OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: FYI: [ebxml-msg] FW: Multimedia content management with HL7 V3 messages

OK - you persuaded me that I need to subscribe to the hl7 transport list!  Pauls' document is excellent at first inspection.
The answer to Miroslav's question vis attachments linking to attachments.  I'm sure what he is thinking is fragments of a large media file - that are then re-combined.
Basically the way we are doing this in NIH with the staged delivery is that first a small alert message is sent notifying the receiver of the interchange - and this creates a queue entry.  The receiver then replies to the sender - and this triggers the delivery of the actual payload(s).  Notice that the tracking ID # is used to group messages together - so you know they are all part of the same interchange.  The ebxml envelope facilitates this.
I believe CDC PHIN do it a little bit differently - instead of the ebXML envelope managing the association - I think they have a "Header" package binary attachment - that describes the remainder of the parts of the package - and then once those are all received they are re-assembled at that point.
Either approach works of course!

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: FYI: [ebxml-msg] FW: Multimedia content management with HL7 V3
From: "Pim van der Eijk" <pim.vandereijk@oasis-open.org>
Date: Fri, March 23, 2007 5:53 am
To: <ebxml-msg@lists.oasis-open.org>

For your information, a follow-up on this topic.
Interestingly, HL7 is already updating its ebXML profile to support ebMS3:
This is the first industry adoption of ebMS3 I am aware of (and ebMS3 is not even an OASIS Standard).

From: Pim van der Eijk [mailto:lists@sonnenglanz.net]
Sent: 23 March 2007 10:46
To: 'Miroslav Koncar (ZG/ETK)'; 'transports@lists.hl7.org'
Cc: 'Bojan Blazona (ZG/ETK)'
Subject: RE: [ebxml-msg] FW: Multimedia content management with HL7 V3 messages

Hello Miroslav,
In ebMS3, it is possible to put the business document (an HL7v3 XML document in your case) in the SOAP body, as all ebXML information is now in the SOAP header. It still is possible to have the XML payload in the attachment, so the second MIME part (the first being used for the SOAP header).  Any additional payloads, such as multimedia data, can be stored in other MIME parts (referenced using "cid" content-id references, http://www.ietf.org/rfc/rfc2392.txt ), or referenced as URLs as for example the streaming video server suggested example.
Whether HL7v3 XML supports hyperlinks with the "content-id" is a question for HL7, and for the HL7 binding to ebXML Messaging, other people may know more about that.  The binding document at http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-ebxml.htm  (despite the phrase "ebXML, Release 2" in its title) is for ebMS3, and it says: 
" While the ebMS specification allows xml User Messages, application messages, messages to be contained in either the SOAP Body element or a MIME part, this specification restricts the placement of User Messages for HL7 Messages to being placed in a MIME part, and for SOA style xml documents to be placed in the Body element.
There are some comments on multimedia attachments in section B.2.2 2.1.4 Payload Container of that draft.

From: Miroslav Koncar (ZG/ETK) [mailto:miroslav.koncar@ericsson.com]
Sent: 22 March 2007 16:46
To: Pim van der Eijk; transports@lists.hl7.org
Cc: Bojan Blazona (ZG/ETK)
Subject: RE: [ebxml-msg] FW: Multimedia content management with HL7 V3 messages

Hi all,
two questions related to the discussion below:
  1. is it possible to reference a binary attachment contained in one MIME part from the HL7v3 XML formatted message contained in another, where none of them are residing in the SOAP envelope (Figure 7 in the ebMS v3.0 Part 1 document - first MIME Part in the MIME envelope)?
  2. the same question as above, but this time HL7v3 message is residing the SOAP body of the first MIME part of the MIME envelope
Note that HL7 and ebXML specification can be found at: http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-ebxml.htm
Thanks, all the best,

From: owner-transports@lists.hl7.org [mailto:owner-transports@lists.hl7.org] On Behalf Of Pim van der Eijk
Sent: Thursday, March 22, 2007 4:30 PM
To: transports@lists.hl7.org
Subject: FW: [ebxml-msg] FW: Multimedia content management with HL7 V3 messages

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 22 March 2007 14:39
To: Pim van der Eijk
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] FW: Multimedia content management with HL7 V3 messages

Could you also point them at the implementation NIH has please -
This supports "staged delivery" where really large payloads can be setup for pulling - so you can optimize bandwidth usage - and do queued delivery.
Also - CDC PHIN has implemented their own mechanism to allow splitting and then re-assembling of large payloads using ebXML messaging  (aka - this is similar to the bittorrent approach - except of course you have secure transmission - with reliable delivery - rather than sending fragments over a public network - that rely on peers being online).
At NIH we have successfully sent 150Mb attachments using Hermes and ebMS.  The typical payload is 3MB to 5MB.  Next we intend to test OrionSMG and NEXUSe2e in these environments to see how they handle this transaction mix too.
Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: [ebxml-msg] FW: Multimedia content management with HL7 V3
From: "Pim van der Eijk" <pim.vandereijk@oasis-open.org>
Date: Wed, March 21, 2007 3:02 pm
To: <ebxml-msg@lists.oasis-open.org>


There is some discussion on the HL7 transports list on a document on
multimedia attachments:


I've sent some information on how ebMS2 already supports this and how ebMS3
might help them even better, see below.

Kind regards,


-----Original Message-----
From: Pim van der Eijk [mailto:lists@sonnenglanz.net]
Sent: 21 March 2007 19:55
To: 'Miroslav Koncar (ZG/ETK)'; 'Marc de Graauw'; 'Alan.P.Honey@kp.org';
Subject: RE: Multimedia content management with HL7 V3 messages


The ebXML Messaging version 2 specification (OASIS standard since 2002, ISO
15000-2 since 2004) has supported a mechanism for attachments to be
referenced (from Manifest/Reference elements in the SOAP header) using
either "content id" references to payloads included in the
SOAP-with-atthachments MIME envelop (so part of the message and physically
transmitted) and other URLs (parts referenced only, not part of the physical
message), such as an https or ftp URL to some remote BLOB store, or an mms:
URL to a streaming video server.  

The idea of separating large attachments from messages to support on-demand,
efficient processing is very common. It is widely known as the "Claim Check"
pattern.  See:

The next version of ebXML Messaging is ebMS3.  The first part is effectively
done and provides convergence with Web Services (for security and
reliability) and some additional functionality for SMEs.  Work on the second
part will start soon and one of the topics I've heard considered for part
two are splitting (large messages so they can be transmitted in parts) and
batching/connection sharing (in extremely high volume situations it may be
more efficient to combine small messages in a single connection, as is
common in some JMS implementations).

If you have requirements that would make ebMS3 better suited to healthcare
messaging, please contact the OASIS ebXML Messaging committee.


-----Original Message-----
From: owner-transports@lists.hl7.org [mailto:owner-transports@lists.hl7.org]
On Behalf Of Miroslav Koncar (ZG/ETK)
Sent: 07 March 2007 16:18
To: Marc de Graauw; Alan.P.Honey@kp.org; transports@lists.hl7.org
Subject: RE: Multimedia content management with HL7 V3 messages

Hi Marc,

> There are two major issues with SWA: large binary files are sent as a
> single MIME attachment, so failure means resending the entire thing,
> and SWA does not allow signing the attachment along with the message.
> MTOM could alleviate the second problem, but is for SOAP 1.2. Any
> thoughts on this problem?
> As for the paper by Miroslav c.s., it's a solid overview, but I do
> find it a bit strange that (rightly) using URL's to retrieve the
> external BLOB is recommended where possible, but SWA or MTOM is
> rejected on the grounds that the relation between HL7 message and BLOB
> is delegated to the 'transport', i.e. SOAP and SWA, whereas in the URL
> case the relation it is delegated to the URI and HTTP protocols. So
> why is it acceptable for URI's but not for SWA?

If I understand your point correctly, the general difference I guess would
be in regards to the bandwidth usage. When you transfer a BLOB in the HL7
message, everthing will be transferred in the same package as you point out,
and if it fails, the most likely thing to happen is resending the entire
package once again. It is most likely that this will happen during the
business hours, and would consume lots of resources. On the other hand, if
you transfer a reference only, the Receiver might choose to fetch the BLOB
later on, or not to fetch it at all if the textual infromation seems to be
enough (e.g. GP getting the radiologist specialist opinion, that only for
auditing purposes needs the MRI image from the patient).

But, at the end of the day, it is very much again project and implementers
decision how to meet this requirement.

Thanks, all the best,

To access the Archives of this or other lists or change your list settings
and information, go to: http: //www.hl7.org/listservice

To access the Archives of this or other lists or change your list settings and information, go to: http: //www.hl7.org/listservice

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]