Medicaid and CHIP Eligibility and Enrollment System Accelerators to a Successful, On-­‐Time Go Live Jessica P. Kahn Senior Technical Advisor CMCS/Data Systems Group What are System Accelerators? •  System accelerators are strategies to expedite state’s eligibility and enrollment system changes and redesigns that can: –  Get states’ systems ready per Affordable Care Act requirements by October 1, 2013 •  Leap-­‐frog many of the tradiFonal one by one by one by one steps •  Save staff Fme/resources •  Reduce costs •  Promote standardizaFon where appropriate and focus innovaFon where needed Why are they needed? •
•
•
•
•
The clock is Fcking Budgets are Fght Resources are tapped SoluFons are available Failure is not an opFon for the state or CMS Partner Up! •  Advantages: –  Fulfills the reusability requirement in the 7 standards & condiFons –  Pools brainpower and staff resources, experience and experFse across states –  Reduces each state’s 10% match total –  Reduces risk of failure Partner Up! •  Partnership could be based upon having a shared vendor and/or on having a similar IT plaWorm and/or similar intended goals/
outcomes (e.g. horizontal integraFon) •  ParFcipaFng states must agree to limit unnecessary variaFon in requirements •  Partnering works best with clear roles and defined processes to keep the ball moving Partner Up! #1 •  MulF-­‐State Early Design & Development –  Example-­‐ 14 states with a shared vendor for design/
development for HITECH –  Each state enters into or modifies an exisFng contract with the same vendor and conduct joint design and requirements development and tesFng –  States’ use of the soluFon is handled through an enterprise license by the vendor –  This model could support a sole source jusFficaFon if a state seeks to join an exisFng mulF-­‐state partnership and could show reduced costs and Fme savings Partner Up! #1 •  Samples, arFfacts in the CALT –  Core/lead APD for the MAPIR HITECH 14 state collaboraFon –  Sample mulF-­‐state governance document –  Sample le`ers of agreement between states –  Sample change management process for mulF-­‐state IT partnership •  CMS Technical Assistance on idenFficaFon of a potenFal partner, help with the structure, logisFcs and funding requests Partner Up #2 •  MulF-­‐State Piggy Back –  The procuring state pursues a (possibly sole source) contract with the vendor used by another state that has already completed compeFFve procurement of the soluFon, using the same/
similar contract, soluFon descripFon, requirements, concept of operaFons and soaware selecFon –  A sole source jusFficaFon could be based upon Fme and cost savings and reduced risk of failure Partner Up #2 •  Samples, arFfacts in the CALT –  Sample RFP and contract language that reflects intent to partner with other states –  Sample mulF-­‐state governance document –  Sample change management process for mulF-­‐
state IT partnership •  CMS Technical Assistance on idenFficaFon of a potenFal partner, help with the structure, logisFcs and funding requests Partner Up #3 •  MulF-­‐State Post-­‐Award Alignment –  Two or more states who have already separately procured the same vendor(s) share a single IT infrastructure, conduct joint JAD, design and tesFng. –  This model is best enabled if the RFP and contract language includes an affirmaFve requirement to partner with another state on these tasks Partner Up #3 •  Samples, arFfacts in the CALT –  Sample RFP and contract language to enable this model –  Sample mulF-­‐state governance document –  Sample change management process for mulF-­‐
state IT partnership •  CMS Technical Assistance on idenFficaFon of a potenFal partner, help with the structure, logisFcs and funding requests Partner Up #4 •  MulF-­‐State HosFng –  The securing state uses a host state’s plaWorm, using a SaaS model or one where the host state’s eligibility system completes the eligibility determinaFon process on behalf of the securing state –  The securing state would “buy” the soluFon as a service or directly as a hosted, mulF-­‐tenant soluFon. Partner Up #4 •  Samples, arFfacts in the CALT –  Sample APDs for system hosFng –  Sample RFP language for a mulF-­‐tenant hosted soluFon –  Sample mulF-­‐state governance document –  Sample change management process for mulF-­‐state IT partnership •  CMS Technical Assistance on idenFficaFon of a potenFal partner, help with the structure, logisFcs and funding requests MulM-­‐State Partnership Support •  CMCS Technical Assistance •  In the Medicaid Community in CALT, there is now an Accelerators Folder and a sub-­‐folder with the mulF-­‐state partnership arFfacts Reuse & Recycle •  With any reuse, some configuraFon and integraFon will sFll be needed. But esFmates of cost and Fme savings around reuse of key components are very promising. •  States should be looking for soluFons with a minimal degree of customizaFon needed •  RFP and Contract Language is KEY •  Reuse is one of the 7 Standards and CondiFons for Medicaid IT funding Reuse & Recycle #1 •  MAGI Business Rules –  Vendors are developing them for states •  Plug for mulF-­‐state partnership with shared vendor! –  CMS is developing them for the Federally-­‐
facilitated Exchange and will share them with States –  Reusing MAGI rules could reduce costs and Fme compared to self-­‐developed by up to 85% Reuse & Recycle #2 •  Eligibility DeterminaFon and/or DeterminaFon and Enrollment Business Process Models –  Helpful to reuse where there are similariFes (integraFon with human services or not, etc) •  From another state (directly or through a shared vendor or via the CALT) •  From the FFE (though these will not include the enrollment steps for Medicaid/CHIP) Reuse & Recycle #3 •  Requirements –  Sub-­‐folder in the Accelerator folder Medicaid Community in CALT called Requirements: •  A date-­‐stamped Word document with the CALT hyperlinks to states’ completed requirements-­‐ no state should start from scratch! Reuse & Recycle #4 •  Other Shared Vendor and/or Federal Assets –  Completed interface specificaFons with the Data Services Hub –  Applicant portal code/wireframes –  Test scenarios and use cases Reuse & Recycle Support •  CALT bi-­‐monthly inventory list-­‐serve messages –  AcFve links to content that has been added to the Exchange and Medicaid State CollaboraFve CommuniFes –  Full inventory list available in respecFve communiFes •  CALT Medicaid State Community –  Accelerators Folder –  State Medicaid IT Review Folder contains subfolders with Architectural, Project, Design arFfacts –  Discussions Tab -­‐ Vendor Forums established as a way to collaborate, communicate and exchange informaFon and ideas –  Early Innovator Grantees Folder •  CMCS CALT Stewardship Approach/TA •  Learning CollaboraFves •  Vendor-­‐sponsored User Groups MAGI-­‐in-­‐a-­‐Box #1 •  A “MAGI in a box” soluFon could be a cloud-­‐
based service offered by another state’s vendor or an independent vendor of just the MAGI rules service or an “integratable” open source MAGI rules engine –  RFPs need to allow for this opFon –  Doesn’t preclude other concurrent E&E system modernizaFon if the MAGI in a box soluFon is external (interfaced with the Data Services Hub) MAGI-­‐in-­‐a-­‐Box Support •  CMS will post its MAGI rules = public domain = vendors can take for their state contract work and/or to build a hosted soluFon product –  Jrules and english/human readable formats •  CMCS Technical Assistance on idenFfying and integraFng these types of soluFons Taking a Phased Approach •  The decision to adopt a phase approach starts with the RFP and conFnues through the Design Gate Review, etc •  Determine what are the minimal requirements for October 1, 2013, what could go in the next phase, etc. Taking a Phased Approach #1 •  Take the legacy system’s rules engine and make it external, add the new rules and have the legacy system use it. SoluFon includes other requirements related to the Data Services Hub interface, etc. –  More feasible than a total redesign for 10/1/13 –  Minimizes the Phase 1 asks of the vendor and focuses Phase 1 on less of the customizaFon-­‐heavy tasks/
more that can be reused –  Doesn’t compromise the to-­‐be roadmap for a more modernized overall system by 12/31/15 Taking a Phased Approach #2 •  Change the rules in the exisFng legacy system for 10/1/13. SoluFon has to include other requirements e.g. electronic verificaFons, the Data Services Hub interface, etc. –  Depends upon the funcFonality of the “legacy” system –  Approach s"ll needs to be consistent with the 7 Standards and CondiFons –  More feasible than a total redesign for 10/1/13 –  Minimizes the Phase 1 asks of the vendor and focuses Phase 1 on less of the customizaFon-­‐heavy tasks/more that can be reused –  Doesn’t compromise the to-­‐be roadmap for a more modernized overall system by 12/31/15 Phased Approach Supports •  Examples of RFP and contract language for a phased approach •  Examples of approved APDs from states taking a phased approach •  CMCS Technical Assistance AcceleraMon Process Enablers •  Starts with procurement –  Are the terms explicit around phased approach, partnering and reuse of other states’ assets? –  Do the RFPs allow bidders to submit alternaFve approaches? –  Fixed price & “we can add anything at no addiFonal cost to respond to yet unknown Federal requirements” –  Why require so much onsite support? •  States’ willingness to reduce the degree of customizaFon & mold their work flows to exisFng system requirements and capabiliFes CMCS Technical Assistance •
•
•
•
•
Greater CALT clarity & tools State and arFfact matching LogisFcs, facilitaFon of collaboraFve efforts Vendor communicaFon at the naFonal level Samples, tools, templates for the “how” CMCS Technical Assistance •  Roll-­‐Out Plan –  All-­‐State webinar –  Calls with states with shared vendors –  One on one calls with states to talk about accelerators and potenFal partnerships –  Calls with states idenFfied to be in the same phase of the system design life cycle (e.g. pre-­‐RFP, waiFng for RFP bids, newly post-­‐award, in design, etc) –  NaFonal vendor engagement QuesMons/SuggesMons •  Follow-­‐up with your CMS Medicaid/CHIP eligibility and enrollment systems lead and/or Jess Kahn Reuse from CMS IT Systems PerspecMve Mark Oh CMS/OIS Re-­‐use OpMons (Systems) •  Three categories of Re-­‐use from Systems PerspecFve –  Tier 1: Share Documents, Processes and Knowledge –  Tier 2: Share & Reuse Code, Library and Packages –  Tier 3: Jointly procure hardware/soaware and manage deployments Tier 1 Tier 2 Tier 3 Available CMS IT Reuse Components for Medicaid/CHIP •  Tier 1 (Knowledge based reuse of System Components) –
–
–
–
Service Notes, Design Pa`erns & Messaging Architecture Test Data and Test Scenarios Security Standards & IntegraFons Common Language Business Rules •  Tier 2 (Sharing of codes and technical Services –
–
–
–
HUB Service Code & Code Repository (Subversion) CI/CD components (Jenkins, Sonar, Nexus, etc) HUB Technical Services (i.e. transfer of a`achments, logging, etc) WSDLs & XSDs •  Tier 3 (Hosted by CMS, offered as SaaS) –
–
–
–
–
Business Rules (Authoring & Management) Repository System New CollaboraFon PlaWorm (zONE – Drupal based) Technical CollaboraFon PlaWorm (CALT) CMS Service Catalog CMS Cloud CompuFng Environment ConsideraMons for State(s) making Systems reuse decision •  Obtain informaFon for available products (Tier 1, Tier 2, & Tier 3 re-­‐use levels) •  IdenFfy effort required to use available products •  IdenFfy cost savings for operaFons/maintenance •  Conduct Risk Assessment to schedule, cost, and resources •  IdenFfy how CMS will coordinate re-­‐use of products •  IdenFfy limitaFons introduced to the state by going with the re-­‐use components