We are doing some work in the area of Cancer Treatment plans and wondering whether we should use existing archetypes (Service request / Medication order etc) or if this area (probably beyond cancer care) merits a different archetype(s).
Our discovery work suggests that the Treatment planning information, though structured, remains at a pretty high-level e.g. it talks about chemotherapy and radiation therapy regimes as against specific medications or radiation dosages. The recording of variation from official protocol or e.g MDT recommendation, is also a significant.
Still working this out but right now we are looking at needing 2 flavours of the Treatment plan, both using an identical template
Active plan which is what is actually being delivered and will be an episodic composition.
Draft plan(s) which will be used until the initial plan is agreed with the patient but also when there may be a need to revise the plan ‘in-flight’, without immediately stopping the active plan i.e. there may be a need to run a draft plan (in discussion) alongside the active plan, until that active plan is superceded . There will potentially be multiple instances of this plan over the course of a patient journey.
Interesting idea which we will look at but I do have slight worry that this idea of ‘draft’ sits at a different level from an incomplete document - it does need to clinically visible to a wide group.
@Paulmiller came across something similar with the Respect form in Scotland, around needing to a have an idea of draft which was available clinically but not clearly signed off and fully active.
Our case really involves a branch in git terms that is merged back into trunk once agreed. I might investigate the specs t see if that might be supported
I agree, the lifecycle state is more a technical status than a clinical one. So it should be judged case by case wether the semantics match. In my experience they usually do. And it’s beneficial to map a clinical status to a technical one, because you can generalise functionality across archetypes. And IIRC there are benefits around versioning, like changing the status without changing the content of a version, e.g. (cryptographic) assertions of a specific version.
The example you mention by Paul seems like a great fit for the lifecycle state.
Branching is imho a different animal, openEHR RM ‘supports’ this: Common Information Model
Your functionality seems more like an automated conditional merge, where the merge is conditional on the value of a datapoint (e.g. an assertion) that’s probably not a clinical content datapoint. much more like GitHub supports with actions and protected branches and auto merge etc.
Found this in the (CIM) spec:
“ One basic rule that must be observed with the use of states is that any transition requires the commit of a new version , even if the content is otherwise unchanged.”
So my remark about versioning benefits are not correct in the way I expressed it. I still vaguely, but sadly can’t specifically, remember there are benefits in this area.
Hey! I would like to share some of our ongoing work at Karolinska regarding the cancer treatment plan. Here are som mind-maps of what we have identified as relevant data so far. Hopefully this can be merged with your work @ian.mcnicoll ?
