Prior Auth.
Test Case.
Test Case/Problem Statement:
You are the product manager on a team that is tasked with building a product that helps patients & providers eliminate any barriers that a patient would face in order to get there medication.
Based on market research we are creating an application that will give providers and patients the correct medication information based on the insurance at very first step, so there are no surprises when patients go pick up the medication.
FYI, there is a lot more that goes into the final product, I did not cover every little detail below.
Purpose of this is to get you to see how I approach a product at a high level, if you would like to learn more. I would love to connect and go over this in more detail.
Research
1- Nearly 70 percent of patients have made personal or financial sacrifices to afford prescribed medications according research done by CoverMyMeds Patient.
3- Providers report spending an average of two business days per week (14.9 hours) completing PA requests and 86% claim that the PA burden for their office is high or extremely high.
2- 77 percent patients feel it is important to discuss affordability.
4- Consulted multiple health care providers. In all my conversations there was one common issue they all raised. Providers have difficulty determining insurance based pricing of the medication and PA requirements. They write the prescription based on experience.
Assumption
- Market research has been completed.
- Custom application.
- Budget has been set.
- We have one year to go live with our POC/MVP.
- Early adopters have been set and will help us with making some key deaccessions.
- Data for insurance and medications already exist.
- There will be data migration of existing users from CoverMyMeds (Extension of CoverMyMeds).
- First iteration is only web application.
- Architectural conversation has started.
- At the minimum team consist of:
- 1 Architecture
- 1 Tech. Lead
- 2 Backend Developers
- 1 Frontend Developer
- 1 DevOps
- 1 UX Designer (Nice to have)
- 1 QA/Test Engineer (Nice to have)
- 1 Scrum Master (Nice to have)
- 1 BA (Nice to have)
Stakeholders
- External: Early Adopters, Patients, Providers (Anyone that can write prescriptions: Drs, NPs, PAs), Case Manager (Nurse that would help patients help connect with anything).
- Internal: CoverMyMeds Internal Support Team, Applications the information is being shared with, Marketing team, Development Team.
Key users for MVP
- Patients
- Providers
- Application Support Team
Application Name
How I think
My Approach
01. Research
We have figured out an opportunity in the market where we could make an impact.
Now we need to figure out the MVP and how to accomplished this. During this stage I work with the architecture, technical lead, & the financial team to figure out what our framework, architecture & tech we plan on using (Setting up Dev, UAT, & Production env.) and what the budget looks like. In addition, we start to put our team together at this point. I start to define what MVP actually looks like and put a high-level roadmap together (See below for detailed broken down road map). If their are any internal teams I start working with them and add necessary tickets/stories in their backlog to prepare for our work to continue.
I also start working with marketing team on how we plan attracting new clients and get more business for this product.
02. Development & Testing
Once the MVP, Architecture, & Technology has been defined we start developing and testing in a agile fashion. As we are developing this product I make sure to keep all our stakeholders in the loop through a presentation at the end of the sprint or various different meetings, so we can pivot if something is not to our stakeholders liking.
During this stage I try to stay least two sprint ahead for the requirements and keep the product backlog prepared for the refinement meetings, this includes wire framing and workflow so our stakeholders know exactly what the end product is going to be before development even begins.
03. Release
During this stage we are preparing to make the final push for the MVP, this could include fixing bugs and releasing last bit of the product to production before going live.
I continue working with the stakeholders in fixing any issues that come up and supporting them in anyway neccessary. While I helping business on board the product, I am also working with them to define the next stage of this product. In our case we start to look at our next feature which makes sense. All at the same time while we continue maintaining the existing product.
Lastly, I continue working with markating team to on board new clients or looking for more clients.
Workflow
And
Wireframe
There will be two main features:
-
Provider Portal
-
Ability to search for patients, drug price based on there profile. Listed from lowest to highest price.
-
If it requires a PA.
-
If the medication is in a REM program.
-
-
Patient Portal
- Ability to only enter insurance information.
- Drug details Read Only.
- Will tell what medications have been prescribed & how much it will cost.
- If any medications require a PA.
- If the medication is in a REM program.
MVP
Road Map
Q1- Prepare architecture and envs. at the same time start working with stakeholders on wire framing and workflow/business cases.
Q2- Deliver the patient portal which is connected to an existing product and gives the ability to add new patients.
Q3- Deliver the provider portal which is connected to to an existing product and connected to insurance/medication data warehouse. Also, allow a new provider to be added.
Q4- Deliver the POC/MVP iteration one.
End of each sprint there will be UAT testing and presentation to the stakeholders for feedback.
Future Plans
Post MVP
Once we have successfully onboarded customers, we will focus on the following next year:
- Enhancements requested by customers
- Nice to have which did not make it into MVP:
- Give patients ability to see where they can get the cheapest medication. This could include retail programs like CVS & Walgreens.
- Give access to Case Managers, where the patient can request for specific items.
- Give patients ability to see price differences between different brands.
- Give provider the ability to tell the differences between drugs in same class.
AGILE METHODOLOGY
- End of every sprint we will present to all stakeholders for feedback and show them progress.
- End of every sprint we will deploy to UAT and to production envs. to let users test.
- Prior to release there will be QA testing.
- In sprint 0 we will determine story size, sprint duration, and meeting timing with development team.
- PM/PO/BA will work with stakeholders to build our the product backlog.
- Success will be determined based on KPIs, which would be set for each quarter.
