MITA with HL7 InformationOut of Cycle HL7 WGM, 18-21 May, 2009, St. Paul, MN

Health Level 7

2

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

Technical Architecture

Information Architecture

3

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.

4

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.

5

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

6

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

7

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

8

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.

9

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.

10

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

11

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.

12

MITA Governance Structure

MITAGoverning Board

InitiativeReviewBoard

ArchitectureReviewBoard

BusinessArchitecture

ReviewBoard

InformationArchitecture

ReviewBoard

TechnicalArchitecture

ReviewBoard

Sub-Workgroup

Registrar

13

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

•Data Models

•Vocabulary

•Mapping to Standards

•Data Management Strategy

•Service definitions

•Infrastructure definitions

•Technical processes

•Technical capabilities

•Mapping to Standards

•MITA Standards

•Framework updates

14

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

15

Multi-Architecture Impact

NMEH

HL7-MITAProject

TAC

BARB

IARB

TARB

ARB

MITA Users

16

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

17

Federal Enterprise Architecture (FEA)

18

Healthcare Standards Environment

FEAParticipates in

19

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.

20

HL7 MITA Work Group Process Flow (Draft)

21

HL7 Development Framework

22

Framework is Essential

Healthcare Development Framework (HDF)

Version 1.2Published on: April 23rd, 2008

23

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

24

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

25

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.

26

Business Area

Technical Area

Technical Function

Technical Capability

Conceptual Data Model

LogicalData Model

Business Capability

Business Process

Medicaid Mission and Goals MITA Principles, Goals, and Objectives

Physical Data Model

27

Business Capabilities Evolve in Response to New Medicaid Functional Requirements

Evolved Business Capability

Internet 2 Provider Credentialing Registry

Potential NHIN standard for Identity Proofing and Authentication

Resulting modifications of the Business

Process at relevant MMM levels

ID Capability Description Applicable Laws & Federal

directives Data

PCM 1.3

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 PAY FOR PERFORMANCE

USC 42 Chapter 7 Subchapter XIX Sec. 1396a (a) & (p) Exclusion of sanctioned providers President Bush’s proposed fiscal year 2007 budget

HIPAA NPI & Provider Taxonomy. EIN, SSN

PCM 1.4

Report Sanctioned Providers

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 99-660 and Section 221(a) of Public

HIPAA NPI & Provider Taxonomy.

Document New Requirement in a Functional Model

28

Business Capabilities are derived from the Model Maturity Model and Business Process Model

Business Capability

Enroll Provider Business Process ITEM DETAILS

DESCRIPTION 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 EVENT

A provider enrollment data set (received from the Receive Inbound Transaction process. Includes both paper and EDI).

RESULTS Validated data set sent to the Manage Provider Information process)

BUSINESS PROCESS STEPS

1. Start: Receive provider enrollment data set from the Inbound Transaction process

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]

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

29

MITA Maturity Model1 2 3 4 5

Definition of State Medicaid Levels of Maturity

Level 1 Level 2 Level 3 Level 4 Level 5

Agency focuses on meeting compliance thresholds for State and Federal regulations, accurate enrollment of eligibles and timely and accurate payment of claims.

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 one-stop-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.

5 YEARS 10+ YEARSNOW

30

Business Capability Matrix

Provider enrollment staff spend hours verifying provider

credentials or fail to do primary credentialing verification

because of difficulty and liability risk

Provider enrollment staff use automated, web-based, online credentialing and sharing of

primary source verification with other state health programs and

other Medicaid agencies

The enrollment process is automated by an interface with

the RHIO Provider Directory which invokes a credential

verification service

5 YEARS

LE

VE

L 1

LE

VE

L 3

LE

VE

L 5

NOW5 YEARS 10+ YEARSNOW

Provider Enrollment – Credentialing Step

31

Evolving Enroll Provider Business Capability

Level 1

Level 2

Level 3

Level 3

Level 4

Level 4

Level 5

Receive paper enrollment application; verify via phone; manual processing

Real time rules driven enrollment /verification; one-stop collaboration

Outcomes based enrollment; continuous verification against national databases

NOW 5 YEARS 10+

Example of Maturing Business Capabilities…

Use proprietary EDI for enrollment /verification; legacy MMIS hard coded rules

Enrollment/verification via RHIOs; access clinical record

32

Enroll Provider Concept of Operations 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

SendsContract

Business Associates

Sends Payment and RA

ReceivesEnrollment

Informationand ID

2629-06—087

CMSOther

Agencies

Bank

Managed Care

Medicaid Beneficiary

Managed Care

Eligibility Source

PaymentManagement

ExternalData-Sharing

Exchange

InformationManagement

MemberManagement

Provider andContractMgmt.

MedicaidAgency Utilization

and QualityManagement

Beneficiary Services Service Auth. andPrepayment Review

Provider

Provider

Provider

Medicaid Beneficiary

RequestAuth.

ReceivesAuths.

Other Payer

Provider

Provider

Provider

Managed Care

Provider Provider

Provider

Provider

SendsInformation

SendsReport

MakesInquiries

Receives Information

RequestsRecords

MakesInquiries

Receives Information

Provider

SendsTreatment

ReceivesApproval

ProvidesRecords

Responds

Inquiries

Sends 1099

Sends Repayment

NotifiesReadjustment

ReceivesEnrollment ID

SendsApplication

SendsEligibility

Information

RequestsPayments

Sends Encounters

SendsClaims

Managed Care

Receives Rates

Assignment

Receives Contract

SendsProposal

SubmitsProposal

AS IS Concept of Operations

TO BE Concept of Operations

2629-06—088

Medicaid Beneficia

ry

Other Payer

Managed Care

Eligibility Source

CMS

Other Agencies

Bank

Provider

Provider

Provider

FinanceManagement

Data Sharing and Communicat

ions

StrategicPlanning

MemberManagement

Provider and ContractManagement

DecisionSupport

MedicaidAgency

Other RHIOs

33

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?)

34

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.

35

HL7 Modeling Hierarchy

36

RIM

(1)Define aD-MIM

D-MIM

(2)Define aR-MIM

R-MIM

(3)Create

an HMD

HMD

RIMReference Information Model

D-MIMDomain Message Information Model

R-MIMRefined Message Information Model

HMDHierarchical Message Definition

HL7 V3 Message Design Models

• Select RIM classes to be included in D-MIMSelect RIM classes to be included in D-MIM

• Clone subset classes of the RIMClone subset classes of the RIM

• Select a subset of class relationshipsSelect a subset of class relationships

• Select a subset of class attributes Select a subset of class attributes

• Select a subset of attribute data types and domainsSelect a subset of attribute data types and domains

• Create clones of D-MIM classes and attributesCreate clones of D-MIM classes and attributes

• Assign alias class and relationship role namesAssign alias class and relationship role names

• Eliminate unnecessary class hierarchiesEliminate unnecessary class hierarchies

• Finalize class relationships and cardinalityFinalize class relationships and cardinality

• Finalize attribute data types and domainsFinalize attribute data types and domains

• Select a root class for the messageSelect a root class for the message

• Arrange classes and attributes hierarchicallyArrange classes and attributes hierarchically

• Declare inclusion and repetition constraintsDeclare inclusion and repetition constraints

• Declare data type and domain value constraintsDeclare data type and domain value constraints

• Assign message element namesAssign message element names

37

ReferenceInformation

Model

ReferenceInformation

Model

DatatypeSpecification

DatatypeSpecification

VocabularySpecificationVocabulary

SpecificationReference

Models

InteractionModel

InteractionModel

DesignInformation

Model

DesignInformation

Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition

ImplementationTechnology

Specification

ImplementationTechnology

Specification

MessageSpecifications

MessageProfile

Specification

MessageProfile

Specification

LocalizedMessage

Specification

LocalizedMessage

Specification

MessageConformanceStatements

MessageConformanceStatements

ConformanceProfiles

38

ReferenceInformation

Model

ReferenceInformation

Model

DatatypeSpecification

DatatypeSpecification

VocabularySpecificationVocabulary

Specification

Reference Models

The HL7 Reference Information Model is the information model from which all other information models and message specifications are derived.

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.

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.

39

InteractionModel

InteractionModel

DesignInformation

Model

DesignInformation

Model

CommonMessage Type

Model

CommonMessage Type

Model

Design Models

An Interaction Model is a specification of information exchanges within a particular domain as described in storyboards and storyboard examples.

A Domain Information Model is an information structure that represents the information content for a set of messages within a particular domain area.

A Common Message Type Model is a definition of a set of common message components that can be referenced in various message specifications.

40

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition

ImplementationTechnology

Specification

ImplementationTechnology

Specification

Message Specifications

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.

41

MessageProfile

Specification

MessageProfile

Specification

LocalizedMessage

Specification

LocalizedMessage

Specification

MessageConformance

Statement

MessageConformance

Statement

Conformance Profiles

A Localized Message Specification is a refinement of a HL7 message specification standard that is specified and balloted by an HL7 International Affiliate.

A Message Profile Specification is a description of a particular or desired implementation of an HL7 Message standard or Localized Message specification.

A Message Conformance Statement is a comparison of a particular messaging implementation and an HL7 message standard, localization, or profile.

42

HL7 V3 Methodology: What and How

Use Case Modeling

Interaction ModelingService Definition

Message Design

Information Modeling

RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

InteractionReferences

43

Domain Analysis Model (DAM)

class 3.7 DAM Artifacts

Domain Analysis Model (DAM)

«optional»Use Case Analysis

Story board

Information Model (Analysis)

Process Flow

«optional»Business Rules Description

Business Trigger Analysis

«optional»Glossary of Classes and Attributes

class 3.7 DAM Artifacts

Domain Analysis Model (DAM)

«optional»Use Case Analysis

Story board

Information Model (Analysis)

Process Flow

«optional»Business Rules Description

Business Trigger Analysis

«optional»Glossary of Classes and Attributes

44

Domain Analysis Model (DAM)

class 4.2: Context

Specification DesignRequirements Analysis

Domain Analysis Model

Stakeholder/Business Requirements

Business Process Model Analysis

Process Flow (Activity Diagram)

Use Case Model

Information Model

Business Trigger Analysis

(from Annex A. Domain Analysis Example)

Specification Dev elopment

Requirements Analysis

Specification Design

Domain Analysis Model

Design Information Model - DIM

Message Structure - CIM

Localization - LIM

Dynamic Model

Technology-Specific Artifacts

(from Annex A. Domain Analysis Example)

45

Design Dynamic Modelact 4.4.2: Design Dynamic Model

Analyst :Business Analyst Facilitator :HL7 Modeling Facilitator

Domain Analysis Model (DAM)

(from 3.7 Artifacts)

DefineInteractionsTriggers

Specify the type ofinteractions and system

roles

Design Information Model (DIM)

(from 4.7.1 Information Modeling Artifacts)

«UML State chart»State Transitions

(from 4.7.2 Dynamic Modeling Artifacts)

«UML Activity Di...Sending Process

Description

(from 4.7.2 Dynamic Modeling Artifacts)

Document notificationtriggers

Document query or request pre-conditions

«UML Sequence Diagra...System Interaction Description

(from 4.7.2 Dynamic Modeling Artifacts)

Document receiv er's responsibilities

«UML Activity Di...Receiv ing Process

Description(from 4.7.2 Dynamic Modeling Artifacts)

Rev iew Dynamic Model Design

Constrained Information Model

(CIM)

(from 4.7.1 Information Modeling Artifacts)

Interface Specification

(from 4.7.2 Dynamic Modeling Artifacts)

Publish Design Model andReports

(from 4.4 P rocess)

Dynamic Model Artifact

Process Activit y

Information Model Artifact

Runtime Artifact

Legend Generate TechnologySpecific Artifacts

(from 4.4.1 Information Model Design )

Deriv e System Functions

Functional Model

(from 4.7.2 Dynamic Modeling Artifacts)

«input»

«input»

«input»

«input»

parameter specification

46

MITA Enroll Provider Example

47

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

48

Medicaid Business Process Model

Medicaid Business Process Model

Care Management

Contractor Management

Operations Management

Member Management

Provider Management

Program Management

Program IntegrityManagement

Business Relationship Management

Enroll MemberDisenroll Member

Inquire Member EligManage Member Info

Manage Member Comm

Award ContractClose out Contract

Manage Contractor CommManage Contractor InfoInquire Contractor Info

Identify Candidate CaseManage Case

Apply AttachmentAudit Claim-EncounterManage Drug Rebate

Prepare EOBCalculate Spend-down

Enroll ProviderDisenroll Provider

Manage Provider CommManage Provider Info

Perform Provider Outreach

Establish CaseManage Case

Manage Medicaid Pop Health

Establish RelationshipManage RelationshipManage Relationship

CommunicationsTerminate Relationship

Maintain State PlanFormulate Budget

Manage Rate SettingManage 1099sManage FFP

49

MITA Business Process

Views the business cross-functionally.

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 ITEM DETAILS

DESCRIPTION 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:

TRIGGER EVENT

A provider enrollment data set (received from the Receive Inbound Transaction or Manage Provider Communication process.

RESULTS Validated data set sent to the Manage Provider Information process

BUSINESS PROCESS STEPS

1. Start: Receive provider enrollment data set. 2. Validate application syntax/semantic conformance. 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. 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 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.

50

Key Information Architecture Elements in the Business Process

Shared Data: License, Prior History, NPI

Trigger:Provider

Application Data

Result:Provider

Enrollment Status Data

ActivitiesProvider

EnrollmentSteps

51

Example of Input Messages (Class Diagram) Enroll Provider

52

Use Triggers to Reference the Process

New Enrollment

Triggers

53

The Overall Process (Activity Diagram)Enroll Provider

54

Data Analytics – Provider Business Area(States, CAQH, HL7)

55

HL7 RIM to MITA Messaging

56

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.)

57

Dynamic Model – Use Case

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

Staff/MMIS verifies provider’scredentials and checks NPS,NPDB and HIPDB status real

time before enrolling

NPS, NPDB, HIPDBMMIS

58

Dynamic Model

NEXT: Develop activity

diagram for the business process steps and exceptions

Determine Pre-condition Post-condition

Add Trigger Events Receiver

Responsibilities (Role of Receiving Application)

Update requirements

ad Activ ity Diagram

MMIS NPS

Initiate NPS Query Interface

NPS Query

Receive Query

Find NPI & PT

«datastore»

NPS Prov ider Record

Provider Indenti ty Confirmed?

Prov ider Enroll Info

Reject Query

Receive Reject Query

Provider Enrol lment Rejection

AggregateNPS Data

Query Response

Receive Query

Response

NPS PT Align with MITA PT?

«datastore»

Prov ider Record

Xw alk toMITA PT

Activi tyFinal

Load NPI

Provider Enrol lment Accepted

Activi tyFinal

Yes

No

Yes

59

Develop HL7 Domain Message Information Model (DMIM)

Map Conceptual Data Model (Step 1 output) to HL7 Logical Data Model to create a constrained graph

For Enroll Provider = Provider Registry DMIM

Conceptual Data Model (CDM)

Logical Data Model (LDM)

MAP to

60

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

61

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

62

Example of HL7 to MITA Messaging

63

HL7 v3 Static Models = MITA Logical Model

64

Serialize –> The Physical Model

Serialize into Message Types from which XML Schema is generated.

Transform

Serialized Table Format XML Schema

65

The Resulting Schema is a component of the Physical Model or IT specification

Physical Model is where the Logical Model meets the Technical Model

66

Business/Information Track

MONDAY, MAY 18 WEDNESDAY, MAY 20Quarter 1

8:30-10

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

Quarter 1

8:30-10

Data Analytics DAM Review

Quarter 2

10:30-12

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.

Quarter 2

10:30-12

Enroll Provider vocabulary

LUNCH LUNCHQuarter 3

1:45-3

Finish agenda from Quarter 1

Review/harmonize SWG deliverables, interactions, and interfaces

Do we understand the intended messaging?

When are messages actually happening?

Quarter 3

1:45-3

Provider models

Quarter 4

3:30-5

Glossary Discussion

Review progress of the day: adjust Tuesday agenda.

Quarter 4

3:30-5

Provider models

Review progress of the day: adjust Thursday agenda.

Evening – Birds of a Feather (BOF) (Embassy Suites Hotel Bar) Evening – BOF and Bash – Galtier Towers

TUESDAY, MAY 19 THURSDAY, MAY 21Quarter 1

8:30-10

HDF 4.2 – DAM, clarify the artifacts in relation to MITA WG Quarter 1

8:30-10

Provider models

Quarter 2

10:30-12

Enroll Provider Model Review Quarter 2

10:30-12

Catch up quarter

LUNCH LUNCHQuarter 3

1:45-3

Enroll Provider Model Review Quarter 3

1:45-3

Planning

Discuss education needs of SWGs

Review project plan timelines

MITA wikiQuarter 4

3:30-5

Data Analytics DAM Review

Review progress of the day; adjust Wednesday agenda

Quarter 4

3:30-5

Planning

Interim meetings

Evening – BOF (TBD) Farewell until Atlanta (September 2009)

67

Technical Track

MONDAY, MAY 18 WEDNESDAY, MAY 20Quarter 1

8:30-10

Joint with Business/Information Track Quarter 1

8:30-10

Support technical services (authentication, authorization, audit trail.

Quarter 2

10:30-12

Joint with Business/Information Track Quarter 2

10:30-12

Service 2 (HITSP/CORE transport) and

Service 3 (Adaptor)

LUNCH LUNCHQuarter 3

1:45-3

Gateway 5010 Overview Quarter 3

1:45-3

Certificates

Quarter 4

3:30-5

Service 1: Inquire Member Eligibility business service and data requirements

Quarter 4

3:30-5

Service Oriented Architecture (SOA)

Evening – Birds of a Feather (BOF) (Embassy Suites Hotel Bar) Evening – BOF and Bash – Galtier Towers

TUESDAY, MAY 19 THURSDAY, MAY 21Quarter 1

8:30-10

Modeling overview Quarter 1

8:30-10

Enterprise Service Bus (ESB)

Quarter 2

10:30-12

Business model data as required in 270/271 transactions Quarter 2

10:30-12

Coordination with HL7 MITA team

LUNCH LUNCHQuarter 3

1:45-3

RIM and mapping business model to the RIM Quarter 3

1:45-3

Coordination with HL7 MITA team

Quarter 4

3:30-5

Interoperability profile Quarter 4

3:30-5

Planning

Evening – BOF (TBD) Farewell until Atlanta (September 2009)

68

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.

69

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.

70

Inquire Member Eligibility Without CORE

TriggerXML

(WSDL)

InquireMember

Eligibility

ResultXML

(WSDL)

MITA Technical Services Using CORE Rules

Web

TechnicalService (meetsCORE

ConnectivityRule)

InquireMember

Eligibility

XMLTechnicalService(aligned

With COREData

ContentX12

270/271)

TriggerXML

(WSDL)

XMLTechnical

Service(aligned

With COREData

ContentX12

270/271)

ResultXML

(WSDL)

Technical Service

(meets COREConnectivity

Rule)

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 toease of public health reporting.

(“standard” requirements not set)

71

Inquire Member Eligibility

Addition of Information Architecture Data Elements

Web

TechnicalService (meetsCORE

ConnectivityRule)

InquireMember

Eligibility

XMLTechnicalService(aligned

With COREData

ContentX12

270/271)

TriggerXML

(WSDL)

XMLTechnical

Service(aligned

With COREData

ContentX12

270/271)

ResultXML

(WSDL)

Technical Service

(meets COREConnectivity

Rule)

Web

MITAData Repository(Supports CORE

Data Requirements)

72

Inquire Member Eligibility Input Messages (Class Diagram)

73

Inquire Member Eligibility Business Process (Activity Diagram)

74

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

75

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.

76

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.

77

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