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

[Tim Brinson <tim@protocol.com>]

Larry Hamel wrote:
> 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.

In this case when you say 'the recipient will need to know where the
information is coming from' I presume you mean what the coding scheme
is.  Codes within a coding scheme have a definition (or multiple).  I
don't think the information about what system, department, or enterprize
the "redbc" came from would help in a translation but it might be good
context information for other reasons.

In LQS a QualifiedConceptCode includes an identifier for the coding
scheme and the concept code within that coding scheme.  I think this is
all we need.

Finding a LQS to do the translation is another issue.  Should we just
rely on using a Trader to find one?  Should COAS have a way of returning
LQS's it knows about?

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

I agree this kind of information is important for certain use
scenerios.  In others it probably is not.  One question is whether the
server always returns this metaknowledge or the client indicates some
way it needs it?  What happens if the COAS server is not a middleware
server or the data did not come from a third system?

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

This should be an implementation issue and hopefully not show up in the
IDL.  I guess what you are saying is the middleware server may need to
know some meta information in order to do the filtering.  It might get
that information from various sources such as knowing what system it
queried for the data, or from the returned data its self.


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

Yes the PersonID makes no sense without knowing the IdDomain.  The
IdDomain could get passed by using the QualifiedPersonId or it could be
meta information that is available via a readonly attribute on the
COAS.  As Jay Brinton suggests the COAS might use a PIDS CorrelationMgr
to map all IDs into one IdDomain.  In this case just plain ole PersonIds
could be used.  I am not suggesting we have duplicate signatures for
qualified and nonqualified IDs though.  In PIDS most interfaces only
needed a simple PersonId but the CorrelationMgr needed
QualifiedPersonIds.


Bob Glicksman wrote:
> For the first use case, the vocabulary may be a "standard" one (e.g. UMLS,
> SNOMED International, ICD-9, etc.), or it may be a proprietary one.  LQS
> needs to know the knowledge domain (e.g. vocabulary type) in order to do
> translations.  Therefore, in addition to location (which might be the
> "knowledge domain" for proprietary vocabularies) there should also be an
> explicit reference to a specific vocabularly.

I'm not sure I understand the difference between "knowledge domain" and
"specific vocabularly".  LQS does not differentiate between standard
(well known) and proprietary vocabularies.  They are both identified by
a naming authority ID.


Jay K. Brinton wrote:
> 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.

This is a good question that I think was raised in Orlando but we have
not answered yet.  On the one hand we don't want to burden every COAS
with having to be an LQS too.  On the other hand if a COAS can do the
tranlation it provides a higher level of service to clients.  IMHO, COAS
will ideally allow both types of implementations but I don't know how
the difference should be exposed in the IDL or as a run time
determination.


Regards,

Tim
begin:          vcard
fn:             Tim Brinson
n:              Brinson;Tim
org:            Protocol Systems, Inc.
adr:            8500 SW Creekside Place;;;Beaverton;Oregon;97008-7107;USA
email;internet: tim@protocol.com
title:          Systems Software Lead
tel;work:       503 526 4392
tel;fax:        503 526 4200
note:           <img src=http://aco.protocol.com/pids/tbrinson.jpg>
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard