|
Re: OHF - IHE Plugin question [message #33267 is a reply to message #33160] |
Sat, 25 August 2007 22:44 |
No real name Messages: 292 Registered: July 2009 |
Senior Member |
|
|
Hi Venkat,
Thank you for your post to the newsgroup and sorry for the delay in
reply. I'm the person to address this issue and am on buisness travel
until mid-September. I'll do my best to check this out during this time.
Regarding the questions I can answer:
1. I'm not sure of this. The system may be down while they update for
the coming connectathon. Or the URL may have changed. Note that NIST is
not a dedicated year round server for testing .. they are primerily used
for pre-Connectathon testing in the fall. The IBM test environment is a
year round environment for testing and is compliant with 2006-2007 IHE
specifications. I'll look into this more when I am able. Note - that the
current development branch in OHF is not stable as we are updating the
code for Connectathon 2008.
2. This behavior is correct - as the patient ID in the document is not
necessarily the patient ID in the XDS Affinity Domain. Reason being -
the document may or may not have been created for sharing purposes - but
rather enterprise internal purposes. So, since the OHF code cannot
determine this fact from the document itself - it takes a conservative
approach and puts the patient Id it finds in the sourcePatientId
metadata, which is correct in either case. I don't recommend that you
feed your id to the affinity domain just to get things to work. You
should be doing a query to see if the patient in question already has an
affinity domain patient ID. For NIST - you cannot feed id's to it. They
have a service that will assign you a test id. Follow the link here:
http://wiki.eclipse.org/IHE_Connectathon_2008#OHF_at_Past_Co nnectathons
to our page for connectathon last year. There is a link there to the
patient Id allocation service on NIST.
3. For now - I'm not sure how this will be accomplished. When
pre-testing for connectathon begins - test certificates will be distributed.
4. Can you open a bug on this issue, attach the debug log and I can
better determine what is going on.
5. These are codes that will be determined by the affinity domain
installation environment. For connectathon - these will be determined by
connectathon officials. To see/use the codes from the last connectathon
- follow the links above to the OHF 2007 Connectathon wiki page. We have
a link there (right by the NIST patient id allocation service) to the
codes used for 2007. These are subject to change for Connectathon 2008.
regards,
Sarah
Venkat wrote:
> Hi all
> I�m using OHF plugins to implement the IHE functionality into our
> application. I have the following questions:
> 1. Is the NIST down? I�m not able to submit documents to the NIST
> at
> http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/port als/yr3a/repository.
> 2. When I submit a CCD document created from my application, the
> source patient id and patient ids within the document are created from
> our application. The submission fails stating that the patient id should
> be in the affinity domain. Should I then perform a Patient Identity Feed
> transaction as a Patient Identity Source actor and register my system
> generated patient id into the NIST registry? If that is the case, to
> which NIST specific MLLP destination should I send the Patient Feed to?
> 3. How can I perform the secure submission for the XDS document
> source actor to the NIST? 4. While performing a XDS-MS document
> submission transaction, I had set the MIME default type �text/xml� and
> the format code to "CDAR2/IHE 1.0" and DocumentDescriptor to CDA_R2. If
> I set the MIME type to "text/x-cda-r2+xml" I�m getting a SOAP error. I
> also notice that there is a XDS_MS DocumentDescriptor. When I tried to
> use this too I�m getting an error? 5. There some DocumentEntry
> and SubmissionSet meta data such as the HealthCareFacilityCode,
> ClassCode, PracticeSetting Code, ContentTypeCode which are not part of
> the generated CCD document. Can u tell me how and from whom these values
> will be received in a real installation.
> I would greatly appreciate any help. Thanks Venkat
>
|
|
|
Re: OHF - IHE Plugin question [message #581077 is a reply to message #33160] |
Sat, 25 August 2007 22:44 |
No real name Messages: 292 Registered: July 2009 |
Senior Member |
|
|
Hi Venkat,
Thank you for your post to the newsgroup and sorry for the delay in
reply. I'm the person to address this issue and am on buisness travel
until mid-September. I'll do my best to check this out during this time.
Regarding the questions I can answer:
1. I'm not sure of this. The system may be down while they update for
the coming connectathon. Or the URL may have changed. Note that NIST is
not a dedicated year round server for testing .. they are primerily used
for pre-Connectathon testing in the fall. The IBM test environment is a
year round environment for testing and is compliant with 2006-2007 IHE
specifications. I'll look into this more when I am able. Note - that the
current development branch in OHF is not stable as we are updating the
code for Connectathon 2008.
2. This behavior is correct - as the patient ID in the document is not
necessarily the patient ID in the XDS Affinity Domain. Reason being -
the document may or may not have been created for sharing purposes - but
rather enterprise internal purposes. So, since the OHF code cannot
determine this fact from the document itself - it takes a conservative
approach and puts the patient Id it finds in the sourcePatientId
metadata, which is correct in either case. I don't recommend that you
feed your id to the affinity domain just to get things to work. You
should be doing a query to see if the patient in question already has an
affinity domain patient ID. For NIST - you cannot feed id's to it. They
have a service that will assign you a test id. Follow the link here:
http://wiki.eclipse.org/IHE_Connectathon_2008#OHF_at_Past_Co nnectathons
to our page for connectathon last year. There is a link there to the
patient Id allocation service on NIST.
3. For now - I'm not sure how this will be accomplished. When
pre-testing for connectathon begins - test certificates will be distributed.
4. Can you open a bug on this issue, attach the debug log and I can
better determine what is going on.
5. These are codes that will be determined by the affinity domain
installation environment. For connectathon - these will be determined by
connectathon officials. To see/use the codes from the last connectathon
- follow the links above to the OHF 2007 Connectathon wiki page. We have
a link there (right by the NIST patient id allocation service) to the
codes used for 2007. These are subject to change for Connectathon 2008.
regards,
Sarah
Venkat wrote:
> Hi all
> I�m using OHF plugins to implement the IHE functionality into our
> application. I have the following questions:
> 1. Is the NIST down? I�m not able to submit documents to the NIST
> at
> http://hcxw2k1.nist.gov:8080/xdsServices2/registry/soap/port als/yr3a/repository
> 2. When I submit a CCD document created from my application, the
> source patient id and patient ids within the document are created from
> our application. The submission fails stating that the patient id should
> be in the affinity domain. Should I then perform a Patient Identity Feed
> transaction as a Patient Identity Source actor and register my system
> generated patient id into the NIST registry? If that is the case, to
> which NIST specific MLLP destination should I send the Patient Feed to?
> 3. How can I perform the secure submission for the XDS document
> source actor to the NIST? 4. While performing a XDS-MS document
> submission transaction, I had set the MIME default type �text/xml� and
> the format code to "CDAR2/IHE 1.0" and DocumentDescriptor to CDA_R2. If
> I set the MIME type to "text/x-cda-r2+xml" I�m getting a SOAP error. I
> also notice that there is a XDS_MS DocumentDescriptor. When I tried to
> use this too I�m getting an error? 5. There some DocumentEntry
> and SubmissionSet meta data such as the HealthCareFacilityCode,
> ClassCode, PracticeSetting Code, ContentTypeCode which are not part of
> the generated CCD document. Can u tell me how and from whom these values
> will be received in a real installation.
> I would greatly appreciate any help. Thanks Venkat
>
|
|
|
Powered by
FUDForum. Page generated in 0.04461 seconds