| Async XDS.b - Questions for the OHF community [message #586357] |
Mon, 04 August 2008 01:19 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.02473 seconds