Will Online Medicare Enrollment Facilitate Processing?

Spring 2009

Although previously announced as a 2008 initiative, CMS delayed the roll-out of its online enterprise enrollment applications to early this year. The online enrollment process is designed to allow fee-for-service providers and non-DMEPOS suppliers to enroll in Medicare, access enrollment data, and provide updates to an existing enrollment via the Internet. CMS has not announced whether DMEPOS suppliers will be eligible for an online enrollment process in the future, only that there are no online enrollment applications for DMEPOS suppliers at this time. This article focuses on the registration process to become an approved user to access the online applications.

For purposes of discussing the online enrollment process, CMS refers to both Part A providers and Part B non- DMEPOS suppliers collectively as providers. This common reference to providers, however, appears to be the only aspect of this new enrollment process that has been simplified. In addition to rather complex educational materials and guides, CMS has created numerous defined terms which must be learned to master the registration process. For example, organization may include a physician or other individual practitioner and not just enrolled entities such as institutional providers and group practices. The following is a list of these key terms:

IACS-PC or Individuals Authorized Access to the CMS Computer Services — Provider Community is a combination of the security system CMS uses to register users and control the issuance of user identifications, passwords, and specific access to web-based applications (IACS); and reference to the provider and supplier communities (PC) that will be required to use the online system to access data.

Organization includes providers and suppliers such as hospitals, HHAs, SNFs, IDTFs, ASCs, ambulance companies and physician group practices, in addition to individual physicians and nonphysician practitioners who want to delegate staff to conduct transactions on their behalf.

Security Official or SO refers to the individual who can register the organization in the IACS and update the organization's profile information. The SO must register and become an approved user and then will be able to authorize others to register as certain types of users. The system allows for only one SO per organization.

Back-up Security Official or BSO is an optional user type and may include one or more individuals who, once approved as a user, may assist the SO in authorizing others to register as certain types of users.

User Group Administrator or UGA refers to the individual or individuals that may have access to the online applications, depending upon the specific role designated for each application. The UGA will establish a User Group and will be able to authorize End Users for that group.

End User refers to a staff member or contractor working for an organization trusted to access the online applications. An individual may be an End User for multiple organizations. For example, an organization that operates a hospital, SNF and HHA may have the same corporate employee function as an End User for each of the organization's User Groups.

Surrogate User Group applies to situations in which the organization wants to delegate online work to individuals or a company outside of the provider organization, such as clearinghouses, credentialing departments and independent contractors. The Surrogate User Group has a contractual business relationship with the organization but not with CMS. A Surrogate User Group may be associated with multiple organizations. For example, many providers request Ober|Kaler to prepare and file Medicare enrollment updates, currently done via completion of the CMS 855 forms. The same Ober|Kaler attorney could serve as the UGA of a Surrogate User Group that is associated with multiple providers.

Application Approver refers to the one or more persons that will approve each Application User's request for a specific role applicable to a particular online application. For each online application, an organization is to designate an Application Approver. The role of Application Approver is often filled by the UGA, but should an organization fail to designate an Application Approver for any enrollment application, the SO or BSO will become the Application Approver by default. The Application Approver is not able to access the online applications, however, which is why neither the SO or BSO is granted such access. Individual practitioners who do not designate staff to assist in completing online enrollments do not have an Application Approver, since the practitioner personally completes the application.

Application User refers to the individual or individuals granted the right to access a particular online application. Within the category of Application Users, different rights may be granted to the user. Some Application Users may be granted only viewing and printing rights, while other Application Users would be approved to enter, edit and submit data to CMS.

CMS will notify provider communities as the web-based applications become available, with clear instructions regarding which provider types should register in IACS. Prior to receiving this notification, providers should not attempt to register. This is a change from the initial series of MLN Matters articles on this subject that encouraged providers to register early, before access to the online services was available. Providers will be able to both access and update enrollment data, in addition to authorizing others to conduct certain transactions on the provider's behalf, such as a clearinghouse or credentialing department. CMS expects users will periodically access the provider enrollment data and, therefore, determined that a user password will expire if the system is not accessed over a 60-day period. Should the password expire, the user will be prompted to create a new password the next time the user logs into the system.

The first step in the registration process will be for the SO to register as a user, which will require the SO to disclose information about the organization in addition to the SO's social security number and date of birth. Once the SO is an approved user, the SO will be able to authorize the BSO, if applicable, the UGAs and Application Approvers to register. Once the UGA is a registered user, the UGA will be able to authorize End Users to register. CMS recognizes that an individual may serve in more than one user role for an organization, so at a minimum the organization will need at least two authorized users, i.e., an SO and UGA, with only the UGA having access to the online applications in this situation. When the plan is to serve in multiple roles, an individual will register under one role and will then be able to add roles once an approved user. Irrespective of how an individual becomes an authorized user for the organization, CMS intends to hold the SO accountable for the behaviors of any approved organization user.

CMS has issued three MLN Matters articles that provide an overview of the IACS system and registration procedures. These articles have undergone some updates, the most recent being July 30, 2008. The first article (MLN Matters No. SE0747) provides an overview of the IACS-PC registration process and registration instructions for SOs and individual practitioners. The second article (MLN Matters No. SE0753) provides instructions for registering BSOs, UGAs, and End Users. The third article (MLN Matters No. SE0754) discusses the final steps in accessing CMS enterprise applications. The articles are supplemented by a series of Quick Reference Guides that are designed to assist the various user types to navigate through IACS. Additionally, CMS has a Reference Chart for Organizations that provides a one-page overview of the various user roles, including who can authorize the individual to access IACS and become an approved user, and the ability of each user type to access the online applications. These reference materials are available on CMS's website at www.cms.hhs.gov/IACS/04_Provider_Community.asp.