Stream: implementers
Topic: MedicationRequest dateEnded is removed
Mritunjay Dubey (Apr 08 2017 at 02:48):
Hey, I went through the changelog and figured out for the field dateEnded/reasonEnded in medicationorder there are no corosponding fields in MedicationRequest. I wanted to know why it has been removed ? How else I am supposed to populate this data ? Let me know if I missed a field which is supposed to be replacement of these fields.
Eric Haas (Apr 08 2017 at 03:08):
A good place to look is in the GForge trackers to see the why something has been changed. These elements are covered by eventHistory.
Mritunjay Dubey (Apr 08 2017 at 05:09):
@Eric Haas I tried looking into that but with content "dateEnded" I couldn't find a similar issue. I am not sure how these should be covered in event history, when you stop a Prescription that is the current state and that should not be part of history.
Mritunjay Dubey (Apr 08 2017 at 05:16):
One Idea could be it could be same as dateWritten of Stopped MedicationRequest, but then I am not sure if there could be a scenario when these two could be different
Michelle (Moseman) Miller (Apr 08 2017 at 11:32):
MedicationRequest.reasonEnded and dateEnded were replaced by the "eventHistory" structure, which was originally going to be a backbone element with status, action, date/time, practitioner, and reason per GF#8442 (looked like this temporarily http://hl7.org/fhir/2016Sep/medicationorder.html), but then "eventHistory" morphed into the reference to Provenance as part of workflow alignment with the request pattern, http://build.fhir.org/request.html per GF#10733.
Personally, I would have preferred it to be inline in the resource instead of relying on Provenance.
Michelle (Moseman) Miller (Apr 08 2017 at 12:03):
Note: we also have GF#12144 approved (but not applied) asking for a profile on Provenance within the Request guidance that will provide examples and documentation on how to use Provenance to represent event history
Yunwei Wang (Apr 08 2017 at 21:12):
@Mritunjay Dubey You just need to MedicationRequest.status to stopped and MedicationRequest.authoredOn to the stop date and MedicationRequest.reasonCode/reasonReference to the stop reason and then link this MedicationRequest with previous one using MedicationRequest.eventHistory
Mritunjay Dubey (Apr 08 2017 at 23:07):
@Yunwei Wang I will just put what I have got from here
When I create a new MedicationRequest, this is how it will look like
MedicationRequest1
status => ACTIVE
authoredon => somedate
When I stop it this is the way it should be populated
MedicationRequest1
status => ACTIVE
authoredon => startdate
MedicationRequest2
status => STOPPED
authoredon => stoppeddate
reasonCode => stopreason
eventhistory => Provenance.target=MedicationRequest1
Correct me if I am wrong
Michelle (Moseman) Miller (Apr 09 2017 at 02:02):
@Yunwei Wang @Mritunjay Dubey I disagree with repurposing those elements (specifically, authoredOn and reasonCode).
For example, the MedicationRequest.authoredOn is explicitly defined as "The date (and perhaps time) when the prescription was initially written or authored on"
Lloyd McKenzie (Apr 09 2017 at 02:03):
@Yunwei Wang MedicationRequest.eventHistory actually points to Provenance, not to past MedicationRequest version. (The Provenance points to a past version.) You should be able to see the history just from looking at the Provenance:
Provenance.period = stopped date (we'll let this be a dateTime in R4)
Provenance.reason = stopped reason
Provenance.activity = aborted (which is the code that means stopped)
Provenance.target = past version of the prescription
Lloyd McKenzie (Apr 09 2017 at 02:04):
Agree with @Michelle M Miller that the Precription.authoredOn always represents the date the prescription was written and the reason always represents the reason for the prescription.
Mritunjay Dubey (Apr 09 2017 at 09:21):
@Michelle (Moseman) Miller @Lloyd McKenzie Even I felt if I will use authoredOn as dateStopped, it might be not right. I feel there can be a scenario when a doctor can say stop taking a medication in that case dateStopped and authoredOn will be different dates.
Mritunjay Dubey (Apr 09 2017 at 09:46):
@Lloyd McKenzie Here is what is I am confused about, when you say The Provenance points to a past version, and then you say Provenance.period = stopped date etc. I think past medicationrequest is the one which was initial requested and the latest is the stopped one. So Ideally it should be stopped.provenance=>intitial.reference because initial is the history of stopped and if this is the case then we will end up populating these fields to the one which was initially created.
Mritunjay Dubey (Apr 09 2017 at 09:47):
Correct me if I am thinking in wrong direction.
Lloyd McKenzie (Apr 09 2017 at 15:08):
@Mritunjay Dubey You're correct that if the most recent change is the "stop", that won't show up in the eventHistory. Instead, there'll be a Provenance instance that directly points to that version that has the relevant information. To see all relevant Provenances for a record, you need to do an _include on MedicationRequest.eventHistory and a _revinclude on Provenance.target. (The latter should generally only give you one record.
Mritunjay Dubey (Apr 09 2017 at 15:46):
@Lloyd McKenzie Sorry I didn’t get last two lines. From what I understood I feel a problem. In our use case most of the times A New medicationorder will be placed and in few cases it will be stopped. After a stop there cannot be a recent state for that order means stopped order will never be a history so there won't be any case it to go as Provenance. So I am not sure how would I populate these fields at all, because these can be populated only in a Provenance.
Lloyd McKenzie (Apr 09 2017 at 16:12):
Every time MedicationRequest gets created or changed in any way, a Provenance record should be created that points to the version of the MedicationRequest that was just created. So, in the simple case of "create order, stop order", you'll have MedicationRequest v1 (status = active, no eventHistory), Provenance1 pointing to MedicationRequest v1 indicating who created it, when, etc. Then MedicationRequest v2 (status = stopped, eventHistory pointing to Provenance1), Provenance2 pointing to MedicationRequest v2 with information about when the stop occurred, why, who did it, etc.
Mritunjay Dubey (Apr 09 2017 at 16:22):
ohh do you mean every version of request will have atleast one provinence which will be not directly reffered in the request.eventHistory. This will hold the information about current version of resource.
Lloyd McKenzie (Apr 09 2017 at 18:12):
Yes. Every version of every resource can (and often should) have a Provenance that captures the details about what changed, who did it and why. So if tracking that information is needed, Provenance is how it's done.
David Hay (Apr 09 2017 at 20:50):
Given that provenance points to the resource it is tracking, is it possible for it to be contained within the resource?
Lloyd McKenzie (Apr 10 2017 at 01:31):
It should be, but there's an invariant that prevents it at the moment (dom-3). I've submitted GF#13187 to fix this.
Brian Postlethwaite (Apr 10 2017 at 03:33):
I've added a note to your tracker on dom-3, I don't like the constraint either.
Yunwei Wang (Apr 10 2017 at 14:13):
@Michelle (Moseman) Miller @Lloyd McKenzie Agree.. That is better than what I proposed. Thanks.
Last updated: Apr 12 2022 at 19:14 UTC
