Medicaid Program: Mechanized Claims Processing and Information Retrieval Systems. Comments Regarding Proposed Rule: CMS-2392-P

Transcription

1 Medicaid Program: Mechanized Claims Processing and Information Retrieval Systems Comments Regarding Proposed Rule: CMS-2392-P Due June 15, 2015

2 Table of Contents I. Introduction and General Comments... 1 II. Comments on Proposed Rule Provisions for 42 CFR Chapter IV Authority Basis, purpose, and applicability Definitions Proposed definitions from the NPRM Additional terms and definitions FFP for design, development, installation or enhancement of mechanized claims processing and information retrieval systems FFP for operation of mechanized claims processing and information retrieval systems Conditions for reapproval; notice of decision Procedures for reduction of FFP after reapproval review III. 45 CFR Part Authority Prior approval condition IV. Additional Discussions of Proposed Technical Changes Technical Changes to 42 CFR Part 433, Subpart C Technical Changes to 42 CFR Part 433, Subpart C modular certification, sub-regulatory guidance, open source and COTS, and reuse Certifying MMIS modules rather the system: To remove barriers to entry for smaller IT vendors, increase the availability of certified modules in market, and create incentive for modular IT architecture and procurement approach Modules for certification before installation: What is the impact on enhanced FFP for maintenance and operations? Sub-regulatory guidance: MMIS module definitions and modular certification process Open source vs. proprietary COTS: Effective and efficient balance for use of enhanced FFP to acquire open source vs. proprietary COTS software and IT technology solutions Page i

3 1.5 Reuse - innovative ways for CMS and states to share and reuse IT solutions and so ensure appropriate marketplace incentives for best quality and value in IT solutions and services for Medicaid New MMIS - is to provide more efficient, economical, and effective administration of the state plan ( (b)(1)) To provide more efficient, economical, and effective administration of the state plan ( (b)(1)) - performance metrics to realize this requirement? State Medicaid Manual, Part To improve customer service and support the dynamic nature of Medicaid eligibility, enrollment, and delivery systems V. Conclusion Appendix 1: Glossary of Acronyms Appendix 2: US Digital Services Playbook Default to Open Appendix 3: Contributors PSTG Modularity Committee Page ii

4 I. Introduction and General Comments The Private Sector Technology Group (PSTG) appreciates the opportunity to provide input and comments on the Centers for Medicare & Medicaid Services (CMS) proposed rule CMS-2392-P in the Notice of Proposed Rule Making (NPRM). PSTG viewed this comment period as a call to action for its members to work in concert with CMS to help set a new path for the Medicaid Health Information Enterprise consistent with the goals of Medicaid Information Technology Architecture (MITA). We applaud CMS efforts to create an environment of collaboration and mutual support, and have approached this opportunity with the importance and urgency it deserves. PSTG is a broad-based group of information technology companies and professionals providing solutions in the health information systems environment. This group s talents and expertise range from system design consulting to program operations. PSTG activities are based on collaboration and a leave your logo at the door approach to healthcare system discussions with state and federal partners. PSTG actively pursues opportunities to provide technical and policy suggestions on matters of significance to the healthcare system in the United States. The comments provided herein were developed by a committee of PSTG members that had originally formed to develop a paper on modularity, exploring the term modularity and its derivations module and modular, what modularity means to CMS and Medicaid, and what states, vendors and CMS have to do differently to achieve greater levels of MITA maturity. With CMS release of the proposed rule on April 15, 2015 for comment, the committee s efforts were redirected to coordinate an evaluation of and provide industry comments on the impact of the rule. The comments on the rule offered herein represent an interpretation and evaluation developed by a cross-section of the Medicaid vendor community. See Appendix 3: Contributors PSTG Modularity Committee for a list of contributing members. Our comments are provided in the following three sections: Section II. Comments on Proposed Rule Provisions for 42 CFR Chapter IV Section III. 45 CFR part 95 Section IV. Additional Discussion of Proposed Technical Changes Page 1

5 II. Comments on Proposed Rule Provisions for 42 CFR Chapter IV 1. Authority. This section affirms the existing authority contained in the introduction to part 433. PSTG has no comment Basis, purpose, and applicability. This subpart is being amended to replace the reference to 45 CFR part 74 with 45 CFR part 92, which supplanted 45 CFR part 74 in September PSTG has no comments regarding this change. In addition, paragraph (a)(2)(ii) and paragraph (iii) are deleted. These paragraphs currently require a federal performance review at least every three years. Previously, a similar requirement was contained in paragraph ; however, this requirement was eliminated in 75 FR 21905, published April 19, This proposed change provides consistency in the federal regulation regarding federal performance reviews. PSTG supports this change Definitions. PSTG used the following guiding principles as we developed our response to the proposed definitions: We used industry-standard terms and concepts to influence our recommendations. We endeavored to use terminology that is consistent with the MITA framework and initiative. We tried to eliminate ambiguous terminology by suggesting additional or alternate terms and definitions for consideration. Wherever possible, we related terms to actual work activities, deliverables, and milestones. We envisioned practical application of the terms, concepts, and definitions in a Medicaid enterprise to test the relevance of our suggestions. Where service-oriented architecture (SOA) and its precepts could be used to name and define something of importance, we suggested the use of SOA-aligned terms. 3.1 Proposed definitions from the NPRM The remainder of this section presents our comments and recommendations for the definitions listed in the NPRM, starting on page 31. Page 2

6 b. Mechanized claims processing and information retrieval system PSTG knows that the mechanized claims processing and information retrieval system phrase is defined in statute and cannot be removed or changed. However, we recommend that today s Medicaid Management Information System (MMIS) and the future vision for the Medicaid enterprise be acknowledged in (b)(2)(ii), perhaps by supplementing section (ii) with the following text or adding it as a new section (iii): A combination of business services, information, and technical capabilities that allow state Medicaid agencies to administer an enterprise-wide medical assistance program that is functionally able to interoperate with other healthcare programs and oversight bodies. The addition of such language would provide relevancy and currency, as well as recognize the importance of business, information, and technology to work in concert. d. Open source PSTG finds the definition of open source to be industry standard and unambiguous. e. Proprietary PSTG finds the definition of proprietary to be industry standard and unambiguous. However, we believe that the differences between proprietary and commercial off-the-shelf (COTS) software are not well understood among the states. To aid in understanding, we suggest adding sub-regulatory guidance that clarifies the difference between proprietary and COTS software. The following is suggested wording for such guidance: Proprietary software can be a commercial solution designed for a specific application, such as MMIS fiscal agent services, but not sold as a packaged product. Proprietary primarily addresses ownership, whereas COTS primarily addresses the software s fit for use out of the box. COTS is proprietary but proprietary is not always COTS. We believe that greater clarity will help states evaluate commercial options and more effectively consider the customization of them. f. Shared services PSTG finds the current definition of shared services to be too limited. We suggest the following definition, followed by our rationale for this revision: Shared services means the provision of services by a dedicated entity that provides these services to multiple internal user groups or external customer groups. The shared services center operates on a one-to-many model and uses its business, information, and technical assets to deliver services. Page 3

7 For many services companies, including those in the Medicaid market, shared services are a costeffective, flexible, and consistent way to deliver services to their external customers. For example, a Medicaid vendor may use a shared service center for all provider inquiries. We strongly encourage the removal of the final sentence of the definition, that is: The funding and resourcing of the service is shared and the providing department effectively becomes an internal service provider. The sentence addresses internal services only and we believe it would be a mistake to limit the shared services definition to internal service delivery. Further, there are many options and best practices for the funding and resourcing of shared services that do not include sharing. The fundamental concept behind the definition is the delivery model (that is, one to many) and not the funding and resourcing. g. MMIS module It is clear that CMS wishes to migrate away from big bang certifications and use an approach that will provide for better outcomes with reduced time-to-benefit and lower costs. PSTG wholeheartedly concurs and applauds CMS s direction. Having an apt term for a staged certification is important, and we acknowledge the need CMS is trying to address. PSTG believes that CMS should not use the term module and instead use the framework that CMS, states, and vendors have worked diligently to make the standard in Medicaid that is, the MITA Business Process Model (BPM). PSTG s positon is that CMS should adopt a MITA BPM certification approach and use terminology consistent with MITA. The CMS-proposed definition of an MMIS module refers to a group of MMIS business processes that can be implemented through a collection of IT functionality is not a technology-industry standard (especially in relation to SOA). We believe that it is ambiguous, technology-centric, and inadequate for states, vendors, and CMS to use with any degree of consistency, commonality and, hence, maturity. Industry-Standard Terminology: The PSTG Modularity Committee looked at dozens of sources, including Gartner and MIT, to compile a short, succinct definition of the word module. Merriam Webster and other non-computer science sources support module as the smallest unit in a composite structure. The terms module, component, and unit are often used interchangeably or in different ways depending upon the context. In SOA-based solutions, a module is a discrete unit of functionality that interacts with other modules via application Page 4

8 services to form a composite application. 1 For example, in provider management, there could be a module for fetch claims history, another for display template for change of address, and still another for request training. Collectively, these and related modules would provide functionality for the Manage Provider Communication MITA Business Objective. We cannot envision a certification scenario at this lowest functional level, nor do we recommend the use of a term that means something else in the industry, especially in relation to SOA, a fundamental concept on which MITA is based. Clarity: The term module might seem workable in theory but, when it comes time to implement this new approach, states, CMS, regional offices, and vendors will not interpret module the same way. The switch to a new vernacular that has not been clearly and uniformly defined will likely perpetuate diversity in interpretation and approach. Member Centricity: The MITA framework stresses a member-centric, business-first approach to the mature Medicaid enterprise. The proposed definition speaks to a collection of IT functionality. The MITA BPM, on the other hand, defines business processes that must be implemented and, hence, certified. MITA Maturity: During the May 5, 2015, PSTG forum with Jessica Kahn, CMS Data Systems Group Director, she expressed that CMS wants states to define their modules. Using the current definition, one state might be granular and another, comprehensive. One might define a module as everything to do with one type of provider while another as everything to do with a particular claim type. In short, there will not be consistency among states about how they are building and deploying MMIS functionality. This will limit repeatability and reference-ability among CMS offices for pre-certification and certification activities. The Medicaid Enterprise Certification Toolkit (MECT) standard that CMS has worked long and hard to achieve might be undermined by new requirements for modules. The unintended consequences of using the term module are far-reaching. PSTG believes that progress toward higher levels of MITA maturity will be compromised if CMS does not align certification with its vision, as embodied in the MITA framework. 1 The Institute of Electrical and Electronics Engineers (IEEE) defines a module as: (1) A program unit that is discrete and identifiable with respect to compiling, combining with other units and loading; for example, the input to, or output from, an assembler, compiler, linkage editor or executive routine. (2) A logically separate part of a program. Page 5

9 We suggest that CMS adopt a MITA-aligned, business process-based certification approach. There are several terms that could be used to denote a group of business processes, such as increment, segment, or bundle. The definition would be something to the effect of: A/an <increment> is a grouping of MITA business processes that are deployed and certified together. An <increment> lists the MITA Business Process Areas and the subordinate Business Objectives that will be deployed and certified. States define their <increments> according to need as expressed and approved in their MITA maturity roadmap. Once a business objective has been certified, it would not need to be recertified when it is called upon to certify another increment. For example, once Manage 1099s is certified, it would not need to be recertified when Process Mass Adjustments is certified. When Process Mass Adjustments is to be certified, its interaction with Manage 1099s would be evaluated during certification. The approach would be incremental and additive until the whole has been certified. In addition, we find that module and module-related terminology has been over-used and, in some cases, used inaccurately. This has created confusion in the market. For example, many states believe they are being compelled by CMS to do modular sourcing, even when their sourcing strategy concludes otherwise, to achieve the Modularity Standard, even though the Modularity Standard does not mention the words sourcing or procurement. We suggest that CMS take this opportunity to clarify the terms module, modular, modularity, and the Modularity Standard. We recommend that the clarification use logical, industry-standard, MITA-aligned language, such as: Module: a discrete unit of functionality in a SOA-based MMIS Modular: the characteristic that makes an MMIS interoperable, gives it longevity, and provides optimal value for money Modularity: the degree to which MMIS components can be separated and combined Modularity Standard: one of seven standards by which an MMIS will be evaluated for enhanced Federal Financial Participation (FFP) There is not a one-size-fits-all definition and associated language for these terms but, given the wide gaps in interpretation, we suggest clarification is warranted. The simpler CMS makes the discussion, the better the adoption and, hence, the outcomes. h. Commercial off-the-shelf software PSTG finds the first sentence of the COTS definition to be industry standard and unambiguous. Page 6

10 The second sentence, that is, COTS software does not include software developed specifically for public assistance programs, is problematic. We agree that if the government pays for software development, as in a work made for hire, a third party cannot claim ownership and package the software for sale or lease as COTS. However, the literal interpretation of this sentence is public assistance software can never be COTS. The PSTG Modularity Committee attempted to ascertain the intent of the second sentence because it seemed out of place. The committee felt that it might be trying to address the issue of ownership when government funds are spent to customize COTS software. Our members encounter this issue frequently and so we decided to provide commentary for CMS s consideration. As noted in our preceding comments on proprietary, proprietary is used primarily to address ownership, while COTS is fit for use out of the box. COTS software is proprietary but proprietary software is not always COTS. A proprietary solution can be commercial that is, available to the market, but not fit for use out of the box. Most MMIS vendors have proprietary solutions that deliver more than software functionality. These solutions use COTS products but the composite solutions are not COTS they are proprietary and commercial. When proprietary solutions are customized at the request of and paid for by the government, the vendor generally retains all ownership rights. The owner may decide to include the customization as part of the solution, and if so, may release the functionality to all its users. Vendors that are asked to customize their commercial solutions do so with great hesitation. Vendors engage in formal release planning and decide what upgrades will benefit all customers. They deploy the upgrades in a controlled manner. Ad hoc customization is risky for both the vendor and its state customers and states do not generally understand the cost involved to manage that risk. We suggest that CMS clarify the difference between proprietary and COTS, as well as address the issue of ownership when customization is paid for with government funds. 3.2 Additional terms and definitions PSTG asks that CMS consider the inclusion of Software as a Service (SaaS) in the new rules. We believe that FFP decisions will be simplified if SaaS is recognized as a different investment than open source, proprietary or COTS software, and shared services. Our proposed definition is: Page 7

11 SaaS is a software delivery model in which software is managed and licensed by its vendor owner on a pay-for-use or subscription basis, centrally hosted, on-demand, and common to all users. Our rationale for including SaaS is that it is a mainstream and well-used delivery model for common business services. State agencies, including Health and Human Services organizations, are increasingly using SaaS to replace functionality that is inadequate for current needs and expensive to operate. The attraction of buying service capability rather than making Cap X investments is compelling for many states. While SaaS is not the only as-a-service capability in the market, it is mainstream and identifiable. Other types of as-a-service delivery models are evolving and today include Business Process, Back Office, Infrastructure, Platform, and Desktop. By including SaaS, other as-a-service components will have a precedent reference and can be handled in sub-regulatory guidance as necessary over time. As a final note, PSTG believes that SaaS should not be included as a type of shared service. SaaS has many differences from shared services, and chief among them is the engagement method. Shared services are engaged under contract, with terms and conditions, while SaaS is engaged via a licensing arrangement FFP for design, development, installation or enhancement of mechanized claims processing and information retrieval systems. PSTG supports the general theme of increasing the accountability of states, their vendors, and other partners to produce high quality, modern, SOA-based, MITA-aligned systems in a way that promotes the sharing of responsibilities and risks more evenly among all parties involved. A large-scale transition to modularity must be accompanied by a standardization of business processes across the Medicaid enterprise to avoid the need for over customization. Greater adoption of and adherence to the MITA-defined business processes will allow system designs to be more interoperable because the inputs and outputs (public interface requirements) of other processes will be known and predictable. In the following section, we comment specifically about how each proposed change will support the goal of modernization and shared accountability. (b) CMS will approve the eligibility and enrollment (E&E) or claims system described in an APD if certain conditions are met. The conditions that a system, whether a claims or E&E system, must meet are: PSTG is pleased that CMS is expanding its definition of a system that is eligible to receive enhanced FFP. It makes sense that E&E capabilities are aligned with a 21st Century Medicaid Health Information Enterprise. Page 8

12 (12) The agency ensures alignment with, and incorporation of, industry standards adopted by the Office of the National Coordinator for Health IT in accordance with 45 CFR part 170, subpart B: The HIPAA privacy, security and transaction standards; accessibility standards established under section 508 of the Rehabilitation Act, or standards that provide greater accessibility for individuals with disabilities, and compliance with Federal civil rights laws; standards adopted by the Secretary under section 1104 of the Affordable Care Act; and standards and protocols adopted by the Secretary under section 1561 of the Affordable Care Act. PSTG supports the adoption and meaningful use of specifically named standards for Medicaid Health Information Enterprises that are eligible for enhanced FFP. In addition, we recommend that future Medicaid enterprise capabilities need to adopt standards for interoperability, including the Office of the National Coordinator for Health Information Technology (ONC) 2015 Interoperability Standards Advisory. (16) The system supports seamless coordination and integration with the Marketplace, the Federal Data Services Hub, and allows interoperability with health information exchanges, public health agencies, human services programs, and community organizations providing outreach and enrollment assistance services as applicable. PSTG supports the seamless coordination and integration of state, federal, and hybrid marketplace, and the Federal Data Services Hub as essential to the goals of healthcare reform, expansion of Medicaid eligibility, and providing 21st century customer service experience through the E&E process for consumers, their families, and advocates. While CMS in general and the Office of Consumer Information and Insurance Oversight have worked diligently to support the letter and spirit of the recent Patient Protection and Affordable Care Act (ACA) requirements, significant work remains. PSTG supports the recommendations by the National Association of Medicaid Directors (NAMD) to improve the electronic exchange processes in this area. The NAMD s March 23, 2015, letter to CMS Acting Administrator, Andrew Slavitt, recommends a prioritized list of modifications to further improve interaction and alignment between state Medicaid agencies and the Exchange program. The recommendations include five key modifications: Stabilize federally facilitated marketplace (FFM)-Medicaid timelines and testing Reduce duplication of effort File format improvements Clarify notices and improve information flow Align and streamline eligibility policies Page 9

13 This last point is of primary importance because of ACA regulations requiring standardization and streamlining notices, alerts, and other communications from Medicaid and the Marketplace. Because of this, we recommend that CMS work with states and vendors to explore a variety of communications. (17) For eligibility and enrollment systems, the state must have delivered acceptable MAGI-based system functionality, demonstrated by performance testing and results based on critical success factors, with limited mitigations and workarounds. PSTG supports both modified adjusted gross income (MAGI)-based and non-magi-based system functionality as referenced in (b)(10): Use a modular, flexible approach to systems development, including the use of open interfaces and exposed application programming interfaces; the separation of business rules from core programming, available in both human and machine readable formats. (18) The State must submit plans that contain strategies for reducing the operational consequences of failure to meet applicable requirements for all major milestones and functionality. PSTG recommends that CMS provide sub-regulatory guidance for and require a detailed plan from the state for comprehensive risk assessments and management plans. These plans should be established at the onset of the Enterprise Life Cycle (ELC), at the start of procurement planning, and then be reviewed and updated as necessary during subsequent project phases. PSTG recommends that sub-regulatory guidance include the requirement that a budget be allocated for risk assessments and reserves set for the additional work discovered throughout the project as part of risk activities. PSTG also recommends that formal risk activities begin at the start of the procurement and continue through the life of the project. Effective risk mitigation plans need to balance the risks between the state, the MMIS vendor, and the independent verification and validation (IV&V) vendor. MMIS vendors are often on fixed price contracts, as opposed to IV&V vendors, which are on time and materials (T&M) contracts. Having different contract structures creates risk imbalance. PSTG recommendations include the following: Effective governance that includes a comprehensive escalation process and change management process should be required as part of the Risk Mitigation Plan. When CMS is meeting with a state during gate reviews, it should also meet with the MMIS vendor and the IV&V vendor to review risks. Care must be taken to develop strategies to account for failure to meet milestones at the right level, and not for each deliverable or line of the project plan. Risk mitigation strategies that address failures at too detailed a level are counterproductive. Page 10

14 Use of federally funded pilots and innovation grants to address the states risk of being the early adopters of emerging modular technologies. Funding for pilots would need to come from current Center for Medicare & Medicaid Innovation (Innovation Center) funds as opposed to the Medicaid budget. Funding is needed to support a Date of Service Cutover methodology for Claims Administration in lieu of massive data conversion (full cutover) to the new MMIS system on the go-live date. This method is used widely by private payers to reduce risks at go-live and aid in system stabilization. This methodology requires the legacy system and the new MMIS to run in parallel for a period of time, streamlines configuration of rules to support Medicaid policy that may be up to two years prior to the implementation of the claims rules engine, and supports alternative approaches for Medicaid claims administration, such as the administrative services only model. (19) The agency, in writing through the APD, must identify key personnel by type and time commitment assigned to each project. PSTG wholeheartedly supports the requirement that states need to identify key personnel for any project that receives enhanced FFP. In addition, we recommend that states identify key personnel for their primary responsibilities and their decision-making authority, and that CMS and the vendor are notified in writing when changes are made. Commitment of key state personnel is essential to the success of any size project that is on time, on budget, and on schedule. There are a variety of issues that present significant challenges to the implementation of such projects in an on time, on budget, and on schedule manner, but key state personnel with clear responsibilities are essential for a successful project of any size. PSTG recommends the following as part of CMS considerations for sub-regulatory guidance: As part of the overall resource management plan and matrix reporting, key personnel named in a project governance structure should provide their projected availability, experience level, a delegate, and escalation and decision-making authority. Key personnel should include state leads for such things as data governance and SOA governance, along with required experience. (20) Systems and MMIS modules developed, installed or improved with 90 percent match must include documentation of components and procedures such that the systems could be operated by a variety of contractors or other users. PSTG supports the documentation of information exchange between people and different computer systems. This will help provide high information quality and minimize misunderstandings. Technical product documents will allow information to be identified, Page 11

15 recognized, understood, and properly handled. Documentation should be embedded into the software and should be printable. PSTG also recommends that CMS review the policy regarding royalty-free licensing of COTS products. Federal or state governments cannot reasonably expect to get a royalty-free license on proprietary modules or COTS components. PSTG recommends that if 90/10 funding is used for enhancements to a module, then CMS and the state own the modifications, which can then be shared. When 90/10 funding is used to purchase an open source module, by definition, the state and CMS can share the module with other states and contractors. Additionally, when 90/10 funding is used to build an application programming interface (API) or API libraries, then CMS and the state can share the code with other states and contractors. (21) For software systems and MMIS modules developed, installed or improved with 90 percent match, the State must consider strategies to minimize the costs and difficulty of operating the software on alternate hardware or operating systems. PSTG supports the focus on strategies to minimize the costs and difficulties of operating software on multiple hardware and operating systems. PSTG recommends that CMS provide states with sub-regulatory guidance for developing hardware and operating system version management plans as part of their enterprise architecture strategy to attain and maintain funding at the higher match rates. Software vendors must make choices in regard to the operating systems and hardware on which their solutions will operate, such as Microsoft, Oracle, or Linux. PSTG supports the use of APIs to allow cross communications between various software and hardware sets. PSTG also recommends that CMS provide states with sub-regulatory guidance for plans to leverage and manage these types of APIs as part of their enterprise architecture strategy to attain and maintain funding at the higher match rates. (22) Other conditions as required by the Secretary. PSTG understands that proposed section 22 exists to offer flexibility for the Secretary to add other conditions in the future; however, open-ended language such as this offers the opportunity for a departure from the general theme and spirit of the regulations. PSTG supports the inclusion of language that would give the Secretary the ability to encourage states to utilize new technologies, methods, and best practices that may be impractical or too new to include at the time of this writing. Page 12

16 (c) (1) FFP is available at 90 percent of a state s expenditures for the design, development, installation or enhancement of an eligibility and enrollment system that meets the requirements of this subpart and only for costs incurred for goods and services provided on or after April 19, PSTG understands that FFP will be made available to states to continue work on the design, development, installation, and enhancement of their E&E systems. Work may continue on the modernization of eligibility and enrollment systems, allowing the completion of existing projects and new enhancement projects to increase the capability and interoperability of E&E systems. (2) Design, development, installation or enhancement costs include costs to procure commercialoff-the-shelf (COTS) software, but should only include the minimum necessary costs to analyze the suitability of COTS software, install and integrate the COTS software, and modify non-cots software to ensure coordination of operations. The nature and extent of such costs must be expressly described in the approved APD. PSTG understands that this section will make available FFP at 90 percent of a state s expenditures for the expenses surrounding the integration of COTS software with certain conditions. This provides several opportunities to states: Allows states to utilize modern COTS systems without financial penalty. Allows CMS, through the Advance Planning Document (APD) process, to determine if a state s customization plans are excessive. Encourages states to reengineer their business processes to be more aligned with industry best practices as expressed by MITA, by minimizing the amount of configuration and software modification necessary. Encourages vendors to produce systems that support those now commonly utilized processes, with less configuration effort, in order to be competitive in the marketplace. This also provides several challenges: States may be reticent to engage in a re-engineering of their business processes. Determining the excessiveness of a state s customization plans is subjective, which could produce inconsistent judgments. Many of the state s customization requirements only become known and articulated during design, development, and implementation (DDI), after the APD has been approved. PSTG believes that a large-scale transition to modularity will be achieved through the increased use of COTS software and through a standardization of business processes across the Medicaid enterprise. Page 13

17 PSTG makes the following recommendations: Utilize the APD approval process to encourage states to align their business processes with MITA business processes The initial configuration of COTS software be included as part of installation and integration, eligible for 90 percent funding Clarify in both the Final Rule and sub-regulatory guidance that enhanced FFP at the rate of 90 percent is only available for the initial configuration of a COTS product Require states to submit their plans for managing, minimizing, and justifying any customizations to attain APD approval Utilize Gate Reviews to validate that minimum additional requests for customization occur during DDI PSTG supports CMS effort to minimize the modification of all software so that COTS software may be more easily integrated into the environment FFP for operation of mechanized claims processing and information retrieval systems. PSTG understands that the intent of this section is to align the approval process for states seeking enhanced FFP for system operation with the rules proposed for certification of MMIS components at a modular level. With that understanding, the rules as proposed would be entirely appropriate Conditions for reapproval; notice of decision. This section is being amended to correspond to the modified numbers 12 and 16 and additional conditions 17 through 22 added to Please reference PSTG s comments regarding these changes contained in Section II Procedures for reduction of FFP after reapproval review. This section has been substantially revised, with changes to the entire section. Subsection (a) currently states that if CMS determines that the system no longer meets the conditions of reapproval, as stated in paragraph , then CMS will reduce FFP for system operations for at least four quarters. The proposed rule amends this subsection to state only that FFP for certain expenditures for system operations will be reduced, with no stated minimum penalty period. This section is further clarified in subsection (b), which states that FFP will be reduced from 75 percent to 50 percent for expenditures related to the operations of noncompliant functionality or system components. This is a substantial change from the current subsection (b), which states Page 14

18 that FFP for system operations will be reduced from 75 percent to no more than 70 percent and no less than 50 percent. The current subsection then lists four criteria to determine the magnitude of the reduction, which are all deleted in the proposed rule. PSTG supports this change, which will enable CMS to penalize a state only for non-compliant functionality or for a system component that is not performing in a compliant manner, rather than reducing FFP for the entire operational cost of the system. We further support the removal of the four-quarter minimum penalty, as it is arbitrary and overly punitive should the issue be quickly remedied and made compliant. The proposed rule introduces new questions regarding how CMS will measure and determine which component or functionality is not performing to warrant reduction in FFP, including: What is the definition of system component? Who defines where a component begins and where it ends? How will CMS determine that a functionality or component is noncompliant using the MECT? PSTG believes that compliance criteria must be based upon the MECT. Compliance should focus on business outcomes and the criteria for compliance should be structured as such. Further, we recommend that CMS consider the above questions when finalizing the rule and/or preparing sub-regulatory guidance. III. 45 CFR Part Authority This section affirms the existing authority contained in the introduction to 45 CFR part 95. PSTG has no comment Prior approval condition PSTG understands that the proposed rule change differentiates approval requirements for expenditures under 45 CFR and 45 CFR part 307 from those under 42 CFR part 433, subpart C. This change allows states under 42 CFR part 433, subpart C to receive prior approval for expenditures that do not exceed $500,000. PSTG supports this change as it will encourage states to pursue smaller and more modular procurements to reduce the risk of large IT implementation projects and accelerate the delivery Page 15

19 of MMIS components. This change will also allow flexibility in the approach taken to procuring large systems and encourage participation by smaller vendors in the marketplace. PSTG makes the following recommendations: CMS should consider forming a small committee tasked with identifying the available modules, or define the use cases and standards necessary to support modules. CMS should allow the noncompetitive dollar amounts to be allocated immediately to allow for incremental modernization (less than $1,000,000 for x, less than $6,000,000 for y, and less than $20,000,000 for COTS installation). CMS should consider providing clarity around what constitutes a noncompetitive install that is less than $6,000,000 to include state costs and ongoing operating costs. CMS should consider making funding available to develop and pilot specific modules to encourage breakthroughs in module development where current module solutions have not been developed. CMS may consider selecting known vendors with proven Medicaid IT modules/components for a pilot with either CMS or a selected state Medicaid agency. This funding can be made available through the MITA Roadmap and APD approval process. CMS should consider making any MMIS component that is subject to prior approval meet a minimum level of documentation with a detailed checklist of required information, including: Source code Implementation guides Data models Analysis and design documents Tailoring guides CMS should consider module functionality and documentation posted to a portal as a minimum requirement to receiving prior approval. PSTG believes that the sharing and reuse of modules will require a focused and funded portal to maintain module-related assets to ensure a defined resource that supports ease of sharing and ongoing reuse. IV. Additional Discussions of Proposed Technical Changes 1. Technical Changes to 42 CFR Part 433, Subpart C Technical Changes to 42 CFR Part 433, Subpart C modular certification, sub-regulatory guidance, open source and COTS, and reuse This section responds to proposed technical changes to conditions that state Medicaid agencies must meet in order to be eligible for enhanced FFP. Page 16

20 PSTG appreciates the opportunity to provide comments on the following topics: The advantages/disadvantages of certifying MMIS modules, rather than the whole system, to: Remove the barrier to entry for many small IT solution vendors Increase the availability of certified modules in the market from which states can choose Create an incentive for the states to take a modular approach in both IT architecture and procurement strategy Identifying the opportunities a modular MMIS certification process may create Identifying the challenges that might arise in defining a finite list of MMIS modules to ensure the appropriate combinations of certification criteria are established Proposing modules for CMS certification prior to the state s installation, without focusing on the implications for state s enhanced match rate for maintenance and operations What should be included in sub-regulatory guidance, such as definitions of MMIS modules? How might a modular certification implementation process work? To truly advance and modernize the MMIS, PSTG recommends that this rule align with the larger government digital strategies such as the Digital Government: Building a 21st Century Platform to Better Serve the American People that indicate digital governmental services should focus on harnessing the power of technology to help create a 21st century digital government one that is efficient, effective and focused on improving the delivery of services to the American people. Accordingly, any of the proposed changes in this rule, particularly to the regulatory conditions for enhanced FFP, need to advance the value of Medicaid healthcare coverage as assessed by a set of performance measures for: Triple Aim: Improving health, improving care delivery, and decreasing costs, in accordance with the National Quality Strategy, as shown in Figure 1 Efficient, Economical and Effective Administration of the State Plan : The first condition 42 CFR (b)(1) Figure 1: Triple Aim of 21st Century Healthcare supported by Health IT Page 17

21 Interoperability 2 of Health Information: To e-enable these goals for a patient-centered 3 learning health system 4 as aligned with the Office of the National Coordinator, Connecting Health and Health Care for the Nation: A Shared Nationwide Interoperability Roadmap Technology, healthcare, and Medicaid have undergone tremendous growth and change, while statute language creating the mechanized claims processing and information retrieval system has not changed since it was enacted in The MMIS today is still largely configured around the same core concepts that it had when the first rules were adopted in Today, Medicaid is the single largest source of healthcare coverage, and it requires digital technology to fulfil this new leadership role. While reducing barriers to entry and increasing certified modules and modular architecture are laudable objectives, the case for change must be driven by 21st century business and healthcare value measured by: Efficiency Economics Effectiveness Improving individual and population health Improving the quality and patient-centeredness of care delivery Decreasing costs by new payment models and increasing consumer engagement With these overarching comments in mind, PSTG responds to CMS request for comments on issues that will impact 42 CFR 433, subpart C with the following recommendations. 2 Interoperability is defined by the IEEE as the ability of a system or a product to work with other systems or products without special effort on the part of the customer. Interoperability is made possible by the implementation of standards. 3 Person-centered learning health system - the power of each individual is developed and unleashed to be active in managing their health and partnering in their healthcare, enabled by information and technology. Healthcare is a partnership between the patient, their caregivers, the care team, and supporting services. 4 A continuously Learning Health System (LHS), was first referenced by the Institute of Medicine in 2007, and today is used across the country and around the world to mean a system based on cycles that includes data and analytics to generate knowledge, leading feedback of that knowledge to stakeholders, with the goal to change behavior to improve health and to transform organizational practice. LHS is the focus of the Office of the National Coordinator s Interoperability Roadmap. Page 18

22 1.1 Certifying MMIS modules rather than the system: To remove barriers to entry for smaller IT vendors, increase the availability of certified modules in market, and create incentive for modular IT architecture and procurement approach. States typically do not have sufficient staff and staffing capabilities to handle multiple procurements. While the prospect of a smaller, discrete delivery of real value is consistent with recommendations from the public sector, including the US Digital Services Playbook and the Improvement Plan to Reform Federal Information Technology Management, most states have insufficient staff to handle several procurements at one time. Issues associated with state staff, such as retooling skill sets, need to be addressed, but we do not believe that this is the appropriate place. Therefore, we confine our comments to the benefits of smaller, more discrete procurements. Helping to reform the procurement process, which has been documented by sources such as Gartner and US Procurement Officers as, at times, more focused on preventing problems than producing value. Allowing modules to be developed for a targeted set of specific business functions. Providing the opportunity to establish a repository of reusable business rules and regularly updated references to standards that are necessary to support interoperability. Such a repository could also store best-practice materials on performance measurement and management, such as service level agreements, dashboard formats, and other performance tracking and reporting capabilities. As clarified during the May 5, 2015, CMS/PSTG Meeting, CMS will work with each state to define their modules. The future architecture may require a core module with enterprise service bus (ESB) capabilities defining the interoperability of the architectural specifications. A clear definition of a component within a module is needed. During planning sessions with CMS, a state will need to define who is responsible for design and governance of each aspect of the system. If it is the vendor, the state needs to define modules and ensure how they will interoperate. Many vendors will require additional capabilities to design and operate the architecture, particularly if modules are truly interoperable. PSTG believes that, to be successful, a modular approach to implementation of the Medicaid enterprise solution must involve the following: Requires a comprehensive plan that is dynamic and regularly updated by the state. Requires effective governance and change management plans to ensure that the mitigation plan previously described in Section II.4 is comprehensive and dynamic and that timing within the plan is clear to all involved. Page 19

23 Requires effective and integrated management, including timing dependencies of crossmodule standards, such as Transformed Medicaid Statistical Information System (T-MSIS), International Classification of Diseases (ICD)-10, and data security. Requires clear and timely definition of data elements. Current data elements defined in State Medicaid Manual (SMM), Part 11 (SMM 11375), are out of date. A more detailed discussion can be found in Section IV.2.2. Requires balance between piloting of new modular concepts and the need to move on with modern technologies and capabilities. Since PSTG concurs with CMS that systems transformation is necessary to meet the vision of the Affordable Care Act, we urge CMS to adopt a similar strategy as the Innovation Center s strategy to develop and test innovation models that are modular. We concur with the following: From an IT perspective, modular development allows agencies to test the probability of the successful implementation of solutions in shorter periods of time, which better positions agencies to adopt new technologies.to minimize risk and maximize the success of the development major investment enhancements or capabilities are completed incrementally. This includes prioritization of critical requirements and functionality that will deliver features for customers. 5 We encourage CMS to work with states and vendors to develop and test various modular approaches and identity and publish best practices in using modular approach to meet the vision of the ACA. If CMS intends to use MITA as the Medicaid reference architecture for this systems transformation through a modular approach, we encourage CMS to take the necessary steps to finalize an architectural model that can be used for modular development. All MITA business processes need to be updated and completely documented. In addition, continuous evaluation of the processes needs to occur to ensure that the BPM remains current. New processes need to be developed that support Medicaid s quality-related efforts to align with the National Quality Strategy, particularly relating to quality and performance measurement, Care Coordination, and engagement. Core processes that have been a focus of ACA are also not included in the current MITA BPM, for example, security management. MITA Self-Assessments need to be standardized so they can be replicated, benchmarked, and comparable across states. CMS needs to regularly publish the status of CMS-funded efforts in using MITA to transform their systems capabilities. 5 Contracting Guidance to Support Modular Development, June 14, Page 20

24 CMS has developed and enhanced a set of MITA certification requirements that include the original MECT checklists plus 15 new checklists: 10 Business Areas checklists, 3 Technical Architecture checklists, 1 checklist for Information Architecture, and 1 checklist for the Seven Conditions and Standards. With the variability between states MITA maturity roadmaps within their State Self-Assessments, it will be difficult to achieve interoperability beyond each state s Scorecards without defined standards and protocols, such as was defined with Health Insurance Portability and Accountability Act (HIPAA) transactions and protocols. If a technology pilot is undertaken, both positive and negative results with impacts should be published in a publicly accessible repository of lessons learned for states and vendors. PSTG recommends that CMS provide a clearer definition of a module that includes defined input and output interfaces, and starting and ending processes for each module. In addition, the definition should include the critical success factors for each module. See comments on this topic provided in the previous Section II.3.1. PSTG recommends that each state that pursues modular development include in its APD the state s strategy for system integration. The state should detail whether it intends to undertake this responsibility through state government staffing or through a contractual agreement. Regardless, the person or entity identified needs to be on board and involved in assisting the state to help define the state s modules based on its business and performance needs. In addition, CMS needs to clarify the distinct role and responsibilities for IV&V and system integration, including, but not limited to the following: An entity may not function as the system integrator and the IV&V services vendor. The qualifications of the system integrator should include technical expertise with complex MMIS procurements and multi-vendor relationship management. PSTG recommends the alignment of the contract approach in the MMIS DDI process. Currently, the prime vendor accepts risks for DDI through a fixed price contract. However, the IV&V vendor typically contracts with the state through a T&M contract, which creates conflicting incentives. Both vendors should share risk for the success of the project, so their interests are aligned for successful and timely completion of the project to meet the state s business and performance needs. PSTG recommends that the planned release schedule for the COTS integration and implementation of the state-identified modules be required in the state s request for proposal (RFP). PSTG recommends that CMS central office staff coordinates closely with the CMS regional offices to ensure consistent interpretation and implementation of the resulting rule from this Page 21

25 NPRM) across the country, and that both the central and regional offices share a commitment to and approach for limiting the customization of COTS software in the APD, RFP, and implementation. As CMS begins to consistently meet with states for the Gate Review process outlined in the Enterprise Lifecycle, PSTG recommends that CMS also meet with the contract vendor(s) as a part of the Gate Review. To ensure the success of the Gate Review, it is essential to include all key parties in the review, and that the Gate Review process aligns with a modular and Agile methodology. 1.2 Modules for certification before installation: What is the impact on enhanced FFP for maintenance and operations? The precertification or partial certification of a module, rather than the entire system, will allow a state to more quickly implement certified modules and receive 75 percent FFP for maintenance and operation of that module. Smaller modular implementations may reduce the staffing demand on state resources that cannot be 100 percent dedicated to a project. Smaller, incremental changes/enhancements to modules may allow states to spread out IT costs over a longer period of time and across budget periods. Enhancements to existing modules qualify for enhanced 75 percent funding if the enhancements result in more efficient and economical operations. With precertification of a module s functionality comes the second stage of finalizing the module as fully certified. This stage includes continuation of initial functions and demonstrates successful interfaces with other external systems, while still proving the performance metrics and results meet the original requirements for the module. CMS is working to define the method it will use to validate the full functionality for this second stage of approval. Some challenges include: Will the state be required to repay enhanced funding (that is, the difference between the 75 percent and 50 percent FFP) if this second validation identifies a defect requiring a Corrective Action Plan (CAP) to reinstate the 75 percent FFP? Will this repayment be passed along to the vendor? What are the limits of customization that CMS will support with enhanced FFP? Per the May 5, 2015 CMS/PSTG Meeting, PSTG learned that CMS will work with each state to discuss and understand the state s business model and the breakouts of modular solutions that will result in efficiencies and cost reductions and any customizations anticipated due to unique state needs. There needs to be a clear definition of a module and its parameters or constraints. The module definition may align with MITA Business Areas, but each state s MITA maturity levels in State Self-Assessment (SS-A) roadmaps vary greatly. Page 22

26 How do we reconcile for intra-state interoperability without technical or informational consistency between the states? In the absence of regulatory protocols and common external interface formats, what is the proper balance between standardization and customization that should be supported with enhanced FFP? At the May 5, 2015, CMS/PSTG Meeting, it was clarified this will be determined in planning and design sessions with each state. PSTG supports initial certification and enhanced funding of a module s functionality prior to full integration with all processes within the enterprise of the state. We understand CMS will need to again validate that the functionality works as designed and defined at that time. We recommend defining use cases 6 that would demonstrate to CMS that the module s functionality is operating as intended and using performance metrics such as key performance indicators (KPIs), which can be submitted for review to CMS for both periods of the modules operation. PSTG recommends standardized performance metrics that measure efficiency, economy, and effectiveness, including: Quantitative (usage statistics) Practical indicators: real-time process time monitoring across external APIs to measure degradation across the enterprise Quality metrics: standard set of measurements to validate outcomes of critical success factors, such as error rates, accuracy of decision, consistency of dispositions Actionable indicators: governance and change management policies Service level metrics: specific to the business process 1.3 Sub-regulatory guidance: MMIS module definitions and modular certification process CMS has the opportunity to further provide written clarification on certification processes that have been successful through sub-regulatory guidance, such as state Medicaid Director s Letters (SMDLs) in the use of both precertification and final modular certification with states currently implementing modular systems for their MMIS. These communication methods are timelier than the lengthy regulation approval process, so information is shared more quickly with the states. 6 Use Case - is a written description of how users will perform tasks on your website. It outlines, from a user s point of view, a system s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled. Use cases add value because they help explain how the system should behave and in the process, they also help brainstorm what could go wrong. Accessed at: Page 23

27 This guidance builds on the current requirement for states to use a modular, flexible approach to systems development. States will need to streamline and enhance their procurement approach to be able to successfully implement and manage the modular acquisition process. Modular acquisition is defined in the Federal Acquisition Regulation (FAR) as the use of one or more contracts to acquire information technology systems in successive, interoperable increments. This guidance also extends the notion of modular development, which focuses on an investment, project, or activity of the overall vision and progressively expands upon the agencies capabilities, until the overall vision is realized. The US Digital Services Playbook recommendation is to build the service using agile and iterative practices. OMB Circular A- 130 instructs entities to structure major information systems into useful segments with a narrow scope and brief duration [in order to] reduce risk, promote flexibility and interoperability, increase accountability, and better match mission need with current technology and market conditions. According to the Technology Federal Acquisition Regulation (TechFAR) Handbook and the US Digital Services Playbook, Agile software development is the preferred methodology for software development contracts that contribute to the creation and maintenance of digital services, whether they are websites, mobile applications, or other digital channels. Even though states are currently required to use a modular, flexible approach to systems development, few states have implementation experience with modular procurement and development approaches. This is a major shift for most states and many vendors. Accordingly, CMS will need to provide substantial technical assistance as well as regulatory and subregulatory guidance. In addition, CMS needs to clarify in the Final Rule its expected timeline for this transition, and define the consequence for states and vendors that do not comply. Sub-regulatory guidance is only guidance, and not regulation or a requirement. As a result, sub-regulatory guidance will be helpful for those states and vendors that concur with this direction, but it leaves the state and other vendors at risk if not all vendors within the enterprise adhere to the same standards to ensure interoperability. PSTG recommends CMS clearly define and standardize its communication methodology and tools to ensure states and vendors work together successfully to make this transition. CMS has historically had a practice of only communicating directly with states regarding system changes. We strongly recommend a model similar to one that has worked successfully for the ONC s collaborative leadership with agencies, providers, and vendors. PSTG recommends that CMS develop a repository for states and vendors to share documents, to host learning communities, and to serve as a channel of regular communication about this change. Page 24

28 PSTG recommends that CMS publicly announce all MMIS system changes through SMDLs. This ensures timely, accurate, and traceable official documentation about system changes. As previously stated, CMS has had a history of communicating directly with states, and sharing documentation directly with states. As a result, vendors are often a step behind in getting access to information. Further, if a vendor is not a fiscal agent, they may lag far behind in the communication process. The goal is to encourage involvement of all interested participants and ensure equal access to information to bring the best and brightest solutions to Medicaid to address its business and performance needs and advance its vision of better health, better care and smarter spending. PSTG recommends that the Final Rule define the term industry standards to ensure consistent understanding and approach nationwide. Medicaid systems must be compliant with multiple industries technology standards industries (of which there are many), Medicaid industry (which includes statutes, regulations, waivers, and State Plan Amendments [SPAs]), and the larger health IT industry (that includes many areas, but not exclusive of ONC). 1.4 Open source vs. proprietary COTS: Effective and efficient balance for use of enhanced FFP to acquire open source vs. proprietary COTS software and IT technology solutions. CMS indicates that its new COTS definition and process would necessitate an exemption of COTS software from 45 CFR (b) to protect intellectual property ; include COTS software in DDI (at 90 percent enhanced FFP for certain specified costs) to encourage states to use COTS and SaaS options; and encourage comments on the use of open source versus propriety COTS and the use of financial and technological costs and benefits to meet the new conditions. PSTG sees several opportunities presented by this new definition: Exempting COTS software from Software and Ownership Rights in 45 CFR (b) provides an incentive for vendors to invest and bring innovation and intellectual capital to this marketplace. Allowing COTS software to be eligible for enhanced 90 percent FFP in the DDI phases, and 75 percent FFP in maintenance and operations creates a clear incentive for states to utilize COTS in their future system without loss of revenue. However, CMS will need to ensure that states minimize customization of COTS software, or the advantages of this approach will not be fully realized. Although both COTS and open source are potentially positive options for states, PSTG is not aware of any MMIS open source solutions operating or in development. While the above opportunities are presented by this proposed definition, PSTG sees several challenges: Page 25

29 MITA remains a loose architectural framework that, in its current state, does not provide sufficient definitions, constraints, or measures to support consistent modular development. Standardized baseline procedures to support the MITA Business Areas processes are not in place. The Organizational Change Management maturity needed to reengineer and integrate siloed operational processes to align with standard procedure to dramatically reduce customizations is not in place. The lack of common SOA and data governance practice maturity prevents the architecture for plug-in modules from being established and matured by states. The lack of technical expertise for designing and maintaining enterprise architecture prevents plug-in modules from being established and matured by states. Guidelines are needed for states in defining acceptable level of customizations of COTS software to understand when that level has been exceeded. PSTG recommends that this Final Rule exempt COTS software from the Software and Ownership Rights provisions in 45 CFR (b). These provisions allow the Department of Health and Human Services (HHS) royalty-free, nonexclusive, and irrevocable license to reproduce, publish, or otherwise use and to authorize others to use for federal government purposes, such software, modifications, and documentation. Vendors invest time, money and intellectual capital in developing system capabilities, and they are only made whole through the ability to sell these capabilities. Vendors are not likely to seek to invest and innovate in the Medicaid systems market if they cannot recoup costs. The current language presents an immense financial risk to vendors and as such poses a barrier to the proliferation of COTS and modularity. PSTG recommends that CMS clarify its approach to and definition of a module. The NPRM requests input on a finite set of modules so CMS can establish certification criteria. In the May 5, 2015 CMS/PSTG Meeting, Ms. Kahn indicated that states would recommend the modular approach and that CMS would work with states to refine and approve it. PSTG recommends that a core set of modules be identified and defined through a collaborative workgroup of representative states, vendors, and CMS. In order for MITA Business Areas to be used as a starting point for defining modules, PSTG recommends that MITA be updated, completed, and standardized to provide sufficient structure for a modular approach. PSTG recommends that this be accomplished through a collaborative workgroup of states, vendors, and CMS. PSTG recommends that sub-regulatory guidance be jointly developed between CMS, the states, and the vendors for best-practice process baselines that align with the MITA Business Areas. States could then align their processes with the best-practice process baselines to reduce the need for customizations, while still leaving room for state-specific processes. Page 26

30 PSTG recommends that a state should include plans in its APD request for enhanced FFP and more information in the RFP regarding: Organizational change management that includes best practices for business process reengineering, workforce impact analysis, and transition, which are all important to the success of any IT implementation project SOA and data governance Sufficient technical expertise for both implementation and ongoing maintenance and operations State-specific customization, if they are planning changes and/or customization of COTS software PSTG recommends that CMS clarify examples of open source software that are currently being used in MMIS deployment and lessons learned. 1.5 Reuse - innovative ways for CMS and states to share and reuse IT solutions and so ensure appropriate marketplace incentives for best quality and value in IT solutions and services for Medicaid PSTG sees several opportunities in: Reuse and innovation A focus on cloud implementations and sharing State Innovation Model (SIM) Initiative that provides support to states for the development and testing of state-based models for multi-payer payment and healthcare delivery system transformation with the aim of improving health system performance for residents of participating states However, a significant challenge is vendors general concerns about intellectual proprietary. PSTG recommends that the most effective way to encourage reuse is to certify modules prior to installation and to encourage states to utilize these modules. In addition, it is important to clarify the vendors business case for preinstallation certification, since CMS stated in their meeting with vendors that a precertified module would have to be recertified once it is installed in order to ensure it is both operable and interoperable. PSTG recommends CMS explore innovative ways to create a multi-state vendor and state repository. We also recommend: A structured pilot process that formalizes and publicizes processes, lessons learned, and how those lessons change future processes. Page 27

31 Building learning communities on key areas of modern development, such as Agile, modularity, performance measurement, and healthcare use cases that focus on improving results. Creating a similar technical assistance portal and repository for MMIS modularity, as has been established for the ACA s Marketplace and Premium Stabilization Programs. The Registration for Technical Assistance Portal (REGTAP) provides technical assistance, training through webinars and other approaches, and user groups related to Marketplace and Premium Stabilization guidance and operations across a wide range of topical areas, as shown in Figure 2. Expand use of and focus on the ONC-established State Innovation Model Health IT Resource Center that provides a comprehensive set of tools to provide technical support and expertise to SIM states, and support health IT innovation in care delivery and payment systems. Medicaid state agencies and Figure 2: REGTAP - Registration for Technical Assistance Portal vendors could benefit from more structured technical assistance and collaboration with ONC to broaden the vision of MMIS and adoption of health IT. This will promote exchange and interoperability so that health information is available where and when it matters. Medicaid staff and vendor staff would benefit from further collaboration of CMMI, the Centers of Medicaid and Children s Health Insurance Program (CHIP) Services, and ONC to develop specialized technical assistance and comprehensive online health IT tools and resources to document and diffuse SIM lessons learned in the use of health IT in advancing innovation in and beyond SIM projects. 2. New MMIS - is to provide more efficient, economical, and effective administration of the state plan ( (b)(1)) This section proposes to modify 42 CFR (b)(1) to increase MITA maturity while considering the industry standards and protocols needed, as well as the time frames to balance change on the path to seamless process and cost efficient interoperability for all entities impacted. Page 28