Issue 6 in cpr-ontology: Remove medical-problem?
cpr-on...@googlecode.com
Owner: chimezie
Labels: Type-Defect Priority-Medium
New issue 6 by chimezie: Remove medical-problem?
http://code.google.com/p/cpr-ontology/issues/detail?id=6
Perhaps the cpr:medical-problem is too much of a catch-all and doesn't
provide much value? The original idea was to capture the L Weed notion of a
problem-oriented medical record, where the 'medical problems' are clearly
identified and explicitly linked to the therapeutic interventions,
medications, diagnostic procedures, etc. related to them. However, in
retrospect, this seems to be more of an issue of how the record is
presented rather than how it is conceived. So, you have problems such as
etiologic agents being medical problems rather than being purely a cause of
them?
In short, should this class be simply removed?
Alan Rector
Just noticed this. I would argue strongly that "Problem" was a role not a category of disorder, etc.
Alternatively it is a heading in the documentation model not a category in the domain ontology - which is a different view on the same point.
I would say that there are at least three different aspects to any clinical entity -
Whether it is normal/abnormal or pathological/non-pathological -
by Normal / Abnormal I mean effectively noteworthy or not in the EPR
by pathological I mean requiring some sort of management, including "watchful waiting"
The clinical role it plays in current care
Diagnosis, chief complaint, problem, treatment, etc.
Many things can play more than one role but few can play all - e.g. an angiogram can be both diagnostic and therapeutic,
an pollen allergy can be pathological but not a current problem, etc.
However, very many things can play the role "Problem".
In fact that was Weed's whole point. So putting Problem as a class in the Domain_entity hierarchy (or whatever
you call your root, just adds confusion.
It is easy in a well structured EPR to say what entities have played the role of "Problem" in someone's EPR. It is very hard to say what entities can and can't play that role.
Hope this helps
Alan
-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/~rector
www.co-ode.org
http://clahrc-gm.nihr.ac.uk/
Chimezie Ogbuji
On Tue, Sep 21, 2010 at 4:10 AM, Alan Rector <rec...@cs.man.ac.uk> wrote:
> Just noticed this. I would argue strongly that "Problem" was a role not a category of disorder, etc.
> Alternatively it is a heading in the documentation model not a category in the domain ontology - which is a different view on the same point.
Yes, I agree (mostly with the alternative, because of the general
shortcoming inherited from BFO of not being able to have occurrent
play a role - and so you can't make a snap:Role work for medical
problems that 'occur' for instance)
> I would say that there are at least three different aspects to any clinical entity
> Whether it is normal/abnormal or pathological/non-pathological -
> by Normal / Abnormal I mean effectively noteworthy or not in the EPR
> by pathological I mean requiring some sort of management, including "watchful waiting"
Is that an epistemic / modal distinction as you have described it
(i.e., it has more to do with the author of the record not so much
with that the record is a about)? I think it is the idea of 'requiring
management' that was meant to be captured in the original intent of
the term medical problem.
> The clinical role it plays in current care
Ok. A hierarchy of such roles is definitely lacking in CPR at the
moment. I will see if I can sketch one out on a wiki.
> Diagnosis, chief complaint, problem, treatment, etc.
> Many things can play more than one role but few can play all - e.g. an angiogram can be both diagnostic and therapeutic,
> an pollen allergy can be pathological but not a current problem, etc.
> However, very many things can play the role "Problem".
> In fact that was Weed's whole point. So putting Problem as a class in the Domain_entity hierarchy (or whatever
> you call your root, just adds confusion.
I agree, I will remove it.
> It is easy in a well structured EPR to say what entities have played the role of "Problem" in someone's EPR. It is very hard to say what entities can and can't play that role.
>
> Hope this helps
Yes, it does, thanks
-- Chime
Alan Rector
On 4 Oct 2010, at 15:50, Chimezie Ogbuji wrote:
> Hello, Alan. See response inline below.
>
> On Tue, Sep 21, 2010 at 4:10 AM, Alan Rector <rec...@cs.man.ac.uk> wrote:
>> Just noticed this. I would argue strongly that "Problem" was a role not a category of disorder, etc.
>> Alternatively it is a heading in the documentation model not a category in the domain ontology - which is a different view on the same point.
>
> Yes, I agree (mostly with the alternative, because of the general
> shortcoming inherited from BFO of not being able to have occurrent
> play a role - and so you can't make a snap:Role work for medical
> problems that 'occur' for instance)
The fact that BFO's restrictions make it impossible to express things sensibly is a strong argument against those features of BFO. We should be judging ontologies by their outcomes and effects on representation, not philosophical dogma.
>
>> I would say that there are at least three different aspects to any clinical entity
>> Whether it is normal/abnormal or pathological/non-pathological -
>> by Normal / Abnormal I mean effectively noteworthy or not in the EPR
>> by pathological I mean requiring some sort of management, including "watchful waiting"
>
> Is that an epistemic / modal distinction as you have described it
> (i.e., it has more to do with the author of the record not so much
> with that the record is a about)? I think it is the idea of 'requiring
> management' that was meant to be captured in the original intent of
> the term medical problem.
What the EHR is about IS epistemic. In fact, that's all the medical record is - the log of what clinicians have heard, seen, thought, and done concerning patients. We can attempt to abstract a model of the patient from the record, but that is just another view by some entity, human or mechanical, on the patient. Entities referred to in the medical record may be from our conceputalisation of reality, but the EHR is a record of how various people understand a small corner of that reality, the patient, at particular times and places. When it comes to the role played by some item of knowledge, then of course it has an epistemic component. If you go back to Weed and the source of the word "problem" in EHRs, it was whatever is a problem "for the patient". Implicitly, whatever was a problem for the patient-doctor duo, since patients have lots of problems that are outside the scope of medicine.
>
>> The clinical role it plays in current care
>
> Ok. A hierarchy of such roles is definitely lacking in CPR at the
> moment. I will see if I can sketch one out on a wiki.
>
>> Diagnosis, chief complaint, problem, treatment, etc.
>> Many things can play more than one role but few can play all - e.g. an angiogram can be both diagnostic and therapeutic,
>> an pollen allergy can be pathological but not a current problem, etc.
>> However, very many things can play the role "Problem".
>> In fact that was Weed's whole point. So putting Problem as a class in the Domain_entity hierarchy (or whatever
>> you call your root, just adds confusion.
>
> I agree, I will remove it.
>
>> It is easy in a well structured EPR to say what entities have played the role of "Problem" in someone's EPR. It is very hard to say what entities can and can't play that role.
>>
>> Hope this helps
>
> Yes, it does, thanks
>
> -- Chime
Regards
Alan