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

Hello,

 

For your information, a follow-up on this 
topic.

 

Interestingly, HL7 is already updating its ebXML 
profile to support ebMS3:

http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-ebxml.htm

 

This is the 
first industry adoption of ebMS3 I am aware of (and ebMS3 is not even an 
OASIS Standard). 

 

Regards,

 

Pim 

 

From: Pim van der Eijk 
[mailto:] 
Sent: 23 March 2007 
10:46
To: 'Miroslav Koncar (ZG/ETK)'; 
''
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.

 

Pim

From: Miroslav Koncar (ZG/ETK) 
[mailto:] 
Sent: 22 March 2007 
16:46
To: Pim van der Eijk; 
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:

  
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)? 
  
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,

Miroslav

 

  

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

  

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

  

  
Pim,

  
 

  
Could you also point them at the implementation NIH has please - 

  
 

  
 http://era.nih.gov/ElectronicReceipt/system.htm

  
 

  
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
messages
From: "Pim van der Eijk" 
    <>
Date: Wed, March 21, 2007 3:02 
    pm
To: <>

Hello,

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

http://www.hl7.org/Library/Committees/xml/Multimedia%20Content%20Management%
20with%20HL7v3%20Messages%2Edoc 
    

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

Kind 
    regards,

Pim

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

Hello,

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:
http://www.enterpriseintegrationpatterns.com/StoreInLibrary.html

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.

Pim

-----Original Message-----
From: 
     [mailto:]
On 
    Behalf Of Miroslav Koncar (ZG/ETK)
Sent: 07 March 2007 16:18
To: Marc 
    de Graauw; ; 
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,
Miroslav

************************************************
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