TN 82 (12-11)

GN 00204.059 Internet Claim (iClaim) Medicare-only Application

A. Background for the iClaim Medicare-only application

Effective March 6, 2010, insured claimants (or their established third party) may complete an iClaim application to enroll in Medicare premium-free Hospital Insurance (Part A) only, or both Part A and Supplementary Medical Insurance (Part B) without having to file for monthly cash benefits. The Modernized Claims System (MCS) abbreviated retirement application (ABAP-R) is the basis for the Medicare-only iClaim and iClaim data propagates to the ABAP-R when MCS is established.

The time for when a completed MCS application becomes inactive is reduced from 30 business days after adjudication (i.e., from when the MCS screens are locked) to three days. This change reduces wait time for the automatic purging of an iClaim application from the Internet Database, so an applicant can establish a new online claim sooner. Thus, applicants may file online for RIB as early as three business days after we adjudicate the iClaim Medicare-only application. However, claimants remain eligible to accumulate delayed retirements credits from full retirement age (FRA) up to age 70, as long as they do not elect to receive RIB.

REMINDER: To receive monthly benefit payments, the claimant must file a separate RIB application (i.e., there is no automatic conversion from Medicare-only to RIB - before or after age 70).

For background and procedures about iClaim applications for RIB, aged spouse’s (AUXSPO) and disability insurance benefit (DIB) claims, see GN 00204.055.

Effective with the Spanish Internet Benefit Application (S-iClaim) release in October 2011, individuals may file online, in Spanish, for retirement, disability and Medicare benefits. This release is in keeping with the August 11, 2000 Executive Order 13166 “Improving Access to Services for Persons with Limited English Proficiency.” It also adds foreign address fields allowing people who reside outside of the United States to file an online application.

1. Medicare Coverage at age 65

With the exception of disabled and End Stage Renal Disease (ESRD) claimants, age 65 is the earliest date Medicare coverage can begin. Full retirement age (FRA) for Title II retirement insurance benefits (RIB) is already past age 65, and will eventually reach age 67. Incentives exist that encourage individuals to wait until at least FRA before applying for monthly cash benefits (e.g., no age reduction and no work deductions). However, if these claimants wait until after age 65 to file for Medicare, a surcharge may be added to their Part B premium for late enrollment.

2. Exception to surcharge for Medicare-only claimants filing after age 65

Claimants covered under a group health plan may be eligible for a Special Enrollment Period (SEP) that allows a Medicare effective date after age 65 without incurring a Part B premium surcharge per HI 00805.275.

B. Internal iClaim Medicare-only Application Functionality

Claimants and their established third parties (i.e., third parties who show a clear intent to complete an application on behalf of another via iClaim per GN 00204.013B and GN 00204.013C.1.) may access the iClaim application to establish a claim for Medicare-only from the same entry point on the socialsecurity.gov website used to apply for RIB. Users may choose to complete the application in English or Spanish.

For more detailed information about the entry point, see GN 00204.059I in this section.

After completing the first three initial information screens (i.e., Applicant Identification, Contact Information, and Birth and Citizenship Information screens) and selecting the “Next” button, iClaim performs a series of verification checks per GN 00204.059E in this section.

If the claimant’s entries pass all verification checks and the claimant is at least 64 years old, iClaim presents a conditional screen containing the question, “Do you wish to apply for Medicare Only, but not for monthly retirement cash benefits at this time?”

NOTE: We established the age 64 criteria because employers are referring their employees to our website with the expectation that these employees can file for Medicare-only (i.e., excluding cash benefits) before they are 64 years and 8 months old. We are attempting to protect these claimants from erroneously filing an online RIB application (for cash benefits), which they would then have to withdraw.

C. Process chart for Medicare-only question on conditional screen

Based on the applicant’s response, one of the actions in the following chart will occur:

If…

and claimant is…

Then…

the response to “Medicare-only” is No,

n/a

the RIB iClaim application is presented as explained in GN 00204.055.

the response to “Medicare-only” is Yes,

  • less than 64 years and 8 months old; or

  • not insured,

the following onscreen edit is generated to the applicant:

“You do not meet one or more of the qualifications to apply for Medicare Only benefits on the Internet. However, you may file for monthly cash retirement benefits online if you change your response to the Medicare Only question from Yes to No.”

If the response is changed, iClaim directs the applicant down the RIB path per GN 00204.055.

NOTE: If the Yes response is repeated, the following generic reject message is generated:

“You do not meet one or more qualifications to apply for Medicare Only benefits on the Internet. You should contact Social Security and tell us you received this message.

If you live within the U.S., our territories or commonwealths, you may call 1-800-772-1213 (TTY 1-800-325-0778). SSA representatives are available at this number Monday through Friday from 7 a.m. to 7 p.m. If you live outside the U.S., our territories or commonwealths, you may visit our Service Around the World page or contact your local U.S. embassy or Consulate.”

(For more detailed information related to insured status, see GN 00204.059G in this section.)

the response to “Medicare-only” is Yes,

at least 64 years and 8 months old but:

  • in current pay on own SSN; or

  • already receiving Medicare on own SSN,

the generic reject message quoted under the NOTE above is generated.

the response to “Medicare-only” is Yes,

  • at least 64 years and 8 months old,

  • insured;

  • not in current pay on own SSN; and

  • not already receiving Medicare on own SSN,

the following question is generated, “Are you already enrolled in Medicare under a Social Security Number other than your own?”

  • If the response is Yes, the generic reject message quoted under the NOTE above is generated.

  • If the response is No, the iClaim Medicare-only application is presented.

D. Language preference selection

Users may select a language preference, English or Spanish, on the Social Security website homepage or the iClaim “Welcome Page.” iClaim retains the preferred language throughout the session.

Informational links and links to external applications from within the iClaim path that are not available in the Spanish language have the phrase “available in English only” displayed in Spanish within the title.

iClaim displays the date format as:

  • Month/DD/YYYY on the English iClaim screens, and

  • DD/Month/YYYY on the Spanish iClaim screens. Dates in this format propagate to MCS in the current MCS format (MM/DD/YYYY).

iClaim does not allow the collection of non-English standard characters. If users enter non-English standard characters, they receive an alert that the characters are unacceptable and instructions to correct the entry.

Information collected in the Spanish iClaim, including free-format text, imports into MCS as it was entered. For claims requiring language translation, the servicing FO must follow procedures in GN 00301.330D.

E. iClaim verification checks

1. Identification criteria

iClaim accesses a pathing Utility called POA/POC/ICERS to verify that:

  • no death indicator is present;

  • no special indicator codes (e.g., fraud or domestic violence) exist;

  • the claimant’s name is not in the Individuals of Extraordinary National Prominence (IENP) file (also known as the Celebrity file); and

  • the claimant’s name and date of birth (DOB) match the last iteration on the Numident (NUMI) for this SSN. (For name criteria exception, see GN 00204.059E.4.

If the identification criteria are met, the Utility continues to scan other specific fields in the following databases:

  • NUMI;

  • Internet Database,

  • Integrated Client Database (ICDB, also known as T2Shared);

  • Modernized Claims System (MCS);

  • Master Beneficiary Record (MBR);

  • Supplemental Security Record (SSR); and

  • Master Earnings File (MEF).

2. iClaim or MCS exclusions

This scan identifies the following iClaim or MCS exclusions:

  • the claimant already has Medicare coverage on his or her own SSN (i.e., BIC A, T, or M on the MBR in LAF U);

  • the claimant is in current pay on his or her own SSN (i.e., BIC A or HA on the MBR in LAF C, D, S, or E);

  • three partial iClaim records already exist;

  • the claimant already completed an iClaim application, but the record still exists in the Internet Database (e.g., it was not purged after the MCS claim was adjudicated, or the protective filing closeout period expired); or

  • an MCS segment for any BIC on the number holder’s SSN is still open.

F. Online reject message

If the Utility detects any condition in the above verification routine is not satisfied, it blocks the iClaim application from being established (i.e., no protective filing is established and the Re-entry Number screen is not generated). Instead, it returns the appropriate online reject message to the applicant directing him or her to contact Social Security for assistance or to schedule an appointment via internet using the online iAppointment scheduler. For detailed policies and instructions about iAppointment (iAppt), see GN 00203.016.

1. Name and date of birth criteria exceptions

If the claimant’s First Name and Last Name do not exactly match existing records, the following online screen appears, “Check the Information You Entered,” which includes language advising the applicant to try again. However, as long as the first character of the First Name and the first three characters of the Last Name match, iClaim allows the applicant to continue.

If the DOB is not an exact match on the month, day, and year, the “Check the Information You Entered” screen also appears. If the system cannot match the claimant’s DOB after three attempts, the following reject screen appears, “We Cannot Process Your Request at This Time.” Although this screen includes language advising the applicant to contact us for assistance, attempts to start an iClaim application are possible on any subsequent business day up to three more times per day.

G. iClaim Address field

The following iClaim pages include a foreign address field: “Contact Information,” “Preparer’s Contact Information,” “Employer Details,” and “Dependants.”

iClaim can collect up to four lines for street address, city, state or region, and zip code or postal code (as well as country) for “Dependents” and “Employer details.” This information may be more than MCS can store in the existing MCS screens in both domestic and foreign address situations.

When iClaim collects more address information than MCS can accommodate, the system automatically puts the overflow data on the MCS development worksheet (DW03). This action does not affect claimant residence or mailing address fields in MCS.

Neither domestic nor foreign address fields accommodate military or diplomatic addresses (Army Post Office [APO], Fleet Post Office [FPO], or Diplomatic Post Office [DPO]). Applicants with APO, FPO, or DPO addresses must enter a standard domestic city, state, and zip code, and input the APO, FPO, or DPO address in “Remarks.”

NOTE: iClaim includes the “Service Around the World” link in all places where the National 800 Number Network (N8NN) link appears.

H. Insured status

The Utility also accesses the Informational/Certified Earnings Record System (ICERS) to query the Master Earnings File (MEF) for insured status purposes.

1. Insured status for Medicare-only claimants

Insured status for Medicare-only claimants must be met without using lag earnings because lag earnings questions are not generated in iClaim, following the ABAP-R path.

2. Insured status for Medicare Qualified Government Employment (MQGE)

Insured status for Medicare Qualified Government Employment (MQGE) claimants must be met without using Federal government employment earnings prior to January 1983. The Utility cannot identify these earnings on the MEF, and the Medicare-only iClaim application does not present the question, “Did you work for the Federal Government in January 1983?”

3. Insured status is not met

This iClaim application will not accept uninsured Medicare-only claims.

If insured status is not met using Social Security Quarters of Credit (SSQC) but the MEF has non-covered government earnings after 1982 , the Utility checks for MQGE insured status using Government Employment Quarters of Credit (GEQC), or a combination of SSQCs and GEQCs, for possible Medicare-only eligibility.

If insured status is not met using SSQCs, post-1982 GEQCs, or a combination of the two, iClaim treats these claims as uninsured and presents the online reject message advising the user to contact Social Security for assistance.

If you receive an inquiry from a Medicare-only claimant who does not appear to be insured, ask the claimant about Federal employment in January 1983. If the response is “Yes,” check for pre-1983 Federal earnings to include in the insured status determination per HI 00801.400 through HI 00801.435.

4. Insured status is met

If the claimant passes the verification checks, meets insured status, and the age alleged meets the filing criteria to enroll in Medicare, the user is allowed to continue the Medicare-only application, a protective filing date is established, and the Re-entry Number screen is generated.

The Utility checks to see whether the claimant’s age and citizenship status were previously established, applying the NUMI tolerances, when applicable, per GN 00302.030 and GN 00303.320, respectively.

If the Utility determines the information is not in our records, it displays the relevant questions. For more details on how iClaim and MCS react to citizenship data in our records, see GN 00204.059P in this section.

I. Re-entry Number screen

If the verification checks and remaining initial information screens are complete (e.g., Contact Information, Birth and Citizenship Information, and Medicare Election Information screens), iClaim:

  • establishes a protective filing date

  • Generates a screen containing the Re-entry Number and providing Medicare (Title XVIII) closeout language.

The applicant can use the Re-entry Number to go back to a partially completed application (see Restart Function in GN 00204.059I.3. in this section).

Supplemental Security Income (SSI) information and closeout language are not included on the Medicare-only version of the Re-entry Number screen because the Medicare-only application is based on the MCS abbreviated RIB application (ABAP-R), which is not an application for all benefits and does not include SSI questions.

If an applicant changes from Medicare-only to RIB, the appropriate protective filing closeout language for the current claim (i.e., RIB) is displayed after the change (i.e., closeout language for RIB and SSI is displayed). The same is true when changing from RIB to Medicare-only (i.e., only Medicare closeout language is displayed). However, the start date used to calculate the closeout period ending date is always the start date of the initial iClaim partial record.

The Utility continues checking to determine if the claimant’s age and citizenship status were previously established, applying the NUMI tolerances when applicable, per GN 00302.030 and GN 00303.320. Age and citizenship related questions are generated only if there is no proof in our records and the NUMI tolerances are not met.

For more information about how and when citizenship is derived, and to see what information is passed to MCS, see GN 00204.059P in this section.

Although the applicant can change from Medicare-only to RIB (or from RIB to Medicare-only) at any time within the online application, he or she must re-enter most of the data collected in the initial application into the current application, including any Medicare information previously entered.

As applicants progress through the iClaim application, the data derived from our internal records are also used in conjunction with responses from previously asked questions to determine what other information is necessary. If additional information is required, iClaim generates only the subsequent questions required to collect this information.

NOTE: Effective January 25, 2014, the Re-entry Number replaces the “Application Number”. iClaim applications started prior to this date will continue to have an “Application Number”.

J. Process for filing iClaim Medicare-only application

Applicants may access the iClaim Medicare-only application by entering our website at www.socialsecurity.gov and selecting, “Applying Online for Medicare Benefits” Or “Applying Online for Retirement.”

The iClaim “Welcome” page displays three radio buttons in the “To Start the Application Process” section. The user must choose one to start the application process. The choices are:

  • The first (top) radio button, “I am applying for myself.” Claimants filing and electronically signing the online application on their own behalf must select this button;

  • The second (middle) radio button, “I am helping someone who wants to apply for benefits and is with me.” Claimants filing and signing on their own behalf, but who are completing the application with the assistance of another person, must select this button; or

  • The third (bottom) radio button, “I am helping someone who is not with me, and therefore cannot sign the application at this time.” Third-party applicants who complete the online application on the claimant’s behalf, when the claimant cannot, or does not wish to sign the application electronically, must select this button. This is the only radio button that establishes a third-party application and generates the “Preparer’s Contact Information” screen.

The third (bottom) radio button is also the only one that generates the “Preparer’s Contact Information” screen.

1. Help screens

Applicants can obtain more detailed information or instructions by clicking on:

  • informational links on the iClaim Welcome page; or

  • “More Info” and “Things to Consider” buttons that appear after most questions in iClaim. These buttons link to help screens.

Links that are not available in Spanish have the phrase “available in English only” displayed within the title. iClaim includes the “Service Around the World” link in all places where the National 800 Number Network (N8NN) link exists.

2. Transmitting and storing iClaim application data on the Internet Database

After an applicant receives the “Re-entry Number” screen, completes each subsequent page in the claims path, and selects the “Next” button, the information on that page transmits to SSA and stores in a separate Internet Database as a partial claim until the applicant completes all screens. For detailed information on the Internet Database, see MSOM INTERNETT2 001.001 and MSOM INTERNETT2 001.003. When the field office (FO) user imports the iClaim into MCS, the information stored in the Internet Database propagates to the MCS screens.

To see information input to a partial or completed iClaim application, query the Internet Database per MSOM INTERNETT2 001.002.

3. Restart function

a. Re-entering the iClaim application

After receiving the Re-entry Number screen, claimants and third parties may leave the Internet application prior to completion by using the “Save & Exit” button located at the bottom-left corner of any screen. Any action that closes the iClaim after the “Re-entry Number” screen leaves a partially completed iClaim record in the Internet Database. This includes exiting iClaim by using the “Save & Exit” button, leaving the session due to a power outage, timing out (taking no action for 30 minutes), turning off the computer, going to another Internet site, or just X-ing out of the application If the user selects the “Save & Exit” button, iClaim presents the “Sign Off” screen that explains how to return to the application later and repeats the Re-entry Number and closeout language.

Applicants may re-enter partial records after following these steps:

  • wait at least five minutes;

  • go to www.socialsecurity.gov;

  • select, “Applying Online for Retirement Benefits” or “Applying Online for Medicare benefits”;

  • select the “Return to Saved Application” button on the right side of the Welcome page; and

  • enter the claimant’s SSN and Re-entry Number as indicated.

An unlimited number of re-entries using the correct SSN and application number are possible within the 6-month protective filing closeout period.

All data entered prior to leaving the application are saved in the Internet Database in the language in which it was entered and does not have to be re-entered. However, no information saves if the applicant exits before receiving the Re-entry Number screen.

Do not ask for an Re-entry Number to restart a partial iClaim record for an applicant, and do not volunteer to establish a new iClaim application.

If the applicant insists on providing you with the Re-entry Number, or having you establish an iClaim application for a partial record already started and asks you to complete it, remember that neither you, nor any other third party, is a proper applicant to sign the application (i.e., press the “Submit Now” button) on the claimant’s behalf. Treat these claims as any other in-office claims or teleclaims requiring the claimant’s signature or attestation.

Currently, the restart function is for claimants and established third parties only. iClaim assigns the Re-entry Number specifically to the applicant who initially provided the claimant’s personal identification information. Although we cannot control with whom the applicant shares this number, we provide language covered under the penalty of perjury statement that discourages sharing the Re-entry Number with anyone else to avoid unauthorized disclosure of the claimant’s personal identification information, as required under the Privacy Act.

Prior to the electronic submission of the completed application, applicants may re-enter a partially completed record using their Re-entry Number to review information previously entered. However, the applicant cannot re-enter the Internet application after selecting “Submit Now” on the “Send this application” screen.

Only the date the partial record is initially established is recorded in the Internet Database using this re-entry method (i.e., no separate dates for reentries using the Re-entry Number are captured).

We systematically purge partial records not completed within the closeout period from the Internet Database because protective filing no longer applies after this date.

For third party-initiated claims, only the third party is given the Re-entry Number and onscreen instructions to reenter the application and finish the claim. The process does not allow the claimant to complete the same iClaim application started by a third party. If a third party starts an iClaim application but does not finish it within two business days, a Conditional Notice (SSA-L1) is automatically sent to the claimant explaining the action started on his or her behalf, and identifying the responsible third party. The notice also explains that no action is necessary by the claimant if he or she wants the third party to complete the application.

If the claimant does not want the third party to continue and still wishes to file, he or she may either make an appointment for an in-office or teleclaim interview, or establish a new online application on his or her own behalf. In either case, the date the third party started the iClaim record protects the filing date if we receive the claimant’s signed application within the protective filing closeout period provided on the SSA-L1.

EXCEPTION: If the third party finishes the iClaim application before the claimant attempts to start a new online claim, the claimant is unable to establish a new iClaim application.

If the claimant does not wish to file, he or she should advise the third party to discontinue all further action on the iClaim application. Since we cannot process a claim without a signed application, there is no requirement for the claimant to contact Social Security in this situation.

b. Changes to the application

Before the claimant presses the “Submit Now” button, he or she can review previously input information at any time and return to the current screen using the “Previous” and “Next” buttons, or the tabs at the top of each screen. The applicant may also re-enter a partially completed application using the Re-entry Number to review information previously entered. Changes can be made at any point in the application.

To report changes after transmitting the completed iClaim application, the claimant must write out the changes and submit them to the office processing his or her claim, or call that office to report the new or changed information. iClaim displays the address and phone number of the servicing field office after submission of the online application.

c. Unable to locate Re-entry Number

If the applicant no longer has the Re-entry Number, he or she must start a new Internet application. A new Re-entry Number is assigned and the old one is deactivated (i.e., the earlier partial record is locked).

An applicant may establish up to three new partial iClaims records (i.e., the original plus two more), and a new 6-month protective filing closeout period begins each time this occurs (For information on multiple protective filings, see GN 00204.010A.6.). If a user attempts to start a fourth new partial, iClaim displays a message page that tells the user that SSA cannot process the request. It also directs the user to contact SSA for assistance.

The date the first partial application was established is the only information from the previous partial that propagates to MCS (as a potential protective filing or PROTFL ISSUE on the DW01). All other information previously input to iClaim must be re-entered.

If the iClaim application is incomplete and you have the claimant’s SSN, you may view the data entered on the partial record(s) by querying the Internet Database per MSOM INTERNETT2 001.002.

For information about purge criteria for iClaim partial records, see GN 00204.059L.1.a. in this section.

4. Submitting the application and proofs

a. Electronic application submission

After completing the screens and reading the penalty of perjury statement, claimants filing on their own behalf electronically sign and transmit their applications by pressing “Submit Now” at the bottom of the “Send This Application” screen. This constitutes a filed application. For alternative signature policy, see GN 00201.015D.

A copy of the claimant’s electronically signed Application Summary is stored in the Online Retrieval System (ORS) in the language in which the application is submitted in iClaim.

b. Paper application summary (third party-initiated)

After completing the screens and reading the penalty of perjury statement, established third parties select “Submit Now.” Upon transmission of the application, the following documents are generated, automatically mailed to the claimant, and stored in ORS:

  • the Comprehensive Notice (SSA-L2)

  • the unsigned Application Summary, and

  • any other pertinent attachments (e.g. List of Evidentiary Documents).

For third party-initiated claims submitted in Spanish, notices and any other pertinent attachments (e.g. List of Evidentiary Documents) generate and store in ORS in Spanish and English in case the claimant is not bilingual. The unsigned Application Summary included with the SSA-L2 is sent to the claimant and stores in ORS in the language the third party uses to submit the iClaim.

EXAMPLE: A third party iClaim submitted in Spanish will generate Spanish and English notices that are stored in ORS, but the Application Summary information in the SSA-L2 to the claimant is in Spanish only for both notices. The third party notices for Spanish iClaims generate in both languages in case the claimant is not bilingual.

The SSA-L2 states that the claimant must review, sign, and submit the application to SSA before any processing can begin.

Because third parties cannot restrict the scope of an application (see GN 00204.059J.2. in this section), the notice also provides Title II/ Title XVIII and Title XVI closeout language (to avoid any potential protective filing issues), and displays all appropriate closeout period ending dates. This notice includes a Confirmation Number that allows the claimant to check the status of his or her claim electronically after submitting the application.

c. iClaim-requested proofs

The iClaim POA/POC/ICERS Utility determines what proofs are necessary during the claims-taking process and checks to see if they already exist in our records. If not, a list of only those documents required generates online. If third parties are involved, this list is also included with the Application Summary mailed to the claimant. We advise claimants to mail or bring these proofs (originals when necessary) to an SSA office for verification.

The only proofs iClaim may request for Medicare-only claims are for proof of age and proof of citizenship (i.e., when the tolerances do not apply).

Contact the claimant, appointed representative per GN 03910.050, or if different, contact the established third party for these proofs when necessary.

5. Viewing sample iClaim application pages (ApPages)

SSA employees can access sample iClaim application pages at http://eis.ba.ssa.gov/appages/ .

  • Select the Internet Benefit Application (iClaim) link.
    Upon entering the iClaim site, a chart appears containing titles of various iClaim application pages.

  • Select the box containing the page title desired.
    These screens do not interact with each other. However, entering a response may generate other related questions on the same screen or other screens.

K. iClaim Medicare-only Application Validity and Scope

1. Valid iClaim application

A valid iClaim application is one that is:

  • completed, electronically signed, and submitted by the claimant; or

  • an iClaim-generated paper application initiated by an established third party, subsequently signed by the claimant, and received by SSA. Signature attestation can apply to a third party-initiated iClaim application. For policy on alternative signature methods, see GN 00201.015.

An iClaim Medicare-only application is only valid when a RIB application, used for Medicare-only purposes, is completed and electronically signed by the claimant. The application is based on the MCS abbreviated RIB application that is restricted to Medicare-only (ABAP-R). This application receives iClaim data when MCS is established.

Third parties may assist a claimant when completing the iClaim application, but the claimant must be present to select the “Submit Now” button, which completes the process. If an established third party initiates the iClaim application on the claimant’s behalf and selects the “Submit Now” button, either use signature attestation with the claimant or obtain the claimant’s wet signature on the paper application summary. For more details, see GN 00204.059N.2.b. in this section.

For valid application policy, see GN 00204.001B.

It is never appropriate for third parties to select the “Submit Now” button when one of the following radio buttons was selected on the iClaim “Welcome” page to start the application process:

  • the first (top) radio button, which indicates the claimant is filing and electronically signing the online application on his or her own behalf; or

  • the second (middle) radio button, which indicates the claimant is filing and signing the online application on his or her own behalf, but is completing the application with the assistance of another person.

With the selection of the first or second radio button, only claimants are authorized to select the “Submit Now” button because this action represents their acceptance of the penalty of perjury statement and is their legal electronic signature. It is never appropriate for third parties to select the “Submit Now” button when the first or second radio button is selected to start the application process because third parties are not proper applicants to sign on the claimant’s behalf. The third party may complete part or all of the application, whether the claimant is present or not, but the claimant must select the “Submit Now” button to establish a valid claim.

If you discover that a third party used the “Submit Now” button to electronically sign the iClaim application on the claimant’s behalf when the first or second radio button was selected on the iClaim Welcome page, it is not a valid application. Depending on the circumstances, report the third party to the Office of Inspector General/Office of Investigations Field Division (OIG/OIFD) and the Office of General Council/General Law (OGC/GL).

For more detailed information about reporting third parties, see

For additional information about identifying and reporting these incidents, see

  • GN 04105.005 Violations of the Social Security Act;

  • GN 04105.015B.2. Representation of Claimant or Beneficiary;

  • GN 04105.015C Procedure; and

  • GN 04111.010 Developing Violations.

NOTE: Whether reporting the third party’s action or not, obtain the claimant’s signed application before processing the claim. However, you may use the application signed by the third party as a protective filing if the criteria in GN 00204.010B.3. are met.

2. Scope of an iClaim Medicare-only application

No other benefit administered by SSA (e.g., Title II or Title XVI) extends from, or is protected by an iClaim Medicare-only application (i.e., no cash benefits are included). However, if an established third party completes the iClaim on behalf of a claimant, he or she is initially filing for all benefits due to the claimant.

When a third party answers “Yes” to the Medicare-only question, in effect, they are restricting the scope of the application. Because third parties cannot restrict the scope, the Comprehensive Notice (SSA-L2) sent to the claimant does include SSI closeout language to avoid any potential open protective filing issues.

For prescribed application policy, see GN 00204.002.

L. MCS Medicare-only application processing

A completed Medicare-only iClaim application updates overnight to the WMIT2 Internet Application list. To request this listing, see MSOM MCSWMI 001.020. Medicare-only iClaim applications are a separate section of this listing under a Medicare-only heading.

When the iClaim Medicare-only application is complete and MCS is established, the information stored in the Internet Database propagates to the appropriate MCS screens as they appear in the path.

If the claimant’s response on the iClaim screens conflicts with data in the Integrated Client Database (ICDB), also known as T2Shared, the ICDB information propagates to MCS instead of the iClaim information. The data input to iClaim (if any) displays in the Internet Database (see MSOM INTERNETT2 001.002), and, depending on the specific field, also on the Record of Change (CHNG) screen. For more information about resolving these discrepancies, see GN 00204.059N.3 in this section.

IMPORTANT: With the October 2011 release, the residence address in iClaim will overkey the residence address on the MCS Client Address (CLAD) screen. If ICDB lists a different address from the one in iClaim, both addresses will display on the Internet Database (see MSOM INTERNETT2 001.001) and on the Record of Change (CHNG) screen.

For more detailed information on the Internet Database, see MSOM INTERNETT2 001.001 and MSOM INTERNETT2 001.003.

For more information about ICDB and its affect on Group Health Plan (GHP) and Medicaid (T19) screens, see MSOM ICD 003.003 and MSOM ICD 003.004.

1. Initial Enrollment Period (IEP)

a. Claimant in first five months of IEP

If the claimant is within the first five months of his or her IEP in the month of filing, “1” is propagated to the field, “IF ENROLLMENT IS IN IEP, ENTER 1 OTHERWISE ENTER 2 FOR GEP OR 3 FOR SEP ELECTION”, on the HIGP screen when it appears in the MCS path.

b. Claimant in last two months of IEP

If the claimant is filing in the sixth or seventh month of the IEP, iClaim does not pass any data to the above HIGP field. If a Special Enrollment Period (SEP) is possible after the IEP ends, contact the employer to verify group health plan (GHP) coverage and determine if the SEP would establish Medicare Part B earlier than filing in the last two months of the IEP. If so, contact the claimant and explain this option. If the claimant then refuses to enroll in Part B during the IEP, enter “2” in the TYPE OF ACTION field on the HIHI screen and document this decision. If appropriate, also establish a tickle or diary for the earliest possible Part B filing date in the SEP.

c. Claimant outside IEP

If the claimant is not within the IEP, iClaim does not pass any data to the HIGP field, “IF ENROLLMENT IS IN IEP, ENTER 1 OTHERWISE ENTER 2 FOR GEP OR 3 FOR SEP ELECTION.” The only other Part B enrollment options are an SEP, and a General Enrollment Period (GEP). The GEP is dependent upon a January through March filing date. The SEP is dependent on the claimant’s employment status and coverage under an employer-provided GHP. If the claimant is outside the IEP and a GHP is involved, he or she may be eligible to enroll in either a GEP or SEP. In any event, contact with the claimant is necessary.

NOTE: If the claimant is not in an IEP, not entitled to an SEP, and outside the filing period for the GEP of the current year (January – March), the earliest Part B coverage possible is July of the following year. This action may include a premium surcharge. If the claimant agrees to elect Part B coverage, complete the HIHI screen path. This automatically establishes Part A with up to six months retroactivity, and deemed Part B filing in the next GEP. For more information about claimants who are not in an IEP or GEP in the month of filing, see HI 00805.040A.2.

2. Third parties and Workload Management Information (WMI)

An iClaim application completed by an established third party on the claimant’s behalf updates overnight to the WMIT2 Internet Application list under Third Party-Unsigned (Category 3). To request this listing, see MSOM MCSWMI 001.020.

Once the claim appears on the listing, establish MCS within five business days and make one attempt to contact the claimant by phone.

When MCS is established, the SSN clears from the Third Party-Unsigned list (usually by the next business day).

3. MQGE claims

If iClaim uses Government Employment Quarters of Credit (GEQC) in the insured status determination, a Medicare Qualified Government Employment (MQGE) alert is generated to the GMES screen, and “MQGE” is displayed in the Internet Database query (see MSOM INTERNETT2 001.002).

If the claimant meets MQGE insured status, iClaim generates the remark, “MQGE INSURED” to the DW03 Remarks screen in the MCS ABAP-R.

Enter a “Y” in the “PROCESS AS MQGE (Y/N)” field of the MREQ screen.

4. iClaim documents stored in Online Retrieval System (ORS)

A copy of the claimant’s electronically signed Application Summary is stored in Online Retrieval System (ORS).

For third party-initiated claims, a copy of the unsigned Application Summary sent to the claimant is also stored in ORS, along with the Comprehensive notice (SSA-L2), and any other pertinent attachments (e.g., List of Evidentiary Documents).

For third party-initiated claims submitted in Spanish, notices and other pertinent attachments (e.g., List of Evidentiary Documents) generate and store in ORS in Spanish and English in case the claimant is not bilingual. However, the unsigned Application Summary generates and stores in the language the third party uses to submit the iClaim. Currently, automated translation of Spanish iClaim data into English for the Application Summary is beyond the scope of iClaim.

EXAMPLE: A third party iClaim submitted in Spanish generates Spanish and English notices, but the Application Summary generates in Spanish only for both notices.

5. DW01 – General ISSUEs

At least two ISSUEs generate to the MCS DW01 screen for iClaim Medicare-only applications. If an established third party is involved, at least one additional ISSUE generates.

Enter the date we received the claimant-signed application in the Receipt (REC) date field of the ABAP-R and ATTEST ISSUEs.

If a third party is involved, also enter this date in the REC date field of the iCLM3P ISSUE. The correct REC date for these ISSUEs is :

6. the date the iClaim application was electronically signed and transmitted to SSA by the claimant as displayed in the Internet Database per MSOM INTERNETT2 001.002 (i.e., COMPLETE: INTERNET COMPLETED DATE: 040310);

7. the date of signature attestation (for third party-initiated claims); or

8. the date you receive the signed paper application (also for third party-initiated claims).

The REC date is not the date MCS is established and, unless the REC date was completed on the same day it was initiated, it is not the Start date of the first iClaim partial.

For application receipt date policy, see GN 00204.007B.3. and GN 00204.007B.4.

6. Earliest wait time before a claimant can file for cash benefits

An applicant may file an online application for cash benefits (e.g., RIB) per GN 00204.055 as early as three business days after the online Medicare-only claim is adjudicated. This is the earliest a prior MCS segment can become inactive.

M. iClaim protective filing date policy

1. Determine the earliest protective filing date

Review all SSA records and DW01 ISSUEs to determine the earliest protective filing date to use as the application filing date. Some, but not all possible sources are:

  • the Internet Database for earlier iClaim partial records (see MSOM INTERNETT2 001.002);

  • open leads in the 800 # Appointment System; and

  • in-office records.

There is no “good cause” provision for extending the ending date of a protective filing closeout period. For more information on good cause, see GN 00204.012B.

a. Internet database

A partially completed iClaim Medicare-only application establishes a potential protective filing as of the date the applicant first completed the initial information screens (i.e., Applicant Identification, Contact Information, Birth and Citizenship Information, and Medicare Election Information screens) and selected the ”Next” button. The next page that appears in the path is the Re-entry Number screen, which provides the appropriate protective filing closeout language and the Re-entry Number.

There can be up to two partial records displayed in the Internet Database in addition to the one used to complete the application (see Restart Function in GN 00204.059I.3. in this section). The start date from the earliest partial record may be used as a protective filing date as long as we receive the signed application within the protective filing closeout period. Review all records in the Internet Database to determine the earliest material iClaim record.

IMPORTANT: We purge partial records from the Internet Database after the 6-month closeout period expires. However, multiple partials on the same SSN are internally connected. None of the related partials are purged until after the closeout period for the latest partial record expires, or the application is completed and adjudicated (i.e., the MCS screens are locked for at least three business days), whichever comes first. At that time, we purge all the partial records for that SSN.

For instructions on querying the Internet Database, see MSOM INTERNETT2 001.001.

NOTE: You may also use a partially completed iClaim application established under an incorrect SSN as the protective filing date of a subsequently filed application if:

  • the incorrect SSN is known;

  • a new application is filed under the claimant's correct SSN; and

  • the protective filing closeout period established by the partial on the incorrect SSN is not expired.

b. 800 Number (800 #) appointment system

The appointment screens in the 800 # system may establish an earlier protective filing date than the earliest iClaim record if the claimant called SSA about filing an application but decided instead to file online. Review the 800 # system for possible earlier protective filing dates and verify whether they are relevant (e.g., still within the closeout period).

For Medicare-only claims, the 800 # Utility discussed in GN 00204.055K.2 does not automatically use potential protective filing dates it may identify in the 800 # system. This is different from its function in an iClaim retirement application. However, if any Title II or Title XVI lead exists in the 800 # system, it passes to the LPF2 screen and generates the question, “IS THIS THE LEAD YOU WANT?” If your response is “Yes,” a protective filing ISSUE (PROTFL) propagates to the MCS DW01 screen and the date of this lead passes to the File Date Determination Screen (FDDS).

Title XVIII leads in the 800 # system do not propagate to a Medicare-only claim because they only apply to Medicare Part D (low-income subsidy) applications.

For additional information about the 800 # appointment screens, see:

  • MSOM APPTS 001.004 Field Office Menu for SSS (City); and

  • MSOM MCS 009.014 File Date Determination Screen.

c. Time zones

Since there is no way for iClaim to determine the time zone in which an applicant is physically located when the initial information screens transmit, Eastern Time (ET) is used. If the applicant is in another time zone and transmits the information after midnight ET but before midnight in his or her time zone, iClaim establishes the protective filing one day later than it should. Be alert to situations where this may have occurred on the last day of the month and revise the protective filing date as needed.

2. iClaim partial record filing date

The date of the earliest partially completed iClaim record propagates to the Request (REQ) field of the PROTFL ISSUE on the MCS DW01, and a one-time adjudicative alert generates to the General Message (GMES) screen when MCS is established (i.e., “PROTFL BASED ON PARTIAL APP – VERIFY”).

GMES alerts cannot be viewed again after they have been generated. If you are establishing MCS and you will not be the adjudicator, print these one-time alerts and make them available to the adjudicator.

Verify that the protective filing date is valid by querying the Internet Menu (IMNU) for earlier start dates from a previous iClaim partial per MSOM INTERNETT2 001.003. If an earlier start dates exists, verify that the partial record pertains to the claimant and falls within the protective filing closeout period before using it.

REMINDER: We systematically purge partial iClaim records after the closeout period expires, since protective filing no longer applies after this date.

3. Examples of partially completed iClaims

EXAMPLE 1

The claimant starts an iClaim application on March 13, 2010, but does not finish it. He uses his Re-entry Number to update and complete the application on April 3.

MCS propagates the information from the application started on March 13, but finished on April 3. The REQ date in the PROTFL ISSUE on the DW01 shows March 13, 2010.

When the MCS application is established, the information from the completed application started on March 13, 2010, and finished on April 3, propagates to MCS.

EXAMPLE 2

The claimant starts an iClaim application on March 13, 2010, but does not finish it. She loses the Re-entry Number and, therefore, has to start a new application on April 3. She also completes the application on April 3.

The information from the April 3 completed application propagates to MCS. The REQ date in the PROTFL ISSUE shows March 13, 2010.

The Start date of the partial record and the completed application both display on IMNU for query.

A one-time alert generates to GMES because a potential protective filing date was based on an earlier partial application.

N. Routing of iClaims

iClaim uses the residence address to route claims to the jurisdictional FO, WSU, or OIO.

1. Spanish iClaims

These are WSU exclusions. iClaim routes Spanish claims to the jurisdictional FO.

2. Domestic residence address

iClaim automatically routes Medicare-only claims with all of the following characteristics to the jurisdictional FO or WSU based on terminal digits:

  • claim is submitted in English;

  • claimant provides a domestic residence address; and

  • claimant’s age and citizenship have been proven.

iClaim determines the jurisdiction by using the Detailed Office/Organization Resource System (DOORS) and the zip code of the claimant’s residence address. Terminal digit assignments between the FOs and WSUs are monitored and adjusted based on the capacity of the WSU to handle iClaims.

iClaim automatically routes the following claims with domestic addresses to the jurisdictional FO:

  • applications where the claimant’s age or citizenship status has not been proven;

  • all Spanish claims.

3. Foreign residence address, except Canadian

iClaim will route all foreign residence address claims, except Canadian, to OIO.

4. Canadian residence address

iClaim will route all claims with Canadian residence addresses to servicing field offices within the United States. An iClaim with no postal code routes to OIO.

5. APO, FPO, or DPO address

FOs and WSUs will route claims with APO, FPO, or DPO addresses to OIO. Neither domestic nor foreign address fields in iClaim can accommodate APO, FPO, or DPO addresses. Applicants must enter claims using a standard domestic city, state, and zip code. The military and diplomatic address may be input in “Remarks”.

O. Workload Support Unit (WSU), Field Office (FO), and Office of International Operations (OIO) responsibilities

1. Verifying application criteria and documenting proofs

To ensure the iClaim application meets all requirements for a valid application follow the procedures outlined in GN 00204.001.

When proofs are sent to an office other than the one where iClaim routed the application, follow the procedures for the required FO coordination in GN 01070.781.

For the click-and-sign signature method for Internet filers and for the disposition of evidence and proofs, follow the procedures in GN 00201.015G.

2. Processing instructions for adjudicators

Obtain queries for at least the Internet Database, ICDB, Appointment Calendar, MBR, and SSR before establishing MCS to see what other information may be needed, whether the iClaim application is valid, to avoid an MCS claim deletion, etc.

a. Claimant-signed applications

Upon receipt of the electronically signed application, take the following actions (not necessarily in the order presented):

  • Establish the appropriate claim in MCS;

  • Review any adjudicative alerts generated to the General Message (GMES), Record of Change (CHNG), and Alerts Display (IA01) screens;

  • Ensure the REC field of the ABAP-R and ATTEST ISSUEs on the DW01 screen contains the date the application was received per GN 00204.007B.4.;

  • Check for earlier protective filing dates (e.g., query the Internet Database, 800 # system, or in-office records);

  • Initiate development for outstanding evidence and proofs;

  • If the claimant makes changes or updates that require an amended application, explain to the claimant that he or she can sign the application electronically. Follow GN 00201.015F.3.c. and read the attestation script to the claimant affirming under penalty of perjury that the information provided is correct, and agreeing to sign the application for benefits. Document MCS, as instructed in GN 00201.015F.4;

  • Adjudicate and effectuate the application per GN 01010.001, paying particular attention to the Adjudicative Responsibilities shown in GN 01010.007. None of these responsibilities are diminished because of the enhanced Internet claims-taking process (i.e., all discrepancies must be resolved prior to adjudication);

  • Annotate MCS (e.g., RPOC or RMKS), the Non-Disability Repository for Evidentiary Documents (NDRED), the Shared Process Evidence (EVID) screen (per GN 00301.286), etc., if required to document any proofs received; and

  • Return proofs and the amended application, if applicable, to the claimant.

b. Third party-initiated claims

The servicing FO has access to the third party-initiated iClaim application immediately after the third party selects on the “Submit Now” button. However, it does not appear on the Internet WMIT2 listing until the next day as an unsigned third party claim (Category 3). To request this listing, see MSOM MCSWMI 001.020.

CAUTION: If you discover that a third party used either of the top two radio buttons to establish and sign the claim electronically (i.e., selected the “Submit Now” button), treat the application as a protective filing but obtain a signed application from the claimant before processing. Also consider reporting these incidents to OIG and OGC (see IMPORTANT note in GN 00204.059J.1. in this section).

Third parties, including those who claim to be proper applicants, should not electronically sign iClaim applications on behalf of SSA claimants from the first (top) or second (middle) radio buttons of the iClaim “Welcome” page. If they are assisting claimants who are electronically signing the application on their own behalf, third parties may use the second (middle) radio button to complete or help claimants complete the application screens, but the claimants must electronically sign the applications on their own behalf.

If third parties are completing the applications on the claimants’ behalf, they should use the third (bottom) radio button, which generates application summaries that the claimants must sign and return.

Only SSA can make proper applicant determinations after evaluating the related evidence (i.e., third parties, including attorneys or other legal representatives, cannot designate themselves to be proper applicants, no matter what argument to the contrary they may provide). No one but the claimant should use the radio button designed for claimants filing for themselves (i.e., the first or top radio button). If third parties do not select the third (bottom) button, the “Preparer’s Contact Information” screen is not generated, so we would not know the third party’s name, address, relationship to the claimant, phone number, etc. In fact, third party involvement would not be obvious.

When the iClaim SSN appears on the WMIT2 listing, establish MCS within five business days and make one attempt to contact the claimant by phone. Once MCS is established, the SSN clears from the Third Party-Unsigned list (usually by the next business day).

NOTE: If the SSN is available for a finished iClaim application, any office may query the Internet Database and import it into MCS. When an office other than the one determined by iClaim establishes MCS, Workload Management Information (WMI) jurisdiction automatically transfers to the office that establishes MCS.

Based on the result of your attempt to contact the claimant, follow the directions below.

If contact is successful:

  • Review the application stored in the Online Retrieval System (ORS) with the claimant, confirm his or her intent to file, and read the attestation script affirming under penalty of perjury that the information provided is correct, and agreeing to sign the application for benefits per GN 00201.015F.3;

  • Ensure that any changes or additions to the application indicated by the claimant update to MCS and store in ORS before entering any other adjudicative updates in the MCS path. This will secure the integrity of the information provided by the claimant. Upon completion of all the claimant-related updates in MCS, immediately go to the Print and Store (PRST) screen and use the STORE function to update ORS. Then return to the first MCS screen in the path and continue adjudicative coding. Subsequent changes are recorded and identified by the adjudicator’s personal identification number (PIN) on the Record of Change (CHNG) screen;

  • Advise the claimant that a notice with a copy of the Application Summary will be automatically mailed, but that it is not necessary to sign and return it to us because he or she just provided us with the appropriate information and signature;

  • Enter the receipt date in the REC field of the iCLM3P ISSUE on DW01 per GN 00204.007B.3.;

  • Also enter the receipt date in the REC field of the ABAP-R and ATTEST ISSUEs per GN 00204.007B.5. and

  • Print and store the attestation cover letter (if evidence is requested), and mail the receipt and summary to the claimant for his or her review and retention.

NOTE: If the attempt is successful but the claimant insists on signing a paper application, advise the claimant to review, update (if necessary), sign, and submit the Application Summary already on its way. Provide the claimant with the closeout period ending date on the vendor notice stored in the ORS. Document the conversation, including the closeout period ending date, on an RPOC screen and enter a tickle date (i.e., on the ABAP-R, ATTEST, and iCLM3P ISSUEs) for the end of the 6-month closeout period on the vendor notice.

If contact is not successful:

  • Send the iClaim Third Party Follow-Up Letter from the “Initial Claims” folder of the Document Processing System (DPS) to the claimant, since closeout language was already provided on the notice sent by the vendor;

  • Document DW01 with a tickle date (i.e., on the ABAP-R, ATTEST, and iCLM3P ISSUEs) for the end of the 6-month protective filing closeout period provided on the vendor notice stored in ORS; and

  • Delete the MCS record if we do not receive the signed application within the closeout period.

If the claimant calls to allege non-receipt of the Application Summary as a result of the DPS notice:

  • Review the address and the application stored in ORS with the claimant, confirm his or her intent to file, and read the attestation script affirming under penalty of perjury that the information provided is correct, and agreeing to sign the application for benefits per GN 00201.015F.3;

  • Ensure that any changes or additions to the application indicated by the claimant update to MCS and store in ORS before entering any other adjudicative updates in the MCS application path. This will secure the integrity of the information provided by the claimant. Upon completion of all the claimant-related updates in MCS, immediately go the Print and Store (PRST) screen and use the STORE function to update ORS. Then return to the first MCS screen in the path and continue adjudicative coding. Subsequent changes are recorded and identified by the adjudicator’s PIN on the CHNG screen;

  • Enter the receipt date in the REC field of the iCLM3P ISSUE on DW01 per GN 00204.007B.3.;

  • Also enter the receipt date in the REC field of the ABAP-R and ATTEST ISSUEs per GN 00204.007B.5.; and

  • Print and store the attestation documents and mail them to the claimant for his or her review or retention along with a receipt.

NOTE: If the claimant insists on signing a paper application, document the conversation on an RPOC screen, print and store the MCS Application Summary, and mail it to the claimant via SSA-L566. Enter a tickle date (i.e., on the ABAP-R, ATTEST, and iCLM3P ISSUEs) for the later of the 6-month period indicated on the vendor notice stored in ORS, or 6 months after the date on the SSA-L566.

Upon receipt of a signed paper application (i.e., initiated by a third party):

  • Ensure that any manually annotated changes or additions to the paper application made by the claimant update to MCS and store in ORS before entering any other adjudicative updates in the MCS application path. This will secure the integrity of the information provided by the claimant. Upon completion of all the claimant-related updates on the paper application to MCS, immediately go the Print and Store (PRST) screen and use the STORE function to update ORS. Then return changed application to the claimant per GN 00201.015 and continue adjudicative coding from the first MCS screen in the path. Subsequent changes are recorded and identified by the adjudicator’s PIN on the CHNG screen;

  • Enter the receipt date in the REC field of the iCLM3P ISSUE on DW01 per GN 00204.007B.3.;

  • Also enter the receipt date in the REC field of the ABAP-R and ATTEST ISSUEs per GN 00201.015H.2.; and

  • Mail a receipt and, if applicable, present the amended application to the claimant.

It is not necessary to mail a receipt to a claimant filing on his or her own behalf because the claimant has the option to print the online Receipt page of the iClaim application. This page is the claimant's receipt.

Do not contact the claimant unless you cannot otherwise resolve an alert or issue raised during the review of the iClaim application, or a document of proof is still outstanding. If development is necessary, it must be with the claimant or appointed representative (per GN 03910.050), but not the established (or any other) third party.

3. Resolving data discrepancies between ICDB and iClaim

If the applicant's responses on the iClaim screens conflict with data already in SSA's Integrated Client Database (ICDB, also known as T2Shared), the ICDB information propagates to the appropriate MCS screen instead of the iClaim data. Depending on the specific field in question, an alert may also appear on the Application (APPL) screen. The data input to iClaim (if any) displays in the Internet Database (see MSOM INTERNETT2 001.002) and, depending on the specific field in question, on the Record of Change (CHNG) screen.

For Group Health Plan (GHP) and Medicaid (T19) screen discrepancies with ICDB, MCS ISSUEs “GHPDCR” and “T19DCR” (respectively) generate to the DW01 screen and must be resolved prior to adjudication. Currently, the GHP and T19 data entered by the iClaim applicant only display in the Internet Database, not on CHNG.

Ensure that the correct information posts to MCS. Contact the claimant if the discrepancies cannot be resolved with readily available information.

For more information about ICDB and the CHNG screen, see MSOM ICD 001.001 and MSOM MCS 005.005, respectively. For more specific information about how ICDB relates to GHP and Medicaid entries in MCS, see MSOM ICD 003.003 and MSOM ICD 003.004.

You must resolve all data discrepancies prior to adjudication (e.g., undisclosed name change). Also, verify GHP information with the employer prior to adjudication if the claimant is enrolling in an SEP, regardless of whether there are discrepancies between iClaim and ICDB.

The following table indicates which database MCS fields in an iClaim Medicare only application uses for the data propagation:

Data Element

Propagated from ICDB

Propagated from iClaim

APPL

  

Name

X

 

Sex

X

 

Birthdate

X

 

Proof of Age

 

X

CLAD

  

Residence address

(For more information about this discrepancy, see GN 00204.059M.2. in this section.)

 

X

CLCZ

  

Citizenship start date

X

 

Citizenship type

X

 

CADR

  

Mailing address

 

X

Telephone number

 

X

ADDR

  

Mailing address

 

X

Telephone number

 

X

HIGP

  

Covered under Group Health Plan (GHP)

X

 

GHP coverage from own employment

X

 

GHP coverage from other’s employment

X

 

Employment start date

X

 

Employment end date (or “Not Ended” - N/E)

X

 

Health insurance start date

X

 

Health insurance end date (or N/E)

X

 

HI19

  

Medicaid start date

X

 

Medicaid end date (or N/E)

X

 

Medicaid number (or UNKNOWN)

X

 

Medicaid state

X

 

4. Obtain additional information

To adjudicate the application, you may need additional information to complete the MCS screens (e.g., verify employer-based GHP dates for a SEP). If so, contact the employer, claimant, or appointed representative (per GN 03910.050), but not the established third party, to obtain the additional information.

5. Additional review responsibilities

The adjudicator's review of the iClaim application data should not involve claimant contact unless the discrepancy or issue cannot be resolved any other way. However, all discrepancies must be resolved per GN 01010.007. This review includes (but is not limited to) the following:

  • Non-citizen status of the number holder;

  • Conflicting ICDB information;

  • Earlier protective filing dates;

  • Possible Medicare Part B, Group Health Plan, or Medicaid eligibility; or

  • Resolution of earnings record discrepancies.

P. Reviewing earnings history policy

Obtain an EARQ for all Medicare-only claims, but only resolve discrepancies identified for years after 1977 that affect Medicare entitlement as required in RS 01404.003B and RS 01404.110.

To obtain an EARQ, see MSOM QUERIES 003.023.

Unlike iClaim applications for RIB and DIB, the iClaim Medicare-only application does not refer to the Social Security Statement, and does not ask about the accuracy of the claimant’s earnings record.

Q. Process for resolving data discrepancies between iClaim and the Modernized Claims System (MCS)

Most questions not asked in iClaim require no additional action. We made modifications to certain MCS screens that bypass adjudicative exceptions or edits. An internal mechanism automatically converts and propagates iClaim application responses to MCS fields in an acceptable format. For Medicare-only claims, there is only one field on one MCS screen where this action applies.

Do not develop for proof of U.S. Citizenship if the Utility passes a “1” (Enumeration) or “2” (Title 2/18/16) to the “Select U.S. Proof if Citizenship Country is U.S.” field of the MCS CLCZ screen. No other action is necessary after these entries.

However, if a “4” (Development Pending) passes to this field, the Utility could not locate proof of U.S. Citizenship on the MBR or SSR, and the NUMI tolerance did not apply. In this situation, develop for proof of U.S. Citizenship (i.e., required before adjudication).

REMINDER: These entries pass to CLCZ only when the Medicare-only claim was started as an iClaim application.

R. References


To Link to this section - Use this URL:
http://policy.ssa.gov/poms.nsf/lnx/0200204059
GN 00204.059 - Internet Claim (iClaim) Medicare-only Application - 01/29/2014
Batch run: 01/29/2014
Rev:01/29/2014