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, MNHealth Level 7
2 Business Architecture Information Architecture Technical Architecture PresentationHL7MITA, HL7, CMS, DHHS, ONC, FEA -> alignment of healthcare architectureMITA Business Architecture -> Information ArchitectureMITA Enroll Provider (HL7 MITA WG Example)MITA Inquire Member Eligibility (Gateway 5010 Project)Business ArchitectureInformation ArchitectureTechnical Architecture
3 HL7An 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 blocksConformanceInfrastructure & MessagingImplementable Technology Specifications (ITS)JavaModeling & MethodologySecurityServices Oriented Architecture (SOA)TemplatesVocabulary
6 HL7 DiversifiedHL7 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 SyntaxGELLOVisual/Context Integration (CCOW)Version 2.x XML (XML encoding of HL7 messages)Clinical Context Documentation Implementation Guide (CCD)Electronic Health Record System (EHRS) Functional ModelPersonal Health Record System (PHRS) Functional ModelServices (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 PageAn 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, VocabularyCollaboration with other federal projects: SAMHSA, DHHS, FDA, NIST, DoD, VHA, Canada InfowayState 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 GroupBusiness Process TeamUse Cases, Storyboards, additional requirements for v2.01 business process templatesData Analytics TeamInformation Model Data analysis and databaseModelers TeamDiagrams and models for business processesVocabulary TeamMedicaid specific vocabularyEducation and Training TeamDocumentation and assistance for newcomers; lessons learned; best practicesEach 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.
14 Supporting Review Organization Activities Supporting Organization – TACActivities –Technical function recommendationsTechnical Function capability level recommendationsTechnical Function Information Model recommendationsTechnical Service WSDL recommendationsHarmonization recommendation between MITA and TechnicalInterface between MITA and technical industry
15 Multi-Architecture Impact MITA UsersMITA Review BoardsARBBARBTARBIARBNMEHTACThe 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-MITAProject
16 Technical Implementer The Big PictureMITA UsersSTAGMITA Review BoardsARBTechnical ImplementerNew Bus ProcBARBTARBIARBNMEHTACDSMO = Designated Standard Maintenance OrganizationOther DSMOsState BusinessSMEsHL7-MITAProjectIndependentInformation Spec.HL7HL7Healtth DataCommunity
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 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.
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.UMLUse Case modelsActivity modelsMessage schemas (HMD, CMET)Information models (DMIM, RMIM)Abstract WSDLBusiness 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 ModelingProduce a storyboard exampleGeneralize the storyboard example into a storyboardInformation ModelingDefine classes, attributes, datatypes, and relationshipsDefine vocabulary domains, code systems, and value setsDefine states, trigger events, and transitionsInteraction ModelingDefine application rolesDefine interactionsMessage DesignDefine D-MIM, CMETs, and R-MIMsDefine HMD and Message TypesThe 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 ModelConceptual ModelLogical ModelPhysical ModelNote: CMS will provide Medicaids with specifications formaking 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 AreaTechnical AreaConceptual Data ModelBusiness ProcessTechnical FunctionLogical Data ModelBusiness CapabilityThere 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 CapabilityPhysical Data Model
27 Evolved Business Capability Business Capabilities Evolve in Response to New Medicaid Functional RequirementsPotential NHIN standard for Identity Proofing and AuthenticationResulting modifications of the Business Process at relevant MMM levelsDocument New Requirement in a Functional ModelEvolved 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 ResultsBusiness Capability
30 Provider Enrollment – Credentialing Step 5 YEARS10+ YEARSNOWNOW5 YEARSLEVEL 1LEVEL 3LEVEL 5The enrollment process is automated by an interface with the RHIO Provider Directory which invokes a credential verification serviceProvider enrollment staff use automated, web-based, online credentialing and sharing of primary source verification with other state health programs and other Medicaid agenciesSUSANProvider enrollment staff spend hours verifying provider credentials or fail to do primary credentialing verification because of difficulty and liability riskBusiness Capability Matrix
31 Evolving Enroll Provider Business Capability NOW YEARSLevel 1Level 2Level 3Level 4Level 5Outcomes based enrollment; continuous verification against national databasesEnrollment/verification via RHIOs; access clinical recordReal time rules driven enrollment /verification; one-stop collaborationUse proprietary EDI for enrollment /verification; legacy MMIS hard coded rulesLevels 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 processingExample of Maturing Business Capabilities…
32 Enroll Provider Concept of Operations COOEnroll Provider Concept of OperationsAs Is:Provider credentials verified via telephone, fax, data matchesDelays, non-standard responsesMissed opportunities to identify sanctionsTo Be:Provider’s credentials verified on-lineApplication triggers automated requestsStandardized responsesContinuous scans of sanction listsAS IS Concept of OperationsTO BE Concept of Operations—088Medicaid BeneficiaryOther PayerManaged CareEligibility SourceCMSOther AgenciesBankProviderRegional Health Information OrganizationFinanceManagementData Sharing and CommunicationsStrategicPlanningMemberProvider and ContractDecision SupportMedicaidAgencyOther RHIOs
33 Challenges with the Art/Science of Modeling “Essentially, all models are wrong, but some are useful.” George E. P. BoxEvolution to Unified Modeling Language (UML)Object-Oriented Analysis (OOA)Object-Oriented Design (OOD)Object-Oriented Analysis and Design (OOAD)Object-Oriented Software Engineering (OOSE)UMLGeneral 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.0UML ModelingThe 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.
36 HL7 V3 Message Design Models RIM Reference Information ModelRIM(1)Define aD-MIM(2) Define aR-MIM(3)Createan HMDHMDSelect RIM classes to be included in D-MIMClone subset classes of the RIMSelect a subset of class relationshipsSelect a subset of class attributesSelect a subset of attribute data types and domainsD-MIMDomain Message Information ModelCreate clones of D-MIM classes and attributesAssign alias class and relationship role namesEliminate unnecessary class hierarchiesFinalize class relationships and cardinalityFinalize attribute data types and domainsR-MIMRefined Message Information ModelSelect a root class for the messageArrange classes and attributes hierarchicallyDeclare inclusion and repetition constraintsDeclare data type and domain value constraintsAssign message element namesHMDHierarchical Message Definition
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.DatatypeSpecificationThe 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.VocabularySpecificationThe 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.DesignInformationModelCommonMessage TypeModelA 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 HierarchicalMessageDefinitionAn Hierarchical Message Definition is a specification of message elements including a specification of their grouping, sequence, optionality, and cardinality.MessageTypeDefinitionA Message Type Definition is a specification of a collection of message elements and a set of rules for constructing a message instance.ImplementationTechnologySpecificationAn 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.MessageProfileSpecificationA Message Profile Specification is a description of a particular or desired implementation of an HL7 Message standard or Localized Message specification.MessageConformanceStatementA 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 ModelingInteraction ModelingService DefinitionInformation ModelingApplicationRoleSenderReceiverTriggerEventTriggersRIMD-MIMDeriveMessage DesignExampleStoryboardInteractionReferencesRestrictR-MIMHL7 V3 Methodology: What and HowContentSerializeHMDRestrictMessageType
47 Developing an Information Architecture Specification for Provider Enrollment Static ModelDynamic ModelHL7 Domain Message Information ModelBallot through HL7 to vet among the Medicaid Community in a consensus process, which, if followed, should result in an ANSI accredited standardRequires agreement of the Community Based Health Care SIG to support projectRequires agreement from other HL7 WGsConstrained MITA specific version of the balloted international standardDevelop HL7 WSDLBallot 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 DepartureUses a Maturity Model to Chart Course of ImprovementsCMS 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, NPITrigger:Provider Application DataActivitiesProvider EnrollmentStepsResult: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)
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., Forenroll provider process collect relevant provider data from NPI, X12 transaction, and MMIS data dictionaries* Develop Conceptual Data Model - e.g., provider is a role (withattributes) 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 updateprovider RMIM in the attached with realm specific requirements, e.g., binding to NPI and Provider Taxonomy code setsStep 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 serviceStep 3: Develop HL7 Domain Message Information Model* Take output of step 1 and 2, creates constrainable graph from whichxml schema can be derived* Ballot through HL7 to vet among the Medicaid Community in aconsensus process, which, if followed, should result in an ANSI accredited standardo Requires agreement of the Community Based Health Care SIG tosupport project (not a problem)o Requires agreement from Personnel Management that the Medicaidflavor 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 TemplatesConsider Use Case DiagramConsider Business Process DiagramActors = Application RolesInputs and Outputs = MessagesEvents = Trigger Events prompting interchange
58 Dynamic ModelNEXT:Develop activity diagram for the business process steps and exceptionsDeterminePre-conditionPost-conditionAddTrigger EventsReceiver Responsibilities (Role of Receiving Application)Update requirements
59 Develop HL7 Domain Message Information Model (DMIM) Conceptual Data Model (CDM)MAP toMap Conceptual Data Model (Step 1 output) to HL7 Logical Data Model to create a constrained graphFor Enroll Provider = Provider Registry DMIMLogical 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 ModelHASDynamic 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
64 Serialize –> The Physical Model TransformSerialized Table FormatXML SchemaSerialize 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 specificationPhysical Model is where the Logical Model meets the Technical Model
66 Business/Information Track MONDAY, MAY 18WEDNESDAY, MAY 20Quarter 18:30-10Joint with TACWelcomeRemarks from Brian OsbergOverview MITA ProjectFM, FM MITA WG, SWGsReview agenda and deliverables for the weekSubworkgroup updatesData Analytics DAM ReviewQuarter 210:30-12Technical/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 vocabularyLUNCHQuarter 31:45-3Finish agenda from Quarter 1Review/harmonize SWG deliverables, interactions, and interfacesDo we understand the intended messaging?When are messages actually happening?Provider modelsQuarter 43:30-5Glossary DiscussionReview 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 TowersTUESDAY, MAY 19THURSDAY, MAY 21HDF 4.2 – DAM, clarify the artifacts in relation to MITA WGEnroll Provider Model ReviewCatch up quarterPlanningDiscuss education needs of SWGsReview project plan timelinesMITA wikiReview progress of the day; adjust Wednesday agendaInterim meetingsEvening – BOF (TBD)Farewell until Atlanta (September 2009)
67 Technical Track MONDAY, MAY 18 WEDNESDAY, MAY 20 TUESDAY, MAY 19 Quarter 18:30-10Joint with Business/Information TrackSupport technical services (authentication, authorization, audit trail.Quarter 210:30-12Service 2 (HITSP/CORE transport) andService 3 (Adaptor)LUNCHQuarter 31:45-3Gateway 5010 OverviewCertificatesQuarter 43:30-5Service 1: Inquire Member Eligibility business service and data requirementsService Oriented Architecture (SOA)Evening – Birds of a Feather (BOF) (Embassy Suites Hotel Bar)Evening – BOF and Bash – Galtier TowersTUESDAY, MAY 19THURSDAY, MAY 21Modeling overviewEnterprise Service Bus (ESB)Business model data as required in 270/271 transactionsCoordination with HL7 MITA teamRIM and mapping business model to the RIMInteroperability profilePlanningEvening – BOF (TBD)Farewell until Atlanta (September 2009)
68 Gateway 5010 ProjectPhase 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 toReduce cost of provider-plan data exchangeIncrease provider access to robust all-payer dataProvide a national solution and direction for real-time data exchangeEncourage public-private collaborationVendor agnosticPhased approachAdministrative focus, with clinical alignment, thus allowing for interoperabilityCoordination with other industry initiatives.
70 Inquire Member Eligibility Without CORETriggerXML(WSDL)InquireMemberEligibilityResultXML(WSDL)(“standard” requirements not set)MITA Technical Services Using CORE RulesWebTechnicalService(meetsCOREConnectivityRule)XMLTechnicalService(alignedWith COREDataContentX12270/271)TriggerXML(WSDL)InquireMemberEligibilityResultXML(WSDL)XMLTechnicalService(alignedWith COREDataContentX12270/271)TechnicalService(meets COREConnectivityRule)WebExamples 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.
71 Inquire Member Eligibility Addition of Information Architecture Data ElementsWebTechnicalService(meetsCOREConnectivityRule)XMLTechnicalService(alignedWith COREDataContentX12270/271)TriggerXML(WSDL)InquireMemberEligibilityResultXML(WSDL)XMLTechnicalService(alignedWith COREDataContentX12270/271)TechnicalService(meets COREConnectivityRule)WebMITAData Repository(Supports COREData 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 compliantTAC builds vendor supportTAC repository for comments and collaborationWork through governance process with friendly partnersArtifacts placed in CMS repositorySolution set delivered to repository
75 AccomplishmentsDefined 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 ServiceFirst 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 MatrixBPM – Business Process ModelingCMS - Centers for Medicare and Medicaid ServicesDAM – Domain Analysis ModelDSMO – Designated Standard Maintenance OrganizationHL7 - Health Level 7IARB – Information Architecture Review BoardMITA - Medicaid Information Technology ArchitectureNMEH - National Electronic Data Interchange HealthcareOOAD – Object Oriented Analysis and DesignPS-TG – Private Sector Technical GroupRSM; RSA – Rational Software Modeler; ArchitectSIG – Special Interest GroupSOA – Services Oriented ArchitectureS-TAG – Services Technical Advisory GroupSWG – Sub work groupSVN – SubversionTAC – Technical Architecture CommitteeTC – Technical CommitteeTARB – Technical Architecture Review BoardUML – Unified Modeling LanguageWeb, WWW – World Wide WebWG – Work GroupWiki – What I Know IsWSDL – Web Services Development Language