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.
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.
we’ve got same challenge few years ago but we don’t have yet a good solution .
1 Like
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
Where can I read up on “View”s?(a)
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
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
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.
Hi Joost,
So many points here to tease out and discuss 
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 . 
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 
Cheers
Heather
1 Like
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
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
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
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
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.
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.
1 Like
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.
2 Likes
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
1 Like
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.