[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
In the secondary issue of whether to "factor-out" relationships is a =
redundancy judgement call, and all redundancy judgement can be =
predicated only on considerations of availability, performance, and =
manageability of security. All other systemic qualities and information =
qualities are degraded, but sometimes only by acceptable, marginal =
levels. I hope we can at least agree that the answer to this issue =
cannot be categorical but is inherently a tradeoff assessment.
In this case, I think that the availability and performance gains =
justify the keeping of relationship content in the various interfaces =
-as long the underlying conceptual class models (information models) and =
their semantics are consistent. Yes, there is a cost in manageability =
and integrity whenever redundancy is introduced, but I think it is =
outweighed by the availability benefit alone inthis case.
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.
-----Original Message-----
From: Peter Nicklin <peter.nicklin@newcastle.ac.uk>
To: jinny m uppal <juppal01@cs.fiu.edu>
Cc: halfem-rfi@cs.fiu.edu <halfem-rfi@cs.fiu.edu>; coas@cs.fiu.edu =
<coas@cs.fiu.edu>
Date: Tuesday, October 20, 1998 9:41 AM
Subject: [COAS-List] Re: Relationship (Service?)
=20
=20
Jinny
=20
I am sending this message to the COAS list because there are COAS=20
comments. For the COAS folk who have not been following this =
debate,=20
we are thinking about the possible role of a relationship service, =
as=20
described below by Jinny......
=20
=20
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.
=20
Let's take the example of "physician-isPrimaryCareOf-patient" from=20
your message because it's a good one. The difficulty I have with a=20
simple -relationship- service to handle this is that there are=20
clinical actions and findings that must use this relationship as a=20
context. So, when the patient is referred to hospital it has=20
been done by a primary care physician and therefore the=20
"physician-isPrimaryCareOf-patient" relationship is relevant to that =
referral (in the UK, it is the responsibility of primary care=20
physicians to control initial referrals to secondary care). =20
Therefore relationships are very much part of the Patient record=20
(whatever that may be).
=20
To some extent this point is implicitly taken on board by COAS,=20
because the latest COAS model has an "Observation Qualifier" which,=20
inter alia, is intended as a means of recording the identity of the=20
"observer". On reflection, I would say that COAS should be thinking =
about recording the identity of the -relationship- between the=20
observer and observed (usually the patient) rather than just the=20
identity of the observer. In so many clinical contexts it is the=20
relationship that authorises (or legitimates) the observation and=20
also provides extra information that is integral to the observation=20
itself (e.g. a proposed action by the clinician with key=20
responsibility for the patient would be more seriously considered =
tha=20
a proposal from someone more peripherally involved). To rephrase,=20
the relationship has medico-legal and clinical importance. Against=20
this, it might be argued that if activity A was performed by=20
clinician C in the context or relationship R between C and Patient =
P,=20
then the very fact that C performed A on P whilst R was current =
would=20
tell us what we needed to know about C's authority. I wouldn't=20
accept this. C may have more than one relationship with P (and we=20
need to know which is the actual context) or may even be acting=20
outside the authority of R.
=20
So, do we need an actual relationship service, or are relationships=20
so deeply embedded into other services, such as Record locator,=20
Demographics, Encounter management, Enterprise management and even=20
COAS and CIAS that, ultimately, a relationship service would=20
imply a separation of concerns that would be impossible to achieve? =
On the other hand, the appearence of relationships in so many =
places,=20
suggests the need for reuse.
=20
I don't know the answer to this - but I do know that it is important =
to the Roadmap to get it sorted out.
=20
Regards
=20
Peter
=20
=
_____________________________________________________________________
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=3DPeter/S=3DNicklin/O=3Dnhs_imc/OU=3Dcbs@mhs.attmail.com
=20
------=_NextPart_000_0022_01BDFC22.0CCE82B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000>In COAS, I agree with Peter that ther may be =
multiple=20
relationships in the context, but IFF the relationhsip =
<EM>attributes</EM> are=20
rich enough I se no harm in an implicit target patient (the identity at =
the=20
"patient side" of the role.). However, due to the fact =
that in=20
legal scenarios the attributes are critical (such as the effective date =
range of=20
the relationship - or the clinical context of the relationship, e.g. =
diagnosis)=20
- I think we need a semantic-rich relationhsip service.</FONT></DIV>
<DIV><FONT color=3D#000000></FONT> </DIV>
<DIV><FONT color=3D#000000>From another angle, I am convinced there is =
compelling=20
value in an explicit relationships service for the same reason that =
there was=20
compelling value to define an explicit person (IdentityAccess) interface =
in=20
PIDs: In many application scenarios, the identity and =
relationships among=20
identities are central to the business process at hand. This is =
certainly=20
the case in the legal scenarios, and is increasingly the case in =
marketing=20
decision support and e-commerce applications.</FONT></DIV>
<DIV><FONT color=3D#000000></FONT> </DIV>
<DIV><FONT color=3D#000000>In the <EM>secondary</EM> issue of whether to =
"factor-<STRONG><EM>out</EM></STRONG>" relationships is a =
redundancy=20
judgement call, and all redundancy judgement can be predicated only on=20
considerations of availability, performance, and manageability of=20
security. All other systemic qualities and information qualities =
are=20
degraded, but sometimes only by acceptable, marginal levels. I =
hope we can=20
at least agree that the answer to this issue cannot be categorical but =
is=20
inherently a <EM>tradeoff</EM> assessment.</FONT></DIV>
<DIV><FONT color=3D#000000></FONT> </DIV>
<DIV><FONT color=3D#000000>In this case, I think that the availability =
and=20
performance gains justify the <EM>keeping</EM> of relationship content =
in the=20
various interfaces -as long the underlying conceptual class models =
(information=20
models) and their semantics are consistent. Yes, there is a cost =
in=20
manageability and integrity whenever redundancy is introduced, but I =
think it is=20
outweighed by the availability benefit alone inthis case.</FONT></DIV>
<DIV><FONT color=3D#000000></FONT> </DIV>
<DIV><FONT color=3D#000000>Therefore I propose that we agree on a =
conceptual model=20
for relationships and then <EM>proceed in parallel</EM> with interfaces =
for a=20
relationship service and other services. I also feel that the=20
relationships service needs to stay at person-level (as PIDS did) =
so that=20
it is fully functional for, but not limited to, healthcare.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
<DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
</B>Peter Nicklin <<A=20
=
href=3D"mailto:peter.nicklin@newcastle.ac.uk">peter.nicklin@newcastle.ac.=
uk</A>><BR><B>To:=20
</B>jinny m uppal <<A=20
=
href=3D"mailto:juppal01@cs.fiu.edu">juppal01@cs.fiu.edu</A>><BR><B>Cc:=
=20
</B><A =
href=3D"mailto:halfem-rfi@cs.fiu.edu">halfem-rfi@cs.fiu.edu</A> <<A=20
href=3D"mailto:halfem-rfi@cs.fiu.edu">halfem-rfi@cs.fiu.edu</A>>; =
<A=20
href=3D"mailto:coas@cs.fiu.edu">coas@cs.fiu.edu</A> <<A=20
href=3D"mailto:coas@cs.fiu.edu">coas@cs.fiu.edu</A>><BR><B>Date:=20
</B>Tuesday, October 20, 1998 9:41 AM<BR><B>Subject: </B>[COAS-List] =
Re:=20
Relationship (Service?)<BR><BR></DIV></FONT>Jinny<BR><BR>I am =
sending this=20
message to the COAS list because there are COAS <BR>comments. =
For the=20
COAS folk who have not been following this debate, <BR>we are =
thinking about=20
the possible role of a relationship service, as <BR>described below =
by=20
Jinny......<BR><BR><BR>Jinny wrote..............<BR>> The way I =
see it,=20
there are two types of relationships we are talking<BR>> about:=20
demographic relationships (that can be obtained from the<BR>> =
demographic=20
service) and others (shall we call them clinical?). The<BR>> =
dmeographic=20
relationships would be accesible from the demo-service. It =
is<BR>> the=20
other type of relationships, like =
physician-isPrimaryCareOf-patient<BR>>=20
type relations that we need a relationship service for.<BR><BR>Let's =
take=20
the example of "physician-isPrimaryCareOf-patient" from =
<BR>your=20
message because it's a good one. The difficulty I have with a=20
<BR>simple -relationship- service to handle this is that there are=20
<BR>clinical actions and findings that must use this relationship as =
a=20
<BR>context. So, when the patient is referred to hospital it =
has=20
<BR>been done by a primary care physician and therefore the=20
<BR>"physician-isPrimaryCareOf-patient" relationship is =
relevant=20
to that <BR>referral (in the UK, it is the responsibility of primary =
care=20
<BR>physicians to control initial referrals to secondary =
care). =20
<BR>Therefore relationships are very much part of the Patient record =
<BR>(whatever that may be).<BR><BR>To some extent this point is =
implicitly=20
taken on board by COAS, <BR>because the latest COAS model has an=20
"Observation Qualifier" which, <BR>inter alia, is intended =
as a=20
means of recording the identity of the =
<BR>"observer". On=20
reflection, I would say that COAS should be thinking <BR>about =
recording the=20
identity of the -relationship- between the <BR>observer and observed =
(usually the patient) rather than just the <BR>identity of the=20
observer. In so many clinical contexts it is the =
<BR>relationship that=20
authorises (or legitimates) the observation and <BR>also provides =
extra=20
information that is integral to the observation <BR>itself (e.g. a =
proposed=20
action by the clinician with key <BR>responsibility for the patient =
would be=20
more seriously considered tha <BR>a proposal from someone more =
peripherally=20
involved). To rephrase, <BR>the relationship has medico-legal =
and=20
clinical importance. Against <BR>this, it might be argued that =
if=20
activity A was performed by <BR>clinician C in the context or =
relationship R=20
between C and Patient P, <BR>then the very fact that C performed A =
on P=20
whilst R was current would <BR>tell us what we needed to know about =
C's=20
authority. I wouldn't <BR>accept this. C may have more =
than one=20
relationship with P (and we <BR>need to know which is the =
actual=20
context) or may even be acting <BR>outside the authority of =
R.<BR><BR>So, do=20
we need an actual relationship service, or are relationships <BR>so =
deeply=20
embedded into other services, such as Record locator, =
<BR>Demographics,=20
Encounter management, Enterprise management and even <BR>COAS and =
CIAS that,=20
ultimately, a relationship service would <BR>imply a separation of =
concerns=20
that would be impossible to achieve? <BR>On the other hand, =
the=20
appearence of relationships in so many places, <BR>suggests the need =
for=20
reuse.<BR><BR>I don't know the answer to this - but I do know that =
it is=20
important <BR>to the Roadmap to get it sorted=20
=
out.<BR><BR>Regards<BR><BR>Peter<BR><BR>_________________________________=
____________________________________<BR>Peter=20
Nicklin, NHS IMC,<BR>c/o CHSR, 21 Claremont Place, Newcastle Upon =
Tyne, NE2=20
4AA, UK<BR>Tel: +44 191 230 3614 Fax: +44 191 230 =
4563 =20
Mobile: +44 831 198319<BR>X400: <A=20
=
href=3D"mailto:imc/G=3DPeter/S=3DNicklin/O=3Dnhs_imc/OU=3Dcbs@mhs.attmail=
.com">imc/G=3DPeter/S=3DNicklin/O=3Dnhs_imc/OU=3Dcbs@mhs.attmail.com</A><=
BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0022_01BDFC22.0CCE82B0--