# Obsolete status for care plan composition archetype **Category:** [RM](https://discourse.openehr.org/c/rm/42) **Created:** 2021-10-11 09:20 UTC **Views:** 2665 **Replies:** 73 **URL:** https://discourse.openehr.org/t/obsolete-status-for-care-plan-composition-archetype/1927 --- ## Post #1 by @joostholslag Care plans in our software undergo a lifecycle from, draft -> active -> archived. where draft -> active depend on stuff like, completeness and sometimes attestation (by other care giver and/or client). And active -> archived usually is caused by changes in the clinical situation, that lead to a new version of the care plan, usually duplicated from the old one, where the old one is 'archived'. I know there is a lifecycle state for a versioned object. That has an incomplete status which would work for indicating draft status, and complete that works for active status. But the only other option is deleted, and imho that should be reserved for other usecases than archived. So any thoughts about adding a code for archived to the terminology for lifecycle state? The alternative approach, would be to add a status element to the archetype, as suggested here: https://discourse.openehr.org/t/lifecycle-state-in-ehrbase/1567 But my current understanding is that this usecase is generic enough (relevant for many persistent compositions, and maybe all versioned objects) so it could be part of the reference model. --- ## Post #2 by @Seref Just to clarify Joost: I was not suggesting adding a status element to the archetype. I was referring to the idea of having a dedicated CDR instance with more relaxed constraints on validation. I have no comments regarding what the lifecycle status of a composition in that CDR may be. I was referring to the case in which a composition is not in a state that's valid openEHR data, but still must be worked on using an openEHR based/backed application. --- ## Post #3 by @ian.mcnicoll Hi Joost, Our approach, based on trying to manage similar situations (and there are still some mixed ideas about!!) 1. 'Incomplete' as composition lifecycle state, for when an openEHR composition has been started but really is not 'safe' clinically to be queried normally. In our example of End of Life, some clinicians feel it important to be able to work on and perhaps share a composition 'privately' but where a 'normal' query would not find it. This is where lifecycle_state = incomplete is helpful, especially as the most recent spec says that mandatory validation checks can ignored. Some folks, Seref included, think this is better handled by a separate CDR, but I'm happy to laeve that open to implementers to decide the best approach. 2. We also have had other clinicians , say , we do not need 'incomplete' as a composiotn 'technical setting' - anything is better than nothing, but we would also like to put some sort of maturity indicator on the document based on local rules. e.g. It is draft vs published. Technically it is queryable but perhaps has not had key fields filled on or is not signed off. 1 and 2 are not contradictory, indeed I understand the Scots are using both for their ReSPECT document. 3. These are both is related to, but different from the lifecycle of the Care plan itself, which will go from 'planned' to 'active', to finished or aborted etc. We are using an ACTION archetype to handle this - it is a local variant of the international ACTION.care_plan - I need to review if we still need that variant but it handles these states in the UI, mapped to the appropriate careflow_steps. Seems to work pretty well. Consent given Consent declined Consent withdrawn Patient died Patient moved away https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGNjYTY5ODExOWUyNDQzMjQ5OGQ4NmYwNThkZDI4MDBi --- ## Post #4 by @Seref [quote="ian.mcnicoll, post:3, topic:1927"] as the most recent spec says that mandatory validation checks can ignored. [/quote] That's news to me. Can I be lazy and asks for a link? That'd remove the distinction between type 1 and 2 'incomplete's we've been talking about in this thread. [quote="ian.mcnicoll, post:3, topic:1927"] Our approach [/quote] which one of your hats you're wearing when you say "Our" here ? :) --- ## Post #5 by @ian.mcnicoll "Our" - freshEHR - working on End of Life Care planning in UK. I may have jumped the gun on the 'incomplete' beahviour issue - I had thought it had been agreed and into the specs but I can't find the PR etc. Discussion [here](https://discourse.openehr.org/t/special-treatment-of-incomplete-versions/420/2) --- ## Post #6 by @thomas.beale [quote="ian.mcnicoll, post:5, topic:1927"] I may have jumped the gun on the ‘incomplete’ beahviour issue - I had thought it had been agreed and into the specs but I can’t find the PR etc. [/quote] [SPECRM-97](https://openehr.atlassian.net/browse/SPECRM-97) --- ## Post #7 by @joostholslag [quote="ian.mcnicoll, post:3, topic:1927"] Hi Joost, Our approach, based on trying to manage similar situations (and there are still some mixed ideas about!!) 1. ‘Incomplete’ as composition lifecycle state, for when an openEHR composition has been started but really is not ‘safe’ clinically to be queried normally. In our example of End of Life, some clinicians feel it important to be able to work on and perhaps share a composition ‘privately’ but where a ‘normal’ query would not find it. This is where lifecycle_state = incomplete is helpful, especially as the most recent spec says that mandatory validation checks can ignored. Some folks, Seref included, think this is better handled by a separate CDR, but I’m happy to laeve that open to implementers to decide the best approach. 2. We also have had other clinicians , say , we do not need ‘incomplete’ as a composiotn ‘technical setting’ - anything is better than nothing, but we would also like to put some sort of maturity indicator on the document based on local rules. e.g. It is draft vs published. Technically it is queryable but perhaps has not had key fields filled on or is not signed off. 1 and 2 are not contradictory, indeed I understand the Scots are using both for their ReSPECT document. 3. These are both is related to, but different from the lifecycle of the Care plan itself, which will go from ‘planned’ to ‘active’, to finished or aborted etc. We are using an ACTION archetype to handle this - it is a local variant of the international ACTION.care_plan - I need to review if we still need that variant but it handles these states in the UI, mapped to the appropriate careflow_steps. Seems to work pretty well. Consent given Consent declined Consent withdrawn Patient died Patient moved away [/quote] Re 1: I think there’s something to say for adding `archived` as a lifecycle state, because it can indeed mean the context of the information is changed in such a way that the data is no longer clinically relevant/safe to query normally. Until I know how we can move this discussion forward we’ll model this with a status element on the composition like report. But it’s problematic because of 1 and because a plan does not have an event context, which is confusing at least and bad modelling at worst imho, and it gives specific problems like a setting and start time being mandatory while there’s no data that makes sense here. We’re probably using null flavours for now, but that’s annoying workaround on a workaround. Or am I missing something? There’s also the lifecycle of the plan itself which could indeed be an instance of the state machine. But using an action for this breaks the openEHR [concept model of recording](https://specifications.openehr.org/releases/RM/latest/ehr.html#_context_model_of_recording), since data in an ENTRY should not contain information about the COMPOSITION it contains, right? --- ## Post #8 by @joostholslag Aand, I just learned null flavours won’t work because this is not an element:s --- ## Post #9 by @thomas.beale [quote="joostholslag, post:7, topic:1927"] Re 1: I think there’s something to say for adding `archived` as a lifecycle state, because it can indeed mean the context of the information is changed in such a way that the data is no longer clinically relevant/safe to query normally [/quote] The problem with that is that in theory someone would have to go back through everything in every patient record and mark data items that are no longer relevant, which is obviously not realistic. But we have a simpler heuristic: whatever is in a persistent Composition, generally managed lists, e.g. Problem list, Meds list, allergies, Family history etc, is assumed to always be valid, because they are curated to be so. Whatever is in Event Compositions, generally Obs, Dx, Rx and actions might or might not have meaning much later. A long history of BP over 160 has meaning as does an old Dx of type I diabetes; but old Rx for amoxycillin or radiology for ankle sprain most likely means nothing. But it depends on what the query purpose is. Might be some research looking for overuse of amoxycillin, or why people playing certain sports have a high historical rate of ankle sprains. You never know what clinical data is going to get used for later on... --- ## Post #10 by @joostholslag Yes, I agree with those statements about persistent compositions assumed to be always relevant. (and very much agree with event compositions only being relevant in the context of that event). But how about episodic compositions? And also for persistent compositions there can be multiple stored compositions in the CDR right? How would you indicate which is the 'active' one, and what to do with the no longer active one? --- ## Post #11 by @ian.mcnicoll For persistent compositions the most recent version is always the active one. Exactly the same for episodic compositions, I'd have thought. That's the whole point of a persistent composition - there in only ever one 'active' instance fo the document - everything else is a previous version. - accessible but not through normal querying. --- ## Post #12 by @joostholslag [quote="ian.mcnicoll, post:11, topic:1927"] the most recent version [/quote] Most recently created, or most recently edited? or with the most recent time in the EVENT_CONTEXT? or one of the other many dates in a template on persistent composition? And I don't think whatever datae we decide on, is going to hold: there can be multiple active care_plans in one CDR... The psychologist, the nurses, the elderly care physician can each have there own active care plan. But even for a single user, there's a requirement to mark a careplan as 'archived', because a new version is now the active version. And this is not automatic, because a new care plan first has to be finished, approved and marked active, it's not just the last edit date or created at date that determines which one is active. --- ## Post #13 by @thomas.beale [quote="joostholslag, post:12, topic:1927"] Most recently created, or most recently edited? [/quote] Either. openEHR is a true versioned health record: whatever changes you make to one or more Compositions, including creation of new ones, will form the new versions of the next state of the record. Each set of changes is a change set, which we call a Contribution in openEHR. So the 'top' versions of all versioned content in the record constitute the current information of the record. ([more explanation](https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_versioning_2)). --- ## Post #14 by @thomas.beale [quote="joostholslag, post:12, topic:1927"] But even for a single user, there’s a requirement to mark a careplan as ‘archived’, [/quote] Yes, that could make sense. Indeed, we probably have to think more about lifecycle of things like Care Plans. --- ## Post #15 by @ian.mcnicoll I understand the need to 'archive' a previous Care plan but I don't think that should be at RM level - for me this needs to be a viable, queryable, though historical record, flagged as 'archived' or inactive or whatever at composition level. UI issue as to whether you want to retrieve only the current active care plan for e.g a mental health care plan or whether you want to see historical documents as well. We have been using an ACTION careplan archetype to manage the state of the care plan, where it has that kind of defined status. --- ## Post #16 by @thomas.beale [quote="ian.mcnicoll, post:15, topic:1927"] We have been using an ACTION careplan archetype to manage the state of the care plan, where it has that kind of defined status [/quote] Just for amusement value: a) the ISM, on which ACTION states are based has no idea of 'archived', and b) this is what the `DV_STATE` was designed for ;) --- ## Post #17 by @joostholslag Thank you for the explanation. But if I read the specs it’s all about versions of a single stored composition. Then it makes sense each change is a new version of that stored composition, and the latest version is easily identifiable. But if there are multiple stored compositions (of a template on persistent composition care plan) those are in separate versioned object containers right? How do you now know which is the most recent one? And how do you record which is the active one, (not always the most recent one, as mentioned before). I now realise there’s two use cases here that may need to be handled differently: A single user creates a plan, activates it, then makes a ‘new’ plan (new composition or new version of the stored composition?) and until that is marked active (could be months later) and the old one marked archived, the old one is the one considered active. If we say in this usecase the new unactivated plan should be a new version of the same stored composition we need a way to label a `VERSION` as `active`/`archived`. It already has a lifecycle state, so to me it makes most sense to expand on that. But I don’t really care if something else is better from an engineering pov. And we need to solve the second usecase: if multiple users of the same CDR each have their own care plan for the same patient, how do you keep track of which care plan to show to which user? --- ## Post #18 by @joostholslag [quote="ian.mcnicoll, post:11, topic:1927"] That’s the whole point of a persistent composition - there in only ever one ‘active’ instance fo the document... [/quote] Agreed in principle off course, but: the scope of that is not the patient: it is the (group) of user working together on one EHR. Different user(groups) can have different instances of a persistent composition (e.g, docs and nurses each have their own problem list). AND The most recent one is not automatically the active one for care plans, as it first has to be activated/approved/attested/finalised whatever. So that logic doesn’t hold for this usecase. And it’s easy to see it’s a valid usecase right? --- ## Post #19 by @joostholslag [quote="ian.mcnicoll, post:15, topic:1927, full:true"] I understand the need to ‘archive’ a previous Care plan but I don’t think that should be at RM level - for me this needs to be a viable, queryable, though historical record, flagged as ‘archived’ or inactive or whatever at composition level. UI issue as to whether you want to retrieve only the current active care plan for e.g a mental health care plan or whether you want to see historical documents as well. We have been using an ACTION careplan archetype to manage the state of the care plan, where it has that kind of defined status. [/quote] If you flag the COMPOSITION how do you handle, the most recent VERSION not being the active one? I do think it should be solved at RM level. But I could live with solving it at composition archetype level. But even that is hardly doable at the moment. Due to design choice of compositions only allow expansion of event context, and for persistent composition mandatory start time and locations don’t make sense and can’t even be nulled. (Persistent compositions don’t have a context of event in clinical practice imho) And sorry Ian but I fundamentally disagree with this modelling pattern of using a ACTION entry to record the status of the containing composition due to: [quote="joostholslag, post:7, topic:1927"] using an action for this breaks the openEHR [concept model of recording](https://specifications.openehr.org/releases/RM/latest/ehr.html#_context_model_of_recording), since data in an ENTRY should not contain information about the COMPOSITION it contains, right? [/quote] But I feel we’re struggling to understand each other and start going in circles, we (Nedap) really needs a solution here and if we (openEHR) don’t solve it, Nedap probably end up with some hack giving technical debt and limiting interoperability later at best and clinical safety risks at worst. So how can we move this further? Maybe an SEC discussion, or a smaller scale video call? Maybe I can give a demo of how this ui works in our legacy app? --- ## Post #20 by @ian.mcnicoll I think there probably is some mutual misunderstanding, and some different use-cases. We are right in the middle of this world right now and maybe we should setup a call to thrash out some of these issues as best we can and report back. --- ## Post #21 by @thomas.beale [quote="joostholslag, post:17, topic:1927"] Thank you for the explanation. But if I read the specs it’s all about versions of a single stored composition [/quote] We have failed if that's what you read :( This [specific section](https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_change_management) might help a bit. Here's the [next level of detail description](https://specifications.openehr.org/releases/RM/latest/common.html#_change_control_package). [quote="joostholslag, post:17, topic:1927"] But if there are multiple stored compositions (of a template on persistent composition care plan) those are in separate versioned object containers right [/quote] If it's the same logical care plan, but modified versions over time, then it is a single Versioned object, containing many versions. If we are talking about clinically distinct care plans, then each of those will be its own Versioned Object, each with its own Versions in each of those Versioned Objects. This should solve the final question. --- ## Post #22 by @sebastian.iancu [quote="thomas.beale, post:21, topic:1927"] If it’s the same logical care plan, but modified versions over time, then it is a single Versioned object, containing many versions. If we are talking about clinically distinct care plans, then each of those will be its own Versioned Object, each with its own Versions in each of those Versioned Objects. [/quote] That's what we also do @joostholslag. Also, our version timeline is linear (i.e. we don't support version branching). Thus the last version of a version container is also the active version of that container. In addition we use Folders to handle Episodes, and each Care Plan is stored 'within' an episode. There might be more than one Care Plans within one Episode, but on application level ensure one is active at a time, we store a status flag info inside composition. --- ## Post #23 by @sebastian.iancu [quote="joostholslag, post:18, topic:1927"] Different user(groups) can have different instances of a persistent composition (e.g, docs and nurses each have their own problem list). [/quote] Your approach at Nedap is I think different then ours, as we don't store everything in one single huge care plan composition, but we use several smaller scoped compositions (things like ACTION, EVALUTION, etc), all referred from the care plan. In our case, a care plan is active once we have an informed consent, which we 'mark' it also on each of these small dependent compositions, per version at the time the consent is received. Later changes on the care plan requires new informed consent, and while that is yet not received, the newly created versions are not considered to be 'active', but 'pending' (but all have lifecycle 'complete'). Around 3-4 years ago we also asked SEC for a change in lifecycle (see https://openehr.atlassian.net/browse/SPECPR-125), but as that was not accepted, we chased other solutions. I can however relate to investigate and discuss in the SEC the need to add 'archived' to lifecycle. --- ## Post #24 by @ian.mcnicoll >>> we use several smaller scoped compositions (things like ACTION, EVALUATION, etc), all referred from the care plan. That is also our approach, as we are working towards managed care information, rather than care plans per se, with different care plans sharing thematic compositions e.g living arrangements, Advance intervention information, Needs and preferences, none of which are tightly bound to any particular care plan. We are not using Folders but probably closer to that idea in design terms. We should definitely have a wee workshop to compare and contrast as I think this is really great area for openEHR. --- ## Post #25 by @joostholslag This explains a lot of the confusion. My design is one plan, one composition with sections for each problem and it’s goals and actions(instruction). (https://github.com/joostholslag/archetypes Could you share yours? --- ## Post #26 by @joostholslag I’d love to align designs. Since we’ll need that to be able for our users to work together on care plans. --- ## Post #27 by @joostholslag [quote="sebastian.iancu, post:22, topic:1927"] our version timeline is linear (i.e. we don’t support version branching). Thus the last version of a version container is also the active version of that container. [/quote] This is why we need the archived status: The status flow we need is draft->active->archived. This could be mapped to the current options in the following way: draft -> incomplete (default after creation/edits) active -> complete (if: technically complete, logically complete, and consent=attestation, user sets marks (button press) the plan as active/complete archived = complete AND there is a newer complete version in the stored composition But this logic breaks if: - there are multiple stored compositions at the same time. e.g. a patient receives treatment in an ambulant setting and the EHR contains GGZ_plan_1, now he gets into a crisis and receives crisis treatment (by a user of the same CDR) described in GGZ_plan_2. How do you know if GGZ_plan_1 is active or archived? - edits will need to be done to both the active plan (typos, small additions not needing new attestation, etc) and to draft plans. I discussed with @ian yesterday that the alternative approach would be to record status in an element in an action entry in the composition (or event_context). But we agreed this is conceptually wrong and violates the openEHR containment model of context recording I mentioned earlier. His view is though that this is clinically safe and we should first experiment before changing the RM. My opinion is I don’t feel comfortable with the clinical risk and technical debt these alternatives introduce. And I think the addition of ‘archived’ to lifecylce_state terminology is warranted at this point. So I created a Pr: https://openehr.atlassian.net/browse/SPECPR-383?filter=11103 Re [quote="thomas.beale, post:9, topic:1927"] The problem with that is that in theory someone would have to go back through everything in every patient record and mark data items that are no longer relevant, which is obviously not realistic. But we have a simpler heuristic: whatever is in a persistent Composition, generally managed lists, e.g. Problem list, Meds list, allergies, Family history etc, is assumed to always be valid, because they are curated to be so. Whatever is in Event Compositions, generally Obs, Dx, Rx and actions might or might not have meaning much later. A long history of BP over 160 has meaning as does an old Dx of type I diabetes; but old Rx for amoxycillin or radiology for ankle sprain most likely means nothing. But it depends on what the query purpose is. Might be some research looking for overuse of amoxycillin, or why people playing certain sports have a high historical rate of ankle sprains. [/quote] I like this thinking and agree we should discourage marking event compositions as archived and relevance should rely on the reader interpreting the event context etc. I’m a bit less convinced on the persistent compositions. (There may be multiple persistent problem lists, it’s valuable to mark one as archived if it’s no longer maintained). But my main point is about episodic compositions. The alternative approach could be to relax the constraints on compositions: add elements outside of event_context, or add a different context for episodic/persistent compositions. I think this should be done as well, but may be too big a change for the current small (but important) requirement. --- ## Post #28 by @thomas.beale [quote="joostholslag, post:27, topic:1927"] This is why we need the archived status [/quote] *I'm now convinced on archived status for persistent and probably episodic Compositions*. For both, it would mark them as something that was in long-term use, and is a) no longer in active clinical use but b) can still be looked at (how did this patient's 15y oncology plan look, before the AcmeAmazingPharma cure was given that killed the cancer...). [quote="joostholslag, post:27, topic:1927"] I discussed with @ian yesterday that the alternative approach would be to record status in an element in an action entry in the composition (or event_context). But we agreed this is conceptually wrong and violates the openEHR containment model of context recording I mentioned earlier [/quote] Conceptually, ecumenically, musically, aesthetically, umbilically... please don't do this! [quote="joostholslag, post:27, topic:1927"] I think the addition of ‘archived’ to lifecylce_state terminology is warranted at this point. [/quote] Yep, that is the way to do it. The challenge is just to work out the modified state machine, and what real world happenings constitute the transition events. --- ## Post #29 by @joostholslag [quote="thomas.beale, post:28, topic:1927"] Yep, that is the way to do it. The challenge is just to work out the modified state machine, and what real world happenings constitute the transition events. [/quote] Great! I’d say the transition will mostly be done by a user (e.g. button click). Reasons to mark an (episodic) composition as archived could be: there is a new version of a care plan, due to clinically significant changes in needs for treatment (new problems, problem solved, first line treatment failed, treatment options finished) and the old plan has lost relevance (other than for historical information, which may be very important for clinical, legal, research etc reasons). One could automate archiving a care plan, if it’s part of an episode of care (e.g. hospital admission, 6 month mental health care outpatient treatment) that’s no longer active. But we probably should think a bit more about what info relating to that episode should be archived before recommending this. I’m thinking folders here. @sebastian.iancu probably has something to say on this. For a persistent problem list, the curator may have changed (new GP) that fundamentally disagrees with the list and creates a new one, and archived the old one. Or the patient gets admitted to the hospital where the surgeon has a totally different perspective of what the patients problems are and creates a new problem list and the old one can never be resumed without acknowledging the interim. (Btw this is also an argument to consider the problem list as context (setting, time, practitioner perspective) specific). Even event compositions might make sense to be archivable. We really should be careful to not trigger archiving everything as pointed out quite nicely by Thomas. But let’s say a BP measurement device turns out to be unreliable. It probably makes sense to archive the observations taken from this device, since they’ve lost relevance for their main use: reflecting BP. The alternative would be to filter the BP graph AQL on this device, I think this is quite cumbersome. And if you as a user, unaware of the faulty device, retrieve the specific composition with the BP observation, you would still need some warning the device was faulty. Deleting the composition would be an acceptable alternative, but this probably hides it from most users, while it may still contain relevant (meta) information. E.g. what the approximate BP was can still be useful (maybe the device was always low), at what time it was measured and at what setting (patiënt probably was at that setting), billing purposes etc. etc. At least I think there’s no need to specify that the archived status can not apply to event compositions. There are probably versioned objects where archived status does not make sense at all e.g. https://specifications.openehr.org/releases/RM/latest/ehr.html#_versioned_ehr_status_class. But for most I can see it be useful: folder, EHR access, composition. Are there more? So I’m hopeful we can skip the complexity of specifying which versioned object are allowed to have an archived lifecycle state. --- ## Post #30 by @sebastian.iancu [quote="joostholslag, post:29, topic:1927"] which versioned object are allowed to have an archived lifecycle state [/quote] Maybe it is just my code solutions, but usually such conditional constrains on RM level are ugly to be implemented in the CDR. I would prefer allowing it always on RM level, and facilitate it on application level - which is rather on the AM level. [quote="joostholslag, post:29, topic:1927"] One could automate archiving a care plan, if it’s part of an episode of care (e.g. hospital admission, 6 month mental health care outpatient treatment) that’s no longer active. But we probably should think a bit more about what info relating to that episode should be archived before recommending this. I’m thinking folders here. @sebastian.iancu probably has something to say on this. [/quote] As said before, we use FOLDERs to model Episode and their contains. If that episode has to be archived, its contained items can be easily "scanned" (by consulting the tree), and than all archived. We are not very happy with this setup, where an Episode is a compound of a FOLDER and a COMPOSITION, conceptually we are missing an EPISODE class in EHR IM, something like FHIR's EpisodeOfCare but in openEHR style ... The logic and workflow around our Episode is programmed on application level, If you will now look only to our data, you'll miss the big picture. --- ## Post #31 by @joostholslag [quote="sebastian.iancu, post:30, topic:1927"] Maybe it is just my code solutions, but usually such conditional constrains on RM level are ugly to be implemented in the CDR. I would prefer allowing it always on RM level, and facilitate it on application level - which is rather on the AM level. [/quote] So I take it you agree with my goal of not specifying it, and allow implementers to decide on which objects and at what level to define the scope of archived state? The latter is primarily an engineering decision, so please don’t listen to my opinion too much:) [quote="sebastian.iancu, post:30, topic:1927"] As said before, we use FOLDERs to model Episode and their contains. If that episode has to be archived, its contained items can be easily “scanned” (by consulting the tree), and than all archived. [/quote] My thinking as well. [quote="sebastian.iancu, post:30, topic:1927"] We are not very happy with this setup, where an Episode is a compound of a FOLDER and a COMPOSITION, conceptually we are missing an EPISODE class in EHR IM, something like FHIR’s EpisodeOfCare but in openEHR style … The logic and workflow around our Episode is programmed on application level, If you will now look only to our data, you’ll miss the big picture. [/quote] Why is an episode of care a folder *and a composition*? In my mind it should be just a folder. But I’m not sure we will be able to put all relevant data about the episode in the other_details. It’s archetypeable, so should be fine. But I’m struggling with data like, setting, time, care team. For some of this data there are already entry archetypes defined, which cannot be included. They can be stored in composition and linked, but then your back at an episode *being* a folder *and* a composition. Wish I agree is ugly, since episode of care is a singular clinical concept, so should be a singular model. Not sure episode of care should be a new RM class, it feels overkill to me. But it would allow for defining containment relationship that data should have with an episode of care, instead of the more vague linked/associated relation folders express. And that would enable setting episode access, status etc in a conceptually more fitting way than with folders. E.g. your example of archiving compositions if the folders that links them are archived, gives trouble in case a composition is linked from multiple folders, only one of which is archived. A containment relationship of the episode of care class would solve this, since containment should be singular (but may be a singular hierarchy). Curious for thoughts, but maybe split this into a new topic? --- ## Post #32 by @sebastian.iancu [quote="joostholslag, post:31, topic:1927"] Why is an episode of care a folder *and a composition*? In my mind it should be just a folder. But I’m not sure we will be able to put all relevant data about the episode in the other_details. It’s archetypeable, so should be fine. But I’m struggling with data like, setting, time, care team. [/quote] We have that folder-composition pair as we are still on RM 1.0.2, but also for the reasons above, to record clinical context of that episode - which I don't find it right to be placed under FOLDER.other_details. [quote="joostholslag, post:31, topic:1927"] E.g. your example of archiving compositions if the folders that links them are archived, gives trouble in case a composition is linked from multiple folders, only one of which is archived. A containment relationship of the episode of care class would solve this, since containment should be singular (but may be a singular hierarchy). [/quote] yeap, we bumped into this dilemma/issue also - not sure what would be best. It is anyway a bit strange to explain why the specs refers to "episodic" composition, but there is no "episode" concept defined in RM. --- ## Post #33 by @thomas.beale [quote="joostholslag, post:29, topic:1927"] But let’s say a BP measurement device turns out to be unreliable. It probably makes sense to archive the observations taken from this device, since they’ve lost relevance for their main use: reflecting BP [/quote] I would not try to do this. It's hard to say if observations that were slightly / very wrong are no longer relevant - since clinical decisions may easily have been made based on them - and even interventions. Some of the preventable deaths in all health systems (80k per annum in the US) are certainly due to decisions made on very bad observational data, but the latter is probably pretty rare (data entry and reading errors are much more common causes). Such bad data can already be logically deleted. I would not like to mix up the semantic of 'archived = valid, but no longer in clinical use' with actually wrong data. In any case, data generated by most devices is pretty reliable - any really bad errors get spotted very quickly, e.g 50% SpO2 for patient who is happily reading a book in bed and conversing with a nurse. So we're mostly talking just grades of accuracy - e.g. +/-3.5% rather than the spec +/-2.5% or so. Do we throw out observations like that? Who would even find them? Unlikely they would ever be spotted. Whether we technically prohibit archiving of event Compositions is another thing, but if such a thing is used in strange ways, it will reduce data interop, even among openEHR systems. What we recommend to be the use of openEHR for real scenarios is thus quite important. --- ## Post #34 by @thomas.beale [quote="joostholslag, post:31, topic:1927"] Why is an episode of care a folder *and a composition*? In my mind it should be just a folder [/quote] A Folder on its own isn't content; it's just a container for content. THe content has to be elsewhere (i.e. in Compositions). [quote="joostholslag, post:31, topic:1927"] Not sure episode of care should be a new RM class, it feels overkill to me. [/quote] Episode of care has been discussed for nearly 20y ;) It's definitely not a class - it's a collection of EHR entries relating to some problem / type of care, during a time period. Technically it is therefore some kind of *index* of other content. Since not everything that is recorded in the EHR during the time period is necessarily to do with the related episode of care - e.g. some items might be unrelated patient-recorded data, or data from another kind of health professional - an episode is not simple the bock of data items committed between two time-points. Normally, it is (roughly) those items between two time-points that are created with the same Composition.context.health_care_facility. Theoretically we could have an attribute in which some episode-of-care tag(s) could be recorded, but it's hard (I've always been told by clinical professionals, and I believe them) to know what to put there in advance (could be date of admission, if secondary /tertiary care) because what appears to be an episode could change partway through (patient gets admitted with chest pain, goes to cardiology, turns out to be something else). Could one go back and retrospectively mark items as being in the same episode, but we are not in the business of creating more work for docs, so not really an option. So I think the best we can do is to create a 'view' that acts as a managed index, and can be built mostly automatically; in this solution, An 'episode of care' is thus something quite similar to a problem list that we discussed some time ago. Using FOlders is a way to do this, that at least Code24 and DIPS use. Ideally, all openEHR would use the same approach, so that not just data items, but entire sections of EHR are mutually comprehensible across sharing systems. --- ## Post #35 by @sebastian.iancu [quote="thomas.beale, post:34, topic:1927"] it’s a collection of EHR entries relating to some problem / type of care, during a time period. Technically it is therefore some kind of *index* of other content. [/quote] I agree with above, but we also think that an episode is also a (shared) context for those indexed content items. If it would be only a grouping tool, then a FOLDER will do the job. If besides grouping you'll need to record other administrative info, there is FOLDER.other_details. But if a clinician-minded person argues that the context should also record care/clinical information, then the solution would be to use/attach also a Composition to capture that data. But all these are implementation choices (on app-level), and the results are just some objects - the semantic is not very obvious if you look to the data. --- ## Post #36 by @thomas.beale [quote="sebastian.iancu, post:35, topic:1927"] But if a clinician-minded person argues that the context should also record care/clinical information [/quote] I am assuming they would; above I used the term 'EHR entries' in its most general sense. In openEHR, this is of course Compositions, in which the specific Entries are found. --- ## Post #37 by @joostholslag [quote="thomas.beale, post:33, topic:1927"] I would not try to do this. It’s hard to say if observations that were slightly / very wrong are no longer relevant - since clinical decisions may easily have been made based on them - and even interventions. Some of the preventable deaths in all health systems (80k per annum in the US) are certainly due to decisions made on very bad observational data, but the latter is probably pretty rare (data entry and reading errors are much more common causes). Such bad data can already be logically deleted. I would not like to mix up the semantic of ‘archived = valid, but no longer in clinical use’ with actually wrong data. [/quote] They are different things wright, data entry errors should be (soft) deleted, with recording the reason for deletion, to be able to recall why a discussion has been made. It has maybe also value to keep it visible if the real value is easily apparent from the wrong data, e.g. bp 80/120 or temp 437.1 centigrade. A device error is arguably different, depending on wether the care profession is seen as the observer (she observes the BP value on the measurement device’s screen, that observation of the value is not wrong) or the device is the observer (the device, due to being wrongly observes a BP. ). This could both be solved by soft delete but it’s less evidently wrong so I prefer archiving. [quote="thomas.beale, post:33, topic:1927"] In any case, data generated by most devices is pretty reliable - any really bad errors get spotted very quickly, e.g 50% SpO2 for patient who is happily reading a book in bed and conversing with a nurse. So we’re mostly talking just grades of accuracy - e.g. +/-3.5% rather than the spec +/-2.5% or so. Do we throw out observations like that? Who would even find them? Unlikely they would ever be spotted. [/quote] I disagree about really bad error getting spotted quickly. If a device wrongly gives a normal value that’s hard to find. E.g. 100% sat while sat is 87%. Many more potential scenarios, many with huge safety risks. My situation is where a device is found to be faulty and all precious measurements should be considered unreliable. They should still be kept in the EHR but archived (or deleted as discussed above). [quote="thomas.beale, post:33, topic:1927"] Whether we technically prohibit archiving of event Compositions is another thing, but if such a thing is used in strange ways, it will reduce data interop, even among openEHR systems. What we recommend to be the use of openEHR for real scenarios is thus quite important. [/quote] Agreed.It is a nice compromise to not technically prohibit archiving of event compositions but stating recommendations like in this topic: - Don’t routinely archive event compositions, but rely on the RM event model to let the user determine relevance. So as to not create unnecessary admin work for clinicians. - Marking objects as archived indicates they are no longer true in the current context. But were valid at the time of recording. - Be careful with marking events as archived and only use it for data that was relevant at the time of recording but in hindsight is no longer to be considered relevant at that time (e.g. faulty device) but not due to normal changes in context (patient has medications changes). -more? --- ## Post #38 by @joostholslag [quote="thomas.beale, post:34, topic:1927"] A Folder on its own isn’t content; it’s just a container for content. THe content has to be elsewhere (i.e. in Compositions). [quote="joostholslag, post:31, topic:1927"] Not sure episode of care should be a new RM class, it feels overkill to me. [/quote] Episode of care has been discussed for nearly 20y :wink: It’s definitely not a class - it’s a collection of EHR entries relating to some problem / type of care, during a time period. Technically it is therefore some kind of *index* of other content. [/quote] Hmm, I’m not sure I agree it’s just an index. What I’m struggling with is how to record the meaning and structure/order of the indexed content. E.g. a reason for admission, may be a reason for encounter, or a diagnosis. But I’d need a coded text to specify the reasons. And I want to record that for an episode one specific reason is the reason for admission. I think there should be a slot in the folder with a name of reason for encounter. Similar for domains in our elderly care plan use case: a care plan is a folder of multiple problems-goals-actions-compositions. The problems are ordered by domain in a fixed structure . Somatic, Functional (mobility etc), Social, Communication (hearing, reading etc) and Psychologic. How do I model this using only a list of object refs? To conclude I believe an episode may also record information, meaning, structure etc. --- ## Post #39 by @joostholslag I’m wondering btw, since folder records list of object refs, why does a folder not record a list of DV_(EHR_)_URI? --- ## Post #40 by @joostholslag And a composition contains a list of content item, can those also be other compositions and folders? Feels strange to me.. --- ## Post #41 by @thomas.beale [quote="joostholslag, post:37, topic:1927"] My situation is where a device is found to be faulty and all precious measurements should be considered unreliable. [/quote] 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). --- ## Post #42 by @joostholslag [quote="thomas.beale, post:41, topic:1927"] …logical deletion or somehow else marking the data as ‘bad’ was the right approach… 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… 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 [/quote] 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. --- ## Post #43 by @sebastian.iancu 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". --- ## Post #44 by @sebastian.iancu [quote="joostholslag, post:39, topic:1927, full:true"] I’m wondering btw, since folder records list of object refs, why does a folder not record a list of DV_(EHR_)_URI? [/quote] How is that going to help? --- ## Post #45 by @sebastian.iancu [quote="joostholslag, post:38, topic:1927"] Hmm, I’m not sure I agree it’s just an index. What I’m struggling with is how to record the meaning and structure/order of the indexed content. E.g. a reason for admission, may be a reason for encounter, or a diagnosis. But I’d need a coded text to specify the reasons. And I want to record that for an episode one specific reason is the reason for admission. I think there should be a slot in the folder with a name of reason for encounter. [/quote] 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. --- ## Post #46 by @Colin_Sutton 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. --- ## Post #47 by @joostholslag [quote="sebastian.iancu, post:43, topic:1927"] 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”. [/quote] 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. [quote="sebastian.iancu, post:44, topic:1927"] How is that going to help? [/quote] 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? [quote="Colin_Sutton, post:46, topic:1927"] 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? [/quote] 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). [quote="Colin_Sutton, post:46, topic:1927"] 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. [/quote] 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. --- ## Post #48 by @sebastian.iancu [quote="joostholslag, post:47, topic:1927"] 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. [/quote] we've got same challenge few years ago but we don't have yet a good solution . --- ## Post #49 by @thomas.beale [quote="joostholslag, post:38, topic:1927"] What I’m struggling with is how to record the meaning and structure/order of the indexed content. E.g. a reason for admission, may be a reason for encounter, or a diagnosis. But I’d need a coded text to specify the reasons [/quote] 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. --- ## Post #50 by @joostholslag Where can I read up on “View”s?(a) --- ## Post #51 by @thomas.beale A place you already commented: [here](https://discourse.openehr.org/t/cross-reference-citations-and-a-solution-for-managed-lists/1355) ;) --- ## Post #52 by @joostholslag 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 --- ## Post #53 by @heather.leslie 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](https://ckm.openehr.org/ckm/archetypes/1013.1.1656) [INSTRUCTION.care_plan](https://ckm.openehr.org/ckm/archetypes/1013.1.1653) [ACTION.care_plan](https://ckm.openehr.org/ckm/archetypes/1013.1.1655) - 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. --- ## Post #54 by @joostholslag 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. --- ## Post #55 by @heather.leslie 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 --- ## Post #56 by @thomas.beale [quote="joostholslag, post:52, topic:1927"] pro: don’t hide potentially relevant data from the user, user should decide [/quote] 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. [quote="heather.leslie, post:53, topic:1927"] 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 [/quote] [quote="heather.leslie, post:53, topic:1927"] The importance of one overarching Care Plan COMPOSITION, updated over time, is that there is a single source of truth. [/quote] 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? [quote="heather.leslie, post:53, topic:1927"] 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. [/quote] 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. --- ## Post #57 by @heather.leslie [quote="thomas.beale, post:56, topic:1927"] So perhaps the concept we need is a top-level whole of patient coordinating meta-plan. [/quote] 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. . --- ## Post #58 by @joostholslag 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? --- ## Post #59 by @sebastian.iancu [quote="joostholslag, post:52, topic:1927"] 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*. [/quote] 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). --- ## Post #60 by @heather.leslie [quote="joostholslag, post:58, topic:1927"] 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. [/quote] 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. --- ## Post #61 by @Colin_Sutton 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. --- ## Post #62 by @joostholslag [quote="heather.leslie, post:60, topic:1927"] 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 [/quote] 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 [quote="heather.leslie, post:60, topic:1927"] it implies something is no longer used, out of date [/quote] [quote="heather.leslie, post:60, topic:1927"] 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 [/quote] This is exactly the implications I’m looking for. [quote="heather.leslie, post:60, topic:1927"] 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. [/quote] 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:) --- ## Post #63 by @joostholslag [quote="Colin_Sutton, post:61, topic:1927"] 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. [/quote] 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. https://specifications.openehr.org/releases/RM/latest/ehr.html#_overview_3 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. --- ## Post #64 by @heather.leslie [quote="joostholslag, post:63, topic:1927"] visit doctor immediately in case of hydrocephalus signs [/quote] Hmmm - I wouldn't expect to see this in a care plan... This is more like patient education to me. [quote="joostholslag, post:63, topic:1927"] take opioids in case of pain after surgery [/quote] I'd expect this to be an INSTRUCTION/ACTION pair that sets the time frame, and it expires after then few days --- ## Post #65 by @Colin_Sutton 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. --- ## Post #66 by @joostholslag 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. --- ## Post #67 by @joostholslag 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? --- ## Post #68 by @thomas.beale [quote="joostholslag, post:67, topic:1927"] So what happens to the composition after it’s lost relevance [/quote] 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). --- ## Post #69 by @joostholslag 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. --- ## Post #70 by @heather.leslie 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? --- ## Post #71 by @joostholslag [quote="heather.leslie, post:70, topic:1927"] Maybe care plan is not the best use case. What are the use cases for other persistent COMPOSITIONs to become obsolete? [/quote] 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: https://discourse.openehr.org/t/audience-specific-problem-name/1924/6?u=joostholslag (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. --- ## Post #72 by @heather.leslie Hi Joost, [quote="joostholslag, post:71, topic:1927"] I expect your view to be the surgeon should update the gp’s problem list, right? [/quote] 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 --- ## Post #73 by @bna 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](https://specifications.openehr.org/releases/PROC/Release-1.6.0/task_planning.html) if you need to implement clinical process- and decision support. --- ## Post #74 by @bna [quote="thomas.beale, post:34, topic:1927"] Episode of care has been discussed for nearly 20y :wink: It’s definitely not a class - it’s a collection of EHR entries relating to some problem / type of care, during a time period. [/quote] 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. https://contsys.org/concept/episode_of_care 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. --- **Canonical:** https://discourse.openehr.org/t/obsolete-status-for-care-plan-composition-archetype/1927 **Original content:** https://discourse.openehr.org/t/obsolete-status-for-care-plan-composition-archetype/1927