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

[David Forslund <dwf@acl.lanl.gov>]

Charles Carman writes:
 > 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 agree that COAS isn't dealing with images, but neither is the request
I'm making.  I claim there are many cases where one wants to browse
lower in the ObservationData hierarchy and that is all I'm asking for.
If I can't return an ObservationRemote  in the Any, then I can't browser
lower in the hierarchy.  My example doesn't get images, but gets some
additional complex information such as a list of URL's which aren't
needed to be sent to the client until they are asked for with the
BrowseAccess interface.  If you include the plicy as indicated below, I
can do what I want to do within the specification.  Later we can add
more explicit Image access with CIAS. I can express every element of the
ImageStudy we have with existing atomic components of ObservationValue.
There are just a lot of details that I don't want to have to retrieve
until I need to, and the suggestion I'm making would take care of this
(as well as our Attachment example).

I'll send email to Yasser about helping with CIAS.

Thanks,

Dave

 > 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
 > >>