NASMD MITA

1
Transitioning to SOA
Bob Guenther CMS
NASMD Conference Washington, DC November 14, 2008
2
Today
Medicaid processes more health claims than any
other payer
On some of the oldest information systems still
in continuous use.
3
Why?

• New MMIS costs range from
• 50 100 million
• Now more than ever, this cost is outside State
  budget allowances
• MMIS solutions limited to all-or-nothing
• Full system replacements viewed as risky
• Limited alternatives to rip and replace

4
Drivers for Change

• Regulatory Changes (X12 5010/ICD-10)
• Contract Lifecycle
• Improving the Business of Medicaid
• Making program more cost effective
• Improving outcomes
• Paying claims more efficiently
• Dawning of the HIT/HIE era

5
What to do?

• Nothing
• not a practical option change is inevitable
• Continue Full System Replacement
• perhaps practical but very complicated and
  expensive
• Begin Incremental System Replacement using SOA
  and MITA
• interesting, tell me more

6
Today

• Tightly-coupled systems are difficult and costly
  to update and generally must be ripped and
  replaced
• Challenging to isolate functionality to replace
  with new technology
• Changes are not isolated so ripple affect
  causes programming challenges
• Proprietary data definitions and formats hinder
  interoperability
• software applications dependent on IT platform
  and eachother

6
7
With SOA

• Prioritize business functionality that most needs
  to be modernized
• Effect an incremental, managed approach in
  porting this functionality away from the
  mainframe environment and into a more flexible,
  modern, distributed environment
• Improve/move functionality as business
  requirements dictate and budget allows.

8

• SOA Concept

9
Business Functionality
Core Business Function
Business Processes
Determine Pricing Calculate Tax
Rates Environmental Regulations
Sell Gas by the Gallon
Workflow Mgmt Supply Chain Mgmt Health Regulation
Compliance
Sell Food From a Menu
Specialty Services Practice Management Health
Plan Billing
Sell Cleanings Every 6 Months
10
Medicaid Functionality
Core Business Functions
Business Processes
Provider Enrollment Provider Communication Provide
r Information
Manage Providers
Member Eligibility Member Outreach Member
Disenrollment
Manage Beneficiaries
Edit/Audit Claim Price Claim Prepare EOB
Process Claims
11
SOA Summary

• Decouples things that change frequently from
  things that do not
• Allows variables to be changed independent of
  core functionality
• Isolates business functions from hard-wired
  technical solutions and organizes them into
  discreet business processes
• Exposes business processes as business services
  with interface definitions and service contracts

12

• Enter MITA

13
MITA

• Designed to leverage the business focus of
  Service Oriented Architecture
• Standardizes core business functionality
• Standardizes shared date to enable
  interoperability
• Allows flexibility for State-specific variables

14
Sample MITA business services

• Enroll Provider
• Disenroll Provider
• Inquire Provider Information
• Manage Provider Information
• Determine Member Eligibility
• Enroll Member

• Disenroll Member
• Inquire Member Information
• Manage Member Information
• Authorize Service
• Inquire Claim Status
• Manage Claim Attachment

15
Incremental Implementation Strategy

• Business Service Selection
• Technical Service Selection
• Infrastructure Requirements
• Tool Requirements
• Resource Requirements
• Pilot
• Lessons Learned
• Iteration

16
Business Service Selection

• Identify the to-be candidate business
  processes. Identify a non-critical but visible
  set of services.
• Select services that can be piloted relatively
  easily.
• Constrain the selection so that it can be
  achieved and success can be measured.

17
Technical Service Selection

• Identify technical services needed for all
  business services selected by
• Using MITA repository solution sets
• Developing use cases for all business services
  selected
• Determine if any technical services already exist
• Identify technical services that need to be
  developed

18
Infrastructure Requirements

• Infrastructure products
• Web service platform
• SOAP runtime server
• UDDI registries
• Trust services
• Service Monitoring
• Considerations
• Functionality
• Performance scalability
• Standards
• Interoperability

19
Tool Requirements

• UML Modeling tools that support XMI
• WSDL development tools
• Client service development tools (IDEs)
• XML tools
• Web service testing, diagnostic, and optimization
  tools
• Code Generators

20
Resource Requirements

• Staff
• Required skill mix (skills and number)
• Required training
• Identify staff availability
• Estimate Timeline based on
• Staff availability
• Budget availability
• Procurement availability and schedule
• Estimate cost for project based on summation of
  following costs
• Business service development
• Technical service development
• Infrastructure procurement
• Tool procurement
• Determine if Budget is available and if timeline
  meets management requirements. Rework all of the
  above activities.

21
Test

• After development of project is complete, test
  the new SOA solution. The test should as close as
  possible
• Run in the operational environment
• Use operational data
• Use operations staff and procedures
• Compare results with legacy results if possible

22
Lessons Learned

• Analyze project and test results
• Evaluate results against the success criteria
• Document lessons learned
• Update all plans, processes, and procedures based
  on results of implementing project and executing
  pilot

23
Iterate

• Based on the lessons learned, identify candidates
  for the next project.
• Next project should have a broader scope then the
  previous.
• As success builds and staff becomes more
  experienced, more critical business services can
  be selected.
• Restart the process by starting with the identify
  business service activity again.

24
What Does a Legacy Wrapper Include?

• Web Service Interface interface to the outside
  world that matches the WSDL for the specific
  Business service
• Web Service adapter translates SOAP request to
  proprietary API supported by the legacy
  application.
• 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
• Legacy Application orchestration orchestrate
  multiple legacy applications in order to achieve
  the functionality of the MITA Business service.

25
Starter Kit

• In the next year CMS along with the States, MITA
  team, HL7 MITA Project, and PSTGs TAC will be
  developing a Starter Kit for States beginning to
  implement MITA
• The Starter Kit will include
• Sample MITA business services
• Sample MITA Technical Services
• Training Packages
• White papers

26
Training Packages

• The following training packages will be developed
• Business Process Modeling
• Business Service Development
• Solution Set Development