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. COO 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 Business Process Conceptual Data Model 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. Application Trigger RIM Role Event Derive Information Modeling Storyboard D-MIM Sender Receiver Restrict Triggers References Interaction R-MIM Example Serialize Interaction Modeling Service Definition HMD Restrict Message Design Storyboard Message Content Example Type Use Case Modeling HL7 V3 Methodology: What and How

17. HL7 v3 Static Models = MITA Logical Model

18. HL7 Static Information Model

19. RIM RIMReference Information Model • Select RIM classes to be included in D-MIM • Clone subset classes of the RIM • Select a subset of class relationships • Select a subset of class attributes • Select a subset of attribute data types and domains (1) Define a D-MIM D-MIM • Create clones of D-MIM classes and attributes • Assign alias class and relationship role names • Eliminate unnecessary class hierarchies • Finalize class relationships and cardinality • Finalize attribute data types and domains (2)Define a R-MIM R-MIM R-MIM Refined Message Information Model • Select a root class for the message • Arrange classes and attributes hierarchically • Declare inclusion and repetition constraints • Declare data type and domain value constraints • Assign message element names (3) Create an HMD HMD Hierarchical Message Definition HMD HL7 V3 Message Design Models D-MIM Domain Message Information Model

20. XML Schema Specification HL7 XML Schema Generator HL7 Vocabulary Specification Hierarchical Message Definition And CMET Specifications HL7 XML Schema Generator HL7 Data Type Specification

21. Hierarchical Message Definition And CMET Specifications XML Schema Specification HL7 Message Data Parsing HL7 Message HL7-Conformant Message Data Instance Application Creation HL7-Conformant Application HL7 V3 Message Implementation Technology

22. Reference Models Reference Information Model Datatype Specification Vocabulary Specification Design Models Interaction Model Design Information Model Common Message Type Model Message Specifications Hierarchical Message Definition Message Type Definition Implementation Technology Specification Conformance Profiles Message Profile Specification Localized Message Specification Message Conformance Statements

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 Support ProviderEnrollment Provider Information Management Manage Provider Communication Manage Provider Information Manage Provider Grievance and Appeal Perform Provider Outreach Inquire Provider Information 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 Shared Data: License, Prior History, NPI Result: Provider Enrollment Status Data Activities Provider Enrollment Steps Trigger: Provider Application Data

34. CMS Provider Regional Health Information Organization Other Agencies Eligibility Source Provider and Contract Management Bank Member Management Finance Management Medicaid Beneficiary Medicaid Agency Strategic Planning DecisionSupport Data Sharing and Communications Provider Other Payer 1 2 3 4 5 Managed Care Provider 2629-06—088 Other RHIOs MITA Conceptual Model Evolves

35. COO CMS Provider Regional Health Information Organization Other Agencies Eligibility Source Provider and Contract Management Bank Member Management Finance Management Medicaid Beneficiary Medicaid Agency Strategic Planning DecisionSupport Data Sharing and Communications Provider Other Payer Managed Care Provider 2629-06—088 Other RHIOs 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: • Provider’s credentials verified on-line • Application triggers automated requests • Standardized responses • Continuous scans of sanction lists TO BE Concept of Operations

36. 5 YEARS 10+ YEARS NOW 1 2 3 4 5 MITA Maturity Model

37. Level 5 Level 4 Level 4 Level 3 Level 3 Level 2 Level 1 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. 5 YEARS 10+ YEARS NOW LEVEL 5 LEVEL 3 LEVEL 1 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 Conceptual Data Model (Step 1 output) to HL7 Logical Data Model to create a constrained graph • For Enroll Provider = Provider Registry DMIM MAP to Logical Data Model

44. Step 3(b) – Develop RMIM Static Model • 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 HAS Dynamic Model

45. Step 3(c): Serialize –> The Physical Model Transform Serialize into Message Types from which XML Schema is generated. Serialized Table Format XML Schema