MITA Business Processes, Technical Functions & Services

1. MITA Business Processes, Technical Functions & Services Monday Quarter 2 Presentation May 18, 2009

2. Technical / Business Services: Where does one start and/or stop and the other take over?

3. Foundation Concepts

4. HL7 corresponds to the conceptual definition of an application-to-application interface placed in the seventh layer of the OSI model. International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference model Levels 7 6 5 4 3 2 1

6. MITA Business Process. MITA Technical Functions International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference model Levels 7 6 5 4 3 2 1

7. NHIN Services

8. MITA Basics

9. – MITA guidelines apply; FFP available – Entity is encouraged to follow MITA guidelines – May exchange information; may influence MITA or vice versa MITA Medicaid Enterprise Departmentof HomelandSecurity CDC CMS Notificationsand Alerts Notificationsand Alerts MSIS Data; Dual Eligibility License Board Other Agency FEA FHA ONC Interface Interface Guidelines;Directives Standards of Interoperability; EHR MITA Business Process#1 Interface Other Payer RHIO Interface Interface MITA Business Process#2 MITA Business Process#3 Interface Use Standards; Develop New Ones Interface Standards Organization Interface Interface Provider SURSor Fraud Contractor Information Exchange BenefitManager State Unemploy-ment Agency

10. Business Process Model v2.01 Member Management Determine Eligibility Inquire Member Eligibility Enroll Member Perform Population & Member Outreach Disenroll Member Manage Applicant & Member Communication Manage Member Information Manage Member Grievance & Appeal Contractor Management Operations Management Program Management 8 9 19 26 Authorize Referral Inquire Payment Status Draw and Report FFP Manage F-MAP Inquire Contractor Information Award Administrative or Health Services Contract Authorize Service Manage Drug Rebate Manage Rate Setting Manage FFP for Services Manage Contractor Information Close out Administrative or Health Services Contract Authorize Treatment Plan Manage Estate Recovery Manage FFP for MMIS Manage State Funds Manage Contractor Communication Manage Administrative or Health Services Contract Apply Attachment Prepare COB Formulate Budget Manage 1099s Perform Contractor Outreach Produce Administrative or Health Services RFP Apply Mass Adjustment Prepare EOB Develop Agency Goals & Objectives Maintain State Plan Support Contractor Grievance and Appeal Audit Claim-Encounter Manage Recoupment Develop & Maintain Program Policy Develop & Maintain Benefit Package Edit Claim-Encounter Manage Cost Settlement Maintain Benefits- Reference Information Perform Accounting Functions Manage TPL Recovery Prepare Medicare Premium Payment Designate Approved Services & Drug Formulary Monitor Performance & Business Activity Price Claim – Value Encounter Manage Payment Information Monitor Performance & Business Activity Manage Program Information Prepare Remittance Advice-Encounter Report Calculate Spend-Down Amount Dev. & Manage Perform. Measures & Reporting Prepare Provider EFT-check Prepare Capitation Premium Payment Prepare Premium EFT-check Prepare Member Premium Invoice Prepare Health Insurance Premium Payment Prepare Home & Community Based Services Payment Program Integrity Management Care Management Business Relationship Management Provider Management 2 4 4 7 Identify Candidate Case Manage Case Establish Case Manage Medicaid Population Health Establish Business Relationship Terminate Business Relationship Enroll Provider Manage Provider Communication Manage Case Manage Registry Manage Business Relationship Manage Business Relationship Comm. Disenroll Provider Manage Provider Grievance & Appeal Inquire Provider Information Perform Provider Outreach Manage Provider Information

11. Inconsistent use of the word “capabilities” in TA Not consistent with taxonomy of the business architecture BA -> BP -> ML -> BS -> SS TCM -> ML -> TS -> SS Achieves consistency Business process equivalent to technical function BP -> ML -> BS -> SS TF -> ML -> TS -> SS Business Services Business Services Technical Functions Technical Capability Matrix Technical Services Technical Services Application Architecture Application Architecture Technology Standards Technology Standards Solution Sets Solution Sets Technical Functions Framework 2.0 Framework 2.0 Plus

12. Technical Functions • Examples of technical functions are Authentication and Authorization. • Interfaces to technical functions modeled as triggers and results. • Technical function only exists to enable the business processes. • Initially, technical functions will be defined using a template but like the business processes will ultimately be based on UML models. • Technical function maturity level pairs (function + capability) will result in a technical service. • The technical functions are being defined by the Private Sector Technology Group’s Technical Architecture Committee (TAC).

13. Artificially linked technology to MITA Business maturity Did not allow flexibility for industry standards Did not provide flexibility in designing technical services/solution sets One to many maturity levels for each technical functions Maturity levels are specified by letter (A, B, C) Maturity levels only have meaning within the scope of that particular technical function Provides flexibility Framework 2.0 Framework 2.0 Plus Technical Function Technical Function Maturity Levels A B ….. Z Maturity Levels Technical Services 1 2 3 4 5 Technical Services Technical Maturity LevelsAre Based on Industry Standards

14. Benefits of New Maturity Level Approach • Technical maturity no longer maps technology to the five levels of business maturity. Instead each technical function is defined with its own independent maturity levels. • The technical function may have one or many levels of maturity based on the industry standards for that particular technical function. • This allows a technical service to be based on the industry derived capabilities/maturity levels. • Solution sets for business services can make use of a heterogeneous mix of technical maturity levels based on the value that they bring to the business process.

15. Technical Services Update • There have been no structural changes to the concept of Technical Services. • A service can be defined for each technical function—maturity level pair. • The methodology used to define the technical service is the same as for business services, i.e., HL7. • The HL7 Reference Information Model will be used in the development of the technical service interfaces whenever possible.

16. Application Architecture Application Architecture Updates • The application architecture captures technical infrastructure needs that can not be defined as a technical function/technical service. An example of this is an enterprise service bus. • Each element of the application architecture will have technical maturity levels and technical solution sets. Technical Service Technical Service Business Service End User Technical Service Technical Service

17. Technical Solution Sets • The role of technical solution sets remains unchanged. • There may be one or many technical solution sets for each technical function—maturity level or application element-maturity level pair. • A solution set has the metadata describing a specific implementation approach.

18. Business Process Technical Function A Technical Function B Business Process Technical Function Technical Function Maturity Levels Maturity Levels Maturity Levels Maturity Levels Maturity Levels 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 A B A B C D Maturity Levels Business Service Technical Service Technical Services 1 2 3 4 5 Business Service Technical Services Technical Solution Set Business Solution Set Technical Service Business Solution Set Technical Solution Set Technical Solution Set Technical Solution Set Technical Maturity Levels Framework 2.0 Framework 2.0 Plus

19. Relation to Business Service Solution Sets • Business services solution sets contain pointers to all technical function—maturity level pairs that are used by the particular implementation of the business service. • Allows maximum flexibility for the implementer to use the mix of technology while maintaining a loose inventory of technology available for use.

20. Framework 2.0 Sporadically mentioned Process same as Business process self assessment Resulted in an assessment of the technical maturity in terms of the five levels of MITA Business Maturity Assessed technology for technology sake Framework 2.0 Plus Refocuses assessment process on business Process is now an inventory of the technical services and applications available Technical assessment is performed to determine what technical assets are currently available in a State’s infrastructure that can support future business needs Used in conjunction with Business service solution sets and the “to-be” business service assessment to determine technical needs to meet the business “to-be” configuration. Technical Assessment

21. Goal is to support semantic interoperability of the MITA business processes and technical functions Interface standardization begins at Maturity level 3 Provides enabling functionality to business services Examples Gateways/adapters CAQH Content X12 Communications CAQH connectivity NHIN EDI Authorization & Authentication Audit logging Encryption MITA Technical Services

22. Business Logic Business Capability Maturity Level 5 Capability Level 1 Capability Level 2 Capability Level 3 Capability Level 4 Capability Level 2 Business Service Level 3 Business Service Level 4 Business Service Level 5 Business Service MITA Business Process, Business Capability Matrix, and Business Services • Definition • Description of business logic • Performance measures Business Process Trigger Result

23. Purpose of a MITA Business Service • The MITA Business service is a logical implementation of a Medicaid Enterprise business process (e.g., Enroll Provider) • The MITA business service supports • Interoperability and plug-and-play • States adapting and extending the service to meet their individual requirements • A MITA business service is implementation neutral

24. Black Box Concept of a Service Service Custom Code Service COTS Service Legacy Application Service COTS Custom Code Custom Code Service Service Service Service

25. Parts of a MITA Service • Service name • Formally defined interface • Behavior characteristics • Business logic • Service Contract (Processing pattern, etc.) • Business Service Definition Package (BSDP)

26. MITA Service Flow • Services are loosely coupled • NO predefined predecessor or successor services to an individual service • Services configured through use of a service contract and an orchestration language • Changes to the flow of services through changes to this orchestration; NOT by changes to the service • Interfaces between the services must be compatible

27. Service A Service A Service B Service C Service C Interoperability - Replacement Starting Configuration Service B1 Final Configuration e.g., replacement of legacy service with COTS

28. Service A Service A Service B Service C Service C Interoperability – Addition Starting Configuration Service B Final Configuration Service D e.g., HIPAA translator

29. Service A Service A Service B Service C Service C Service E Interoperability – New Starting Configuration Service B Final Configuration e.g., new utilization review process

30. Service A Service A Service B Service C Service C Interoperability – New Business Process Starting Configuration Service B3 Final Configuration Service F e.g. , utilization review service with new potential fraud report e.g., automated fraud detection processing

31. Business Process and Business Service Relationship Definition Description of business logic Performance measures Business Process Business Logic Result Trigger What does the service do and what is needed to engage the service Business capability Business Service WSDL defined WSDL defined Service Contract Business Logic Data • Example • Eligibility Inquiry Response • HIPAA 271 XML schema • Example • Eligibility Inquiry • HIPAA 270 XML schema Performed by legacy subsystem, new code or services, COTS or combination Shared between or with other services

32. MITA Service Definition Methods • Interfaces are defined in Web Service Definition Language (WSDL) • Messages are defined in XML schemas • Business Logic – currently free form text, will become business rules in the future • Business Service Management (orchestration) is defined in Web Service – Business Process Execution Language (WS-BPEL) • Data is defined in MITA logical data model

33. State Personalization of Services • Change Message Structure - Schema change • Change data being used – Change data set name (e.g., instead of mapping to “state-A-MVA” map to “state-B-MVA) • Replace capability – Replace service with state unique service preserving input and output • Re-Orchestrate business services – Add new services to flow • Change business rules – Replace the set of business rules used by a service with a new set of business rules

34. Service Interface Specification Development Process Standard Analysis Applicable Standard Report MITA Business Process Specification (template & BCM) Model Business Process MITA Governance Boards (Adoption packages) Develop BS Interface Specification adoption recommendation (WSDL, XML Schema and models) (Adoption packages) Coordinate with TAC and identify Technical Service gaps TAC

35. Putting it all together

36. Service Orchestration Business Service Invocation Technical Service- 3 Business Service - B True Technical Service - 1 Business Service - A Technical Service - 2 Business Service- C False Business Service- D

37. Interface Response Interface Request Service Contract Interaction Specification Service “XYZ” Service Request

38. Step 1: Member Invokes “Determine Eligibility” Service Step 6: Provider Receives “Determine Eligibility” Response Step 11: Member completes enrollment form Sample Service #2 – Member Eligibility and Enrollment Enrollment Info Request Step 10: Send request for more info Enrollment Response Determine Eligibility Request Access Channel Enrollment Info Response Member Service Portal Eligibility Response Step 9: Route request for more information to Service Portal MITA Enrollment Info Request MITA Determine Eligibility Response MITA Enrollment Response MITA Determine Eligibility Request Security & Privacy Services Logging Services MITA Enrollment Info Response Data Format Services Step 5: Receive/ Route/ Manage Step 2: Receive/ Route/ Manage Enterprise Service Bus Determine Eligibility Service Contract Service Management Engine Enroll Member Service Contract Step 7: Service contract – “activate” enroll member service MITA Determine Eligibility Request Step 3: Execute Determine Eligibility Business Process MITA Determine Eligibility Response MITA Enroll Member Request MITA Enrollment Info Request MITA Enrollment Response MITA Enrollment Info Response Step 8: Request Information for enrollment Determine Eligibility Service Enroll Member Service Step 4: Return Response

39. Step 1: Provider Invokes “Enroll Provider” Service Step 6: Provider Receives “Enroll Provider” Response Sample Service #1 – Provider Enrollment Enrollment Request Access Channel Provider Service Portal Enrollment Response MITA Enrollment Response MITA Enrollment Request Security & Privacy Services Logging Services Data Format Services Step 2: Receive/ Route/ Manage Step 5: Receive/ Route/ Manage Enterprise Service Bus Provider Enrollment Service Contract Service Management Engine MITA Enrollment Request MITA Enrollment Response Step 3: Execute Provider Enrollment Business Process Step 4: Return Response Enroll Provider Service

40. – MITA guidelines apply; FFP available – Entity is encouraged to follow MITA guidelines – May exchange information; may influence MITA or vice versa MITA Medicaid Enterprise Departmentof HomelandSecurity CDC CMS Notificationsand Alerts Notificationsand Alerts MSIS Data; Dual Eligibility License Board Other Agency FEA FHA ONC Interface Interface Guidelines;Directives Standards of Interoperability; EHR MITA Business Process#1 Interface Other Payer RHIO Interface Interface MITA Business Process#2 MITA Business Process#3 Interface Use Standards; Develop New Ones Interface Standards Organization Interface Interface Provider SURSor Fraud Contractor Information Exchange BenefitManager State Unemploy-ment Agency Business Service Technical Service Connection

41. GUI GUI GUI The TAC’s 5010 Gateway Project Phase 1 Inquire Member Eligibility 1 Phase 2 IME TS-B1 TS-C1 Phase 3 IME TS-A TS-B1 TS-C1 TS-D Legend Business Service Technical Service GUI Potential Post Phase 3 Other Business Services TS TS-B TS-C TS TS TS

42. IME Test Suite CAQH Core In Connectivity TS X12/MITA XML adapter TS Dash- Board Inquire Member Eligibility BS MITA XML/X12 adapter TS CAQH Core Out Connectivity TS

43. MITA Review Boards ARB BARB TARB IARB The Big Picture MITA Users STAG Technical Implementer New Bus Proc NMEH TAC Other DSMOs State Business SMEs HL7-MITA Project Independent Information Spec. HL7 HL7Healtth Data Community

44. MITA Architecture Review Board • MITA Standards • Framework updates MITA Business Architecture Review Board MITA Information Architecture Review Board MITA Technical Architecture Review Board • Service definitions • Infrastructure definitions • Technical processes • Technical capabilities • Mapping to Standards • Business Process • Business Capability • S-SA process • Conformance Criteria • Data Models • Vocabulary • Mapping to Standards • Data Management Strategy MITA Architecture Governance Structure

45. MITA Architecture Review Board • MITA Standards • Framework updates MITA Business Architecture Review Board MITA Information Architecture Review Board MITA Technical Architecture Review Board • Service definitions • Technical Functions • Templates • Activity diagrams • Technical Information Vocabulary and glossary • Tec Function capabilities • Mapping to Standards • Infrastructure definitions • Business Process • Templates • Activity diagrams • Business Capability • Business Information Vocabulary and glossary • Conformance Criteria • Data Models and associated views • WSDL and associated XSD • Information Vocabulary and glossary • Mapping to Standards MITA Architecture Governance Artifacts