4 International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference modelLevelsHL7 corresponds to the conceptual definition of an application-to-application interface placed in the seventh layer of the OSI model.7654321
6 MITA Technical Functions International Standards Organization (ISO) defined communications model, Open Systems Interconnection (OSI) reference modelLevels7MITA Business Process.MITA Technical Functions654321
7 NHIN Services Interface Standard Description Subject Discovery PIXv3 Service for locating patients based on demographic informationQuery for DocumentsXCALocate health documents associated with a specific patient that conforms to a set of criteriaRetrieve DocumentsRetrieve specific requested documents associated with a patientQuery Audit LogIHE ATNALog requests for patient health information and make this log available to patients.Authorization FrameworkSAMLArticulate the justification for requesting patient medical informationConsumer preferenceXACMLEnable consumers to specify with whom they wish to share their electronic health informationMessagingSOAP/WSDL/WS-addressing/ws-securityProvide secure messaging services for all communication between nhin ENABLED HEALTH ORGANIZATIONSAuthorize Case follow upProvide an ability to re-identify pseudonymized patient record when legally permitted for public health case investigationHealth Information Event messagingWS-Base NotificationProvides a publish/subscribe capability for ongoing feeds of data between NHIN enabled health organizationsNHIE Service registryUDDIRegistry that enables NHIN enabled health organizations to discover the existence and connection information for other NHIN enabled health organizations
9 MITA Medicaid Enterprise CDCDepartment of Homeland SecurityCMSNotifications and AlertsNotifications and AlertsMSIS Data; Dual EligibilityOtherAgencyLicenseBoardFEAFHAONCGuidelines; DirectivesInterfaceInterfaceMITABusinessProcess #1Standards of Interoperability; EHROtherPayerInterfaceRHIOInterfaceMITABusinessProcess #2MITABusinessProcess #3InterfaceInterfaceUse Standards; Develop New OnesInterfaceInterfaceStandardsOrganizationInterfaceProviderSURS or Fraud ContractorInformation ExchangeBenefit ManagerStateUnemploy- mentAgency– MITA guidelines apply; FFP available– Entity is encouraged to follow MITA guidelines– May exchange information; may influence MITA or vice versa
10 Business Process Model v2.01 OperationsManagementProgramManagementContractorManagementMemberManagementDetermine EligibilityEnroll MemberDisenroll MemberManageMember InformationInquire Member EligibilityPerform Population& Member OutreachManage Applicant& Member CommunicationManage MemberGrievance & Appeal261998Authorize ReferralInquire Payment StatusDraw and Report FFPManage F-MAPInquire ContractorInformationAward Administrative orHealth Services ContractAuthorize ServiceManage Drug RebateManage Rate SettingManage FFP for ServicesManage ContractorInformationClose out Administrativeor Health Services ContractAuthorize Treatment PlanManage Estate RecoveryManage FFP for MMISManage State FundsManage ContractorCommunicationManage Administrativeor Health Services ContractApply AttachmentPrepare COBFormulate BudgetManage 1099sPerformContractor OutreachProduce Administrativeor Health Services RFPApply Mass AdjustmentPrepare EOBDevelop AgencyGoals & ObjectivesMaintain State PlanSupport ContractorGrievance and AppealAudit Claim-EncounterManage RecoupmentDevelop & MaintainProgram PolicyDevelop & MaintainBenefit PackageEdit Claim-EncounterManage Cost SettlementMaintain Benefits-Reference InformationPerformAccounting FunctionsManage TPLRecoveryPrepare MedicarePremium PaymentDesignate ApprovedServices & Drug FormularyMonitor Performance &Business ActivityPrice Claim –Value EncounterManagePayment InformationMonitor Performance &Business ActivityManageProgram InformationPrepare RemittanceAdvice-Encounter ReportCalculateSpend-Down AmountDev. & Manage Perform.Measures & ReportingPrepare ProviderEFT-checkPrepare CapitationPremium PaymentPrepare PremiumEFT-checkPrepare MemberPremium InvoiceHere is your vision test for the day! Please do not strain to read the content of each tiny box. Instead, let me walk you through the important things to recognize.The MITA BPM has 8 Business Areas. [read each BA title aloud] These likely sound familiar to you. Although states may have their own names for these areas, the functions within each are relatively easy to recognize and common to most Programs.Each one of the 8 Business Areas has defined Business Processes. These definitions include descriptions, triggers, process steps, results, dependencies, etc…Through the course of the SS-A, we will help your team identify the corresponding Business Area and Process within your organization, then gather the appropriate stakeholders to define where you align with the MITA definitions and where you may differ. There is no requirement to align completely today. Rather this documentation helps lay the foundation for understanding where your state can leverage MITA components and where you will have to implement additional development to accommodate state-specific requirements.Prepare Health InsurancePremium PaymentPrepare Home & CommunityBased Services PaymentProgramIntegrityManagementCareManagementBusinessRelationshipManagementProviderManagement2447Identify Candidate CaseManage CaseEstablish CaseManage MedicaidPopulation HealthEstablishBusiness RelationshipTerminateBusiness RelationshipEnroll ProviderManageProvider CommunicationManage CaseManage RegistryManageBusiness RelationshipManage BusinessRelationship Comm.Disenroll ProviderManage ProviderGrievance & AppealInquireProvider InformationPerformProvider OutreachManageProvider Information
11 Technical Functions Framework 2.0 Framework 2.0 Plus TechnologyStandardsApplication ArchitectureTechnical ServicesTechnical Capability MatrixBusiness ServicesSolution SetsTechnologyStandardsApplication ArchitectureTechnical ServicesTechnical FunctionsBusiness ServicesSolution SetsAchieves consistencyBusiness process equivalent to technical functionBP -> ML -> BS -> SSTF -> ML -> TS -> SSInconsistent use of the word “capabilities” in TANot consistent with taxonomy of the business architectureBA -> BP -> ML -> BS -> SSTCM -> ML -> TS -> SS
12 Technical FunctionsExamples of technical functions are Authentication and Authorization.Interfaces to technical functions modeled as triggers and results.Technical function only exists to enable the business processes.Initially, technical functions will be defined using a template but like the business processes will ultimately be based on UML models.Technical function maturity level pairs (function + capability) will result in a technical service.The technical functions are being defined by the Private Sector Technology Group’s Technical Architecture Committee (TAC).
13 Technical Maturity Levels Are Based on Industry Standards Framework 2.0Technical ServicesTechnical FunctionMaturity Levels54321Framework 2.0 PlusMaturity LevelsZ…..BATechnical ServicesTechnical FunctionOne to many maturity levels for each technical functionsMaturity levels are specified by letter (A, B, C)Maturity levels only have meaning within the scope of that particular technical functionProvides flexibilityArtificially linked technology to MITA Business maturityDid not allow flexibility for industry standardsDid not provide flexibility in designing technical services/solution sets
14 Benefits of New Maturity Level Approach Technical maturity no longer maps technology to the five levels of business maturity. Instead each technical function is defined with its own independent maturity levels.The technical function may have one or many levels of maturity based on the industry standards for that particular technical function.This allows a technical service to be based on the industry derived capabilities/maturity levels.Solution sets for business services can make use of a heterogeneous mix of technical maturity levels based on the value that they bring to the business process.
15 Technical Services Update There have been no structural changes to the concept of Technical Services.A service can be defined for each technical function—maturity level pair.The methodology used to define the technical service is the same as for business services, i.e., HL7.The HL7 Reference Information Model will be used in the development of the technical service interfaces whenever possible.
16 Application Architecture Updates The application architecture captures technical infrastructure needs that can not be defined as a technical function/technical service. An example of this is an enterprise service bus.Each element of the application architecture will have technical maturity levels and technical solution sets.Application ArchitectureTechnicalServiceTechnicalServiceBusinessServiceEnd UserTechnicalServiceTechnicalService
17 Technical Solution Sets The role of technical solution sets remains unchanged.There may be one or many technical solution sets for each technical function—maturity level or application element-maturity level pair.A solution set has the metadata describing a specific implementation approach.
19 Relation to Business Service Solution Sets Business services solution sets contain pointers to all technical function—maturity level pairs that are used by the particular implementation of the business service.Allows maximum flexibility for the implementer to use the mix of technology while maintaining a loose inventory of technology available for use.
20 Technical Assessment Framework 2.0 Sporadically mentioned Process same as Business process self assessmentResulted in an assessment of the technical maturity in terms of the five levels of MITA Business MaturityAssessed technology for technology sakeFramework 2.0 PlusRefocuses assessment process on businessProcess is now an inventory of the technical services and applications availableTechnical assessment is performed to determine what technical assets are currently available in a State’s infrastructure that can support future business needsUsed in conjunction with Business service solution sets and the “to-be” business service assessment to determine technical needs to meet the business “to-be” configuration.
21 MITA Technical Services Goal is to support semantic interoperability of the MITA business processes and technical functionsInterface standardization begins at Maturity level 3Provides enabling functionality to business servicesExamplesGateways/adaptersCAQH ContentX12CommunicationsCAQH connectivityNHINEDIAuthorization & AuthenticationAudit loggingEncryption
22 Business Capability Maturity MITA Business Process, Business Capability Matrix, and Business ServicesDefinitionDescription of business logicPerformance measuresBusiness LogicBusiness ProcessTriggerResultLevel 1CapabilityLevel 2Level 3Level 5Level 4Business Capability MaturityOnce the MITA Business Processes have been identified the next step is to develop the MITA Business Service. As part of the development of the Business Process an entry in the business capability maturity matrix was developed for each process (For a more detail discussion of the MITA CMM see the MITA whitepaper.). For each business processes non-level 1 ( and optionally level 2) capability a single business service will be developed. This relationship is shown in the diagram.Level 2BusinessServiceLevel 3Level 4Level 5
23 Purpose of a MITA Business Service The MITA Business service is a logical implementation of a Medicaid Enterprise business process (e.g., Enroll Provider)The MITA business service supportsInteroperability and plug-and-playStates adapting and extending the service to meet their individual requirementsA MITA business service is implementation neutralMITA business serviceA service is the basic element in a Service Oriented Architecture (SOA). A goal of an SOA is to provide services that have a concrete meaning on the business level. A service is a software element that provides a complete business process or function.Service - an resource that provides a capability of performing tasks that form a coherent functionalityBusiness Service - corresponds to the logical implementation of an Business Process in a web service. The business service contains a service maturity level description and a Business Service Definition PackageThe MITA Business Service allows two things-“Plug n Play” - An individual service can be replaced with a new implementation without impacting the rest of the enterprise. (Replace a service that is currently a wrapped COBOL application with a COTS product or J2EE C++ program., without changing any of the external interfaces.)“Interoperability” – The ability to change an external user of a service without changing the service. This could delete, add or modify external services, or clients ( A new service ( could be an application or other client) is added to the enterprise that takes as input the output from an existing service)
24 Black Box Concept of a Service CustomCodeServiceCOTSServiceLegacyApplicationService look identical on the outsidesame inputsame outputsame behaviorInside (“under the hood”) they can be very different. As shown here a service can be all custom code, or a COTS product, or wrapped legacy code, or a combination of the above, or a composite of other services.ServiceCustomCodeCOTSCustomCodeServiceServiceServiceService
25 Formally defined interface Behavior characteristics Business logic Parts of a MITA ServiceService nameFormally defined interfaceBehavior characteristicsBusiness logicService Contract (Processing pattern, etc.)Business Service Definition Package (BSDP)In the MITA framework a business service must have the following associated dataService name is the name that the service is invoked byFormally defined interface – the interface is defined by using the Web service definition language (WSDL)Behavior characteristicsbusiness logic – describes what goes on under the hood of the business serviceservice contract – describes the expected behavior of the interface ( eg is the interface a real time or online interface)The BSDP is a MITA defined set of metadata describing the service
26 Services are loosely coupled MITA Service FlowServices are loosely coupledNO predefined predecessor or successor services to an individual serviceServices configured through use of a service contract and an orchestration languageChanges to the flow of services through changes to this orchestration; NOT by changes to the serviceInterfaces between the services must be compatibleThe business service’s objective is to provide an independent version of a business process that can woven together with other services to form composite business processes.Service contract is defined by the web service definition language and service patterns. Orchestration is done using Business Process Execution Language
27 Interoperability - Replacement ServiceAServiceBServiceCStartingConfigurationServiceAServiceB1ServiceCFinalConfigurationStarting configuration is three services that have been orchestrated serially to form a composite business service.The change is that the middle service is replaced with a new service.Examples of this are:replacement of a legacy service with COTSReplacing an existing service with a new services cont6aining new Medicaid regulationsAs long as the interface does not change for the service the preceding and succeeding services do not have to be changed to successfully run with the new servicee.g., replacement of legacy service with COTS
28 Interoperability – Addition ServiceAServiceBServiceCStartingConfigurationServiceAServiceBServiceCStarting configuration is three services that have been orchestrated serially to form a composite business service.The change is that a new service. Has been added to the front endExamples of this are:HIPAA translatorWeb enabledThe only change required is to orchestrate Service D into the composite service.As long as the interface does not change for the service B none of the existing services need to be changed to successfully run with the new serviceFinalConfigurationServiceDe.g., HIPAA translator
29 Interoperability – New ServiceAServiceBServiceCStartingConfigurationServiceAServiceBServiceCServiceEStarting configuration is three services that have been orchestrated serially to form a composite business service.The change is that a new service. Has been added to the back endExamples of this are:New utilization reviewThe only change required is to orchestrate Service E into the composite service.As long as the interface does not change for the service C none of the existing services need to be changed to successfully run with the new serviceFinalConfiguratione.g., new utilization review process
30 Interoperability – New Business Process ServiceAServiceBServiceCStartingConfigurationServiceAServiceB3ServiceCStarting configuration is three services that have been orchestrated serially to form a composite business service.The change is that service B is replaced with the new service B3 which generates an additional response. The new response is used by a brand new service, Service F.The only changes required areto orchestrate the new response from Service B3 and Service F into the composite service.As long as the interface does not change the existing interfaces for the service B none of the existing services need to be changed to successfully run with the new servicesFinalConfigurationServiceFe.g. , utilization review service with new potential fraud reporte.g., automated fraud detection processing
31 Business Process and Business Service Relationship DefinitionDescription of business logicPerformance measuresBusiness ProcessBusiness LogicTriggerResultWhat does the service do and what is needed to engage the serviceBusiness capabilityBusiness ServiceWSDL definedService ContractWSDL definedBusiness LogicDataThe business process and capability are used to define the services business logic and service contract.A services interface is derived from the business processes trigger and responses and is described using the Web Definition Language (WSDL)ExampleEligibility Inquiry ResponseHIPAA 271 XML schemaExampleEligibility InquiryHIPAA 270 XML schemaPerformed by legacy subsystem, new code or services, COTS or combinationShared between or with other services
32 MITA Service Definition Methods Interfaces are defined in Web Service Definition Language (WSDL)Messages are defined in XML schemasBusiness Logic – currently free form text, will become business rules in the futureBusiness Service Management (orchestration) is defined in Web Service – Business Process Execution Language (WS-BPEL)Data is defined in MITA logical data model
33 State Personalization of Services Change Message Structure - Schema changeChange data being used – Change data set name (e.g., instead of mapping to “state-A-MVA” map to “state-B-MVA)Replace capability – Replace service with state unique service preserving input and outputRe-Orchestrate business services – Add new services to flowChange business rules – Replace the set of business rules used by a service with a new set of business rulesAn example of when a schema change could be used is if the standard schema show certain entities as being optional and a state wants its implementation to have the entities as mandatory.That data set being used by either replacing the dataset itself or by changing the name of the data set to be used.Replacing a services was already discussed in the previous slides.Re-orchestration can be used to recombine existing services or to add new services
34 Service Interface Specification Development Process StandardAnalysisApplicableStandardReportMITA BusinessProcessSpecification(template & BCM)ModelBusinessProcessMITAGovernanceBoards(Adoption packages)Develop BS InterfaceSpecification adoptionrecommendation(WSDL, XML Schema and models)(Adoption packages)Coordinatewith TAC andidentify TechnicalService gapsTAC
36 Service Orchestration BusinessService InvocationBusinessService - BTechnicalService- 3TrueTechnicalService - 1TechnicalService - 2BusinessService - ABusinessService- CFalseService orchestration are the sequencing rules used to provide a business service.Currently for MITA this service orchestration is not dynamic but is configured prior to execution of the business service. Shown is the figure is a generic example of a service orchestration.Business services shown are one of the ~100 MITA Business Services (i.e. enroll member, enroll provider, calculate spend-down, etc.)MITA technical services provide technical functions such as security, privacy, logging, forms management, etcBusinessService- D
37 Service Contract Interaction Specification Service “XYZ” Service RequestInterface RequestInterface ResponseService contracts document the rules and procedures used to activate a service. These service contracts are used by the Enterprise service bus and service management engine to activate a service and to route responses from the service.
38 Sample Service #2 – Member Eligibility and Enrollment Step 1: Member Invokes“Determine Eligibility” ServiceStep 6: Provider Receives“Determine Eligibility” ResponseStep 11: Member completes enrollment formSample Service #2 – Member Eligibility and EnrollmentEnrollmentInfo RequestStep 10: Send request for more infoEnrollmentResponseAccessChannelDetermine EligibilityRequestEnrollment Info ResponseMemberService PortalEligibilityResponseStep 9: Route request for more information to Service PortalMITA EnrollmentInfo RequestSecurity& PrivacyServicesEligibility ResponseMITA DetermineLoggingServicesMITA EnrollmentResponseData FormatServicesMITA DetermineEligibility RequestMITA EnrollmentInfo ResponseStep 5: Receive/ Route/ ManageStep 2: Receive/ Route/ ManageEnterprise Service BusDetermine EligibilityServiceContractService Management EngineEnroll MemberServiceContractStep 7: Service contract – “activate” enroll member serviceThis slide shows the orchestration of a two MITA Business Services. The Determine Eligibility and Enroll Member services are executed in this example, the scenario demonstrates a potential beneficiary checking if they are eligible and then doing a self-enrollment. Even though this scenario shows a potential member initiating the process it could be also be a MEDICAID administrator.Step 1 – A potential member makes a request via the MITA access channel. This request could be done by using a web client, PDA or Kiosk. The Access Channel and Provider Service Portal will call MITA technical services to perform the following activitiesData Format Services – support device specific protocols, wrap payload data with MITA envelope, and perform high level data validation.Security & Privacy Services – authenticate user, single logon, validate user is authorized to perform this function, validate user is authorized to use data (privacy)Logging Services – captures all input/output data to a log.Note: some of the services may be invoked from the ESB and not the service portal. These details are still being worked and will be included in Framework 2Step 2 – The Enterprise Service Bus (ESB) an Service Management Engine (SME) route the MITA message to the appropriate MITA business service. The service contract is used to determine how this service is invoked. It should be noted that the service may not be on the same platform as the ESB receiving the request. In this case the ESB/SME will determine where the service is located and routing the message to the appropriate ESB.Step 3 – The Determine Eligibility Service receives the MITA determine eligibility request and executes the business logic associated with the request.Step 4 – This scenario demonstrates a successful execution of the business logic resulting in a message sent back indicating potential beneficiary is eligibility. The message generated is a MITA formatted message ( i.e. MITA envelope and payload)Step 5 – ESB/SME determines what to do after receiving response message ( was message expected, who should receive the message, should other business services be invoked). In this example the Determine Eligibility Response message is routed to the Service portal. The SME also determines that the enroll member service should also be activated based on the successful ( potential member is eligible) determine eligibility. Steps 6 and 7 are both initiatedStep 6 – The service portal/access channel log the response, validate security and privacy rules, and translate the data into the specific format required by the hardware used by the requestor. The potential member then receives the response that they are eligible.Step 7 – ESB/SME activate enroll member service with enroll member requestStep 8 – Enroll Member Service executes business logic and determines that additional information is needed to perform the enrollment A MITA message is generated requesting the additional information.Step 9 – ESB/SME routes message to service portalStep 10 – The service portal/access channel log the response, validate security and privacy rules, and translate the data into the specific format required by the hardware used by the potential member. The potential member then receives the request for additional information for enrollment. This scenario shows the member is deciding to enroll, but in reality member may decide not to self enrollment at this timeStep 11 – Member receives request for enrollment information and completes formStep 12 – The service portal/access channel log the response, validate security and privacy rules, and translate the data into the MITA format .Step 13 ESB/SME route Enrollment information response to enroll member serviceStep 14 Enroll Member service executes business logic to process enrollment information responseIt should be noted that the figure does not show that the business service also updates other shared data ( i.e. plan registries) storesStep 15 Enroll Member service generates and sends MITA message for successful enrollment.Step 16 ESB/SME routes message to service portalStep 17 The service portal/access channel log the response, validate security and privacy rules, and translate the data into the specific format required by the hardware used by the requestor. The member then receives the response that they are enrolled.Step 3: Execute Determine Eligibility Business ProcessMITA DetermineEligibilityRequestMITA DetermineEligibilityResponseMember RequestMITA EnrollMITA EnrollmentInfo RequestMITA EnrollmentInfo ResponseMITA EnrollmentResponseStep 8: Request Information for enrollmentDetermine EligibilityServiceEnroll MemberServiceStep 4: Return Response
39 Sample Service #1 – Provider Enrollment Step 1: Provider Invokes“Enroll Provider” ServiceStep 6: Provider Receives“Enroll Provider” ResponseSample Service #1 – Provider EnrollmentAccessChannelEnrollmentRequestProviderService PortalEnrollmentResponseMITA EnrollmentRequestMITA EnrollmentResponseSecurity& PrivacyServicesLoggingServicesData FormatServicesStep 2: Receive/ Route/ ManageStep 5: Receive/ Route/ ManageEnterprise Service BusProviderEnrollmentServiceContractService Management EngineThis slide shows the orchestration of a single MITA Business Service. The Enroll Provider service is executed in this example, the scenario demonstrates a provider doing a self-enrollment.Step 1 – A provider makes a request via the MITA access channel. This request could be done by using a web client, PDA or Kiosk. The Access Channel and Provider Service Portal will call MITA technical services to perform the following activitiesData Format Services – support device specific protocols, wrap payload data with MITA envelope, and perform high level data validation.Security & Privacy Services – authenticate user, single logon, validate user is authorized to perform this function, validate user is authorized to use data (privacy)Logging Services – captures all input/output data to a log.Note: some of the services may be invoked from the ESB and not the service portal. These details are still being worked and will be included in Framework 2Step 2 – The Enterprise Service Bus (ESB) an Service Management Engine (SME) route the MITA message to the appropriate MITA business service. The service contract is used to determine how this service is invoked. It should be noted that the service may not be on the same platform as the ESB receiving the request. In this case the ESB/SME will determine where the service is located and routing the message to the appropriate ESB.Step 3 – The Enroll Provider Service receives the MITA enroll provider request and executes the business logic associated with the request.Step 4 – This scenario demonstrates a successful execution of the business logic resulting in a message sent back indicating successful enrollment. The message generated is a MITA formatted message ( i.e. MITA envelope and payload)Step 5 – ESB/SME determines what to do after receiving response message ( was message expected, who should receive the message, should other business services be invoked). In this example the Enrollment Response message is routed to the Service portal.Step 6 – The service portal/access channel log the response, validate security and privacy rules, and translate the data into the specific format required by the hardware used by the requestor. The provider then receives the enrollment responseMITA EnrollmentRequestMITA EnrollmentResponseStep 3: Execute Provider Enrollment Business ProcessStep 4: Return ResponseEnrollProviderService
40 MITA Medicaid Enterprise CDCDepartment of Homeland SecurityCMSNotifications and AlertsNotifications and AlertsMSIS Data; Dual EligibilityOtherAgencyLicenseBoardFEAFHAONCGuidelines; DirectivesInterfaceInterfaceMITABusinessProcess #1Standards of Interoperability; EHROtherPayerInterfaceRHIOInterfaceMITABusinessProcess #2MITABusinessProcess #3InterfaceInterfaceUse Standards; Develop New OnesInterfaceInterfaceStandardsOrganizationInterfaceProviderSURS or Fraud ContractorInformation ExchangeBenefit ManagerStateUnemploy- mentAgency– MITA guidelines apply; FFP available– Entity is encouraged to follow MITA guidelines– May exchange information; may influence MITA or vice versaBusiness ServiceTechnical ServiceConnection
42 IME Test Suite Dash- Board Inquire Member Eligibility BS CAQH Core In Connectivity TSX12/MITA XMLadapter TSDash-BoardInquire MemberEligibility BSMITA XML/X12adapter TSCAQH Core OutConnectivity TS
43 Technical Implementer The Big PictureMITA UsersSTAGMITA Review BoardsARBTechnical ImplementerNew Bus ProcBARBTARBIARBNMEHTACRoles and responsibilitiesMITA Review BoardsAdoptions of MITA specificationsEvaluation of recommendationsHarmonization of collateral architecture impactsNotification Changes to MITA standards to MITA user communityNMEHBusiness process recommendationsBusiness process capability level recommendationsHL7-MITA WorkgroupBusiness Process Information Model recommendationsBusiness Service WSDL recommendationsHarmonization recommendation between MITA and HL7 (vocabulary, models, data types, code sets)Interface between MITA and HL7TACTechnical function recommendationsTechnical Function capability level recommendationsTechnical Function Information Model recommendationsTechnical Service WSDL recommendationsHarmonization recommendation between MITA and Technical DSMOInterface between MITA and technical industryOther DSMOsState BusinessSMEsHL7-MITAProjectIndependentInformation Spec.HL7HL7Healtth DataCommunity
45 MITA Architecture Governance Artifacts Review BoardMITABusiness ArchitectureInformation ArchitectureTechnical ArchitectureBusiness ProcessTemplatesActivity diagramsBusiness CapabilityBusiness Information Vocabulary and glossaryConformance CriteriaData Models and associated viewsWSDL and associated XSDInformation Vocabulary and glossaryMapping to StandardsService definitionsTechnical FunctionsTechnical Information Vocabulary and glossaryTec Function capabilitiesInfrastructure definitionsMITA StandardsFramework updates