Reference Architecture for MedicaidDave Hill

September 18, 2017

Problem• $5B spent on Medicaid IT annually

• State Medicaid Enterprise Systems (MES) are antiquated, monolithic mainframe systems, developed organically

• Very little reuse, lots of customization per state, little interoperability

• Dominated by large, entrenched vendors resulting in limited competition, big bang deployments

• Smaller vendors can’t break in• Fragmented market is not attractive to new vendors• Market is demand-driven, not supply-driven

• MITA 3.0 promotes modularity, but does not provide adequate technology and information guidance

• Most states need that guidance to succeed

Proposed Solution

• Reference Architecture for Medicaid Enterprise Systems• Consistent set of architectural best practices• Common vocabulary with which to discuss implementations• Architectural templates for the Medicaid domain• Asset base and common shared services that modules can draw upon

• Service definitions for Medicaid functional areas• Breakdown functional areas into individual microservices• Create service definitions for each microservice

Proposed Solution

• Poplin Working Group• Under the MITA Governance Board overseeing next version of MITA• States: VT, CA, WV, NM• Vendors: CNSI• Real working group

• Weekly meetings are very tactical (scrums)• Two-week sprints• Executive-level commitment of 1 to 2 FTE (6 FTE+ total so far)

• Monthly status meeting• CA, WY, RI, Molina, Oracle, Deloitte, Wipro

• Working collaboratively with ONC, MITA-TAC, MTA, PSTG

Functional Areas - Divide and Conquer• Provider Management (CNSI)

• Screening• Enrollment

• Claims• Pharmacy • Financial Management• Member Management

• Eligibility• Enrollment

• Third Party Liability• Case Management (Vermont)

• Interaction with Eligibility & Enrollment

• Data Warehouse / Business Intelligence / Analytics• Managed Care Enrollment Broker• Shared Services (MITRE)

• Service registration, service discovery, messaging, security

5

Service definitionsactively being

developed today

6

•Four components•Business process diagrams•Object definitions / diagrams•Resource definitions•API definitions

Service Definitions

Adopting the Reference Architecture into MES

MITA TA&IA

Certification

Pre-certification

State RFP

Working Group

Incremental updates

The Time is Now!

8

• A few states have already started implementing modular architectures

• Using incompatible approaches

• More states are contemplating and designing modular architectures

• The rest are looking for guidance and trends

States are ready and hungry for this transition.

The longer we wait, the more isolated and fragmented the Medicaid enterprise will become.

projectpoplin.org#POPLIN

Backup

11

Business Process Diagrams

12

Object Definitions

• Structural diagrams and descriptions

• Represent the entity composition and

relationships of a system

• Sys/UML Diagrams

• Class / Block / Object

• Composite Structure / Internal Block

13

• Name of Object/Resource• Based on parent Object if inherited

• Description of Object/Resource• List of fields in Object/Resource

• Name and type of field• Optional or required• Relationships• Description of field

Resource Definitions

14

• API Overview• General description of the purpose of the API and notes that

should be applied generally by clients when accessing the API.• List of API endpoints

• Verb for the endpoint (e.g. GET, PUT, POST, DELETE for RESTful services) followed by the relative URL for the endpoint

• Supported data formats• Any header fields that are required• List of parameters that are required

• Description and type• List or range of valid values, if appropriate• Optional or required

• List of return values• Examples

• Calls in supported formats, return value formats, and common errors

API Definitions

15

API Definitions - Example

16

API Definitions - Example