Transcript MITA with HL7 Information Health 7 Level

MITA with HL7 Information
Out of Cycle HL7 WGM, 18-21 May, 2009, St. Paul, MN
Health Level 7
Presentation
 HL7
 MITA, HL7, CMS, DHHS, ONC, FEA -> alignment of healthcare architecture
 MITA Business Architecture -> Information Architecture
 MITA Enroll Provider (HL7 MITA WG Example)
 MITA Inquire Member Eligibility (Gateway 5010 Project)
Business
Architecture
Information
Architecture
Technical
Architecture
2
HL7
 An international standard development organization established
more than 20 years ago.
 Enables interoperability of healthcare information.
 Creates standards for the exchange, management, and integration
of electronic healthcare information.
 Develops specifications, e.g., a messaging standard that enables
disparate healthcare applications to exchange key sets of clinical
and administrative data. (HL7 does not develop software).
 Why Health “Level Seven”? – this refers to the highest level of the
International Organization for Standardization (ISO)
communications model for Open Systems Interconnection (OSI) –
the application level.

The seventh level supports such functions as security checks,
participant identification, availability checks, exchange mechanism
negotiations and, most importantly, data exchange structuring.
3
HL7 Today
 Version 3 Reference Information Model (RIM v3)






Messages evolved over several years using a "bottom-up" approach
that has addressed individual needs through an evolving ad-hoc
methodology.
Many optional data elements and data segments, making it adaptable
to almost any site.
The optionality forces implementers to spend more time analyzing
and planning their interfaces to ensure that both parties are using the
same optional features.
Well-defined methodology based on a reference information (i.e.,
data) model. It will be the most definitive standard to date.
Rigorous analytic and message building techniques and
incorporating more trigger events and message formats, resulting in
a standard that is definite and testable, and provide the ability to
certify vendors' conformance.
Uses an object-oriented development (OOD) methodology and a
Reference Information Model (RIM) to create messages. The RIM is an
essential part of the HL7 Version 3 development methodology, as it
provides an explicit representation of the semantic and lexical
connections that exist between the information carried in the fields of
HL7 messages.
4
Steering Divisions: Foundations & Technologies
 Provides fundamental tools and building blocks









Conformance
Infrastructure & Messaging
Implementable Technology Specifications (ITS)
Java
Modeling & Methodology
Security
Services Oriented Architecture (SOA)
Templates
Vocabulary
5
HL7 Diversified
 HL7 started with and is traditionally thought of as “messaging”.
For most of its life, however, HL7 has also produced more than
messaging standards.








Electronic Data Exchange in Healthcare Environments (i.e.
“messaging”) (v2 and v3)
Arden Syntax
GELLO
Visual/Context Integration (CCOW)
Version 2.x XML (XML encoding of HL7 messages)
 Clinical Context Documentation Implementation Guide (CCD)
Electronic Health Record System (EHRS) Functional Model
Personal Health Record System (PHRS) Functional Model
Services (i.e., Services as related to a Services Oriented Architecture
6
Cooperation with Other Standards Developing
Organizations
 HL7 cooperates closely with other standards developers, such as:









Accredited Standards Committee X12N (AXC X12N)
Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT)
Digital Imaging and Communications in Medicine (DICOM)
eHealth Initiative (eHI)
Logical Observation Identifiers Names and Codes (LOINC)
National Council for Prescription Drug Programs (NCPDP)
Object Management Group (OMG)
Health Information Technology Standards Panel (HITSP)
Continuity of Care Document (CCD) – XML standard for medical
information summarization
7
HL7 Home Page
WGM – Work Group Meetings/Balloting Cycles are 3 times annually (January, May, September). Over 700 members
representing 30 countries and private sector.
Out of Cycle Meetings – Held during ballot cycle; typically when a WGM is outside the U.S.
8
CMS Collaboration with HL7 Financial Management
Technical Committee (FM TC)
FM TC Mission/Charter:
To enhance and promote HL7 standards by developing and
extending the financial content of HL7. This includes development
of the HL7 artifacts that support financial instruments such as
accounts, transactions, claims, invoices, authorizations, eligibility,
and contracts.

January 2008, HL7 MITA Workgroup (WG) established within the HL7
FM TC.
 Collaboration with other HL7 TCs: PA, SOA, MnM, Vocabulary
 Collaboration with other federal projects: SAMHSA, DHHS, FDA,
NIST, DoD, VHA, Canada Infoway
 State and private sector staff volunteer work on transforming the MITA
business process templates into the MITA Information Architecture
resulting in technical services.
 Development Framework needed.
 Healthcare (HL7) Development Framework (HDF).
 MITA Development Framework (MDF) – passed HL7 international
balloting cycle September 2008.
 First artifact in the HL7 U.S. Realm.
9
Work Group; Teams
HL7 MITA Work Group (HL7 MITA WG)
The HL7 MITA Project Work Group is focused on creating the initial MITA
Business Process Models and Information Model which will become the MITA
Information Architecture.

HL7 MITA Project Work Group
 Business Process Team
 Use Cases, Storyboards, additional requirements for v2.01
business process templates
 Data Analytics Team
 Information Model Data analysis and database
 Modelers Team
 Diagrams and models for business processes
 Vocabulary Team
 Medicaid specific vocabulary
 Education and Training Team
 Documentation and assistance for newcomers; lessons learned;
best practices
10
Relationship with CMS, Other States, Private Sector
 MITA Governance is established and maintained by CMS and
controls the MITA Standards that will be used by Medicaid
systems.
 All external bodies can only make recommendations for standards
to be adopted by MITA. MITA governance will actually adopt
standards.
 MITA governance will control versioning and effective dates for
specifications.
 MITA standard artifacts will exist in MITA repositories that will
designated by CMS.
 The Initiative Review Board is only indirectly tied to the
specification adoption process since it responsible for the
approval of: MITA APD/RFP guidelines, transition plan, legislative
analysis, goals & objectives, Initiative governance.
11
MITA Governance Structure
MITA
Governing Board
Registrar
Initiative
Review
Board
SubWorkgroup
Architecture
Review
Board
Business
Architecture
Review
Board
Information
Architecture
Review
Board
Technical
Architecture
Review
Board
12
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
•Data Management
Strategy
•MITA Standards
•Framework updates
MITA
Technical Architecture
Review Board
•Service definitions
•Infrastructure
definitions
•Technical processes
•Technical capabilities
•Mapping to Standards
13
Supporting Review Organization Activities
 Supporting Organization – TAC
 Activities –
 Technical function recommendations
 Technical Function capability level recommendations
 Technical Function Information Model recommendations
 Technical Service WSDL recommendations
 Harmonization recommendation between MITA and Technical
 Interface between MITA and technical industry
14
Multi-Architecture Impact
MITA Users
ARB
BARB
TARB
IARB
NMEH
TAC
HL7-MITA
Project
15
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.
HL7-MITA
Project
HL7
HL7Healtth Data
Community
16
Federal Enterprise Architecture (FEA)
17
Healthcare Standards Environment
Participates in
FEA
18
Next Steps for CMS
 Develop MOU with HL7.
 Include detail specification of artifacts exchanged.
 Complete work on the business capabilities matrices.
 Develop detail submission process for each architecture.
 Demonstrate business architecture maturity with development of
a service.
 Gateway 5010 Project (POC) at MMIS 2009.
 National TAC working with MITA HL7 WG and TARB.
 “Inquire Member Eligibility” business process.
 Information models.
 Technical specifications.
 Implement service.
19
HL7 MITA Work Group Process Flow (Draft)
20
HL7 Development Framework
21
Framework is Essential
Healthcare Development Framework
(HDF)
Version 1.2
Published on: April 23rd, 2008
22
MITA Information Models
 The Business Process Model is derived by analyzing the Medicaid
Business Requirements in terms of the Concept of Operations.
 The Business Process Model is neutral with respect to any
organization, location, staff, outsourcing, and automation.
 Applying the Medicaid Maturity Model (MMM) to the Business
Process Model yields the Business Capabilities.
 Business Capabilities show the evolution of Business Processes
over time.






UML
Use Case models
Activity models
Message schemas (HMD, CMET)
Information models (DMIM, RMIM)
Abstract WSDL
23
HL7 V3 Message Development Methodology: How




Use Case Modeling
 Produce a storyboard example
 Generalize the storyboard example into a storyboard
Information Modeling
 Define classes, attributes, datatypes, and relationships
 Define vocabulary domains, code systems, and value sets
 Define states, trigger events, and transitions
Interaction Modeling
 Define application roles
 Define interactions
Message Design
 Define D-MIM, CMETs, and R-MIMs
 Define HMD and Message Types
24
MITA Information Architecture Models
 The Business process/ Business capability combinations are the
cornerstone of the Business Architecture and the driver for the Technical
Architecture.
 Business Capabilities map to the Conceptual Data Model.
 The Conceptual Model is the basis for the Logical Data Model.
 New functional requirements may change the Business Capabilities.
 Business Capabilities may update the Conceptual Data Model, and thereby
evolve the Logical Data Model.
 The Logical Data Model can be expressed as a WSDL.
 The Logical Model will be implemented via a Physical Model via a
information technology specification such as Java or XML.




Business Model
Conceptual Model
Logical Model
Physical Model
Note: CMS will provide Medicaids with specifications for
making their systems interoperable, and reusable.
CMS does not mandate types of software.
25
Medicaid Mission and Goals
Business
Area
MITA Principles, Goals, and Objectives
Conceptual
Data Model
Business
Process
Technical
Area
Technical
Function
Logical
Data Model
Business
Capability
Technical
Capability
Physical
Data Model
26
Business Capabilities Evolve in Response to New
Medicaid Functional Requirements
Potential NHIN standard
for Identity Proofing and
Authentication
Internet 2 Provider
Credentialing Registry
Resulting modifications
of the Business Process
at relevant MMM levels
Document New
Requirement in a
Functional Model
ID
PCM
1.3
Capability
Description
Provider
Enrollment
Determination
and
Management
The MMIS shall support timely, automated online processes and data
management of the Provider Registry for Provider, Operations, Program,
Care, and Program Integrity Management by performing the following
functions:
 Validate Provider Application Data
 Query and monitor provider’s status on the OIG Sanctioned list, the
Excluded Parties List, the NPDB, and HIPDB for sanctions
 Reporting required data on sanctioned providers as required by state
and federal law
 Verification of NPI and periodically monitor NPS for updates to
required fields
 Credentialing
 Assignment of MITA designated Provider Taxonomy
 Verification of IRS identifiers (SSN / EIN)
 Claim and capitation reimbursement
 State requirements relating to provider enrollment
 Notification to Provider about Enrollment Determination outcome and
ongoing status
 Appeals Procedures

PCM
1.4
Report
Sanctioned
Providers
Applicable Laws & Federal
directives
USC 42 Chapter 7 Subchapter
XIX Sec. 1396a (a) & (p)
Exclusion of sanctioned providers
Data
HIPAA NPI &
Provider
Taxonomy.
EIN, SSN
President Bush’s proposed
fiscal year 2007 budget
Evolved
Business
Capability
PAY FOR PERFORMANCE
The MMIS shall support timely, automated online processes and data
management for the following functions:
 Query and monitor provider’s status on the OIG Sanctioned list, the
Subtitle H of Public Law 105-33
and Title IV of Public Law 99660 and Section 221(a) of Public
HIPAA NPI &
Provider
Taxonomy.
27
Business Capabilities are derived from the Model
Maturity Model and Business Process Model
Enroll Provider Business Process
DETAILS
The Enroll Provider business process is responsible for
managing providers’ enrollment in programs, including
 Receipt of enrollment application data set from the
Manage Provider Communications process
 Processing of applications, including status tracking (e.g.,
new, resubmission, duplicate) and validating application
meets state submission rules, e.g., syntax/semantic
conformance
 Validation that the enrollment meets state rules by
 Performing primary source verification of verifies provider
credentials and sanction status with external entities,
TRIGGER
A provider enrollment data set (received from the Receive
EVENT
Inbound Transaction process. Includes both paper and EDI).
RESULTS
Validated data set sent to the Manage Provider
Information process)
BUSINESS
1. Start: Receive provider enrollment data set from the
PROCESS
Inbound Transaction process
STEPS
2. Determines its status as initial, adjustment to a
processed provider enrollment data or a duplicate
submission that is already in the enrollment process but
not yet completed and loaded into Provider Registry
3. Validate provider credentials
4. Validate enumeration
5. Performance Evaluation ETC.
PREDECESSOR 1. Receive Inbound Paper/Phone/Fax process
2. Receive Inbound EDI process
SUCCESSOR
1. Manage Provider Information process
SHARED DATA 1. Provider Registry data: e.g., NPI, provider
demographics, provider taxonomy
2. Member Registry data: e.g., member identifier, member
demographic data, third party resources ETC.
CONSTRAINTS [Requirements, variations]
ITEM
DESCRIPTION
FAILURES
The Enroll Provider process contains a series of potential
points of failure. The application could fail any edit. Business
rules define when one or more edit failures will result in
suspending or denying the application.
Examples:
Business Process = Preconditions,
Trigger, Data in Motion, Steps, and
Results
Business
Capability
28
1
2
3
4
5
MITA Maturity Model
5 YEARS
NOW
10+ YEARS
Definition of State Medicaid Levels of Maturity
Level 1
Agency
focuses on
meeting
compliance
thresholds for
State and
Federal
regulations,
accurate
enrollment of
eligibles and
timely and
accurate
payment of
claims.
Level 2
Level 3
Level 4
Level 5
Agency focuses
on cost
management
and improving
quality of and
access to care
within structures
designed to
manage costs
Focus on
managing costs
leads to
program
innovations.
Agency focuses
on adopting
national
standards,
collaborating with
other agencies in
developing
reusable business
processes, and
promoting onestop-shop
solutions for
providers and
consumers..
Agency benefits
from widespread
and secure
access to
clinical data and
focuses on
improvement of
healthcare
outcomes,
empowering
beneficiaries
and P4P.
Agency focuses
on fine tuning
and optimizing
program
management,
planning and
evaluation since
it has benefited
from national
interoperability.
29
Provider Enrollment – Credentialing Step
5 YEARS
5 YEARS
NOW
NOW
10+ YEARS
LEVEL 1
LEVEL 3
LEVEL 5
The enrollment process is
automated by an interface
with the RHIO Provider
Directory which invokes a
credential verification service
Provider enrollment staff use
automated, web-based, online
credentialing and sharing of
primary source verification with
other state health programs and
other Medicaid agencies
Provider enrollment staff
spend hours verifying provider
credentials or fail to do
primary credentialing
verification because of
difficulty and liability risk
Business Capability Matrix
30
Evolving Enroll Provider Business Capability
NOW
Level 5
Level 4
Level 3
Level 2
Level 1
5 YEARS
10+
Outcomes based enrollment; continuous verification against national databases
Enrollment/verification via RHIOs; access clinical record
Real time rules driven enrollment /verification; one-stop collaboration
Use proprietary EDI for enrollment /verification; legacy MMIS hard coded rules
Receive paper enrollment application; verify via phone; manual processing
Example of Maturing Business Capabilities…
31
Enroll Provider Concept of Operations
AS IS Concept of Operations
Provider
Business
Associates
Provider
Sends
Proposal
Sends
Contract
Administrative
Contracts
Care
aged
Man tracts
Provider
en ra
B nist
i
m
Con
r
ide t
ov n
Pr ollme
r
En
it n
ef tio
D e Elig
term ibil
it
ina y
Elig
tion
ibility
Inqu
ir y
Receives
Enrollment
Information
and ID
Medicaid
Beneficiary
Enrollm
en t
Medicaid
Agency
er
Providcation
uni
Comm
n
ng
la
n
P
ep
or
ti
ic
al
R
tr
at
eg
Qu
ent
U
& Ftilizatio
rau
d Dn R evie
etec
w
tion
Ass
Payment
and RA
Sends
Repayment
Sends 1099
Request
Auth.
Receives
Auths.
Provider
ality
ts
di
Ex
te
rn
Case Ma
nag em
u
blic n
Pu tio
id/ ora
ica ab
ed Coll
S
l
Financia on
Administrati
Service Auth. and
Prepayment Revi ew
A
Receives
Information
External
Data-Sharing
Exchange
Provider
P
ent
P aym
Utilization
and Quality
Management
M h
MS
alt
He edicaid/Cring
M Sha
Data
Dual-Eligibles
Initiatives
Multi-E
Collabor ntry
ation
Data
Sha
ring
n
cisio
De
in
g
ber ion
Mem
ic at
mun
port
C om
S up
Makes
Inquiries
Inf ormation
Management
Requests
Payments
Sends
ent
stmssing
ce
Adju
g
ssin
Pr o
roc e
Payment
Management
Member
Management
Other
Payer
Bank
Provider and
Contract
Mgmt.
Beneficiary Services
Notifies
Readjustment
Sends
Encounters
Sends
Claims
Receives
Rates
s
Pr & E
oc nc
Receives
Contract
Inquiries
Managed
Care
Network
Administra
tion
Rate
s an
d Fe
Cl
aim
es
Sends
Eligibility
Information
Responds
Provider
Submits
Proposal
Managed
Care
oo ess oun
ing te
r
r
B din
en a
ef tio
its n
of
Receives
Enrollment ID
Provider
Managed
Care
C
Sends
Application
Eligibility
Source
Provider
Assignment
Ad
 As Is:
 Provider credentials verified
via telephone, fax, data
matches
 Delays, non-standard
responses
 Missed opportunities to
identify sanctions
 To Be:
 Provider’s credentials
verified on-line
 Application triggers
automated requests
 Standardized responses
 Continuous scans of
sanction lists
ur a
nc e
Receives
Approval
Sends
Treatment
Provider
Provider
Makes
Inquiries
Sends
Report
Provides
Records
Receives
Information
Medicaid
Beneficiary
Sends
Information
CMS
Other
Agencies
Requests
Records
Provider
Managed
Care
2629-06—087
TO BE Concept of Operations
CMS
Provider
Eligibility
Source
Medicaid
Beneficia
ry
Other
Payer
Provider
and Contract
MemberManagement
Finance
Management
Management
Medicaid
Strategic Agency Decision
Planning Data Support
Sharing and
Communicat
ions
Managed
Care
Other
Agencies
Bank
Provider
Provider
Other
RHIOs
2629-06—088
32
Challenges with the Art/Science of Modeling
 “Essentially, all models are wrong, but some are useful.” George
E. P. Box
 Evolution to Unified Modeling Language (UML)
 Object-Oriented Analysis (OOA)
 Object-Oriented Design (OOD)
 Object-Oriented Analysis and Design (OOAD)
 Object-Oriented Software Engineering (OOSE)
 UML
– General purpose modeling language that tries to
achieve compatibility with every possible
implementation language.
 Diagrams -> Models (huh?)
33
UML v2.0
UML Modeling
Structure Diagrams: what things must be in the
system being modeled.
Behavior Diagrams: what must happen in the
system being modeled.
Interaction Diagrams: subset of behavior diagrams
that emphasize flow of control and data among the
things in the system being modeled.
34
HL7 Modeling Hierarchy
35
HL7 V3 Message Design Models
RIM
RIM
• Select RIM classes to be included in D-MIM
Reference Information Model
• Clone subset classes of the RIM
(1)
Define a
D-MIM
• Select a subset of class relationships
• Select a subset of class attributes
• Select a subset of attribute data types and domains
D-MIM
D-MIM
• Create clones of D-MIM classes and attributes
Domain Message Information Model
(2)
Define a
R-MIM
• Assign alias class and relationship role names
• Eliminate unnecessary class hierarchies
• Finalize class relationships and cardinality
R-MIM
R-MIM
Refined Message Information Model
• Finalize attribute data types and domains
• Select a root class for the message
(3)
Create
an HMD
• Arrange classes and attributes hierarchically
• Declare inclusion and repetition constraints
• Declare data type and domain value constraints
HMD
HMD
• Assign message element names
Hierarchical Message Definition
36
Reference
Models
Reference
Information
Model
Datatype
Specification
Vocabulary
Specification
Design
Models
Interaction
Model
Design
Information
Model
Common
Message Type
Model
Message
Specifications
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
Conformance
Profiles
Message
Profile
Specification
Localized
Message
Specification
Message
Conformance
Statements
37
Reference Models
Reference
Information
Model
The HL7 Reference Information Model is the
information model from which all other information
models and message specifications are derived.
Datatype
Specification
The HL7 Datatype Specification defines the structural
format of the data carried in an attribute and influences
the set of allowable values an attribute may assume.
Vocabulary
Specification
The HL7 Vocabulary Specification defines the set of all
concepts that can be taken as valid values in an instance
of a coded attribute or message element.
38
Design Models
Interaction
Model
An Interaction Model is a specification of information
exchanges within a particular domain as described in
storyboards and storyboard examples.
Design
Information
Model
A Domain Information Model is an information
structure that represents the information content for a
set of messages within a particular domain area.
Common
Message Type
Model
A Common Message Type Model is a definition of a set
of common message components that can be
referenced in various message specifications.
39
Message Specifications
Hierarchical
Message
Definition
Message
Type
Definition
Implementation
Technology
Specification
An Hierarchical Message Definition is a specification
of message elements including a specification of their
grouping, sequence, optionality, and cardinality.
A Message Type Definition is a specification of a
collection of message elements and a set of rules for
constructing a message instance.
An Implementation Technology Specification is a
specification that describes how to construct HL7
messages using a specific implementation technology.
40
Conformance Profiles
Localized
Message
Specification
A Localized Message Specification is a refinement of a
HL7 message specification standard that is specified
and balloted by an HL7 International Affiliate.
Message
Profile
Specification
A Message Profile Specification is a description of a
particular or desired implementation of an HL7
Message standard or Localized Message specification.
Message
Conformance
Statement
A Message Conformance Statement is a comparison of
a particular messaging implementation and an HL7
message standard, localization, or profile.
41
Application
Role
Trigger
Event
Information Modeling
Storyboard
Sender
RIM
Derive
D-MIM
Receiver
Triggers
Restrict
References
R-MIM
Interaction
Example
HL7 V3
Interaction Modeling Methodology:
Service Definition
What and How
Message Design
Storyboard
Example
Content
Use Case Modeling
Serialize
HMD
Restrict
Message
Type
42
Domain Analysis Model (DAM)
class 3.7 DAM Artifacts
class 3.7 DAM Artifacts
Process Flow
Use Case Analysis
Use Case Analysis
Story board
Process Flow
Business Trigger Analysis
Story board
Information Model (Analysis)
Information Model (Analysis)
Business Trigger Analysis
«optional»
Business Rules Description
«optional»
Business Rules Descriptio n
«optional»
Glossary of Classes and Attributes
«optional»
Glossary of Classes and Attributes
43
Domain Analysis Model (DAM)
44
Design Dynamic Model
45
MITA Enroll Provider Example
46
Developing an Information Architecture
Specification for Provider Enrollment




Static Model
Dynamic Model
HL7 Domain Message Information Model
Ballot through HL7 to vet among the Medicaid Community in a
consensus process, which, if followed, should result in an ANSI
accredited standard
 Requires agreement of the Community Based Health Care SIG
to support project
 Requires agreement from other HL7 WGs
 Constrained MITA specific version of the balloted international
standard
 Develop HL7 WSDL
 Ballot or register as a conformance profile with HL7 SOA SIG
47
Medicaid Business Process Model
Medicaid Business Process
Model
Member
Management
Enroll Member
Disenroll Member
Inquire Member Elig
Manage Member Info
Manage Member Comm
Provider
Management
Enroll Provider
Disenroll Provider
Manage Provider Comm
Manage Provider Info
Perform Provider Outreach
Contractor
Management
Operations
Management
Award Contract
Close out Contract
Manage Contractor Comm
Manage Contractor Info
Inquire Contractor Info
Apply Attachment
Audit Claim-Encounter
Manage Drug Rebate
Prepare EOB
Calculate Spend-down
Program
Management
Care Management
Program Integrity
Management
Business
Relationship
Management
Maintain State Plan
Formulate Budget
Manage Rate Setting
Manage 1099s
Manage FFP
Establish Case
Manage Case
Manage Medicaid Pop Health
Identify Candidate Case
Manage Case
Establish Relationship
Manage Relationship
Manage Relationship
Communications
Terminate Relationship
48
MITA Business Process
 Views the business crossfunctionally.
 Organizes the actions of the
business as a set of activities
in response to business
events .
 Cuts through the existing
silos enabling opportunities
for real process improvement.
 Objective is to capture all
Medicaid-related business
processes in the MITA model.
Enroll Provider Business Process
DETAILS
The Enroll Provider business process is responsible for
managing providers’ enrollment, including
 Receipt of enrollment application data set from the
Manage Provider Communications process
 Processing of applications, including status tracking (e.g.,
new, resubmission, duplicate) and validating application
meets Federal and State submission rules, e.g.,
syntax/semantic conformance
 Validation that the enrollment meets Federal and state
rules by
o Performing primary source verification of
provider credentials and sanction status with
external entities, including:
A provider enrollment data set (received from the Receive
TRIGGER
Inbound Transaction or Manage Provider Communication
EVENT
process.
Validated data set sent to the Manage Provider Information
RESULTS
process
BUSINESS
1. Start: Receive provider enrollment data set.
PROCESS
2. Validate application syntax/semantic conformance.
STEPS
3. Determine status as initial, adjustment to a processed
provider enrollment data or a duplicate submission that is
already in the enrollment process but not yet completed
and loaded into Provider Registry.
4. Verify with internal and external entities
5. Validate enumeration
PREDECESSOR 1. Receive Inbound Transaction
2. Program Integrity business area requests enrollment
review activities.
1. Manage Provider Information process
SUCCESSOR
SHARED DATA 1. Provider Registry data: e.g., NPI, provider
demographics, provider taxonomy.
2. Member Registry data: e.g., member identifier, member
demographic data, third party resources, etc.
CONSTRAINTS The provider application and enrollment process must
accommodate the full range of provider types, organizations,
specialties, different types of applicants (e.g., the primary
FAILURES
Enrollment application terminates or suspends due to:
 Duplicate or cancelled application.
 Failure to validate application edits.
ITEM
DESCRIPTION
49
Key Information Architecture Elements in the
Business Process
Shared Data:
License, Prior
History, NPI
Trigger:
Provider
Application
Data
Activities
Provider
Enrollment
Steps
Result:
Provider
Enrollment
Status Data
50
Example of Input Messages (Class Diagram)
Enroll Provider
51
Use Triggers to Reference the Process
Triggers
New Enrollment
52
The Overall Process (Activity Diagram)
Enroll Provider
53
Data Analytics – Provider Business Area
(States, CAQH, HL7)
54
HL7 RIM to MITA Messaging
55
Static Model
 Collect relevant "data in motion" for a business process.
 Example: For the Enroll Provider business process, collect relevant
provider data from NPI, X12 transaction, and MMIS data dictionaries.
 Develop Conceptual Data Model (CDM) - e.g., provider is a role class (with
attributes) played by an entity class with attribute and scoped by one or
more entities (credentialing, supervision, enumeration etc.)
56
Dynamic Model – Use Case
Staff/MMIS verifies provider’s
credentials and checks NPS,
NPDB and HIPDB status real
time before enrolling
MMIS
NPS, NPDB, HIPDB
Start with MITA
Business Process
Templates
 Consider Use Case
Diagram
 Consider Business
Process Diagram
 Actors =
Application Roles
 Inputs and Outputs
= Messages
 Events = Trigger
Events prompting
interchange
57
Dynamic Model
ad Activ ity Diagram
MMIS
NEXT:
 Develop activity
diagram for the
business process
steps and exceptions
 Determine

Pre-condition
 Post-condition
 Add
Receive
Query
Initiate NPS Query Interface
Prov ider
Enroll Info
Find NPI & PT
NPS
Query
«datastore»
NPS Prov ider
Record
Provider
Enrollment
Rejection
Receive
Reject
Query
Reject
Query
No
Provider Indentity Confirmed?
Yes
Receive
Query
Response
ActivityFinal

Trigger Events
 Receiver
Responsibilities
(Role of Receiving
Application)
 Update requirements
NPS
Query
Response
Aggregate
NPS Data
«datastore»
Prov ider
Record
Load NPI
Provider
Enrollment
Accepted
Yes
NPS PT Align with MITA PT?
Xw alk to
MITA PT
ActivityFinal
58
Develop HL7 Domain Message Information Model (DMIM)
Conceptual Data Model (CDM)
MAP to
 Map Conceptual Data Model (Step 1
output) to HL7 Logical Data Model
to create a constrained graph
 For Enroll Provider = Provider
Registry DMIM
Logical Data Model (LDM)
59
Develop Refined Reference Information Model (RMIM)
 For Enroll Provider, there
would be RMIMs for
different interfaces based
on the activity diagram,
e.g., add and update
provider registry record,
query for provider, notify
subscribers about
changes to the provider
registry.
 Since these artifacts
already exist in HL7, MITA
would constrain to
Medicaid realm specific
requirements, e.g.,
binding to NPI and
Provider Taxonomy code
sets.
Static
Model
HAS
Dynamic
Model
60
Messaging
Finding the correct data element from HL7 RIM
Example of Enroll Provider Step 12: Request that the Manage
Administrative and Health Services Contract business process
negotiate contract and send enrollment determination notifications.
HL7 COCT_HD780005UV
61
Example of HL7 to MITA Messaging
62
HL7 v3 Static Models = MITA Logical Model
63
Serialize –> The Physical Model
Transform
Serialized Table Format
XML Schema
Serialize into Message Types from which XML Schema is generated.
64
The Resulting Schema is a component of the
Physical Model or IT specification
Physical Model is
where the Logical
Model meets the
Technical Model
65
Business/Information Track
MONDAY, MAY 18
Quarter 1
8:30-10
Quarter 2
10:30-12
Quarter 3
1:45-3
Quarter 4
3:30-5
Joint with TAC
Welcome
Remarks from Brian Osberg
Overview MITA Project
FM, FM MITA WG, SWGs
Review agenda and deliverables for the week
Subworkgroup updates
Technical/Business Service. Where does one start and/or stop and the other
take over?
Transaction Steps. Workflow analysis of an X12 transaction in and out.
LUNCH
Finish agenda from Quarter 1
Review/harmonize SWG deliverables, interactions, and interfaces
Do we understand the intended messaging?
When are messages actually happening?
Glossary Discussion
Review progress of the day: adjust Tuesday agenda.
Evening – Birds of a Feather (BOF) (Embassy Suites Hotel Bar)
TUESDAY, MAY 19
WEDNESDAY, MAY 20
Quarter 1 Data Analytics DAM Review
8:30-10
Quarter 2 Enroll Provider vocabulary
10:30-12
LUNCH
Quarter 3 Provider models
1:45-3
Quarter 4 Provider models
3:30-5
Review progress of the day: adjust Thursday agenda.
Evening – BOF and Bash – Galtier Towers
THURSDAY, MAY 21
Quarter 1
8:30-10
HDF 4.2 – DAM, clarify the artifacts in relation to MITA WG
Quarter 1 Provider models
8:30-10
Quarter 2
10:30-12
Enroll Provider Model Review
Quarter 2 Catch up quarter
10:30-12
LUNCH
Enroll Provider Model Review
LUNCH
Quarter 3 Planning
1:45-3
Discuss education needs of SWGs
Review project plan timelines
MITA wiki
Quarter 4 Planning
3:30-5
Interim meetings
Quarter 3
1:45-3
Quarter 4
3:30-5
Data Analytics DAM Review
Review progress of the day; adjust Wednesday agenda
Evening – BOF (TBD)
Farewell until Atlanta (September 2009)
66
Technical Track
MONDAY, MAY 18
WEDNESDAY, MAY 20
Quarter 1 Joint with Business/Information Track
8:30-10
Quarter 1 Support technical services (authentication,
8:30-10 authorization, audit trail.
Quarter 2 Joint with Business/Information Track
10:30-12
Quarter 2 Service 2 (HITSP/CORE transport) and
10:30-12 Service 3 (Adaptor)
LUNCH
LUNCH
Quarter 3 Gateway 5010 Overview
1:45-3
Quarter 3 Certificates
1:45-3
Quarter 4 Service 1: Inquire Member Eligibility business service and data
requirements
3:30-5
Quarter 4 Service Oriented Architecture (SOA)
3:30-5
Evening – Birds of a Feather (BOF) (Embassy Suites Hotel Bar)
TUESDAY, MAY 19
Evening – BOF and Bash – Galtier Towers
THURSDAY, MAY 21
Quarter 1 Modeling overview
8:30-10
Quarter 2 Business model data as required in 270/271 transactions
10:30-12
LUNCH
Quarter 3 RIM and mapping business model to the RIM
1:45-3
Quarter 1 Enterprise Service Bus (ESB)
8:30-10
Quarter 2 Coordination with HL7 MITA team
10:30-12
LUNCH
Quarter 3 Coordination with HL7 MITA team
1:45-3
Quarter 4 Interoperability profile
3:30-5
Evening – BOF (TBD)
Quarter 4 Planning
3:30-5
Farewell until Atlanta (September 2009)
67
Gateway 5010 Project
 Phase 1. Define and implement a stub “Inquire Member Eligibility”
Web service.
 Phase 2. Define and implement a HITSP 85 CAQH CORE compliant
connectivity service.
 Phase 3. Define and implement an X12 to MITA to MITA compliant
web service adaptor.
 Phase 4. Integration of the previous phases to form a complete
server side solution for HITSP/CORE compliant secure exchange
for 5010 Eligibility transactions.
68
Gateway 5010: Shared Goals MITA and CORE
 Drive adoption of existing, and federally supported standards to
 Reduce cost of provider-plan data exchange
 Increase provider access to robust all-payer data
 Provide a national solution and direction for real-time data
exchange
 Encourage public-private collaboration
 Vendor agnostic
 Phased approach
 Administrative focus, with clinical alignment, thus allowing for
interoperability
 Coordination with other industry initiatives.
69
Inquire Member Eligibility
 Without CORE
Trigger
XML
(WSDL)
Inquire
Member
Eligibility
Result
XML
(WSDL)
(“standard” requirements not set)
 MITA Technical Services Using CORE Rules
Web
XML
Technical
Technical
Service
Service
(aligned
(meets
With CORE
CORE
Data
Connectivity
Content
Rule)
X12
270/271)
Trigger
XML
(WSDL)
Inquire
Member
Eligibility
Result
XML
(WSDL)
XML
Technical
Service
Technical
(aligned
Service
With CORE (meets CORE
Data
Connectivity
Content
Rule)
X12
270/271)
Web
Examples of key benefits: Industry alignment, coordinated direction for industry participants (plans,
vendors) and associated cost savings by not reinventing the wheel, more robust data, can add to
ease of public health reporting.
70
Inquire Member Eligibility
 Addition of Information Architecture Data Elements
Web
XML
Technical
Technical
Service
Service
(aligned
(meets
With CORE
CORE
Data
Connectivity
Content
Rule)
X12
270/271)
Trigger
XML
(WSDL)
Inquire
Member
Eligibility
Result
XML
(WSDL)
XML
Technical
Service
Technical
(aligned
Service
With CORE (meets CORE
Data
Connectivity
Content
Rule)
X12
270/271)
Web
MITA
Data Repository
(Supports CORE
Data Requirements)
71
Inquire Member Eligibility Input Messages (Class Diagram)
72
Inquire Member Eligibility Business Process
(Activity Diagram)
73
TAC Next Steps







Announce that final adoption will be ready at MMIS 2009
Solution set certified as CORE compliant
TAC builds vendor support
TAC repository for comments and collaboration
Work through governance process with friendly partners
Artifacts placed in CMS repository
Solution set delivered to repository
74
Accomplishments
 Defined the Technical Services needed to completely implement
several MITA business services.
 Demonstrated the ability to coordinate with at least one other
major industry initiative.
 Demonstrated a working proof of concept.
 Collaborated with the MITA HL7 Work Group.

Reviewing CAQH Provider DataSource, which has over 600K+
providers, and is free of charge to providers. Its mission is to reduce
the administrative burdens of provider data collection processes like
credentialing; HITSP. Others are considering uses for this database,
e.g. emergency response, that providers could opt-into.
 Begin to define the process of adopting a MITA Technical Service
 First solution set in the repository.
75
Web Resources
•
•
•
•
•
•
http://www.cms.hhs.gov/MedicaidInfoTechArch/
http://newgforge.hl7.nscee.edu/docman/?group_id=40
http://mita.wikispaces.com/
http://www.mitahealth.org/
http://www.mitamatters.blogspot.com/
http://www.google.com – type in MITA, HL7, CMS, etc.
76
Acronym Soup
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
BARB – Business Architecture Review Board
Blog – Web Log
BCM – Business Capability Matrix
BPM – Business Process Modeling
CMS - Centers for Medicare and Medicaid Services
DAM – Domain Analysis Model
DSMO – Designated Standard Maintenance Organization
HL7 - Health Level 7
IARB – Information Architecture Review Board
MITA - Medicaid Information Technology Architecture
NMEH - National Electronic Data Interchange Healthcare
OOAD – Object Oriented Analysis and Design
PS-TG – Private Sector Technical Group
RSM; RSA – Rational Software Modeler; Architect
SIG – Special Interest Group
SOA – Services Oriented Architecture
S-TAG – Services Technical Advisory Group
SWG – Sub work group
SVN – Subversion
TAC – Technical Architecture Committee
TC – Technical Committee
TARB – Technical Architecture Review Board
UML – Unified Modeling Language
Web, WWW – World Wide Web
WG – Work Group
Wiki – What I Know Is
WSDL – Web Services Development Language
77