Stream: implementers
Topic: task vs diagReq vs medReq
Jose Montoya (Dec 01 2016 at 16:55):
The use case is the patient or their practitioner orders a few items from us for the patient to use the items to collect some samples and then returns them to us for diagnostic. We need to build a resource that allows these items to be ordered. Initially we were gonna go with DiagnosticOrder but we learned it's being deprecated and are now mainly looking at Task, but would like some input or recommendation as to what makes more sense.
Jose Montoya (Dec 01 2016 at 17:45):
DiagnosticRequest also seems a good fit
Jose Montoya (Dec 01 2016 at 17:48):
Especially since the patient/practitioner will be interested in getting the results from the diagnostic
Jose Montoya (Dec 01 2016 at 18:09):
I guess ideally the use case would comprise 2 diff resources Task, which would be sending the sample container to the patient and getting it back, followed by a DiagnosticRequest to be performed on the samples.
Jose Montoya (Dec 01 2016 at 18:09):
Does that sound sane?
Jose Montoya (Dec 01 2016 at 18:10):
Could there be a clean way to collapse that into 1 resource...
Grahame Grieve (Dec 01 2016 at 18:47):
that sounds right. The Task documentation should sufficiently explain why they are not collapsed into one resoruce
Jose Montoya (Dec 01 2016 at 19:51):
Usage Recommendations for Task:
"Not clear why would anyone do this . . . "
Jose Montoya (Dec 01 2016 at 19:52):
http://build.fhir.org/workflow.html#12.1.2.6.4
Grahame Grieve (Dec 01 2016 at 19:56):
that's pretty amusing. @Lloyd McKenzie please look at that
diego kaminker (Dec 01 2016 at 19:57):
Worried about the scope of the recommendation? About Task in general? :)
Eric Haas (Dec 01 2016 at 19:57):
RE "DiagnosticOrder but we learned it's being deprecated" - This is incorrect DiagnosticOrder has been renamed to DiagnosticRequest in STU3 just like MedicationOrde has been renamed to MedicationRequest.
Jose Montoya (Dec 01 2016 at 20:01):
So we're trying to figure out the best way to implement our use case. 1- patient/practitioner orders some sample containers, 2- patient/practitioner sends us back the container with sample. 3- we diagnose the sample and report the results. At this point I'm thinking a Task that keeps track of SupplyRequest + Supply Delivery + DiagReq (For when we get it back) + DiagReport
Jose Montoya (Dec 01 2016 at 20:01):
It's getting a little unwieldy
Jose Montoya (Dec 01 2016 at 20:02):
But I think that's as clean and FHIRish as it can be
Grahame Grieve (Dec 01 2016 at 20:02):
usually that's 2 separate workflows :
- SupplyRequest / SupplyDelivery
- DiagnosticRequest / DiagnosticReport
Grahame Grieve (Dec 01 2016 at 20:03):
but yes, that's the moving parts you have to deal with
Lloyd McKenzie (Dec 05 2016 at 21:56):
@Grahame Grieve We couldn't think of a good reason for a placer to post a Task to a receiver's system. It's a theoretical option we figured we should document, but don't have a good reason for that particular workflow.
Grahame Grieve (Dec 05 2016 at 22:01):
I think it arises once you inject a broker into the middle between multiple systems
Lloyd McKenzie (Dec 05 2016 at 22:31):
Having a broker is a separate scenario and that one makes good sense. It's the one where the Placer posts the Task to the Filler that's a little odd.
Last updated: Apr 12 2022 at 19:14 UTC
