RE: [COAS-List] use cases for metaknowledge about source

["Jay K. Brinton" <brinton@adelphia.net>]

I agree that these are all important things to consider in a large distributed healthcare network.

It seems Patient ID domain info could get tricky in terms of source, in the case where you have a hierarchical arrangement of PIDS.  Seems to me you would go with the domain of the highest level correlation mgr.

A related item that occurs to me (forgive me if this has been addressed) is the proper way to convey coded data and/or data that has been processed by a lexicon.  Is it returned in the form generated by the source system, or according to the coding scheme / vocabulary of the requesting system, or both?  Seems that this decision may have legal implications.

Regards,
Jay

never comply with standards that are unworthy of you  -Ayn Rand

Jay Brinton
Chief Software Engineer
SAIC HealthCare Technology Sector

brintonj@saic.com / brinton@adelphia.net
344 Tampa Ave
Pgh, PA 15228
412 563 7003

-----Original Message-----
From:	Larry Hamel [SMTP:larryh@medgrid.philips.com]
Sent:	Monday, June 29, 1998 9:31 PM
To:	coas@cs.fiu.edu
Subject:	[COAS-List] use cases for metaknowledge about source

y'all,

In discussions with CareFlow|Net (Juggy--pls. jump in if I miss anything),
a few use-cases came up which seem to point up the benefits of
"info-source" metaknowledge as part of a COAS reply.

The first case involves vocabulary translation.  Say that a COAS lab server
uses a proprietary code "redbc" to indicate a count of red blood cells.
(this example is entirely fabricated.)  In order to use a Lexical Query
Service (LQS) to translate this "redbc" label, it seems that the recipient
will need to know where the information is coming from.  

The second case involves an enterprise with many COAS servers which may
contain similar information.  For example, consider an enterprise with 3
report repositories, all COAS servers.  Say that a query for all reports
for patient Jones returns two lists, and that a COAS client receives a
unified list from a middleware layer.  It seems best to include
"info-source" metaknowledge with results in this case so that a client can
query the direct source of the information.

The third case concerns filtering and access control.  For example, if a
result comes from a COAS server for psychiatric evaluations with special
restrictions, we may want to do extra access control or logging before
passing that information onwards.

There is some metaknowledge inherent in a Patient ID which contains a
domain.  Should all COAS responses have a PatientID domain as an included
parameter or required field?   What other "info-source" metaknowledge, if
any, is necessary to accommodate the cases above?

cheers,

larry