Post on 06-Jan-2016
description
transcript
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