Upload
natalie-law
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
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
7
6
5
4
3
2
1
LevelsHL7 corresponds to the
conceptual definition of an application-to-application
interface placed in the seventh layer of the OSI model.
5
6
International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI)
reference model
7
6
5
4
3
2
1
Levels
MITA Business Process.
MITA Technical Functions
7
NHIN Services Interface Standard Description
Subject Discovery PIXv3 Service for locating patients based on demographic information
Query for Documents XCA Locate health documents associated with a specific patient that conforms to a set of criteria
Retrieve Documents XCA 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 XACML Enable consumers to specify with whom they wish to share their electronic health information
Messaging SOAP/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 registry UDDI 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
SURSor Fraud
Contractor
BenefitManager
Provider
OtherPayer
OtherAgency
CMS
LicenseBoard
RHIO
FEAFHA
CDCDepartmentof Homeland
Security
ONC
StandardsOrganization
MITABusinessProcess
#3
MITABusinessProcess
#2
MITABusinessProcess
#1
StateUnemploy-
mentAgency
MS
IS D
ata;
D
ual
Elig
ibili
ty
InterfaceInterface
Inte
rface
Interface
Interface
Inte
rface
Interface
Interface
Standards of Interoperability
;
EHR
Interface
Use Standards;
Develop New Ones
Info
rmat
ion
Exc
han
ge
Guidelines;Directives
No
tifi
cati
on
san
d A
lert
sN
otificatio
ns
and
Alerts
MITA Medicaid Enterprise
10
ProviderManagement
ContractorManagement
Operations Management
ProgramManagement
BusinessRelationshipManagement
ProgramIntegrity
Management
CareManagement
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 CaseEstablish
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
26 19 9 8
7442
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
TechnologyStandards
Application Architecture
Technical Services
Technical Capability
Matrix
Business Services
Solution Sets
Framework 2.0 Plus
TechnologyStandards
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 Group’s Technical Architecture Committee (TAC).
13
Technical Maturity LevelsAre 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
54321
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 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.
BusinessServiceEnd User
TechnicalService
TechnicalService
TechnicalService
TechnicalService
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
Technical Maturity Levels
Framework 2.0 Framework 2.0 Plus
Business Service
BusinessProcess
Maturity Levels
54321
Business Solution
Set
Technical Service
Technical Function
A
Maturity Levels
54321
Technical Solution
SetTechnical Service
Technical Function
B
Maturity Levels
54321
Technical Solution
Set
Business Service
BusinessProcess
Maturity Levels
54321
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 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
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 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.
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
ResultTrigger Business Logic
Business Process
•Definition•Description of business logic•Performance measures
Level 1Capability
Level 2Capability
Level 3Capability
Level 5Capability
Level 4Capability
Business Capability Maturity
Level 2Business
Service
Level 3Business
Service
Level 4Business
Service
Level 5Business
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
ServiceLegacy Application
ServiceCustom Code
COTSCustom Code
ServiceCOTS
ServiceCustom Code
ServiceService Service Service
25
Parts of a MITA Service
Service nameFormally defined interfaceBehavior characteristics
Business logic Service Contract (Processing pattern,
etc.)Business Service Definition Package
(BSDP)
26
MITA Service Flow
Services are loosely coupledNO predefined predecessor or successor
services to an individual serviceServices configured through use of a service
contract and an orchestration languageChanges 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
ServiceB
ServiceA
ServiceC
ServiceB1
ServiceA
ServiceC
StartingConfiguration
FinalConfiguration
e.g., replacement of legacy service with
COTS
28
Interoperability – Addition
ServiceB
ServiceA
ServiceC
ServiceB
ServiceA
ServiceC
ServiceD
StartingConfiguration
FinalConfiguration
e.g., HIPAA translator
29
Interoperability – New
ServiceB
ServiceA
ServiceC
ServiceB
ServiceA
ServiceC
StartingConfiguration
FinalConfiguration
ServiceE
e.g., new utilization review
process
30
Interoperability – New Business Process
ServiceB
ServiceA
ServiceC
ServiceB3
ServiceA
ServiceC
ServiceF
StartingConfiguration
FinalConfiguration
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 Logic Data
WSDL defined 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
DefinitionDescription of business logicPerformance 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 changeChange 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
Coordinatewith TAC andidentify Technical Service gaps
StandardAnalysis
MITA Business Process
Specification(template & BCM)
ModelBusinessProcess
TAC
MITAGovernance
Boards
(Adoption packages)
(Adoption packages)
35
Putting it all together
36
Service Orchestration
Business Service Invocation
TrueFalse
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 Response
Interface Request
38
MIT
A D
eter
min
e E
ligib
ility
R
equ
est
Sample Service #2 – Member Eligibility and Enrollment
Enterprise Service Bus
Service Management Engine
Member Service Portal
Determine Eligibility Request
AccessChannel
AccessChannel
Step 1: Member Invokes
“Determine Eligibility” Service
Security & Privacy Services
Data Format Services
Logging Services
Determine EligibilityService
Contract
Step 2: Receive/ Route/
Manage
Step 4: Return Response
Step 3: Execute Determine Eligibility Business Process
Eligibility Response
MIT
A D
eter
min
eE
ligib
ility
Res
po
nse
MIT
A D
eter
min
e E
ligib
ility
Req
ues
t
MIT
A D
eter
min
eE
ligib
ility
R
esp
on
se
Determine Eligibility Service
Step 5: Receive/ Route/
Manage
Step 6: Provider Receives
“Determine Eligibility” Response
MIT
A E
nro
ll M
emb
er R
equ
est
Enroll Member Service
MIT
A E
nro
llmen
t In
fo R
equ
est
MIT
A E
nro
llmen
t In
fo R
equ
est
Enrollment Info Request
Enrollment Info Response
MIT
A E
nro
llmen
t In
fo R
esp
on
se
MIT
A E
nro
llmen
t In
fo R
esp
on
se
MIT
A E
nro
llmen
t R
esp
on
se
MIT
A E
nro
llmen
t R
esp
on
se
Enrollment Response
Enroll MemberService
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
MIT
A E
nro
llmen
t R
equ
est
Sample Service #1 – Provider Enrollment
Enterprise Service Bus
Service Management Engine
Provider Service Portal
Enrollment Request
AccessChannel
AccessChannel
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
MIT
A E
nro
llmen
t R
esp
on
se
MIT
A E
nro
llmen
t R
equ
est
MIT
A E
nro
llmen
t R
esp
on
se
EnrollProvider 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
SURSor Fraud
Contractor
BenefitManager
Provider
OtherPayer
OtherAgency
CMS
LicenseBoard
RHIO
FEAFHA
CDCDepartmentof Homeland
Security
ONC
StandardsOrganization
MITABusinessProcess
#3
MITABusinessProcess
#2
MITABusinessProcess
#1
StateUnemploy-
mentAgency
MS
IS D
ata;
D
ual
Elig
ibili
ty
InterfaceInterface
Inte
rface
Interface
Interface
Inte
rface
Interface
Interface
Standards of Interoperability
;
EHR
Interface
Use Standards;
Develop New Ones
Info
rmat
ion
Exc
han
ge
Guidelines;Directives
No
tifi
cati
on
san
d A
lert
sN
otificatio
ns
and
Alerts
MITA Medicaid Enterprise
Business Service
Technical ServiceConnection
41
The TAC’s 5010 Gateway Project
InquireMember
Eligibility 1
GUI
Legend
Business Service
Technical Service
GUI
TS-B1 TS-C1GUI
TS-A TS-B1 TS-C1 TS-DGUI
IME
IME
Phase 1
Phase 2
Phase 3
PotentialPost
Phase 3
TS-B TS-COtherBusinessServices
TSTS
TSTS
42
IME Test Suite
CAQH Core InConnectivity TS
X12/MITA XMLadapter TS
MITA XML/X12adapter TS
CAQH Core OutConnectivity TS
Inquire MemberEligibility BS
Dash-Board
43
The Big Picture
NMEH
HL7-MITAProject
TAC
BARB
IARB
TARB
ARB
MITA Users
STAG
New Bus Proc
Other DSMOs
HL7 HL7Healtth DataCommunity
Technical Implementer
IndependentInformation Spec.
State BusinessSMEs
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