Medicare

Setting Up Medicare

Medicare is a health insurance regulation from the Government of US, for three different kinds of people.

  • Persons > = 65 years of age
  • Persons < 65 years with a certain set of disabilities.
  • Persons with ESRD (a specific Kidney related disease)

There are four different types of Medicare coverage available:

Part A

a. It is a Hospital Insurance

b. It could be a Premium free coverage if the participant or his/her spouse has paid for the Medicare Taxes while working.

c. Else, there are other clauses that can make one eligible for premium free coverage.

Part B

a. It is a Medical insurance

b. The Participant must pay premium for this.

Part C

a. It is a Medical Advantage Insurance

b. This advantage plans pay the premium for the participant, however there might be other out of pocket costs involved.

Part D

a. This is the most important and widely opted Medicare.

b. This is the Prescription Drugs Coverage

c. The premium cost reduces drastically with this coverage.

d. The Participant must apply for the same and then based on the eligibility s/he is granted Medicare.


OK, now let’s see how to implement these. In US legislation, Medicare part D is the one that is implemented widely, reason being all others can be managed by the usual benefits set up, and they do not require extra set up unlike the Medicare Part D.

Carriers define a set of plans that are specific to the demands of Medicare Part D; so from a Functional consultant’s point of view it is nothing more than identifying the population and defining eligibility into those plans.

Identifying Population

The initial purpose is to identify the population that has applied for Part D and has been approved. The HR department in our firm might be getting some kind of feed from the Federal Department of health and human services or might be manually administering a list of Medicare Part D approved participants. Once the population is identified by the HR Department, it is now our task to update the system with that identifier.

We can choose any field in HRMS to identify that population. However it’s better to go for a SIT in people form. So for that we can create a new SIT that will store the Medicare Part D status along with effective dates. We can either use an Inbound Interface or add the values manually in based on the frequency and counts.

The SIT can also be designed to store the application details. Like someone has applied for the Medicare part D and has not been approved yet; and once approved the flag can then be changed. This is just a mere example. We can have as many details as we need in the SIT.

Setting up Eligibility

The Next task is to setting up eligibility for the Medicare part D Plans. This is simple. Go ahead and create a rule that will go and check the flag in our SIT. If the flag holds the appropriate value, it will return Y else N.

Attach this eligibility profile at the PLIP level as mandatory. PLIP is preferred because; the Plan might be a Medicare Plan in one Program and might not be a Medicare Plan in another. Otherwise we can just stick to the Plan Level. However we need to make sure we have the COBRA Coverage in mind, while doing it at the Plan level.

Defining Life Events

We will have to define our life events in order to grant or Revoke eligibility to the Medicare Plans. So there should be the following Life Events:

  • Turning 65: To ensure the Participant is given a chance to enrol in Medicare if he has already approved for the same.
  • Dependent Turning 65: Same as ’Turning 65’, but for Dependents.
  • Participant gains Medicare status: This event should fire when there is a change in the SIT flag that makes the Participant eligible to be in Medicare Part D.
  • Participant loses Medicare Status: This should fire, when the participant had an eligible Medicare part D status, and he lost it now.

Managing Enrollments

As we have defined different life events, it becomes easy; because now, the enrollment and default set up can be managed based on the life events.

· Make sure the participant gets enrollment Opportunity to the Medicare Plans if he gains Medicare status and vice versa.

· The Defaults can be designed to flip the Participant in and out of Medicare based on their statuses.

· The Enrollment opportunity might get blocked based on their Option tier. This is optional, but handy in case our firm does not want the participants to change their Option tiers when there is a change in Medicare status.

Split Enrollments

There will be situations where our firm would like to have only Medicare Participants in the Medicare Plans and the non Medicare Dependents to be excluded in another plan. This is a very popular requirement and almost all firms do it the same way. To deal with this, we should create a new Plan type for Medicare and add all the Medical Plans in there.

We should restrict eligibility in such a manner that, only Medicare participants / participants with Medicare dependent should be eligible to get in to the Medicare Plan type. Same should be the case with the Medical Plan type too. So the eligibility will be allowed only when there is an eligible person to be enrolled / covered under the plan type.

If we can, we should also restrict our eligibility to options, based on the eligible Dependents on file.

Remember, if we are using an Extract to report our enrolments to Carriers, the Split Enrolments can be nasty because the same person can be enrolled in Medical and Medicare both; however with enrolling himself in one and covering just the dependents in other. We should put in special care in order to configure the extract correctly, especially when it is an ANSI standard one.