How would you map a “pharmacy drug dispense” task, where the patient comes with a prescription and a clerk delivers the medication packages?
I was thinking this is clearly and ACTION, but also seems to be an ADMIN_ENTRY, since it is just a delivery of some product.
I’m inclined to think it as an ACTION if this task alters the state of the prescription INSTRUCTION ISM. On this case, as a parallel question, I’m not sure if the dispense ACTION should be a final “COMPLETED” state, what happens if we want to record the patient’s intake of the drug? Where the real “COMPLETED” is when the treatment is finished.
> > I'm inclined to think it as an ACTION if this task alters the state of
> the
> > prescription INSTRUCTION ISM. On this case, as a parallel question, I'm
> not
> > sure if the dispense ACTION should be a final "COMPLETED" state, what
> > happens if we want to record the patient's intake of the drug? Where the
> > real "COMPLETED" is when the treatment is finished.
>
> That might mean that some INSTRUCTIONs never get COMPLETED
> until the patient dies.
>
>
There is a state "EXPIRED", so that is covered IMO if an expiration date is
recorded, or even if the whole system has preconfigured expiration dates
for drug treatments.
I meant to say that some treatments will not end until the
patient dies meaning that the COMPLETED state will never be
reached if we take into account
[...] the patient's intake of the drug [... where] the
real "COMPLETED" is when the treatment is finished.
I know this was modeled. Just wanted to understand the rationale behind choosing an ACTION vs an ADMIN_ENTRY, this is to help me create an exercise for my students. And for ACTION, if the dispense should be an active of final state, and from your message it seems I was on the right path, not thinking this as a final state since more actions can happen after the dispense, like the one I mentioned of the patient recording intake.
> > > I'm inclined to think it as an ACTION if this task alters the state
of
> > the
> > > prescription INSTRUCTION ISM. On this case, as a parallel question,
I'm
> > not
> > > sure if the dispense ACTION should be a final "COMPLETED" state, what
> > > happens if we want to record the patient's intake of the drug? Where
the
> > > real "COMPLETED" is when the treatment is finished.
> >
> > That might mean that some INSTRUCTIONs never get COMPLETED
> > until the patient dies.
> >
> >
> There is a state "EXPIRED", so that is covered IMO if an expiration date
is
> recorded, or even if the whole system has preconfigured expiration dates
> for drug treatments.
I meant to say that some treatments will not end until the
patient dies meaning that the COMPLETED state will never be
reached if we take into account
Gotcha! Yes of course, chronic medication is never COMPLETED
the process of administering medication (as Action) to the Patient System and that is documented
the process of fulfilling an Order (Prescription) issued by a Prescriber, where the Clerk hands over the Medication to the Patient System, and that is documented
Everything is about documenting what happens to the Patient System in the case of the EHR.
The first process is an ACTION_ENTRY in the context of the process of administering medication to the Patient System.
The second is an Order that is executed as an ADMIN_ENTRY as part of an Organisational process within the Pharmacy.
Both are nested processes starting with a Plan that can be documented, an Order as part of the plan; followed by the documented execution of the Order by the Clerk, and then the Action of applying the medication to the patient. Each of these steps have a set of possible states.
In my line of thinking I’ve used a set of Entries to model healthcare provision documentation generically:
the generic Observation process using the ENTRY
the generic Evaluation process using the ENTRY
the generic Planning process using the ENTRY
the generic Ordering process using the ENTRY
the generic Action process using the ENTRY
Each of these can be applied in the context of the Patient System or the Organisational System one fixed attribute is used,
A de novo Evaluation result (e.g. diagnosis) is about the Patient System. The same diagnosis in a referral letter is done in an Administrative context
Yes. Sorry I misread your email but I think Karsten has helped you. We regarded the dispense of a medication as part of the full medication management cycle from initial order through to the patient being administered the medication
It is possible to think of there being two parallel processes, as Gerard has suggested.
The order → administration of the medication to the patient
and we did consider using different archetypes for each but after discussion and some practical experimentation decided to reflect these as different pathway steps in the same archetype as in many health systems, the separation is unclear.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
The Instruction State Machine (ISM) is designed to accommodate this, by including ‘timeout’ transitions that enable software to ‘expire’ old orders. Of course, there needs to be some service or application that does this, but it is a perfectly legal change to the data that reflect reality, i.e. that the noone informed the system that a given order (typically medication) was completed or otherwise finished (e.g. aborted). This is not the way the current ISM works, but is closer to the Task level view of things, as opposed to order-level view (which doesn’t care who the workers are). The state machine for Tasks is , in the Task Planning spec. IN addition, there is the concept of a Task Plan ( with multiple performers), which is per-performer (worker). Each Task Plan has a computed state, based on the states of the Tasks within that plan. The logic for computing this is . In openEHR systems of the future, both types of state machines will operate, so that it will be possible to know the state of every order, as well as the ‘state of the work’ being done to perform the orders. - thomas
There is nothing to prevent the creation of an ACTION and an ADMIN_ENTRY, possibly in the same COMPOSITION, and in at least some situations, this is probably the right thing to do.
certainly true in theory, and maybe in reality. But drug treatments change and different variants may be tried over time - true even for basics like insulin - so at least for some chronic medication situations, it probably will be the case that one treatment finishes and another starts, based on a (?slightly) different order, with this repeating over time.
There is the interesting situation as to what constitutes a stop/start and an amend for medication. Generally, if it is the same generic substance people will want to see it as an amend. This means they do not have to go through all the warnings and search again in the database. This is probably of no consequence from a data point of view, apart from the fact that you do not want to be warned that a patient has previously been on this medication (happens in our system).
We modelled that as minor change (Active) / major change (Aborted) , without closely defining, what constiuted either…
Major change to order
Careflow step
A major change to the order was required, resulting in this order being stopped and a replacement order being started.
Current state: aborted
Minor change to order
Careflow step
The medication order has been changed in a manner which does not require a new instruction/order to be issued, according to local clinical rules.
Current state: active
That’s probably a jurisdiction thing too. I’m not sure if it’s a legal requirement or just considered good clinical practice, but generally a dose change is a cessation/new order here.
