First, my apologies if this post is a bit too long. I’ve been trying to get some orientation from the community concerning openEHR modeling of a problem oriented medical record (POMR). I thank Ian for his previous replies, both in the forum and in the seminar Erik recently organized (sorry for the long question I sent; I guess it’s a pattern). I must say, though, that I am not satisfied with the answers My bad: I couldn’t accurately picture the use case.
Second, a bit of context: I am a medical doctor, specialised in Internal Medicine, and currently a part of a team of 4 clinicians from Centro Hospitalar do Porto (Portugal) who are leading the systematic, progressive migration to an openEHR based solution of our institution HIS. Since the 1980s, POMR is broadly implemented here, and I tend to defend it with the same energy as I’ve been defending openEHR for the last 4 years. They actually have some things in common, not least the need to get deeply involved with them before starting to see their virtues. And, for the sceptics, they are both ‘no go’ scenarios in medical records. For me, they could constitute the perfect marriage in a health information system. If we can avoid the traps that can make it ‘an organization’s worst nightmare’, as someone I can’t remember wrote in a book about EHR problem list implementations.
I’ll try to explain my view on this, as it’s not ‘religious’, but a very rational one.
POMR was the first formal medical notation system trying to organize medical records, to capture medical reasoning, and to document the diagnostic process. The problem list can provide a master index to the huge medical records. I won’t dig deep into its many virtues, as they are very well described in the late Prof. Lawrence Weed’s articles and books. For those interested, I will send a list of my selected references. The least known side of Weed’s breakthroughs is, in a way, the precursor of CDS: problem-knowledge coupling, he called it.
Diagnosis, as Weed put it, is still a ‘highly differentiated guessing’. We’re seldom 100% certain of the diagnosis. Even if all the data was beautifully presented in a beautifully structured and information-rich form, we’d still make mistakes. The main route to diagnosis is pattern recognition - and, as you know, there’s a lot of overlap between clinical conditions, and the circumstances of diagnostic work are usually far from ideal. This diagnosis can always be refuted; that’s life as usual in clinical medicine. But we seldom get feedback on our misdiagnosis, especially if we work in acute care settings.
POMR, in the era of HITs, could provide the ‘glue’ that links symptoms and signs, and their workup and treatment, to what ultimately constitutes a diagnosis (and its subsequent refinement). It could also support a feedback loop on clinical reasoning, eventually providing medical teaching and post-grad education with what it lacks the most: a means to effectively teach medical reasoning and diagnosis (for many of us, the essence of being a doctor, side by side with the ‘human’ skills). In a openEHR based, CDS/GDL/PROC supported HIS, the identification of problems (or diagnosis) could also be the trigger for a specific workplan. The subsequent outcomes could then be adequately mapped to the interventions specifically addressing this problem.
I could go on and on with this, but I’ll spare you.
I’d really love to get some feedback beyond scepticism, even though I deeply respect it.
On a final note, I must say that I am very proud of being part of this community, even though I am a newcomer. You have been doing a terrific work.
I’m afraid I didn’t get the question. Are there archetypes missing to represent a problem oriented medical record, or is it something in the specs?
We’ve got the Problem/Diagnose archetype and the Symptom/Sign archetype. And a lot of observations (findings included), instructions, actions and evaluations, which can relate or be linked to any problem.
If you have specific HIS implementation of POMR which you wish to port (as-is) to openEHR, it will help if you can us much more information on how this currently works. There are a very wide range of ways in which POMR is actually implemented, from a very simple ‘problem list’ maintained quite separately from any original diagnoses made in the rest of the system, to much more complex nested arrangements, with or without active/inactive status minor/major status, links to symptoms etc, or with even more complex arrangements on start and stop episodes.
It’s hard to give specific detailed advice without knowing more about your current approach. sorry if I sounded negative about POMR, I’m not actually negative at all, but having used it myself or seen it used practically since 1981, I’m just aware of the complexities and difficulties of actually maintaining it, especially when complex constructs are used. We actually maintained paper-based POMR , long after we were computerised.
I was recently involved in helping design the POMR aspects of the openEHR-based Pasiensky GP-system in Norway - see some screenshots.
If you could give some further detail on your current implementation that would help.
Welcome to the community and let’s keep this conversation going.
All informaticians I speak to seem to have deep respect for Weed’s work but the issue seems to come in translating the theory into clinical systems. I’ve heard they exist but never seen a system like this working IRL, probably most people I know are in the same situation. So it’s probably more an issue of understanding the complexity, rather than scepticism.
Maybe if you could arrange a demonstration we could understand your point of view better and respond more enthusiastically . I would certainly appreciate that (warning: AEST timezone!).
A POMR approach will require a number of layers, including the semantics, workflow, CDS logic, task planning, querying, app/vendor smarts etc. openEHR already has lots of the building blocks. Do you have a vendor willing to invest in building an openEHR-, POMR-enabled HIS?
I suspect that, as @varntzen points out we already have a number of archetypes that have been designed with POMR in mind as a possible future goal. I’m certainly willing to support you as much as I can from the archetype development point of view - we need to discern what already exists for reuse and identify additional requirements.
‘Weed’s logic’ is, in my opinion, vastly underrated, both in medical practice and (most) modern HIS. I can’t think of a better index for patient data, on a user perspective. In fact, this form of problem-solving is in itself so embeded in every healthcare system (and in both medical and nursing standards of practice), that I somehow feel (remember, from a clinician’s uninformed perspective) it should be part of the RM.
At the same time, formally expressing the diagnostic process in the IS could allow the human thought process (arguably today’s black box of healthcare) into the system where it (still) belongs.
Some insight into our use-case:
We are going through slow but steady ‘first steps’ in the progressive implementation of an openEHR based architecture in a large, public university hospital, with the possibility of future broadening of the scope to some primary care contexts. There are several local silos, which we expect to transform with integration archetypes. The proper EHR system (POMR-process support included) will be built from scratch, as the EHR enforced in 2011 offered a useless problem list UI. But POMR somehow survived, and is living today in small text boxes of patient diaries. We intend to use some outputs of legacy data integration as ‘suggestions’ for populating the problem list.
We are looking to build the ‘full POMR package’. Or, as Ian put it, ‘complex nested arrangements, with active/inactive (and) minor/major status, links to symptoms etc (and) more complex arrangements on start and stop episodes’. One of the goals is to picture the diagnostic process, in a auditable way. For that I mean, for example:
representing in a permanent, queriable format every point of data interpretation (assessments): association of risk factors, symptoms (and absence of others), lab results, etc;
illustrating the evolving problem list, signaling changes determined by the consecutive assessments and any hypothesis formally excluded, for example;
linking instructions, actions and even full episodes to the concrete (1+) problems/diagnosis that justify them, enabling the system to adequately show the most pertinent information to each context of care.
I’ve already looked into some of the resources the community built or wrote over the years. As Thomas pointed out, this topic has been raised before. I will put together a list of POMR/openEHR-related resources I found useful, so I can share it with you in another post.
I am (relativelly) aware of the hard work ahead, and of most of the needs Heather pointed out. We don’t have any investors from the vendor landscape; our IT partners belong to a university IT lab.
Every contribution from the community will be, of course, very welcome!
Thanks, Pedro, I have a better understanding of “what you’re up to” now. Sounds interesting. I’ll let others respond to your views on the Reference model. From a clinical modellers point of view, please don’t hesitate to ask for help and guidance
if you see a need for new or altered archetypes.
As it’s a bit hard to follow up on topics in the mail archive, and for future reference, here’s a selection of quotes I transcribed a while ago from the first discussion suggested by Thomas.
Did your views on this change significantly?
There is a method of implementation in POMR whereby a header, generally the ‘problem’, is linked to other record entries or elements that are to do with that problem (…) Of course things may relate to more than one Problem, Problems may link to each other, Problem headers and content will change over time. There is usually a fair amount of manual curation, which may be very contextual, but theoretical a lot of it could be automated. By modelling this linkage in data it would become computable, and potentially make some clinicians very happy in their work! Is this something that is part of openEHR specification or that can be modelled in archetypes? Or is it down to the application to manage this?
The link between the problem and others records is a SOAP structure. Where section “A” report one or many problems when episode oriented record or cronological record. (…) The archetypes exist in openehr.org/ckm, are these:
openEHR-EHR-COMPOSITION.encounter.v1 - link SOAP (or SOAPs) with a time/event
openEHR-EHR-SECTION.soap.v1 - to link all record with a problem or problems
openEHR-EHR-EVALUATION.problem_diagnosis.v1 - problem inside the SOAP
openEHR-EHR-COMPOSITION.problem_list.v1 - link list with a time (update event)
openEHR-EHR-SECTION.problem_list.v0 - organize a list
openEHR-EHR-CLUSTER.problem_qualifier.v1 - status of the problem
The task for the EHR is to present the list of patient’s problems in a way that facilitates clinical decision making. This may be through the coded problem titles (e.g. diabetes is always important for every clinician to know about, a common cold is unimportant after X months), concurrent prescriptions (e.g. gastro-oesophageal reflux is considered active as long as the patient is prescribed antacid medication), explicit manually created problem links (e.g. shortness of breath is due to heart failure, amitryptiline was started because of pain), and explicit manual problem attributes (e.g. the GP has marked osteoarthritis as a major active problem).
things like Problem lists are ‘interesting’, and I consider them a second order informational artefact. The short answer on how to do them is probably something like this:
• creating an artefact to represent a specific problem (…) will mostly be done at execution time, by clinicians deciding what things are ‘related to’ the given problem; such choices are likely to be somewhat subjective;
• technically a problem in the POMR sense could be represented as a dedicated Composition containing LINKs or DV_EHR_URI references to the bits and pieces of interest elsewhere in the EHR;
• tag(s) could be added a priori to EHR content (e.g. lab results, physical exams, ECGs, etc) before it is committed, identifying it as part of some particular problem(s), or similarly, Compositions could be classified under Folders representing problems, just as they already are under Folders representing episodes - but of course this relies on health workers knowing what problems are ‘defined’ in the EHR, and whether the new content should be added. Realistically, most linking of content to a problem is likely to be a post hoc process.
As yet, the machinery to do this mostly exists, but there is little in the way of standardised patterns or usage of it to achieve any kind of standardised ‘problem’ document (NB: not the same as ‘problem list’ - which is one level up, and is a managed list of issues considered to be problems, usually inclding current Dxs such as diabetes etc).
To go further, e.g. to automate any of this would be a question of creating rule-sets in which each rule detects a certain kind of content being committed (using an AQL query or AQL path matcher or ADL match expression), and adds a link to that content from the dedicated Composition. Such rules would be evaluated on data commits to the EHR inside a rule engine.
I suspect the best we can do at the moment is to standardise use of the above mechanisms to create problem descriptions in a generic sense. Experimentation with rules over time should eventually generate some reliable patterns.
For many years we collected data items under the heading of Problem in a Problem List f(PrL) or use by one Healthcare Provider (HcP). Then the Episode (Ep) was introduced because GP’s started to collaborate with other HcP’s. The progression of the developments in the Patient System over time cause changes in the title of the PrL and Ep. E.g. PL title = Reason for Encounter (cough); then PL title=Pulmonary infection; then PL title=Tuberculosis; Ep titles probably will have the same titles. The Continuity of Care standard provides a lot a fine detail. In order to make things simple I used my compatible version of the medical treatment model of that standard,
Observation in the Patient system (PS) that is documented
Evaluation of the Observations, PrL, EL, etc leading to differential diagnosis, working diagnosis or determined diagnosis
Planning. Differential Diagnosis will lead to plans with goals to prove or disprove diagnosis or start treatment
Actions. Plans a re broken down to actioned and documented procedures influencing the PS or other (non-PS) systems for administrative purposes such as data exchange, requests, scheduling, updating the PL and/or Ep
Followed by Observations that are documented.
Steps 1 to 4 each have a fixed Pattern Archetype as ENTRY archetype. All PS and Ep’s are collected in distinct FOLDERs the FOLDER shows the progress of the health and care process over time.
SOAP notes should really be considered as ‘persistent’ Compositions (…). If we treated SOAP notes as persistent things that were always retruned to with each new consultation, lab result, and intervention on that problem, the POMR view of things would be very clear. The potential problem, at a computing/data level, is to implement the idea wrongly, and to actually include inline the data items being generated by all these activities, inside the SOAP note. This won’t really work for at least 3 reasons:
• many Obs (including VS & labs) relate to multiple problems, e.g. most vital signs - do you record copies in all (say) 4 extant SOAP notes? No - that kind of data cloning destroys querying.
• quite often, docs and nurses do Obs that don’t relate to a specific problem. In the ER, the problem might not be known for some time; a GP health checkup is not a problem-specific consult… so in these cases, you don’t have any SOAP note to which you would attach the data.
• it is often only clear later on which problems any given Obs, Dx etc relate to, so really, the freedom is needed to commit isolated info (e.g. recorded by patient devices) to the EHR, and then (maybe) link it to SOAP notes later on.
In openEHR, most if not all implementations I know of already operate on a ‘commit-data-now’ basis, without trying to be very POMR. To make an openEHR EHR a POMR, I would say that any SOAP note has to be given a status of ‘persistent’ (or maybe some new status, like ‘ongoing’, which could be changed later), and then, as different treating docs work with patients, they will progressively compile the content of any SOAP note, using linking to committed EHR content. This means a) post-hoc SOAP note building can occur; b) more than one SOAP note can refer to the same Obs, labs, Dx etc; c) querying for clinical Obs, Dxs etc remains independent of SOAP notes and d) SOAP notes don’t get lost in the miasma of past event data, they are instead headline parts of the EHR. In this way, SOAP notes, inasfar as they are used in any given EHR, become a progressively built view of each problem, not just a way of structuring an encounter note.
In a slightly roundabout way, Links from Problem-SOAP Compositiions to Entries committed at other times is essentially the equivalent of tagging, and indeed the UI could easily be built to make it look exactly like tagging, by presenting a list of existing SOAP note problem names, and the ‘tag this under problem X’ action would create the relevant Link.
Literal tagging causes some issues in versioned, medico-legal EHRs, because you are updating the link target, not the logical link source, when there is nothing changing in the target.
it seems to me we should think a bit more about (?semi-)persistent SOAP Compositions, and maybe a related micro-service to make it easy to do logical tagging that actually does the correct linking…
Tagging could be helpful metaphor but I think the magic would lie in defining / agreeing what the LINK types were - ‘caused by’, ‘to investigate’, ‘prescribed for’??? Dunno - would need some work, but that would then allow people to view the data in more logical and useful ways.
Getting people to maintain all that is probably impossible, even with super UI, so probably we would need to find clever ways to automate it - but inevitably it will need some level of manual curation.
As part of SOAP style data-entry the Assessment part might well contain a Diagnosis/Problem entry which may (but may not) appear on the POMR Problem list. Ideally linked back to the original consultation. Problem Lists may be flat and have simple attributes like inactive/active major/minor but may have much more complex nesting to reflect condition grouping, process groupings, temporal groupings.
Some systems in the UK and Netherlands are entirely Problem driven i.e. for every new consultation the clinician must allocate it to an existing problem header or create a new one.
And in non-primary care settings it is common to see Contextual Problem lists - Care plans, Outpatient consults, Speciality Problem lists e.g Renal medicine.
well my epistemological (and non-MD) view is that thinking of a SOAP structure not just as the headings for a ‘SOAP note’, but as the headings for a ‘problem summary’ or similar, could create better quality problem-oriented data in the record.
If there was a small catalogue of ‘problems’ (anything for which a SOAP structure summary already created in the past), each with a title that could be anything from a patient issue (chronic back pain) to a solid Dx (diabetes), then the UI could show that list, and when a new encounter occurred, the doc could create (structured) event notes as usual, and also (by some efficient drag-n-drop) choose an existing problem and attach some of those notes (e.g. patient stmt, phys exam, etc) to it, rather than just creating a new SOAP note.
Or it might be the other way around, where one or more problems is chosen from the list, and the notes created inside them visually, which would still create independent event notes, and links from the relevant problems (i.e. the link could be removed or ignored in the future).
If that kind of approach were used in a fairly disciplined way, it might lead to the emergence of some high-quality problem oriented content in the EHR, in theory making it progressively easier for docs seeing the patient later in time to get an efficient feel for what is going on with that patient.
As an observer it seems to me there has been a lot of effort to codify encounters and make the data in them computable and recallable. Then we create an entity called problem which has little formal connection with this data - it is the synthesis by a sophisticated clinician of a shorthand summary describing that patient in a useful way. This to me is the essence of what I do apart from management decisions of course. Without this the record is just a set of (relatively) raw data. I dont think computers are at the stage where they can replace the clinician in doing this - though it might an interesting AI problem.
The synthesis of a relevant problem list is especially important in multimorbid patients which now form a large proportion of our work.
To me SOAP is a structured way to think about an encounter and is not particularly relevant to a problem list - unless you see the “A” part as the Assessment for the whole patient.
And here’s the second throwback moment: a repost of the discussion on the second topic, dating back from 2014.
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?
“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.
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.
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:
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) ?
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.
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.
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.
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 dependent (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 (PL) as a persistence composition (2nd level),
A problem oriented view that consist of compositions that are related to a power set of the PL (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
Maybe I’m losing some clinical context by adopting a data view of the setting but would not a POMR 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 ?
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.
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. (…)
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.
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 are 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.
I wonder if the GP ‘master care plan’ is more like a ‘care plan dashboard’ rather than an actual care plan? With functions like ‘show all overdue / suspended / etc etc’…
You will need those statuses from every activity in every type of care plan, whether separated or aggregated.
From the general coordinating provider point of view the overwhelming response we hear is that they want one single care plan that covers all problems rather than having to view multiple fragmented ones for each problem, although the ability to see the origins of each activity is also necessary for viewing, sharing in context etc.
This could either be implemented as:
a master view of an amalgamation of all ‘problem’-based care plans, with ability to reconcile equivalent or similar acitvities or lump some together to be achieved simultaneously eg send the patient off for a single blood test at which all due bloods can be done.
Or alternatively it can be a single care plan that uses some method to tag with the problem/s for separation out when clinically relevant.
I don’t particularly mind - it is largely an implementation question from my POV. Our implementations tend to the single care plan
I like this approach. The master care plan is what we call Patient plan. There should be only one of this in a given EHR. This plan evolves over time as more items are addes or removed.
To administer this plan you need a dashboard with functionality to filter on overdue, finished, etc. And of course you need commands like add, update, finish, etc.
The plan is a master view on plan items from different systems and with contributions from all health care specialities. Depending on the users point of view it should be possible to dig into details about specific parts of the plan.
I am not sure if it is possible to archetype this dashboard. I guess this is up to the application to implement this. The clinical modeller should archetype the content of different plan items. To make this work we need a
basic set of INSTRUCTON/ACTIVITY/ACTION archetypes that make the outer boundaries of a care plan and care plan elements.
The single care plan giving way to multiple views makes sense to me as well. I don’t think with so many degrees of freedom in modelling with openEHR we cannot possibly reconcile the many different care plans post-hoc to create the really valuable master view for purposes Heather nicely put. Having spend entire last
week in a major HIS procurement evaluation I must say this looks like the way things are already been implemented in many places around the world! I also have noted the current immaturity of using links effectively to do things just like this - maybe we need some ‘design patterns’ which Tom had indicated some
Another point is, although I haven’t been practicing Medicine for too long now, I know the links between problems vs goals vs actions do not play nicely at all times - indeed for most of the time. They can be subjective and quite error prone. Therefore I don’t think ‘natural order’ (as in DMBS) of an EHR can (note: corrected to ‘can’ in a subsequent post) be of POMR type - it has to follow real life: randomness and episodicity. Maybe we should look at putting a quantifier for the “likelihood” of the links - any thoughts?
Another point is, although I haven’t been practicing Medicine for too long now, I know the links between problems vs goals vs actions do not play nicely at all times - indeed for most of the time. They can be subjective and quite error prone. Therefore I don’t think ‘natural order’ (as in DMBS) of an EHR cannot be of POMR type - it has to follow real life: randomness and episodicity.
Problem orientation is – of course – a best-effort approach. An EHR which “forces” problem orientation facilitates good care by making clinicians think about what things really mean.
What is meant by “randomness” ? “Episodicity” does not at all run counter to problem orientation.
I agree about episodicity not being particularly an issue with problem orientation.
Re: “randomness” I couldn’t find the best expression I guess…What I was referring to is the fact that the information captured by today’s systems can be quite diverse and that stems not from the differences about data entry, coding etc. but more to do with human factors such as the care setting, qualifications and interest of the health professional capturing information, business rules of the organisation, organisational culture and sometimes pure chance. So if the patient has seen been seen by a nurse, a GP, community worker, specialist etc. they may all have own views of the problems and their relationships to goals and actions etc. and eventually any causality type links to observations.
I think the EHR specification and its implementation should provide firm hooks in the data collected to be able to generate different kinds of Problem Oriented Views. I assume this is one solid reason to incorporate some clinical semantics into RM as openEHR does.
one of the lessons we learned in the past is that hooks are needed for the epistemic information types (observation, evaluation, action, instruction, admin) that occur in clinical process, but an ideal version
of the process itself can not be a /requirement/. The Danish board of digital health instituted a model called G-EPJ in about 2005, which had a lot of similarities to the openEHR core Entry types and process. However, in G-EPJ, they made the idealised process, that is, the links from Observation -> Diagnosis -> Intervention etc, a requirement, and they published XML schemas and other artefacts that forced e.g. a Dx to be present as an ‘indication’ for every medication administration, and similar kinds of links.
This didn’t work with industry, for reasons Koray mentions here - in reality GPs sometimes prescribe without a diagnosis as such, nurses and docs administer drugs in hospital without always having an order. And of
course historical records of such events can easily be incomplete, making it impossible to reconstruct data from a legacy EHR into the new required form.
This Danish work was conceptually very good, but a bit naive, and we learned from that - provide appropriate information types, and make it possible to have process links but don’t require them. There are some improvements that could be done today to this, but the basic decision has turned out to be right I believe, based on intervening years of use.
in reality GPs sometimes prescribe without a diagnosis as such
In reality GPs (I am one) often prescribe without a diagnosis. The proverb “The Gods put the Diagnosis before any Treatment” doesn’t hold in GP land. However, GPs (better) never prescribe without a reason. That reason very much is the “patient problem at hand”. There is always a reason for which to prescribe. (if the reason isn’t the patient problem the patient may need another GP If there doesn’t appear to be a reason clinicians better think again.
administer drugs in hospital without always having an order. And of course historical records of such events can easily be incomplete, making it impossible to reconstruct data from a legacy EHR into the new required form.
While that seems like an excellent technical argument the very nature of having documented (generated by import from legacy data), say:
reason = "unknown" / "don't know" / "old stuff"
- drug 1
- order 2
- lab test 3
tells the clinician to think things over when needed and re-arrange. Of course, one might say that it behooves the system displaying such data to flag unlinked artifacts in the above way.
This Danish work was conceptually very good, but a bit naive
Are there links ? Thanks.
and we learned from that - provide appropriate information types, and make it possible to > have process links but don’t require them.
From a technical point of view it is probably very prudent to not require such links (as in, say, a non-nullable foreign key) but the user-facing side of the system as a whole (as long as it is used for individual-patient care rather then epidemiology) should make it, like, “real hard” to forego such links. I suppose I can agree with that approach.
All in all this starts to remind me of whether NULLs should be allowed to happen in a given relational schema or whether any such schema should be further normalized to not require NULLs, right ?
To administer this plan you need a dashboard with > functionality to filter on overdue, finished,
What you seem to be describing is a TODO list to do with solving of pressing issues and is, at best, part of a care plan (in the form of planned repeat procedures, say).
A short-term plan (“handling AMI”, “gall-bladder removal”, …) is a protocol rather than a relevant care plan (“feel well with diabetes”, “improve management of factors contributing to risk of depression”, “sanely approach cardiovascular risk management”).
Patient-centric care plans better concern themselves with long-term holistic goals in terms of salutogenesis.
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).
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.
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.
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
June 2006 readmission
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.
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”.
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.
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?
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.
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.
Crikey @Leuschner!! That’s a serious bit of summarisation., thanks.
In practical terms, here’s how I would start the ‘perfect’ POMR implementation, at least of a GP system.
THe app would be wholly POMR-driven .i.e. every encounter, or part of an Encounter has to start with assigning the record to an existing problem or creating a new one. In the UK , most of the GP systems at one time offered quite sophisticated POMR. The ones that worked (ie POMR well-maintained) were POMR-driven, not POMR as secondary exercise. You can decide what you like the fact that the best POMR app is no longer in business!!
The problem/diagnosis archetype is a good basis for virtually all problem list records. I would expect that original problem-diagnosis to be captured ‘in-context’ - that would normally mean in a GP encounter composition,i.e not normally entered directly into a POMR composition directly, though there might be some exceptions for ‘Contextual Problem lists’ (later!!).
There is a completely separate Problem List composition which manages the list itself, linking out to the original Problem-diagnosis records i.e it does not carry any problem-diagnosis archetypes it self, just points to their original locations. It also manages the status (active, inactive etc) , the start and stop dates, nesting and meaning of linkages. This will need some kind of Problem Thread header and Issue header archetypes or RM component.
was my effort at picking up some of the ideas from Contsys-2.
The main openEHR challenge in here is in managing the linkages and querying across them. It is certainly do-able but it would be nice to work out a more generic RM and/or archetype and associated AQL that made this a little easier. Thomas and I spent a day head-bashing this last year.
I’d strongly re-iterate my suggestion to look at Contsys-2 in this area. Although I don’t agree with all of the ideas in there, I think it does give us some useful new vocabulary to talk about the information structures and relationships without getting tangled in pre-existing ideas and terms.
One of the key ideas that Contsys-2 gets right is that although there is clearly a place for a single longitudinal Problem list (best, I think co-curated by patient and GP) , Problem list type structures appear in Care plans, referral documents, discharge documents, End of life treatment plans etc, etc. Contsys-2 acknowledges that. @johnmeredith (I am a co-author) was due to present a paper at MIE that talks about the ‘contextual problem list’, arguing that the typical Key Condition, Co-morbidities, Complications, Other Problems format is just another kind of Problem list, just with an arrangement of key problem information to fit a particular condition or presentation.
Your example of ‘diabetes’ as a co-morbidity in a surgical admission record is the perfect example. A good surgical record will have constructed a contextual problem list that best prioritises and organises (hinding many immediately unimportant issues) that gives the surgical team the best possible snapshot of ‘things they need to know about’ in terms of their immediate responsibility. It may not function as a true WEED POMR in terms of active/inactive etc but fulfils the same purpose - organise/re-organise potentially very complex and voluminous ‘problems’ into a useful order and level of visibility.