Presentation is loading. Please wait.

Presentation is loading. Please wait.

MITA with HL7 Information Health Level 7

Similar presentations


Presentation on theme: "MITA with HL7 Information Health Level 7"— Presentation transcript:

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

2 Business Architecture Information Architecture Technical Architecture
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 Information 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 An HL7 WGM is held 3 times annually. Sunday through Friday. Intense working conference. No vendors or sales pitches. The objective is to collaborate face-to-face with world-class experts in the HL7 realm. Some private sector firms have full-time employees that work on HL7 messaging as a job within that corporation. The work produced by HL7, however, is entirely voluntary, non-proprietary, and non-profit. 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. The Minnesota MITA Development Framework (produced from the Minnesota MITA/UML projects) was cloned into the MITA Development Framework and went through the first ballot opportunity in May The MDF passed balloting on the second try. HL7 works with numerous other standards organizations – CAQH,

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 Each of the sub workgroups meet once a week via phone. The groups are comprised of state, federal and private sector staff who spend allowable time each week working on the MITA artifacts. CMS views this work as part of the funding provided to states via MITA IAPD FMAP. CMS has recognized that states and private sector won’t be able to complete all the necessary groundwork/artifacts without help. CMS has contracted staff as well. Each of the HL7 MITA sub work group teams assists each other and report to the weekly HL7 MITA work group call. The team members present at HL7 conferences and work on completion of balloting items.

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 Governance Structure
Review Board MITA Business Architecture Information Architecture Technical Architecture Business Process Business Capability S-SA process Data Models Vocabulary Mapping to Standards Data Management Strategy Service definitions Infrastructure definitions Technical processes Technical capabilities 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
MITA Users MITA Review Boards ARB BARB TARB IARB NMEH TAC The previous use cases discussed assumed that the MITA Architecture Review Board (ARB) found no “collateral architecture impact” on the other two MITA Architectures, There are three MITA Architectures; Business Architecture, Information Architecture and the Technical Architecture. This slide presents what happens if there are perceived collateral architecture impacts. The ARB determines that based on the recommended change to a single MITA architecture there is a potential for collateral architecture impact to the other MITA Architectures. The ARB therefore sends the recommended change to the other two lower level review boards to determine if the change will impact their architecture. The lower level review boards analyze the change to determine if there is an impact to their specific architecture. If there is no impact the ARB is notified. If there is an impact a recommendation is developed and given to the ARB. For both the initial impact analysis and recommendation development the lower level may use there supporting organization to produce the product.. The recommendation for the collateral architecture impact could be a change in the original change or a co-change that must accompany the original change. After the ARB has received all collateral architecture impact recommendations it will determine if they need to be consolidated and passed back to the lower level architecture review board for a composite review. This step may be iterative until the needs of all three architectures have been satisfied. Assuming no impact to the other architectures the recommendations for adoption are passed to the MITA Governance board where it is officially adopted and notification of the adoption is announced. HL7-MITA Project

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

17 Federal Enterprise Architecture (FEA)
MITA is aligned with the FEA. The Business Architecture within MITA is considered one of the most mature business models in the health care arena. CMS is aligned and in many cases, forging the path.

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 Business Capabilities will embody changes to the conceptual dynamic and static model e.g., at Level 2, when key proprietary interfaces must conform to HIPAA, the conceptual model for Level 1 will evolve to include new classes and properties, e.g., provider taxonomy and NPI are new properties of the provider role class from Level 1. The role class “clearinghouse” may be a new class for some state Operations Management Business Processes at Level 2. At Level 4, the role class “RHIO” might be a new to the Conceptual Model. These changes will be reflected in the Logical Model.

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 The MITA SWG is at the stage indicated here. The Message Design for Enroll Provider is close at hand. The Message Design for Inquire Member Eligibility is to be demonstrated as a proof of concept at MMIS 2009 in August. Members of the national TAC and a couple of MN DHS staff are involved in this project.

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. Business Capabilities will embody changes to the conceptual dynamic and static model e.g., at Level 2, when key proprietary interfaces must conform to HIPAA, the conceptual model for Level 1 will evolve to include new classes and properties, e.g., provider taxonomy and NPI are new properties of the provider role class from Level 1. The role class “clearinghouse” may be a new class for some state Operations Management Business Processes at Level 2. At Level 4, the role class “RHIO” might be a new to the Conceptual Model. These changes will be reflected in the Logical Model.

26 Medicaid Mission and Goals MITA Principles, Goals, and Objectives
Business Area Technical Area Conceptual Data Model Business Process Technical Function Logical Data Model Business Capability There are key touch points between the three architectural components of MITA: Each business process maps to data in the Conceptual Data Model (CDM) (Information Architecture) Each business capability maps to corresponding levels of maturity in the Logical Data Model (Information Architecture) A business capability definition is used as the requirements for designing a business service (Technical Architecture). The Business Service (BS) uses the Logical Data Model (LDM) attributes described in the Business Capability (BC). The LDM points to specific data standards. Technical Capability Physical Data Model

27 Evolved Business Capability
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 MITA Maturity Model 1 2 3 4 5 5 YEARS 10+ YEARS NOW

30 Provider Enrollment – Credentialing Step
5 YEARS 10+ YEARS NOW NOW 5 YEARS LEVEL 1 LEVEL 3 LEVEL 5 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 SUSAN 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 Evolving Enroll Provider Business Capability
NOW YEARS Level 1 Level 2 Level 3 Level 4 Level 5 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 Levels 4 & 5 are not currently defined by MITA. The maturity levels of most Medicaids are 1 or 2. The transitioning to EA/SOA will realize increased capability over time. This (along with As-Is and To-Be modeling) is the information that will be needed for funding IAPDs. Receive paper enrollment application; verify via phone; manual processing Example of Maturing Business Capabilities…

32 Enroll Provider Concept of Operations
COO 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 AS IS Concept of Operations TO BE Concept of Operations —088 Medicaid Beneficiary Other Payer Managed Care Eligibility Source CMS Other Agencies Bank Provider Regional Health Information Organization Finance Management Data Sharing and Communications Strategic Planning Member Provider and Contract Decision Support Medicaid Agency 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?) Language developed in the late 90’s so relatively new. It is large and complex. Software evolution as recent as the last 2 years have enhanced ability for modelers to utilize UML. But, the software is complex. Some users will stay within the confines of Visio to accomplish the UML models. That is acceptable. CMS is adopting software that is Eclipse based. Members of the modeling team are using various softwares, however the repository for the HL7 artifacts will utilize the RSM/RSA versions. In the context of a specific project, the most applicable features of UML may be tailored to accomplish the specific goal. A diagram is usually a subset of a model. UML is object oriented – think of a diagram. Diagrams produced in UML then become the Model.

34 UML v2.0 UML Modeling The HL7 MITA SWG is utilizing Class, Activity, Use Case, State Machine, and Sequence Diagrams. More may be added as necessary. 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 HL7 V3 Message Design Models
RIM Reference Information Model RIM (1) Define a D-MIM (2) Define a R-MIM (3) Create an HMD HMD 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 D-MIM Domain Message Information Model 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 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 HMD Hierarchical Message Definition

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

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

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
MITA Business Areas and Business Processes Provide Common Vocabulary and Point of Departure Uses a Maturity Model to Chart Course of Improvements CMS Encourages States to Implement Improvements

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 Activities Provider Enrollment Steps Result: Provider Enrollment Status Data

51 Example of Input Messages (Class Diagram) Enroll Provider

52 Use Triggers to Reference the Process
New Enrollment

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.) Step 1: Static Model * Collect relevant "data in motion" for some biz process - e.g., For enroll provider process collect relevant provider data from NPI, X12 transaction, and MMIS data dictionaries * Develop Conceptual Data Model - e.g., provider is a role (with attributes) played by an entity with attribute and scoped by one or more entities RE: credentialing, supervision, enumeration etc. * Map to HL7 Logical Data Model - would look like the add and update provider RMIM in the attached with realm specific requirements, e.g., binding to NPI and Provider Taxonomy code sets Step 2: Dynamic Model * Do activity diagram for biz process - typical biz process steps - from MITA Biz Process Templates as vetted with NMEH * Determine the pre-condition, post-condition, trigger events, receiver responsibilities and update requirements * Develop WSDL describing service Step 3: Develop HL7 Domain Message Information Model * Take output of step 1 and 2, creates constrainable graph from which xml schema can be derived * Ballot through HL7 to vet among the Medicaid Community in a consensus process, which, if followed, should result in an ANSI accredited standard o Requires agreement of the Community Based Health Care SIG to support project (not a problem) o Requires agreement from Personnel Management that the Medicaid flavor is conformant with their balloted international standard (properly constrained realm specific specialization) (not a problem)

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

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

59 Develop HL7 Domain Message Information Model (DMIM)
Conceptual Data Model (CDM) 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 (LDM)

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
Transform Serialized Table Format XML Schema Serialize into Message Types from which XML Schema is generated.

65 Physical Model is where the Logical Model meets the Technical Model
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 20 Quarter 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 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. Enroll Provider vocabulary LUNCH Quarter 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? Provider models Quarter 4 3:30-5 Glossary Discussion Review progress of the day: adjust Tuesday agenda. 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 21 HDF 4.2 – DAM, clarify the artifacts in relation to MITA WG Enroll Provider Model Review Catch up quarter Planning Discuss education needs of SWGs Review project plan timelines MITA wiki Review progress of the day; adjust Wednesday agenda Interim meetings Evening – BOF (TBD) Farewell until Atlanta (September 2009)

67 Technical Track MONDAY, MAY 18 WEDNESDAY, MAY 20 TUESDAY, MAY 19
Quarter 1 8:30-10 Joint with Business/Information Track Support technical services (authentication, authorization, audit trail. Quarter 2 10:30-12 Service 2 (HITSP/CORE transport) and Service 3 (Adaptor) LUNCH Quarter 3 1:45-3 Gateway 5010 Overview Certificates Quarter 4 3:30-5 Service 1: Inquire Member Eligibility business service and data requirements 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 21 Modeling overview Enterprise Service Bus (ESB) Business model data as required in 270/271 transactions Coordination with HL7 MITA team RIM and mapping business model to the RIM Interoperability profile 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 Trigger XML (WSDL) Inquire Member Eligibility Result XML (WSDL) (“standard” requirements not set) MITA Technical Services Using CORE Rules Web Technical Service (meets CORE Connectivity Rule) XML Technical Service (aligned With CORE Data Content X12 270/271) Trigger XML (WSDL) Inquire Member Eligibility Result XML (WSDL) XML Technical Service (aligned With CORE Data Content X12 270/271) Technical Service (meets CORE Connectivity 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 to ease of public health reporting.

71 Inquire Member Eligibility
Addition of Information Architecture Data Elements Web Technical Service (meets CORE Connectivity Rule) XML Technical Service (aligned With CORE Data Content X12 270/271) Trigger XML (WSDL) Inquire Member Eligibility Result XML (WSDL) XML Technical Service (aligned With CORE Data Content X12 270/271) Technical Service (meets CORE Connectivity Rule) Web MITA Data 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/
– 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


Download ppt "MITA with HL7 Information Health Level 7"

Similar presentations


Ads by Google