We are supporting Karolinska in some work to augment the current medication archetypes to better support chemotherapy prescriptions and administrations. We have opened this topic to facilitate conversations but to invite others to contribute if they are working in similar areas.
There are 2 key additions that seem to be necessary:
A. Regimen details
Against each prescription, some extra information about the regimen being used e.g.
Regimen name/ID
Course/cycle number
Course/cycle day number
Others may emerge?
Note that this is not to document the regimen itself, just to tag the prescription to be able to tie it back to where this prescription/administration fits in the regimen.
For now the assumption is that this will be a CLUSTER extension.
B. Trial drug details
Drug trial name
Flag to say this is a trial drug Perhaps blinded/unblinded?
Unblinded drug name (or perhaps the medication name is just updated
Initial thinking is that use of trial drugs is sufficiently common that it may make sense to to add these elements to CLUSTER.mediation.v1
We did some initial work on modelling the generic Consent forms for SACT (Systemic Anti-Cancer Therapy) over here, at https://www.cancerresearchuk.org/, to help the team looking at the processes for this in NHS Scotland to see how viable a digital approach would be.
We modelled up the forms as a mind map in Miro, copied here as a PDF
We were not asked to progress the program further so the modelling is not super refined ( or indeed correct!) but of relevance to your work I think is the âName of proposed course of treatmentâ section which includes treatment regimen requirements and a reference to trials.
For those curious about the Swedish setting/context, the national list of âregimensâ can be found at Läkemedelsregimer - vuxna - RCC Kunskapsbanken (in Swedish, but partly browsable/understandable).
If you go into a specific diagnose, like breast cancer, youâll find a list of regimens to pick from and different info intended for patients (some also translated to English and/or Arabic) and info for clinicians. There are also downloadable XML-versions of the regimens listed. The XML files have XML tag names in English that may help understanding.
The regimens themselves donât go into EHRs, and will of course not be modeled using openEHR, but references to regimens and regimen protocol versions used will go into the EHR as @ian.mcnicoll described above.
This thread takes my mind way back to the ideas of building âmetaâ archetypes that align with CONTSYS health threads - linking archetypes and compositions via URIs etc.
The data we record related to a single clinical trial or to provide an overview of a chronic disease is important to be able to view - there needs to be a multitude of ways to âslice and diceâ an EHR that is more than we can currently provide by multiple summaries or chronological event records. The notion of finding ways to group or filter for related material (summaries and event-based data) to provide a holistic view will be necessary, but is something we can only dream about, for now. Yet it is critically important to be able to record that data now, even if we canât provide those views just yet.
However, if we add attributes/tags for attributes related to trials or chronic diseases into the existing archetypes in these use cases, we will potentially need to add attributes/tags for all sorts of reasons to any and every archetype to make this work cohesively. While it seems a reasonable short-term solution at first glance and for this use case alone, I am concerned that we may soon find becomes an unsustainable and reactive modelling pattern.
Designing optional generic CLUSTERs to be nested in âAdditional detailsâ or âExtensionâ SLOTs seems to me a better pattern choice for each of these 2 options, at least for now and until we understand/investigate the âmetaviewâ requirements. It will effectively extend the use of existing archetypes into less common but critical domains such as trials; support the current Karolinska (and probably othersâ) use cases; avoid adding bulk to the established archetypes; and optimise potential reuse across other clinical concepts such as recording symptoms/signs that we attribute to the drug trial, and especially related adverse reactions.
Exactly what you suggest is the main approach suggested by Ian and others. I donât think anybody has objected to that so far. (But I have not studied @Paulmillerâs mindmap yet.) Great that you and Ian both suggest the same approach!
This is definitely in the âspeculatingâ department. I completely agree that we do not want otget ito the position of overloading the medication details archetype with a lot of drug trial-specific information. However, we do have a pretty common situation where a drug is given as part of a clinical trial even in GP land. We then have the problem of accurately identifying that drug since it is quite likely not to be on the national drug dictionary and therefore have some sort of AMT,. Dm+d, RxNorm code.
So the thinking was that it might be reasonable to consider including the trial name/identifier as a proxy for a drug identifier, and since this is not uncommon, that it should be included as a part of the core archetype. I donât have a strong opinion either way though.
As I understand it youâre trying to identify a drug for an order (INSTRUCTION) or administration (ACTION) so that it can be prescribed or administered but wonât be found in a typical pharmacopeia, and then connect it as part of an active clinical trial.
Just thinking out loud here⌠Is the name of the actual âMedication item nameâ in these circumstances simply not the name by which the drug is known and identified by clinicians prescribing and administering during the trial for clinical safety reasons, or its proxy eg âbig blue pillâ? Noting also that there may or may not be a code associated with it, and if so, the code may be formal or informal/local.
Confirmatory details that this drug is indeed part of a trial is added as a permanent part of the prescribing/administration record using the Trial CLUSTER extension details, including double-blindness and other related attributes and can be persisted after completion of the trial.
After the big reveal at the end of the trial, we find that âbig blue pillâ is either a sugar placebo or the latest game-changer in oncology. It seems reasonable to go back into the prescribing/administration record and update the Medication with the real/future-proof name/code pair so there is an accurate record of what the patient actually took - game-changer or sugar - during the trial period? In addition, consider adding the temporary trial/proxy drug name into the Trial CLUSTER extension to keep the connection if required in the future.
In this way it remains focused on accurate prescribing/administration and related clinical safety because the âactive nameâ as best known at the time or prescribing or administering is at the heart of each INSTR/ACTION archetype and the CLUSTER simply acts as the tag back to the trial, much like in your âRegimen detailsâ proposal.
We have some modelling on this in a project in Helse Vest (the western health region in Norway). It was for another clinical domain, ECT treatment, but the requirement look similar. For that use-case we modelled a CLUSTER to carry process related data like serial/sequence information in multiple levels. For each new treatment the numbers where queried from the previous and incremented according to local rules.