Approach to Module Integration

Executive Summary

IDHW has selected a “Systems Integrator (SI) Advisory Services” approach to managing traditional MMIS SI functions. As detailed in the IDHW MMIS Modernization project charter, the SI Advisory vendor will be responsible for connecting all MMIS modules together into an enterprise system to realize the Department’s vision. The SI Advisory vendor will have technical governance oversight responsibilities and will be tasked with the oversight of the integration of business modules and the implementation of technical shared services.

The SI Advisory vendor is expected to perform two primary tasks:

• Develop a comprehensive framework for the technical aspects of the modernization effort, to include standardized design, development, integration, implementation, and operations of modules through defined governance, communication, integration, and data exchange methods
• Provide oversight of module vendors to manage and ensure adherence to the comprehensive technical framework

The SI Advisory vendor will utilize and enhance the InMP to govern all MMIS integration activities. Module vendors will in turn use the plan to develop their individual module integration plans. The plan should encompass the integration domains and related MMIS Modernization requirements to include:

• Business Integration Processes: Business integration supports inter-module business processes and workflows. The InMP will guide business owners as to how their functional areas will be impacted by integration across modules. Functional specifications will be produced that describe the business rules, test conditions, and development approach so that the owner can review and approve the design.
• Information Integration Processes: Information integration supports inter-module information flows. It will touch on delivery mechanism, format and scheduling standards and protocols. The IDHW Data Management Strategy Framework along with regulatory requirements should serve as the primary guide for MMIS modular data integration standards and overall approach.
• Technical Integration Processes: Technical integration speaks to the technical aspects of the modernization effort, to include standardized technical design, development, integration, implementation, and operations of modules through defined governance, communication,integration, and standards.

Encompassing the individual integration processes, the InMP provides a framework for MMIS legacy to modernization transition and integration planning by defining Integration standards and methodologies.

Module Integration Goals and Objectives

Module Integration will align and support overall MMIS Modernization project goals. MMIS Module Integration specifically entails promoting a standards-driven approach to governing interoperability across all modules.

Goals and objectives of MMIS module integration include:

• Goal 1: Forecast technical needs for system integration across MMIS modules in the most effective and efficient manner that promotes module interoperability and trust in department data.
  • Objective 1.1: Support IDHW in procuring new or identifying existing toolsets covering integration functionality planned to support module integration. This list is subject to further review and finalization by IDHW for inclusion into MMIS Modernization scope:
    • Application Programming Interface (API) Management
    • Centralized Rules Engine
    • Data Analysis and Reporting
    • Enterprise Service Bus (ESB) Management
    • Identity and Access Management/Single Sign On (SSO)
    • Master Data Management (MDM)
    • Operational Data Store (ODS)
    • Security Management
• Goal 2: Provide technical guidance and oversight to IDHW, sister bureaus, and MMIS vendors to implement technical services once the technical needs and strategies are finalized.
  • Objective 2.1: Apply relevant standards and schedule to manage the logistics of multiple toolset implementations, including those within the MMIS Integration platform, to ensure successful interoperability across all modules.
  • Objective 2.2: Assist IDHW and module vendors to address interoperability needs where no relevant standards yet exist.
• Goal 3: Provide technical guidance and oversight to ensure MMIS replacement modules are continuously integrated and aligned with legacy MMIS modules and IDHW technology
  • Objective 3.1: Maintain standards and schedule as MMIS modules promote product releases during implementation and ongoing maintenance.
• Goal 4: Develop strategic guidance on developing a service-oriented approach to integration and interoperability utilizing the anticipated State-wide ESB infrastructure and API development to foster data availability, integrity, and exchange.
  • Objective 4.1: Select specific approaches and communications technologies that will define a Service-Oriented Architecture (SOA) platform where MMIS Modernization modules will be interconnected via exposed APIs through a central ESB.

System Identification and Ownership

The MMIS, as an entity, performs many business processes, involving multiple and varied integration activities both internal and external to the Medicaid agency. The system owners will be the most knowledgeable about the business uses and needs for their modules. It will be important for the SI Advisory vendor to work closely with each system owner as they collaborate with vendors on module integration solutions. Table 2 identifies the IDHW section or business unit that is responsible for each current module, while Table 3 identifies the future modules and owners. As the procurements move forward, the information in Table 3 will need to be updated periodically.

Integration Management Strategy

The SI Advisory vendor will work with module vendors and the IDHW MMIS project team to develop a module integration strategy that will define integration standards and governance process details in an incremental implementation roadmap for MMIS modules. It will also enable the tactical integration of new modules and trading partners, following a defined process.

Integration Management Strategy Components

• Module Integration Governance: The InMP will document governance over the technical direction of the MMIS modernization solution and integration effort through establishing application architecture system boundaries and integration architecture standards.
• Vendor Onboarding: The InMP will include a subsection for Vendor Onboarding and Communications Planning. Each module vendor will be educated by the SI as to the MMIS modernization project technical standards and Software Development Life Cycle (SDLC) approach. Specifics of module vendor onboarding are provided below in Section ### .1 Vendor Onboarding Planning.
• Module Implementation Sequencing: In alignment with the MMIS Strategic Procurement Plan, the InMP will coordinate the logistics of system implementations and the overall integration of technical solutions, modules, testing, and system certification schedules.
• Module Integration SDLC Planning: The InMP will be in concordance with MMIS PMO plans to detail processes around Change Management, Release Management, Integration Testing, and Test Data Management. The InMP will detail strategic and, more importantly, logistical considerations for MMIS modernization development lifecycles. Examples include data conversion release schedules and the resulting data sharing process and module integration testing timeframe.
• Legacy MMIS Module sunsetting: The InMP will detail steps for legacy MMIS module sunsetting, including potential parallel production “run” periods between legacy and replacement modules, legacy module freeze (i.e., system change) windows, and contractual compliance for legacy module retirement.
• Operations Impact Analysis: Leveraging MMIS procurement deliverables such as the Concept of Operations (ConOps) and the MMIS Risk Management Plan (RMP), the InMP will document known assumptions, risks, and constraints to ongoing IDHW business operations The analysis will detail replacement module implementation impact to current IDHW business functions, including prospective changes to business processes post-module implementation, potential choke points in resource commitments across module cutover timeframes, and operational module interoperability.

Vendor Onboarding Planning

As individual MMIS module implementations commence, new vendors and/or module contractors will require specific onboarding, which will require that their communications needs be analyzed and documented. The SI vendor is expected to drive the onboarding process in collaboration with the MMIS PMO team and IDHW, aligning their communications planning with overarching MMIS Project communication standards.

Vendor onboarding will be guided by MMIS project timelines documented in the IDHW MMIS Project Charter. (Note: The timeframes in the charter are projections and may change based on project funding and/or scope change.) Primary vendor onboarding activities are documented in the MMIS Vendor Onboarding Management Plan (VOMP). These include activities associated with the staff onboarding, introduction to project management tools, various system resources and required regulatory and security training. These activities will be driven by the MMIS PMO team. SI Advisory vendor responsibilities for onboarding will be to orient vendors to MMIS integration technical standards and methodologies as described in Section 3 Module Integration Standards and Methodology. Specific activities may include the following identified in Table 4.

Vendor Communications Planning

The MMIS Communication Management Plan (CMP) will be the guiding document for establishing clear, concise, timely and accurate communication processes and procedures for all MMIS modernization vendors. The SI Advisory vendor is expected to include module vendors, the State (identified stakeholders), PMO, and EQC in all meeting invitations and email communications related to module integration. The SI Advisory vendor and module vendors will be required to collaborate with each other as they manage the broad scope of project integration requirements.

Module Integration Activities

The InMP will detail required activities to ensure module implementations are well-coordinated and aligned to overall MMIS Modernization project goals and objectives. The plan will be designed to minimize and mitigate the inherent risks associated with large scale MMIS modular implementation. The activities include:

Table 5

Module Integration Standards and Methodology

Medicaid Statutes and Regulatory Standards – Health Information and Exchange

Federal statutory provisions governing the management and sharing of health information by covered entities have advanced to cover key aspects of data availability privacy and security. The SI Advisory vendor will be expected to understand, promulgate, and monitor adherence to regulatory standards by module vendors in concordance with IDHW policies. Primary standards for consideration are detailed in the following sections.

MITA Framework Standards

The SI Advisory vendor will ensure cross module alignment with the current Medicaid Information Technology Architecture (MITA) framework. Born out of the 2009 American Recovery and Reinvestment Act (ARRA), MITA promotes “…business, information and technology architectures that provide an overall framework for interoperability, as well as processes and planning guidelines for enabling State Medicaid enterprises to meet common objectives within the framework while supporting unique local needs.” The MITA framework promotes the procurement and implementation of Commercial Off-The-Shelf (COTS) packages (or SaaS), and the sharing, leveraging, and reuse of Medicaid technologies and systems.

HIPAA and Administrative Simplification Standards

The SI Advisory vendor will be prepared to document and monitor compliance with HIPAA standards applicable to all MMIS integration and interoperability functions. A provision of the HIPAA act, Administrative Simplification …” mandates that the U.S. Department of Health and Human Services (HHS) adopt standards to streamline communications between health care providers and health plans”. HHS in turn has deemed health plans, health care clearinghouses and health care providers as covered entities under HIPAA and follow-on interoperability regulations promulgated under the Patient Protection and ACA. As a covered entity, IDHW requires all contracted business associates to be HIPPA and ACA compliant.

HHS has adopted four types of standards to make electronic communications more efficient:

• Transactions: Pharmacy and health care administrative information, including claims
• Code sets: Classifies clinical diagnoses and procedures
• Unique identifiers: For providers and employers
• Operating rules: Business rules supporting the standard transactions

Transactions

Under HIPAA, HHS adopted certain standard transactions for the electronic exchange of health care data. Covered entities who conduct any of these transactions electronically must use an adopted standard from ASC X12N or National Council for Prescription Drug Program (NCPDP) (for certain pharmacy transactions). Module vendors will utilize HIPAA standard transactions as part of submitting, processing, and paying claims; integrating health plan eligibility; managing coordination of benefits and other information. The transport of the core set of HIPAA transactions including claims and encounters (837), eligibility inquiries (270), claim status (276), enrollments (834), authorizations (278), premiums (820), and payments (835), as well as corresponding HIPAA standard responses including TA1, 999, 271, 277, 277CA, 820, and 834.

Code Sets

Under HIPAA, HHS adopted specific code sets for diagnoses and procedures used in all transactions. Code sets outlined in HIPAA regulations include:

• International Classification of Diseases, (ICD)
• Health Care Common Procedure Coding System (HCPCS)
• Current Procedure Terminology (CPT)
• Code on Dental Procedures and Nomenclature (CDT)
• National Drug Codes (NDC)

Unique Identifiers

HIPAA establishes and requires unique identifiers for:

• Employer Identification Number (EIN) is issued by the Internal Revenue Service and is used to identify employers in electronic transactions.
• National Provider Identifier (NPI) is a unique 10-digit number used to identify health care providers. NPIs and EINs must be used on all HIPAA transactions.

Operating Rules

Under ACA, operating rules are defined as “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications.” Operating rules set certain requirements for transactions that are covered by HIPAA. They specify the information that must be included when conducting standard transactions. The Council for Affordable

Quality Healthcare Committee on Operating Rules for Information Exchange (CAQH CORE) is the authoring entity of the operating rules currently adopted by HHS.

21st Century Cures Act – Interoperability and Patient Access

The 21st Century Cures Act’s (Cures Act) and the subsequent final rules related to interoperability and burden reduction focuses on driving interoperability and patient access to make data freely available to patients leveraging CMS regulatory authority. CMS Interoperability and Patient Access Final Rule (CMS9115-F) details requirements Medicaid, Children’s Health Insurance Plan (CHIP) and Qualified Health Plan (QHP) health plan sponsors must meet. This includes the following:

• Implement and maintain a standards-based Patient Access API
• Payer to Payer Data Exchange - Coordinate care between payers by exchanging, at a minimum, the information contained in the United States Core Data for Interoperability (USCDI)
• Make standardized information about provider networks available via a Fast Healthcare Interoperability Resources (FHIR®) based Provider Directory API
• Improve the Dual Eligible Experience
• Comply with the Office of the National Coordinator (ONC) for Health Information Technology (HIT) 21st Century Cures Act final rule

The SI Advisory vendor will ensure cross module alignment with Cures Act standards and promote the use of open access APIs, specifically adherence to Health Level 7 (HL7®) FHIR® standard and relevant technical standards. Guidance and compliance details are available in a guidance letter to State Health Officials, SHO # 20-003 Implementation of the CMS Interoperability and Patient Access Final Rule and Compliance with the ONC 21st Century Cures Act Final Rule.

Business Process Requirements

The MMIS performs many business processes, involving multiple and varied data exchanges both internal and external to the Medicaid agency, as well as supporting many system users. To ensure that the integration needs of the system are well-understood, it will be expected of each vendor for the new MMIS modules to detail the:

• Business processes their module will support
• Parties served by the process, including whether they are internal or external
• Data type and sensitivity level included in the process
• Data delivery method

For the purposes of the first iteration of the InMP, this section also provides some high-level context on the current business process flows, modules involved, and data used. IDHW’s current MMIS is comprised of multiple modules. These modules operate as a cohesive MMIS claims solution, along with a separate EDW and PBA.

Using the MITA structure, the current MMIS business processes have been detailed in business flows which can be located on the IDHW SharePoint site at this location: https://idhw.sharepoint.com/sites/MedicaidEPP/Shared%20Documents/Business%20Process%20Information Table 8 lists, at a high-level, the current business process in question, the current MMIS module(s) that are part of the process, and the data categories used in the business process.

Beyond specific MITA business processes, the SI Advisory vendor shall provide integration guidance and leadership to IDHW and module vendors, which includes managing project business requirements impacted by data and application integration across modules. Key business requirement categories requiring integration governance and controls include:

• Operational Reporting: Designated MMIS Modules must maintain and deliver reports and data visualizations (i.e., dashboards) supporting business functions across all categories of Medicaid data. Module reporting solutions should provide the capability to run pre-defined, scheduled reports, and ad hoc queries.
• Federal Reporting: Designated MMIS modules must meet CMS reporting guidelines, requirements, and periodicity. Any new federal reporting requirements must be accommodated.
• Business Rules Engine: Designated MMIS modules shall implement Business Rules Engines (BRE) with the ability to create, configure, and maintain rules for business functions.
• Data Conversion and Migration: Designated MMIS Modules shall identify all data elements and sources of data that must be converted or migrated to support all MMIS processes and to meet all functional specifications.
• Data Management and Governance: MMIS Modernization vendors will adhere to a comprehensive data management strategy that will support integration, optimization, quality, stewardship, standards, and governance of data.
• Interface Management: MMIS Modernization vendors will support the exchange of data between the system and the systems with which it interfaces (including external entities) to facilitate business functions that meet the requirements of Department policy, and federal and State rules and regulations.

The SI Advisory vendor will work proactively and collaboratively with the MMIS Modernization Project team to bring multiple agencies and module vendors together to develop and implement a comprehensive integration strategy in support of project business requirements.

Information Process Requirements

The SI Advisory vendor will collaborate with all IDHW enterprise vendors and solutions to accurately collect, process, and distribute applicable interface data/transactions. Module Integration and interoperability solution strategies will be evaluated for use in integration planning for the MMIS

Modernization Project with the SI Advisory vendor recommending final approaches to IDHW for review and approval.

Among the primary acts of governance is assuring information process standards are adhered to throughout the MMIS Modernization project lifecycle. High level information process standards have been referenced in sections ### HIPAA and Administrative Simplification Standards and ### 21st Century Cures Act – Interoperability and Patient Access and provide a starting point for understanding planned information process standards for module integration. The Standards and Implementation Specifications, Section 3004 Of the Public Health Service Act, 45 CFR Part 170, Subpart B have been adopted by ONC detailing the systems integration standards for sponsoring health plans. The information processing aspects of the standards are summarized below:

Table 9

Synchronous Data Exchanges

The SI Advisory vendor will collaborate on solution design and standards with MMIS Modernization vendors on requirements for synchronous (real-time) data exchanges. Synchronous exchanges require an executing process in the source system to wait for confirmation from the receiving system prior to executing the next sequenced activity. Note: At this time, it is not anticipated that literal, real-time data synchronization between modules will be an MMIS Modernization project requirement.

Asynchronous Data Exchanges

The SI Advisory vendor will collaborate on solution design and standards with MMIS Modernization vendors on requirements for asynchronous (near real-time) data exchanges. Asynchronous exchanges do not require an executing process in the source system to wait for confirmation from the receiving system prior to executing the next sequenced activity. Data is usually processed and delivered out of a triggering event in the source system of record. This type of transaction is most often facilitated through an ESB.

Batch Data Exchanges

The SI Advisory vendor will collaborate on solution design and standards with MMIS Modernization vendors on requirements for batch data exchanges. Batch transfer solutions imply collections of data, usually extracted into delimited text files, that are periodically scheduled via file transfer protocol (FTP) software. Manual, ad-hoc requests for files can be accommodated through most FTP solutions. Data in “batch mode” represents the full data set at the given point in time, also referred to as a snapshot. Batch mode processing can also capture only data that has been changed since the last extract, also referred to as the delta.

Technical Requirements

The SI Advisory vendor will provide technical integration assistance that shall include collaboration with IDHW to coordinate multiple technical efforts on the various MMIS Modernization modules. The SI will serve as a technical liaison between module vendors, the PMO, IDHW, and other State Agencies to ensure the technical approach is architected and agreed upon and that technical decisions, risks, and issues are processed through closure or resolution within agreed-upon timelines. The vendor shall provide a single point of contact for overseeing all technical governance activities related to the integration of systems/solutions. Among the primary acts of governance is assuring information standards are adhered to throughout the MMIS Modernization project lifecycle. High level technical standards have been referenced in sections (link here) HIPAA and Administrative Simplification Standards and (link here) 21st Century Cures Act – Interoperability and Patient Access and provide a starting point for understanding planned technical standards for module integration. The Standards and Implementation Specifications, Section 3004 Of The Public Health Service Act, 45 CFR Part 170, Subpart B has been adopted by (ONC) detailing the breadth of systems integration standards for sponsoring health plans. The technical aspects of the standards are summarized below:

• Transport Standards and Other Protocols
  • ONC Secure Health Transport Statement
  • ONC XDR and XDM Direct Messaging Specifications
  • ONC Transport and security specifications
  • ONC Direct Edge Protocols Implementation Guide
  • ONC Delivery Notification Implementation Guide
• Functional Standards
  • Accessibility: Web Content Accessibility Guidelines (WCAG) ##
  • HL7 Version 3 Standard: Context Aware Retrieval Application functionality
• Standards For HIT to Protect Electronic Health Information Created, Maintained, And Exchanged
  • Encryption and decryption of electronic health information
  • Hashing of electronic health information
  • Record treatment, payment, and health care operations disclosures
  • Record actions related to electronic health information, audit log status and encryption of end user devices.
  • Encryption and hashing of electronic health information
  • Synchronized clocks
  • Audit log content
• Application Programming Interface Standards
  • HL7® FHIR® standard and implementation specifications
  • OpenID Connect Core standard

American with Disabilities Act Compliance Requirements – Section 508 Standards

The SI Advisory vendor will collaborate with IDHW and the PMO team to ensure module vendor solutions comply with all sections of the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act. Creation and maintenance of a MMIS Modernization 508 compliance checklist for Web Sites, Web applications and Software compliance should be the responsibility of the SI Advisory vendor and should be utilized throughout the project lifecycle, including CMS certifications activities. A checklist template for 508 compliance is available from the Department of Health and Human Services.

MMIS Modernization System Performance and Scaling Requirements

The SI Advisory vendor will ensure that module vendors provide the ability to integrate and maintain large amounts of data sets from internal and external sources with minimal technical issues affecting system performance. The SI will work with IDHW, the PMO team and each module vendor to determine data consumption expectations and document them in the InMP. The SI will also validate module vendors ability to provide a solution architecture supporting vertical and/or horizontal infrastructure and application scaling as it applies to the requirements of system integration.

As part of Operational Readiness, the SI will gather and confirm integration test results demonstrating that module solutions meet all Service Level Agreements for system performance and application scaling as defined in the scope of work.