Stream: implementers
Topic: DSTU2 / STU3 Prescriber
Dave Barnet (Jul 14 2017 at 14:09):
I'm getting a bit confused about what has happened to the DSTU2 MedicationOrder prescriber in STU3. The equivalent resource in STU3 seems to be MedicationRequest. There's no explicit Prescriber in MedicationRequest as there was in DSTU2 MedicationOrder. The nearest thing in MedicationRequest I can see is the requestor\agent. However, the agent can be one of Practitioner; Organization; Patient; RelatedPerson or Device, with the description being "Who ordered the initial medication(s)". The description for requestor reads "The individual, organization or device that initiated the request and has responsibility for its activation." . The description for the requester\agent reads "The healthcare professional responsible for authorizing the initial prescription.". The Search Parameters description for requester.agent reads "Returns prescriptions prescribed by this prescriber". So, is the agent the person (or thing) that ordered the initial medication, do they have responsibility for its activation, and is the agent indeed the Prescriber (can a Patient or RelatedPerson really be a Prescriber?). Hope you can clear up this confusion.
Lloyd McKenzie (Jul 14 2017 at 14:15):
If you're dealing with a proper order (MedicationRequest.intent = 'order' or one of its specializations) then I'd expect the MedicationRequest.requestor to always be a Practitioner. But for recommendations/plans, it could be a broader set of people as recommendations can come from devices (decision-support apps), patients or family members or generic organizations.
Abbie Watson (Sep 25 2017 at 02:40):
Yes, can anybody give some advice on where to find some documentation on the DTSU2 vs STU3 change from MedicationOrder to MedicationRequest? We started implementing the Argonaut specs last year, and to this date, Epic and Cerner are still on DTSU2, so are supporting MedicationOrder as their specific API. Yet, FHIR has moved onto STU3 and no longer supports MedicationOrder. We've managed to do a complete full-stack implement of 12 of the 13 resources supported by both Epic and Cerner (database to UI), and are moving to MedicationOrder. But now we're debating on whether it makes sense to implement a v1.6.0 schema when we're trying to keep to v3.0.1 schemas.
Lloyd McKenzie (Sep 25 2017 at 03:36):
What sort of documentation are you looking for? Rationale for the change? List of accompanying changes?
Abbie Watson (Sep 25 2017 at 05:44):
Either of those would be great. Accompanying changes for the day-to-day implementation stuff.
But there's also the bigger question of what happens if/when the ONC approves Epic/Cerner submissions with DTSU2? I doubt such documentation exists, but I guess I'm looking for guidelines on how to approach implementation since there seems to be Epic/Cerner who are either lagging or exercising their market positions to define MedicationOrder as the U.S. national standard; while HL7 is moving ahead and defining MedicationRequest as the international standard. This plays into their App Store strategies as well. If the Epic App Orchard requires DTSU2 to get into that market; suddenly there's a whole bunch of financial incentive to stick with v1.6.0 instead of implementing to v3.0.1. But maybe they're going to move ahead with v3.0.1 and are just being slow? So many questions....
Lloyd McKenzie (Sep 25 2017 at 05:49):
I'm not sure what Epic and Cerner's plans are with respect to timelines for moving to newer versions of FHIR, however I'm not aware they've given any intention to not move to a newer version eventually. (And in fact, some of the changes in R3 and R4 have come at their request.) So I would anticipate their migration eventually. The changes can be seen in the R2 Diff tab of the MedicationRequest resource in R3. The change in name was driven by the scope of the resource and a desire to avoid confusion. The resource is used not only for orders, but also for plans and proposals. It was felt that retaining the name "Order" in the resource would have been misleading. (The same rationale applies to the various other 'request' resources.)
Jenni Syed (Sep 25 2017 at 15:54):
From a Cerner perspective, we'll be running both a DSTU 2 and STU 3 endpoint for a while, once we start getting STU 3 out the door (just like we did for May Ballot DSTU 2 and DSTU 2 final for a while).
Jenni Syed (Sep 25 2017 at 15:55):
We will have to re-certify STU 3, unfortunately. :) We'll be using the US-FHIR-Core profiles for STU 3.
Last updated: Apr 12 2022 at 19:14 UTC
