Stream: patient empowerment
Topic: Task Profiles - Request for Correction
Virginia Lorenzi (Dec 12 2020 at 06:15):
Some nitpicky questions for task masters:
1) Task.intent and Task.status are both mandatory - should they be Must Support as well?
2) We decided to use an R4 markdown type extension on Description - where is that extension exactly?
3) One of the reviewers of our spreadsheet asked: do Task.for and Task.requester have to actually be resources or could they be display strings?
4) Task.authoredOn is set to Must Support and 1..1 - does it need to be 1..1 or is 0..1 OK? All the other dates have Must Support and 0..1
@John Keyes FYI
Lloyd McKenzie (Dec 12 2020 at 15:07):
-
mustSupport lets you define what the expectations for 'support' are. E.g. "Must display", "must allow the user to capture", "must store", etc. I'd certainly expect Task.status to be displayed, stored and captured. I'm not sure that the same is true of Task.intent. The latter would quite possibly be implicit and not exposed to the user.
-
I'd posted it in the chat during our call. http://hl7.org/fhir/StructureDefinition/rendering-markdown
-
If we don't constrain, any reference could potentially just be Reference.display or even Reference.extension. However, I think we'd certainly want at least Task.for to be properly populated with a proper reference.
-
If we want to track the timelines associated with regulation, we need to know when the counter starts. I think that's the argument for 1..1
Virginia Lorenzi (Dec 13 2020 at 10:33):
@Lloyd McKenzie we were looking at the task statuses again and received status definition sounds better than requested to indicate that provider org has assumed responsibility and is reviewing the request. You had suggested we don't use received.
Lloyd McKenzie (Dec 13 2020 at 14:45):
Received is used when someone wants to claim ownership of an unassigned Task to keep someone else from claiming it while they evaluate whether they can do it or not. That's not really what we're talking about in our use-case.
Debi Willis (Dec 13 2020 at 20:59):
@Lloyd McKenzie I think the purpose of that status (for us) is to indicate that someone at the clinic has claimed the task and is going to review the record and get back to the patient with the status of whether or not they will accept or reject the requested change, or whether they need more time. We want to let the patient know that someone has received their request (instead of it sitting in a dark bottomless pit somewhere). The definition of received is listed as "A potential performer has claimed ownership of the task and is evaluating whether to perform it." It seems that "Received" fits what we need... to let the patient know someone has picked up the task." Thoughts?
@Virginia Lorenzi
Virginia Lorenzi (Dec 13 2020 at 22:44):
Yes Lloyd what you described sounds like a valid status. I imagine a queue of things not being looked at and then finally it is looked at and assigned out for review or review is done by that person. The queue is not a technical under the covers queue but an inbound worklist.
Lloyd McKenzie (Dec 14 2020 at 00:37):
In our case, the Task is already assigned, so there's no real need to 'claim' it - it's already owned.
Virginia Lorenzi (Dec 14 2020 at 01:22):
by who? Please explain more of the examples you see receive applying to I guess.
Lloyd McKenzie (Dec 14 2020 at 02:39):
If I post a Task seeking fulfillment of a referral for a cardiologist - but no specific owner is assigned, various cardiology clinics could subscribe and one could 'claim' it while they evaluated it against their business rules to decide if they would accept it. Or fulfillment might be sought to fill a drug order but you don't know what pharmacy the patient is going to. When the patient calls the pharmacy, they'd 'claim' the Task, but wouldn't necessarily agree to fill it until the pharmacist had reviewed it.
Virginia Lorenzi (Dec 14 2020 at 07:41):
request for correction comes into medical records department. There is a single queue and system or human chooses who to assign the task to for the review work or someone elects to claim it. I believe that happens but I will double check. Even if its sitting in the inbox - they have it but noone has even started looking at it, it seems like its in limbo and needs to get to "in review" state. I guess that could be represented by businessStatus = In Review @Debi Willis
Lloyd McKenzie (Dec 14 2020 at 14:50):
The initial state would be 'requested'. It would then transition to accepted or rejected once a decision has been made. It might bump around the organization to 3 or 4 people before it finds the one who's appropriate (and has enough information) to make a decision. It's not clear there's any value to shifting out of the 'requested' state to 'received' at any point.
Last updated: Apr 12 2022 at 19:14 UTC
