bridge retrieveDocumentByUrl design question [message #35266] |
Thu, 18 October 2007 13:07  |
Eclipse User |
|
|
|
Hi,
I just upgraded from the 0.2 release in May to the cvs contents from
yesterday. I see some great changes, but there's one that I have a
question on. For the retrieveDocumentByUrl method, it now takes a
patientId as a parameter. Previously it had only the url, why do you add
a patient id as a parameter when you're trying to retrieve by a url? At
first I thought maybe there was a new parallel query to the registry to
retrieve the document's metadata that required the patientid, but from the
response I got when I tried it all the metadata is still blank just as it
used to be when you were retrieving the doc by url. So I don't see the
benefit of adding this patient id?
thanks,
Jesse
|
|
|
|
Re: bridge retrieveDocumentByUrl design question [message #35370 is a reply to message #35336] |
Thu, 18 October 2007 15:15  |
Eclipse User |
|
|
|
Hi Matt,
Thanks for the quick answer, good to know!
Jesse
Matthew Davis wrote:
> Good question - this was a bug we had to fix from EU Connectathon last
> year. On the ATNA Import Event audit message, the patientId for whom
> you're doing the import needs to be noted. The monitors didn't catch
> the problem in Chicago but asked us to fix it in Berlin. When we
> reconciled our changes from Berlin earlier this month, it was added in CVS.
> The API in the XDS Consumer (Consumer.retrieveDocument) was also
> modified to accept a patient ID.
> -Matt
> Jesse Pangburn wrote:
>> Hi,
>> I just upgraded from the 0.2 release in May to the cvs contents from
>> yesterday. I see some great changes, but there's one that I have a
>> question on. For the retrieveDocumentByUrl method, it now takes a
>> patientId as a parameter. Previously it had only the url, why do you
>> add a patient id as a parameter when you're trying to retrieve by a
>> url? At first I thought maybe there was a new parallel query to the
>> registry to retrieve the document's metadata that required the
>> patientid, but from the response I got when I tried it all the metadata
>> is still blank just as it used to be when you were retrieving the doc by
>> url. So I don't see the benefit of adding this patient id?
>>
>> thanks,
>> Jesse
>>
|
|
|
Re: bridge retrieveDocumentByUrl design question [message #582299 is a reply to message #35266] |
Thu, 18 October 2007 13:25  |
Eclipse User |
|
|
|
Good question - this was a bug we had to fix from EU Connectathon last
year. On the ATNA Import Event audit message, the patientId for whom
you're doing the import needs to be noted. The monitors didn't catch
the problem in Chicago but asked us to fix it in Berlin. When we
reconciled our changes from Berlin earlier this month, it was added in CVS.
The API in the XDS Consumer (Consumer.retrieveDocument) was also
modified to accept a patient ID.
-Matt
Jesse Pangburn wrote:
> Hi,
> I just upgraded from the 0.2 release in May to the cvs contents from
> yesterday. I see some great changes, but there's one that I have a
> question on. For the retrieveDocumentByUrl method, it now takes a
> patientId as a parameter. Previously it had only the url, why do you
> add a patient id as a parameter when you're trying to retrieve by a
> url? At first I thought maybe there was a new parallel query to the
> registry to retrieve the document's metadata that required the
> patientid, but from the response I got when I tried it all the metadata
> is still blank just as it used to be when you were retrieving the doc by
> url. So I don't see the benefit of adding this patient id?
>
> thanks,
> Jesse
>
|
|
|
Re: bridge retrieveDocumentByUrl design question [message #582312 is a reply to message #35336] |
Thu, 18 October 2007 15:15  |
Eclipse User |
|
|
|
Hi Matt,
Thanks for the quick answer, good to know!
Jesse
Matthew Davis wrote:
> Good question - this was a bug we had to fix from EU Connectathon last
> year. On the ATNA Import Event audit message, the patientId for whom
> you're doing the import needs to be noted. The monitors didn't catch
> the problem in Chicago but asked us to fix it in Berlin. When we
> reconciled our changes from Berlin earlier this month, it was added in CVS.
> The API in the XDS Consumer (Consumer.retrieveDocument) was also
> modified to accept a patient ID.
> -Matt
> Jesse Pangburn wrote:
>> Hi,
>> I just upgraded from the 0.2 release in May to the cvs contents from
>> yesterday. I see some great changes, but there's one that I have a
>> question on. For the retrieveDocumentByUrl method, it now takes a
>> patientId as a parameter. Previously it had only the url, why do you
>> add a patient id as a parameter when you're trying to retrieve by a
>> url? At first I thought maybe there was a new parallel query to the
>> registry to retrieve the document's metadata that required the
>> patientid, but from the response I got when I tried it all the metadata
>> is still blank just as it used to be when you were retrieving the doc by
>> url. So I don't see the benefit of adding this patient id?
>>
>> thanks,
>> Jesse
>>
|
|
|
Powered by
FUDForum. Page generated in 0.05375 seconds