Stream: implementers
Topic: Repeat prescription request
David Hay (Jul 08 2021 at 05:56):
I’m trying to figure out how to represent a patients ‘request for repeat prescription’.
This occurs when a patient is already taking the medication on a long term basis, but is about to run out, and communicates with their doctor to get another script without having to see them. The doctor can accept the request, creating a prescription or decline it requesting a consultation.
The request comes from a patient portal, where the list is composed of MedicationStatement resources.
Given that this is a request, it would seem that a resource from the request pattern should be used – which in this case could either be a MedicationRequest (requester = patient, intent = ‘proposal’) or a Task.
I’m leaning towards MedicationRequest (It would need to be updated by the doctor to be used as the actual prescription – or a new one generated).
Task doesn’t seem to offer a lot of additional value (there is no significant workflow), and would still require some other resource (like a MR) to represent what is actually being requested.
Does that seem reasonable?
Vassil Peytchev (Jul 08 2021 at 11:38):
If you have the options to accept or decline, then Task is better suited - it has these status codes available out of the box. The patient request in this cases is a request for action regarding an existing prescription, which is the MedicationRequest - again, Task is a better fit here, in my opinion.
Lloyd McKenzie (Jul 08 2021 at 14:09):
Normally you'd use a Task that points to the original MedicationRequest saying "please renew this". The response might be "ok, done" or "please come in" or "I think we're going to change your dose", etc.
Lloyd McKenzie (Jul 08 2021 at 14:10):
You could have the patient create a MedicationRequest with intent of 'proposal', but then you'd still need machinery (Task, operation, message, etc.) to say "please action this".
David Hay (Jul 08 2021 at 17:51):
Thanks. And if the original 'medication' resource is a MedicationStatement (not a MedicationResource) - ie a summary of the original request ?
David Hay (Jul 08 2021 at 18:08):
Just thinking about this a bit more - if the GP is generating a script (with MedicationRequest resources) which is sent to a pharmacy, is an associated Task still needed?
Lloyd McKenzie (Jul 08 2021 at 18:55):
You could still have a Task, though the semantics of the Task.code would be a bit more funky. "Please provide a refill for whatever the current prescription is for the medication summarized by this record". Not impossible, but slightly odd...
Vassil Peytchev (Jul 08 2021 at 19:13):
Could the semantics be expressed using different structure? E.g.
- Current medication is only accessible via MedicationUsage - use Task.input to reference the medication
- Current medication is accessible as an existing MedicatonRequest - use Task.focus to reference the medication
In both cases the code can be the same (please authorize refill).
To David's second question - the actual prescription process will have a different Task resource. The Task related to the patient request is not the same as the actual prescription.
David Hay (Jul 08 2021 at 22:27):
So in option 1, you could have a single task referencing all MedicationStatement resources - which would be good! In this scenario at least, the PMS has the 'original' data for the medication that it used to create the MedStatement, so that would work nicely. Need to figure out the code of course...
Option 2 is doable - but focus is 1..1 - needing a Task per medication. You could argue that each drug is a separate 'thing' with its own workflow of course...
wrt the second question - I guess it's more about prescribing generally. If the provider wishes to generate a prescription with, say, 5 medications on it - does that mean the resulting structure (whatever paradigm it may be) needs 5 Tasks as well? ie the MedicationRequest (a 'request' resource) is not enough on it's own? Is this Grahames example of finding a paper prescription on the street - by itself it isn't enough to be the actual order to dispense? And - if so - then one Task per MedRequest?
Peter Jordan (Jul 08 2021 at 22:57):
The cardinality of MedicationRequest.medication is 1..1, so one medication resource resource per prescription item (drug) would be required if you go down that route. However, if you are going down that path (rather than just Task) - it might be better to discuss this with the NZePS team, because whatever solution that you design would need to fit into the NZePS eco-system, .e.g. a requirement not to create additional messaging to pharmacies.
David Hay (Jul 08 2021 at 23:45):
Absolutely. Has any design work already been done?
David Hay (Jul 08 2021 at 23:53):
BTW - I don't believe it could ever be 'just Task' - the task has to be referencing something via focus - which I guess in this case would be the MedicationRequest...
David Hay (Jul 08 2021 at 23:55):
One other thing: If we model the prescription as a Document (after all it is a signed, legal thing - in primary care anyway), then there could be other possibilities - eg the Composition uses the section to point to a List that references the MedicationRequest resources. Then the Task references the List. But I'm kinda hoping that someone else has worked on this...
Lloyd McKenzie (Jul 09 2021 at 00:56):
If the Task points to the List, how would you know which request to renew?
Lloyd McKenzie (Jul 09 2021 at 00:57):
As a side point, just because clinicians are used to thinking about everything as being a 'document' doesn't mean that the FHIR document paradigm is appropriate. If you desperately want a signature on a MedicationRequest (or anything else) you can do that with an extension - and considerably less overhead.
Peter Jordan (Jul 09 2021 at 01:21):
@David Hay don't forget that the NZ Medicines Regulations changed last year, so we now have both paperless and signature-exempt prescriptions.
Jose Costa Teixeira (Jul 09 2021 at 19:49):
If the prescription is a clinical issued document, I don't think we could use a Task
Jose Costa Teixeira (Jul 09 2021 at 19:50):
I see task as "this is authorized already, please do one more"
Jose Costa Teixeira (Jul 09 2021 at 19:51):
For a physician saying "this needs a new authorization, please do more" I'd definitely look at medrequest
Jose Costa Teixeira (Jul 09 2021 at 19:53):
The cardinality of medication in a request is a challenge but I think the current recommendation is to use a requestgroup
Lloyd McKenzie (Jul 09 2021 at 20:11):
The prescription is always the MedicationRequest - whether you wrap it in a document or not.
Jose Costa Teixeira (Jul 10 2021 at 07:18):
If the prescription is for "1x Drug A + 2x drug B + Drug C PRN", this can be called 1 prescription with 3 lines, not 3 prescriptions.
Jose Costa Teixeira (Jul 10 2021 at 07:19):
We need to group those. Sometimes we need to say "items 2 and 3 are going to be replaced by item 4) and then the prescription has 2 lines.
Lloyd McKenzie (Jul 10 2021 at 16:34):
Two possibilities. If the order is inseparable - i.e. you can't cancel or suspend one part without cancelling or suspending the same thing (and the combination is considered a single order for the purpose for renewals), then you must use RequestGroup. If the piece of paper just happens to have 3 orders on it, they'll all have the same groupIdentifier so that you know they were ordered at the same time. Each item can be cancelled or suspended or renewed independently. The same groupIdentifier may drive different outcomes in terms of reimbursement or other processes, but otherwise doesn't matter much. In all cases, if you're asking for a renewal you're pointing to MedicationRequest or RequestGroup - never a document or Composition.
Jose Costa Teixeira (Jul 10 2021 at 20:58):
Right. That is what I assumed and what I recall - use RequestGroup.
Jose Costa Teixeira (Jul 10 2021 at 21:00):
In IHE we used prescriptions as documents (on the CDA side that was the only way to go, I guess, and for V2 we needed to consider more than a point-to-point communication). When we do REST our lives should be oh so much easier
Jose Costa Teixeira (Jul 10 2021 at 21:02):
on the topic of prescription Vs prescription lines: I'm not confident about saying in an ihe profile:
"the standard way to exchange a prescription... depends. A prescription can be a RequestGroup or a MedRequest"
Jose Costa Teixeira (Jul 10 2021 at 21:04):
Receivers should be able to expect consistent behaviour, right?
Lloyd McKenzie (Jul 10 2021 at 21:06):
Unless you're talking complex chemotherapy regimens, prescriptions are going to be MedicationRequest. Complex multi-drug orders that must be treated as a single therapy are pretty much unheard of in community settings.
Jose Costa Teixeira (Jul 11 2021 at 05:49):
Simple treatments like hypertension contain 3 drugs. Many prescriptions include the medication and the stomach protector.
Lloyd McKenzie (Jul 11 2021 at 05:58):
Sure, but are they treated as an inseparable order or are they captured by the community as two separate Rxs? I'm pretty sure it's the latter.
Jose Costa Teixeira (Jul 11 2021 at 13:00):
there is some context to this: I am thinking "Prescription" the analogous to the paper that the physician gives when we leave the consultation. In some languages this paper is called the equivalent to "recipe". (which is where i come from - the prescription is the paper, not a single line)
Jose Costa Teixeira (Jul 11 2021 at 13:02):
And I think these lines being inseparable depends on at least one factor: the indication. If two drugs are taken for the same indication, I'd definitely presume they are inseparable. E.g. antibiotic + PPI for a patient that has ulcers.
Lloyd McKenzie (Jul 11 2021 at 14:30):
Probably worth investigating whether systems can suspend or cancel one and not the other. (Should or would cancel is different. If it's possible then you've just dealing with MedicationRequest with no RequestGroup involved.
Last updated: Apr 12 2022 at 19:14 UTC
