FHIR Chat · Request - Status - Response (Event) · workflow

Stream: workflow

Topic: Request - Status - Response (Event)

nicola (RIO/SS) (Dec 10 2019 at 15:23):

Sorry for intrusion :) For some national system we discussed request-response(event) integration. On the patterns page, we see a definitions-request-event model. I missed important integration aspect - status tracking and management. Spec recommends use Task to track the status of the request. It seems for me, tasks are internal implementation details of a "performing system". What do you think about introducing a "Status" pattern? There are two options - inline status into a request or keep it as a separate resource (but not a task). In Kubernetes for better UX status is a part of object, which updated by "performing system". User sends object definition and introspect (track) status by reading object.status (there is special API to update only status element - as we have in FHIR for some meta elements). Another approach is to have a separate specialized resource - [X]Status (ClaimStatus for example). Tasks can update status, but should not be a public API. The key design point is that specialized Request will have a very specific Status (which should be modeled in a "natural way" as other FHIR resources). I understand the temptation to use "generalized Task", but isn't this a way to do the same mistakes as v3 did?

nicola (RIO/SS) (Dec 10 2019 at 15:24):

As a "modern" client I would describe my "wishful" integration workflow:

1. I send [X]Request
2. I can track [X]Status by polling [X]Request.status (`GET /[X]Request/<id>/status`) or link on [X]Status provided during the request
3. If it's not too late, I can update or cancel [X]Request
4. From [X]Status I can discover [X]Response available (ideally as reference)

nicola (RIO/SS) (Dec 10 2019 at 15:34):

Here is another description of this workflow:

As "a requesting system" I create "request" resource
If it's not against business rules, I can refine or cancel "request" by "updating request resource"
As "a performing system" I manage "status" resource for specific "request" to reflect "current state" of "request"
As "a requesting system" I can track "status" of "request" by polling API/Subscription etc
As "a performing system" I publish "response" resource and update "status"  (ideally providing a ref to "response" ). Ideally "request" resource can be "finalized" and linked with "response"
As "a requesting system" I discover from "status" that "request" is "completed" and ref to retrieve "response"

Lloyd McKenzie (Dec 10 2019 at 15:41):

A Request might have three different systems simulaneously fulfilling different aspects of the request. (Or alternatively, there may be numerous different systems fulfilling different aspects over time). The Request status reflects only the status of the authorization, never the status of the fulfillment because of this many to 1 relationship. Task is the resource that manages tracking of fulfillment. It acts as a shared resource that can be manipulated by both placer and filler systems. (Typically filler systems have no authority to make any changes to the authorizing Request, though they may create their own mirror "filler order" Request that represents the details of what they've actually agreed to do.

nicola (RIO/SS) (Dec 10 2019 at 15:47):

Isn't task too detailed to be public API resource?

nicola (RIO/SS) (Dec 10 2019 at 15:49):

I'm talking about Status resources (which can be backed by tasks) but specialized for Requests.

nicola (RIO/SS) (Dec 10 2019 at 15:53):

Let say Task implements part of the Status interface, but often has a lot of "internal details" of "performing party" and does not have "specific status details" for "requesting party"

nicola (RIO/SS) (Dec 10 2019 at 15:54):

I.e. semantic volume of Status resource is much smaller and can be specialized

nicola (RIO/SS) (Dec 10 2019 at 15:59):

I'm afraid in real systems we will have a heterogeneous heap of "generic" Tasks with an enormous amount of extensions.

nicola (RIO/SS) (Dec 10 2019 at 16:05):

It reminds me somehow v3 style - I hope, I'm wrong! "Too abstract/generic" resources make "design discussions" too hard. All participants keep their own ideas in mind.

Lloyd McKenzie (Dec 10 2019 at 16:18):

I don't really understand why there'd be a need for much in the way of extensions on Task. A Task lets you say "who asked for this?", "who's doing this?", "what is to be done?", "where are things at?". The granularity of the tasks on a public (or internal) interface is up to the system. It could just be a instance that's 1..1 with the Request or could get very fine-grained - generally as part of a compositional hierarchy. Task.businessStatus is specifically intended to convey a meaningful state to the requesting party. This is where something like "waiting for specimen delivery" or " undergoing secondary review" would go.

Task is the typical mechanism that systems will use whenever one system is asking another system to do something.

Lloyd McKenzie (Dec 10 2019 at 16:19):

I'm not clear on what the envisioned difference is between your proposed 'Status' resource and what's on Task. I also don't understand why there's a perceived need for specialization in either Status or Task.

nicola (RIO/SS) (Dec 10 2019 at 20:33):

Let me explain with example. When I made a purchase in an online store, I’m interested in its status - did they find the item when they brought it. I’m not interested in who packaged, the name of the driver, the brand of the truck - i.e. internals of workflow.

nicola (RIO/SS) (Dec 10 2019 at 20:34):

Isn't the same applicable to ServiceRequest or Claim?

Jose Costa Teixeira (Dec 10 2019 at 20:36):

A ServiceRequest would only contain the status of the request itself- draft, active, canceled... (and complete)

Jose Costa Teixeira (Dec 10 2019 at 20:37):

would not contain business status like "specimen collected" or "done, but not billed"

nicola (RIO/SS) (Dec 10 2019 at 20:38):

When physician ordered the lab panel, she intrested in did specimen was collected and delivered, estimated time of result, preliminary results etc!?

Jose Costa Teixeira (Dec 10 2019 at 20:38):

those business statuses correspond to things that are triggered by a request, but are well beyond the detail needed in a request

nicola (RIO/SS) (Dec 10 2019 at 20:39):

I'm not claiming this is a part of request.

nicola (RIO/SS) (Dec 10 2019 at 20:39):

I've missed status resource.

Jose Costa Teixeira (Dec 10 2019 at 20:40):

I'm not claiming this is a part of request.

Correct (you type too fast, or I am slow), be patient :)

nicola (RIO/SS) (Dec 10 2019 at 20:40):

;)

Jose Costa Teixeira (Dec 10 2019 at 20:41):

These statuses are a status of something, not a request. they are a status of a "thing that will/has been done". and that thing is task.

nicola (RIO/SS) (Dec 10 2019 at 20:41):

The question is how to design request/status/response protocol betwen two systems.

nicola (RIO/SS) (Dec 10 2019 at 20:42):

in case of online store do you suppose to use Task API to track purchase?

Jose Costa Teixeira (Dec 10 2019 at 20:43):

as example: a lab request triggers a couple of things that will run adjacent or combined:

1. collection, preparation, analysis
2. billing
3. patient pickup, preparation and delivery (since you mention the delivery)
   3.1 for fun, the pickup can be split into more things

nicola (RIO/SS) (Dec 10 2019 at 20:43):

Yep

Jose Costa Teixeira (Dec 10 2019 at 20:43):

The notion of status is depending on the thing it is running on.

Jose Costa Teixeira (Dec 10 2019 at 20:44):

So in the list above you can have 4 tasks, each with their status.

nicola (RIO/SS) (Dec 10 2019 at 20:44):

Yes, depending on workflow

nicola (RIO/SS) (Dec 10 2019 at 20:45):

But as a client, should i track all this tasks to understand the status of request?

Jose Costa Teixeira (Dec 10 2019 at 20:45):

(sure, all of this is depending on the workflow we choose. BTW, there is always the chance that 3.1 will be split in 3.1.1 or appended a 3.2 because the patient was not at home)

Jose Costa Teixeira (Dec 10 2019 at 20:45):

There is no status of a request.

Jose Costa Teixeira (Dec 10 2019 at 20:45):

What is the status of a prescription? When the meds are dispensed by the pharmacy?

Jose Costa Teixeira (Dec 10 2019 at 20:46):

what is the status of the lab example?
For a clinician who entered the request, in simple cases, it is just either done or not.

Jose Costa Teixeira (Dec 10 2019 at 20:46):

(and that is supported in the request)

Jose Costa Teixeira (Dec 10 2019 at 20:47):

if the status needs to be decomposed, then it is because different things that need to be done.

nicola (RIO/SS) (Dec 10 2019 at 20:47):

For me this workflow looks like Implementation details, as a client I'm interested in milestones of it

Jose Costa Teixeira (Dec 10 2019 at 20:48):

sure, then you can use task to keep track of the business status that includes those milestones.
If you are in the clinical side, you have a set of milestones

Jose Costa Teixeira (Dec 10 2019 at 20:48):

if you are in the billing, perhaps another set of milestones

Jose Costa Teixeira (Dec 10 2019 at 20:50):

You can use Task resource without having to describe the detailed workflows, i.e. basically as a status tracker

Jose Costa Teixeira (Dec 10 2019 at 20:51):

it would really be a small json... which I think is what you are looking for, right? Just a notion of "where this is at"

nicola (RIO/SS) (Dec 10 2019 at 20:52):

That's why I'm afraid of too abstract resources ;)

Jose Costa Teixeira (Dec 10 2019 at 20:53):

would it help to make some examples (we really really should)?

nicola (RIO/SS) (Dec 10 2019 at 20:54):

Can you sketch api/protocol using tasks to order MRI, track status and get report?

nicola (RIO/SS) (Dec 10 2019 at 20:54):

Suppose we have hospital and external MRI center

nicola (RIO/SS) (Dec 10 2019 at 20:55):

i.e. two systems/Organizations

nicola (RIO/SS) (Dec 10 2019 at 20:55):

oh i forgot patient

Jose Costa Teixeira (Dec 10 2019 at 20:57):

what do you mean you forgot patient?

Jose Costa Teixeira (Dec 10 2019 at 20:57):

(hoping you don't mean you are actually in a hospital and a patient is waiting for you...)

Jose Costa Teixeira (Dec 10 2019 at 21:00):

I could draft an exampleScenario starting with that. Somewhere this week is still OK with you? Or better, join the Workflow call monday?

Jose Costa Teixeira (Dec 10 2019 at 21:01):

if you can provide more info (unless you just want a really simple sequence of request, no scheduling, no contrast, nothing)

nicola (RIO/SS) (Dec 10 2019 at 21:04):

Thank you. I will try to join a call. No rush at all ;)

Jose Costa Teixeira (Dec 10 2019 at 21:05):

Thanks for the question, it stimulates us to produce guidance.

nicola (RIO/SS) (Dec 10 2019 at 21:05):

But waiting physician, patient and integration engineer would be nice motivation;)

Vassil Peytchev (Dec 10 2019 at 21:33):

Have you looked through http://build.fhir.org/workflow-communications.html? On that page you will see several scenarios that explain how this is done using a Task resource, without specifying how the Task resource is shared.

Then there are several RESTful patterns of sharing Task for the purposes of workflow management at http://build.fhir.org/workflow-management.html, and there is also the option to use FHIR messaging or operations/services for sharing a Task resource.

Lloyd McKenzie (Dec 11 2019 at 00:23):

When a MedicationRequest is created, nothing happens. No drugs are dispensed. No drugs are administered. In the paper world, the patient might take the script and stick it in their pocket and run it through the laundry and never get it filled. (Or not run it through the laundry and still never get it filled.) The trigger for action is the "request for fulfillment". And a request for fulfillment often isn't to action the entire order. The script might be for 30 days supply and 11 refills. But maybe this is an expensive drug - and it's not tolerated that well, so the pharmacist (or the patient's insurer) recommnends only getting 10 days supply and see if it works. So a fulfillment request (Task) - pointing to the MedicationRequest as its authorization - is created asking the pharmacy to dispense 10 days supply. That Task has a status. The initial pharmacy might reject the prescription (they don't carry that drug). So a new task gets created targeting a different pharmacy than the patient's preferred pharmacy. This pharmacy accepts the request. Then they prepare the med. Then the pharmacist verifies the dispense. Then the insurance is processed. Then the patient is contacted saying the medication is ready for pickup. Then the package gets moved to the back drawer because the patient didn't pick it up the same day. Then finally it's picked up.

All of those would be updates to the same Task - changing the status occasionally (accepted, in-progress, completed) and the businessStatus every time. A week or so later, a new Task would be initiated asking for the remaining 20 days supply of the first fill. Then another Task for the next month. Then a Task for 2 months supply because the patient is going on holidays. Each Task would have its own status. The prescribing physician may or may not be aware of all of the tasks. It might be they only see the dispense events. It might be they see nothing at all. The key thing is that there can be numerous requests for fulfillment against a single Request - and each of those requests for fulfillment will have an independent status.

In practice, there may be sub-tasks generated against the base "please fulfill" Task. In a lab scenario, there could be a separate Task for each step/machine the specimen runs through. Those would typically never be exposed outside the filling system though. The high level "please fulfill" Task isn't going to have any details other than what pharmacy/lab/imaging center is doing the work and a single business code reflecting "where is it at".

Peter Jordan (Dec 11 2019 at 02:20):

When a MedicationRequest is created in countries with ePrescription Services, some things actually do happen and these events vary by domain - e.g. in NZ that request will be automatically sent to the Prescription Repository (Exchange); additionally, in others the patient also will nominate their pharmacy of choice who will be notified and will prepare the medication ready for pick-up. I'm certainly not disputing that there can be numerous tasks relating to a single request - but there is probably an almost infinite variety of these, particularly when insurance/reimbursement is involved which is very different outside of North America.

Lloyd McKenzie (Dec 11 2019 at 02:34):

The transmission to the pharmacy would generally be via Task - unless the pharmacy can't say "no"

Lloyd McKenzie (Dec 11 2019 at 02:36):

Merely posting a prescription can't result in the automatic counting of pills because sometimes prescriptions arr shared as an FYI (e.g. for drug - drug interaction checking)

Peter Jordan (Dec 11 2019 at 02:42):

You should check that with someone with detailed knowledge of how ePrescribing works in the UK - I've only seen the videos! However, there will obviously be exceptions to the most common workflows - e.g. the chosen pharmacy has run out of a particular drug. Some countries have a mix of paper and electronic scripts, others have moved (almost?) exclusively to paperless prescribing. Lots to consider here....including rest home prescribing, which is throwing up all sorts of new problems for the NZ ePrescription Service!

Lloyd McKenzie (Dec 11 2019 at 02:48):

If the UK is doing messaging, then message events can distinguish behaviour. However if they're doing pure REST, the spec only offers two ways of asking for fulfillment - setting a tag or using Task. The former option provides no mechanism to refuse or communicate status.

Peter Jordan (Dec 11 2019 at 03:01):

I don't think that the UK are using FHIR for ePrescribing and neither is NZ at present. It would be interesting to know which countries do have a FHIR-based operational ePrescription Service and which approach, messaging or REST, they've taken. Even more useful, from an NZ perspective, would be to see if/how anyone has upgraded such a service from a messaging-based design to a RESTful one.

Grahame Grieve (Dec 11 2019 at 04:10):

@Brian Postlethwaite do you know what we're doing here?

nicola (RIO/SS) (Dec 11 2019 at 08:42):

Let me try again: It's clear that behind request some workflow is started, which can be modeled by Tasks. As in Kubernetes, when I create a deployment or service a lot of things happening. I'm talking about top-level client interface/protocol to semantically tracking the status of a request, which I believe the client only cares about until the result. You can think [X]Status resource as a workflow summary, milestones, updated for a client by an internal workflow engine. Workflows variability is to hight to standardize, it is possible. With a domain focus group, we can describe important milestones of Lab or Radiology Order, describe it as ServiceStatus resource and help systems to integrate with each other :)

Grahame Grieve (Dec 11 2019 at 09:19):

I think it's just not that simple. It's a two way discussion about the status, with underlying process. It's not right to simplify too far

nicola (RIO/SS) (Dec 11 2019 at 09:22):

@Grahame Grieve can you elaborate? Do you mean the problem that underlying processes can vary a lot?

Grahame Grieve (Dec 11 2019 at 09:25):

no we don't care about the underlying processes. but we do care about the exchange between the requester and the requestee

Grahame Grieve (Dec 11 2019 at 09:25):

the requester says 'do this please'

Grahame Grieve (Dec 11 2019 at 09:26):

the requestee goes through a whole process and the requestee wants to know where it's up to.

Grahame Grieve (Dec 11 2019 at 09:26):

and it also might want to cancel it, but simply saying 'stop' doesn't actually mean 'stop' - it might be too late, for example, or it might take time

Grahame Grieve (Dec 11 2019 at 09:27):

so using a task to track the requestee status leaves the request representing the requester's desire

nicola (RIO/SS) (Dec 11 2019 at 09:30):

Completely agree. I fill some discomfort to call it "Task" (but my English is not native) - I would call it "Status of request". "Task" has an additional semantic load - but maybe I'm wrong. And this is ok to use "Task" as "Status".

nicola (RIO/SS) (Dec 11 2019 at 09:32):

I like kubernetes spec/status model - it's easy to comprehend (https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)

Lloyd McKenzie (Dec 11 2019 at 13:28):

Task is a generic mechanism to say "please do" and to allow communication between requester and performer. The "please do" might be "fulfill Request x". It might be "Change status of resource Y". It might be "Complete Questionnaire Z". In all cases, it serves as the means to ask, for the performer to accept/reject and for the performer to communicate "where things are at". Task seemed to be the most intuitive name we could come up with. Task has "intent", which means they can be proposed, planned or ordered. "Status" isn't terribly intuitive for covering that space. (And it's not obvious that separate resources would work better for existing systems.)

nicola (RIO/SS) (Dec 11 2019 at 14:39):

Isn't ServiceRequest as well "please do"? Should I say "please do" twice to know the status?

Tim Zallin (Dec 11 2019 at 14:44):

i.e. why for some "please do" requests we have specific domain resources like ServiceRequest, Claim, etc (which follow request pattern) and for other s we should use generic Task resource?

Tim Zallin (Dec 11 2019 at 14:45):

for checking claim status for instance spec right now suggests to use Task with code = status

nicola (RIO/SS) (Dec 11 2019 at 14:45):

I agree "Status" does not look like an individual resource. That's why kubernetes guys embedded it into "Request" as sub-object, which updated by the "performing party" (that's tradeoff).

Vassil Peytchev (Dec 11 2019 at 14:49):

ServiceRequest is primarily for "ordering procedures for one patient". This is the authorization to ask "please do", and as such "belongs" to the provider who authorizes it, and it is (usually) not subject to change by another entity. The actual dynamic "please do" is represented by Task. When using Task for workflow management between systems, it is always paired with the authorization (which follows the request pattern) using Task.basedOn.

The documentation of ServiceRequest is sub-par in this regard. A tracker is incoming: J#25298

Tim Zallin (Dec 11 2019 at 15:05):

are you saying that typically I should use two resources, one for the actual request (e.g. ServiceRequest) and also the Task resource to track the state of completion?

Vassil Peytchev (Dec 11 2019 at 15:09):

Unless you have a very simple workflow, where no negotiation, rejection, or cancellation before completion is possible, then yes, you need two resources. This is (attempted to be) explained in http://build.fhir.org/workflow.html and the related pages.

Lloyd McKenzie (Dec 11 2019 at 15:59):

ServiceRequest is "I authorize". In some situations, the mere creation of a ServiceRequest may lead to the automatic initiation of a "please do", but that's not a given - and the processes are distinct. There are many ways to invoke a "please do", as covered in the workflow portions of the spec:

• messaging
• operation
• Task
• tag

Lloyd McKenzie (Dec 11 2019 at 16:00):

Having the Request updated by the performing party is problematic - especially if digital signatures are in play.

Grahame Grieve (Dec 11 2019 at 23:45):

also things like ServiceRequest exist in many records - a record that a service was asked for. That's not the same as actually asking for it to happen

Brian Postlethwaite (Dec 12 2019 at 09:43):

The Australian eprescribing is in its early days, but that's planned to be rest only.
I feel it's probably different to what others are taking about, it's a central shared register of prescriptions.
Prescribers all send here. Then any dispenser can dispense it, but obviously only 1. So no real workflow like being discussed here.
A patient can go to any pharmacy and get it dispensed.
I'll re-check with the others here.

Jose Costa Teixeira (Dec 12 2019 at 11:24):

"no real workflow here" ...yet (I assume)

Jose Costa Teixeira (Dec 12 2019 at 11:26):

You may eventually have to handle partial dispensing, no dispensing, updates to prescriptions, updates to prescriptions that are already partially dispensed, cancellation of prescriptions,...

Lloyd McKenzie (Dec 12 2019 at 12:23):

You'd also want to know what was in progress so that when one pharmacy starts processing the final dispense, the patient can't go somewhere else and also ask for the last dispense. I expect you'll find Task needs to sit in there somewhere.

Jose Costa Teixeira (Dec 12 2019 at 14:39):

This thread does remind me of the IHE Pharmacy profiles. In the beginning, there was no workflow... Then we only needed a status. When we realised, XDW was there

Peter Jordan (Dec 12 2019 at 20:51):

The requirements listed by @Jose Costa Teixeira and @Lloyd McKenzie are all handled by NZePS when implementing the central shared registry/repository/broker model. Actually, @Brian Postlethwaite , our architecture was originally based on that of the Australian eRX service! It will be interesting to see this implemented using FHIR and, yes, you will need to discuss a lot of workflow issues! I'm currently tasked with mapping the NZePS Data Model to FHIR R4 resources, but the use case is for accessing NZePS data passed to a Clinical Data Repository, not a change to our transactional model.

nicola (RIO/SS) (Dec 14 2019 at 08:05):

This thread does remind me of the IHE Pharmacy profiles. In the beginning, there was no workflow... Then we only needed a status. When we realised, XDW was there

The problem with workflow modeling and engines from my experience - they just do not work or work poorly in real life :( I sow properly working only simple status/checklist solutions

nicola (RIO/SS) (Dec 14 2019 at 08:23):

(deleted)

Lloyd McKenzie (Dec 14 2019 at 14:39):

Task tries to not be over-complicated. Though if you want complicated, you're free to bring in PlanDefinition and go to town :)

Jose Costa Teixeira (Dec 14 2019 at 19:00):

Yes, when reality kicks in, models tend to show their ugly side. This is why I mention XDW - things get ugly.

Jose Costa Teixeira (Dec 14 2019 at 19:07):

This discussion started looking for a "status" resource, we have Task that can hold the status and the checklist.
Implementations with Definition/Request/Event/Task can support simple or complicated cases.

Last updated: Apr 12 2022 at 19:14 UTC