Adding to the DV_QUANTITY units options

Tool Support Archetype Designer
61

Sorry @Thomas - I’m going to have to disagree again!! (Not like me I know).

’Product-based’ prescribing is a very well-established approach in many different countries, including the UK, particularly in community settings. The purpose is to give clear instructions to the person adminstering or taking the medication in an unsupervised setting like primary care
So an order like “Flucloxacillin capsules 250mg 2 cap four times daily” is completely normal, and is explicitly supported by the openEHR models. Clearly it does introduce some complexity in moving between this approach and the ‘Dose-based prescribing’ equivalent like “Flucloxacillin 500mg 4 times daily” as would be more typical in UK hospital systems but there has been a lot of work done to make this possible. THe NHS Meds team have some very nice documentation based on FHIR but the same principles apply- a snippet here - Implementation guide for interoperable medicines

In the UK, and I suspect elsewhere, there are regular attempts to unify and go with mode or the other but in reality this collides with a whole lot of massive barriers - - staff retraining, primary legislation changes, wholesale system changes, which means we are almost certainly stuck with having to support for some time if not forever.

One critical aspect is to be able ot capture the ‘dose unit’ as a coded item. not just as text.

DV_QUANTITY was adjusted some time ago now to allow non-UCUM codesystems, explicitly to support ‘dose units’ like ‘tablet’, ‘capsule’ e,g a SNOMED terms.
Prior to that, there were separate quantity (as q qualified real’ and unit elements but this was very messy to explain and implement.

FWIW this is now aligned with FHIR Quantity

So my suggestion is to use this to represent the ‘recorded’ prescribed quantity i.e. if the prescriber is using product-based then use 'dose units’ if dose-based’ then use SI units, though this is not always possible for mixed preparations.

Alternate dose can then be used to carry the dose-based equivalent if this is helpful.

To calculate that alternate ‘SI dose’, as others have said you either have to capture the form and strength of the ‘dose unit’ in the CLUSTER.medication archetype, or , as @Thomas suggested make use of knowledge within the drug terminology. We have this in the UK with the dm+d terminology which essentially captures the key information about the medication product to be able to make that conversion, and the UK Meds team did have that working as a demonstrator. We feel confident enough about version management of dm+d such that we do not feel the need to explicitly duplicate the product strength/ form details in the patient record (in Cluster. Medication) but we know that folks in other jurisdictions do not have the same confidence.

So right now, after an explicit request to add ‘dose unit’ support to DV_QUANTITY, with changes to the dosage archetype made in response, we do have a standard approach, which happens to line up with FHIR.

62

Yep, I know this of course, and it has to be supported (clearly), and obviously the models must reflect this reality, or data won’t even be captured properly in the first place. So, no argument from me.

Now to details:

Flucloxacillin capsules 250mg 2 cap four times daily

This is an Instruction, i.e. an order, in a form that can be directly acted upon.

However, when each admin Action is recorded (assuming that they are…), you ideally want two things to be stated:

  • A) that the two caps were taken by the patient, i.e. that the prescribed admin act was carried out - I would not necessarily even use DV_QUANTITYs here
  • B) the actual real dose - computed once (not many times later) of each ingredient in the formula - these need to be DV_QUANTITYs

A) tells later users of the record that one administration was completed at time T by HCF X etc, and B) provides a computable form of what actual amounts of what substances were put into the patient’s body.

Theoretically I would trust DM+D as well, but that’s not really the point; at some point it will turn into something else (maybe due to privatisation, along with the rest of the NHS…) and patient lifelong health records containing refs into DM+D suddenly can’t be computed with. If the relevant meta-data exists in DM+D, it should be used to compute the true admin dose values once for each INstruction, as a kind of ‘template’ sub-Cluster whose meaning is ‘effective dose description’, containing the computed effective doses of each ingredient (to cover mixtures). Each subsequent Action would record a copy of this Cluster, with any modification needed, e.g. if only one cap were given on the 4th dose (not going to happen with anti-biotics, but common with steroids or similar).

The other reason you can’t ‘trust DM+D’ is that the data will one day turn up in the EHR system of a Japanese cruise ship for a sick UK traveller and they just won’t have DM+D available to resolve anything; same in reverse for say a Korean patient visiting Spain, and so on.

If we want lifelong health records that are properly computable over decades, and don’t rely on temporary / local knowledge resources, I don’t see a way out of doing something like the above.

63

I had thought the discussion above was about Instructions not Actions but I take the point about the challenge of knowing exactly the substance amount administered.

64

The actual administered dose (as well as form, route, etc) needs to be recorded as part of the ACTION, as it can change for any number of reasons when theory (order) hits reality (administration).

But if a specific product is recorded as administered (even if the order is for a generic substance, the dose actually administered will usually be a specific product), it should be possible to calculate the amount of active substance either at the time of recording or at a later date given enough information about the product.

65

Yes… ‘should’…! If it can be done at the time of creation of Instruction or at worst, the Actions, it should. Leaving it till later means it will never be done. But committing non-computable info in the first place just means the EHR is non-computable, at least for this purpose (meds dosing).

66

@HHeiser

I might have said something a little different for co-codamol, though I appreciate this is not the current guidance in the archetype. I’d still prefer for the ‘dosage’ to represent the original instruction given, so ‘1-2 tablets’, where the ‘tablet’ would be carried in the extended Quantity structure and use alternateDose for the derived dose

67

Thank you! How long does it usually take before the change is implemented in Archetype Designer?

68

It’s probably a good idea to notify Better about the change once the pull request has been merged.