MMIS - MITA Bob Guenther


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MMIS - MITA Bob Guenther

  1. 1. NASMD Conference Washington, DC November 14, 2008 Transitioning to SOA Bob Guenther CMS
  2. 2. Today Medicaid processes more health claims than any other payer… On some of the oldest information systems still in continuous use.
  3. 3. Why? <ul><li>New MMIS costs range from </li></ul><ul><li>$50 – $100 million </li></ul><ul><li>Now more than ever, this cost is outside State budget allowances </li></ul><ul><li>MMIS solutions limited to “all-or-nothing” </li></ul><ul><li>Full system replacements viewed as risky </li></ul><ul><li>Limited alternatives to rip and replace </li></ul>
  4. 4. Drivers for Change <ul><li>Regulatory Changes (X12 5010/ICD-10) </li></ul><ul><li>Contract Lifecycle </li></ul><ul><li>Improving the Business of Medicaid </li></ul><ul><ul><li>Making program more cost effective </li></ul></ul><ul><ul><li>Improving outcomes </li></ul></ul><ul><ul><li>Paying claims more efficiently </li></ul></ul><ul><li>Dawning of the HIT/HIE era </li></ul>
  5. 5. What to do? <ul><li>Nothing </li></ul><ul><ul><li>not a practical option – change is inevitable </li></ul></ul><ul><li>Continue Full System Replacement </li></ul><ul><ul><li>perhaps practical but very complicated and expensive </li></ul></ul><ul><li>Begin Incremental System Replacement using SOA and MITA </li></ul><ul><ul><li>interesting, tell me more… </li></ul></ul>
  6. 6. Today <ul><li>Tightly-coupled* systems are difficult and costly to update and generally must be ripped and replaced </li></ul><ul><li>Challenging to isolate functionality to replace with new technology </li></ul><ul><li>Changes are not isolated so “ripple affect” causes programming challenges </li></ul><ul><li>Proprietary data definitions and formats hinder interoperability </li></ul><ul><li>* software applications dependent on IT platform and eachother </li></ul>
  7. 7. With SOA <ul><li>Prioritize business functionality that most needs to be modernized </li></ul><ul><li>Effect an incremental, managed approach in porting this functionality away from the mainframe environment and into a more flexible, modern, distributed environment </li></ul><ul><li>Improve/move functionality as business requirements dictate and budget allows. </li></ul>
  8. 8. <ul><li>SOA Concept </li></ul>
  9. 9. Business Functionality Sell Gas by the Gallon Sell Food From a Menu Sell Cleanings Every 6 Months Determine Pricing Calculate Tax Rates Environmental Regulations Workflow Mgmt Supply Chain Mgmt Health Regulation Compliance Core Business Function Business Processes Specialty Services Practice Management Health Plan Billing
  10. 10. Medicaid Functionality Manage Providers Manage Beneficiaries Process Claims Provider Enrollment Provider Communication Provider Information Member Eligibility Member Outreach Member Disenrollment Core Business Functions Business Processes Edit/Audit Claim Price Claim Prepare EOB
  11. 11. SOA Summary <ul><li>Decouples things that change frequently from things that do not </li></ul><ul><li>Allows variables to be changed independent of core functionality </li></ul><ul><li>Isolates business functions from “hard-wired” technical solutions and organizes them into discreet business processes </li></ul><ul><li>Exposes business processes as business services with interface definitions and service contracts </li></ul>
  12. 12. <ul><li>Enter MITA… </li></ul>
  13. 13. MITA <ul><li>Designed to leverage the business focus of Service Oriented Architecture </li></ul><ul><li>Standardizes core business functionality </li></ul><ul><li>Standardizes shared date to enable interoperability </li></ul><ul><li>Allows flexibility for State-specific variables </li></ul>
  14. 14. Sample MITA business services <ul><ul><li>Enroll Provider </li></ul></ul><ul><ul><li>Disenroll Provider </li></ul></ul><ul><ul><li>Inquire Provider Information </li></ul></ul><ul><ul><li>Manage Provider Information </li></ul></ul><ul><ul><li>Determine Member Eligibility </li></ul></ul><ul><ul><li>Enroll Member </li></ul></ul><ul><ul><li>Disenroll Member </li></ul></ul><ul><ul><li>Inquire Member Information </li></ul></ul><ul><ul><li>Manage Member Information </li></ul></ul><ul><ul><li>Authorize Service </li></ul></ul><ul><ul><li>Inquire Claim Status </li></ul></ul><ul><ul><li>Manage Claim Attachment </li></ul></ul>
  15. 15. Incremental Implementation Strategy <ul><ul><li>Business Service Selection </li></ul></ul><ul><ul><li>Technical Service Selection </li></ul></ul><ul><ul><li>Infrastructure Requirements </li></ul></ul><ul><ul><li>Tool Requirements </li></ul></ul><ul><ul><li>Resource Requirements </li></ul></ul><ul><ul><li>Pilot </li></ul></ul><ul><ul><li>Lessons Learned </li></ul></ul><ul><ul><li>Iteration </li></ul></ul>
  16. 16. Business Service Selection <ul><li>Identify the “to-be” candidate business processes. Identify a non-critical but visible set of services. </li></ul><ul><li>Select services that can be piloted relatively easily. </li></ul><ul><li>Constrain the selection so that it can be achieved and success can be measured. </li></ul>
  17. 17. Technical Service Selection <ul><li>Identify technical services needed for all business services selected by: </li></ul><ul><ul><li>Using MITA repository solution sets </li></ul></ul><ul><ul><li>Developing use cases for all business services selected </li></ul></ul><ul><li>Determine if any technical services already exist </li></ul><ul><li>Identify technical services that need to be developed </li></ul>
  18. 18. Infrastructure Requirements <ul><li>Infrastructure products </li></ul><ul><ul><li>Web service platform </li></ul></ul><ul><ul><li>SOAP runtime server </li></ul></ul><ul><ul><li>UDDI registries </li></ul></ul><ul><ul><li>Trust services </li></ul></ul><ul><ul><li>Service Monitoring </li></ul></ul><ul><li>Considerations </li></ul><ul><ul><li>Functionality </li></ul></ul><ul><ul><li>Performance & scalability </li></ul></ul><ul><ul><li>Standards </li></ul></ul><ul><ul><li>Interoperability </li></ul></ul>
  19. 19. Tool Requirements <ul><li>UML Modeling tools that support XMI </li></ul><ul><li>WSDL development tools </li></ul><ul><li>Client & service development tools (IDEs) </li></ul><ul><li>XML tools </li></ul><ul><li>Web service testing, diagnostic, and optimization tools </li></ul><ul><li>Code Generators </li></ul>
  20. 20. Resource Requirements <ul><li>Staff </li></ul><ul><ul><li>Required skill mix (skills and number) </li></ul></ul><ul><ul><li>Required training </li></ul></ul><ul><ul><li>Identify staff availability </li></ul></ul><ul><li>Estimate Timeline based on: </li></ul><ul><ul><li>Staff availability </li></ul></ul><ul><ul><li>Budget availability </li></ul></ul><ul><ul><li>Procurement availability and schedule </li></ul></ul><ul><li>Estimate cost for project based on summation of following costs: </li></ul><ul><ul><li>Business service development </li></ul></ul><ul><ul><li>Technical service development </li></ul></ul><ul><ul><li>Infrastructure procurement </li></ul></ul><ul><ul><li>Tool procurement </li></ul></ul><ul><li>Determine if Budget is available and if timeline meets management requirements. Rework all of the above activities. </li></ul>
  21. 21. Test <ul><li>After development of project is complete, test the new SOA solution. The test should as close as possible: </li></ul><ul><ul><li>Run in the operational environment </li></ul></ul><ul><ul><li>Use operational data </li></ul></ul><ul><ul><li>Use operations staff and procedures </li></ul></ul><ul><li>Compare results with legacy results if possible </li></ul>
  22. 22. Lessons Learned <ul><li>Analyze project and test results </li></ul><ul><li>Evaluate results against the success criteria </li></ul><ul><li>Document lessons learned </li></ul><ul><li>Update all plans, processes, and procedures based on results of implementing project and executing pilot </li></ul>
  23. 23. Iterate <ul><li>Based on the lessons learned, identify candidates for the next project. </li></ul><ul><li>Next project should have a broader scope then the previous. </li></ul><ul><li>As success builds and staff becomes more experienced, more critical business services can be selected. </li></ul><ul><li>Restart the process by starting with the identify business service activity again. </li></ul>
  24. 24. What Does a Legacy Wrapper Include? <ul><li>Web Service Interface – interface to the outside world that matches the WSDL for the specific Business service </li></ul><ul><li>Web Service adapter – translates SOAP request to proprietary API supported by the legacy application. </li></ul><ul><li>Data Transformation – ability to accept MITA XML messages and to transform them into messages that are recognized by the legacy application. Also the inverse transformation to go from internal format to MITA XML </li></ul><ul><li>Legacy Application orchestration – orchestrate multiple legacy applications in order to achieve the functionality of the MITA Business service. </li></ul>
  25. 25. Starter Kit <ul><li>In the next year CMS along with the States, MITA team, HL7 MITA Project, and PSTG’s TAC will be developing a Starter Kit for States beginning to implement MITA </li></ul><ul><li>The Starter Kit will include </li></ul><ul><ul><li>Sample MITA business services </li></ul></ul><ul><ul><li>Sample MITA Technical Services </li></ul></ul><ul><ul><li>Training Packages </li></ul></ul><ul><ul><li>White papers </li></ul></ul>
  26. 26. Training Packages <ul><li>The following training packages will be developed </li></ul><ul><ul><li>Business Process Modeling </li></ul></ul><ul><ul><li>Business Service Development </li></ul></ul><ul><ul><li>Solution Set Development </li></ul></ul>