I’ll second that. I have three care plans under Medicare as a patient: one is active with two sub-plans and supersedes another, the third was several years ago.
None are likely to be flagged as obsolete; the date in the record is sufficient to indicate the status.
The problem with this perspective is this is largely a technical problem with different solution, and we’re looking for input on the clinical safety issues of the proposed solution.
Let’s put aside the master composition/vs composition per sub plan for a moment please. Since it’s a separate issue.
The problem is: if I have different versions of a single care plan composition, how do I know (technically) which version is the ‘active’ one and which ones are old/outdated and which ones are future plans yet to be activated. Normally one assumes the latest ( complete) version is considered the current one. However with plans this isn’t always true, a draft plan version can be the newest version and (technically) complete, but not to be considered active clinically. So we want to be able to mark versions as not active (incomplete or obsolete). More info and alternative (technical) approaches are described in the linked specrm and specpr
This is exactly the implications I’m looking for.
It’s primarily something to be interpreted by the application. And the app can map it to something clinically interpretable in a given context. E.g. a technically obsolete version of a care plan, can be shown in the UI to be clinically/legally considered archived: “no longer in use, kept for archiving purposes, no longer to be guaranteed to be true/current information one can depend on”. (Like we use incomplete to indicate draft forms).
We previously considered calling the state ‘archived’ but that triggered expectation from software engineers that it could be stored on a backup tape outside the main system and should be immutable. Since this isn’t necessarily what we’re aiming for, we changed it to obsolete.
Other suggestions are welcome.
We will off course discuss the plan design: master vs seperate indexed compositions further, but maybe a live conversation would be helpful:)
Are they plans from multiple doctors from different specialties and from different institutions? How is coordination handled? May the cardiologist overwrite the plan from the endocrinologist (random examples)? If not (probably), they should be separate compositions, since the “compositions is the smallest unit that should be authorised, since the entire composition is needed to reliable interpret the clinical statements it contains. EHR Information Model
Also the date isn’t always sufficient, a neurosurgical care plan from when 30 years ago a ventricular peritoneal drain was placed, stating “visit doctor immediately in case of hydrocephalus signs” will be active life long. While a (version of) a plan from a surgeon that says take opioids in case of pain after surgery can be obsolete a few days later.
Hmmm - I wouldn’t expect to see this in a care plan… This is more like patient education to me.
I’d expect this to be an INSTRUCTION/ACTION pair that sets the time frame, and it expires after then few days
My point is that ‘can be obsolete a few days later’ is a passive status, noone is going to bother to update the record. The GP who started the plan may be too busy to coordinate the plan; they might update it the next time the patient visits, but more likely will be looking at a new event.
I sense a difference in perspectives. My requirements are from a nursing home setting, where an elderly care physician intensively manages a small group of patients with complex multimorbidities using a care plan. Where the care plan is a list of sub plans which in turn consist of a problem one or more goals for that problem and one or more actions for those goals.
That makes sense. But it would also make sense to record that action in a care composition, right? So what happens to the composition after it’s lost relevance?
Don’t forget most of the data in a long term health record is irrelevant (for current care - research obviously a different thing) after some days/weeks/months - most obs & labs, physical exams, and even minor diagnoses (infections, small injuries etc). It’s the persistent Compositions and (more recently) episodic Compositions of recent dates that matter.
Time (currency) is the basic criterion for determining relevancy. So I don’t think we should assume that unless old content is specifically marked obsolete it is going to get in the way. I think Care plans and some kinds of problem lists are likely to be the main candidates for this idea (as per your original analysis).
Agreed. I think the default should be information in event category compositions are always to be (clinically) judged for currency, where time lapsed is indeed (usually) the most important criterion. This is routine clinical practice, often unconsciously.
For persistent compositions I’d like towards the status that they can by default be assumed to be current. (Off course for patient safety reasons the responsibility for checking this assumption remains with the healthcare professional). And should be marked obsolete if the information no longer is safe to be assumed current. (Known outdated, unmaintained archived etc).
Episodic compositions are a bit trickier and currency probably depends on the status of the episode. Which is not specified in openEHR afaik.
If we agree on this it may make sense to add this to the spec as descriptions/comments with the lifecycle states as part of the specrm-107.
This is the nub of the issue - whether the COMPOSITION could/should lose its relevance.
In my current thinking, there is only one COMPOSITION that carries all the tasks (per EHR, per aged care home, whatever context), forever. It doesn’t become obsolete at all because there is always something to do, even if it is only the next tetanus vaccination in 10 years time. If it is empty then there are no designated tasks until someone adds one but in this situation it is precisely because it is empty that we know there is nothing outstanding! If we have multiple COMPOSITIONs with varying states of currency that will be a challenge to query consistently, track activity states, and coordinate in a single setting with more than one practitioner - even worse in an integrated care setting with a multidisciplinary care team.
So the COMPOSITION carries the INSTRUCTION/ACTION pair for each sub plan, perhaps held within a SECTION for the purpose, plus the INSTRUCTION/ACTION pairs and goals for each clinical activity/task etc. This may need something like an INSTRUCTION index to support slick querying (@thomas.beale @heath.frankel ??) and filtering.
Maybe care plan is not the best use case. What are the use cases for other persistent COMPOSITIONs to become obsolete?
How about a problem list, let’s say the GP keeps a persistent problem list, now the patient is transferred to the hospital, (single EHR/federation/different EHR with post hoc data exchange) and the surgeon starts their own problem list, the GP’s one should be marked obsolete imho (and reactivated after discharge probably). Now we will end up at the same discussion probably, since I expect your view to be the surgeon should update the gp’s problem list, right?
I would again argue it’s unfeasible (technically impossible in the case of seperate EHRs afaik) and probably undesirable, since so much context (author, setting) and metadata (authorisations) has changed recorded in the composition. And most importantly the perspective has changed too much, GPs look at problems totally differently than surgeons do: DM to a gp is a condition that requires chronic management, to a surgeon it’s a higher risk of wound infection and someone you need to consult the diabetologist on to ‘fix those sugars’. If you take a nurses problem list and a doctors problem list, this difference in perspective grows even more problematic.
Now you may suggest in turn to have different views for surgeons, GPs and nursed on a single master problem list composition? And I than again would say you’ll run into issues like described above. Moreover would you be ok with recording DM2 three times(surgeon, gp, nurse) in that master composition? More info on the different perspectives on problem here: Audience specific problem name - #6 by ian.mcnicoll
(where from my previous thoughts, I still argues for the opposite I’m arguing now, I got convinced by Ian)
I do agree why you want to keep it closely together, it’s a single patient and single biochemical alteration off course. And integrating facilitates collaboration, and the current systems disjoint is one of the main reasons for working on openEHR. However I’ve come around to the idea that it’s better to record separate compositions and link problems together to keep them aligned.
This can even be using a single (medical) problem list, managed by a single doctor (if the healthcare system has such a coordinating person as the Netherlands does) that indexes other problem(lists). This can be done using a persistent composition with repeating DV_(EHR_)URI or FOLDERs, depending on whether it’s mostly a document or mostly an index.
Hi Joost,
No
It is hard to respond in a thread like this, maybe one day we’ll be able to get back to F2F meetings and this would be a great topic for inclusion in a modelling conference.
In an ideal openEHR world with shared health records, perfect data merging and an assigned Problem List coordinator, there would be a single problem list that can be filtered and ordered according to the viewer - in this case the GP view will be different to the renal physician and the community nurse not because any one of them shouldn’t have access to view the full list of problems, but what is considered a priority for GP chronic disease management is not the same for the renal physician who is managing only the chronic renal failure and all other diagnoses are effectively background considerations.
But it is tricky to try to mirror this across the reality of disparate systems - in fact, we can’t and probably shouldn’t. We can share a problem list between providers, but it should be up to them to include them in a local Problem list as EVAL.problem_diagnosis (or not) and also to potentially assign them relevant qualifier status (CLUSTER.problem_qualifier) that is relevant to the receiving care context. So the Problem/Diagnosis list can be kept applicable to all, but the context of primary or secondary diagnosis etc can be configurable per healthcare provider. Divergence may occur, but the intentional design of EVAL.problem_diagnosis level of information is key to supporting alignment when sharing, and the qualifier is usually only relevant at the local context level.
Again, I don’t think any Problem list would ever become obsolete, we just need to track its currency and update accordingly.
Just to add to the complexity, I suspect Nursing diagnoses should also be recorded using a separate archetype again because of the different semantics. DM2 would be recorded using the EVAL.problem_diagnosis but care-related risks and diagnoses should perhaps be recorded with slightly different semantics, although these could all be added to the local comprehensive problem list - again, filtering is key here.
Look forward to talking soon
Heather
This is a long thread containing many parallell and overlapping topics.
For the there are (at least) three topics here:
Topic 1: Do any vendor, system or application need a way to mark a composition as archived or obsolete?
Yes they do.
Topic 2: Should obsolete/archived compositions be included in the result from an AQL query?
I have no strong opinion on the default except it need to be the same across all openEHR platforms/CDR. The applications and developers of those applications will need to look into the requirements for the specific case. And implement the use-case at hand regarding what to show and when to show the data.
Topic 3: How do we implement Care plan in openEHR?
Look into the Task Planning specification if you need to implement clinical process- and decision support.
I think Contsys have solved the definitions for episode, episode of care, etc. quite good. It’s always my reference when discussing such terms. It’s needed to have a useful conversation on how data are connected through a clinical process.
Most of the process related concepts fits reasonably well with #openehr folder. I would have modelled them years ago if we didn’t have the concept of episodes, periods, contacts, etc in our system before we went into #openehr.