Stream: implementers
Topic: medicаtion prescription
Tihomir Petrov (Jan 10 2020 at 15:02):
Hi, I would like to ask in which resource I can keep a medicаtion prescription in fhir database?
Vassil Peytchev (Jan 10 2020 at 15:13):
A prescription is represented by MedicationRequest
Tihomir Petrov (Jan 10 2020 at 15:27):
Yes, I know that the MedicationRequest represents a single medication request, but I want to implement a prescription contained few medication requests in the context of a single Encounter. Can we use for example Composition in order to group few MedicationRequests in the context of the Encounter? The idea behind that is to have a way to print all the prescriptions related to the Encounter.
René Spronk (Jan 10 2020 at 15:43):
MedicationRequest resources have a reference to the Encounter. As such that's the default grouping mechanism.
Jose Costa Teixeira (Jan 10 2020 at 17:03):
Depends
Jose Costa Teixeira (Jan 10 2020 at 17:03):
If a prescription consists of several items, these typically are bound together clinically
Jose Costa Teixeira (Jan 10 2020 at 17:04):
So there is a single grouping resource that is the "parent"
Jose Costa Teixeira (Jan 10 2020 at 17:04):
CarePlan is what I would use
David Hay (Jan 10 2020 at 17:05):
or List?
Jose Costa Teixeira (Jan 10 2020 at 17:05):
For just grouping and saying "these belong together" I would use a requestgroup
Jose Costa Teixeira (Jan 10 2020 at 17:06):
List does not convey this is one single clinical order
David Hay (Jan 10 2020 at 17:07):
RequestGroup does seem better if it's an actual order...
Jose Costa Teixeira (Jan 10 2020 at 17:08):
It is an actual single order that cannot be decomposed technically - its integrity is a clinical element as well
Lloyd McKenzie (Jan 10 2020 at 17:11):
For multiple meds ordered at the same time, there's no grouping resource. They just all share the same groupIdentifier.
Lloyd McKenzie (Jan 10 2020 at 17:11):
RequestGroup is only used if the medications can't be manipulated independently. I.e. you can't suspend one without suspending all - which generally means multiple meds that have tight interdependencies in terms of delivering a single therapy.
Jose Costa Teixeira (Jan 10 2020 at 17:22):
Ah yes and there is groupidentifier
Jose Costa Teixeira (Jan 10 2020 at 17:25):
I confess I'm not very comfortable with the range of options and what they depend on.
Jose Costa Teixeira (Jan 10 2020 at 17:26):
I think at the top level we have CarePlan that can be used for long-term prescriptions like hormonal therapy, psychiatric treatments, etc.
Jose Costa Teixeira (Jan 10 2020 at 17:27):
then we have grouping - requestGroup and groupIdentifier, which is to group the actionable requests.
Lloyd McKenzie (Jan 10 2020 at 17:28):
I might use CarePlan to represent "intended therapy" - where a single entry in the CarePlan could cover numerous prescriptions over time
Jose Costa Teixeira (Jan 10 2020 at 17:28):
Yes
Jose Costa Teixeira (Jan 10 2020 at 17:28):
long-term therapies are in that group, right?
Jose Costa Teixeira (Jan 10 2020 at 17:29):
The act of prescribing implies a responsibility that is not operational but clinical - if the physician prescribes 2 drugs together, they may or may not be dispensed separately, but that is something that is a clinical decision.
Lloyd McKenzie (Jan 10 2020 at 17:31):
Each MedicationRequest is treated as an independent order. The decision to fill, suspend, cancel, etc. is independent of any other MedicationRequest - even if authored at the same time on the same 'virtual' piece of paper. RequestGroup is used in those situations where the decision to act on one request can't be made independently of another request. If you cancel/suspend one, you need to cancel/suspend all.
Jose Costa Teixeira (Jan 10 2020 at 17:31):
I was "trained" to assume this is the case by default:
RequestGroup is only used if the medications can't be manipulated independently. I.e. you can't suspend one without suspending all - which generally means multiple meds that have tight interdependencies in terms of delivering a single therapy.
Jose Costa Teixeira (Jan 10 2020 at 17:32):
so far so good. So that leaves the groupIdentifier for which cases ? When they are entered in the saem editing session?
Lloyd McKenzie (Jan 10 2020 at 17:38):
Yes. groupIdentifier is used for the paper equivalent of "ordered on the same written script". Also applies to lab orders marked off on a common requisition form, etc.
Jose Costa Teixeira (Jan 10 2020 at 17:48):
what is the difference (from a user entry perspective) between
a) ordered on the same script and
b) can't be made independently...
Jose Costa Teixeira (Jan 10 2020 at 17:49):
My assumption is that a implies b by default unless otherwise made explicit (how?)
Lloyd McKenzie (Jan 10 2020 at 18:03):
(a) definitely doesn't imply (b). It's very common for clinicians to order multiple drugs on a single piece of paper. In most jurisdictions, that has no impact on the ability to manipulate the scripts independently downstream. If someone writes your asthma med renewal on the same piece of paper the prescribe an antibiotic, cancelling the antibiotic wouldn't be expected to cancel the asthma med.
Jose Costa Teixeira (Jan 10 2020 at 18:11):
yes, but that decision is a clinical act. If someone cancels the antibiotic and not the asthma med, that person is then onwards responsible for the clinical impact of that, right?
Jose Costa Teixeira (Jan 10 2020 at 18:12):
(I'm agreeing with most of it, I just need some deterministic criteria to provide guidance on this situation)
Lloyd McKenzie (Jan 10 2020 at 18:18):
There's clinical responsibility for the impact on the patient regardless of whether things were ordered on the 'same' piece of paper or not.
Lloyd McKenzie (Jan 10 2020 at 18:20):
In many jurisdictions, the fact that things were ordered on the same piece of paper has no impact. In some cases, there can be impacts on downstream processing or payment. But, in FHIR, if you want to declare dependence, then you use RequestGroup. And in that case, the 'intent' of all of the MedicationRequests (or other Requests) becomes 'option' and you can't change the status of one without changing the status of all.
Jose Costa Teixeira (Jan 10 2020 at 18:25):
So, the guidance would be
"If an order is entered as a whole, use RequestGroup". If an order is just entered in one session without this having any impact on its integrity, you can use groupIdentifier"
?
Lloyd McKenzie (Jan 10 2020 at 18:27):
If you have a single order with multiple interdependent components, use RequestGroup. (It's possible that a RequestGroup might be adjusted over time - not necessarily a requirement that everything be ordered at once). If you simply want to capture that multiple things were ordered as part of the same ordering 'event', use groupIdentifier.
Jose Costa Teixeira (Jan 10 2020 at 18:46):
ok. And for orders that are represent a treatment and are not actionable themselves but may trigger the actionable prescriptions, use CarePlan.
Jose Costa Teixeira (Jan 10 2020 at 18:48):
right ?
Lloyd McKenzie (Jan 10 2020 at 18:52):
Not necessarily. The non-actionable bit is conveyed by 'intent'. You can have MedicationRequest instances that have an intent of 'planned' (or 'proposed'). CarePlan is primarily relevant when you want to have a big-picture view of a whole bunch of meds (and maybe other things too). If you need to capture detailed dosage instructions, the CarePlan activities might still need to point to a MedicationRequest with an intent of 'planned' to convey that detail.
Jose Costa Teixeira (Jan 10 2020 at 18:57):
True. In my head the notion is that Careplan is a "Treatment".
Jose Costa Teixeira (Jan 10 2020 at 18:59):
The Swiss have this - a big-picture view of what treatments are being planned for the patient.
For example if I have one pescription and then change it for the same indication but adjust the dosage, that may be still a same Treatment.
Jose Costa Teixeira (Jan 10 2020 at 19:01):
I think the exact boundaries will depend on the jurisdiction, and to make these boundaries clear we may have to resort to examples.
Jose Costa Teixeira (Jan 10 2020 at 19:07):
so, @Tihomir Petrov I think this is the answer I prefer (your mileage may vary):
-
MedRequests may simply point to the same Encounter, but this does not imply more than the circumstance they were authored. In other words, it does not make those requests a "prescription" - it's still a bunch of requests made in the same encounter.
-
If you need to make that set of requests a consistent set:
2.1
If you have a single order with multiple interdependent components, use RequestGroup. (It's possible that a RequestGroup might be adjusted over time - not necessarily a requirement that everything be ordered at once).
2.2
If you simply want to capture that multiple things were ordered as part of the same ordering 'event', use groupIdentifier.
- If your notion of prescription means "this person will be on PPIs for the rest of their life", this will be a CarePlan (you probably don't need this, but it will be very handy when you need to make a medication record :))
Vassil Peytchev (Jan 10 2020 at 19:59):
MedicationRequests that point to the same encounter contain sufficient information in most cases. You may need groupIdentifier if either there is no Encoutner to group the MedicationRequests in a single prescription, or if you have circumstances where grouping all the Encounter's MedicationRequests is not allowed (in the paper world that would correspond to using a secure vs non-secure prescription pad)
Jose Costa Teixeira (Jan 10 2020 at 20:13):
I think the matter is not if they can be placed in the same context. For context, encounter is ok.
The matter is "are these authored together, and if so, is there a meaning in that togetherness"
Last updated: Apr 12 2022 at 19:14 UTC
