Re: [COAS-List] moving between QueryAccess and BrowseAccess

[Charles Carman <ccarman@medgrid.philips.com>]

Dave,

I agree that how the ObservationIDs are returned by a COAS server is not
obvious from the IDL, because it is not explicitly IN the IDL, only lumped
in the generic ObservationQualifier stuff, and in the text of the submission.
[Larry, we need to add an explicit Qualifier Code for the COAS
ObservationID.  Maybe this would help clear up some of the confusion about
how ObservationIDs are returned.]

About your example, let me see if I understand your use-case.  A user asks
a COAS server for all the images for a specific person, but they do not
want the images sent initially, just the supporting data.  The QueryAccess
interface seems appropriate for this, using a Policy to not return any
ObservationValues (as opposed to QualifierValues which are the values of
the ObservationQualifiers).  Now, the user want to be able to selectively
retrieve the images themselves.  This could be done using ObservationIDs
and the get_observation() operation in the QueryAccess interface, or the
get_value...(?) operation in the BrowseAccess interface if we had
ObservationRemote references back from the response to the initial query.

The primary purpose of the BrowseAccess interface is to browse lower in the
ObservationData hierarchy, but in this example, the only things lower in
the hierarchy are the images themselves, and COAS does not support browsing
through the header data of images (unless that header data is also made
available by the COAS server as ObservationQualifiers).  Dealing with the
image specific header information is the responsibility of the CIAS
interface, for which a submission team is in the process of forming.  [If
you want to join the team being organized by Philips, or learn more about
it, send e-mail to Yasser Alsafadi at yha@philabs.research.philips.com].

I'm sure this did not answer all of your questions, but the main point I
wanted to get across is that there are multiple ways to get the
information, and that each is appropriate to a different style of access
and at different places in the ObservationData hierarchy.  The submission
team did not consider mechanisms to support moving easily from one
interface to another (except for the set of interfaces within the
BrowseAccess module).  A policy to specify the return of
RemoteObservationData at the leafs of the data returned by a QueryAccess
operation should be considered for inclusion in the submission.

I will be at the OMG meeting, and would be glad to talk more with you about
this.

Chuck

At 05:51 PM 3/19/99 -0700, David W. Forslund wrote:
>At 05:14 PM 3/19/99 , Charles Carman wrote:
>>Dave,
>>
>>Additional points need to be made here.  In the current COAS IDL,
>>ObservationIDs are returned as ObservationQualifiers.  They are returned
>
>This isn't obvious from the IDL.
>
>
>>this way because we did not want to require an ObservationID for every
>>ObservationData object in the hierarchy, nor did we believe that all
>>ObservationData objects should have unique IDs.  Our current "model" (only
>>in some of our heads) is that most servers will have unique IDs for only
>>the ROOT ObservationData objects.  Thus, your proposed use of COAS may not
>>be supported by some (many?) COAS servers if you expect that an
>>ObservationID will be available for any arbitrary ObservationData object in
>>the data hierarchy.
>
>But you seem to allow for ObservationRemote (BrowseAccess) for everything,
>thus I can get an
>Object reference which is all I need.  I just need a way to control or
>steer it.  It isn't obvious that ObservationId 
>wouldn't be supported by most servers since it is in many of the Access
>calls.  I actually think an ObservationRemote interface is preferable.
>
>>To help us understand your situation and respond with particular examples
>>or suggestions, would you please explain the use-case/example you have in
>>mind?  There are certainly uses of COAS that we have not anticipated.
>
>In the other email I tried to describe it.  We may have attachments that
>could be "heavyweight" (e.g., images)  and not desirable to be send in a
>query, but would be fetched in a deferred manner.  Having those attachments
>returned as ObservationRemote interfaces would be nice (and thus legal to
>have in the Any for ObservationValue as I understand). 
>The same applies for an ImageStudy, for which we would like to obtain a
>reference from the Query and then start the BrowseAccess process.
>
>It could be considered a performance question, but it is more than that I
>believe.  If it is acceptable to return an ObservationRemote interface in
>the any of ObservationData and this can be "selected" by means of a POLICY
>directive, the problem would be taken care of.  Since you have two
>"multimedia" types in ObservationValue now, it only needs to be stated that
>an ObservationRemote is also legal and that a mechanism as indicated by
>Larry would be the way to declare that you want to have a reference not the
>entire data.
>
>The Use case is a clinician trying to review the various treatments and
>reports on a patient and wanting to only see the "supporting" information
>such as imagestudies or attachments if they need it, but would like to know
>that the information exists.
>
>Thanks,
>
>Dave 
>>
>>Thanks for your help working out these kinds of details!
>>
>>Chuck Carman
>>