The Arkansas Medicaid Management Information System is an automated data processing system that
- verifies the eligibility of beneficiaries for providers
- processes Medicaid claims
- reimburses providers for services rendered to Medicaid beneficiaries
- provides the Division of Medical Services the data it needs to administer the Medicaid program—set rates, establish budgets, identify trends in the health care industry, and minimize abuses of the program
This system must meet federal standards (known as General System Design requirements) if the state is to receive the maximum allowable federal grants to support the program. That is, the system must be certified by the governing federal agency, Centers for Medicare & Medicaid Services (CMS, formerly known as
MMIS, maintained by DXC Technology, conforms to
all of these criteria. The system became fully certified by
in June 1986, retroactive to the system’s first payment cycle of October 1, 1985.
is a collection of integrated subsystems, each developed to meet certain
goals, and all working together to meet
needs. For more information, click on a subsystem name in the list below.
Recipient Eligibility Subsystem
Claims Processing Subsystem
Third-Party Liability Subsystem
Long-Term Care Subsystem
Children’s Health Services (EPSDT) Subsystem
The Recipient Eligibility Subsystem stores current and historical data about all individuals who are eligible for Medicaid benefits. This data is used in claims processing and administrative reporting.
The Recipient Eligibility Subsystem receives data transmissions each day from the Arkansas Client Eligibility System and the Long-Term Care Section of
DMS. The incoming data is reconciled with data already in the subsystem, and discrepancies are analyzed and resolved.
The Provider Subsystem keeps track of health care providers–individuals, facilities, and organizations–who are authorized to serve Medicaid beneficiaries. It also maintains pricing data for certain types of services.
The Provider Enrollment Unit enters and revises data about providers each day.
processes that information daily and produces reports to help the Provider Enrollment Unit track its work and identify and correct errors. This rapid turnaround prevents delays in getting services to Medicaid patients and in paying providers for those services.
The Provider Subsystem also maintains data about physicians who participate in Medicaid’s Primary Care Physician program, a system that operates much like a health maintenance organization, reducing duplication of services and controlling health care expenses for the state.
The Reference Subsystem keeps track of all the codes and conditions that apply to Medicaid claims. For example, codes have been assigned to each diagnosis (International Classification of Diseases), procedure (HCFA
Common Procedure Coding Schemes), and drug (National Drug Codes). And other data applies to virtually every code; for example, for each procedure, the subsystem must keep track of whether the procedure is covered by Medicaid and, if so, which types of providers are allowed to perform the procedure and how much providers are paid for it.
This subsystem not only is critical to claims processing but also is an essential tool for
and DXC Technology personnel. The data can be viewed through online terminals by individuals who are working on new
computer programs, conducting research, or answering questions from providers. Reports produced by the subsystem also help Medicaid managers analyze payments according to procedure code, provider type, and provider specialty.
The Pharmacy Prior Authorization function is part of the Reference Subsystem. Beginning July 1, 1995, pharmacists could use a voice-response system (using a touchtone telephone to interact with the computer) to get authorization for prescriptions. This system improved on earlier methods; but pharmacists usually had to wait for prescribers to complete and submit prior authorization forms. Since February 1, 2003, prescribers can use the voice-response system to request prior authorizations. Thus, this innovation has helped to get medicine to Medicaid beneficiaries more quickly and has speeded payments to participating pharmacies.
The Reference Subsystem also tracks drug rebates. To participate in Medicaid’s Prescription Drug Program, a drug manufacturer must sign an agreement with
to give Medicaid a rebate. The rebate money goes back into the drug program; thus it allows medicines to be provided to Medicaid beneficiaries at reduced prices.
The Claims Processing Subsystem is the core of
MMIS. It uses data from the Recipient Eligibility, Provider, and Reference subsystems to adjudicate claims–decide whether they should be paid and at what rate–and passes that information to the remaining subsystems for analysis, reporting, and follow up.
This subsystem has four components: Front End, Medical Policy History, Control Series, and Financial.
Front End Component
The three main processes of the Front End component ensure the integrity and reliability of claim data, allowing claims to be processed and paid as quickly as possible.
The Input Conversion process transforms claims in all media (submitted electronically, on tape, or on paper) to an expanded format that
can process most efficiently. It also accepts corrections to erroneous data that caused claims to be rejected in previous cycles and puts those corrected claims in line to be paid.
The Edit process checks the claim data against requirements defined by the Division of Medical Services to ensure its validity. For example, it ensures that numeric fields contain numbers, the provider number used is valid and active, and the procedure is appropriate to the diagnosis. Claims that do not pass these hundreds of checks are denied or suspended to be reviewed.
The Preliminary Pricing process assigns tentative payment amounts to claims according to the four most basic methods: institutional, professional, drug, and crossover.
Medical Policy History Component
The Medical Policy History component of the Claims Processing Subsystem audits all claims. That is, it compares the current claim data to its file of previous claims to be sure that the beneficiary has not exceeded the limits placed on Medicaid assistance, the claim is not a duplicate, and the relationships among the data elements are appropriate. If, for example, a provider bills Medicaid for performing an appendectomy on a patient who had her appendix removed 15 months ago, the Medical Policy History component will catch that error.
If the claim passes these audits, it is checked against the Prior Authorization File. Some procedures can be paid for only if Medicaid approves the procedure in advance. The Medical Policy History component first checks whether the procedure requires prior authorization and, if so, then checks whether that authorization was given.
The last step in this component is assigning a final amount to be paid to the provider for the service.
Control Series Component
The Control Series component of the Claims Processing Subsystem produces weekly reports of claim activity to be used by DXC Technology managers and Medicaid administrators.
The Financial component writes checks to providers (or transmits their payments electronically) and issues remittance advices (written records that help providers keep track of their payments) by transmitting a file of financial activity to the bank each week. It also compiles payment information for tax reporting; generates tax statements for providers (1099 forms and B-notices); recoups overpayments, credits, and refunds; and produces financial reports for the Medicaid administration.
Third-party liability refers to the responsibility of an agency other than Medicaid–such as a private insurance company–to meet at least part of the health care costs of a Medicaid beneficiary. By identifying beneficiaries who have third-party health care coverage, the Third-Party Liability Subsystem helps avoid and recover costs that should not be borne by the state.
The subsystem compares third-party liability data, stored in the Recipient Eligibility Subsystem, to the data submitted on claims. If the subsystem finds that a service is covered by an insurance policy, the Medicaid claim is not paid, and the provider is advised to file a claim with the insurance carrier.
The subsystem generates a variety of letters to insurance companies, providers, and beneficiaries, following up on claims for which a third party may be liable. And the subsystem’s files can be viewed online, simplifying research involving suspect claims.
Arkansas Medicaid distributes free software to all nursing homes for submitting electronic claims. We also provide vendor specifications to organizations that want to use their existing data processing systems to bill Medicaid, and we work closely with those organizations to assure that their electronic systems integrate smoothly with ours.
The Children’s Health Services (EPSDT) Subsystem supports the Early and Periodic Screening, Diagnosis, and Treatment (EPSDT) program. This preventive health care program applies to all Medicaid beneficiaries who are younger than 21. It includes developmental screenings, encouraging the detection and treatment of potential health problems.
The subsystem is concerned mostly with informing the parents or guardians of
beneficiaries about the availability of services and reminding them to take advantage of those services. Twice a year, it notifies beneficiaries of the services that are available. When a screening is due (according to a schedule defined by
DMS), it sends a notice to the appropriate County Human Services Office, which contacts the beneficiary to arrange an appointment.
The Children’s Health Services Subsystem also generates reports that satisfy federal and state requirements for reporting services to children and that are used by Children’s Health Services administrators to chart the direction of programs.