Implementing Medicaid Management Information System

Implementing the Model Medicaid ManagementInformation System

JOHN C. ANDERSON, PhD, and PAUL FARSETH, BA

THE MODEL MEDICAID Management Information Sys-tem (MMIS) has been, subjected to much recentcriticism and concern from government administra-tors, legislators, and providers of health services.Some critics suggest that it is not fulfilling its in-tended objectives in States where it has been in-stalled, that it is not processing information correctly

fj Dr. Anderson is assistant professor of managementsciences, Graduate School of Business Administra-tion, and member of the Management InformationSystems Research Center of the University of Minne-sota. Mr. Farseth is supervisor, Catastrophic HealthBenefits Program, Minnesota Department of PublicWelfare, and was formerly principal managementanalyst in the department's Medicaid DevelopmentSection. Tearsheet requests to Dr. John C. Anderson,Graduate School of Business Administration, 751Business Administration Tower, University of Min-nesota, Minneapolis, Minn. 55455.

and on time. Others suggest that although the systemmay process information correctly, the reports itproduces have not been integrated productively intothe management of State Medicaid programs (titleXIX of the Social Security Act). We believe thatcareful review of State experience with the MMISwill show the model system to be a sound design foradministering Medicaid. The problems which haveclustered around the MMIS are real, but they arethe consequences of the particular processes thatStates have used in implementing the design andintegrating the system with their administrativeoperations.

It is not surprising that the MMIS has been diffi-cult to implement and integrate. Researchers andmanagers, both public and private, have been in-creasingly concerned in recent years with the problemof how to implement management information sys-tems. In all parts of society examples can be foundof failed information system projects, expensiveproducts of hard effort which produced unused in-

March-April 1977, Vol. 92, No. 2 135

formation or information that is inadequate to themanagerial needs it was designed to satisfy.An almost unanimous conclusion of recent research

into the problem of implementing information sys-tems is that implementation must be viewed as anongoing process rather than the last phase of aproject effort. Success is won or lost all through theanalysis, design, and developmental phases and bythe care and flexibility with which the early phases'plans are refined during the final installation ofcomputer programs and administrative procedures.A related conclusion is that information systems,when in place, become dynamic parts of their orga-nizations. Implementation must continue, with thesystem evolving with the organization.This paper draws on our observation of the process

of implementing the MMIS in Minnesota. We offersome normative conclusions and recommendations toguide other States' MMIS efforts and other efforts inbuilding large-scale information systems, particularlyin the public sector.

Background: MMIS and the Minnesota ProjectSince its inception in 1966, the federally sub-sidized Medicaid program of medical assistance forthe poor and disadvantaged has encountered anunexpected spiraling of its costs, whiclh now exceed$14 billion per year in State and Federal expendi-tures. Administered by State and Territorial Govern-ments and their local subdivisions under the generalsupervision of the Department of Health, Education,and Welfare's Social and Rehabilitation Service, theprogram has varied greatly in the effectiveness of itsmanagement. Controls on excessive and duplicatepayments, investigation of fraudulent claims, andcontrols on substandard quality of services have oftenbeen lacking. Complicated standards of eligibilityhave led to errors in who may have access to theprogram's benefits. Lacking the substantial co-insurance involvements of recipients' pocketbooksfound in the Medicare program, Medicaid recipientshave not objected to large amounts of overserviceand to overcharging, which Medicare recipients wouldfind intolerable.To correct these deficiencies, the Social and Re-

habilitation Service developed a model MedicaidManagement Information System to guide States incomputerizing and upgrading their claims paymentoperations, fraud investigations, and utilization con-trol efforts.This model was first published in August 1971,

and pilot implementation in Ohio was begun inJ972. In the Social Security Amendments of 1972,

Congress provided fiscal incentives to States to setup information systems patterned after the model(Federal assumption of 90 percent of developmentcosts and 75 percent of operating costs of qualifyingsystems). Those amendments also required States togenerate statistical profiles of providers' patterns ofservice and of recipients' patterns of service utiliza-tion. Group profiles were to provide norms againstwhich individuals' profiles could be compared. Suchprofiling requires computerized information han-dling on a scale similar to that envisioned in theMMIS. Requiring it provided further incentive toStates to install the MMIS.The Minnesota Department of Public Welfare

responded to the new incentives quickly, beginningwork in January 1973 on a centralized Medicaid pay-ments and information system that would meet theMMIS design criteria and would replace the manualprocessing of claims previously carried on by 87county welfare departments. Centralized paymentsfor nursing home services were begun in January1974, and by May 1975 all regular providers of healthservices were paid through the new system. Computerprograms that generate management reports andsurveillance profiles were completed by August 1975,and Minnesota was certified for 75 percent Federalparticipation in MMIS-related operating costs, effec-tive the first of that month.

Since then, the system has been significantly re-fined, particularly in its benefits recovery capacityand in the tracking of persons eligible for EarlyPeriodic Screening, Diagnosis, and Treatment(EPSDT). During fiscal year 1976, the system pro-cessed approximately 220,000 claims and adjustmentsper month, paying out about $320 million in bene-fits by the year's end. Administrative costs for theyear came to roughly $4.5 million. These costsinclude expenses for provider enrollment and train-ing, claims processing, production of managementreports, surveillance and utilization review, medicalpolicy supervision, mailing of explanations of Medic-aid benefits (EOMBs) monthly to recipients ofservices, plus teleprocessing and maintenance of thecase information (eligibility) file. The $4.5 milliondoes not include the cost of audit staff and generaloverhead costs for the welfare department's execu-tives and support services. Also excluded are thecounties' costs-costs of administering the recipienteligibility intake and review process, assistance toclients needing EPSDT services, review of the appro-priateness of nursing home patients' level of care,and local review of certain monitored claims formedical supplies. After the exclusions, the adminis-

136 Public Health Reports

trative cost per claim amounted to about $1.70, asum which compares favorably with Medicare ex-perience. Caution is needed in such comparisons,however, as definitions vary as to what constitutesa claim or what expenses are to be included in ad-ministrative costs.

In establishing its MMIS payment system, Minne-sota transferred an important group of computerprograms from the Oklahoma welfare informationsystem to provide the basic structure of its case infor-mation system. Most of the other computer programsneeded to implement the MMIS model were trans-ferred from the Ohio Department of Public Welfare,the pilot project site. Administrative procedures andthe concept of using optical character recognition(OCR) scanning devices instead of keypunching toconvert data to computer form were borrowed fromthe Michigan Department of Social Services. A sys-tem for processing nursing home claims was devel-oped locally. All transferred computer programswere substantially rewritten to meet local require-ments and to improve their computer efficiency.

Management of the Minnesota project was led bystaff from a small consulting firm, assisted by stafffrom the Minnesota Department of Public Welfareand the information systems division of the State'sadministration department.

Minnesota's experience with the MMIS wasneither smooth nor disastrous. The information sys-tem which resulted is not the ultimate version ofthe MMIS, but it is more than adequate, and it isevolving to meet new needs in the administrationof the Medicaid program. Drawing on our experi-ences in the Minnesota project, we offer here a con-ceptual discussion of six areas where problems mayarise during an MMIS effort, six areas in which keytasks must be addressed:

Defining program and operations policiesOrganization planning and defining of rolesManaging and controlling the projectDefining data and output requirementsProvider relations and trainingCoping with technological change

Defining Program and Operations PoliciesTo be worth its development and operating costs, aMedicaid information system must support and exe-cute the program's key policies. Therefore the poli-cies must be known. In addition, they must be fair,defensible, and capable of enforcement. (In Minne-

sota, program policies often proved to be unclear atthe start, owing to the previously loose-knit admin-istration of the program by many local agencies.)

If policies are ill-defined, they must be clarified.If they are out of date, unfair, or unenforceable, theyneed to be revised. A management information sys-tem as big as the model MMIS has too much inertialmass to risk setting any part of it in motion on awrong track. The costs of backtracking and fixingerrors can be huge-both in dollars and in injusticesto providers and recipients of medical care.

Clearly, not all policies can be defined and ana-lyzed in advance of the technical phases of such aproject. Indeed, one of the strengths of the Mlinne-sota project was its continuing reconsideration ofobjectives, policies, and priorities as the political,legal, and administrative constraints on the projectbecame more clear. But it is important to achievethe greatest possible clarity about the program's andthe system's goals before beginning.To make sure that policy is defined, revised, and

correctly programed into a mechanized system ofclaims payments, staff must be assigned to refinepolicies, to analyze the impact of new or proposedFederal laws and regulations, and to interpret thepolicies definitively to systems analysts, health careproviders, provider trainers, and claims processingsupervisors. Opportunities must be provided foradversarial evaluations of particular policies, lestthey be based on inadequate information or set with-out regard for external consequences.

Organizations going through rapid change orgrowth are often tempted to limit criticisms fromstaff and to discourage meddling across organiza-tional lines. This fosters accountability and sup-presses fruitless squabbling, but the mediation ofpolicy criticisms (or technical disagreements overmethods and procedures) through a few members ofa managerial elite may stifle and dry up informationsources needed to keep an organization's processesof change on target. Forbidding communicationsbetween work groups (as some supervisors did dur-ing the Minnesota project), particularly if they areworking on different aspects of the same problem orfunction, delays information flows and distorts andfilters information which needs to be communicated.The Minnesota MMIS project overcame initial

unclarity about program objectives, policy con-straints, and limits on what could be required ofoutsiders such as health care providers, county wel-fare offices, and Medicare fiscal agents, by applyingtechniques discussed in the next two sections of thispaper. When the techniques failed or were not ap-


plied, the costs were significant. Before discussingthose techniques, however, two other aspects ofpolicy definition need comment.

Besides internal policy definition and revision, theleaders of an MMIS project effort must acquire legis-lative support for statutory revisions of policy. InMinnesota it became necessary, midway in the pro-ject, to seek legislation giving the Medicaid programa right of subrogation to recipients' health and cas-ualty insurance benefits (to the extent of the pro-gram's expenditures for any given recipient). Inother States, legislation has been needed to mod-ernize legal requirements for approval of vendorclaims or for keeping records or issuing checks. Inaddition, existing laws may not give enough author-ity to a Medicaid program to require standard in-voice forms.

Finally, there is the issue of legislative support fordeveloping a new Medicaid management informa-tion system. Indeed, this is the first issue encoun-tered, as the State's share of development costs mustoften be appropriated after much debate overwhether "inept State bureaucracies" or "self-servingoutsiders" can better be trusted to do a good job ata reasonable cost.This problem of legislative support was short-

circuited in Minnesota by the intervention of theGovernor's statewide Loaned Executive AssistanceProgram (LEAP) during 1972. Eying projections oflow development costs from an earlier consultantstudy of centralizing Medicaid claims processing in-house and the screening portability of the OklahomaState welfare information system, the LEAP teamsassigned to the welfare department forced an earlycommitment to developing a State-operated MMIS.

Other States may not find such decisions so easy toresolve, nor should they. If the Medicaid agencylacks internal managerial expertise, if the State civilservice system is intractable, or if computer and sys-tems support are lacking or outdated, the possibilityof buying an established fiscal agent's expertise de-serves evaluation.

If a contractor is to operate a system after build-ing it, however, several new concerns arise: Whatincentives does the contractor have to control pro-gram expenditures? Is there some risk that the con-tractor may control program expenditures by deny-ing benefits in an arbitrary way, often after servicehas been rendered? Does the contracting fiscal agenthave any incentive to control its operating costs ifit is paid on a "cost-plus" formula? Are its costs andoverhead expense required to be reasonable andopen to audit? Will the State be able to do an effec-

tive audit, probing deeply and carefully enough tochallenge the fiscal agent's cost statements?

If a fiscal agent is to be reimbursed on a flat rateper claim, do the performance criteria in the con-tract insure that any underbid by the agent will notbe recovered improperly through slow or inaccurateclaims processing? Is there any fine-print provisionfor formula increases in rates which pass the agent'sfirst year underbid losses back to the State in subse-quent years?And if a fiscal agent is selected that later proves

too expensive or unacceptable in some other way,how is the State agency to handle claims processinguntil another agent can be selected and installed? Itappears that at least one State has been forced torenew a fiscal agent's contract at unfavorable termsbecause no other agent could be installed quicklyenough. Such misfortunes can be forestalled bycareful contract writing, with clear definitions ofshort-term renewal options to cover periods of re-negotiation or changes in contractors.

Organization Planning and Defining of RolesAlong with the practical work of project manage-ment and control, discussed subsequently, Stateagencies beginning an MMIS development face aneed to review their internal organization for deci-sion and control and the quality of their supervisionof local welfare agencies or offices. At the same time,they need also to review their relationships withoutside agencies to clarify roles, powers, goals, func-tions, and the distribution of political influence.Such outside agencies include State health depart-ments, hospital and nursing home rate-setting au-thorities, professional standards review organizations(PSROs), and health professions' licensing boards.A Medicaid agency's administrators need to look

at the commitment of time available from their topmanagers and from the directors of local offices.Minnesota's ability to bring its MMIS project tofruition required continuing detailed attention andsupport from the Commissioner and her deputy.Their involvement was crucial to acquiring and su-pervising the project's consultant firm, to shapingthe project's authorizing and housekeeping legisla-tion, and to forcing decisions from other depart-ments (particularly the administration department,which was responsible for the State computer center,and the personnel department, through which emer-gency staff appointments and timely acquisition ofprofessional staff had to be channeled). Since thewelfare department was at first short of experiencedand aggressive staff in the AMedicaid policy section,


the almost daily participation of the director of theincome maintenance division in the project wasessential.

In allocating responsibilities, each person's man-agerial ability needs to be looked at. In every orga-nization there are managers who are comfortablewith the status quo, settled in their ways and lack-ing in the curiosity and assertiveness needed toguide drastic new developments. Ihis may be a spe-cial risk in government, where tenure can protectthe weak and political pressures may housebreak theinnovative. If such persons hold key positions, theyneed clear guidance on what is expected in the neweffort. In an MMIS development, everyone worksdouble. Letting those who may turn out to be inde-cisive, unmotivated, or incompetent know about theextraordinary demands with which they will be facedmay make it simpler to relocate them to less stressfulpositions or to justify their later replacement.

Outside the central Medicaid agency, control oflocal welfare offices is critical, for these must man-age the determination and review of recipients' eligi-bility, transmit timely and accurate eligibility infor-mation to the central office, deal with recipients'practical ptoblems, and maintain other local rela-tionships for the State. A State department is likelyto find that the size and sophistication of such localoffices or agencies vary. Such variations, the degreeof local autonomy (be it legal or habitual), past re-sponsibilities, and past performance should all beconsidered in deciding what functions to delegatebeyond eligibility intake and review and arrangingfor EPSDT services. Should local agencies answerservice providers' inquiries about Medicaid recipi-ents' eligibility dates and ID numbers? Should theyhave a role in reviewing nursing home patients'levels of care? Should they make decisions on rentingor buying durable medical equipment? Each Statewill find different answers. The answers maybe misguided, however, if the past and expectedcapabilities of the local offices are not reviewed, giv-ing close attention to possible causes of past per-'formance failures. -Some causes of failure can beremedied. Confusing central office directives on poli-cies and procedures can be clarified. But local,autonomy and unwillingness to cooperate are moredifficult to change. If county welfare boards refuse tohire sufficient staff at the expense of local propertytaxpayers, the Medicaid agency may need some meansto compel cooperation or to subsidize the counties'costs with State and Federal funds.

Regarding relations with other agencies, the fol-lowing observations may be helpful.

Medicare fiscal agents. It is desirable to arrangewith Medicare carriers and intermediaries for auto-mated exchange of data on payments made forMedicaid recipients. Such acquisition of data oncomputer tape should be provided for early in anMMIS project. It eliminates the need to make healthcare providers bill both Medicare and Medicaid. Itimproves the accuracy of payments for crossoverclaims and removes opportunities for provider fraud.It provides more complete data for surveillance andutilization review of services to Medicare benefi-ciaries. And it costs less (to both the Medicaid andMedicare organizations) than shipping explanationsof Medicare benefits on paper from the fiscal agentsinto the Medicaid shop for manual review, anno-tation, and keypunching. Liaison is also desirablewith Medicare fiscal agents regarding such mattersas their relations with hospital utilization reviewcommittees and PSROs, sharing of practitioner feeschedules, and coordination of audits of hospitals'statements of operating costs.

State health departments. The Medicaid agencyneeds timely verification from State health depart-ments of the eligibility of hospitals and nursinghomes to participate in the title XIX program. Itneeds to facilitate health departments' mandatorymedical or professional reviews of care given to nurs-ing home patients. It can profit from acquisition ofcomputer files of the social security numbers ofpersons who have died (in order to purge Medicaideligibility files). It may need health departmentassistance in meeting its obligation to provide earlyperiodic screening, diagnosis, and treatment forchildren. It may want to contribute to institutionalrate review activities carried on by health depart-ments. And it may be able to provide useful epi-demiologic and health services utilization data tohealth department researchers.

Professional standards review organizations. Goodrelationships with PSROs are important to StateMedicaid programs because of the contribution thePSROs can make to cost containment and qualityassurance. PSRO relationships affect MMIS effortsbecause PSROs may depend on Medicaid agenciesto collect the uniform hospital discharge data ab-stract for PSRO review. Or, being physician con-trolled and jealous of their autonomy, they maymake it difficult for a Medicaid program to collectsufficient information for claims review, budget plan-ning, and utilization review. In any event, if dataare to be collected for PSRO use or in parallel withPSRO collection, agreement on uniform data coding


schemes is important, lest hospitals face impossiblereporting burdens.

Other compensation systems. Finally, we empha-size the importance to State Medicaid programs ofinvesting more staff, expertise, and systems capa-bility in the recovery of health care benefits to whichrecipients are entitled. This effort requires closeliaison with the health and auto insurance industriesand with the Workers' Compensation system. Analy-sis of Minnesota data suggests that a well operatedand aggressive system of claiming recipients' bene-fits on a national scale could recover more than $500million per year in health and casualty insurance,workers' compensation, and dependents' health bene-fits from employed absent fathers. Minnesota hascomputerized much of the benefits recovery process,but accomplishing this has required cooperationwith the insurance industry and training of localwelfare agency staff to insure that good informationon recipient coverage is effectively reported.

Managing and Controlling the ProjectProject managers must plan to communicate withand actively involve all persons affected by an MMISproject if an effective information system is to beimplemented. Having addressed the make-or-buy de-cisions mentioned earlier and having settled on somecombination of consultant (or fiscal agent) and Stateeffort, management must develop routines, proce-dures, and an organization to carry out the project'stasks. In this regard, we offfer several comments.

First, the level of involvement of a consultantorganization must be controlled if a State or someother agent is to operate the new information sys-tem when it is completed. Minnesota's Medicaidagency assured its ability to operate, maintain, andrefine the system by limiting the role played by itsconsulting firm and by distributing the firm's per-sonnel throughout the project's work groups. As aconsequence, almost no components came into thesystem without State personnel having participatedin their detailed design and computer programing.If this had not been done, State operating staffwould have been dependent on the consultingfirm's system documentation and unclear about theplacement of the system's components and the rea-soning behind their particular form.

Next, use of a project-management protocol isdesirable, so that all tasks are done in an effective,ordered, and timely manner. Minnesota, followingthe practice of the State computer center, used apackaged set of procedures (PRIDE, M. Bryce &

Associates) for systems analysis and documentation,cost analysis, and job scheduling. The particularpackage of procedures that a State chooses is notcritical, but use of documentation standards, standardtask lists for organizing and phasing work, andstandardized procedures for reviewing progress pro-vides important protection against oversights, ineffec-tive assignments of staff, and failures to keep tech-nical documentation complete and up to date.Using components of a system transferred from

another State should not substitute for analysis ofinternal requirements, nor should it tempt the proj-ect's managers toward unrealistic expectations ofhow quickly systems development can be accom-plished. Minnesota encountered policy differences,technical deficiencies, differences in medical serviceand diagnosis codes, and other problems embodiedin the computer programs it transferred. All thesehad to be worked out before the programs couldbe run reliably. When they were not considered, ashappened with the surveillance and utilization re-view programs, which received only minor patchesto computer code, the computer outputs containeddata of questionable value.On the other hand, the value of the experience

and completed debugging of computer programs in-herent in a transferred system cannot be underrated.The imported system's documentation, coupled withqueries to its management and support personnel,are valuable tools for training and orienting projectstaff. The "not invented here" syndrome shouldnot blind a State to this opportunity to avoid errorsother States have worked through.

Finally, to insure that decisions are made on aninformed basis, the project's decision makers shouldhave the benefit of regular structured informationexchanges and technical orientation briefings. Brief-ings on data processing concepts for policy staff mayforestall unrealistic demands on the technical stafffor impossible time schedules or impractical com-puter processing logic. Briefing systems and proce-dures analysts regularly on the program's objectives,policies, and regulations will help them to draw outthe policy staff with good questions about the sys-tem's requirements and will make the analysts moresensitive to the sequential dependency of each suc-cessive computer subsystem.The Minnesota MMIS project suffered initially

from the data processing naivete of policy staff andfrom systems analysts' inability to define or elicitthe necessary decisions from the policy staff. Twofactors compensated for these findings. First, duringthe early stages of development, many of the deci-


sions taken were strategic rather than technical;they were choices of which design components ofthe system to import from other States. Meldingtechnical and policy expertise did not become aproblem until the retailoring of the imports to localrequirements began. Second, once detailed designof reports and processing logic got under way, twomajor committees facilitated information exchangeand discussion of policies and methods.Formed early in the project, a welfare systems

advisory committee (WISAC) drew together Statepolicy and systems staff with representatives ofcounty welfare departments. Meeting monthly, andsometimes more often, the WISAC committee drewfrom the staffs of the, local agencies informationabout what data they could provide for the Medic-aid public assistance case information system andwhat outputs the local agencies needed for internaluse and for control of data integrity. The discussionsof this group had major impacts on the data setfinally installed in the case information system, onthe methods of local agency reporting to the sys-tem, on the design of the system's reports, and onthe establishment of the central eligibility files usedfor the turnover of adult cash assistance cases tothe Federal Supplemental Security Income (SSI)Program.

Beginning work in the spring of 1974, approxi-mately 1 year into the project, a second, even moreimportant committee came into being. The Tuesdaymorning group was a tactical consortium of about20 policy staff, systems analysts, and data projectmanagers, chaired by the project coordinator; itincluded the income maintenance director, actingwith the authority of an assistant commissioner.The Tuesday morning group reviewed progress onall key issues, discussed alternative technical designstrategies, wrestled repeatedly over how to define orrevise unworkable program and operations policies,and reached consensus on priorities and assignmentsof staff resources. These sessions, often stormy, werecrucial to the project's success. During these meet-ings, the interdependence of the work groups andproject actors became clear. Gaps in policy, impos-sible burdens proposed to be laid on medical careproviders, new Federal regulations, and the conse-quences of programer misunderstandings were iden-tified and analyzed. Worth noting is that all partici-pants could address any work group's progress,methods, designs, or interpretation of the regula-tory environment. This tapping of all participatingpolicy and systems staff persons as information re-sources consistently led to advance warnings of over-

sights and impending problems (both technical andpolitical), which could then be addressed beforethey achieved fatal momentum.The Tuesday morning group assured coordina-

tion of efforts. Because it functioned in a structuredbut open and nonauthoritarian way, it improved theinformation base for decisions. Because it operated,for the most part, by consensus (the group felt strongdiscomfort if any knowledgeable member could notagree), it elicited an uncommon and powerful espritfrom its members. Finally, because the higher levelsof management participated in the group, it wasable to define its outputs without a continuing riskof reversal from above.

Defining Data and Output RequirementsAll analyses of management information systems aimat some array of outcomes, typically information out-puts on which operational controls, disbursements,audit trails, budgeting, and strategic managementdecisions can be based. Defining the content andform of outputs to meet management's and theorganization's needs is critical to the success of theproject.

The availability of the data requirements andreporting structures identified in the published"MMIS General Systems Design" should not lead aState to assume that this analysis is complete orsufficient for all State requirements. The managersof the Minnesota project found considerable furtheranalysis was required.We have already said much about the need to

clarify, continuously, the program objectives to beaccomplished by information management. We stressthat the sufficiency, acquirability, reliability, andconsistency of data must be assured, and the formin which they are presented must enable the userto find the information needed to make decisions.

Sufficiency. Computer files and the input docu-ments, such as invoices, must contain the data ele-ments needed for automated decisions, computations,and edits. There is a temptation to build tough andlean systems based on minimal data sets. States plan-ning to develop an MMIS will do well to recognizethat more data elements will be needed to drive theMMIS than are recommended in the model systemdistributed by the Department of Health, Education,and Welfare through National Technical InformationService. Data sets smaller than those in the model sys-tem may endanger the system's certifiability forincreased Federal participation in operating costs.


Acquirability. Data elements to be reported bymedical vendors or county welfare agencies must besufficiently well defined and well organized to makethe cost of reporting them reasonable. Procedure anddiagnosis codes (for example, the InternationalClassification of Diseases, Adapted, Eighth Revision-the ICDA-8-and the major variant published bythe Commission on Professional and Hospital Activ-ities-the H-ICDA-2) should reflect a consensus oflocal providers' practice. It is madness to requirephysicians to code invoices with the procedure codesof the National Association of Blue Shield Plans ifthe dominant local insurance carriers are demand-ing use of codes from the third edition of CurrentProcedure Terminology (the CPT-3). (Local Medi-care coding choices are less critical if the carriers aredoing their own coding, although codes received oncrossover claims passed on by title XVIII carriersshould be translatable for utilization profiling pur-poses.)

If data are not reported, redundant sources shouldbe supplied, with system defaults for nonfatal datagaps. For example, Minnesota found that recipients'birthdates on invoices were more accurate than thedates in the eligibility file, but more likely to bemissing. Both sources of data are entered in thesystem, so that discrepancies can be flagged to assureaccurate computing of recipients' ages.

Reliability. Besides editing data for plausible valuesand correct formats, a well built MMIS should havedata collection forms designed to prevent errors infilling them out or in keying (or scanning) them intocomputer processing. Standard invoices prevent re-porting errors, but nonstandard conventions for fill-ing them out may create more errors than use of in-voices designed specifically for Medicaid. Data re-ported should be relatively raw. Providers shouldnot have to do complex computations to arrive atnet billed charges. The computer can do the com-puting better, though it may need more operands(data reported) to get started.

Identifiers should contain self-checking digits (com-puter check digits) where possible. However, if anumeric series of identifier codes has many gaps andfew transposition problems, as perhaps in the CPT,the need for check digits is less critical. In Minne-sota, the State medical association's re-issue of theCPT contains check digits used by Medicaid but notby Blue Shield. Each feels that it gets payoffs fromits approach to the codes. On the other hand, Minne-sota's failure to put check digits in recipient identifi-cation numbers has been a source of grief.

Codes to be captured should be of workable size.Minnesota's 16-digit recipient identification numberinvites errors each time it is copied, keyed, orscanned, even when it is broken into small blocks.

Finally, data schemes should be designed for easyediting on data entry equipment (particularly key-disks and optical scanners), because correction or re-jection of defective data by manual operation is mostefficient when no major computer processing has beendone and when no marrying of errors lists to originaldocuments is needed.

Consistency. Data coding schemes must be consis-tent over time. If significant changes in schema areundertaken .(for example, from ICDA-8 to H-ICDA-2), providers of data must be notified of the changedrequirements and given training, computer historyrecords must be translated, and providers should,preferably, be required to enter a flag mark on sub-missions of new data to indicate use of the new codes.Similarly, when old fields are redefined in computerrecords, previous data in the computer history filesmust be purged before the new application begins.

If MMIS components are transferred from otherStates, the compatibility of code structures is espe-cially important, because edits and decision treesmay be hard coded in COBOL on the basis of codemeanings not applicable in the new location. Minne-sota was forced to do major overhauls of the Ohiosurveillance and utilization review computer pro-grams after it initiated use of the 1964 CaliforniaRelative Value Studies procedure codes as permis-sible alternatives to the CPT. All procedure mapshad to be double tabled to the second code scheme,and the isomorphic American Dental Associationcodes had to be filtered out.

Output clarity. Reports should present informa-tion needed for making decisions at the level of theintended users. Reports should be organized to flagor focus attention on the exceptional items whichrequire action and to assist retrieval of data on thepersons or classes of cases of interest to the user.Following are several pitfalls worth noting:

* Reports which summarize transaction data to atrivial level of generality.* Reports which display so muclh detail that sum-maries and comparisons are physically impractical toextract.* Reports lacking data needed to interpret detail,suclh as abstracts of a recipient's history with no diag-nosis data or with drug codes but no drug names.* Reports in awkward sort orders whiclh disperse


data desired to be accessed simultaneously (for ex-ample, claims adjustments for a provider which can-not be examined adjacent to regular claims in aprovider history).* Reports which display comparison data in sortorders different from the reports or files with whichthey are to be compared.

Finally, we stress again that the contents of re-ports must be tailored to management's actual needsin decision making, as these are understood in eachState. Early in the analysis of the Minnesota's sys-tem's requirements, it became evident that a largenumber of statistical reports not defined in themodel MMIS or the Ohio system would be desired.Other new reports had to be developed to serviceMinnesota's system of charging counties for partof the non-Federal share of expenditures. Hospitalcost settlement reports had to be repeatedly redoneand redefined. Analysis of the distribution of reasonsfor pended claims was needed.Rethinking and augmenting the report structures

of information system packages are normal tasksin transferring computer systems. The process shouldnot be glossed over, as it can make or break a trans-fer effort. The new system must generate enoughusable information to make it controllable by itsmanagers in its new form and changed environment.New report structures should not simply recapitu-

late material in existing reports. The old reportsmay have been unreliable, incomplete, misleading,unintelligible, or simply unused. It is essential toassure that reports can be generated to supportall important operating, planning, and control deci-sions. Information systems can be decision systemsonly when their reporting structures support andare compatible with management's decision processes.

Provider Relations and TrainingIn developing a Medicaid MIS, provider relationsand training have at least four major facets: market-ing, tapping the information resource, training, andtroubleshooting.

Marketing. Installation of the MMIS causes changesin processing requirements and procedures for han-dling medical claims. New data elements must bereported by vendors of health services. New invoicesand forms come into use. Standards for payment ofclaims tighten. Explanations of payments change.Delays and foulups in payments occur. All of theseevents mean that the Medicaid agency has a market-ing problem with its vendors. It must sell vendorson the value to them of putting up with the new

requirements and the expected inconveniences thatoccur during the debugging of a new system.Marketing requires direct communication, face-

to-face if possible, with affected vendors, to alertthem early to impending changes, to persuade themof the good will and honest intentions of the Medi-caid agency's staff, to convince them of the socialutility of the proposed changes, and to clarify thebenefits they may expect to receive (such as im-proved cash flow). Such communications should becandid and timely but not dogmatic and premature,and the agency staff should guard against makingcommitments and uninformed promises that latermay not be kept.

In addition, good marketing requires liaison withprofessional associations and influential representa-tives of provider groups to assure their assent andsupport for the project. Their support will often beless than generous, since the MMIS lays new burdenson providers, may reduce fees, and promises newforms of provider surveillance. But failure to discussthe new requirements and benefits with providergroup leaders will result in resentment, organizedresistance to the new requirements, and politicalproblems over misunderstood requirements.

Tapping the information resource. Providers ofcare know what information they can report, whatbookkeeping procedures they use, and their businessoffice costs. They may not know these facts precisely,but they have better information than the Medicaidagency has. The Minnesota agency discovered, to itschagrin, that it is cheaper and politically easier to tryearly to tailor billing procedures to what is withinreach of providers' business offices than to invest inrequirements which cannot or will not be met. AState will find it useful to work through its infor-mation reporting requirements with providers, busi-ness office personnel, and service bureaus early inthe development process. This interchange does not

require yielding on disputes over capture of dataabsolutely required in the system, but it does mean

keeping open to the possibility that some proposedrequirements may be trivial or needlessly clumsywhen a simpler or different approach may be more

acceptable.In addition, providers of care believe that they

have something to contribute to the definition offair policies on what services should be covered,subject to which checks and reviews. They do, bothindividually and through their professional associa-tions and delegates to Medicaid advisory committees.Unless a State's Medicaid and MMIS project staffs


are exceptionally large and experienced, providerinputs to redefinitions of policy are invaluable infilling in the State agency's gaps in knowledge andexpertise.

Training. Changes in billing and bookkeepingrequire retraining of providers and, most important,their billing clerks and service bureaus. Trainingmaterials must be complete and adequately indexed,with clear examples. Training seminars must beheld for billing office personnel, not just for pro-fessionals or hospital administrators. Training shouldbe timely, not the week before procedures change.Trainers must know billing and claims processingconventions intimately and have open lines of com-munication with Medicaid systems and policy staffto obtain quick answers to questions and difficultieswhich may arise. In addition, trainers should beinstructed to identify and communicate back to theagency newly discovered problems and policy con-fusions, so that they may be corrected.

Because procedures will continue to change as anMMIS is refined, channels of communication withproviders should be continuous. Minnesota foundthat information could be distributed quickly viamessages on fortnightly remittance advice billings.Provider bulletins that can be produced and mailedon short notice are often necessary, but these shouldgo through a clearance procedure to control unau-thorized "emergency" changes in procedures andpolicies. Provider handbooks should be indexed sothat changes and additions are simple to insert.Minnesota discovered that numbering inserts by sec-tion and topic was no substitute for page numbers.

Finally, individual providers will invent uniqueways of fouling up both the system and their cashflow. Staff who train provider personnel should beprepared to work with individual providers to locatethe cause of their problems. The claims processingsystem should be capable of referring providers withpersistent problems regularly to the training unit,using such tools as provider inquiries and provider-specific computer analyses of error-code frequenciesin pended claims. In Minnesota's experience, one-to-one communication with providers having con-sistent processing difficulties has been an expensivebut cost-effective method of resolving provider prob-lems.

Troubleshooting. During and after the MMIS'installation, individual providers and the systemwill have problems. A mechanism is needed for pro-viders' inquiries about unpaid, mispaid, and rejected

claims. The organizational location is not critical,but this office must have access to the claims anddocument control (tracing) indexes and to remit-tance advices and warrant logs. Its staff need accessto policy and medical professional staff, to systemsanalysts and programer support, and to providerhandbooks and systems documentation. Staff whohandle provider inquiries must be alert to commonproblems which may be resolved through providertraining, information bulletins, and handbook revi-sions, or by reprograming computer edits and bil-ling conventions. In Minnesota, this function, alongwith processing of requests for adjustments, is han-dled by the staff of experienced medical claims ana-lysts responsible for reviewing excepted claims.

Coping with Technological ChangeThe model MMIS is a design for a large and com-plex computerized information system. Building itmakes demands on computer facilities and theirpersonnel. Replacing clerical operations with com-puter processing drastically changes established doc-ument handling and decision making routines.Establishing new management functions dependenton computer outputs changes managers' modes ofaccess to decision data, as well as the sorts of dataavailable. Coping with such changes is, in largemeasure, a problem of managing people, of helpingthem to organize and adjust to a new wQrk andinformation environment.The adjustment can be eased by giving care to

the technological changes which impact the workenvironment or complicate the computer system.We discuss some common sources of technologicaldifficulty in this section.

Need for new computer and terminal hardware.Bringing up a system in a computer center withoutsufficient disk file, tape drive, or line printer capac-ity may necessitate major rewriting of transferredcomputer programs or cause losses in computer effi-ciency. Conflicting demands for central processingunit time or computer core may delay productionprograms and occasionally force skipping the pro-duction of some management reports. Outdated tele-communication systems may compromise the time-liness of eligibility files or increase the productionand distribution load of paper and microfichereports.

Minnesota's experience establishes that a separatestand-alone computer controlled by the Medicaidagency is not mandatory for MMIS processing. How-ever, it does illustrate the need for active facility


planning and organizing, and careful schedulingwith a State's information system department.

Borrowed programs in nonstandard computer lan-guages. Transferred MMIS system components mayrequire conversion of hardware-specific shortcutstaken in what is ostensibly American NationalStandards Institute COBOL. Transferred compo-nents may be tied to proprietary data base software,which must be purchased if new file interfaces arenot to be developed.

Borrowed computer programs which do not matchtheir documentation. Program people and systemsanalysts should be alert during the implementationof a transferred system that the computer code foredits, file organizations, and decision trees may nolonger match the narrative documentation.

Optically scanned vendor invoices. If optical scan-ning of invoices is used for data entry, providers ofhealth services need to know how they must typeand handle their invoices. (They will also need anexplanation of how their claims will be paid morequickly through use of OCR technology.) A multi-font OCR device itself will need fine tuning of itscharacter screens to assure that it can read all com-mon typewriter and line printer fonts used on theinvoices.

Data display media. Users of computer outputsshould receive data in intelligible formats in a me-dium suitable to their use. Random lookups inlarge, frequently updated data sets are easiest to dousing on-line video terminal inquiry or face indexedCOM (computer output to microform) microfiche.Proof lists, management data, and error resolutionforms should be on paper so that notes and com-putations can be written on them. Reports of anaudit trail character or of other possible historicalinterest should be reduced to microfilm or micro-fiche for permanent storage, regardless of how theprime user's copies were produced.

Provider and service bureau computer limitations.If providers rely on their own or service bureaus'computer systems for billing or accounting services,the computer systems create a need for additionallead time for providers to respond to new Staterequirements.

ConclusionsThis discussion of Minnesota's experiences has high-lighted a number of concerns for other States plan-ning to implement the model Medicaid Manage-

ment Information System. Some infortuitous deci-sions and problems have been touched on whichMinnesota could have avoided with the hindsightof today. On the whole, however, we believe thatthe Minnesota project was effective. The final prod-uct has proved acceptable and is well on its way tobecoming a true management information systemfor Minnesota's Medicaid program.Attempting to consolidate our recollections regard-

ing critical issues was difficult. Attempting to sum-marize them further is perhaps a disservice, becausethe preceding discussion is but the tip of the ice-berg; many underlying observations and empiricalfacts could usefully be explored. Nonetheless, at therisk of oversimplification, some general conclusionsand recommendations are in order.

States beginning an MMIS project should activelyseek available knowledge and expertise in the MMISarea. States beginning today have an advantage inthat Federal guidelines for system design are nowavailable, and their interpretation is clearer thanduring Minnesota's project. Federal staff who haveworked on State site audits have clarified their in-terpretations of the design requirements and areavailable for advice. Other States have been throughthe development experience and can provide in-sight, some of which has been documented in thispaper.

It should be recognized that the MMIS (or at leastsome of the subsystems) may lend itself to a systemtransfer effort, noting on the one hand the benefitsof available structure and savings of time and moneyinherent in such transfers, and on the other hand,the risks of policy, code structure, and hardwareincompatibility, the dependencies on other organi-zations, and the behavioral complications of suchprojects. Transfer processes themselves must be care-fully structured to insure successful implementa-tion. Cost differences should be explored thoroughly.An evolutionary development of the system should

be planned. The target should be clear before begin-ning, but an attempt to proceed intractably downa prescribed path to the final product will com-promise the results. The business of project man-agement is to firm up requirements' analyses andsystems' designs to the best possible state at anygiven time, leaving appropriate ffexibility and logi-cal hooks for enhancement where necessitated byorganizational needs. The development of informa-tion systems is a learning process-for managers indefining their goals, for both management and sys-tems analysts in deciding the kinds of informationneeded to support management decision making and


operational control, and for systems designers andprogramers in learning how best to capture andmanipulate data with accuracy, flexibility, andeconomy.

Structured participation of key individuals andorganizations at strategic points in the developmentprocess is imperative; unstructured participationcan be more of a hindrance than a help. Partici-pants must be carefully selected and they shouldinclude persons who are knowledgeable about opera-tional needs and who can understand policies andprocedures within affected organizations.

Early and adequate communications with pro-viders, other agencies, and other organizational unitswithin the parent organization are critical. Whatparticipants feel must be noted as well as what theycan document, since inarticulate feelings are oftenclues to information needed for successful implemen-tation.One of the strengths of the Minnesota project

was structured participation. One of its shortcom-ings was that it did not push structured participa-tion further than it did.In an MMIS project, the organization itself must

evolve. Information flows, informal communicationand authority structures, formal responsibilities, andbasic functioning of the organization will be affected

by the development and the ongoing new opera-tions. The process of organizational change musteffect an orderly, informed transition. When orga-nizational growth is necessary, skill requirementsand staff resources to meet those requirements mustbe carefully examined. Staffing by the "good per-son" approach without due consideration of theskills required can cause delay, error, and loss oforganizational rapport, and it can bring about otherproblems associated with replacement of poor choicesof personnel.The design process must be policy driven. Policies

should not be decided by bouncing them off thedesign, nor should they be locked up in advanceof the design. Rather the definition and documenta-tion of policies, as well as assessments of their flexi-bility, must be a continuous part of the design proc-ess. Legislation must be planned for, and the timelags associated with the legislation must be antici-pated.While organizational and behavioral changes are

prominent issues in MMIS implementation, tech-nological change must also be managed. Changesin technology are easier to plan and assess thanorganizational changes, but failures of equipmentand software to meet expectations may cause delays,increased costs, and organizational problems.

Additional Information on the Medicaid Management Information System

Several publications useful to Medicaid proj-ect managers are available from the NationalTechnical Information Service (NTIS), Spring-field, Va. 22151. Request by NTIS numbers.

* Social and Rehabilitation Service, U.S. De-partment of Health, Education, and Welfare:Medicaid management information system.General systems design for title XIX. Ed. 2,Washington, D.C., December 1973, 5 volumes.PB 236-550, $37.

* Social and Rehabilitation Service, U.S. De-partment of Health, Education, and Welfare:Medicaid management information system.General installation guide for title XIX.Washington, D.C., June 1972. PB 210-742,$4.25.

* Social and Rehabilitation Service, U.S. De-partrnent of Health, Education, and Welfare:Model training program for implementing theMedicaid management information system.Washington, D.C., March 1973. PB 217-222,$5.75.

* Social and Rehabilitation Service, U.S. De-partment of Health, Education, and Welfare:S/UR operational techniques. Washington,D.C., February 1973. PB 216-158, $8.50.

* Social and Rehabilitation Service, U.S. De-partment of Health, Education, and Welfare:MARS operational techniques. Washington,D.C., spring 1974. PB 216-159, $7.25.


Documents

Implementing Medicaid Management Information System