reference architecture for medicaid - nescso.org• reference architecture for medicaid enterprise...
TRANSCRIPT
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