Stream: workflow
Topic: Service request (laboratory) broker workflow
Alexander Ivanov (Jul 03 2018 at 10:47):
@Lloyd McKenzie @Grahame Grieve We have discussed possible workflow for ordering diagnostic requests with the broker (dispatcher) at FHIRstarter at SPb. So we've done flowcharts to summarize our discussion.
In our case clinic interact with several labs, it collects specimen and sends them to the laboratory. So we need the lab to tell clinic some information about protocols for collecting specimens. Also, the lab should be able to request some extra info (Questionnaire) to set the correct reference or in case of government regulation rules.
The main steps of this interaction are:
1. Get a catalog of possible order codes.
2. Get an estimated time of accomplishment for each position in a catalog.
3. Get information about required specimens.
4. Get extra questionnaires.
5. Request service request
6. Get results
Workflow-states-for-a-lab-order-for-a-blood-test-using-lab-broker-dispatcher.png
It seems we can express all our needs with new R4 resources, but we have some questions:
1. Should we have some Task to describe whole interaction? Clinic can use it to show that all ServiceRequest with the same requestionId was successfully created.
2. What kind of resource should be "event" for ServiceRequest for specimens? Should it be Procedure? I've found this discussion http://community.fhir.org/t/how-to-associate-a-specimen-with-a-procedure/826/4 , I think we are also interested in specimens section in Procedure.
3. When lab asks the clinic to fill out the Questionnaire can we set a reference to Questionnaire into supprtingInfo field of ServiceRequest?
4. Should we use an extension in EntryDefinition for estimated time of accomplishment?
Jose Costa Teixeira (Jul 03 2018 at 11:32):
1. : What do you want to define? The diagram you show with concrete steps and values seems like an ExampleScenario. If you want to define how the workflow CAN behave (i.e. what are the boundaries instead of a specific example instance) the you'd use PlanDefinition
Lloyd McKenzie (Jul 03 2018 at 12:55):
Hi Alexander,
In looking at your workflow, a few minor comments:
- 1 should probably be an ObservationDefinition. EntryDefinition probably isn't necessary to your use-case (and may well go away)
- I'd expect #1, 9, 10 and 17 to happen at the same time
- 6+7 can be done in a single query using _include if you like (but separate queries are fine)
- 8, 16, 23, 27, 31, 36, 40 should be a PUT rather than a POST
- 11 is optional. The task in 12 could just say "please instantiate this ActivityDefinition"
- 14 could grab the Task, the service request (if any), and everything pointed to (ActivityDefinition, Questionnaire, SpecimenDefinition). No need to have so much back and forth. And when completing them, you can update the Task to point to the Specimen and QuestionnaireResponse
- 25 is optional. You could share about the specimen collection procedure, but not sure anyone else will care
- Typically you wouldn't need DocumentReference for the rendered report. You'd just embed it in DiagnosticReport.presentedForm. However, if you want it to be available for MHD or something, then DocumentReference is fine.
Lloyd McKenzie (Jul 03 2018 at 13:01):
In response to your questions
1. The Task(s) assigned by the lab to the clinic could be "subtasks" of the original Task asking the lab to fulfill the order
2. It would typically be Procedure. Whether you need to actually expose the procedure or just the resulting Specimen is up to you
3. I'd probably have the original Task point to a PlanDefinition which points to ActivityDefinitions for specimen collection and completing the Questionnaire. In theory, when the clinical system retrieves the ObservationDefinition it could grab everything else and include those things on the original Task seeking fulfillment. However, if the expectations vary by fulfilling lab, then having the lab initiate the request is reasonable
4. I'd put it on ObservationDefinition and submit a change request for it to be added to core as I think that's something that would typically be part of the definition
Alexander Ivanov (Jul 03 2018 at 13:03):
1. : What do you want to define? The diagram you show with concrete steps and values seems like an ExampleScenario. If you want to define how the workflow CAN behave (i.e. what are the boundaries instead of a specific example instance) the you'd use PlanDefinition
We are interested in the exact case, is correct from FHIR point of view? Later on, we can create formal definition with PlanDefinition.
Alexander Ivanov (Jul 03 2018 at 13:26):
In response to your questions
1. The Task(s) assigned by the lab to the clinic could be "subtasks" of the original Task asking the lab to fulfill the order
2. It would typically be Procedure. Whether you need to actually expose the procedure or just the resulting Specimen is up to you
3. I'd probably have the original Task point to a PlanDefinition which points to ActivityDefinitions for specimen collection and completing the Questionnaire. In theory, when the clinical system retrieves the ObservationDefinition it could grab everything else and include those things on the original Task seeking fulfillment. However, if the expectations vary by fulfilling lab, then having the lab initiate the request is reasonable
4. I'd put it on ObservationDefinition and submit a change request for it to be added to core as I think that's something that would typically be part of the definition
3. I think we can use PlanDefinition and ActivityDefinition for specimen collection and Questionnaire. It will reduce the number of requests.
But there is an issue with the number of specimens to be taken, for example, some labs allow to take one container for two ServiceRequests and the other requires to take separate containers for each ServiceRequest. The number of containers and specimens is calculated based on all requests received by the laboratory, that is why I think laboratory should initiate the request for specimens.
Lloyd McKenzie (Jul 03 2018 at 13:32):
That makes sense
Alexander Ivanov (Jul 09 2018 at 07:28):
@Игорь Николаев you've asked for the last version of sequence chart:
Workflow-states-for-a-lab-order-for-a-blood-test-using-lab-broker-dispatcher.png
Lloyd McKenzie (Jul 09 2018 at 08:02):
Looks good. Step 14 is optional. It's a directed Task and presumably the requesting EHR isn't going to say "no". (If they do, they don't get their test results :>). So it's not essential to communicate to the lab that they've agreed to do the task - unless it's possible for multiple systems to provide the specimen and QuestionnaireResponse.
In terms of communicating the QuestionnaireResponse and Specimen back to the lab, there are two options. Updating the ServiceRequest is a valid one and probably my preferred choice as it puts the information where it should ideally be. However, in some workflows the notion of updating an order once fulfillment is underway might be deemed "problematic". If that were the case, your alternative would be to attach the information as outputs to the Task. I'm not advocating for doing that, just letting you know you have the choice.
Last updated: Apr 12 2022 at 19:14 UTC
