Obsolete status for care plan composition archetype

Specifications RM
41

I remember the core group on GEHR (1992-1995) - @Sam , Dipak, @DavidIngram and others - talking about exactly this scenario! My memory is that we thought logical deletion or somehow else marking the data as ‘bad’ was the right approach. We didn’t have openEHR’s version control design back then of course, much less Version lifecycle.

It’s not really for people like me to pontificate on how you want to clinically represent things like this - the clinical group needs to work out an appropriate semantic solution. I would just re-iterate - I don’t think it’s good generally to use a representation (e.g. archiving) whose semantics are defined a certain way, for a situation whose semantics are quite different. But if you can convince yourselves that archiving rather than logical deletion is more semantically correct, so be it.

I’d actually be in favour of some small addition to the RM to enable marking data as ‘bad’ - not deleted, but to be ignored by certain processes (most querying, unless some flag was turned on - after all you still have to be able to run a query to retrieve bad data for specific purposes).

42

You convinced me. I actually also don’t like mixing up semantics of deletion or archiving with marking data as bad. And agreed on the querying with flag part. We have to think a bit longer together with the clinical group about how to do marking of bad data and wether we can come up with scenarios where archiving events is appropriate. Archiving can still be the most pragmatic solution for a bad data sub scenario. What would a RM addition for bad data look like?
If we can’t come up with scenarios for archiving we can simplify the recommendation around archive lifecycle state: don’t use for event compositions.

1 Like
43

So, just checking, are there these two different use-case you want to gather information form an EHR:

  1. search some values in the whole history, thus across episodes (so just disregard the episode context)
  2. search values that are “now” relevant, perhaps within the current or or another specific episode
    I was thinking that what you want is that while searching within an episode context, you consider all the rest of information “archived”; except those that are part of a persistent composition, which is never “archived”.
44

How is that going to help?

45

That’s also what we are missing at Code24. We can group and index all compositions that ar related to an episode, we could also arrange them in subtrees (subfolders) according to some logic, and with RM 1.1 we could also record more details if needed. But we are not able to point in the EHR to episode-concepts (other than an episode composition under the episode subtree). Whoever will read the data (other then us) will have to know our logic & decisions, solutions, etc. because there is no Episode class.

2 Likes
46

What is an episode? Is it a bunch of encounters relating to a diagnosis? Or is it a series of encounters relating to several diagnoses? I don’t think it’s a ‘reason for admission’, though that should be recorded.
I suggest the missing feature is a ‘hashtag’ recorded against any encounters. diagnoses, measurements, etc. with the person setting the tag as an owner attribute.
The tag would be queryable by anyone, but set or cleared only by the owner.

47

Ad 1 correct.
Ad 2 our current use of (not yet openEHR FOLDERS) episodes is mostly for problem oriented records in elderly care where patients have many (5-20) problems more or less active at the same time:

  • grouping information (text report, documents, questionnaires etc.)
  • around a problem (name of the episode)
  • recording goals and actions on that problem
  • link a diagnosis from problem list
  • it has several dates: start, end (this hides it from the list of active episodes)
  • a date for evaluation, (this will send a notification to the user when an evaluation of the problem is due)
  • authorisation for which discipline (e.g. nurse, md) is allowed acces to the episode and it’s (content)
  • relevant for (e.g. nurse, md) for filtering the list of episodes

For the parts around grouping information the current feutures of FOLDER with object refs to text reports etc is fine. The order of the reports is determined by the date of the individual reports, and the meaning of the reference is implicitly very clear.
But for other stuff it’s as you described it will be very hard for others to interpret. But I’m also missing options to constrain occurrences of specific references: e.g. an episode should have 1…1 reason for admission, 1…1 problem 0…* text reports 0…* goals and as said before the slots for references should have a name (and most of the other features elements have) to confer meaning. We need this to be able to render an episode in our frontend and connect ui (text box, label, order) to the folder structure.

It’s not, it’s a bit off topic, I was just surprised that we have two classes that appear to do the same.

This did made me realise however that LINKs go some way: our editor allows me to set existence to mandatory and cardinality. And they have meaning and type attributes. But they don’t have a fixed path in the FOLDER so how will we link a LINK to a ui element?

It’s a terribly overloaded term. We use it as described above where encounters can be part of multiple episodes usually if the problems are related (e.g. if they’re about both headache and toothache).

This is actually the way we built our UI: reports can be tagged with episodes. It’s easy enough to store the tagged link in the folder instead of the report. But it would be nice to record the reference in the report as well, it’s relevant information for interpreting the report to know it’s been classified as related to an episode. But both scenarios have problems: data duplication, possible inconsistencies, data exchange of only report but not FOLDER wich breaks the information completeness, viewing a reports related episodes is computationally more expensive if you need to query all folders for links to that report, the episode folder can be deleted, while this should not necessarily mean the report should lose the information it’s related to a problem, potential for partial authorisation: view the report but not the episode has potential for incomplete data authorisation etc. Etc.

48

we’ve got same challenge few years ago but we don’t have yet a good solution .

1 Like
49

This is the driver for the ‘View’ concept, which enables views of other EHR content to be constructed, along with other related information. We need to continue the analysis of that.

1 Like
50

Where can I read up on “View”s?(a)

51

A place you already commented: here :wink:

52

So, we’re making progress. The current change request is to add an ‘Obsolete’ lifecycle state. It will not have expected behaviour around mutability specified.
The open question for our clinical community is around wether obsolete data should be returned by AQL queries by default.

  • pro: don’t hide potentially relevant data from the user, user should decide
  • con: obsolete data (inactive problem from an obsolete problem list) can also be a clinical safety risk if unclearly presented to the user. And clinical decision algorithms may make wrong recommendation if not taking obsolete data into account.
  • migration perspective: obsolete data will only end up in your CDR after implementing it, so if we don’t return obsolete data via AQL by default, your’re not missing anything and there’s a chance to verify obsolete data is adequately presented/CDS processed and it’s not a problem . The other way around is more risky.

@bna @ian.mcnicoll @Paulmiller @heather.leslie @siljelb @varntzen others, please?
https://openehr.atlassian.net/browse/SPECRM-107

1 Like
53

Coming late to the party and probably not fully understanding the full thread, my thinking is that event-based COMPOSITIONS like documents may need a lifecycle of incomplete/published etc to know when the clinical content is ready for public release/publication to the health record.
However something like a care plan at COMPOSITION level should be persisted forever, one place to query for whatever content is available, or not. In that vein the various ‘sub care plans’ that an individual gathers or completes over time are recorded under this umbrella COMPOSITION. As such, we have INSTRUCTION.care_plan and ACTION.care_plan to track progress, including completion or aborting a sub care plan. Possible ‘sub care plans’ include immunisation (eg default creation of ‘infant immunisation’ for all on creating a birth record), then various ones that are added over time for preventive health based on age & gender or problem/disease-specific protocols.

The importance of one overarching Care Plan COMPOSITION, updated over time, is that there is a single source of truth. Often there may be care plan tasks that are effectively duplications eg Blood pressure checks for preventive health and a diabetes plan that need to be managed and ones scheduled close together should be recorded as a single entry, as well as managing/scheduling potential conflicts eg the BP item needing to be completed monthly in one plan and 6 monthly in another. There needs to be a way to reconcile all of the potential care plans such that the GP (or any other provider) can do the Blood Pressure at a specific visit and it checks off all the other BP recording requirements within agreed time frames eg 2 weeks before or after a proposed ‘due date’ to prevent the patient needing to reattend for a BP measurement in too close a proximity to another measurement.

In this way a ‘sub care plan’ for the ‘Infant vaccination schedule’ would be active at birth, ‘completed’ after the last of the infant schedule of vaccinations, and a '5 yr+ childhood immunisation schedule added at 5 years of age, whether or not the infant schedule had been completed. Then it becomes a clinical issue to reconcile the vaccinations and modify the vaccination plan as a ‘catch up’ schedule. As soon as they are diagnosed with Juvenile onset diabetes, the care plan for that is added… The care plan evolves over time to match the patient care needs. The ‘Care Plan’ as an EHR entity (COMPOSITION-level) never obsolete, but the content waxes and wanes, in fact it needs to support anything happening to a ‘sub care plan’ for each clinical purpose eg the immunisation schedule needs to be modified due to the diabetes diagnosis. This potentially ever-changing scenario needs to be managed via the INSTRUCTION/ACTION pair IMO.

COMPOSITION.care_plan
INSTRUCTION.care_plan
ACTION.care_plan - authored in 2011 to support the above scenario

If we have multiple Care plan COMPOSITIONs in an EHR, I don’t see how the integrated view can be managed. If they are all separate and fragmented this is not providing patient-centred care. It is complex, but if we can get it working, it would be rather magnificent.

1 Like
54

Maybe first my definition of care plan:
“A document style collection that lists all problems the patient has, what goals are set for each problem and what actions are taken to achieve that goal.“
E.g.
Hypertension | systolic < 180 | losartan 2dd

The list may be ordered by a methodology (ICF, SFMPC/nanda/Omaha etc) and problems/goals/actions may be limited by sets from that methodology.
The document can further contain/link information like advance care plan, allergies, medical history etc.
And it can contain administrative data: who (persons/disciplines) is involved in care, who is responsible for managing the plan, monitoring the problem, carrying out the action etc.

Context info: in Dutch elderly care there are often two care plans in use: the medical one, which is the personal responsibility of the physician and the nursing one which is the responsibility of the organisation delegated to a caregiver/nurse. The nursing plans should be checked by the doctor not to conflict with the medical one. They may be unified in a single ‘document’ and methodology, but this rarely works well for the doctor. Issues are:

  • nursing methodology too restrictive for medical problems (e.g. Hypothyroidism is not a possible problem in Omaha methodology)
  • conflicting responsibilities (nurse has to process and unify the doctors problems into the plan)
  • different perspectives on the problem and scope of goals (nurses view functionally and well-being , doctors are biochemically and complication prevention oriented).
  • a unified care plan is usually very large, making quick overview problematic
  • different update cadences: nursing plan is updated yearly, doctors plan updated weekly or daily

Etc.
So this leads me to conclude that it’s not possible to unify all care plans in a single composition. There still is a lot of overlap in the care plan structures: problem(goal(action)). And a lot of problems/goals/actions are shared and require involvement from multiple disciplines (medical/nursing/therapist/social worker). So what we’re currently striving for is each sub plan as a separate composition (with eval.problem/eval.goal/action.care_plan structured by sections)and separate FOLDERS to index those compositions into a medical care plan and a nursing care plan.
Older designed archetypes are linked in a previous post in this topic.

What we would really like is to design this in such a way that it also allows inclusion and collaboration from other professionals that work from a different organisation and EHR deployment.
Our analysis into mental healthcare says it’s possible to use the same problem/goal/action structure but the scope of a plan there is limited to a single problem.
From my experience in hospital care I’d say this is possible as well.
And GP’s probably will also be able to work with this structure, however my experience there is limited to a few weeks.

So now a sub care plan can lose relevance, e.g. a UTI has been cured by antibiotics. So it should be marked as ‘archived’: no longer relevant for daily care, but should be kept according to local legal requirements and for later rereading. And it should be possible to reactivate it, e.g. if a new UTI presents, to keep the change history.

So, there are two intertwined issues at hand here:

1: is it possible to have a unified care plan in a single composition? (No)
2: can a VERSION clinically be considered as ‘obsolete’: keep it, but don’t consider the information up to date (yes)

Now if we agree on 1 and 2 (please also answer the next question if we don’t):
Should an ‘obsolete’ care plan/problem list/advance care plan/etc. turn up in a default AQL query? My pro’s and con’s for yes/no are in my previous post, some more info in the linked specrm/pr.

55

Hi Joost,

So many points here to tease out and discuss :exploding_head: although I expect that we may be more aligned than it seems at first glance.

Another point is that we need to prioritise the display of a care plan that is relevant to the clinical role of the viewer, and the patient. In fact, we need to be able to provide a variety of views, hence my idea of the sub-plans - so that the endocrine physician can see the Diabetes plan relevant to them, and the Diabetes nurse can see the relevant items for them. The GP can see both and the tasks related to their practice.d

In the community space in AU there is an increasing role for a care coordinator who actively manages the care plans and assigns tasks to members of the appropriate care team. So there are times when all care plan items need to be viewed as a whole, but others where only a specific subset should be viewed and actioned, based on their role in the community or hospital care team. So, for this model to be successful, there needs to be a coordinator - if not the patient, then someone appointed. It still won’t be perfect but aiming to avoid duplication and ensure tasks are ticked off using the patient time and provider resources as efficiently as possible.

So I’m prioritising some different things, assuming slightly different work processes etc, and I’m pushing back gently again, even if only to play devil’s advocate a little - you still need to decide what works within your environment . :sunglasses:

If a sub-plan for UTI is completed, then the ACTION should be recorded as complete and the completed items removed from the active care plan - both doc and nurse need to be informed of this, and there needs to be a protocol about who records it as complete and in what timeframe to ensure the plan is up-to-date.

In an ideal, fully integrated world I think it is desirable to be able to make a single care plan available for viewing, where every item is potentially viewable. In lieu of that nirvana, we should strive to achieve as much transparency for all the tasks required for this patient as we can in the environment we have control over. Whether the underlying structure is a single COMPOSITION or a view comprised of multiple data sources, is up to the implementer. However, that master (monster?) care plan also needs to be filtered, sliced & dices in many ways so that it can be a useful tool within clinical practice. The design should be as flexible as possible, that’s why I’d rather speak in terms of filtered views (subsets) presented to the end user rather than fixed folders etc - then it can grow and evolve via querys or filters as clinical practice changes, new roles are added, etc etc rather than changing/evolving the storage mechanism with new queries etc.

I don’t really think in terms of a sub-plan as obsolete. It is completed, suspended or aborted etc in ACTION pathway terms. I’m not sure that this should be a COMPOSITION attribute.

If you want to query care plans, then you definitely need to first define if it is active or not, and ensure that this is prominently displayed. Again, a master/monster list will need clever querying on currency/clinician role/ tasks due within the next x wks etc to display the relevant items for the clinician role/location etc.

It is the most complex of complex EHR tasks that we’re discussing here!

It is almost certainly impossible to come to conclusions about care plans on a thread like this - needs more like a week-long F2F workshop :rofl:

Cheers
Heather

1 Like
56

Arguably most application forms would be built to do what is expected from each such form, possibly with a button that reruns the query with obsolete=on (or off). As long as it is easy to run such a query (it should be), I suspect that the default is less important than we might have originally thought on yesterday’s call.

Whether there really is one care plan (with sub-parts) or just multiple plans would seem to be the existential question. Do we know what clinician and cultural (e.g. US v Germany v Spain v Korea v…) preferences look like here?

Yes this is a recognised question but is advanced functionality, and probably does argue for a single over-arching care plan with a common ‘actions’ section. The logical reason for this is that the patient him/herself is a ‘singleton’, i.e. there is only one physical entity to which actions can be applied, not many. Same with medications. So either a single list is created and curated over time, or else there are multiple carers / institutions doing their own thing, and probably nurses or GPs get to figure out how to merge the disparate list actions (or medications) onto the patient. The former is at best inefficient, and the latter is positively dangerous, which is why a single source of truth medication list is so important.

I think your argument here says: we should think about care plans the same way.

EDIT: I missed @joostholslag 's reply - he provides cogent reasons why there might not be a single care plan, at least not as a single Composition/document entity. I am less worried about single Composition as well - the view in Task Planning is that multiple Work Plans for a patient will be in multiple Compositions.

So perhaps the concept we need is a top-level whole of patient coordinating meta-plan. And the singleton problem doesn’t go away: multiple lists of actions or medications to be applied to the patient are likely to become incoherent / dangerous.

1 Like
57

I guess that is what I’m proposing… but support smart ‘slicing & dicing’ as needs be for a given viewer/clinician role/clinical context/location etc - describing a common approach but end-user preferences/requirements determines what they see. A diabetes specialist may only want to see the tasks that are relevant for their speciality, but it would be useful to be able to see the other items required by other sub plans - in that way care can be better coordinated or tests scheduled to require one visit instead of two etc.
It will still only work within one integrated ecosystem, which is clearly a long way away from our current reality, but there is utility in describing a common approach to optimise flexibility or allowing simpler local solutions as required.
It would be of great value if we can provide guidance for the aspirational, best practice solution principles, and the models to support such an implementation. .

1 Like
58

I think we are closely aligned on the requirements. Your idea of different views on the But I’m quite convinced it shouldn’t be a single mega composition with actions per sub plan. But composition per sub plan. And that sub plan can be obsolete. Maybe thinking of episodic problem lists is easier to think about obsolete state, could I please also get feedback on that part of the question?

1 Like
59

Even though I was not asked explicitly, I would like to express support towards this ‘obsolete’ state term. It comes close to a need we also had few years ago.

On the other hand, from a technical mind/perspective, I think is not only useful for care plans, but also for other use-cases, some also mentioned by Joost above. Perhaps slightly better functionality (but more complex) can be achieved by grouping data in a context of episodes, and considering (de-facto) ‘obsolete’ everything that is recorded in other episodes (thus outside of the ‘current-episode’ context).

1 Like
60

I’m really struggling to understand the use of ‘obsolete’ in a health record - it implies something is no longer used, out of date, more like a mobile phone that has been replaced with a newer version because it can’t connect to the network.

Instead, to me the care plan is dynamic - any sub care plan (ie individual sub careplans per condition/protocol/vaccination schedule etc) can be planned, scheduled, suspended, aborted or completed - as can each of the individual component tasks/activities.

Obsolete seems more a category implying that this is a piece of information we don’t query it for current activities- we don’t know if it is incorrect or out of date etc so I don’t understand the value of labelling data in this way because I can’t interpret it meaningfully. And of course, in medico-legal terms nothing in a health record can be obsolete because of the need for provenance and a relevant & coherent clinical history.

I really don’t care how a care plan is implemented at the technical level, but IMO the ideal care plan has to be designed so that the master/monster can be viewed if necessary as well as providing filtered subsets appropriate for the viewer.

The per COMPOSITION approach seems clumsy to my non-tech thinking because so many sub-plan activities are not mutually exclusive from another sub-plan, so I can’t imaging how they can be clearly separated.