[news.eclipse.technology.ohf] Async XDS.b - Questions for the OHF commun

[Matthew Davis <mattadav@xxxxxxxxxx>]

Greetings all,

Ah, another IHE testing season is ahead of us.  A good time to start 
thinking about how to handle the future.

This year we're at the beginning of upcoming, paradigm-altering changes 
in IHE thinking.  This extends beyond technical paradigms and more into 
use paradigms.  This include a genuine asynchronous Web services 
implementation of XDS (Async XDS.b) along with a white paper on metadata 
versioning and the potential upcoming changes to patient identity and 
XDS.  Combined these changes are going to require new approaches to many 
folks' IHE implementations.

As an IHE implementation, we're looking at how these changes will affect 
OHF and our users' implementations.  For this year, we're going to start 
relatively small - with asynchronous XDS.b.  While async XDS has been 
around for several years, async XDS.b is the first formalization of the 
profile using standard async transactions.  The big thing about async 
XDS.b is it's a major step toward enabling truly federated, 
cross-community document exchange.

From an OHF IHE point of view, asynchronous Web services are a 
challenge to our existing code, both the core IHE component and (even 
more so) the Bridge.  Since the beginning, both APIs have been tightly 
synchronous.  This most certainly has to change, requiring more 
flexibility and perhaps completely new libraries to address it.  Another 
challenge is in the way that the IHE has opted to profile asynchronous 
transactions.  By using bi-directional HTTP, they introduced a 
substantial requirement to systems that will use XDS.b:  An actively 
listening Web server in the XDS Consumer.  Based on the way that XDS has 
been implemented in many clinical systems, such as EMRs, this requires 
servers at the edge of the RHIO, notably on end-user workstations.  To 
me, that alone introduces numerous technical and policy challenges that 
must be addressed in RHIO planning.

From an OHF point of view, we can address these challenges using any 
number of best practices for non-blocking Web services.  But, due to the 
technical requirements introduced, I'd like to hear from the community 
on how we can best help meet your requirements for applications 
intending to using asynchronous XDS.b.

So, I have a few questions for everyone:

1)  Do you plan to test asynchronous XDS.b at Connectathon 2009?

2)  If so, what is your primary purpose for using async XDS.b?  Is it to 
further enable XCA?  For batched transactions in large enterprise 
systems (classical use of async XDS)?  As a helper library for XCA 
sending/receiving gateways?  Just as an extension to existing 
synchronous XDS.b?  something else?

3)  Based on (2) how will you address it in your application?  For 
example, in many systems, XDS consumers are "call and wait", giving an 
active response within seconds to the person using the system.  This 
probably won't work for async, so how will you approach it from a use 
point of view?

4)  What tools can we provide to the community?  How would you like to 
see our IHE implementation address async XDS.b?  Callback APIs?  Some 
type of active proxy with storage manager that can be queried/retrieved 
from? (but doesn't necessarily run on the client system, maybe an 
adaptation of the Bridge)?  Push-based email proxy?

Thanks for helping us move forward and keep with the ever-changing 
requirements of IHE thinking.

-Matt