[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[COAS-List] Blob related scenarios for COAS



COAS group,

I have not been paying as close attention to the COAS work as I'd like,
but, I jotted down a couple of scenarios which our company has battled at
various levels, which may be able take advantage of a COAS interface.
Basically, my thoughts centered around being able to do more with an object
than just what is described in the interface. Some of the complexity of
interpreting the data would be located outside of the interface, on both
the client and server sides. This "post-processing" would still require
some level of mutual understanding between the client and server
applications.  I don't have enough experience with the OMG to know if this
goes directly against the goals of the IDL. If, by implying that the client
will perform interpretative processing on object data, it means the object
is not really encapsulated.

Anyway, here they are...

1)  A care giver has patient identifying information, such as a name,
social security number, age, gender, photo ID, etc. The care giver wants to
locate a patient's current medication, allergies, chronic problems, lab
tests, etc. The care giver uses patient identifying information to locate
the desired lists. Once the list is located, the user is able to view the
lists in some user friendly soft of way (web browser, green screen columns,
etc). Hopefully, the viewing application will be granted the ability to
distinguish between discrete items within these list, such as
differentiating the prescribed medication's name from the medication's
frequency and duration, thereby helping the application display information
more logically to the user.

The client application is able to function appropriately with a variety of
exposed formats. Examples of possible exposed list formats may include a
collection of discrete measurements, unstructured strings, structured
string (marked up in a standard way such as HTML, XML, or SGML), etc.

2) A specialized application has the sole duty of enabling a user to create
complex structured (clinical) reports. These reports may include embedded
links to external sources of electronic and non-electronic data (images,
tissue samples, etc). The structure and complexity of the report vary from
report to report. The representation of the values within a report and
their relationship to each other, must remain constant, they may only be
altered explicitly by the user.

Despite the potential complexity of a report, the primary purpose of the
report is to be utilized by other clinical information systems which
perform other specialities. For example, a report creating application may
cooperate with a clinical information management system that specializes in
document archiving and manages access to reports and information within
reports. This archiving system may not have the ability, or desire, to use
all of the structure within the report, but is able to expose the report to
other applications (such as a data mining type of application) which can.

The report is to be communicated between the creating application and the
managing application without having to either raise the awareness of the
client application up to the level where it understands all of the
complexity of the report, or, collapse the complexity out of the report
down to the level where the client can understand all of it.  (Applies to
the interface supporting this communication).

-Karen Dolan