[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
&quot;patient side&quot; of the role.).&nbsp; 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>&nbsp;</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:&nbsp; In many application scenarios, the identity and =
relationships among=20
identities are central to the business process at hand.&nbsp; 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>&nbsp;</DIV>
<DIV><FONT color=3D#000000>In the <EM>secondary</EM> issue of whether to =

&quot;factor-<STRONG><EM>out</EM></STRONG>&quot; 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.&nbsp; All other systemic qualities and information qualities =
are=20
degraded, but sometimes only by acceptable, marginal levels.&nbsp; 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>&nbsp;</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.&nbsp; 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>&nbsp;</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.&nbsp; I also feel that the=20
relationships service needs to stay at person-level (as PIDS did)&nbsp; =
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 &lt;<A=20
    =
href=3D"mailto:peter.nicklin@newcastle.ac.uk">peter.nicklin@newcastle.ac.=
uk</A>&gt;<BR><B>To:=20
    </B>jinny m uppal &lt;<A=20
    =
href=3D"mailto:juppal01@cs.fiu.edu">juppal01@cs.fiu.edu</A>&gt;<BR><B>Cc:=
=20
    </B><A =
href=3D"mailto:halfem-rfi@cs.fiu.edu">halfem-rfi@cs.fiu.edu</A> &lt;<A=20
    href=3D"mailto:halfem-rfi@cs.fiu.edu">halfem-rfi@cs.fiu.edu</A>&gt;; =
<A=20
    href=3D"mailto:coas@cs.fiu.edu">coas@cs.fiu.edu</A> &lt;<A=20
    href=3D"mailto:coas@cs.fiu.edu">coas@cs.fiu.edu</A>&gt;<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.&nbsp; =
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>&gt; The way I =
see it,=20
    there are two types of relationships we are talking<BR>&gt; about:=20
    demographic relationships (that can be obtained from the<BR>&gt; =
demographic=20
    service) and others (shall we call them clinical?). The<BR>&gt; =
dmeographic=20
    relationships would be accesible from the demo-service. It =
is<BR>&gt; the=20
    other type of relationships, like =
physician-isPrimaryCareOf-patient<BR>&gt;=20
    type relations that we need a relationship service for.<BR><BR>Let's =
take=20
    the example of &quot;physician-isPrimaryCareOf-patient&quot; from =
<BR>your=20
    message because it's a good one.&nbsp; 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.&nbsp; So, when the patient is referred to hospital it =
has=20
    <BR>been done by a primary care physician and therefore the=20
    <BR>&quot;physician-isPrimaryCareOf-patient&quot; 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).&nbsp;=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
    &quot;Observation Qualifier&quot; which, <BR>inter alia, is intended =
as a=20
    means of recording the identity of the =
<BR>&quot;observer&quot;.&nbsp; 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.&nbsp; 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).&nbsp; To rephrase, <BR>the relationship has medico-legal =
and=20
    clinical importance.&nbsp; 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.&nbsp; I wouldn't <BR>accept this.&nbsp; C may have more =
than one=20
    relationship with P&nbsp; (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?&nbsp; <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&nbsp;&nbsp; Fax: +44 191 230 =
4563&nbsp;=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--

For details regarding list subscriptions and the list archive see:
http://cadse.cs.fiu.edu/omg/halfem-rfi/