Stream: implementers
Topic: Pre-booking and pro-booking
Medi Harsini (Dec 02 2019 at 15:05):
I am trying to create a concept around Workforce Management using FHIR. I have got three main events as follows:
a) Request for a demand: Technically a request listing all the requirements for someone to fill it in. Technically speaking you say what sort of clinician you need for an appointment. Did anyone come across something similar in clinical transactions? If yes, what resource has been used? A service request perhaps?
B) Booking: Which I used an appointment.. technically here is the guy you looking for...
C) Time sheet: which I am planning to use encounter (as per @Rik Smithies kind advises) . Technically a correction on the appointment saying here is the actual time period for the appointment.
Would love to hear what you are thinking on the above concept specially what you suggest on "A"
PS: All the concept above has a 1-1 relationship.
Thanks
Lloyd McKenzie (Dec 02 2019 at 15:58):
ServiceRequest (or Task or other Request resources) are typically how you define what's needed. @Brian Postlethwaite, comments on the other questions?
Rik Smithies (Dec 02 2019 at 16:05):
The Encounter is really just the "shift" that a staff member ends up doing (after a request goes out to find someone to work that shift). It's not an encounter with a patient (well, if it is, that is not recorded), but otherwise it has many of the same characteristics. And the Appointment is really just a request for a person to do a shift, and again, is staff rather than patient centric. The Encounter fulfills/instantiates the Appointment and may be longer or shorter in the end. Would be good to get input on using these in a staff oriented pattern.
Medi Harsini (Dec 02 2019 at 17:55):
Thanks @Rik Smithies and @Lloyd McKenzie for your inputs. I will check the Task and ServiceRequest. From what it seems to be the case, we may be able to use servicerequests for a group of tasks and and task to be used for the actuak requirement. I will review this tomorrow against the current model and see if it can be fitted
Medi Harsini (Dec 13 2019 at 12:16):
@Rik Smithies @Lloyd McKenzie Thanks once again for your helps. I have established that service request is perhaps best describing the actual demand for a worker. I am still not sure, about the use of appointment to fulfil the bookings. What would be the logic workflow once a servicerequest is defined? Technically speaking Appointment and Appointmentresponses are not part of FHIR workflow. So with a clear mind, is there a resource in FHIR which have the concept saying " I want to place this practitioner here to response this service request?" and what would be the resource to use, after when the work is completed to say this is actual event once it has been completed?
CC: @Brian Postlethwaite
Lloyd McKenzie (Dec 13 2019 at 12:32):
Typically, you create the ServiceRequest. Then you create a Task asking some provider to satisfy all or part of the ServiceRequest. They mark the Task as accepted. They then create whatever they need on their side to drive the execution (a 'filler-order' ServiceRequest, Appointment, etc.). They execute the Task, updating status as appropriate. Eventually they produce outcome documentation (Observations, Procedure, DiagnosticReport, CarePlan, whatever) and list those as outputs of the Task and mark the Task as complete.
Medi Harsini (Dec 13 2019 at 13:47):
Thanks @Lloyd McKenzie It seems that we are almost right on the concept then. A servicerequest will be sent to the serviceprovider and it carries enough info to make the booking. So task is not needed I guess. The actual execution from the service provider is Booking (which I guess I used Appointment for). Appointment is booked John Doe to the service request... And then John Doe would have a timesheet. What do you think of timesheet, is there any resource which has got a similar concept? Rik suggested Encounter which is in fact can answer what want.
Lloyd McKenzie (Dec 13 2019 at 14:22):
To trigger action, a request needs either an "actionable" tag or an associated Task. Merely posting a Request to a system can't be presumed to request action. The request is merely an authorization.
Lloyd McKenzie (Dec 13 2019 at 14:24):
In terms of time sheet, it depends what sort of time is being captured. Encounter, Procedure or possibly other resources could be appropriate
Medi Harsini (Dec 13 2019 at 16:09):
@Lloyd McKenzie As creating Tasks is not needed here specially because once a request is created and sent, it is actionable. Hence, we will have to do the servicerequest.meta.tag = actionable. Does this satisfy the requirement to not create a task? I have checked https://www.hl7.org/fhir/workflow-management.html and all the routes seem to mandate a creation of a task? Can we get away from it? if no, can we then create it in the filler system but not provide a facility to inform the filler?
Timesheet happens when the appointment/booking is finished to list the differences from planned vs actual
René Spronk (Dec 13 2019 at 16:31):
@Lloyd McKenzie request is the "recording of the authorization" - nitpicking maybe, but the wording helps to point out that as a mere "recording" its is not something that's to be acted upon per sé
Vassil Peytchev (Dec 13 2019 at 16:35):
Since this is closely related to booking an appointment, have you looked at the Argonaut scheduling profile? https://www.fhir.org/guides/argonaut/scheduling/index.html
Medi Harsini (Dec 13 2019 at 16:49):
@René Spronk Having look at https://www.hl7.org/fhir/workflow-management.html#12.8.7 , a servicerequest actionable can be sent instead a task to the placer system. I wondered if creating a task is really needed? What would happen if I dont want to use task at all? Am I going to be non FHIR compliant? Becasue the task is not really applicable on my usecases. unless I can use the task instead of appointment/booking. The booking in my world is need to book someone to fulfill a servicerequest for a specific time period
Lloyd McKenzie (Dec 13 2019 at 19:40):
A ServiceRequest is only actionable if it has the relevant tag or is pointed to by Task. You can skip Task and just use Tag. However, that means that there's no mechanism for the recipient to say "no" and there's no means to track progress. If you're ok with those limitations, then ServiceRequest (with the tag) is fine.
Vassil Peytchev (Dec 13 2019 at 19:50):
There is also the alternative of an operation which takes a ServiceRequest as a parameter, then you don't even need a tag...
Lloyd McKenzie (Dec 13 2019 at 21:23):
But you do need to convince everyone relevant to support your custom operation...
Vassil Peytchev (Dec 13 2019 at 21:49):
That's true, and as presented, the requirement for a ServiceRequest to result in a list of appointment slots sounds like it is for a fairly constrained community.
I hope it is clear that the availability of a variety of options presented here is due to limited input and analysis of the requirements. In a differently established FHIR ecosystem one could:
- request the available appointments, similar to the Argonaut Appointment Availability Operation
- book an appointment, where appointment.basedOn references the relevant ServiceRequest
This removes the need for ServiceRequest to be actionable, but puts the burden on the requester to manage the process.
Medi Harsini (Dec 13 2019 at 21:50):
@Lloyd McKenzie Thanks, I think i understood you completely and can live with the constraints as long as the placer can revoke it. The filler in my world, should always try to find a match. @Vassil Peytchev thanks, not sure If I know what you mean exactly. A was
@both Also On a différent note, If i want to say I’m placing a practitioner or a person in a location to fulfill a task, which resource do you recommend. I want to be able to provide multiple identifier of the person and also some coding associated to like skillsset
Lloyd McKenzie (Dec 13 2019 at 21:55):
Either the resource that represents the filling action (Procedure, Encounter, etc. Or Task. The individual would be Practitioner
Medi Harsini (Dec 13 2019 at 21:57):
Certainly not appointment ?
Lloyd McKenzie (Dec 13 2019 at 22:07):
That could work too
Medi Harsini (Dec 13 2019 at 22:22):
And an encounter for the timesheet elements including the elements of the exact time or exact locations ?
Alternatively I can create my booking with encounter and also send another encounter to deliver the exact times and exact locations ? All based on task? or serviceRequest?
Lloyd McKenzie (Dec 13 2019 at 22:37):
What kind of activity are you scheduling?
Medi Harsini (Dec 13 2019 at 23:08):
Well, as stated initially . It’s a shift to fulfill a role. A typical scenario would be
1- Request: I need a male head nurse for ICU for this start to end time
2- Booking: I found John Doe which can do the job
3- Timesheet: John Doe has completed the shift for this actual start time to end time. This then gets feeded to pay John Doe
@Lloyd McKenzie
Lloyd McKenzie (Dec 13 2019 at 23:46):
Ah. So shift scheduling. My leaning would then be:
Task for what's needed when and where
Task gets updated when someone is assigned
Task gets updated to completed when done - possibly with sub-tasks representing actual shifts
Encounter wouldn't be appropriate as it's not about a meeting between a particular patient and the healthcare systems or between providers. ServiceRequest is also more clinical. This is more administrative
Medi Harsini (Dec 14 2019 at 00:09):
Oh so all around Task only !
Lloyd McKenzie (Dec 14 2019 at 00:26):
I think so
Medi Harsini (Dec 15 2019 at 02:36):
Thanks @Lloyd McKenzie . After a long review I think I’m going to propose; Service Request => Task for booking => Task for timesheet
On a higher note, I’d have to define job roles and positions. A job is a continues aggregated of services if you like. Any suggestions on that?
Also, once a task is completed how do you define the pay elements on paying the performer? Thanks once again
Lloyd McKenzie (Dec 15 2019 at 04:16):
The managing of provider payroll isn't really in scope for FHIR. You may have to look at Basic. In terms of provider roles, you could look at PractitionerRole. I'm not totally understanding your notion of 'job'
Medi Harsini (Dec 15 2019 at 12:59):
@Lloyd McKenzie thanks. Well forgetting about the job for a second, can I please ask if there is a concept that I can groupe the service requests together? I think I’d be able to create a job if I can group them together. Before you said the service request itself can be the answer, I want Service not the request elements. I want to be able define A Service before it gets to Service Request.
On a différent note, once a task if finished how to add a pay elements or create a pay elements for the task? Can a task carry a pay element as well ?
Medi Harsini (Dec 15 2019 at 15:07):
@Vassil Peytchev Thanks for your comments previously. Can you please elaborate on what you said on creating an Operation which takes service request as parameters
Lloyd McKenzie (Dec 15 2019 at 22:03):
We have Claim which involves receiving payment from insurers. And we have Invoice and InvoiceElement which are aimed at receiving payment for other means. We have ExplanationOfBenefits which involves describing what payments have been made by an insurer. It's possible you might be able to make one of those work, but we don't really have anything whose purpose is tracking payments from a healthcare organization to its providers
Medi Harsini (Dec 15 2019 at 22:07):
Thanks @Lloyd McKenzie . Can you please kindly advise on the first part of the question on how to dm define group of services before it gets to service request
Lloyd McKenzie (Dec 15 2019 at 22:11):
What is the purpose of the group? What are the ramifications of something being part of the group vs. not? Are they always ordered together? Do they have dependencies?
Medi Harsini (Dec 15 2019 at 22:51):
They may get ordered, paid separately. Also the they may need to be defined for planning. The fields on the job is different.
A job can be broken down to smaller shifts and if they’re vacant, I’ll be defining them in service request to be converted to task to be fulfilled
Lloyd McKenzie (Dec 16 2019 at 00:32):
It's possible to put a common grouping id on multiple requests indicating they were authored simultaneously. There's also RequestGroup, but that's for Requests that have strong interdependencies and can't have their status managed separately. A third possibility is to just use Task. It supports composition.
Medi Harsini (Dec 16 2019 at 09:58):
(deleted)
Medi Harsini (Dec 16 2019 at 16:34):
@Lloyd McKenzie @Rik Smithies Thanks both for your generous time on my concept. After a gap analysis of my concept against both of the following routes, and have also internally reviewing the concept against the possible two routes (Service Request->Tasks->Task VS Service Request->Appointment->Encounter), it has been voted in the favour of the latter. So I am going to propose the concept based on that having you guys suggestions in mind. Thanks once again.
Last updated: Apr 12 2022 at 19:14 UTC
