MITA Information Architecture Development Framework

1
MITA Information Architecture Development
Framework
2
Presentation Purpose

• Show how the Information Architecture derives
  from the Business Architecture
• Information Architecture Methodology
• Demonstrate using Enroll Provider Business Process

Information Architecture
Business Architecture
Technical Architecture
3
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 to the
  Business Process Model yields the Business
  Capabilities
• Business Capabilities show the evolution of
  Business Processes over time

4
The Ops Con Drives the Business Process Model
Business Process
5
Business Capabilities are derived from the Model
Maturity Model and Business Process Model
Business Process Preconditions, Trigger, Data
in Motion, Steps, and Results
Business Capability
6
MITA Information Architecture Models

• The resulting 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 evolving the Logical Data
  Model
• The Logical 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

7
Relationship of the Business, Functional, and
Logical and Physical Data Models
Conceptual Data Model
Business Process
Maturity Model
Business Capability
LogicalData Model
Functional Model
Physical Data Model
8
Business Capabilities Evolve in Response to New
Medicaid Functional Requirements
Potential NHIN standard for Identity Proofing and
Authentication
Resulting modifications of the Business Process
at relevant MMM levels
Document New Requirement in a Functional Model
Evolved Business Capability
9
Medicaid Mission and Goals MITA Principles,
Goals, and Objectives
Technical Area
Business Area
Conceptual Data Model
Business Process
Technical Function
LogicalData Model
Business Capability
Technical Capability
Physical Data Model
10
The Conceptual Data Model is comprised of a
Static Concept Model and a Dynamic Activity
Diagram
Conceptual Data Model
Static Concept Model
Formalized Business Process Model
Dynamic Activity Diagram
11
Logical Model is the Serializable Object Model,
Vocabulary, Data Types, and Interactions that
comprise the Service Definition Payload
Object Model
Supported Interactions
Vocabulary and Code Sets
LogicalData Model
Data Types
12
The Resulting Schema is a component of the
Physical Model or IT specification
Physical Model is where the Logical Model meets
the Technical Model
13
Part 2 MITA Information Model and HL7 Methodology
14
HL7 v3 Artifacts
15
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

16
HL7 V3 Methodology What and How
17
HL7 v3 Static Models MITA Logical Model
18
HL7 Static Information Model
19
HL7 V3 Message Design Models
D-MIM Domain Message Information Model
20
HL7 XML Schema Generator
HL7 Vocabulary Specification
Hierarchical Message Definition And CMET
Specifications
HL7 XML Schema Generator
HL7 Data Type Specification
21
HL7 V3 Message Implementation Technology
22
(No Transcript)
23
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.
24
Design Models
An Interaction Model is a specification of
information exchanges within a particular domain
as described in storyboards and storyboard
examples.
Interaction Model
A Domain Information Model is an information
structure that represents the information content
for a set of messages within a particular domain
area.
Design Information Model
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.
25
Message Specifications
Hierarchical Message Definition
An Hierarchical Message Definition is a
specification of message elements including a
specification of their grouping, sequence,
optionality, and cardinality.
Message Type Definition
A Message Type Definition is a specification of a
collection of message elements and a set of rules
for constructing a message instance.
Implementation Technology Specification
An Implementation Technology Specification is a
specification that describes how to construct HL7
messages using a specific implementation
technology.
26
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.
27
Provider Enrollment Example

• Business Model
• Conceptual Model
• Logical Model
• Physical Model

28
Medicaid Business Process Model
29
Provider Management
Enroll Provider
Disenroll Provider
30
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

31
Key Information Architecture Elements in the
Business Process
Shared Data License, Prior History, NPI
Trigger Provider Application Data
Result Provider Enrollment Status Data
Activities Provider Enrollment Steps
32
Business Processes Reflect Evolving Medicaid
Functions / Drivers
MITA Business Functions
Statutory Source of Requirements
Evolving Functional Requirements
33
Business Process Model
The MMIS shall support timely, automated online processes and data management of the Provider Registry for Provider, Operations, Program, Care, and Program Integrity Management
Shared Data License, Prior History, NPI
Result Provider Enrollment Status Data
Activities Provider Enrollment Steps
Trigger Provider Application Data
Validate Provider Application Data Query and monitor providers 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
34
MITA Conceptual Model Evolves
35
Enroll Provider OPS CON
AS IS Concept of Operations

• As Is
• Provider credentials verified via telephone, fax,
  data matches
• Delays, non-standard responses
• Missed opportunities to identify sanctions
• To Be
• Providers credentials verified on-line
• Application triggers automated requests
• Standardized responses
• Continuous scans of sanction lists

TO BE Concept of Operations
36
MITA Maturity Model
37
Evolving Enroll Provider Business Capability
NOW 5 YEARS
10
Outcomes based enrollment continuous
verification against national databases
Enrollment/verification via RHIOs access
clinical record
Real time rules driven enrollment /verification
web portal
Use proprietary EDI for enrollment /verification
hard coded rules
Receive paper enrollment application verify via
phone manual processing
Example of Maturing Business Capabilities
38
Provider Enrollment Credentialing Step
5 YEARS
NOW
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
39
Developing an Information Architecture
Specification for Provider Enrollment

• Step 1 Static Model
• Step 2 Dynamic Model
• Step 3 HL7 Domain Message Information Model
• Step 4 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 (not a problem)
• Requires agreement from Personnel Management that
  the Medicaid
• Constrained MITA specific version of the balloted
  international standard Step 4 Develop HL7 WSDL
• Step 5 Ballot or register as a conformance
  profile with HL7 SOA SIG

40
Step 1 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 - e.g., provider is
  a role class (with attributes) played by an
  entity class with attribute and scoped by one or
  more entities RE credentialing, supervision,
  enumeration etc.

41
Step 2 (a) 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

42
Step 2 (b) 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

43
Step 3(a) Develop HL7 Domain Message
Information Model
Conceptual Data Model
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
44
Step 3(b) Develop 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 merely constrain to Medicaid realm specific
  requirements, e.g., binding to NPI and Provider
  Taxonomy code sets

Static Model
HAS
Dynamic Model
45
Step 3(c) Serialize gt The Physical Model
Transform
Serialized Table Format
XML Schema

• Serialize into Message Types from which XML
  Schema is generated.