[COAS-List] use-cases for OIDs?

[Larry Hamel <larryh@medgrid.philips.com>]

y'all,

What are our use-cases for the Observation IDs (OIDs) in the COAS model?

First, let's set the scene by assuming that OIDs are returned by COAS as
part of a response to a request for meta-data.  Some COAS function like
"get_available()" returns a list of meta-data, including OIDs for
observations which satisfy the who/what/when/etc. parameters of
get_available().  

Let's say that we query a COAS lab server, calling get_available() about
blood gas measurements, and receive a few OIDs.  Next, we want to get the
"real" full data for a particular instance, and do so by supplying an OID
within a COAS call "get_by_ID()".  Say our call looks something like

	results = labServer.get_by_ID( someID );

and thus we expect the lab server to figure out, just from the OID, the
data we require.

What will the server need within the OID to accomplish this fetch?  

In the original get_available() call, we specified the QualifiedCode for
information we wanted (the "what" param).  This code allowed the COAS
server to navigate to a list of OODB objects, or an RDBMS table, or
whatever proprietary structure exists, in order to get meta-data about the
individual items.

Similarly, the OID must provide some means for the COAS server to navigate
to this same list of objects or table, as well as providing a key to the
exact object or row.  Logically, we can speak about these 2 pieces of
information as code + key, though there is a possibility to collapse this
into a proprietary, opaque blob.  Logically, though, we need a code and a
key for this scenario.

What about persistence?

For another potential use-case, consider a scenario where we store an OID
on disk.  In this use-case, to make use of old, stored OIDs, we first must
determine the COAS server which provided the OID.  At a minimum, we would
need a server name or ID, and in a distributed enterprise, some domain name
or ID.  This serverName and serverDomain could be stored to disk separately
from the OID, or be encapsulated in the OID itself, or perhaps added to the
OID by a COAS client that was interested in persisting the OID in a
relatively complete fashion.  In any case, here are two more bits of
information, serverName and serverDomain, that seem to be necessary for the
persistence use-case.

At least two ID entities seem relevant to our exploration of OIDs (nb: I am
not proposing that we should use the same schemes):  the DICOM Unique ID
(UID) and the CORBA interoperable object reference (IOR).  

The DICOM UID guarantees uniqueness with a registration of domains.  The
first portion of a UID like 1.2.840.113488.2.48.384.1.1998.8.5079.2.1.1 is
a DICOM domain, registered with a global domain authority, much like an IP
domain is registered with a domain authority.  The rest is of the UID is
opaque, proprietary to the vendor, although many vendors use easily-parsed
segments which may include patient, date and/or study information.  

The CORBA IOR encapsulates server/domain info with well-known syntax for IP
address and port, as well as having opaque portions.  An outside
application can decode the well-known parts of the IOR.

So these stand as examples of some techniques for incorporating information
into IDs.  What information do OIDs in COAS need?  Are there other
use-cases, or different interpretations of the above scenarios?  Please let
us know.

thanks,

larry

Larry Hamel
Principal Software Engineer
Philips Medical Systems
2171 Landings Dr.
Mountain View, CA 94043-0837
U.S.A.

Voice:  +1 (650) 426 2553         
Email:  larryh@medgrid.philips.com
Fax:    +1 (650) 426 2550