DRAFT: Route planning/handover support

[duckbytes]

Adds a tab to the task overview page for Routes/Handovers. Adds general route planning capabilities.

Can be used for internal journeys or originating hospitals when collaborating with other groups.

Add a handover point to the route and set the location from the directory.

Click the map to expand for a maps view.

Each handover has these data points:

• handover location
• status
• assigned rider
• time handover completed

Status could be PENDING (assigned but not yet picked up) > PICKED UP > DROPPED OFF > COMPLETED (rider home).

The first and last elements in the list are the first pick up and final delivery points.

Draft model for the schema:

type Handover
@auth(rules: [
  {allow: private, operations: [read]},
  {allow: groups, groups: ["COORDINATOR", "ADMIN"], operations: [create, read, update]},
])
@model {
  id: ID!
  tenantId: ID! @index(name: "byTenantId")
  task: Task! @belongsTo
  timeOfHandover: AWSDateTime
  handoverLocation: Location @belongsTo
  orderInGrid: Int!
  status: TaskStatus
}

Also add to Task model:

handovers: [Handover] @hasMany

TaskAssignee model:

type TaskAssignee
@auth(rules: [
  {allow: private, operations: [read]},
  {allow: groups, groups: ["COORDINATOR", "RIDER", "ADMIN"], operations: [create, read, delete]},
])
@model {
  id: ID!
  tenantId: ID! @index(name: "byTenantId")
  role: Role!
  task: Task @belongsTo
  assignee: User! @belongsTo
  handover: Handover @belongsTo
}

Piggybacking on the TaskAssignees model to record assigned riders to a handover, by adding a Handover relation. This means the dashboard only has to look at one datasource for displaying all riders tasks on their dashboard.

This would change the Task to non-required (on master current it is a required field). Could also add a new role to Role enum: HANDOVER.

I had considered using the same Task model for handovers instead of creating a new model, however this would mean duplicating data to keep records consistent (priority, contact information). It would also add unnecessary data points like time picked up, time dropped off, when only time of handover is required.

Uncertain how to handle assignments to the task itself, as depending on whether there are handovers, a rider needs to either pick up a job and take it to the delivery destination, or take it to the next handover point.

If a rider is assigned to the task their dashboard will display the task as if they were taking it the whole way. If assigned to the rider as a handover it'll show just their leg of the trip.

It could be that we should adopt the same type of assignment record for all rider jobs, regardless of if the Task has any handovers or not.

Code is still a work in progress and this is a draft pull request.

@ianphunt58 and @petersjtaylor can you provide feedback please?

[ghost]

Looking at the description I am not sure I see the need for a separate workflow for Handovers, at the end of the day, the destination is the Handover point, the rider will go no further. For the handover rider his job starts from the Handover point. Perhaps when creating Handover jobs, n job records need to be created for as many destinations as there are, 2 by default.

[duckbytes]

That workflow does work for the time being, but I think there are some benefits to adding relay support:

• Overall a better user experience, as it's easier to think of one job having multiple steps, rather than having completely separate jobs
• Better tracking: eventually I want to add a view that tracks the steps of a job. For external users they can see where their delivery is or has been. For volunteers they can look up a job in the past and see exactly each step of the delivery, which would be very difficult if the jobs were separate.
• No duplication of data. A job has the same urgency, contact details and time of call. Maintaining two separate jobs would mean trying to duplicate and synchronise any changes between those records. The drop off time would be the same as the pick up time of the next.

I also think the map feature would be a very nice one for visualising relays and seeing the distances involved.

[ghost]

That workflow does work for the time being, but I think there are some benefits to adding relay support:

• Overall a better user experience, as it's easier to think of one job having multiple steps, rather than having completely separate jobs
• Better tracking: eventually I want to add a view that tracks the steps of a job. For external users they can see where their delivery is or has been. For volunteers they can look up a job in the past and see exactly each step of the delivery, which would be very difficult if the jobs were separate.
• No duplication of data. A job has the same urgency, contact details and time of call. Maintaining two separate jobs would mean trying to duplicate and synchronise any changes between those records. The drop off time would be the same as the pick up time of the next.

I also think the map feature would be a very nice one for visualising relays and seeing the distances involved.

Ok, I can see a few use cases in your response there. Does the code support all of those use cases?

[duckbytes]

Ok, I can see a few use cases in your response there. Does the code support all of those use cases?

They can be supported. This will be a good starting point I think.

Looking up historical records is high up on my list of things to do too. I might pick that up quite soon.

[ianphunt58]

Not really sure if I should comment, way too detached now of the plan or the schedule or the status of any go live at Freewheelers. Happy to get involved but need to know the structure now, it drifted away from me Ian Hunt Chair – SERV Herts and Beds From: Peter SJ Taylor ***@***.***> Sent: 30 January 2023 11:40 To: platelet-app/platelet ***@***.***> Cc: ianphunt58 ***@***.***>; Mention ***@***.***> Subject: Re: [platelet-app/platelet] DRAFT: Route planning/handover support (PR #122) That workflow does work for the time being, but I think there are some benefits to adding relay support: * Overall a better user experience, as it's easier to think of one job having multiple steps, rather than having completely separate jobs * Better tracking: eventually I want to add a view that tracks the steps of a job. For external users they can see where their delivery is or has been. For volunteers they can look up a job in the past and see exactly each step of the delivery, which would be very difficult if the jobs were separate. * No duplication of data. A job has the same urgency, contact details and time of call. Maintaining two separate jobs would mean trying to duplicate and synchronise any changes between those records. The drop off time would be the same as the pick up time of the next. I also think the map feature would be a very nice one for visualising relays and seeing the distances involved. Ok, I can see a few use cases in your response there. Does the code support all of those use cases? — Reply to this email directly, view it on GitHub <#122 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYEX27YKVHPHXDZSB6CH4GTWU6SADANCNFSM6AAAAAATHAHZHQ> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AYEX273UDKSQVIJPVGGLYF3WU6SADA5CNFSM6AAAAAATHAHZHSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST6OI4Y.gif> Message ID: ***@***.*** ***@***.***> >

[Joetooker95]

I like the idea of being able to see a point by point tracking/ progress update screen and for the rider only to see their leg of the journey instead of the entire run to save confusion.

[MajesticCake]

There are two distinct types of relays, relays that are wholly internal to the one blood bike group and a relay with another blood bike group, and the two distinct relays could feasibly be required for a single job.

Internal Relays
For internal relays utilising two (or more) riders, it is desirable to be able to monitor the multiple riders. Currently on single rider jobs the rider marks the job as "Rider Home" after the items are delivered and the rider is home, this completes the job.

If there is but one job and a "handover" option what does the first rider do when they have returned home? They can't mark the job as rider home as they do for a single rider job as this will potentially "Complete" the job before the items have reached the final destination.

Sometimes, it is required to have three or more legs of an internal relay, this would require two lots of handover buttons on a single job. Would the number of handovers be configurable by the coordinators?

External Relays
Currently relays with other blood bike groups requires each group to set up a job for their own group. Would it be possible to have a single job that goes across groups? The groups involved in the relay would need to be utilising Platelets for this to happen, what problems would there be if the other group(s) were not using Platelets?

Exported Data
The job data is exported as a CSV file, what would the data look like for a relay job? It needs to be recognisable as a relay job especially if the job was in conjunction with another blood bike group.

[duckbytes]

User stories

Coordinators

• I want to record a job that might require a handover. I will know if the job requires a handover once the pick up and drop off locations are known. The handover details can be entered once the job is created.

• I want to decide a handover point where two riders will meet and exchange the items. A single delivery might have multiple handover points with multiple riders.

• I want to assign a rider to each handover and make clear their role in the exchange.

• I want to be able to record whether or not a handover is to another blood bike group. If the other blood bike group is using platelet, I should be able to specify the group and record it against the job.

• If a coordinator from another blood bike group has assigned our group, I want to be notified and see details of the request.

• If a handover from another blood bike group is pending, I want to decide if we can accept or reject the handover. I will need the appropriate information to make this decision. The handover point, the final destination, timelines and schedule, inventory, and priority.

• A handover from another blood bike needs to show any additional useful information, like contact details of the delivery destination.

• Once I have accepted or rejected the handover from another blood bike group, I might want to define internal handovers, or hand over the destination to a further blood bike group.

• As a coordinator for the originating pick up and the group facilitating the final delivery, I want to see the current status of the job (active, picked up, etc.) and the associated times (pick-up time, etc.).

• As a coordinator for the originating pick up, I want to communicate with all involved parties including those from other blood bike groups.

• As a coordinator for the blood bike group facilitating the final delivery, I want to be able to communicate with the originating group coordinator.

• I want to see a map of the entire route, with an indicator for each handover point.

• When looking at the route, I want to see something that indicates the current active leg.

Riders

• I want to see the pick up and drop off destination of my leg of the route.

• I want to know if the pick up or drop off destination is a handover or not.

• I want to record the time of handover.

• If I have picked up the item from another rider, I should not also have to enter the time of pick up. However this might be needed if it is being handed over to me by another blood bike group.

Admins

• I want to export data in such a way that reflects each handover step under one job detail.

• I want to update locations in the directory as a handover point.

@MajesticCake @Joetooker95 @FlashJackFromGungagai please let me know if you have any feedback or more suggestions for user stories.

[duckbytes]

Key persons and timelines

Coordinators

The initial coordinator is the key person and primary contact for all involved in the process. They decide where handovers take place while their group is responsible for the item, who does the delivery, and whether or not it goes to another blood bike group. They also receive the initial call from the NHS staff member.

Each involved blood bike group will have a coordinator. Typically the coordinator for each blood bike group will contact next coordinator required in the chain until delivery happens.

The coordinator responsible for the current leg decides where handovers take place and who will take the item.

NHS staff member

The NHS staff member is the key customer. They call the blood bike group telephone number and are put in touch with the coordinator. Delivery details are exchanged with the coordinator, who then accepts or rejects the request.

Riders

There are two or more riders involved in a handover.

• First rider picks the item up from the sender.
• They hand over to the next rider at a given handover point.
• Second rider hands over to a third rider, or deliver the item.

Potentially there are as many riders as needed in as many groups until the item is delivered. Occasionally deliveries have been made cross country with more than two groups. Assuming three groups involved with internal handovers to cover the long distance, as many as 6 riders could be involved from start to finish.

Sender and recipient

Typically someone will be at the pick up location and the drop off location to send and receive the delivery. The name of the sender and recipient is taken on pick up and delivery.

Assuming that all riders are on the system, it may not be required to record the name of the rider at each handover.