You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To complete the functionality for a 60/40 TU claim to be processed, the 40 part needs to be accounted for in the designs. Because 40 claims are closely linked with 60, they were considered during the design process for 60 to allow for a holistic journey and reduce amount of work needing to be done in the future to update.
38
+
39
+
40
+
![A screenshot from the processing a claim prototype showing the current processing a submitted 60 claim](60-submitted.png"Current submitted 60 claim view - processing")
41
+
42
+
## What our ideas were
43
+
44
+
>**We believe that** the same info about the organisation, training and submitter
45
+
>**Will be needed for** processors
46
+
>**As it will** help them follow the same process as they did for 60 with familiarity on layout
47
+
48
+
>**We believe that** only the evidence of completion and not payment
49
+
>**Will be needed for** processors
50
+
>**As it will** help that focus on the important information to processing that relevant part of claim
51
+
52
+
>**We believe that** the yes option having no further input needed
53
+
>**Will be needed for** processors
54
+
>**As it will** not need any further information from the processors to calculate the reimbursement amount, this is information already supplied during the 60 part processing.
55
+
56
+
![A screenshot from the processing a claim prototype showing a approved 40 claim ](40-yes.png"40 claim- not yet processed")
>**As it will** be very clear what the next steps are and why
61
+
62
+
![A screenshot from the processing a claim prototype showing a approved 40 claim ](40-outcome-screen.png"40 claim outcome screen - approval")
63
+
64
+
65
+
>**We believe that** reiterating reimbursment amount on the approved claim screen
66
+
>**Will be needed for** future processors
67
+
>**As it will** be very clear on what happened on this claim.
68
+
69
+
![A screenshot from the processing a claim prototype showing a rejected 40 claim ](40-approved.png"Rejected 40 claim ")
70
+
71
+
![A screenshot from the processing a claim prototype showing a rejected 40 claim ](40-rejected.png"Rejected 40 claim ")
72
+
73
+
## How we tested our ideas and what we found
74
+
75
+
- 60 and 40 being seperate wasn't liked as participants thought of them as
76
+
77
+
## What we will do next
78
+
- Adding content to link 60 and 40 claims together
79
+
- Allowing to be searched on with combined claim number
80
+
81
+
>**We believe that** linking the other part of the 60/40 claim
82
+
>**Will be needed for** processors
83
+
>**As they will** be able to understand the situation going on with the other part to build the mental scaffolding in their head and see where the other part is up to in processing.
Copy file name to clipboardexpand all lines: app/posts/processing/2024-05-30-update-for-60.md
+26-13
Original file line number
Diff line number
Diff line change
@@ -19,40 +19,53 @@ aside:
19
19
20
20
For care skills funding there are two funding types: 100, and 60/40. So far the prototype and designs allow for 100 claims to be processed, but for MVP both 100 and 60 claims are expected to be delivered. There are differences between the information that is supplied by the submitter for these two types of claims so the designs need to be changed and considered to allow for them to be processed. The 40 part of the 60/40 claim is not expected to have any claims submitted for for quite some time so some scope that they may not need to be included for MVP, but because so closely linked with 60, still need to be considered during the design process to allow for a holistic journey and reduce amount of work needing to be done in the future.
21
21
22
+
![A screenshot from the processing a claim prototype showing the current processing a submitted 100 claim](100-submitted.png"Current submitted 100 claim view - processing")
23
+
22
24
## What our ideas were
23
25
24
-
One of our biggest questions for a 60/40 claim is whether the 60 / 40 parts of the claim are two seperate claims to be processed seperately or two parts of the same claim. This is something that is also being considered in the submitter journey alongside, on how we present. The two parts of a 60/40 claim will still be submitted at different moments of time and the 40 will only be processed if the 60 part is approved, so to fit into the current flow of a 100 claim, it fits as can be judged in isolation.
26
+
One of our biggest questions for a 60/40 claim is whether the 60 / 40 parts of the claim are two seperate claims to be processed seperately or two parts of the same claim. This is something that is also being considered in the submitter journey alongside, on how we present. The two parts of a 60/40 claim will still be submitted at different moments of time and the 40 will only be processed if the 60 part is approved, so to fit into the current flow of a 100 claim, it fits that can judge each part in isolation.
25
27
26
-
We believe that problem areas with 60/40 claims going into the condensed MVP single screen is the calculation of the reimbursement amount as this is already a area identified as confusing for processors with room for error,
28
+
>**We believe that** splitting and judging 60 and 40 parts of a claim to be judged in isolation
29
+
>**Will be needed for** processors
30
+
>**As they will** only need the information relevant to each part of the claim at that moment to process.
27
31
28
-
>**We believe that**reimbursement amount is going to the
29
-
>**Will be needed for**
30
-
>**As it will**
32
+
>**We believe that**following the layout of a 100 claim for a 60 claim
33
+
>**Will be needed for**processors
34
+
>**As it will**follow the layout they are already used to from processing 100 claims, and has much of the same or similar information that can adapt to work for both.
31
35
36
+
We believe that problem areas with 60/40 claims going into the condensed MVP single screen is the calculation of the reimbursement amount, as this is already an area identified as confusing for processors with room for error.
32
37
33
38
>**We believe that** well considered content
34
39
>**Will be needed for** processors
35
-
>**As it will** allow them accurately calculate reimbursement amount.
40
+
>**As it will** allow them to understand how it is calculated and what is needed of them to ensure the correct amount is reimbursed.
36
41
37
42
>**We believe that** automatically calculating the reimbursement amount
38
43
>**Will be needed for** processors
39
-
>**As it will** reduce the mental load.
44
+
>**As it will** reduce the mental load, and once we have the cost per learner from the processor.
45
+
46
+
>**We believe that** needing the processors to enter the cost per learner rather than asking the submitters
47
+
>**Will be needed for** submitters
48
+
>**As it will** reduce the burden on the submitters on what they have to submit, and we can train processors to ensure more accurate calculations.
49
+
50
+
#### Screenshot
51
+
52
+
![A screenshot from the processing a claim prototype showing the current processing a submitted 100 claim](60-submitted.png"Submitted 40 claim view - processing")
40
53
41
54
>**We believe that** the claim outcome screen
42
55
>**Will be needed for** processors
43
56
>**As it will** provide space for content on reimbursment amount explanations and what is going to happen next.
44
57
45
-
#### Screenshot
46
-
- of the 60/40 submitter journey.
47
-
This is the information the submitter has supplied and needs to be presented to the processor to process their claim correctly.
48
-
This is the current view of the 100 claim processor journey.
49
-
50
58
59
+
![A screenshot from the processing a claim prototype showing a submitted 60 claim getting approved and explaining the reimbursement amount on the outcome screen](60-outcome-explained.png"Submitted 60 claim - outcome screen explaining the reimbursement amount")
51
60
52
61
## How we tested our ideas and what we found
53
62
63
+
- From testing we found processors found cacluating the cost per learner difficult when presented with a variety of evidence, that sometimes stated costs for multiple learners, so they would have to work out how much from one.
64
+
54
65
## What we will do next
55
-
- For closing comments on the UCD log, give some information on what the next steps are with this piece of work, are there any further iterations that could be made but may not be as high priority just yet, is there further research to be done on a certain part of the design. Talk about things you were not able to do as part of this design that you want to be raised at a later stage and how this has been documented to be revisited.
66
+
- Refinement of content adding examples of reimbursement calculations.
67
+
- To be reflected in the future, post MVP, the iteration on this processing screen with the aim to reduce the cognitive load on the processor and refine how we ask them to check criteria.
0 commit comments