Presentation on theme: "MITA Business Processes, Technical Functions & Services Monday Quarter 2 Presentation May 18, 2009."— Presentation transcript:
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 International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference model Levels HL7 corresponds to the conceptual definition of an application-to-application interface placed in the seventh layer of the OSI model.
6 International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference model Levels MITA Business Process. MITA Technical Functions
7 NHIN Services Interface StandardDescription Subject DiscoveryPIXv3 Service for locating patients based on demographic information Query for DocumentsXCA Locate health documents associated with a specific patient that conforms to a set of criteria Retrieve DocumentsXCA Retrieve specific requested documents associated with a patient Query Audit LogIHE ATNA Log requests for patient health information and make this log available to patients. Authorization Framework SAML Articulate the justification for requesting patient medical information Consumer preferenceXACML Enable consumers to specify with whom they wish to share their electronic health information MessagingSOAP/WSDL/WS- addressing/ws-security Provide secure messaging services for all communication between nhin ENABLED HEALTH ORGANIZATIONS Authorize Case follow up PIXv3 Provide an ability to re-identify pseudonymized patient record when legally permitted for public health case investigation Health Information Event messaging WS-Base Notification Provides a publish/subscribe capability for ongoing feeds of data between NHIN enabled health organizations NHIE Service registryUDDI Registry that enables NHIN enabled health organizations to discover the existence and connection information for other NHIN enabled health organizations
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 SURS or Fraud Contractor Benefit Manager Provider Other Payer Other Agency CMS License Board RHIO FEA FHA CDC Department of Homeland Security ONC Standards Organization MITA Business Process #3 MITA Business Process #2 MITA Business Process #1 State Unemploy- ment Agency MSIS Data; Dual Eligibility Interface Standards of Interoperability; EHR Interface Use Standards; Develop New Ones Information Exchange Guidelines; Directives Notifications and Alerts MITA Medicaid Enterprise
10 Provider Management Contractor Management Operations Management Program Management Business Relationship Management Program Integrity Management Care Management Authorize Referral Authorize Service Authorize Treatment Plan Apply Attachment Apply Mass Adjustment Audit Claim-Encounter Edit Claim-Encounter Price Claim – Value Encounter Prepare COB Prepare EOB Prepare Premium EFT-check Prepare Provider EFT-check Prepare Medicare Premium Payment Inquire Payment Status Manage Payment Information Prepare Remittance Advice-Encounter Report Calculate Spend-Down Amount Prepare Member Premium Invoice Manage Drug Rebate Manage Estate Recovery Manage Recoupment Manage Cost Settlement Manage TPL Recovery Prepare Capitation Premium Payment Prepare Home & Community Based Services Payment Prepare Health Insurance Premium Payment Manage Contractor Information Manage Contractor Communication Perform Contractor Outreach Support Contractor Grievance and Appeal Inquire Contractor Information Award Administrative or Health Services Contract Close out Administrative or Health Services Contract Manage Administrative or Health Services Contract Produce Administrative or Health Services RFP Member Management Determine Eligibility Enroll Member Disenroll Member Manage Member Information Inquire Member Eligibility Perform Population & Member Outreach Manage Applicant & Member Communication Manage Member Grievance & Appeal Manage FFP for Services Manage F-MAP Manage State Funds Manage 1099s Perform Accounting Functions Monitor Performance & Business Activity Maintain Benefits- Reference Information Manage Program Information Develop & Maintain Benefit Package Manage Rate Setting Develop Agency Goals & Objectives Develop & Maintain Program Policy Maintain State Plan Formulate Budget Manage FFP for MMIS Draw and Report FFP Designate Approved Services & Drug Formulary Establish Case Manage Case Manage Medicaid Population Health Manage Registry Identify Candidate Case Manage Case Establish Business Relationship Manage Business Relationship Comm. Manage Business Relationship Terminate Business Relationship Enroll Provider Disenroll Provider Manage Provider Information Inquire Provider Information Manage Provider Communication Manage Provider Grievance & Appeal Perform Provider Outreach Dev. & Manage Perform. Measures & Reporting Monitor Performance & Business Activity Business Process Model v2.01
11 Technical Functions 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 Framework 2.0 Technology Standards Application Architecture Technical Services Technical Capability Matrix Business Services Solution Sets Framework 2.0 Plus Technology Standards Application Architecture Technical Services Technical Functions Business Services Solution Sets
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 Groups Technical Architecture Committee (TAC).
13 Technical Maturity Levels Are Based on Industry Standards 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 Technical Services Technical Function Maturity Levels Framework 2.0 Plus Maturity Levels Z ….. BA Technical Services Technical Function
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 functionmaturity 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. Business Service End User Technical Service Technical Service 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 functionmaturity level or application element- maturity level pair. A solution set has the metadata describing a specific implementation approach.
18 Technical Maturity Levels Framework 2.0Framework 2.0 Plus Business Service Business Process Maturity Levels Business Solution Set Technical Service Technical Function A Maturity Levels Technical Solution Set Technical Service Technical Function B Maturity Levels Technical Solution Set Business Service Business Process Maturity Levels Business Solution Set Maturity Levels DBA Technical Services Technical Function Maturity Levels BA Technical Services Technical Function C Technical Solution Set Technical Solution Set
19 Relation to Business Service Solution Sets Business services solution sets contain pointers to all technical functionmaturity 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 Technical Assessment 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 States 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.
21 MITA Technical Services 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
22 MITA Business Process, Business Capability Matrix, and Business Services Result Trigger Business Logic Business Process Definition Description of business logic Performance measures Level 1 Capability Level 2 Capability Level 3 Capability Level 5 Capability Level 4 Capability Business Capability Maturity Level 2 Business Service Level 3 Business Service Level 4 Business Service Level 5 Business Service
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 Legacy Application Service Custom Code COTS Custom Code Service COTS Service Custom Code 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 Interoperability - Replacement Service B Service A Service C Service B1 Service A Service C Starting Configuration Final Configuration e.g., replacement of legacy service with COTS
28 Interoperability – Addition Service B Service A Service C Service B Service A Service C Service D Starting Configuration Final Configuration e.g., HIPAA translator
29 Interoperability – New Service B Service A Service C Service B Service A Service C Starting Configuration Final Configuration Service E e.g., new utilization review process
30 Interoperability – New Business Process Service B Service A Service C Service B3 Service A Service C Service F Starting Configuration Final Configuration e.g., utilization review service with new potential fraud report e.g., automated fraud detection processing
31 Business Process and Business Service Relationship Trigger Business Logic Business Process Result Business Service Service Contract Business LogicData WSDL defined Shared between or with other services 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 Definition Description of business logic Performance measures What does the service do and what is needed to engage the service Business capability
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 Develop BS Interface Specification adoption recommendation (WSDL, XML Schema and models) Applicable Standard Report Coordinate with TAC and identify Technical Service gaps Standard Analysis MITA Business Process Specification (template & BCM) Model Business Process TAC MITA Governance Boards (Adoption packages)
35 Putting it all together
36 Service Orchestration Business Service Invocation True False Business Service- D Technical Service- 3 Business Service - B Business Service - A Business Service- C Technical Service - 2 Technical Service - 1
37 Service Contract Service XYZ Service Request Interaction Specification Interface ResponseInterface Request
38 MITA Determine Eligibility Request Sample Service #2 – Member Eligibility and Enrollment Enterprise Service Bus Service Management Engine Member Service Portal Determine Eligibility Request Access Channel Access Channel Step 1: Member Invokes Determine Eligibility Service Security & Privacy Services Data Format Services Logging Services Determine Eligibility Service Contract Step 2: Receive/ Route/ Manage Step 4: Return Response Step 3: Execute Determine Eligibility Business Process Eligibility Response MITA Determine Eligibility Response MITA Determine Eligibility Request MITA Determine Eligibility Response Determine Eligibility Service Step 5: Receive/ Route/ Manage Step 6: Provider Receives Determine Eligibility Response MITA Enroll Member Request Enroll Member Service MITA Enrollment Info Request MITA Enrollment Info Request Enrollment Info Request Enrollment Info Response MITA Enrollment Info Response MITA Enrollment Info Response MITA Enrollment Response MITA Enrollment Response Enrollment Response Enroll Member Service Contract Step 7: Service contract – activate enroll member service Step 8: Request Information for enrollment Step 9: Route request for more information to Service Portal Step 10: Send request for more info Step 11: Member completes enrollment form
39 MITA Enrollment Request Sample Service #1 – Provider Enrollment Enterprise Service Bus Service Management Engine Provider Service Portal Enrollment Request Access Channel Access Channel Step 1: Provider Invokes Enroll Provider Service Security & Privacy Services Data Format Services Logging Services Provider Enrollment Service Contract Step 2: Receive/ Route/ Manage Step 4: Return Response Step 3: Execute Provider Enrollment Business Process Enrollment Response MITA Enrollment Response MITA Enrollment Request MITA Enrollment Response Enroll Provider Service Step 5: Receive/ Route/ Manage Step 6: Provider Receives Enroll Provider Response
40 – MITA guidelines apply; FFP available – Entity is encouraged to follow MITA guidelines – May exchange information; may influence MITA or vice versa SURS or Fraud Contractor Benefit Manager Provider Other Payer Other Agency CMS License Board RHIO FEA FHA CDC Department of Homeland Security ONC Standards Organization MITA Business Process #3 MITA Business Process #2 MITA Business Process #1 State Unemploy- ment Agency MSIS Data; Dual Eligibility Interface Standards of Interoperability; EHR Interface Use Standards; Develop New Ones Information Exchange Guidelines; Directives Notifications and Alerts MITA Medicaid Enterprise Business Service Technical Service Connection
41 The TACs 5010 Gateway Project Inquire Member Eligibility 1 GUI Legend Business Service Technical Service GUI TS-B1TS-C1 GUI TS-ATS-B1TS-C1TS-D GUI IME Phase 1 Phase 2 Phase 3 Potential Post Phase 3 TS-BTS-C Other Business Services TS
42 IME Test Suite CAQH Core In Connectivity TS X12/MITA XML adapter TS MITA XML/X12 adapter TS CAQH Core Out Connectivity TS Inquire Member Eligibility BS Dash- Board
43 The Big Picture NMEH HL7-MITA Project TAC BARB IARBTARB ARB MITA Users STAG New Bus Proc Other DSMOs HL7 HL7Healtth Data Community Technical Implementer Independent Information Spec. State Business SMEs
44 MITA Architecture Governance Structure MITA Architecture Review Board MITA Business Architecture Review Board MITA Information Architecture Review Board MITA Technical Architecture Review Board Business Process Business Capability S-SA process Conformance Criteria Data Models Vocabulary Mapping to Standards Data Management Strategy Service definitions Infrastructure definitions Technical processes Technical capabilities Mapping to Standards MITA Standards Framework updates
45 MITA Architecture Governance Artifacts MITA Architecture Review Board MITA Business Architecture Review Board MITA Information Architecture Review Board MITA Technical Architecture Review Board 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 Service definitions Technical Functions Templates Activity diagrams Technical Information Vocabulary and glossary Tec Function capabilities Mapping to Standards Infrastructure definitions MITA Standards Framework updates