Validating health plan consumers recommendations based on members usage analytics, claim data and consumer response for recommendations.
Consumer: Health Insurance Company
We were tasked with testing a system that could process large amount of health plan consumer data and provide accurate recommendations via an api which can be consumed by other systems once authenticated. The system would allow health plan companies to configure and setup recurring recommendations and notifications for their consumers providing them guidance on care, health assessments, promoting usage of digital products, online payments, etc. The engine is able to process large amounts of member records as it gets loaded into the system. Based on analytics data captured the corresponding recommendations would be generated. Any change in the member information would also trigger a reload for reprocessing the new info to update recommendations from the platform.
Lets look at a few examples for recommendations:
Scenario 1: A member is visiting a pharmacy for a prescription pickup and based on the member claims data the consumer engine knows that the member has not received a flu shot so immediately the engine will process that information and send a recommendation via a service bot to the member to take a flu shot.
Scenario 2: Payer has released a Member Portal mobile app and if a member has not yet downloaded and logged into the app the consumer engine will process that data and send a recommendation to the member about availability of the app and encourage them to use the app.
Scenario 3: A member has had a particular treatment which created a claim and that treatment requires follow up care and procedures to be done so a recommendation can be send to a CSR that might be having a conversation with the member so that they can remind them of the need for the additional care.
The recommendations listed above are generated by the platform via an api but consumed by different applications and rendered to the consumers on various interfaces. Now lets take a look the testing approach.
High Level Test Objective:
After a member data load and the member data is processed, validate the generated recommendations and notifications for a member are accurate and proper response data to these recommendations are captured for ongoing communications.
Consumer Id, Consumer Attributes, Consumer Analytics Data
- Member attributes, member data are available via a consumer api and other payer api which return consumer care data
- A recommendation API will return the recommendation that was generated for the consumer based on the data
So as soon as the member data is loaded the platform starts processing the data and generates the consumer recommendations for each member. So now we have to ensure that these generated recommendations are accurate for each member based on their analytics and care data. Now since the members data is available via a consumer API and the members care data is available via a payer API we will call those APIs to identify what recommendations should be generated for each member. We process the response from these apis to identify the recommendation for each consumer and store in environment variables. At this point we call the get recommendation api to compare the recommendations generated to ensure that there is a match. First we validate that recommendations count is accurate and then we compare the recommendation details to ensure that matches as well.
This allows validation of recommendations generated for large amounts of health plan consumers to be validated without any manual intervention, saving us time on testing, providing 95 percentage test coverage and increasing efficiency.
Documentation: Zephyr, JIRA, Confluence, Swagger