Private Sector Technology Group--White Papers

All MMIS systems are different, but most of the systems in use today are based on a handful of original models that have been cloned and moved from state to state. Some state systems fall into the homegrown category, many fall into the legacy category, and a few are based upon newer models including client/server MMIS and mainframe MMIS that use RDBMS. The primary architectural features that differentiate MMIS are:

It will facilitate the process of measuring the impact of HIPAA if we can identify the characteristics of systems most affected by the new standards. By identifying the relationship between HIPAA requirements and specific system characteristics, we can leverage similarities in various state systems to avoid duplicating the efforts of assessment and consideration of implementation alternatives.

For example, one characteristic that varies across MMIS is whether the system supports line-item adjudication or document adjudication or whether the system supports a fixed or variable length record. Some systems use a hybrid model that does both. Another system characteristic that varies is whether identifiers include embedded intelligence. For example, a state’s provider identifier may include intelligence that tells the MMIS the provider’s type or location. Other MMIS use separate fields to designate provider type or group affiliation. It may be more problematic to make HIPAA changes to MMIS systems that rely on "smart" provider IDs. In fact, some of these systems may have to be totally redesigned or replaced.

Another variation is that some MMIS systems may be designed to process all claims for a given claim type before processing any other claim type while others may be able to intermix claim types. Certain very large volume MMIS systems were set up to partially process a portion of all daily claims by provider ID, then partially process another portion of all daily claims by recipient ID, and then merge the results together for final processing.

The next section of this paper suggests characteristics of MMIS systems that can be used to classify MMIS systems by analyzing their structure and dividing them into a handful of model designs. Certain model designs require a greater level of effort than others to achieve HIPAA compliance. We hope the analysis presented here will help guide HCFA and the states in assessing probable impact nationally and prioritizing corrective action efforts.

This section identifies the components of the MMIS system most susceptible to changes required by HIPAA. This analysis assumes that the state has not yet determined its approach to achieving compliance and therefore illustrates the impact of HIPAA requirements on the current MMIS. Modifying the current MMIS would require significant changes. The state could opt to use translators for strategic input and output functions, or replace the MMIS altogether, or enter into cooperative arrangements with providers and clearinghouses, or use a combination of strategies. These strategies will be discussed in more detail in the compliance section of this document.

In addition to characteristics of a system’s architecture, timing of implementing HIPAA standards is a separate variable that can increase the impact on the Medicaid operation. Medicare claims processing operations may be HIPAA compliant sooner than Medicaid, necessitating bridge and conversion strategies to accommodate HIPAA-compliant crossover claims in a non-compliant Medicaid environment. A similar situation occurred during Y2K conversions, but the impact due to HIPAA is much greater because code conversions and crosswalks are involved. The effect of timing is also evident in the case where a state begins implementing HIPAA EDI standard formats while waiting for solutions to compensate for lack of local codes associated with current business practices. This could require states to maintain burdensome workarounds while waiting for requested special codes to be approved. Another timing factor is the ever-changing implementation dates for the rules. It will be difficult for states to manage a staggered series of implementation dates. Configuration management and change control procedures will be challenged to manage implementation of X 12 electronic format standards first, followed by the new NPI.

This paper focuses on MMIS system impact only. A second paper addresses changes required to the Medicaid business processes. In the following table, the columns represent:

MMIS Characteristic	Issues/Implications	Areas of Impact	Sizing Factors
Provider ID	Systems using an intelligent ID will need to be modified to accommodate the intelligence-free NPI. States will need to crosswalk current ID with NPI. This may be more complicated in states that currently require providers to use different IDs for different purposes (e.g. to capture location of service, provider type, etc.)	Edit and audit logic tied to the indicators in the intelligent provider ID< Logic tied to provider type and specialty All standard reporting: MARS, SURS, and financials 1099 processing Interfaces with administrative services and the IRS Pricing/rates may be tied to specific provider ID, provider type, or provider location Ability to associate Prior Authorizations with correct provider, at specific location	# processes using provider ID # tables using provider ID # processes dependant on intelligence in provider ID # technical workarounds required to support affected processes Estimate of number of rejected claims due to bad provider ID
Eligible Providers	1. NPI may not identify providers at the same granular level as current Medicaid provider Ids. NPIs in some areas will be more detailed than current ID numbers while less detailed in other areas. Some examples:	If NPIs and state Medicaid provider IDs are specified at different levels, then it may not be possible to do a one‑to‑one crosswalk between old/new IDs. States may have to re‑enroll their entire provider base using the NPI, convert history, and change other processes. Some examples:	# new provider types (e.g., transportation drivers, pharmacists) # providers excluded from enumeration # processes affected
	Some states allow residents and or interns to prescribe and they are assigned provider numbers. Different cost centers and locations of a major hospital enterprise probably won't be identified in the same way as Medicaid does now. Some states reimburse Physician Assistants and Midwives. States pay taxi cab companies but not taxi drivers. There is talk of enumerating pharmacists. States recognize providers of care outside of the traditional medical community, e.g., homemakers, drivers, family care givers	Payment rules must be developed for individual providers who are not eligible for enumeration Develop separate provider enrollment process for non-enumerated providers? Expand provider database if non-Medicaid providers, e.g., pharmacists, are added to the enumeration list. Unless paper submitters are enumerated, a state could not re-enroll their entire provider base using NPI. The major consideration is whether states can accurately crosswalk both to state ID from NPI and to NPI from state ID. If that crosswalk can be accomplished, there is no big hurdle to compliance; if not, complying with NPI will be a great challenge.
Length Of Provider ID	The NPI will likely be 10-digits, requiring most states to expand this field.	Storage issues are the biggest concern, as well as changing the lengths of data elements in files or tables Expanding the provider ID field is similar to expanding the date field for Y2K, i.e., a major effort.	# processes using ID
Health Plan ID	Applies to MCOs and the state Medicaid Agency. States identify both the MCO and the contract (one MCO can have more than one contract).	Could require expansion of current fields used to identify the MCO. Changes might be required to identify individual contracts. Need to research implication of Medicaid Agency as a Health Plan.	# of MCOs # of MCO contracts
Enumeration	If the Medicaid agency is responsible for some enumeration, new business processes and systems need to be created.	Provider enrollment Provider certification Provider training	Depends on role of State in the enumeration process
Line Item vs. Claim Adjudication	Some legacy systems are based on a claim document, while others are line item based, and others still are hybrids. More research is needed to understand the impact of HIPAA on this MMIS characteristic.	Additional data will be stored with every transaction whether processing is done by line or claim; capacity is the issue. Line-level systems will be affected more, unless it is a RDBMS design and header data is repeated Line item vs claim document is an administrative claiming issue (contractual payment) not a HIPAA issue.
Encounter Data	States have come up with various formats and different data requirements for encounter data submission. MMIS’ that currently accept encounter data in an X12 format will be less affected than those that currently use a different format.	Encounter data processing in general	# of MCOs Measure of the difference between HIPAA standard format and the state’s current requirements for MCOs
Standard Codes	Data exchange partners must use and only use the Standard Code Set. Some states may still use a truncated (9-digit) NDC code; this is not compliant Standard code sets identified do not include mental health DSM codes Some codes (e.g. EOB codes) are maintained in the X12 implementation guides, while others are maintained by standard development organizations (SDO). Changes to code sets maintained by different organizations may not be coordinated. Some national code lists must be purchased from a SDO.	Some states will have to revise medical policy, reissue provider manuals, train providers States need to be able to capture, reimburse, and report on all services< Some states will need to expand procedure/service fields to accommodate the standard code for certain services	# of codes that will need to be converted to the Standard # of providers affected # of processes affected # of tables affected Estimate of number of rejected claims due to bad codes
Local Codes	The more local codes a state uses, and the greater the percentage of claims that are adjudicated with local codes, the more policy and business decisions will have to be made (and the more complicated the process) in order to develop alternative methodologies to get the claims paid correctly. In many cases, state statutes will require modification. There could be major dissatisfaction in the provider community. HCPCS “J” codes are frequently used by states and are expanded to accommodate Medicaid-specific services. States that have local code-based logic hard-coded in their MMIS will need to modify this.	Need to review of all edits, audits, and some pricing logic. Will affect reporting (especially waivers and other special programs) and prior authorizations. May require policy changes and business process changes; may require legislative action. May affect annual automated code update processes (e.g., CPT, ADA, NDC, and compound drugs) especially when a Standard code is exploded and overlaps a local code.	# of local codes # of providers using local codes< # of processes affected # of tables affected # claim lines submitted with local codes # remittance advices # claim status inquiries # prior authorizations # of workarounds required to pay providers for services outside the Standard code set Complexity of the workarounds Estimate of number of rejected claims due to bad codes
Historical Data	HIPAA does not require historical data to be converted to the new standard formats. States may need to convert historical data anyway for service limits, duplicate checking, other logical edits performed during adjudication involving history, reporting or other purposes.	Need converted data for TPL recoveries, fraud investigations, claim adjustments, auditing, and consistency of reporting and trend analysis. Knowledge management systems demand consistent history. Historical editing during claims adjudication If the state does not convert history to HIPAA requirements, it will need a contingency plan to support historical research.	# of historical data records to convert Complexity of change required Amount of expansion required to record length< Estimate of number of rejected claims due to bad codes Number of historical edits to revise
Provider Software	States that provide software to providers will need to upgrade software and train providers. Provider software today uses either proprietary formats or NSF/UB92 formats. Under HIPAA, these formats may not be submitted directly to Medicaid. The software must be changed to an X12 format, or the provider must send claims through a clearinghouse.	State provided software will have to be upgraded to meet the changed requirements Software will have to be distributed to all providers. Change remote access software as needed. State will have to test and approve all third party billers and independent provider software for HIPAA compliance.	# of providers using state-supplied software
Use of Translators	States that currently use a front-end translator may be able to modify the translator as part of a HIPAA compliance strategy.	Translators require maintenance Eventually the system will have to be upgraded with all attendant costs; may require extra processing especially for conversion	# of translators used # of conversions handled by the translator
Number Of Independent System Components	The greater the number of independent system components, the greater the level of effort required to modify and integrate them. Some examples of independent components include: POS systems DSS/Data warehousing systems Eligibility verification and other types of eligibility systems Enrollment Broker systems Drug Rebate systems< Standalone SURS Prior authorization systems< County or local operated health systems Carve-out systems (e.g., dental services, mental health) Third Party Liability systems	Must test interfaces and perform reconciliation and error correction with all systems exchanging data governed by HIPAA	# of interfaces where data are exchanged # of transactions involved # of different contractors Complexity of the End-to-End Testing Plan
Electronic Submission Standards	It is estimated that currently fewer than 3% of Medicaid providers submit claims using the X-12N envelope. This means a large scale effort for both the provider and the health plan. Even if a clearinghouse is used, states will need to undertake a major End-to-End testing plan. ANSI X12 mandates certain data elements on the claim (and probably other transactions) that MMIS does not use. These data elements must be passed back to the provider on the remittance advice and to certain third parties, e.g., code indicating the patient's relationship to the insured for TPL recoveries. Some states currently use NCPDP for pharmacy claims, but some do not. Some states do not have online claims adjudication. In addition, many states do not support the NCPDP format for batch claim submissions.	Electronic submission requirements Processes requiring retooling to the X-12N and HL7 States will need to either a) rewrite their MMIS to accommodate these extraneous data elements, or b) strip off and store these data elements when a transaction first enters the system, then re-attach on the outbound side, or c) use a clearinghouse to accomplish the same thing. Note that clearinghouses have to be under contract to the state and the state will pay all charges associated with these designated clearinghouses. This could be a major new expense for states (and 75% FFP?).	# of formats which must be changed # of providers and clearinghouses involved in End-to-End testing with the state # of programs affected
Security	All MMIS systems have security processes, but HIPAA may require more.	May have to re-engineer the security processes Retrain staff	Estimate of degree of compliance of current system with HIPAA standards
Electronic Signatures	If there are differences between the state’s requirements for the electronic signature and HIPAA requirements, change may be required	Could require change to current processes Current require change to legislation implementing electronic signature process	# of HIPAA transaction types with electronic signature< # of transactions processed with electronic signature
System Certification	HIPAA compliance may be a requirement for future MMIS certification
Client/Server MMIS Models	Special considerations for Client/Server model MMIS:	May be easier to modify and test?
Multiple Contractor MMIS Models	Special considerations for multiple contractor MMIS models, e.g., Texas:	Greater effort required in planning, End-to-End testing	# of data exchange contracts
Electronic Transaction Types	Most MMIS today are moving toward more electronic data exchanges. Most states already support electronic claims, encounters, enrollment and disenrollment, eligibility inquiry, payment and remittances, claim status inquiry, referrals and authorization. Only lacking claim attachments and first report of injury.	All of these transaction types must meet HIPAA standards. Some change is required for all.	# of electronic transactions by type
Privacy	To be developed, but see SURS below
SURS	Privacy requirements may require SURS to develop new processes for disclosure, consent, and tracking of this information. For example, states could be required to maintain detailed audit trails of every conceivable transaction, case tracking and correspondence systems for consumers who've requested access to their medical records, dispute resolution procedures and cost of hearings and appeals. Also problematic is the requirement that Medicare and Medicaid use the same unique NPI in identifying potential fraud cases when exchanging information with each other. This implies that history and internal formats must be converted to NPI.	Historic data (if not converted) Process for auditing medical records Case tracking procedures and documentation of cases Tracking of consumer consent for access to records	# of SURS cases Amount of history to convert Difficulty of converting or implementing appropriate consent tracking and case tracking
Paper Claims	States may wish to issue policy that changes code sets for submission of paper claims to conform to HIPAA code sets, or States could design crosswalks between “legacy” code sets and HIPAA code sets, or States could design logic that allows claims editing and comparison between/among multiple code sets for the same data element.

By comparing notes on assessments, requirements analysis, and alternative strategies for implementing HIPAA standards, states will be able to help each other in planning, sizing, and selecting the best solutions.

A separate paper, Approaches to HIPAA Compliance, addresses the impact of HIPAA on the Medicaid business operations and different implementation strategies.

OVERVIEW OF ARCHITECTURAL DIFFERENCES IN MEDICAID MANAGEMENT INFORMATION SYSTEMS (MMIS) SYSTEMS

MMIS Characteristic

Issues/Implications

Areas of Impact

Sizing Factors