Processing hannah

app/posts/processing/2024-05-30-update-for-40.md

@@ -0,0 +1,87 @@
+---
+title: Expanding design to account for 40 claims
+description: Updating processing flow to allow designs to account for 40 claims and differing information
+author:
+  name: Hannah Williams
+  url: '#'
+date: 2024-07-30
+tags:
+  - processing-version-3
+  - process-a-claim
+aside:
+  title:  Processing Prototypes
+  content: |
+    [View processing prototypes](https://adult-social-care-7fe9bafd955a.herokuapp.com/version-index?area=Processing) 
+    Password: ascbsa123
+---
+
+Version 3 claim id's for processing
+
+100
+Submitted: Z1Z-F1J6-3XF7-A
+Approved: Z8S-F1J6-4GH7-A
+Rejected: K93-SK68-3S2K-A
+
+60
+Submitted: WR5-R2P4-DSL4-B
+Approved: R4Y-NL7G-D967-B
+Rejected: NLE-BMDT-68ZI-B
+
+40
+Submitted: R7J-NC3G-D967-C
+Approved: R4Y-NL7G-D967-C
+Rejected: K92-HD52-7GD9-C
+
+## Why we did this work
+
+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.
+
+
+![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")
+
+## What our ideas were
+
+>**We believe that** the same info about the organisation, training and submitter 
+>**Will be needed for** processors
+>**As it will** help them follow the same process as they did for 60 with familiarity on layout
+
+>**We believe that** only the evidence of completion and not payment
+>**Will be needed for** processors
+>**As it will** help that focus on the important information to processing that relevant part of claim
+
+>**We believe that** the yes option having no further input needed
+>**Will be needed for** processors 
+>**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.
+
+![A screenshot from the processing a claim prototype showing a approved 40 claim ](40-yes.png "40 claim- not yet processed")
+
+>**We believe that** reiterating reimbursment amount breakdown
+>**Will be needed for** processors 
+>**As it will** be very clear what the next steps are and why
+
+![A screenshot from the processing a claim prototype showing a approved 40 claim ](40-outcome-screen.png "40 claim outcome screen - approval")
+
+
+>**We believe that** reiterating reimbursment amount on the approved claim screen
+>**Will be needed for** future processors 
+>**As it will** be very clear on what happened on this claim.
+
+![A screenshot from the processing a claim prototype showing a rejected 40 claim ](40-approved.png "Rejected 40 claim ")
+
+![A screenshot from the processing a claim prototype showing a rejected 40 claim ](40-rejected.png "Rejected 40 claim ")
+
+## How we tested our ideas and what we found
+
+- 60 and 40 being seperate wasn't liked as participants thought of them as 
+
+## What we will do next
+- Adding content to link 60 and 40 claims together
+- Allowing to be searched on with combined claim number
+
+>**We believe that** linking the other part of the 60/40 claim
+>**Will be needed for** processors
+>**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.
+
+
+
+

app/posts/processing/2024-05-30-update-for-60.md

@@ -33,38 +33,39 @@ One of our biggest questions for a 60/40 claim is whether the 60 / 40 parts of t
 >**Will be needed for** processors
 >**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.
 
-![A screenshot from the processing a claim prototype showing the current processing a submitted 100 claim](60-submitted.png "Current submitted 100 claim view - processing")
-
-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, 
-
->**We believe that** reimbursement amount is going to the 
->**Will be needed for** 
->**As it will** 
-
+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. 
 
 >**We believe that** well considered content
 >**Will be needed for** processors
->**As it will** allow them accurately calculate reimbursement amount.
+>**As it will** allow them to understand how it is calculated and what is needed of them to ensure the correct amount is reimbursed.
 
 >**We believe that** automatically calculating the reimbursement amount
 >**Will be needed for** processors
->**As it will** reduce the mental load. 
+>**As it will** reduce the mental load, and once we have the cost per learner from the processor.
+
+>**We believe that** needing the processors to enter the cost per learner rather than asking the submitters
+>**Will be needed for** submitters
+>**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. 
+
+#### Screenshot
+
+![A screenshot from the processing a claim prototype showing the current processing a submitted 100 claim](60-submitted.png "Submitted 40 claim view - processing")
 
 >**We believe that** the claim outcome screen
 >**Will be needed for** processors 
 >**As it will** provide space for content on reimbursment amount explanations and what is going to happen next.
 
-#### Screenshot
-- of the 60/40 submitter journey.
-This is the information the submitter has supplied and needs to be presented to the processor to process their claim correctly.
-This is the current view of the 100 claim processor journey.
-
 
+![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")
 
 ## How we tested our ideas and what we found
 
+- 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. 
+
 ## What we will do next
-- 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.
+- Refinement of content adding examples of reimbursement calculations.
+- 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.
+