[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [COAS-List] Re: Relationship (Service?)
Hi all,
Here are my replies to mails from Chuck, Peter and Jon in one package
deal!
Chuck said........
> P.S. Reading over what I have just written, maybe we need to define
> "relationship". It is clear to me that COAS will be able to express,
> retrieve, etc. relationship instances. It is also clear to me that a
> health care enterprise needs to manage the activities, roles, and care
> givers who perform these activities in the various roles. Somemechanism
> is clearly needed to help with this management activity. I am not sure I
> would call it a relationship service though.
Here is what I think of as a "relationship". This isnt a definition,though.
A "relationship" (that is served by a relationship service) is an
association between two entities/objects that is valid over a time period.
It has, as attributes (in the OO sense), the related objects (2 or more),
the relationship-type (that classifies the relationship, for example
isPrimaryCarePhysicianof), and a context. Using Peter's example. Smith has
a 'isPrimaryCarePhysicianOf' relationship with Chuck under the context of
a particular 'referral'.
The management activity that Chuck mentions will probably use this service
to do its business!
Chuck, in response to your question about what use this will be,we can use
this service outside of HRAC. For example, if you wanted to find
all patients of a particular physician, you could look up the relationship
service.
Peter said...
> >So, do we need an actual relationship service, or are relationships
> >so deeply embedded into other services, such as Record locator,
> >Demographics, Encounter management, Enterprise management and even
> >COAS and CIAS that, ultimately, a relationship service would
> >imply a separation of concerns that would be impossible to achieve?
> >On the other hand, the appearence of relationships in so many places,
> >suggests the need for reuse.
Indeed, relationships are deeeply embedded in systems, and supporting a
relationship service will bring to the forefront those relationships, and
make manipulation by third party objects more feasible. I think, thats
what Jon implies. We might have redundancy, but given there are
requirements (like HRAC etc.), this seems good enough.
Peter talks about observation vs observationqualifier.....
> >because the latest COAS model has an "Observation Qualifier" which,
> >inter alia, is intended as a means of recording the identity of the
> >"observer". On reflection, I would say that COAS should be thinking
> >about recording the identity of the -relationship- between the
> >observer and observed (usually the patient) rather than just the
> >identity of the observer. In so many clinical contexts it is the
Peter, what you said points out a need to define what is it that
completely defines a relationship. Maybe somebody can add more attributes
to the previous list.
Ofcourse, a "context" seems indispensable. In fact I have been thinking we
will probably have relationships between the same entities, with the same
timeperiod, but different contexts. Reusing the previous example, Smith is
a PrimaryCarePhysician of Chuck under the context of a referral
_as well as_ an encounter, do you agree?
Jon suggested.........
>Therefore I propose that we agree on a conceptual model for relationships
>and then proceed in parallel with interfaces for a relationship service
>and other services. I also feel that the relationships service needs to
>stay at person-level (as PIDS did) so that it is fully functional for,
>but not limited to, healthcare.
I agree with the first sentence, but I am not clear what the second means.
Are you saying there are no relationships between entities that are not
persons that are interesting enough to be included in a relationship
service? What about relationships like a contract between an HCP and an
insurance company? Or between an insurance company (of type "isPayorFor")
a patient?
Jinny.
"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, 20 Oct 1998, Charles Carman wrote:
> Peter,
>
> I agree with your comments 100%.
> To answer your question(s) at the end, I am not sure we need a
> "relationship" service as much as we need an "authority" service, which may
> be part of HRAC (or may not). I don't think we need a service that stores
> or "serves" relationships. What service would it actually provide.
> Instead I think we need a service that can be asked about the roles of a
> care giver with respect to a subject of care and a health care enterprise,
> and their authority to perform those roles (the HRAC may cover the
> authority part, but may not feel that the assignment of roles to care
> givers is part of its scope).
> What do you think?
>
> Chuck
>
> P.S. Reading over what I have just written, maybe we need to define
> "relationship". It is clear to me that COAS will be able to express,
> retrieve, etc. relationship instances. It is also clear to me that a
> health care enterprise needs to manage the activities, roles, and care
> givers who perform these activities in the various roles. Some mechanism
> is clearly needed to help with this management activity. I am not sure I
> would call it a relationship service though.
>
> At 02:29 PM 10/20/98 +0000, you wrote:
> >Jinny
> >
> >I am sending this message to the COAS list because there are COAS
> >comments. For the COAS folk who have not been following this debate,
> >we are thinking about the possible role of a relationship service, as
> >described below by Jinny......
> >
> >
> >Jinny wrote..............
> >> The way I see it, there are two types of relationships we are talking
> >> about: demographic relationships (that can be obtained from the
> >> demographic service) and others (shall we call them clinical?). The
> >> dmeographic relationships would be accesible from the demo-service. It is
> >> the other type of relationships, like physician-isPrimaryCareOf-patient
> >> type relations that we need a relationship service for.
> >
> >Let's take the example of "physician-isPrimaryCareOf-patient" from
> >your message because it's a good one. The difficulty I have with a
> >simple -relationship- service to handle this is that there are
> >clinical actions and findings that must use this relationship as a
> >context. So, when the patient is referred to hospital it has
> >been done by a primary care physician and therefore the
> >"physician-isPrimaryCareOf-patient" relationship is relevant to that
> >referral (in the UK, it is the responsibility of primary care
> >physicians to control initial referrals to secondary care).
> >Therefore relationships are very much part of the Patient record
> >(whatever that may be).
> >
> >To some extent this point is implicitly taken on board by COAS,
> >because the latest COAS model has an "Observation Qualifier" which,
> >inter alia, is intended as a means of recording the identity of the
> >"observer". On reflection, I would say that COAS should be thinking
> >about recording the identity of the -relationship- between the
> >observer and observed (usually the patient) rather than just the
> >identity of the observer. In so many clinical contexts it is the
> >relationship that authorises (or legitimates) the observation and
> >also provides extra information that is integral to the observation
> >itself (e.g. a proposed action by the clinician with key
> >responsibility for the patient would be more seriously considered tha
> >a proposal from someone more peripherally involved). To rephrase,
> >the relationship has medico-legal and clinical importance. Against
> >this, it might be argued that if activity A was performed by
> >clinician C in the context or relationship R between C and Patient P,
> >then the very fact that C performed A on P whilst R was current would
> >tell us what we needed to know about C's authority. I wouldn't
> >accept this. C may have more than one relationship with P (and we
> >need to know which is the actual context) or may even be acting
> >outside the authority of R.
> >
> >So, do we need an actual relationship service, or are relationships
> >so deeply embedded into other services, such as Record locator,
> >Demographics, Encounter management, Enterprise management and even
> >COAS and CIAS that, ultimately, a relationship service would
> >imply a separation of concerns that would be impossible to achieve?
> >On the other hand, the appearence of relationships in so many places,
> >suggests the need for reuse.
> >
> >I don't know the answer to this - but I do know that it is important
> >to the Roadmap to get it sorted out.
> >
> >Regards
> >
> >Peter
> >
> >_____________________________________________________________________
> >Peter Nicklin, NHS IMC,
> >c/o CHSR, 21 Claremont Place, Newcastle Upon Tyne, NE2 4AA, UK
> >Tel: +44 191 230 3614 Fax: +44 191 230 4563 Mobile: +44 831 198319
> >X400: imc/G=Peter/S=Nicklin/O=nhs_imc/OU=cbs@mhs.attmail.com
> >
> >
> For details regarding list subscriptions and the list archive see:
> http://cadse.cs.fiu.edu/omg/halfem-rfi/
>