Assumption 1
These should be recorded using the openEHR-EHR-ACTION.procedure.v1, both for inseration and removal
Assumption 2
It is a good idea to create a template “Catheter procedure” or similar using the openEHR-EHR-COMPOSITION.report-procedure.v1 and including openEHR-EHR-ACTION.procedure.v1
That was for recording of information.
Question
Next question is around whether to use a persistent composition for this use case. We always want to see a list of catheters (and similar things currently inserted into the patient), sounds similar to requirements around allergies, medications, problems etc that have persistent compositions. What would be a good option for something like this:
Use the Problem list which can also contrain procedures
Create a new persistent composition archetype for “Catheter list” (or better named)
Ignore persistent compositions and just query the relevant procedure entries?
Finally, you want to relate care plans to these catheters for managing cleaning/infections. Does that impact the above decision, could it be easier or more difficult to relate care plans (not referring to any specific openEHR implementation of a care plan, just the wider business concept) if it is an entry on a persitent composition list?
This must be a common use case, so hopefully others have thought about it before
ACTIONS to record if/when those INSTRUCTIONS were carried out or skipped, discontinued etc.
OBSERVATIONS of catheter sites - signs of infection etc.
We spent a lot of time specialising the device archetype for different classes of catheter. which is one thing I would do differently now - I think it is generally better to accept the huge variation in catheter devices and arguably create a separate per-catheter - or catheter type) to slot in as further detail than using specialisation.
I can see the argument for persistent compositions but we did not and I still would not go down that road here. This is a situation where it should be possible to track ‘dynamically’ the catheter insert-review-remove lifecycle using INSTRUCTIONS and ACTION in Encounter compositions. The work is being done and is being documented. It can be challenging technically to track complex instruction/action states but is is doable. I would probably not have specific catheter procedure composition template but just embed the stand catheter pattern (embedded templates can be helpful here) into e.g regular Nursing encounter compositions. The initial Instructions might be part of a Catheter care plan composition, with subsequent Actions referring back there.
Persistent compositions are helpful when the data needs curated e.g. problem lists / allergy lists, or where it might be theoretically possible to do device tracking e.g. something like a hip replacement or pacemaker if every part of the system was recording correctly but over time and in a very distributed environment this is likely to break down. So having a curated list of ‘devices’ for safety purposes is probably the best that can be done.
Around this point, I find clients or onlookers start saying or thinking - wow - ‘why is openEHR so complicated’ ! But actually these kind of questions are really about the weird and brain-sapping/energising world of clinical informatics, and all that openEHR does is support some possible options by having a few pre-built concepts like persistent compositions, instructions and actions. Someone still has to do the hard work of figuring out exactly what the client needs or wants.
If you could look inside any healthIT system and you will find exactly the same challenges and a huge variety of approaches to solving the same sort of issue.
I think this is a good starting position, and captures the high level use case.
“This is a situation where it should be possible to track ‘dynamically’ the catheter insert-review-remove lifecycle using INSTRUCTIONS and ACTION in Encounter compositions.”
Think we need to play around a bit here to see how to slice this. But might skip the persistent composition to start with. If we come up with something useful or have additional questions we’ll raise them here!
I agree - the dynamic approach feels doable (and we did do it!) but it does depend on the local ability to capture enough data to make it work. Same applies to using a care-plan as the ‘focus’ for the cycle. That makes perfect sense if the staff are used to creating a Catheter Care plan as they will already be used to the documentation overhead that implies but in other settings that ‘care plan’ may be more implicit.
We use CVC/PVC in the emergency app for the circulation assessment and actions. In that context, sometimes you don’t have the INSTRUCTION, just the ACTION, alongside with an OBSERVATION (ACTION+OBS in the same COMPOSITION), ACTION to track status changes and data specific about the procedure, with some OBSERVATIONS for the body site + catheter size + extra info.
On ICU and other levels of hospitalization an INSTRUCTION applies better than for emergency. But I totally agree with Ian. Having an INSTRUCTION, that would be INSTRUCTION+ACTION on the first COMPOSITION to set the initial status of the request.
I guess also the TASK PLANNING could be used for tracking, but I’m not familiar with that model.
I think task planning imay be a solution, because its not all about insertion and removal, but also replace, that encompass both. For the user point of view, no one wants to record remove catheter and insert a new one, when they just want to record that a replacement was done.
To list all the medical devices that a patient has and how many days they are exposed to, is very relevant for infection control. So, find a way to express the presence of a device should be more standardized and not dependable of local solutions.
So, find a way to express the presence of a device should be more standardized and not dependable of local solutions.
Yup I agree but there really have to be 2 separate approaches…
Where each ‘device’ event (insertion, review, removal, replace etc) is captured rigorously (preferably supported by task-planning but you still need instructions, actions etc). That is the gold standard but it does involve a lot more development and ambition by the customer.
Just manually a maintain a ‘register’ of ‘current devices’ - we do have a devices summary archetype for this. THis is simpler but does require someone to manually curate the register and keep it up to date.
But you are right. We should start trying to document these different examples, even if alternative approaches might be required.
Considering the ACTION approach, not a specific archetype, any change of status can be recorded, since you map the ISM states with your real world statuses, so if you have those 3 statuses in the ACTION archetype, I don’t see the issue. Now, if the specific archetype doesn’t have those, it could be edited.
From the TP model what you get is a more detailed workflow specification with actionable items, that could help to semi-automate some record flows. But in terms of tracking those 3 statuses, either works (EVAL+ACTION vs. TP).
and that might help with one of the other issues, which is the granuality of the INSTRUCTION e.g. ‘Catheter management’ vs. ‘replace/remove/inseret etc’ which again will be down to local policy /custom.
