Presentation on theme: "MITA with HL7 Information Out of Cycle HL7 WGM, 18-21 May, 2009, St. Paul, MN Health Level 7."— Presentation transcript:
MITA with HL7 Information Out of Cycle HL7 WGM, May, 2009, St. Paul, MN Health Level 7
2 Presentation HL7 MITA, HL7, CMS, DHHS, ONC, FEA -> alignment of healthcare architecture MITA Business Architecture -> Information Architecture MITA Enroll Provider (HL7 MITA WG Example) MITA Inquire Member Eligibility (Gateway 5010 Project) Business Architecture Technical Architecture Information 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.
6 HL7 Diversified HL7 started with and is traditionally thought of as messaging. For most of its life, however, HL7 has also produced more than messaging standards. Electronic Data Exchange in Healthcare Environments (i.e. messaging) (v2 and v3) Arden Syntax GELLO Visual/Context Integration (CCOW) Version 2.x XML (XML encoding of HL7 messages) Clinical Context Documentation Implementation Guide (CCD) Electronic Health Record System (EHRS) Functional Model Personal Health Record System (PHRS) Functional Model Services (i.e., Services as related to a Services Oriented Architecture
7 Cooperation with Other Standards Developing Organizations HL7 cooperates closely with other standards developers, such as: Accredited Standards Committee X12N (AXC X12N) Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT) Digital Imaging and Communications in Medicine (DICOM) eHealth Initiative (eHI) Logical Observation Identifiers Names and Codes (LOINC) National Council for Prescription Drug Programs (NCPDP) Object Management Group (OMG) Health Information Technology Standards Panel (HITSP) Continuity of Care Document (CCD) – XML standard for medical information summarization
8 HL7 Home Page WGM – Work Group Meetings/Balloting Cycles are 3 times annually (January, May, September). Over 700 members representing 30 countries and private sector. Out of Cycle Meetings – Held during ballot cycle; typically when a WGM is outside the U.S.
9 CMS Collaboration with HL7 Financial Management Technical Committee (FM TC) FM TC Mission/Charter: To enhance and promote HL7 standards by developing and extending the financial content of HL7. This includes development of the HL7 artifacts that support financial instruments such as accounts, transactions, claims, invoices, authorizations, eligibility, and contracts. January 2008, HL7 MITA Workgroup (WG) established within the HL7 FM TC. Collaboration with other HL7 TCs: PA, SOA, MnM, Vocabulary Collaboration with other federal projects: SAMHSA, DHHS, FDA, NIST, DoD, VHA, Canada Infoway State and private sector staff volunteer work on transforming the MITA business process templates into the MITA Information Architecture resulting in technical services. Development Framework needed. Healthcare (HL7) Development Framework (HDF). MITA Development Framework (MDF) – passed HL7 international balloting cycle September First artifact in the HL7 U.S. Realm.
10 Work Group; Teams HL7 MITA Work Group (HL7 MITA WG) The HL7 MITA Project Work Group is focused on creating the initial MITA Business Process Models and Information Model which will become the MITA Information Architecture. HL7 MITA Project Work Group Business Process Team Use Cases, Storyboards, additional requirements for v2.01 business process templates Data Analytics Team Information Model Data analysis and database Modelers Team Diagrams and models for business processes Vocabulary Team Medicaid specific vocabulary Education and Training Team Documentation and assistance for newcomers; lessons learned; best practices
11 Relationship with CMS, Other States, Private Sector MITA Governance is established and maintained by CMS and controls the MITA Standards that will be used by Medicaid systems. All external bodies can only make recommendations for standards to be adopted by MITA. MITA governance will actually adopt standards. MITA governance will control versioning and effective dates for specifications. MITA standard artifacts will exist in MITA repositories that will designated by CMS. The Initiative Review Board is only indirectly tied to the specification adoption process since it responsible for the approval of: MITA APD/RFP guidelines, transition plan, legislative analysis, goals & objectives, Initiative governance.
12 MITA Governance Structure MITA Governing Board Initiative Review Board Sub- Workgroup Architecture Review Board Business Architecture Review Board Information Architecture Review Board Technical Architecture Review Board Registrar
13 MITA Architecture Governance Structure MITA Architecture Review Board MITA Business Architecture Review Board MITA Information Architecture Review Board MITA Technical Architecture Review Board Business Process Business Capability S-SA process Data Models Vocabulary Mapping to Standards Data Management Strategy Service definitions Infrastructure definitions Technical processes Technical capabilities Mapping to Standards 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
16 The Big Picture NMEH HL7-MITA Project TAC BARB IARBTARB ARB MITA Users STAG New Bus Proc Other DSMOs HL7 HL7Healtth Data Community Technical Implementer Independent Information Spec. State Business SMEs
17 Federal Enterprise Architecture (FEA)
18 Healthcare Standards Environment FEA Participates in
19 Next Steps for CMS Develop MOU with HL7. Include detail specification of artifacts exchanged. Complete work on the business capabilities matrices. Develop detail submission process for each architecture. Demonstrate business architecture maturity with development of a service. Gateway 5010 Project (POC) at MMIS National TAC working with MITA HL7 WG and TARB. Inquire Member Eligibility business process. Information models. Technical specifications. Implement service.
20 HL7 MITA Work Group Process Flow (Draft)
21 HL7 Development Framework
22 Framework is Essential Healthcare Development Framework (HDF) Version 1.2 Published on: April 23rd, 2008
23 MITA Information Models The Business Process Model is derived by analyzing the Medicaid Business Requirements in terms of the Concept of Operations. The Business Process Model is neutral with respect to any organization, location, staff, outsourcing, and automation. Applying the Medicaid Maturity Model (MMM) to the Business Process Model yields the Business Capabilities. Business Capabilities show the evolution of Business Processes over time. UML Use Case models Activity models Message schemas (HMD, CMET) Information models (DMIM, RMIM) Abstract WSDL
24 HL7 V3 Message Development Methodology: How Use Case Modeling Produce a storyboard example Generalize the storyboard example into a storyboard Information Modeling Define classes, attributes, datatypes, and relationships Define vocabulary domains, code systems, and value sets Define states, trigger events, and transitions Interaction Modeling Define application roles Define interactions Message Design Define D-MIM, CMETs, and R-MIMs Define HMD and Message Types
25 MITA Information Architecture Models The Business process/ Business capability combinations are the cornerstone of the Business Architecture and the driver for the Technical Architecture. Business Capabilities map to the Conceptual Data Model. The Conceptual Model is the basis for the Logical Data Model. New functional requirements may change the Business Capabilities. Business Capabilities may update the Conceptual Data Model, and thereby evolve the Logical Data Model. The Logical Data Model can be expressed as a WSDL. The Logical Model will be implemented via a Physical Model via a information technology specification such as Java or XML. Business Model Conceptual Model Logical Model Physical Model Note: CMS will provide Medicaids with specifications for making their systems interoperable, and reusable. CMS does not mandate types of software.
26 Business Area Technical Area Technical Function Technical Capability Conceptual Data Model Logical Data Model Business Capability Business Process Medicaid Mission and Goals MITA Principles, Goals, and Objectives Physical Data Model
27 Business Capabilities Evolve in Response to New Medicaid Functional Requirements Evolved Business Capability 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
28 Business Capabilities are derived from the Model Maturity Model and Business Process Model Business Capability Business Process = Preconditions, Trigger, Data in Motion, Steps, and Results
29 MITA Maturity Model YEARS10+ YEARS NOW
30 Business Capability Matrix Provider enrollment staff spend hours verifying provider credentials or fail to do primary credentialing verification because of difficulty and liability risk Provider enrollment staff use automated, web-based, online credentialing and sharing of primary source verification with other state health programs and other Medicaid agencies The enrollment process is automated by an interface with the RHIO Provider Directory which invokes a credential verification service 5 YEARS LEVEL 1 LEVEL 3 LEVEL 5 NOW 5 YEARS10+ YEARS NOW Provider Enrollment – Credentialing Step
31 Evolving Enroll Provider Business Capability Level 1 Level 2 Level 3 Level 4 Level 5 Receive paper enrollment application; verify via phone; manual processing Real time rules driven enrollment /verification; one-stop collaboration Outcomes based enrollment; continuous verification against national databases NOW 5 YEARS 10+ Example of Maturing Business Capabilities… Use proprietary EDI for enrollment /verification; legacy MMIS hard coded rules Enrollment/verification via RHIOs; access clinical record
32 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: Providers credentials verified on-line Application triggers automated requests Standardized responses Continuous scans of sanction lists COOCOO AS IS Concept of Operations TO BE Concept of Operations Medicaid Beneficia ry Other Payer Managed Care Eligibility Source CMS Other Agencies Bank Provider Finance Management Data Sharing and Communicat ions Strategic Planning Member Management Provider and Contract Management 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?)
34 UML v2.0 UML Modeling Structure Diagrams: what things must be in the system being modeled. Behavior Diagrams: what must happen in the system being modeled. Interaction Diagrams: subset of behavior diagrams that emphasize flow of control and data among the things in the system being modeled.
35 HL7 Modeling Hierarchy
36 RIM (1) Define a D-MIM (2) Define a R-MIM (3) Create an HMD HMD RIM Reference Information Model D-MIM Domain Message Information Model R-MIM Refined Message Information Model HMD Hierarchical Message Definition HL7 V3 Message Design Models Select RIM classes to be included in D-MIMSelect RIM classes to be included in D-MIM Clone subset classes of the RIMClone subset classes of the RIM Select a subset of class relationshipsSelect a subset of class relationships Select a subset of class attributesSelect a subset of class attributes Select a subset of attribute data types and domainsSelect a subset of attribute data types and domains Create clones of D-MIM classes and attributesCreate clones of D-MIM classes and attributes Assign alias class and relationship role namesAssign alias class and relationship role names Eliminate unnecessary class hierarchiesEliminate unnecessary class hierarchies Finalize class relationships and cardinalityFinalize class relationships and cardinality Finalize attribute data types and domainsFinalize attribute data types and domains Select a root class for the messageSelect a root class for the message Arrange classes and attributes hierarchicallyArrange classes and attributes hierarchically Declare inclusion and repetition constraintsDeclare inclusion and repetition constraints Declare data type and domain value constraintsDeclare data type and domain value constraints Assign message element namesAssign message element names
37 Reference Information Model Reference Information Model Datatype Specification Datatype Specification Vocabulary Specification Vocabulary Specification Reference Models Interaction Model Interaction Model Design Information Model Design Information Model Common Message Type Model Common Message Type Model Design Models Hierarchical Message Definition Hierarchical Message Definition Message Type Definition Message Type Definition Implementation Technology Specification Implementation Technology Specification Message Specifications Message Profile Specification Message Profile Specification Localized Message Specification Localized Message Specification Message Conformance Statements Message Conformance Statements Conformance Profiles
38 Reference Information Model Reference Information Model Datatype Specification Datatype Specification Vocabulary Specification Vocabulary Specification Reference Models The HL7 Reference Information Model is the information model from which all other information models and message specifications are derived. 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. 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.
39 Interaction Model Interaction Model Design Information Model Design Information Model Common Message Type Model Common Message Type Model Design Models 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. A Common Message Type Model is a definition of a set of common message components that can be referenced in various message specifications.
40 Hierarchical Message Definition Hierarchical Message Definition Message Type Definition Message Type Definition Implementation Technology Specification Implementation Technology Specification Message Specifications An Hierarchical Message Definition is a specification of message elements including a specification of their grouping, sequence, optionality, and cardinality. A Message Type Definition is a specification of a collection of message elements and a set of rules for constructing a message instance. An Implementation Technology Specification is a specification that describes how to construct HL7 messages using a specific implementation technology.
41 Message Profile Specification Message Profile Specification Localized Message Specification Localized Message Specification Message Conformance Statement Message Conformance Statement Conformance Profiles A Localized Message Specification is a refinement of a HL7 message specification standard that is specified and balloted by an HL7 International Affiliate. A Message Profile Specification is a description of a particular or desired implementation of an HL7 Message standard or Localized Message specification. 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 Message Design Information Modeling RIM Restrict R-MIM Serialize HMD Restrict Message Type Example Storyboard Example D-MIM Derive Application Role SenderReceiver Trigger Event Triggers Content Interaction References
43 Domain Analysis Model (DAM)
44 Domain Analysis Model (DAM)
45 Design Dynamic Model
46 MITA Enroll Provider Example
47 Developing an Information Architecture Specification for Provider Enrollment Static Model Dynamic Model HL7 Domain Message Information Model Ballot through HL7 to vet among the Medicaid Community in a consensus process, which, if followed, should result in an ANSI accredited standard Requires agreement of the Community Based Health Care SIG to support project Requires agreement from other HL7 WGs Constrained MITA specific version of the balloted international standard Develop HL7 WSDL Ballot or register as a conformance profile with HL7 SOA SIG
48 Medicaid Business Process Model
49 MITA Business Process Views the business cross- functionally. Organizes the actions of the business as a set of activities in response to business events. Cuts through the existing silos enabling opportunities for real process improvement. Objective is to capture all Medicaid-related business processes in the MITA model.
50 Key Information Architecture Elements in the Business Process Shared Data: License, Prior History, NPI Trigger: Provider Application Data Result: Provider Enrollment Status Data Activities Provider Enrollment Steps
51 Example of Input Messages (Class Diagram) Enroll Provider
52 Use Triggers to Reference the Process New Enrollment Triggers
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.)
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) Map Conceptual Data Model (Step 1 output) to HL7 Logical Data Model to create a constrained graph For Enroll Provider = Provider Registry DMIM Conceptual Data Model (CDM) Logical Data Model (LDM) MAP to
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 Serialize into Message Types from which XML Schema is generated. Transform Serialized Table FormatXML Schema
65 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 18WEDNESDAY, 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 Quarter 1 8:30-10 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. Quarter 2 10:30-12 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? Quarter 3 1:45-3 Provider models Quarter 4 3:30-5 Glossary Discussion Review progress of the day: adjust Tuesday agenda. Quarter 4 3:30-5 Provider models 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 19THURSDAY, MAY 21 Quarter 1 8:30-10 HDF 4.2 – DAM, clarify the artifacts in relation to MITA WGQuarter 1 8:30-10 Provider models Quarter 2 10:30-12 Enroll Provider Model ReviewQuarter 2 10:30-12 Catch up quarter LUNCH Quarter 3 1:45-3 Enroll Provider Model ReviewQuarter 3 1:45-3 Planning Discuss education needs of SWGs Review project plan timelines MITA wiki Quarter 4 3:30-5 Data Analytics DAM Review Review progress of the day; adjust Wednesday agenda Quarter 4 3:30-5 Planning Interim meetings Evening – BOF (TBD)Farewell until Atlanta (September 2009)
67 Technical Track MONDAY, MAY 18WEDNESDAY, MAY 20 Quarter 1 8:30-10 Joint with Business/Information TrackQuarter 1 8:30-10 Support technical services (authentication, authorization, audit trail. Quarter 2 10:30-12 Joint with Business/Information TrackQuarter 2 10:30-12 Service 2 (HITSP/CORE transport) and Service 3 (Adaptor) LUNCH Quarter 3 1:45-3 Gateway 5010 OverviewQuarter 3 1:45-3 Certificates Quarter 4 3:30-5 Service 1: Inquire Member Eligibility business service and data requirements Quarter 4 3:30-5 Service Oriented Architecture (SOA) Evening – Birds of a Feather (BOF) (Embassy Suites Hotel Bar)Evening – BOF and Bash – Galtier Towers TUESDAY, MAY 19THURSDAY, MAY 21 Quarter 1 8:30-10 Modeling overviewQuarter 1 8:30-10 Enterprise Service Bus (ESB) Quarter 2 10:30-12 Business model data as required in 270/271 transactionsQuarter 2 10:30-12 Coordination with HL7 MITA team LUNCH Quarter 3 1:45-3 RIM and mapping business model to the RIMQuarter 3 1:45-3 Coordination with HL7 MITA team Quarter 4 3:30-5 Interoperability profileQuarter 4 3:30-5 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) MITA Technical Services Using CORE Rules Web Technical Service (meets CORE Connectivity Rule) Inquire Member Eligibility XML Technical Service (aligned With CORE Data Content X12 270/271) Trigger XML (WSDL) XML Technical Service (aligned With CORE Data Content X12 270/271) Result XML (WSDL) 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. (standard requirements not set)
71 Inquire Member Eligibility Addition of Information Architecture Data Elements Web Technical Service (meets CORE Connectivity Rule) Inquire Member Eligibility XML Technical Service (aligned With CORE Data Content X12 270/271) Trigger XML (WSDL) XML Technical Service (aligned With CORE Data Content X12 270/271) Result XML (WSDL) 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 – 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