We have failed if that’s what you read 
This specific section might help a bit.
Here’s the next level of detail description.
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.
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.
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 [SPECPR-125] - openEHR JIRA), 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.
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.
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). (GitHub - joostholslag/archetypes
Could you share yours?
I’d love to align designs. Since we’ll need that to be able for our users to work together on care plans.
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
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.
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…).
Conceptually, ecumenically, musically, aesthetically, umbilically… please don’t do this!
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.
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. EHR Information Model.
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.
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.
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.
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:)
My thinking as well.
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?
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.
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.
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.
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).
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.
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.
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.
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.
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).
Agreed.It is a nice compromise to not technically prohibit archiving of event compositions but stating recommendations like in this topic:
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.
I’m wondering btw, since folder records list of object refs, why does a folder not record a list of DV_(EHR_)_URI?
And a composition contains a list of content item, can those also be other compositions and folders? Feels strange to me…