Design Doc 002 Benefit Eligibility
status of design doc:
Authors: [Names of who Authored this Design Doc]
Reviewers: [Name of who reviewed this Design Doc and when]
High level summary describing what this design doc entails. Should inform the reader whether its useful for them or not... 3 paragraphs max
Related story: Eligibility Filters
Benefit Finder is intended to have many benefits with a need to prioritise by relevance for the end user. The concept is when a user selects a value for their situation using the drawer component, that the input can be filtered through a set of eligibility criteria related to benefits returning a relevance score. The relevance score will then be used to order the benefits by most likely eligible and grey out benefits deemed not eligible. Since we can't guarantee accurate results all benefits will still be displayed with their eligibility criteria showing why it did or did not pass.
- Benefits have a prioritisation based on eligibility criteria
- Eligibility criteria will be returned with passed/failed/unknown
- Eligibility criteria to remain at a high level
- Benefit content will not be included
- Implementation of all possible eligibility criteria (the tool should be a generalist for potential benefit matches)
Existing Code: api/benefits.js
The existing solution would ideally be separated out of Benefits Finder as it is likely to be complex and has potential to be reusable. The eligibility score is quite primitive as an enum (NOT_ELIGIBLE, POTENTIALLY_ELIGIBLE and ELIGIBLE) which makes it hard to highlight the most important benefits. Currently a user must qualify on all eligibility criteria for a benefit and having two paths with different criteria is not supported. Returning criteria belonging to a benefit and whether they have passed or failed is not supported.
Technical Architecture section... describe in technical details the new solution and how it will solve the outline problems. Be detailed here... diagrams are always an asset. A developer should be able to read this section and understand what they need to do while you not being there
How will this solution be tested, once in production how will things be supported and how alerts will be sent out when things go wrong
examples:
- Will this require an increase resources ( Devs, DevOps ect )
- Any security implications ?
- Does this need to be communicated in any way to effected stakeholders ?
- No business rules to follow
- How me match eligibility criteria to benefits is unclear
- How we determine eligibility criteria is unclear
Any open questions that can't be currently addressed