Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » OHF » Async XDS.b - Questions for the OHF community
Async XDS.b - Questions for the OHF community [message #44925] Sun, 03 August 2008 21:19 Go to next message
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
Re: Async XDS.b - Questions for the OHF community [message #44961 is a reply to message #44925] Mon, 04 August 2008 06:24 Go to previous messageGo to next message
Eclipse User
Originally posted by: 322zx.163.com

The OHF that we are usring supports the XDS.b? I now installed the XDS.b
web service on my machine.I want to use the OHF to connect to the XDS.b
serivce. Do this implement?

If I want to submit some documents to the service,I need to write the
code?
I used my onwer services URL,but always failed.
I studied OHF,but I did not known how to start with.
I use the test in ohf,the program always had some errors.
Can someone help me?
Re: (re: technical support question) Async XDS.b - Questions for the OHF community [message #44984 is a reply to message #44961] Mon, 04 August 2008 13:20 Go to previous messageGo to next message
Matthew Davis
Messages: 269
Registered: July 2009
Senior Member
Hi,

You can use OHF to connect to any XDS.a or XDS.b-compliant document
registry or repository. Please note that the default servers listed in
the source code (http://lswin10.dfw.ibm.com) are no longer available.

Could you may post an error log of the problem?

Thanks,
-Matt

RobertHua wrote:
> The OHF that we are usring supports the XDS.b? I now installed the
> XDS.b web service on my machine.I want to use the OHF to connect to the
> XDS.b serivce. Do this implement?
>
> If I want to submit some documents to the service,I need to write the
> code?
> I used my onwer services URL,but always failed.
> I studied OHF,but I did not known how to start with.
> I use the test in ohf,the program always had some errors.
> Can someone help me?
>
questions on existing XDS.b [message #45005 is a reply to message #44961] Mon, 04 August 2008 13:30 Go to previous messageGo to next message
No real name is currently offline No real name
Messages: 292
Registered: July 2009
Senior Member
Hi Robert,

I've changed the subject of your email - as Matt's questions are about
new development and yours are about what already exists.

It is true that OHF already supports XDS.b (synchronous). But, OHF is an
enabling client side technology. It will help you submit and query
documents by constructing the standards-based, complex, messages for you
to send to a server. OHF does not implement the server side (it does not
implement an XDS Registry or an XDS Repository). A picture may help:

+-----------+ OHF API or WS +---------+ IHE protocol +-----------+
| your | -----> | OHF | --------> | IHE server|
|application| +---------+ +-----------+
+-----------+

So to complet a query or submit document scenario, you'll need to use
one of our known internet servers to connect with and configure OHF to
point to this server. Then you can call OHF, using the simplified API
and it will do the rest of the work.

See:
http://wiki.eclipse.org/IHE_Test_Server_Information

As Matt previously posted, the IBM servers are in the process of
(physically) relocating. We'll let the community know when this process
is complete.

A good place to start is with the JUNIT tests for each plugin - these
can be used, along with a server infrastructure, to experiment with the
capabilities of OHF.

Hope this clarifies,
- Sarah




RobertHua wrote:
> The OHF that we are usring supports the XDS.b? I now installed the
> XDS.b web service on my machine.I want to use the OHF to connect to the
> XDS.b serivce. Do this implement?
>
> If I want to submit some documents to the service,I need to write the
> code?
> I used my onwer services URL,but always failed.
> I studied OHF,but I did not known how to start with.
> I use the test in ohf,the program always had some errors.
> Can someone help me?
>
Re: questions on existing XDS.b [message #45013 is a reply to message #45005] Mon, 04 August 2008 22:48 Go to previous messageGo to next message
Eclipse User
Originally posted by: 322zx.163.com

Thanks for everyone helping me!!
Now I use the OHF test connect to my owner Registry and Ropostory
service successful.
But I only use the test that OHF supplied£¬I want to wirte to my onwer
codes to submit my owner Documents.Can somebody give me some samples?
I also want to known the flow that how to write codes using OHF API.
To this question I known little, not too clear¡£
Re: questions on existing XDS.b [message #45038 is a reply to message #45013] Tue, 05 August 2008 12:28 Go to previous messageGo to next message
No real name is currently offline No real name
Messages: 292
Registered: July 2009
Senior Member
Hi Robert,

Please see the code in org.eclipse.ohf.ihe.xds.source.test.mesa in the
src_tests/ folder of the XDs source plugin. In particular, test 11746
shows code for submitting documets via XDS.a and test 12046 shows code
to submit documents via XDS.b. You can follow this code as an example of
how to write the code you'll need to run your own tests.

Hope this helps,
- Sarah


RobertHua wrote:
>
> Thanks for everyone helping me!!
> Now I use the OHF test connect to my owner Registry and Ropostory
> service successful.
> But I only use the test that OHF supplied£¬I want to wirte to my onwer
> codes to submit my owner Documents.Can somebody give me some samples?
> I also want to known the flow that how to write codes using OHF API.
> To this question I known little, not too clear¡£
>
Re: Async XDS.b - Questions for the OHF community [message #45786 is a reply to message #44925] Mon, 18 August 2008 13:18 Go to previous messageGo to next message
Jesse Pangburn is currently offline Jesse Pangburn
Messages: 166
Registered: July 2009
Senior Member
Hi Matt,
Sorry for the late reply, I've been away from the IHE thing for a bit.
Anyway, we're still thinking about asynch and how much we really need it
etc, but some of the business people think it is a real world thing. That
said, this is my rough answer to your questions:
1) yes, we will test asynch XDS.b at connectathon
2) We want it to support large batched transactions
3) As an integration engine, user use cases are not an issue, we are
simply enabling other systems to do IHE integration.
4) Good question. In our case we see no issue with providing a SOAP
server for getting callbacks. As a user of the bridge though, I'm not
certain how this could be done easily. The only thing I can think of
is when we call the bridge on the outbound asynch request, we provide a
URL to send the callback to.
The callback would then be a web service that you define the WSDL for and
we
implement on our own then the bridge could call it at the URL that we
provide when
we invoke the asynch request- probably with a transaction ID or
sessionID or something to correlate?

As we discuss this internally and maybe bounce it off a partner or
customer or something, I hope to be able to improve or clarify my answers
:-)

thanks,
Jesse

Matthew Davis wrote:

> 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
Re: Async XDS.b - Questions for the OHF community [message #45963 is a reply to message #45786] Tue, 19 August 2008 13:00 Go to previous message
Matthew Davis
Messages: 269
Registered: July 2009
Senior Member
Jesse,
Thanks a bunch for your comments. The bridge is very much a problem in
the design of this.

I've been self-debating whether or not to even attempt this in the
Bridge. What you suggested is the only way I can come up with to
properly handle it (unless it's some type of proxy that a user further
queries on some interval). But, that's a serious number of moving
parts... two async Web service transactions interacting with each other.
( and I assume even more down the stream for y'all too).

This will help give some direction as well. We feel that it's important
to attempt async b, if not for a large number of people to use this
year, but more for the future.

I'm going to publish some design proposals shortly. I'd be very
appreciative if you would comment on those when they're up.

Thanks,
-Matt

Jesse Pangburn wrote:
> Hi Matt,
> Sorry for the late reply, I've been away from the IHE thing for a bit.
> Anyway, we're still thinking about asynch and how much we really need it
> etc, but some of the business people think it is a real world thing.
> That said, this is my rough answer to your questions:
> 1) yes, we will test asynch XDS.b at connectathon
> 2) We want it to support large batched transactions
> 3) As an integration engine, user use cases are not an issue, we are
> simply enabling other systems to do IHE integration.
> 4) Good question. In our case we see no issue with providing a SOAP
> server for getting callbacks. As a user of the bridge though, I'm not
> certain how this could be done easily. The only thing I can think of
> is when we call the bridge on the outbound asynch request, we provide a
> URL to send the callback to.
> The callback would then be a web service that you define the WSDL for
> and we
> implement on our own then the bridge could call it at the URL that we
> provide when
> we invoke the asynch request- probably with a transaction ID or
> sessionID or something to correlate?
>
> As we discuss this internally and maybe bounce it off a partner or
> customer or something, I hope to be able to improve or clarify my
> answers :-)
>
> thanks,
> Jesse
>
> Matthew Davis wrote:
>
>> 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
>
>
Re: Async XDS.b - Questions for the OHF community [message #586373 is a reply to message #44925] Mon, 04 August 2008 06:24 Go to previous message
RobertHua is currently offline RobertHua
Messages: 58
Registered: July 2009
Member
The OHF that we are usring supports the XDS.b? I now installed the XDS.b
web service on my machine.I want to use the OHF to connect to the XDS.b
serivce. Do this implement?

If I want to submit some documents to the service,I need to write the
code?
I used my onwer services URL,but always failed.
I studied OHF,but I did not known how to start with.
I use the test in ohf,the program always had some errors.
Can someone help me?
Re: (re: technical support question) Async XDS.b - Questions for the OHF community [message #586380 is a reply to message #44961] Mon, 04 August 2008 13:20 Go to previous message
Matthew Davis
Messages: 269
Registered: July 2009
Senior Member
Hi,

You can use OHF to connect to any XDS.a or XDS.b-compliant document
registry or repository. Please note that the default servers listed in
the source code (http://lswin10.dfw.ibm.com) are no longer available.

Could you may post an error log of the problem?

Thanks,
-Matt

RobertHua wrote:
> The OHF that we are usring supports the XDS.b? I now installed the
> XDS.b web service on my machine.I want to use the OHF to connect to the
> XDS.b serivce. Do this implement?
>
> If I want to submit some documents to the service,I need to write the
> code?
> I used my onwer services URL,but always failed.
> I studied OHF,but I did not known how to start with.
> I use the test in ohf,the program always had some errors.
> Can someone help me?
>
questions on existing XDS.b [message #586386 is a reply to message #44961] Mon, 04 August 2008 13:30 Go to previous message
No real name is currently offline No real name
Messages: 292
Registered: July 2009
Senior Member
Hi Robert,

I've changed the subject of your email - as Matt's questions are about
new development and yours are about what already exists.

It is true that OHF already supports XDS.b (synchronous). But, OHF is an
enabling client side technology. It will help you submit and query
documents by constructing the standards-based, complex, messages for you
to send to a server. OHF does not implement the server side (it does not
implement an XDS Registry or an XDS Repository). A picture may help:

+-----------+ OHF API or WS +---------+ IHE protocol +-----------+
| your | -----> | OHF | --------> | IHE server|
|application| +---------+ +-----------+
+-----------+

So to complet a query or submit document scenario, you'll need to use
one of our known internet servers to connect with and configure OHF to
point to this server. Then you can call OHF, using the simplified API
and it will do the rest of the work.

See:
http://wiki.eclipse.org/IHE_Test_Server_Information

As Matt previously posted, the IBM servers are in the process of
(physically) relocating. We'll let the community know when this process
is complete.

A good place to start is with the JUNIT tests for each plugin - these
can be used, along with a server infrastructure, to experiment with the
capabilities of OHF.

Hope this clarifies,
- Sarah




RobertHua wrote:
> The OHF that we are usring supports the XDS.b? I now installed the
> XDS.b web service on my machine.I want to use the OHF to connect to the
> XDS.b serivce. Do this implement?
>
> If I want to submit some documents to the service,I need to write the
> code?
> I used my onwer services URL,but always failed.
> I studied OHF,but I did not known how to start with.
> I use the test in ohf,the program always had some errors.
> Can someone help me?
>
Re: questions on existing XDS.b [message #586402 is a reply to message #45005] Mon, 04 August 2008 22:48 Go to previous message
RobertHua is currently offline RobertHua
Messages: 58
Registered: July 2009
Member
Thanks for everyone helping me!!
Now I use the OHF test connect to my owner Registry and Ropostory
service successful.
But I only use the test that OHF supplied£¬I want to wirte to my onwer
codes to submit my owner Documents.Can somebody give me some samples?
I also want to known the flow that how to write codes using OHF API.
To this question I known little, not too clear¡£
Re: questions on existing XDS.b [message #586423 is a reply to message #45013] Tue, 05 August 2008 12:28 Go to previous message
No real name is currently offline No real name
Messages: 292
Registered: July 2009
Senior Member
Hi Robert,

Please see the code in org.eclipse.ohf.ihe.xds.source.test.mesa in the
src_tests/ folder of the XDs source plugin. In particular, test 11746
shows code for submitting documets via XDS.a and test 12046 shows code
to submit documents via XDS.b. You can follow this code as an example of
how to write the code you'll need to run your own tests.

Hope this helps,
- Sarah


RobertHua wrote:
>
> Thanks for everyone helping me!!
> Now I use the OHF test connect to my owner Registry and Ropostory
> service successful.
> But I only use the test that OHF supplied£¬I want to wirte to my onwer
> codes to submit my owner Documents.Can somebody give me some samples?
> I also want to known the flow that how to write codes using OHF API.
> To this question I known little, not too clear¡£
>
Re: Async XDS.b - Questions for the OHF community [message #586788 is a reply to message #44925] Mon, 18 August 2008 13:18 Go to previous message
Jesse Pangburn is currently offline Jesse Pangburn
Messages: 166
Registered: July 2009
Senior Member
Hi Matt,
Sorry for the late reply, I've been away from the IHE thing for a bit.
Anyway, we're still thinking about asynch and how much we really need it
etc, but some of the business people think it is a real world thing. That
said, this is my rough answer to your questions:
1) yes, we will test asynch XDS.b at connectathon
2) We want it to support large batched transactions
3) As an integration engine, user use cases are not an issue, we are
simply enabling other systems to do IHE integration.
4) Good question. In our case we see no issue with providing a SOAP
server for getting callbacks. As a user of the bridge though, I'm not
certain how this could be done easily. The only thing I can think of
is when we call the bridge on the outbound asynch request, we provide a
URL to send the callback to.
The callback would then be a web service that you define the WSDL for and
we
implement on our own then the bridge could call it at the URL that we
provide when
we invoke the asynch request- probably with a transaction ID or
sessionID or something to correlate?

As we discuss this internally and maybe bounce it off a partner or
customer or something, I hope to be able to improve or clarify my answers
:-)

thanks,
Jesse

Matthew Davis wrote:

> 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
Re: Async XDS.b - Questions for the OHF community [message #586850 is a reply to message #45786] Tue, 19 August 2008 13:00 Go to previous message
Matthew Davis
Messages: 269
Registered: July 2009
Senior Member
Jesse,
Thanks a bunch for your comments. The bridge is very much a problem in
the design of this.

I've been self-debating whether or not to even attempt this in the
Bridge. What you suggested is the only way I can come up with to
properly handle it (unless it's some type of proxy that a user further
queries on some interval). But, that's a serious number of moving
parts... two async Web service transactions interacting with each other.
( and I assume even more down the stream for y'all too).

This will help give some direction as well. We feel that it's important
to attempt async b, if not for a large number of people to use this
year, but more for the future.

I'm going to publish some design proposals shortly. I'd be very
appreciative if you would comment on those when they're up.

Thanks,
-Matt

Jesse Pangburn wrote:
> Hi Matt,
> Sorry for the late reply, I've been away from the IHE thing for a bit.
> Anyway, we're still thinking about asynch and how much we really need it
> etc, but some of the business people think it is a real world thing.
> That said, this is my rough answer to your questions:
> 1) yes, we will test asynch XDS.b at connectathon
> 2) We want it to support large batched transactions
> 3) As an integration engine, user use cases are not an issue, we are
> simply enabling other systems to do IHE integration.
> 4) Good question. In our case we see no issue with providing a SOAP
> server for getting callbacks. As a user of the bridge though, I'm not
> certain how this could be done easily. The only thing I can think of
> is when we call the bridge on the outbound asynch request, we provide a
> URL to send the callback to.
> The callback would then be a web service that you define the WSDL for
> and we
> implement on our own then the bridge could call it at the URL that we
> provide when
> we invoke the asynch request- probably with a transaction ID or
> sessionID or something to correlate?
>
> As we discuss this internally and maybe bounce it off a partner or
> customer or something, I hope to be able to improve or clarify my
> answers :-)
>
> thanks,
> Jesse
>
> Matthew Davis wrote:
>
>> 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
>
>
Previous Topic:ProvideAndRegisterDocumentSetType --> OMElement
Next Topic:Query Document Failure using the OHF
Goto Forum:
  


Current Time: Sat Aug 23 11:39:43 EDT 2014

Powered by FUDForum. Page generated in 0.02070 seconds