updating cpd processing

Author: hannah-williams-bsa

app/images/processing/cpd-processing/processed-claim-approved.png

@@ -65,7 +65,7 @@ Notes are decided not to be necessary to the core user journey to process a clai
 
 ### Remove multiple screens
 
-Multiple screens becomes more technical effort. Condensing into as few as possible by combining the critiera questions onto claim details screen for MVP and incorporating the reimbursement amount and rejection notes into a conditional input on criteria radio button input rather than on a seperate screen.
+Multiple screens becomes more technical effort. Condensing into as few as possible by combining the critiera questions onto claim details screen for MVP and incorporating the reimbursement amount and rejection notes into a conditional input on criteria radio button input rather than on a seperate screen. Removed edit rejection notes from the outcome screen as considered easy enough to go back to the unprocessed claim screen, edit notes and click continue again.
 
 #### Risks
 

app/images/processing/cpd-processing/processed-claim-rejected.png

@@ -15,37 +15,55 @@ aside:
     Password: ascbsa123
 ---
 
-We had a processing workstream kickoff on ... with the wider product team to begin the processing a claim piece of work. After understanding the constraints and the scope of the journey from multiple buisness and tech perspectives, we had a in-person workshop with the UCD team. We explored ideas of how this journey could look, what are the needs and wants of the users and then stripped it back to the MVP of what we deemed necessary to complete a processing claim journey based off assumptions and hypothesis'. We tested this inital design flow w/c 22 April 2024.
+## Why we did this work
 
+The prototype has been expanded to allow CPD claims to be submitted. The expectation is that there are going to be less of these type of claims, so the work balanced user needs with coming up with a design flow that has the least amount of changes needed to the TU journey, with minimal technical effort. This means when bringing CPD claims now into the processing side of the service there is also minimal design effort, more following the patterns and process of what has already been done.
 
+## What our ideas were
 
+#### Differences
+The two funding pots have different rules and information submitted so there are small differences that need to be displayed in the designs.
+- What you claim for. Tu claims are for courses and qualifications with awarding bodies and whereas CPD claims are open ended to cover books and journals to time spent mentoring etc. Tu training will have a set name to process whereas CPD claims have a free input textbox with up to 75 characters to describe.
 
-Allowing for 60 updates
-- Reimbursement amount, importance of content 
+>**We believe that** adding content stating whether its a revalidation or care skills claim
+>**Will be useful information for** processors
+>**As it will** set them up to know what kind of claim they are about to process as each has different information to look for.
 
+>**We believe that** encouraging the submitter to enter a verbose training description
+>**Will be useful for** processors
+>**As it will** help them understand the context of the claim.
 
-So far we have only included 100 claims designs in the prototype. Next up is 60 part of 60/40 TU claims. Can't think about 60 without 40 
+- TU funding has two types of 100 and 60/40 which has different and complicated rules on how much to refund and the burden is taken off the submitter and onto the processor to enter the cost per learner based off the evidence. For CPD funding its more straightforward, as a learner has a budget of £500 each and is allowed to submit claims up to that amount. In the service we have the amount the training cost and the remaining budget amount, so the amount to be reimbursed is something the service can easily calculate itself, rather than asking the processor to work it out. The processor just needs to check the evidence of payment matches the criteria and the rest will be predetermined.
 
-So far we have only included 100 claims designs in the prototype. We have considered the 60/40 TU claim offering along the way considering whether our current designs would have the flexibility to 
+>**We believe that** displaying the learner budget remaining
+>**Will be useful for** processors
+>**As it will** help them to understand the context of the claim and can check the reimbursement calculation.
 
-## Why we did this work
+>**We believe that** removing the need to enter a reimbursement amount
+>**Will be useful for** processors
+>**As it will** remove the burden and chance of error in calculation.
 
-One of our biggest assumptions for a 60 claim is whether the 60 / 40 parts of the claim are two seperate claims or two parts of the same claim.
+![A screenshot from the processing a claim prototype showing a unprocessed claim](unprocessed-claim.png "Unprocessed claim")
 
-## What our ideas were
-- Providing visuals of Information architecture
-- Including all interactions
-- Wireframe and interface ideation
-- Hypothesis
+>**We believe that** the outcome screen 
+>**Will be useful for** processors
+>**As it will** be a place to explain the reimbursement amount and explain why it might be more or less than the training amount based on the revalidation budget remaining on the learner.
 
-## How we tested our ideas and what we found
+![A screenshot from the processing a claim prototype showing the search claim screen](reimbursement-amount.png "Approval outcome screen - reimbursement explaining")
 
-- Prototype URLs and version numbers must be provided as part of the UCD log
-- User testing feedback
-- URLs to Miro boards and prototypes where any iteration history is documented
+![A screenshot from the processing a claim prototype showing the search claim screen](processed-claim-approved.png "Processed claim - approved")
 
-## 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.
 
+>**We believe that** the outcome screen 
+>**Will be useful for** processors
+>**As it will** be a place to explain the reimbursement amount and explain why it might be more or less than the training amount based on the revalidation budget remaining on the learner.
 
+![A screenshot from the processing a claim prototype showing the search claim screen](unprocessed-claim-no.png "Unprocessed claim - no selection")
+
+![A screenshot from the processing a claim prototype showing the search claim screen](rejection-notes.png "Rejected outcome screen - rejection notes")
+
+![A screenshot from the processing a claim prototype showing the search claim screen](processed-claim-rejected.png "Rejected processed claim")
+
+## How we tested our ideas and what we found
 
+- Tested with users on ...

app/images/processing/cpd-processing/reimbursement-amount.png

@@ -17,20 +17,11 @@ aside:
 
 ## Why we did this work
 
-CPD has been removed as a option for funding. Been stripped out of the version 4 prototype and this version will act as the new MVP. Version 3 holds the design for the last iteration of CPD.
+CPD has been removed as a option for funding because.... Version 4 of the prototype has stripped out CPD and this version will act as the new MVP. Version 3 holds the design for the last iteration of CPD.
 
+## What we did
+On the processing side this has no effect on the overall design journey as CPD was added in the service onto the TU journey trying to minimise amount of design and tech work needed due to tight delivery deadlines.
 
-## What our ideas were
-
-
-## How we tested our ideas and what we found
-
-- Prototype URLs and version numbers must be provided as part of the UCD log
-- User testing feedback
-- URLs to Miro boards and prototypes where any iteration history is documented
-
-## 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.