1

NASMD ConferenceWashington, DCNovember 14, 2008

Transitioning to SOA

Bob GuentherCMS

2

TodayMedicaid 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…

66

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

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

Sell Gas by the Gallon

Sell Food From a Menu

Sell Cleanings Every 6 Months

Determine PricingCalculate Tax Rates

Environmental Regulations

Workflow MgmtSupply Chain Mgmt

Health Regulation Compliance

Core Business Function Business Processes

Specialty ServicesPractice Management

Health Plan Billing

10

Medicaid Functionality

Manage Providers

Manage Beneficiaries

Process Claims

Provider EnrollmentProvider Communication

Provider Information

Member EligibilityMember Outreach

Member Disenrollment

Core Business Functions Business Processes

Edit/Audit ClaimPrice Claim

Prepare EOB

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

1. Business Service Selection

2. Technical Service Selection

3. Infrastructure Requirements

4. Tool Requirements

5. Resource Requirements

6. Pilot

7. Lessons Learned

8. 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 PSTG’s 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