Problem-oriented records and querying by problem

Technical (archive)
1

Hi, another question related to querying:

I have a case of problem-oriented records, where I need to query all the COMPOSITIONS related to a specific problem (evolutions, controls, etc).

Since we have a Problem List persistent archetype that records OBSERVATIONS about the health problems:

  • Would it be a good solution to use LINKs between those OBSERVATIONs and the COMPOSITIONs related to those problems in order to solve the “query COMPOSITIONS by health problem”?

Is there another solution for this? What do you think?

Thanks!

2

Hi all, just re-sending this question on the clinical list too.

I’m wondering how to handle the link between documents and health problems in a problem-oriented record.

Thanks!

3

It is really problematic in most systems. First there are often more than one problem addressed. Second, a lot of them are trivial and one off and do not need to be on the problem list (more reason for encounter).

I like the idea of doing this with folders in openEHR. No need to link from the document so it can be done retrospectively. It can even be different for different users potentially.

Cheers Sam

Dr Sam Heard
Chairman, openEHR Foundation

4

Nice! I didn’t considered the alternative using folders.

I’m guessing there is no recommended way to implement the p-o record.

Does anyone else implemented this in a different way? What is your experience?

Thanks a lot!

Pablo Pazos

www.CaboLabs.com

5

"How to do X in a Problem Oriented Record"

If one poses this question one has not understood one
fundamental aspect of ALL medical records pertaining to a
single patient (as opposed to epidemiological records):

_All_ data is _always_ problem oriented. Any record keeping
system "must" support attributing "things" to problems.

Exactly what constitutes a problem depends on the patient,
the provider, the level and type of care, the current focus
of attention, the granularity of record keeping,
circumstantical happenstance, knowledge of the day, etc.

It may go so far as to seem to not be a problem oriented
record -- in cases of extreme speciality, say, a geneticist
only giving advice on one specific mutation in a given
patient. That is, however, only a special case -- a singular
problem -- of a problem oriented record.

One can choose to ignore this fact but that is choosing to
ignore a part of reality. Not necessarily inappropriate for
solving a given problem but still fundamentally wrong (as to
our current level of understanding of reality, of course).

Documents are a special case since they often display
properties of a summary of care over a range of problems and
thusly need to be linked with several problems in a target
record.

Lab results are another case to consider: All things
considered every single result (rather than the battery that
was ordered) needs to be linked to potentially several
problems. Batteries may get ordered "on behalf" of a single
problem but results rarely apply to only one. Such is the
wetware reality of healthcare involving actual human beings.

Karsten

6

I think the future will be that a Care Plan informational construct (note: for US, something very closely related to an ‘order set’), partially manually written, partially machine populated with links to relevant items, will be the thing that ties it together. Consider: the proof that something really is considered a ‘problem’, out of all the non-problems and trivial problems (e.g. one-off throat infection) is that some clinical professional wants to create a care plan, to define ongoing treatment and track interventions (all medications, other interventions etc). A flexible model of a Care Plan (for each major ailment) that allows tying together of such information, and is machine-updated, I think will end up being the main way clinical professionals can interact with the raw data. We can imagine a Care Plan ‘service’ with an API for add/update/remove items/rules and apps for looking at care plans. Behind the Care Plan(s) in the EHR we still need managed medication list(s) and problem list. I see the latter two as 2nd order informational constructs, and Care Plans as 3rd order constructs. - thomas

7

Maybe I’m losing some clinical context by adopting a data view of the setting but would not a problem oriented record be a ‘view’ on clinical data ? The clinical problem is obviously context dependant (cancer, diabetes etc) so this sounds like a higher order view on top of clinical data to me. I’d see problem list as a 2nd order construct like you, but I guess I’d consider problem oriented record at 3rd and Care plan at 4th level.

If care plan is what the name implies than it involves actions to be taken on top of a particular problem view so I’d feel safer having that in its own layer. So I’d consider something like:

Say an EHR with ~100 compositions (1st level).
A problem list as a persistence composition (2nd level),
A problem oriented view that consist of compositions that are related to a power set of the problem list (3rd level)
A care plan that uses the problem view and other computable care action concepts (4th level)

The definition of problem oriented view belongs to 3rd level and you can have different care plans for the same problem view at the 4th etc etc..

8

While I agree that that's something to consider I am creating
"care plans" all day, for both "complex" and "trivial"
problems. It is very much in the eye of the beholder what's
trivial and what's not. My patients are so much the happier
for their "plan" for "one-off throat infection".

It's an interesting point of view.

Karsten

9

well that's my point actually. If a doc wants to create a care plan for X, then X for patient P is by definition a 'problem' in that doc's opinion, and consequently in P's care. So there it doesn't matter what the problem is - fractured toe or cancer, it's up to some health care professional to decide. I am just thinking of abstractions that can be usefully concretised to provide a good framework for applications to enable the patients care team to do their work, and to find & create information in a natural way.

- thomas

10

Hi all,

Sorry. Coming late to the party. I think the Contsys 'Health Issue
Thread' has this correct (similar) to the HL7 Concern structure, which
expresses a need to restructure , re-prioritise or re-frame a list of
originally recorded problems, diagnoses or issues to reflect a
specific clinical context and requirement. So Health Issue Threads
appear in Care Plans, Discharge documents, episodic Problem lists (as
per Larry Weed) and, of course the longitudinal holistic Problem list
as would be carried in a GP system.

The main problem we have in openEHR is that these are often tree-like
structures, reflecting groupings of conditions by episode or clinical
relevance

e.g.

Ischaemic Heart disease
    2004 Angina
    2006 MI
       April 2006
       June 2006 readmission

Although we can, of course, create these structures with LINKS, we do
not have an easy way to model thos kind of construct or to query it
generically.

This might be useful

http://www.openehr.org/wiki/display/healthmod/Problem,+Issue,+Diagnosis+and+Concern

A have built a wee Health Issue thread archetype to act as the container but
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

11

Hi Karsten,

The question was not “how to do X in a POMR”, the question was “how to model a POMR in openEHR”. Please read my first message to the list.

Is not for me to define what a problem is, I don’t need/care to do that, that’s for a physician to define. What I need is to provide an structure in which a physician can do that, using openEHR of course.

Also, POMR in this context is by Weed’s definition, so it has a specific structure not every record has: a master problem list, statuses for each problem, progress notes for each problem, etc.

In the other hand, yes, that information is in every MR, but you have to read a lot to find all the info relevant to a specific problem. What we need to do is to have that information linked in an explicit way to avoid that manual search, and have all the relevant info at one click of distance. IMO that was Weed’s idea.

Hope that helps to clarify my question.

12

And that's where I think the care plan distinction breaks
down. Good clinical practice would ideally mandate creating a
"plan" for any issue brought up during a healthcare-patient
encounter.

Providers and patients may decide to ignore certain issues in
a given setting but that doesn't help much either - the
remaining issues would all become problems because they would
all ask for a care plan.

IOW, since all non-ignored issues want a care plan they all
become "problems".

Karsten

13

All in all we seem to mean the same thing except I contest
the usefulness of requiring-a-care-plan to define "problem".

There can be "problems" which are of the nature "take into
account but don't directly act on" for conducting other care.
Say, a surgeon will be well aware of a patient's diabetes (as
in considering causes for delayed healing, or considerate
selection of drug therapies) -- and may want to record that
as a patient problem -- but will not necessarily render
associated care (until a toe needs to be taken off) and
thusly will not establish a care plan.

Perhaps the gist is: Issues for which a care plan is
established are considered problems while there still may be
problems without a care plan.

Karsten Hilbert

14

Hi Karsten,

firstly, I am not offering the Care Plan means of extensionally identifying problems as a bullet-proof method; it's just a working theory at this stage.

For the above: wouldn't this patient normally have a diabetic care plan, and for surgery that is not diabetic related, then there will be a care plan for that, say 'left hip problem' or whatever. If the surgery is diabetic related, then it would presumably occur as an intervention that is part of the diabetic care plan?

- thomas

15

The question was not "how to do X in a POMR", the question
was "how to model a POMR in openEHR". Please read my first
message to the list.

I certainly did.

I was not precise in my first wording. What I wanted to point
out was that if we ask the question

  How to _view_ (display) an existing medical record _as_ a POMR ?

we seem to have missed the fact (as to my understanding) that
any "existing medical record" very much IS a POMR and that it
"cannot be any other way".

Non-POMRs would seem to be data storage containers (of
instances of medical data) rather than clinically useful
_medical_ records. It is only the clinical integration of
biological data (of whichever quality or type) that turns
data into information and thusly a "medical record".

Is not for me to define what a problem is, I don't
need/care to do that, that's for a physician to define. What
I need is to provide an structure in which a physician can do
that, using openEHR of course.

What I've been wondering is that the need to turn data into
problem-related information (in order to be useful) will seem
so fundamental to any clinician that doing so would seem to
be one of the first and foremost functionality of any medical
record software.

Also, POMR in this context is by Weed's definition, so it
has a specific structure not every record has: a master
problem list, statuses for each problem, progress notes for
each problem, etc.

(I wasn't aware that Weed had defined statuses on problems --
is there a link for reading up on that ? So for I only found
http://www.geritech.org/2013/05/medicine-in-denial-problem-oriented-medical-record.html
)

I agree that the Weed model of POMR seems best suited to
comprehensive, longitudinal care but I would really like to
learn of just one counter-example to the following
proposition:

  Any medical record lends itself to being structured
  according to the POMR model.

Therefore it should in order to afford internal clinical
sense (what I am not saying here is that every clinician must
be presented with a problem oriented view or even that that
would best suit every clinicians workflow).

In the other hand, yes, that information is in every MR,
but you have to read a lot to find all the info relevant to a
specific problem. What we need to do is to have that
information linked in an explicit way to avoid that manual
search, and have all the relevant info at one click of
distance. IMO that was Weed's idea.

Here we are on the same side of things.

What I am stressing is that I would really expect any
_information_ model intended for clinical use as a
patient-centric medical record to easily afford the POMR
approach. In my personal view it should really even enforce
problem orientation internally. Otherwise said model would be
a _data_ model (of which being an excellent one is really
desirable).

So, back to your question, are we looking for where exactly
(and how) OpenEHR turns from a data model into an information
model (as per my attempt at definition above) ?

Karsten Hilbert

Declaration of potential conflict of interest: I have helped implement
a POMR.

16

Hi Thomas,

firstly, I am not offering the Care Plan means of extensionally identifying
problems as a bullet-proof method; it's just a working theory at this stage.

Sure, I am not trying to put people wrong (I can't, at any
rate), just treading the line a bit of being advocatus diabolus...

For the above: wouldn't this patient normally have a diabetic care plan, and
for surgery that is not diabetic related, then there will be a care plan for
that, say 'left hip problem' or whatever.

Agree.

If the surgery is diabetic related, then it would
presumably occur as an intervention that is part of
the diabetic care plan?

Agree except that the primary diabetic care plan would live
at the GP office (or the diabetes clinic office) while the
surgeon would now set up her own diabetes-related surgery
care plan under the problem "diabetes".

However, even before that the surgeon would certainly want to
record the fact "diabetes" as a problem such that she is
reminded of one potential cause of future wound infections,
delayed healing processes, ... in surgery *not* related to
diabetes itself. A considerate surgeon would want to be able
to recommend getting blood sugars checked and/or even switch
from oral diabetes medication to insulin application for the
time of healing of a non-diabetes wound.

But there wouldn't be a diabetes care plan per se (at the
surgeon's) during such times.

Karsten

17

this is my interest as well, and the reason for thinking about Care Plans as computational objects, that include partly computed (queried) contents.

Note that the whole design of openEHR is more or less predicated on a POMR idea, fairly equivalent to models like the 'hypothetico-deductive model of problem solving'. That's why we included Entry types in the information model like Observation, Evaluation (meaning: any kind of assessment or opinion), Instruction, Action and AdminEntry.

Experience has shown that these are a pretty good match for most clinical information, but that refinements are needed in future generations of the openEHR approach, most notably to decouple the epistemic types mentioned above from being 1:1 with fixed data structures, as Ian McNicoll has often argued. But the general principle won't change - each piece of information committed to the EHR will have an epistemic type/status related to the POMR approach.

The current challenge in my opinion is to define computational objects that correspond to higher level entities, like 'medication list', 'problem list' and 'care plan', each of which is at least partly a computed index into the relevant 1st level information items (i.e. the raw obs, Dx, actions etc). There are some good preliminary pieces of work around on this that need to be put together.

- thomas

18

Maybe I'm losing some clinical context by adopting a data view of the
setting but would not a problem oriented record be a 'view' on clinical
data ?

Ah, putting it that way makes sense, too: the POMR approach
to be a view integrating "data" into "information".

My point would be that problem orientation is so fundamental
a "view" that it should really be mandatory (even if only
internally -- if physicians can't be bothered with thinking
about which problem to attribute items to a coarsely grained
ordering, say along the lines of ICPC, might get applied
based on, say, provider speciality or some such).

The clinical problem is obviously context dependant (cancer,
diabetes etc) so this sounds like a higher order view on top of clinical
data to me. I'd see problem list as a 2nd order construct like you, but I
guess I'd consider problem oriented record at 3rd and Care plan at 4th
level.

Interesting idea: "comprehensive" care plan, not necessarily
per-problem. Maybe per-goal (for which health goals must not
be per-problem :wink: ?

If care plan is what the name implies than it involves actions to be taken
on top of a particular problem view so I'd feel safer having that in its
own layer. So I'd consider something like:

Say an EHR with ~100 compositions (1st level).

IOW, a data store rather than an EHR.

A problem list as a persistence composition (2nd level),

The minimum requirement for the data store to become an EHR.

Thanks,
Karsten

19

My bad: using a consistent terminology is hard sometimes. When I say data view, I mean openEHR data.

So my 100 compositions are good old openEHR compositions in an openEHR implementation.
All my layers are in openEHR, building on top of each other. So if you (and I) take openEHR clinical data as information (even though I called it data previously) I’m suggestion transformations of information to higher levels.

Each level knows about what is below it (Problem lists know about clinical data, they don’t know about care plans) but does not know in which context it is going to be used. So problem lists would not have any references to care plans.

I can’t agree or disagree with you regarding how fundamental problem orientation is; I am not a clinician. But I could enforce it in a clean and customisable way if I use the architecture I suggested. Some of these layers I’ve suggested may not be easily definable (if there is such a word..) in openEHR but that is OK, this is why there are PhD programmes out there.

So I guess my point is; when Pablo asks how do I do problem oriented records with openEHR, I’d say “using an architecture like this”, based on a slight modification of Tom’s (IMHO) correct suggestion of computable care plans. Your points would all be mapped into that architecture and become software implementation tasks and decisions.

Best regards
Seref

20

Hi Karsten,

I think in practice you will see a variety of care plans depending on the context.

The endocrinologist will be using a diabetes care plan for their care of the patient, and likely not having access to, nor particularly interested in, what other specialists might be scheduling.

The cardiologist will be using a cardiology-protocol-based care plan, probably developed in splendid isolation from the endocrinologist activities.

The rehab specialist will be using a purpose-built care plan for the patient's recovery from a knee replacement.

However it will be critical that the GP or coordinating primary care provider develop/need a single global care plan, (which can be separated out for the different purposes, if needed) that provides an overview of all activities that the patient requires - what is due, overdue, planned etc. This will ensure that the blood glucose and renal function tests required by both the endocrinologist and cardiologist iare coordinated, if clinically appropriate and tests/appts not repeated unnecessarily. They will have access to a 'master' plan that will detail all reviews/goals/test/appointments for each 'specialty' plan and have the ability to coordinate the components to suit the best interests of the patient as a whole - a care plan for the patient, not just one per problem.

The patient or the parent/caregiver will also benefit with being able to schedule appointments/tests etc.

And we will need to be able to break down that master care plan to see which components belong with each problem, or are shared between problems, and for context-based sharing with other health care providers.

Regards

Heather