Thanks and talk to you soon.
Regenstrief Institute, Inc.
···
Do you think you could open a pull request against jembi:ihe-pix-xdsd-profile instead off jembi:develop. That way we will be able to see just you commits in the PR instead of all of our commits.
Thanks,
Ryan
On Fri, Dec 14, 2012 at 4:17 AM, Xiao, Hui huxiao@regenstrief.org wrote:
I finally fixed my fork problem and was able to push my changes to my forked repository (https://github.com/xiaomonp ).
I also created a pull request for you and Hannes to review these changes. We can discuss a little more tomorrow.
Thanks,
Hui Xiao
Systems Engineer
Medical Informatics
Regenstrief Institute, Inc.
410 West 10th Street, Suite 2000
Indianapolis, IN 46202-3012
Phone 317-423-5527
email
hxiao@regenstrief.org
From: Xiao, Hui
Sent: Thursday, December 13, 2012 4:21 PM
To: Ryan
Cc: Hannes Venter;
openhim-dev@googlegroups.com;
hxiao@regenstrief.org; Cy Colvard; Khokhar, Shahid; Biondich, Paul G
Subject: RE: Process stored query response
I have committed my initial code of implementation for processing document registry query response,
document repository query and document repository response to the ihe-pix-xds-profile branch of the master repo. I had some hard time to keep my own fork in sync with the master repo so I just committed my changes to the master repo instead. Please let me
know if you see any major issues.
Thanks,
Hui Xiao
Systems Engineer
Medical Informatics
Regenstrief Institute, Inc.
410 West 10th Street, Suite 2000
Indianapolis, IN 46202-3012
Phone 317-423-5527
email
hxiao@regenstrief.org
From: Ryan [mailto:rg.crichton@gmail.com]
Sent: Wednesday, December 12, 2012 3:18 AM
To: Xiao, Hui
Cc: Hannes Venter;
openhim-dev@googlegroups.com;
hxiao@regenstrief.org; Cy Colvard; Khokhar, Shahid; Biondich, Paul G
Subject: Re: Process stored query response
Great, I’m glad you have what you need to implement these methods 
Just a further note, we are registered as an XDS Source and Consumer so that does not specific what document must go in the XDS message. From the sending side we will just put our
ORU_R01 in as the document. For receiving, at the connect-a-thon, I guess we will have to accept whatever the repository we are testing against returns us. This could be be a PDF, CDA or anything. We don’t have to know how to read the document, we just have
to be able to log the message showing that we received it.
Cheers,
Ryan
On Tue, Dec 11, 2012 at 8:03 PM, Xiao, Hui huxiao@regenstrief.org wrote:
Thank you Hannes! You did answer all of our questions, and provided additional information which
is very helpful too.
We know how to implement these methods now and will let you know when it is done.
Thanks again and have a nice day!
Hui Xiao
Systems Engineer
Medical Informatics
Regenstrief Institute, Inc.
410 West 10th Street, Suite 2000
Indianapolis, IN 46202-3012
Phone 317-423-5527
email
hxiao@regenstrief.org
From: Hannes Venter [mailto:hannes@jembi.org]
Sent: Tuesday, December 11, 2012 12:48 PM
To: Xiao, Hui
Cc: Ryan; openhim-dev@googlegroups.com;
hxiao@regenstrief.org; Cy Colvard; Khokhar, Shahid; Biondich, Paul G
Subject: Re: Process stored query response
Hi Hui,
I’m glad we could help you guys understand the project better.
To answer your questions:
1 & 2. We’re currently only using the Mohawk server (xds.marc-hi.ca) for testing purposes,
and so no: this server will not form part of the RHEA stack for the connectathon (both the registry & repository).
We’re actually also using several other mohawk servers for testing as well (e.g.
pix.marc-hi.ca).
We are however planning to test the OpenHIM as a document source as well, but only for the Provide & Register Set.b request (ITI-41).
We won’t have a document registry or a repository as part of our stack.
- We’re actually not implementing CDA at all for the XDS documents. We initially planned to,
but found that the the CDA “summary” model is incompatible with our OpenMRS encounters
(which are basically messaging base), and so it would have have taken too much work at this stage to implement CDA profiles.
Currently we just simply place the ORU_R01 encounter directly as a document in the XDS request,
and so will arrive as a straight attachment from the repository.
Feel free to look at the XDSRepositoryProvideAndRegisterDocument code if
you want to see what the document looks like going into the repository
(the unit test for this class can generate a sample message).
- We’re only using SoapUI for testing (since it’s a such a useful tool for testing/tweaking your messages),
but you certainly don’t have to create tests for it if you don’t want to use the tool yourself.
But if you do make tests for it, feel free to share them
I hope this helps to answer all your questions.
Don’t hesitate to let us know if you have any more.
Cheers
Hannes
On Tue, Dec 11, 2012 at 6:18 PM, Xiao, Hui huxiao@regenstrief.org wrote:
Hi Ryan and Hannes,
Thank you both for your reply, which does help a lot for us to understand our pending tasks and relevant
context. We feel we have a much better understanding of the whole IHE connectathon project now, but would like you to help us to clarify a few more points before jumping into the actual implementation:
-
By looking at the queryencounters-denormalization-xds.b flow, it seems the document registry is currently installed at
xds.marc_hi.ca , which I assume is at MOHOK campus. Is that part of RHEA services that will be tested in the connectathon acting as RHEA’s own document registry? Or does Jembi plan to only test OpenHIM as a
XDS consumer? Can OpenHIM act as a XDS document source (and be able to register its document with the registry service hosted by a 3rd party) as well?
-
Similarly, is it true that the document repository is currently also hosted at MOHOK, and this service is also part of RHEA services that will be tested in the connectathon
acting as RHEA’s own document repository?
-
As the output of XDSRepositoryRetrieveDocumentSetResponse method will be an HL7 v2 ORU_R01 message, which should contain the information received from the repository server,
does it mean we need to convert the CDA document (HL7 v3) embedded in the repository server response to HL7 v2 ORU message so that it can be consumed by point of care application such as OpenMRS? Or shall we simply wrap the CDA document in HL7 v2 ORU message’s
OBX segment as an BASE64 encoded attachment? Alternatively, is it also good enough to simply render (with a CDA xslt) the CDA document in a simple Web application?
-
Do we need to implement both Java unit test and SoapUI test for these methods?
Thanks a lot,
Hui Xiao
Systems Engineer
Medical Informatics
Regenstrief Institute, Inc.
410 West 10th Street, Suite 2000
Indianapolis, IN 46202-3012
Phone 317-423-5527
email
hxiao@regenstrief.org
From: Ryan [mailto:rg.crichton@gmail.com]
Sent: Tuesday, December 11, 2012 4:20 AM
To: Hannes Venter
Cc: openhim-dev@googlegroups.com;
hxiao@regenstrief.org
Subject: Re: Process stored query response
Thanks Hannes, moving this here is a good idea.
I agree with what you have said. I just wanted to add that for XDSRegistryStoredQueryResponse ,
the output would be what ever data we need to be able to construct retrieve documents message using the XDSRepositoryRetrieveDocumentSet class in whatever form you deem most appropriate. There will likely be multiple calls to this class as the response
can return multiple documents.
Cheers,
Ryan
On Tue, Dec 11, 2012 at 11:05 AM, Hannes Venter hannes@jembi.org wrote:
Note: I’m just moving the issue thread from github to the mailing list, I believe this is a much better format for this type of discussion
Hi Hui,
The flow for Stored Query is in
mediation/queryencounters/queryencounters-denormalization-xds.b.
However the response XDSRegistryStoredQueryResponse is not integrated yet.
Also for the flows for Retrieve Document Set haven’t been implemented yet.
For
XDSRegistryStoredQueryResponse: the input will be the response from the registry server (AdhocQueryResponse).
This class will need to parse the input for a list of documents in the repository to retrieve.
These document links will be the input for
XDSRepositoryRetrieveDocumentSet.
However, I’m not sure what this input should look like, but I think we can use our own format.
The
output however will be a request to the repository.
The input for **XDSRepositoryRetrieveDocumentSetResponse **will be the response from the repository server
(i.e. the
input is RetrieveDocumentSetResponse).
The
output will be an HL7 v2 ORU_R01 message (the document that was stored in the repository).
Any ideas/corrections @Ryan?
Cheers
Hannes
Original message thread from github (https://github.com/jembi/openhim/issues/14#issuecomment-11207976):
- Ryan, Can you please point out to us (from the OpenHIM source code repository)
the Mule flow files to invoke the “XDSRegistryStoredQueryResponse”, “XDSRepositoryRetrieveDocumentSet” and “XDSRepositoryRetrieveDocumentSetResponse” transforms? Can you correct me if I’m wrong with the following understanding? The output of XDSRegistryStoredQueryResponse
is AdhocQueryResponse, the input is an HL7 v2 ORU R^01 message? The output of XDSRepositoryRetrieveDocumentSet is RetrieveDocumentSetRequest, the input is an HL7 v2 ORU R^01 message? The output of XDSRepositoryRetrieveDocumentSetResponse is RetrieveDocumentSetResponse,
the input is RetrieveDocumentSetRequest? Can you provide us a brief description on the input and out of each method if my understanding above is incorrect? Thanks a lot, Hui Xiao Systems Engineer Medical Informatics Regenstrief Institute, Inc. 410 West 10th
Street, Suite 2000 Indianapolis, IN 46202-3012 Phone 317-423-5527 email
hxiao@regenstrief.orgmailto:hxiao@regenstrief.org From: Ryan Crichton [mailto:notifications@github.com ] Sent: Sunday, December 09,
2012 3:34 PM To: jembi/openhim Cc: xiaomonp Subject: Re: [openhim] Process stored query responses (#14** )
We got it from the guys at Mohawk College in Canada. I’m not quite sure where they got it from or if they generated it themselves. For details of the XDS profile we have just been using the information linked to here
http://wiki.ihe.net/index.php?title=Cross-Enterprise_Document_Sharing**
The reference information is linked to on that page. You don’t have to worry about any of the service implementation for this issue though. We are more looking for a the code to do the XML processing. Ie. reading the XML response and then pulling out information
in order to generate the retrieve documents messages. From: Xiao, Hui Sent: Sunday, December 09, 2012 10:00 AM To: jembi/openhim; jembi/openhim Cc: xiaomonp Subject: RE: [openhim] Process stored query responses (#14** )
Ryan, Then where did you get the wsdl from? The reason I asked this question is that I suspect I may have missed some important supplemental information that is helpful for the implementation of XDS profile (e.g. an IHE test bundle including all the wsdl files,
xml registry data files, database import scripts, etc). The wsdl looks very similar to (maybe exactly the same as) the ones exposed by Regenstrief’s current NWHIN gateway built from NWHIN CONNECT platform. NWHIN CONNECT by itself has offered a reference implementation
with lots of soapUI test cases (inclduing document query, document retrieve, etc). Maybe we can reuse some of them? Thanks, Hui*
–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office:
+27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
–
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office:
+27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
