Stream: implementers
Topic: MedicationRequest statusReason
Ardon Toonstra (Dec 24 2020 at 11:04):
MedicationRequest has a new field in R4, namely statusReason. This element aligns very closely with one of our concepts. However, we are a bit concerned about the comment in statusReason: "This is generally only used for "exception" statuses such as "suspended" or "cancelled".". Our data model also has the option to state that a MedicationRequest is changed/corrected due to for example a change in the dosage instruction. This would then be mapped to status = 'active' and statusReason = 'reason why it's changed'.
Can we use the statusReason element for “active” statuses as well? To indicate the ‘why is this med active’?
Melva Peters (Dec 26 2020 at 22:23):
What are some of the reasons why it is active and what is the use case for recording this? The Pharmacy Work Group hasn't heard this use case to this point. At what point would you populate the statusReason field for an active medication?
Arianne van de Wetering (Jan 07 2021 at 13:51):
@Melva Peters It could be a dosage change. So you make a medicationRequest (as a follow-up of a previous one) stating that you want the dosage changed. And you want to convey a reason for that (patient experienced side effect).
So:
MedicationRequest 1 - status active - take 2 pills twice a day - starting January 2, 2021
MedicationRequest2 - status active - take 1 pill once a day - starting January 7, 2021, reason: side effect.
Of course on January 7 you also stop MedicationRequest 1, it ends January 6, 2021. We want to store the reason for starting MedicationRequest 2 in that same - still active - MedicationRequest.
Please bear in mind: in our model MedicationRequest1 and MedicationRequest2 are linked by a common identification (which is in an extension). This means it is clear they both 'belong' to the same 'medication treatment'. Medication treatment is a concept we had to put in an extension. Linking MedicationRequest/MedicationDispense/MedicationUse to each other by sharing a common identification (medication treatment) is something that is - at the moment - presumably unique for The Netherlands.
Melva Peters (Jan 07 2021 at 13:55):
In my experience, the MedRequest1 is discontinued as of Jan 6th with a reason of side effect. The new MedRequest is created on January 7th with the new dose. I would suggest that you add a Jira Issues for the Pharmacy WG to review. Make sure you include a full description of your use case. We can discuss during the Working Group Meeting if you are planning on attending or on a conference call if you can dial in.
Arianne van de Wetering (Jan 07 2021 at 13:59):
Well, we see it as a change in 'medication treatment'. The new MedicationRequest represents this change and it therefore makes sense to store the reason for making this change (making MedicationRequest2) with it. This is how the model has been designed.
Arianne van de Wetering (Jan 07 2021 at 14:22):
Maybe I should explain a bit more of our use case. In The Netherlands the medication process is a very distributed process over different health care instituations. This means that provider A (General Practitioner) may have created MedicationRequest1, but provider B (specialist in hospital) is registering the new MedicationRequest2 within the same 'medication treatment'.
Obviously provider B cannot and may not update MedicationRequest1 which lives on the server of provider A. But we still want to store a reason (side effect).
Technically provider B actually stores two MedicationRequest instances, the first, let's call it MedicationRequest1stop, only to stop MedicationRequest1 (MedicationRequest1stop is meant as a mainly technical instance of MedicationRequest, main functional purpose is to make clear the end date of MedicationRequest1 ánd the professional who was responsible for this). The second is the new MedicationRequest2 which should give a proper view of what the patient should be doing from now on. It makes it easier to have the reason ín that instance, so that it is not necessary to also retrieve MedicationRequest1stop to make a reconciliated medication overview.
Vassil Peytchev (Jan 07 2021 at 19:18):
Unless the MedicationRequest resource has an invariant that only allows statusReason to be used with "exception statuses", I don't think the language in the comment prohibits the use of statusReason with an active status. My suggestions would be:
- Describe the use of statusReason with a status of active in your IG
- Create a Jira ticket with a specific proposal to update the comment for statusReason to use somewhat less "harsh" language
Lloyd McKenzie (Jan 07 2021 at 19:40):
Status reason for an 'active' status would generally go in reason, not statusReason. I can't understand how the reason for a MedicationRequest being active could ever be different from the reason for having a MedicationRequest at all.
The request to stop MedicationRequest1 would be represented using Task, not MedicationRequest.
Vassil Peytchev (Jan 07 2021 at 20:41):
MedicationRequest.reason is defined as CodeableReference(Condition | Observation). It seems to be geared towards showing the problem that is being treated with the medication. Are you suggesting that there should be reasons that describe the conditions being treated and a reason that is the the reason for changing the dosage?
Lloyd McKenzie (Jan 08 2021 at 01:14):
Reason for changing the dose would, ideally, be captured on the Provenance that represents the change. It's not a reason that applies to the status or to the overall order, it applies to the change. In cases where that involves stopping one order and creating another, you can still have a single Provenance that represents the creation of one and the revision of the other (or the creation of the Task that seeks revision of the other, if you don't have the authority to change it yourself).
Vassil Peytchev (Jan 08 2021 at 04:11):
I don't think having this in the Provenance reflects how systems keep track of the reason for the new order with changed dosage (or form, for a different example). I think this is usually part of the order itself.
Lloyd McKenzie (Jan 08 2021 at 04:21):
But it's not the reason for the order - it's the reason for the change from one order to the other. The reason for the order is the indication. Provenance is where we capture reason for change (which is not the same thing as reason for status).
Richard Townley-O'Neill (Jan 08 2021 at 05:51):
I could not find any codes in the value set for Provenance.reason that are relevant to refining a medication dosage for medical reasons. The resource looks to be about tracking who, when, their authorisation, their legal justification etc. Not a clinical/medical reason.
Am I alone in reading it that way?
Lloyd McKenzie (Jan 08 2021 at 06:53):
Provenance.reason captures the reason for every action taken that manipulates one or more resources. The value set is quite limited. I have zero clue why they made it extensible - it doesn't seem like the sort of resource element where it's reasonable to try to enforce consistency across all possible types of change across all possible systems. @John Moehrke ?
Arianne van de Wetering (Jan 08 2021 at 09:50):
Provenance.reason captures the reason for every action taken that manipulates one or more resources
If that is the design principle, why was the MedicationRequest.statusReason introduced in R4?
John Moehrke (Jan 08 2021 at 12:01):
Arianne van de Wetering said:
Provenance.reason captures the reason for every action taken that manipulates one or more resources
If that is the design principle, why was the MedicationRequest.statusReason introduced in R4?
we recognize that sometimes the (who, what, where, when, why) is so fundamental to the use of the Resource, that duplication of that is better. As Vassil points out in this case it is more typical that the reason is tracked inside the MedicationRequest.
John Moehrke (Jan 08 2021 at 12:03):
Richard Townley-O'Neill said:
I could not find any codes in the value set for Provenance.reason that are relevant to refining a medication dosage for medical reasons. The resource looks to be about tracking who, when, their authorisation, their legal justification etc. Not a clinical/medical reason.
Am I alone in reading it that way?
The reason is the purpose of use under which the activity happened. In this case that would be Treatment.
John Moehrke (Jan 08 2021 at 12:06):
we have not had someone propose that there is a need for an element to hold a more refined reason. We have just had people asking for clarification of the purpose of use underwhich the change was made. I am not sure this is the same as the current element (it is 0..*, and extensible), or if that need should be a different element that doesn't exist yet.
Arianne van de Wetering (Jan 08 2021 at 12:48):
John Moehrke said:
we recognize that sometimes the (who, what, where, when, why) is so fundamental to the use of the Resource, that duplication of that is better. As Vassil points out in this case it is more typical that the reason is tracked inside the MedicationRequest.
Well, we agree here. Back to the original question then: we would also like to use statusReason when the status is 'active'. The reasons for suspending medication are mainly the same as the reasons for a dose change, where the (new) medicationRequest is 'active'. Having two separate fields is not helping implementers.
Lloyd McKenzie (Jan 08 2021 at 14:33):
"Why is this on hold?" or "Why was this stopped?" is something that would be of interest even if there were subsequent changes to the resource. We could have forced you to go get the provenance that captured the status change, but determined that there was a need for this information to be front and center. If we think the same is true for something like 'dose change', then I'd turn priorPrescription into a complex structure and put reason there.
Arianne van de Wetering (Jan 08 2021 at 15:07):
Just to be sure: 'dose change' itself is not the reason it is just the effect of an underlying reason. This reason can be "Too strong drug action" (which may also be a reason for suspension/abortion). As our designers see it: this is the reason we are making a new instance of MedicationRequest. Without this reason the preceding MedicationRequest would have sufficed.
"Why is this on hold?" or "Why was this stopped?" is something that would be of interest even if there were subsequent changes to the resource.
Our caregivers also want to know "why was this changed", especially if there are subsequent changes needed.
As for implementers: we have one list of 'reasons' which has reasons for both change (the change may also entail a different route / product / et cetera) and suspension/abortion. The reasons overlap for both causes (which is why there is one list), and will always result in a new instance of MedicationRequest, so to our designers both suspension/abortion and continuation are a 'change' which require a reason.
It is just a bit of a pain to have to put them in different places in the MedicationRequest (let alone in a Provenance resource) depending on whether you are aborting/suspending or continuing with a change
John Moehrke (Jan 08 2021 at 15:12):
might the reason be captured as an Observation. The previous medication stopped, and a new medication started?
Arianne van de Wetering (Jan 08 2021 at 15:13):
John Moehrke said:
might the reason be captured as an Observation. The previous medication stopped, and a new medication started?
Same 'pain', yet another resource to create/maintain and for status 'suspension/abortion' you are supposed to use statusReason. Just not nice.
Lloyd McKenzie (Jan 08 2021 at 15:45):
Reason for change of anything is generally captured in Provenance. If you change a patient's address, reason would be in Provenance. If you correct a lab value, reason would be in Provenance. If you cancel a referral, reason would be in Provenance. The only trick here is that the 'change' manifests as a status change to the old thing and creation of a new thing. (And the boundary for what sort of changes force that vs. what can be done without a new order are variable - in some environments, changing the dose can be done without a new order number.) We can't capture 'reason for change' on the resource itself because multiple changes will occur over time. MedicationRequest has "relevant history" which points to Provenance which allows you to see all of the important changes.
Arianne van de Wetering (Jan 08 2021 at 16:30):
Hmm, I see your point for when you are manipulating an existing resource instance, especially for a resource instance that will have a long life, such as Patient.
However, we do not typically 'update' an existing instance in MedicationRequest, because we have to cater for distributed systems. And we want processing to be the same whether you manipulate your 'own' resources or someone else's, so that only one type of process is needed. Distributed systems amend the same patient's medication treatment, but cannot and may not manipulate instances on other servers. Instead they make new MedicationRequest instances reflecting the agreement between practitioner/patient. So, in our design, we always create a new instance with a new discrete business identifier (and logical id of course). And we do use a correlation id ("medication treatment identifier") to link all medication related resources (MedicationRequest, MedicationDispense, MedicationUse) to the same treatment.
The reason for making the MedicationRequest (or, if you will: for making it 'active', giving it status 'active') is just something we need to have as much readily available as the reason for suspending/aborting it. For the first MedicationRequest in a medication treatment, such a reason is typically not needed. Maybe the opposition to a reason for status 'active' grounds there: the real/underlying reason for the existence of any active MedicationRequest is that you are treating some disorder. That reason, however, will be in reasonCode/reasonReference regardless of statusReason, and it is therefore very clear to be distinct from statusReason.
In our use case, each new MedicationRequest after the first moderates the existing medication treatment, and a readily available change reason just really helps. It helps our implementers to have to place it/look for it in the same place as the suspension/abortion reason.
If statusReason is a no go, we may have to fall back on an extension for the short-term, as implementing Provenance will be a longer term path.
Lloyd McKenzie (Jan 08 2021 at 17:01):
Creating a new instance is totally fine. My point is that in different environments the rules around "when is update ok" and "when must you create a new instance" vary. But, ideally, the location to capture the reason for the transition would be consistent regardless of business approach.
The reason you're capturing is not really a "reason why this MedicationRequest exists", but more "reason why this MedicationRequest is different than the one it's replacing".
As mentioned, while Provenance is the 'standard' place to capture that reason for change/reason for difference from preceding order, we can (and do) propagate information from Provenance into the core resource when it's deemed important and retrieving the Provenance is too much overhead. However, I don't think the place for your reasonCode should be statusReason, but instead a new element. You could certainly submit a change request to have another core element added (or a standard extension).
Peter Jordan (Jan 08 2021 at 22:10):
Falling back on the generic business requirements of an e-Prescribing Service - the status of virtually all Prescriptions will change during their life cycle and as each version of a prescription is a legal artefact it is likely to be persisted by a Server (ePrescription Exchange or Broker). The current version of a Prescription that is passed to/from clients will contain a status and, possibly (but not always) a reason for that status which may, or may not, relate to another Prescription. My approach for passing a status reason would be to see if any of the concepts in http://hl7.org/fhir/ValueSet/medicationrequest-status-reason are applicable - remembering that the binding strength is only 'example'.
However, based on my 10 years experience as a (payload) architect and implementer in the NZ e-Prescription Service, I'm not convinced that it's possible to create a Code System that will serve the multitude of reasons why the status of Prescription might change AND the current one certainly doesn't come close to matching all of our use cases.
Arianne van de Wetering (Jan 11 2021 at 16:42):
Lloyd McKenzie said:
... However, I don't think the place for your reasonCode should be statusReason, but instead a new element. ...
How about we broaden the definition and change the name of 'statusReason' to 'provenanceReason' ?
Lloyd McKenzie (Jan 11 2021 at 17:02):
That's not going to make sense to most implementers. And you might well want both statusReason and a reason for change to a new resource. If you have a prescription that was created to lower the dose and it's currently on hold, you're going to want both pieces of information.
Arianne van de Wetering (Jan 12 2021 at 10:15):
Lloyd McKenzie said:
That's not going to make sense to most implementers. And you might well want both statusReason and a reason for change to a new resource. If you have a prescription that was created to lower the dose and it's currently on hold, you're going to want both pieces of information.
Changing the dose has it's reason, and changing status to 'on hold' has it's reason. Both actions are not typically done at the same moment in time. In our use cases only the reason for the latest change needs to be readily available.
Lloyd McKenzie (Jan 12 2021 at 17:03):
It doesn't matter if they're done at the same moment in time. The MedicationRequest doesn't represent "what just happened". It's the current view of the order someone sees when they query. When you query for the patient's prescriptions, you'll want to see "why is the patient on this med at all?" (MedicationRequest.reason), "why is this prescription currently on hold?" (MedicationRequest.statusReason), and - for your use-case - "why does this prescription have a different dose than the prescription it replaces?" - which therefore needs to go in a separate slot.
Peter Jordan (Jan 12 2021 at 23:21):
Agree with that last post from @Lloyd McKenzie - although, to be accurate, the appropriate R4 properties are MedicationRequest.reasonCode and MedicationRequest.reasonReference (c/f MedicationRequest.statusReason and MedicationRequest.SubstitutionReason). The key point is that, by default, MedicationRequest represents "the current view of the order".
Last updated: Apr 12 2022 at 19:14 UTC
