The Medicare Open Enrollment Period, sometimes called the Annual Election Period (AEP),Ìý runs each year from October 15 to December 7. During this time, Medicare health and drug plans can make changes in cost, coverage, and the providers and pharmacies in their networks. Also, during this period, beneficiaries with Medicare Parts A & B can switch to a Part C plan.

Before Medicare AEP begins, Heath plans prepare their systems, processes and people to ensure high-quality customer experience and meet Centers for Medicare & Medicaid Services (CMS) compliance. However, despite all the preparation and hard work, there are instances which impacts AEP significantly. Here are some of the examples:

• Incorrect processing of Enrollment Application received from Agents
• Improper deriving of the election codeÌý
• Incorrect Primary care physician on ID cards
• Clogging of system due to large volume of the Applications
• Integrated diverse systems not working as expected resulting in manual work
• First time scenarios – unanticipated scenarios slipping through end-to-end testing
• Non-flexible systems unable to accommodate last minute business demands
• Security and vulnerability assessments impacting operations
• Managing TRR related delays from CMSÌý
• Deploying regulatory changes without impacting downstream systems
• Retro processing scenarios during AEP and Post AEP

This is not an exhaustive list, the severity and impact depend on various criteria such as membership count, number of plans, size of the plan, service area, etc.

The question is, why such unaddressed scenarios pop up despite all the preparation and is there a way to get to know such issues before they even occur in production?

Let’s try to go through the answer in steps:

• Unexecuted AEP codeÌý
  • The unaddressed scenarios pop up because, the code which is run during AEP scenarios runs only during AEP. Since AEP logic and processes are tied to specific timeframe, the AEP processing related code is triggered when the AEP timelines hit. Till such period this portion of the code remain unexecuted. And on top of it, throughout the year, Health plan would have implemented change request, CMS regulatory changes and other system maintenances.
• Limitation on test coverage
  • Though, testing team is involved in conducting end-to-end testing and regression to ensure every aspect of the system is covered. But, how would a test engineer or business analyst test a scenario which is going to occur in future and on a specific period only? Predicting the behavior of system which depends on the specific data and time using sample test data is indeed challenging.

I am not talking about using Sci-fi time machines to address this problem. There are time simulation solutions which can be used to mimic AEP scenarios before AEP begins. This will empower testing team to address above mentioned issues.

For one of our M360 clients 91¿ì»îÁÖ has deployed time simulation module which enabled the client to perform end-to-end testing way before AEP. This resulted into a successful AEP.

• 91¿ì»îÁÖ created production-like isolated test environment for Health plans with an ability to change date/time and simulate AEP and any other date/time related scenarios. This environment was used for end-to-end testing and for simulating the production to assist Health plan’s preparation way ahead of AEP.

Most of the health plans would start the AEP preparation in terms of completing the change requests, closing on all defects and consolidating any pending activities in the month of July. Generally, July’s software release would be a major one. Post this release internal AEP testing activities and AEP preparation would kick-in.

Health plans that have witnessed resource constraints, application error backlogs, error prone manual activities and increased member grievances during AEP must start evaluating an end-to-end pre-enrollment and membership management system.

Sooner the better!

Reference

Ìý

Got a question about M360? Contact us and we’ll respond as soon as possible