[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Relationship (Service?)
for 1.2 i offer another issue and a possible solution.
issue: the 'relevant' place may turn out to be more than one place, making it
irrelevant :-( e.g. A registration system would capture/manage patient->admitting md
relationship. This registration system is used by all of BHS. BHS now gobbles up a
new hospital that has a new registration system capturing the same relationships.
solution: the location of these relationships is dynamic, or should be able to be
discovered dynamically. could naming/trader entries for relationship types, or
domains (area in which a relationship is valid..context?), what about federation a la
coas. I believe that the relationships will need to be distributed, rather than
centralized. we've got lots of legacy that could be fitted with corba adaptors more
easily than convincing vendors to break their application logic to read/write
relationships to a central location.
jinny m uppal wrote:
> 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/
> >
>
> ------------------------------------------------------------------------
> Name: relationModel.zip
> relationModel.zip Type: Zip Compressed Data (application/x-zip-compressed)
> Encoding: BASE64
--
----------------------------------------------------
Eric Butler EricB@BaptistHealth.Net
Senior Systems Architect
Baptist Health Systems of South Florida
305.596.1960 X4343
----------------------------------------------------
For details regarding list subscriptions and the list archive see:
http://cadse.cs.fiu.edu/omg/halfem-rfi/