There is a distinct advantage to enrollment technologies that are built specifically for CMS's enrollment and dis-enrollment regulations for Medicare Advantage and Part D.  One such specification includes the Application Programming Interface (API) integration of the CMS MARX database for the validation of eligibility for Medicare Part A, B and D. This is a unique function that allows for real-time eligibility validation within the enrollment technology and avoids the less timely alternative of using batch processes for file submission to CMS. Additionally, special election periods are factored in to the technology logic and consists of low income subsidies from CMS, moving service areas, Chronic Condition Special Needs Plans (CSNPs), and members losing employer-sponsored group coverage.

Another CMS rule set defines whether an enrollment is complete or incomplete. Certain elements must be present such as: member's signature, responses to questions about other sources of coverage, ensuring the member's permanent address is within the service area. Incomplete enrollments are funneled through automated workflows to obtain missing information, for example, a request for information letter may be triggered. Once the membership is complete, changes in membership status or updates to information are initiated through the enrollment technology and flows to impacted systems.

Because enrollment is the member's first touchpoint with the health plan, enrollment technologies should also enable other downstream activities like claims processing, vendor integration, and member correspondence so each aspect of the member experience feels seamless and promotes a cohesive brand identity for the health plan.

Host: We’re joined today by Dave Laity, who will discuss Regulatory Concerns In Enrollment Technology. Welcome, Dave. I’m thrilled to have you on the show today.

Dave: Thanks! it’s great to be here.

Host: Dave, would you tell us a little about your background?  

Dave: Sure. I started my career in customer service for a large regional health plan. When Medicare Advantage and Part D became more prominent in the market in 2006, I moved into a role to help develop product offerings and standard enrollment solutions for those products. That included the implementation of the IkaSystems enrollment product, which is now Advantasure. Once the enrollment project was live in production, I left the health insurance company to work for IkaSystems to continue building out the Enrollment product.  At Advantasure, I’ve been part of several different teams that focused on production support, product enhancements, and new client implementations. In all of these roles, I worked closely with internal stakeholders, including compliance and regulatory teams, to help build solutions for health plans that meet their business needs and to ensure they’re fully compliant.  

Host: When you developed the Enrollment solution, were you the first in the marketplace with a product of this kind, or were you developing something with enhanced capabilities?  

Dave: The market already had its bigger players that existed from a commercial insurance perspective. And I think a lot of those software applications were able to make changes and modifications to their current systems to be compatible with Medicare Advantage. But what we were doing was building the enrollment product from scratch. We took the enrollment and disenrollment regulations that CMS published for Medicare Advantage and Part D (often referred to as MA and PDP), and really used that as the list of requirements. Those regulations and feedback from clients were used together to build an industry-leading product.  

Host: How was building the product using the regulations as a foundation advantageous or maybe even different from the other platforms that were making modifications to their already existing structure?  

Dave: Good question. At the time, it gave us more flexibility because we were building a product from scratch using the latest technologies. In other words, we weren’t constrained to existing systems with old technology or functionality that was built specifically for commercial business. Medicare Advantage is very unique and very specific. Over the years, we’ve been asked if we can enroll in commercial membership in the Medicare Advantage system, and the answer generally has been no because of the MA and PDP-specific rules that were built into the system. You know the old adage, “If you try to please everyone, you’ll please no one.” And this couldn’t be more true here.  

Host: Could you elaborate on what kinds of unique specifications are different for Medicare Advantage vs. commercial business systems?  

Dave: There are a lot of rules in place with Medicare Advantage enrollment. First, we have to validate the member’s Medicare Part A, B, and D eligibility before we can enroll them into a Medicare Advantage or Part D plan.  To do this, we had to integrate with the CMS Medicare Beneficiary database, which is the source of truth for Medicare eligibility information. Many plans and vendors use a batch process, or file submission to CMS, to capture Medicare eligibility. We were able to take advantage of their real-time eligibility look-up. That is handled through an API, or Application Programming Interface, which allows 2 different systems to communicate with each other.  Another rule is that there are only specific times or scenarios when members can enroll. Generally, the annual enrollment period, or AEP, is the time when any member can enroll in any plan they want. Outside of that, there are special election periods but, the member has to be eligible for these enrollment or election periods. A few examples include members who first become eligible for Medicare, members who are eligible for low-income subsidies from CMS, or members who move from one service area to another service. A couple more examples include members who have certain chronic conditions. They’re able to enroll in Chronic Condition Special Needs Plans, or CSNPs, year-round. Last but not least is a pretty common scenario for members who are losing employer group coverage. These members are eligible to enroll in individual MA or MAPD plans after losing their employer-sponsored coverage.  Not all of these scenarios typically apply to commercial plans, and this highlights why we build solutions that are specific to Medicare Advantage.  So, tying this back to technology, you have to build these validations into the enrollment solution.  The enrollment is where the member’s overall experience begins. A successful enrollment enables other downstream activities, like claims processing, vendor integration, and member correspondence.

Host: So, the API you were talking about allows for coordination with CMS’s system. Is that a primary differentiator in the market?

Dave: It is. First, the CMS MARX database stands for the Medicare Advantage Rx database. This is where all Medicare eligibility is housed at CMS. So, we were able to use that eligibility data and bake it into our core logic to do real-time Medicare Advantage eligibility determination during the enrollment process. CMS offers this real-time capability to all health plans and third-party vendors, but it’s a differentiator because not all vendors have been able to take advantage of it.

Host: There are so many Medicare regulatory and compliance rules. Can you give a broad overview of the different types of rules that exist and how that influences the logic built into the technology?  

Dave: Yeah, one of the things that comes to mind is CMS’s set of rules that defines an enrollment as complete or incomplete. Our system has a completeness check to make sure we’ve met the CMS criteria. Things like the member’s signature, responses to questions about having other coverage, and making sure that the member’s permanent address is within the plan service area are all things that we have to check before submitting the enrollment to CMS. If the member doesn’t have one or some of those elements captured, then the enrollment is marked as incomplete and goes into a different workflow to obtain the missing elements. So, the incomplete pathway includes outreach to the member with a Request for Information letter. You know, it might say, “Dear Member, we received your enrollment request, but you didn’t sign your application. Please contact customer service to resolve and provide that information.” Then, it’ll go back through the completeness check to make sure all the data elements and responses to questions have been received.

Host: So, once the member is enrolled, that’s a separate workflow? Can you give me an idea of how that works?

Dave: Once a member passes that completeness check and it’s been determined that the enrollment is complete, we submit it to CMS. CMS will respond with an acceptance or rejection. In most cases, about 99% of the time, the enrollment will be accepted because the system has gone through all of the required validations. After acceptance from CMS, it’s processed as a member in the system, and any changes that occur from here are considered membership maintenance. There are a number of different things a member may have to update after they’re enrolled. For example, if a member contacts customer service to notify them of an address change, the rep will make that change in the system. If the new address is in a state or county that’s outside the health plan’s service area, the system catches that and starts tracking the member in our Out of Area process. This process, like a few others, includes some member tracking and member correspondence components.

Another example is a PCP change. A member might contact customer service to find a new PCP. These changes are all initiated in our Enrollment system and flow downstream to other impacted systems, like our claims processing system.  

Host: And, I’d assume that all of this is automated.  

Dave: Yes, that’s all automated, including the letters that are triggered. There’s always some manual business processing and some oversight that goes into it to manage the workflows in the system like ensuring letters are going out on time and responses are being received and recorded when a member calls in. But overall, it is a fully automated process.  

Host: I suppose the system has to be updated and added to when CMS releases new regulations.  

Dave: Yes, that’s correct. CMS will have software releases and regulatory changes throughout the year. And then, leading up to AEP, there are usually changes to Chapter 2 of the Medicare Managed Care Manual and Chapter 3 of the Prescription Drug Manual, which are the main pieces of enrollment and disenrollment regulation that we reference for our Enrollment solution.  We have teams that do an initial review once those updates are received. And, then they work with the product teams to do a deeper impact analysis to see if any changes are needed in our systems or processes. If a change is needed, the teams collaborate on scope, requirements, and estimates, and the changes are included in one of our upcoming monthly software releases.

Host: Is there any coordination with the quality team to build enrollment processes and member workflows into the tech to ensure there’s a cohesive brand identity and positive member experience?

Dave: Yeah, definitely. Quality assurance, or QA, is part of everything we do.  All of our teams have dedicated QA resources that ensure everything we deliver to our clients is high quality and defect-free. Whether we’re building out enhancements or making regulatory updates, we’ve always got an eye toward quality and compliance.  

AEP is an important time of the year for our clients and for us. So, it’s really important for us to understand any changes that our clients are making for the upcoming plan year so we can accommodate them in our systems. It’s also really important for us to monitor and adapt to all regulatory changes that we receive.  

Host: Dave, thank you so much for explaining how regulatory issues impact tech development in the Medicare Advantage market.  

Dave: You bet. I enjoyed talking with you.  

Host: To all our listeners, if you enjoyed this episode, follow the Medicare Advantage For Health Plans podcast on Apple, Spotify, or your favorite podcast app. Be sure to share this episode with your colleagues on LinkedIn.