Re: Relationship (Service?)

[jinny m uppal <juppal01@cs.fiu.edu>]

Peter, Konstantin, Eric,

Peter's diagram is pretty good, but that is how things would be done
anyways. An object always has attributes(characteristics in your diagram) 
and relationships. What I was talking about (perhaps Konstantin means the
same) is that we need one trusted place (service) that we can goto to
enquire about a particular relationship, given that we have some required
query attributes.
Right now, the relationships exist, but  only where they were created,
and are buried inside the model of the system that created them. We need a
nice standard interface that will take queries and return results,
independent of how those are created or stored. _That_ is the relationship
service, as I understand it. Ofcourse, the next question is 1. where is
this service located and 2. what is the manner in which this service make
ssure it handles the requests that are coming. 

For 1., it could be  
1.1 one central relationship repository (the relationship server) or,
1.2 it could be just an interface supported by all modules that have
relationships of interest to others. (I think Eric talks about 1.2)
Each of the above approaches introduce a bunch of issues. 
For 1.1, all relationship creators must inform that big guy about every
new relaitonship. Then there is the problem (as Konstantin said): how do
legacy systems do that? Adapters? Data minig? There are other usual
problems of a centralised repositories ......

for 1.2: it sounds good, except that when you need to find out about a
particular relationship, you need to know where that relationship lives.
And that is for most part, static information (I think). for exmaple 
a primary care physician relationship: we know it will be in the encounter
(registration)system, because that's where it got created. This is what
Peter means when he says 'relevant place', right?

For 2., we could have a simple model that captures for every two related
objects, the relationship instance which also has as attributes, the time
period over which it was  true and the context. I must say i am not
very clear about what exactly the "context" is going to be. I mean it
could be anything at all, really. Thats thinking material.....
What about location where that relationship was created? (a particular
building of a hospital?).
Enclosed is a zipped rtf file for one such model. (Read it,
its only 10KB! ;-) ) RelationshipType and RelatedObejct Type are, in
COSMOS-speak, knowledge level objects, and the others are operational
level. Peter, note that Related Objects (I dont know what else to call
them at this point), could be institutions, physicians, patients or
anything at all.

Jinny.
PS:Whew! that was a big brain dump! Please excuse my typos! 

"Make everything as simple as possible, but not simpler" - Albert Einstein -
---------------------------------------------------------------------------
Jinny Uppal,                                   E-mail: jinnyu@usa.net
SCS,Florida International University,                  juppal01@cs.fiu.edu
Miami, Florida (The SunShine State)      Phone (Work): 305-348-4038
---------------------------------------------------------------------------

On Tue, 13 Oct 1998, Konstantin Beznosov wrote:

> Peter,
> 
> I think we do need a relationship service. It will hide all specifics of
> finding relationships in hospital environment. The service will perform role of
> Mediator from Mediator pattern (The Gang of Four, 1995).
> I think you and I agree on the main points. I just come into the discussion
> more from the perspective of healthcare enterprise design than from the
> perspective of data modeling in healthcare.
> 
> Konstantin
> 
> > By making the relationship a sub-type of the Person (or Subject) 
> > property of one of the members of the relationship we also, by 
> > implication, place that relationship within the record of that Person 
> > (e.g. patient record).  Therefore, i would tend to agree with 
> > Konstantin, but not for quite the same reason, that we do not need a 
> > relationships server.  Instead, I think we need a consistent model of 
> > relationships and these should be stored in the relevant place.  So a 
> > parent/child relationship would be stored in the patient record, a 
> > provider/patient relationship would be stored in an encounter manager 
> > and a provider/employee relationship would be stored in an enterprise 
> > manager.
> 
> 
> For details regarding list subscriptions and the list archive see:
> http://cadse.cs.fiu.edu/omg/halfem-rfi/
>

relationModel.zip