MITA with HL7 Information Out of Cycle HL7 WGM, 18-21 May, 2009, St. Paul, MN Health Level 7

1. MITA with HL7 Information Out of Cycle HL7 WGM, 18-21 May, 2009, St. Paul, MN HealthLevel7

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) Information Architecture Business Architecture Technical 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

13. MITA Architecture Review Board • MITA Standards • Framework updates MITA Business Architecture Review Board MITA Information Architecture Review Board MITA Technical Architecture Review Board • Service definitions • Infrastructure definitions • Technical processes • Technical capabilities • Mapping to Standards • Business Process • Business Capability • S-SA process • Data Models • Vocabulary • Mapping to Standards • Data Management Strategy MITA Architecture Governance Structure

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. MITA Review Boards ARB BARB TARB IARB Multi-Architecture Impact MITA Users NMEH TAC HL7-MITA Project

16. MITA Review Boards ARB BARB TARB IARB The Big Picture MITA Users STAG Technical Implementer New Bus Proc NMEH TAC Other DSMOs State Business SMEs HL7-MITA Project Independent Information Spec. HL7 HL7Healtth Data Community

17. Federal Enterprise Architecture (FEA)

18. Healthcare Standards Environment FEA Participates 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.2 Published 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. 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

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

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

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

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

31. 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; one-stop collaboration Use proprietary EDI for enrollment /verification; legacy MMIS hard coded rules Receive paper enrollment application; verify via phone; manual processing Example of Maturing Business Capabilities…

32. 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 Concept of Operations 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

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

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

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

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

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

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

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

43. Domain Analysis Model (DAM)

44. Domain Analysis Model (DAM)

45. Design Dynamic Model

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

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.

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