MITA Business Processes Technical Functions Services Monday Quarter
MITA Business Processes, Technical Functions & Services Monday Quarter 2 Presentation May 18, 2009
Technical / Business Services: Where does one start and/or stop and the other take over? 2
Foundation Concepts 3
International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference model Levels 7 6 HL 7 corresponds to the conceptual definition of an application-to-application interface placed in the seventh layer of the OSI model. 5 4 3 2 1 4
5
International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference model Levels 7 MITA Business Process. 6 5 MITA Technical Functions 4 3 2 1 6
NHIN Services Interface Standard Description Subject Discovery Query for Documents PIXv 3 XCA Retrieve Documents XCA Service for locating patients based on demographic information Locate health documents associated with a specific patient that conforms to a set of criteria Retrieve specific requested documents associated with a patient Query Audit Log IHE 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 preference Enable consumers to specify with whom they wish to share their electronic health information Provide secure messaging services for all communication between nhin ENABLED HEALTH ORGANIZATIONS Messaging XACML SOAP/WSDL/WSaddressing/ws-security Provide an ability to re-identify Authorize Case follow PIXv 3 pseudonymized patient record when legally permitted for public health case investigation up a publish/subscribe capability for Health Information WS-Base Notification Provides ongoing feeds of data between NHIN enabled health organizations Event messaging Registry that enables NHIN enabled health NHIE Service registry UDDI organizations to discover the existence and connection information for other NHIN enabled health organizations 7
MITA Basics 8
MITA Medicaid Enterprise Department of Homeland Security Other Agency Int e Gu Dir idelin ect es; ive s rfa Interface erf ac e ce Int Inf Excorma han tion ge RHIO Interface MITA Business Process #3 c rfa te e In te rfa ONC nd Sta In Provider er Int c rfa e MITA Business Process #2 ; ty bili era rop e t f In s o EHR ard e fac te Interface MITA Business Process #1 License Board In Other Payer ce CMS MSIS Data; Dual Eligibility ns atio s tific ert No nd Al a FEA FHA No t andificat Ale ions rts CDC U Dev se S elo tand p N ard ew s; On es SURS or Fraud Contractor Standards Organization Benefit Manager State Unemployment Agency – MITA guidelines apply; FFP available – Entity is encouraged to follow MITA guidelines – May exchange information; may influence MITA or vice versa 9
Business Process Model v 2. 01 Operations Management Authorize Referral Inquire Payment Status Draw and Report FFP 8 9 19 26 Member Management Contractor Management Program Management Manage F-MAP Inquire Contractor Information Award Administrative or Health Services Contract Determine Eligibility Inquire Member Eligibility Close out Administrative or Health Services Contract Enroll Member Perform Population & Member Outreach Authorize Service Manage Drug Rebate Manage Rate Setting Manage FFP for Services Manage Contractor Information Authorize Treatment Plan Manage Estate Recovery Manage FFP for MMIS Manage State Funds Manage Contractor Communication Manage Administrative or Health Services Contract Disenroll Member Manage Applicant & Member Communication Apply Attachment Prepare COB Formulate Budget Manage 1099 s Perform Contractor Outreach Produce Administrative or Health Services RFP Manage Member Information Manage Member Grievance & Appeal 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 Identify Candidate Case Manage Case Care Management 2 4 Business Relationship Management Provider Management 4 7 Establish Case Manage Medicaid Population Health Establish Business Relationship Terminate Business Relationship Enroll Provider Manage Provider Communication Manage Case Manage Registry Manage Business Relationship Comm. Disenroll Provider Manage Provider Grievance & Appeal Inquire Provider Information Perform Provider Outreach Manage Provider Information 10
Technical Functions Framework 2. 0 Plus Business Services Technical Capability Matrix Business Services Technical Functions Technical Services Application Architecture Technology Standards Solution Sets l l Inconsistent use of the word “capabilities” in TA Not consistent with taxonomy of the business architecture n BA -> BP -> ML -> BS -> SS n TCM -> ML -> TS -> SS l l Achieves consistency Business process equivalent to technical function n BP -> ML -> BS -> SS n TF -> ML -> TS -> SS 11
Technical Functions l Examples of technical functions are Authentication and Authorization. l Interfaces to technical functions modeled as triggers and results. l Technical function only exists to enable the business processes. l Initially, technical functions will be defined using a template but like the business processes will ultimately be based on UML models. l Technical function maturity level pairs (function + capability) will result in a technical service. l The technical functions are being defined by the Private Sector Technology Group’s Technical Architecture Committee (TAC). 12
Technical Maturity Levels Are Based on Industry Standards Framework 2. 0 Plus Technical Function Maturity Levels 1 2 3 4 Maturity Levels 5 A Technical Services l l l Artificially linked technology to MITA Business maturity Did not allow flexibility for industry standards Did not provide flexibility in designing technical services/solution sets B …. . Z Technical Services l l 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 13
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. n The technical function may have one or many levels of maturity based on the industry standards for that particular technical function. n This allows a technical service to be based on the industry derived capabilities/maturity levels. n 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. n 14
Technical Services Update There have been no structural changes to the concept of Technical Services. n A service can be defined for each technical function—maturity level pair. n The methodology used to define the technical service is the same as for business services, i. e. , HL 7. n The HL 7 Reference Information Model will be used in the development of the technical service interfaces whenever possible. n 15
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. n Each element of the application architecture will have technical maturity levels and technical solution sets. n Technical Service End User Application Architecture Business Service 16
Technical Solution Sets The role of technical solution sets remains unchanged. n There may be one or many technical solution sets for each technical function—maturity level or application elementmaturity level pair. n A solution set has the metadata describing a specific implementation approach. n 17
Technical Maturity Levels Framework 2. 0 Technical Function A Business Process Maturity Levels 1 2 3 Framework 2. 0 Plus 4 Technical Function B Business Process Maturity Levels 5 1 2 3 4 Technical Function Maturity Levels 5 1 2 3 4 5 Maturity Levels A B Technical Function Maturity Levels A B C D Maturity Levels Business Service Technical Service Business Solution Set Technical Solution Set 1 2 3 Technical Service Technical Solution Set 4 5 Business Service Business Solution Set Technical Services Technical Solution Set 18
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. n Allows maximum flexibility for the implementer to use the mix of technology while maintaining a loose inventory of technology available for use. n 19
Technical Assessment l Framework 2. 0 Sporadically mentioned l Process same as Business process self assessment l Resulted in an assessment of the technical maturity in terms of the five levels of MITA Business Maturity l Assessed technology for technology sake Framework 2. 0 Plus l l 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. 20
MITA Technical Services l Goal is to support semantic interoperability of the MITA business processes and technical functions l Interface standardization begins at Maturity level 3 l Provides enabling functionality to business services l Examples n n n Gateways/adapters u CAQH Content u X 12 Communications u CAQH connectivity u NHIN u EDI Authorization & Authentication Audit logging Encryption 21
MITA Business Process, Business Capability Matrix, and Business Services • Definition • Description of business logic • Performance measures Business Process Trigger Result Business Logic Business Capability Maturity Level 1 Capability Level 2 Business Service Level 3 Capability Level 3 Business Service Level 4 Capability Level 4 Business Service Level 5 Capability Level 5 Business Service 22
Purpose of a MITA Business Service l The MITA Business service is a logical implementation of a Medicaid Enterprise business process (e. g. , Enroll Provider) l The MITA business service supports n Interoperability and plug-and-play n States adapting and extending the service to meet their individual requirements l A MITA business service is implementation neutral 23
Black Box Concept of a Service Custom Service Code Service COTS Legacy Service Application Custom Code COTS Service Custom Code Service 24
Parts of a MITA Service l Service name l Formally defined interface l Behavior characteristics n Business logic n Service Contract (Processing pattern, etc. ) l Business Service Definition Package (BSDP) 25
MITA Service Flow l Services are loosely coupled l NO predefined predecessor or successor services to an individual service l Services configured through use of a service contract and an orchestration language l Changes to the flow of services through changes to this orchestration; NOT by changes to the service l Interfaces between the services must be compatible 26
Interoperability - Replacement Starting Configuration Final Configuration Service A Service B Service C Service A Service B 1 Service C e. g. , replacement of legacy service with COTS 27
Interoperability – Addition Starting Configuration Service A Service B Service C Final Configuration Service D e. g. , HIPAA translator 28
Interoperability – New Starting Configuration Service A Service B Service C Service E Final Configuration e. g. , new utilization review process 29
Interoperability – New Business Process Starting Configuration Service A Service B Service C Service A Service B 3 Service C Final Configuration Service F e. g. , utilization review service with new potential fraud report e. g. , automated fraud detection processing 30
Business Process and Business Service Relationship Definition Description of business logic Performance measures Business Process Trigger Result Business Logic What does the service do and what is needed to engage the service Business capability Business Service WSDL defined Service Contract Business Logic Example Eligibility Inquiry • HIPAA 270 XML schema Performed by legacy subsystem, new code or services, COTS or combination WSDL defined Data Shared between or with other services Example Eligibility Inquiry Response • HIPAA 271 XML schema 31
MITA Service Definition Methods l Interfaces are defined in Web Service Definition Language (WSDL) l Messages are defined in XML schemas l Business Logic – currently free form text, will become business rules in the future l Business Service Management (orchestration) is defined in Web Service – Business Process Execution Language (WSBPEL) l Data is defined in MITA logical data model 32
State Personalization of Services l Change Message Structure - Schema change l Change data being used – Change data set name (e. g. , instead of mapping to “state-A-MVA” map to “state-B-MVA) l Replace capability – Replace service with state unique service preserving input and output l Re-Orchestrate business services – Add new services to flow l Change business rules – Replace the set of business rules used by a service with a new set of business rules 33
Service Interface Specification Development Process Standard Analysis MITA Business Process Specification (template & BCM) Applicable Standard Report Model Business Process ) es ackag np doptio (A Develop BS Interface Specification adoption recommendation MITA Governance Boards (WSDL, XML Schema and models) s) ac Coordinate with TAC and identify Technical Service gaps p ion ge ka pt do (A TAC 34
Putting it all together 35
Service Orchestration Business Service Invocation Technical Service - 1 Technical Service - 2 Business Service - A ue Tr Fa lse Business Service - B Technical Service- 3 Business Service- C Business Service- D 36
Service Contract Interaction Specification Service Request Service “XYZ” Interface Request Interface Response 37
Step 1: Member Step 6: Provider Invokes Receives “Determine Eligibility” Service “Determine Eligibility” Response Step 11: Member completes enrollment form Sample Service #2 – Member Eligibility and Enrollment Step 10: Send request Enrollment Step 2: Receive/ Route/ Manage Data Format Services Enterprise Service Bus Determine Eligibility Service Step 4: Return Response Step 9: Route request for more information to Service Portal Step 5: Receive/ Route/ Manage Contract Service Management Engine Enroll Member Service Determine Eligibility Service Enroll Member Service MITA Enrollment Response MITA Enrollment Info Request MITA Enroll Member Request MITA Determine Eligibility Response MITA Determine Eligibility Request Contract Step 3: Execute Determine Eligibility Business Process MITA Enrollment Response Logging Services MITA Enrollment Info Response Security & Privacy Services MITA Enrollment Info Request Eligibility Response MITA Determine Eligibility Response Member Service Portal MITA Determine Eligibility Request Access Channel for more info Info Request Enrollment Response Determine Eligibility Request Enrollment Info Response Step 7: Service contract – “activate” enroll member service Step 8: Request Information for enrollment 38
Step 1: Provider Step 6: Provider Invokes Receives “Enroll Provider” Service Response Sample Service #1 – Provider Enrollment Provider Service Portal Enrollment Response Security & Privacy Services Logging Services Data Format Services Enterprise Service Bus MITA Enrollment Response Step 3: Execute Provider Enrollment Business Process MITA Enrollment Request Service Management Engine MITA Enrollment Response Step 2: Receive/ Route/ Manage Enrollment Request MITA Enrollment Request Access Channel Provider Enrollment Service Step 5: Receive/ Route/ Manage Contract Step 4: Return Response Enroll Provider Service 39
MITA Medicaid Enterprise Department of Homeland Security Other Agency Int e Gu Dir idelin ect es; ive s rfa Interface erf ac e ce Int Inf Excorma han tion ge RHIO Interface MITA Business Process #3 c rfa te e In te rfa ONC nd Sta In Provider er Int c rfa e MITA Business Process #2 ; ty bili era rop e t f In s o EHR ard e fac te Interface MITA Business Process #1 License Board In Other Payer ce CMS MSIS Data; Dual Eligibility ns atio s tific ert No nd Al a FEA FHA No t andificat Ale ions rts CDC U Dev se S elo tand p N ard ew s; On es SURS or Fraud Contractor Standards Organization Benefit Manager State Unemployment Agency – MITA guidelines apply; FFP available – Entity is encouraged to follow MITA guidelines – May exchange information; may influence MITA or vice versa Business Service Technical Service Connection 40
The TAC’s 5010 Gateway Project Phase 1 Phase 2 Phase 3 GUI Inquire Member Eligibility 1 GUI TS-B 1 TS-A IME TS-B 1 TS-C 1 IME TS-D Legend Business Service Potential Post Phase 3 TS TS TS-B Other Business Services TS-C Technical Service GUI 41
IME Test Suite CAQH Core In Connectivity TS X 12/MITA XML adapter TS Dash. Board Inquire Member Eligibility BS MITA XML/X 12 adapter TS CAQH Core Out Connectivity TS 42
The Big Picture MITA Users STAG ARB BARB New Bus Proc Technical Implementer TARB IARB NMEH TAC Other DSMOs State Business SMEs Independent Information Spec. HL 7 -MITA Project HL 7 Healtth Data Community 43
MITA Architecture Governance Structure MITA Architecture Review Board MITA Business Architecture Review Board MITA Information Architecture Review Board • Business Process • Data Models • Business Capability • Vocabulary • S-SA process • Mapping to Standards • Conformance Criteria • Data Management Strategy • MITA Standards • Framework updates MITA Technical Architecture Review Board • Service definitions • Infrastructure definitions • Technical processes • Technical capabilities • Mapping to Standards 44
MITA Architecture Governance Artifacts MITA Architecture Review Board MITA Business Architecture Review Board • Business Process • Templates • Activity diagrams • Business Capability • Business Information Vocabulary and glossary • Conformance Criteria MITA Information Architecture Review Board • Data Models and associated views • WSDL and associated XSD • MITA Standards • Framework updates MITA Technical Architecture Review Board • Service definitions • Technical Functions • Templates • Activity diagrams • Information Vocabulary and glossary • Technical Information Vocabulary and glossary • Mapping to Standards • Tec Function capabilities • Mapping to Standards • Infrastructure definitions 45
- Slides: 45