Mike Lincoln MD, VA Peter Elkin MD, Mayo Clinic Allen Hobbs PhD, Kaiser Permanente

1. ‘2008 ArchitecturalLessons Learned from Analyses of AHIC Use Cases andDevelopment of HITSP Interoperability Specifications Mike Lincoln MD, VA Peter Elkin MD, Mayo Clinic Allen Hobbs PhD, Kaiser Permanente Nancy Orvis and Celia Quivers, DoD MHS Steve Hufnagel PhD, DoD MHS Contractor 16 August 2008, Draft Version K For 8-10 Sept HITSP TC Meeting Presentation For 6 Oct 08 HITSP Panel Presentation For ONC/FHA Recommendation AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

2. Introduction Latest status is available at http://hitsp.wikispaces.com/FORMAL+METHODS In March ‘2008, we initiated an AHIC Use-Case analysis project, which focused on the identification of Information Exchange Requirements (IERs) and their AHIC-HITSP traceability. We used Business Process Modeling Notation (BPMN) Behavior-Models and Unified Modeling Language (UML) Component Structure-Models to represent each use-case and its IERs. This report presents architectural lessons learned from the ‘2008 analyses of AHIC use-cases as a part of the development of HITSP Interoperability Specifications: • It summarizes results, conclusions, recommendations and benefits. • It proposes a FY ‘2009 Phase II project (Slide 14) • It provides sample use case tables and models. (Slides 18-38) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

3. Executive Summary • We analyzed the AHIC ‘2008 Personalized Healthcare (PHC) and Consults and Transfers of Care (CTC) use cases using Business Process Modeling Notation (BPMN) behavior-models and Unified Modeling Language (UML) component structure-models. • We analyzed the potential benefit to stakeholders (e.g., AHIC, HITSP, CCHIT, NHIN, ONC, FHA, Federal Agencies, CIOs, EHR system venders, system purchasers and users.) • We recommend an IER-centric formal graphical-specification approach because, • it provides intuitive traceability from • AHIC use-case stakeholders’ Information-Exchange Requirements (IERs) to • HITSP business-technical actor Interoperability Specifications (IS) to • NHIN system-interface implementation profiles to • CCHIT system-component certification specifications. • it emphasizes HITSP reuse and is extensible to new situations. • We recommend a Healthcare Reference Architecture (HRA) be built to encourage reuse of the AHIC requirements, HITSP designs, NHIN profiles and CCHIT certification models. • We recommend that Healthcare CIO offices build their Business Transformation Architectures (BTAs) and investment portfolios from Integrated Requirements Design (IRD) packages constructed from the Healthcare Reference Architecture. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

4. BackgroundProblems and Hypothesized Solutions Legacy HITSP Interoperability Specifications (IS) have the following problems: • PROBLEM: HITSP IS traceable from Section 2 Requirements to Section 3 Design • HYPOTHESES: 1) focus should be on AHIC use-case Information Exchange Requirements (IERs) and their HITSP transformation to System Data Exchanges (SDEs). IERs are described as source and destination business stakeholders, stakeholders’ data requirements and stakeholders’ data exchange methods. SDEs are system-transactions described by applying HITSP IS constraints and HITSP constructs to the IERs resulting in standards-based interoperable SDEs. • 2) BPMN behavior-models and UML component structure-Models can explicitly show AHIC Stakeholders, Information Exchange Requirements (IERs) and HITSP Business Actors. Stakeholder is a person, organization or system, which performs business actions in a use-case. It is important to distinguish use case stakeholders from HITSP Business Actors; both include systems. Business Actor is an IT system component which supports one or more stakeholders and one or more Technical Actors engaged in exchanging specific Transactions. • PROBLEM:Traceability across AHIC, HITSP, NHIN, CCHIT • HYPOTHESIS: intuitive IER based traceability among AHIC requirements, HITSP designs, NHIN profiles and CCHIT certifications will come from formal models of HITSP transformation of IERs into system-component SDE specifications. NHIN groups the IERs/SDEs into implementation profiles (e.g., web services). CCHIT categorizes groups of IERs into HL7 EHR System Functional Model functions. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

5. Background (Continued)Problems and Hypothesized Solutions Legacy HITSP Interoperability Specifications (IS) have the following problems: • PROBLEM: HITSP-conformant reuse and repurposing methodology needed • HYPOTHESES: IERs should be the basis of reuse within a Health Reference Architecture • an AHIC-based Business Reference Architecture (BRA) can define functional-capabilities. • a HITSP-based Technical Reference Architecture (TRA) can define system-functions. • NHIN-based implementation profiles can further constrain the architectural specifications • Integrated Requirements and Design (IRD) packages of BRA+TRA elements can specify HITSP-conformant Business Transformation Architectures (BTA) and their investment portfolios. A BTA shows how an as-is architecture is transformed to a to-be architecture by the Integrated Requirements-Design (IRD) packages within an investment portfolio. • PROBLEM: Pragmatic approach to HITSP-conformant Implementations • HYPOTHESES: Stakeholders and their IERs should be mapped to HITSP Business Actors using a Healthcare Reference Architecture. IER’s should be constrained to clinical care setting using HITSP ISs. IER’s should be mapped to standards-based System Data Exchanges (SDE) using HITSP constructs. NHIN implementation profiles may further constrain the architecture. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

6. Result (Lesson Learned) #1: AHIC-HITSP-NHIN-CCHIT Traceability Based on IERs Modeled As BPMN Behavior-Models and UML Structure-Models • IERs as the key to traceability was confirmed. • Traceability can be maintained from AHIC use case IER requirements mapped to HITSP Interoperability Specification IER-designs mapped to NHIN-IER implementation profiles mapped to CCHIT IER-certification tests. • IER is Information Exchange Requirement. IERs are described as source and destination business stakeholders, stakeholders’ data requirements and stakeholders’ data exchange methods. • To encourage reuse, IERs should have HITSP wide numbers and consistent descriptions across AHIC use cases and HITSP Interoperability Specifications. • Stakeholders, Processes, Business & Technical Actors can be modeled with • Business Process Modeling Notation (BPMN) representing AHIC Use Cases. • UML Component models representing HITSP Business Actors and their IERs. • UML Sequence diagrams representing HITSP Technical Actors and their SDEs. • SDE is System Data Exchange. SDEs are system-transactions described by applying HITSP IS constraints and HITSP constructs to the IERs, resulting in standards-based SDE specifications. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

7. Result (Lesson Learned) #2Health Reference Architecture (HRA) A Business HRA can be used to specify functional-capabilities. • Business Reference Architecture (BRA), has three facets (columns) • Business Stakeholders (e.g., use case persons, organizations or systems) • Business Processes (e.g., procedures, activities or tasks) • Business Policies (e.g., regulations, standards) A Technical HRA can be used to specify system-functions. • Technical Reference Architecture (TRA) has three facets (columns): • System Components (e.g., HITSP Business Actors) • System Functions (e.g., HITSP Technical Actors) • System Constraints (e.g., HITSP Interoperability Specifications, Constructs and optional implementation profiles) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

8. Result (Lesson Learned) #3HITSP Reuse and Repurposing • Reuse can start with Information Exchange Requirements (IERs). • Analysts identify new use case Stakeholders and IERs. • Architects, designers and testers identify legacy or planned system components’ IERs. • CCHIT maps system-components to the HL7 EHR System Functional Model and its associated IERs. • IERs can be mapped to HITSP Interoperability Specifications (ISs) and their clinical care setting constraints. • HITSP ISs can map IERs to HITSP constructs. • HITSP constructs can map IERs to standards-based System Data Exchange (SDE). • IERs, which do NOT have HITSP IS mappings, require new or repurposed HITSP ISs and/or constructs. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

9. Result (Lesson Learned) #4HITSP-Conformant System-Specifications andCCHIT-Certification Test-Specifications HITSP-conformant system-specifications can be defined by mapping • Stakeholders and their IERs to HITSP Business Actors using a Healthcare Reference Architecture. • IER’s to HITSP Interoperability Specifications clinical care setting using HITSP ISs. • IER’s to standards-based System Data Exchanges (SDE) using HITSP constructs. CCHIT certification test specifications can be defined by • Steps 1-3 above plus • Business-Actor/ System-components mapped to HL7 EHR system Functional Model (EHR-S) functions Legacy Systems can be mapped-and-gapped with • HL7 EHR System Functional Model (EHR-S) • Business Transformation Architecture (BTA) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

10. Summary of Conclusions • AHIC can effectively represent use case stakeholders, processes and IERs as BPMN behavior-models. • HITSP can describe business actors’ functional-capabilities, Information Exchange Requirements (IERs) and Data Requirements (DRs) in its “Interoperability Specification, Section 2: Requirements”√ • HITSP can model business actors and IERs as UML component structure-models. √ • HITSP can map IERs to constructs in its “Interoperability Specification, Section 3: Design”√ • HITSP constructs can map IERs to standards-based interface-specifications. √ • Integrated Requirements and Design (IRD) packages of functional-capabilities and system-components can link Stakeholders, Actors, IERs, data, HITSP ISs and constructs, transactions and standards.. • Architectures of IRD packages can specify System Data Exchanges (SDEs). • Architectures may be further constrained by implementation patterns, such as SOA or web services. • CCHIT can map system-components to the HL7 EHR System Functional Model (EHR-S) • Each component can be mapped to HITSP conformant interface specifications (step 5 above) • IRD packages can map IERs to CCHIT certification SDEs (step 6 & 7 above) • IRD-packages can describe Business Transformation Architectures (BTAs). (steps 6 above) • Investment portfolios can be composed of IRD packages and their associated cost-estimates. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

11. Recommendations • AHIC use-cases should provide BPMN models to the event-action level. • HITSP ISs should provide UML component structure-models √ • HITSP ISs should map Business Actors’ IERs to HITSP constructs √ • CCHIT certification test packages should contain system-components of HITSP-conformant IER-SDE specifications. • FHA should define a Health Reference Architecture (HRA) from AHIC requirements, HITSP designs, NHIN implementation profiles & CCHIT certification models. • Healthcare CIO Offices should • map their business stakeholders’ requirements and legacy systems to the Health Reference Architecture (HRA) to define their current and future state architectures. • use Integrated Requirements and Design (IRD) packages to specify functional-capabilities and system-components within their business transformation architectures (BTAs) and investment portfolios. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

12. Benefits This recommended Model Driven Architecture (MDA) Integrated Requirements and Design (IRD) approach supports clear, complete, concise, correct and consistent, formal specifications of an EHR health IT reference-architecture using BPMN behavior-models and UML Component structure-models. Business Transformation Architectures (BTA) and Investment Portfolios specified by Integrated Requirements and Design (IRD) packages of BPMN behavior-models and UML structure-models are auditable to AHIC requirements, HITSP designs, NHIN implementation-patterns and CCHIT certification-test-specifications, providing increased process reliability and making implementations from HITSP Interoperability Specifications less risky. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

13. Proposed Phase II Prototype Project The Phase II project will: • Prototype Phase-I recommended BPMN behavior and UML structure models for legacy AHIC use cases, HITSP constructs and CCHIT functional-component certification-specifications. • Prototype Phase-I recommended Health Reference Architecture (HRA) from AHIC requirements, HITSP designs, NHIN profiles and CCHIT component certification models. • Prototype approaches to specifying Service Oriented Architecture (SOA) and NHIN web-services implementation-patterns within the HRA. • Prototype OMG's Object Constraint Language (OCL) augmentation to BPMN and UML models to support functional System Qualification Tests (SQT), technical System Integration Tests (SIT) and CCHIT certification tests. • Prototype MHS-VA “Wounded Warrior” architecture in BPMN, UML and OCL. • Demonstrate MHS-VA Wounded Warrior architecture traceability to AHIC requirements, HITSP designs, CCHIT component certification-specifications, based on artifacts from 1-5 (above). AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

14. Proposed Phase II Prototype Project (continued) • OMG's Object Constraint Language (OCL) can specify conditions on models, • Such as HITSP IS constraints on AHIC use-case BPMN behavior-models and UML structure-models. • OCL expressions can specify operations and actions that, when executed, alter the state of the system, • such as AHIC use-case Stakeholders’ IERs and HITSP Business Actors’ SDEs. • Modelers can use OCL to specify application-specific constraints in their models, • such as AHIC-Use Case/ HITSP-IS clinical care setting constraints. • Testers/certifiers can use OCL to specify queries on a model, which are completely programming language independent, • such as CCHIT certification test specifications. BENEFIT: AHIC-HITSP-NHIN-CCHIT conformance traceability, suitable to allow CCHIT certification from a system's specification, • such as NHIN HIE core service implementation profiles, • Federal Agencies NHIN Connect, etc. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

15. Questions, Issues and Plans Participation is welcome; contact one of the co-authors to join the team. QUESTIONS: none identified to date. ISSUES: none identified to date. PLANS: • IERs, DRs and recommended models will be updated for: • first for IS04: Emergency Responder (ER-EHR) ‘2008 use case, • IS09: Consults and Transfers of Care (CTC) and • IS08: Personalized Healthcare (PHC); • then for ‘2008 IS10, IS11, IS12 and IS77 use cases and • finally for ‘2006 and ‘2007 IS01, IS02, IS03, IS05, IS06 and IS07 use cases. • Then the Phase II project will commence. For other use case details, current status and additional information see http://hitsp.wikispaces.com/ http://hitsp.wikispaces.com/FORMAL+METHODS http://HITSP.wikispaces.com/HOW+TO+GUIDE AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

16. Chronology of ‘2008 Events • 20 Mar – presented Phase 1 “task charter” proposal to ONC/FHA • 23 Mar – ‘2008 AHIC use cases received by HITSP from ONC • 24-26 Mar HITSP Technical Committees (TCs) face-to-face meeting to overview AHIC use cases • 12-14 May HITSP TC Face-to-face to finalize RDSS Section 2: Requirements • 07 Apr – HITSP Provider Perspective Technical Committee starts BPMN analysis of CTC and PHC use cases • 12-14 May HITSP TC Face-to-face to finalize RDSS Section 2: Requirements • 11-13 Jun HITSP TC Face-to-face to finalize RDSS Section 3: Design • 27 Jun – HITSP Milestone publish ‘2008 RDSS documents for one month of public comments • 11 Jul - Start this FHA Phase I Project Report • 24 Jul - Present this Phase 1 Report to ONC/FHA Federal Health Enterprise Architects Forum (FHEAF). – Health Information Architecture (HIIA) Task Force • 25 Jul – HITSP receives public comments on ‘2008 RDSS documents • 29 Jul - Briefed FHA FHIEF-HIIA WG and they requested ER-EHR Models • 8-10 Sep - HITSP TC face-to-face meetings, Chicago • 26 Sep - HITSP Milestone Publish ‘2008 Interoperability Specification for one month of Public Comments • 27-29 Oct - HITSP Technical Committee meetings, • 5 Dec – HITSP Milestone Publish ‘2008 Interoperability Specification for HITSP Panel approval and public release AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

17. Acronyms and Assumption • √ means HITSP has already adopted conclusions 2-5 and recommendation 2. • Actor is an entity that can perform a system-to-system interactions (e.g., information exchange), which supports a use-case IER. • BPMN is Business Process Modeling Notation, which is a standard graphical representation of a use-case. • Business Actor is an IT system component which supports one or more stakeholders and one or more Technical Actors engaged in exchanging specific Transactions. It is important to distinguish use case stakeholders from HITSP Business Actors; both include systems. HITSP Interoperability Specification section 3: “Design” focuses on Business Actors and their associated HITSP constructs, which map stakeholder IERs to standards-based specifications of Technical Actor transactions (e.g. interoperable system component interfaces). • Construct is a HITSP standards specifications document. There are three construct types: “Component “ for data , “Transaction” for an SDE and “Transaction Package” for sequences of transactions/SDEs. • EHR-S is HL7 EHR System Functional Model. • IER is Information Exchange Requirement. IERs are described as source and destination business stakeholders, stakeholders’ data requirements and stakeholders’ data exchange methods and mechanisms. Within an obvious context, IER description may be shortened to its data requirements. • IRD is Integrated Requirements Design, which links Stakeholders, Actors, IERs, data, HITSP ISs and constructs, transactions and standard • SDE is System Data Exchange. SDEs are system-transactions described by applying HITSP IS constraints and HITSP standards-based constructs to the IERs, resulting in SDE interoperability-specifications. • SOA is Service Oriented Architecture (e.g., DOD Net-Centric Architecture) which is a software architecture where functionality is grouped around business processes and packaged as interoperable services. • Stakeholder is a person, organization or system, which performs business actions in a use-case. It is important to distinguish use case stakeholders from HITSP Business Actors; both include systems. HITSP Interoperability Specification section 2: “Requirements” analyzes Stakeholders actions to identify their IERs. • Technical Actor is an Actor which can perform one or more HITSP specified Transactions enabling the  creation, sending, receiving, and consuming of information exchanged.A system-component implements one or more technical actors. • Transaction is a specific system data exchange between two Technical Actors as specified by a HITSP Construct and supports an IER through the appropriate selection and profiling of base standards.  One or more Transactions support an IER between two Business Actors. HITSP constructs transform an IER into one-or-more standards-based transactions. • Web Services , defined by the W3C as "a software system designed to support interoperablemachine-to-machine interaction over a network". In common usage the term refers to clients and servers that communicate using XML messages that follow the SOAP standard, where there is often machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). ASSUMPTION:EHR-S is complete; but, it may need to be updated or augmented for financial and Enterprise Resource Planning (ERP). see http://HITSP.wikispaces.com/HOW+TO+GUIDE & http://hitsp.wikispaces.com/FORMAL+METHODS for background, details and latest updates AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

18. Supporting Tables and Models • Consults and Transfers of Care (CTC) • MODELS: BPMN Level-1 (Scenarios), BPMN Level-2 (Events), BPMN Level-3 (Actions) • TABLES: Data Requirements (DRs), Information Exchange Requirements (IERs) • TABLE: HITSP Constructs used in Interoperability Specification (IS) • MODELS: UML Component diagram each use case scenario • TABLE: IERs-DRs mapped to HITSP components for each use case scenario • DETAILS AT:http://hitsp.wikispaces.com/Consultations+and+Transfers+of+Care • Emergency Responder (ER-EHR) • TABLES: Data Requirements (DRs), Information Exchange Requirements (IERs) • TABLE: HITSP Constructs used in Interoperability Specification (IS) • MODELS: UML Component diagram each use case scenario • TABLE: IERs-DRs mapped to HITSP components for each use case scenario • DETAILS AT:http://hitsp.wikispaces.com/Emergency+Responder-EHR • Personalized Healthcare (PHC) (Work in Progress) • MODELS: BPMN Level-1 (Scenarios), BPMN Level-2 (Events), BPMN Level-3 (Actions) • TABLES: Data Requirements (DRs), Information Exchange Requirements (IERs) • TABLE: HITSP Constructs used in Interoperability Specification (IS) • MODELS: UML Component diagram each use case scenario • TABLE: IERs-DRs mapped to HITSP components for each use case scenario • DETAILS AT:http://hitsp.wikispaces.com/Personalized+Healthcare AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

19. Sample CTC BPMN Behavior-Model Level-1‘2008 Consults and Transfers of Care (CTC) Use Case DISCLAIMER: The sample CTC models and tables, presented in this draft Report are based on the 27 July CTC RDSS and will be revised based on the resultant Interoperability Specification (IS). AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

20. Sample BPMN Behavior-Model Level-2For CTC Consultations Scenario NOTE: Patient perspective NOT shown here, due to limited slide space . AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

21. Sample BPMN Behavior-Model Level-2For CTC Transfers of Care Scenario NOTE: Patient perspective NOT shown here, due to limited slide space . AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

22. Sample CTC BPMN Behavior-Model Level-3 For the full set of CTC level-3 BPMN analysis models, see http://hitsp.wikispaces.com/Consultations+and+Transfers+of+Care AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

23. CTC Data Requirements (DRs) From BPMN Model Analysis AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

24. CTC Information Exchange Requirements (IERs)From BPMN Model Analysis AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

25. HITSP Constructs Used by CTC BOLD indicates ‘2008 new HITSP constructs AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

26. CTC Scenario 1 (Consults) Component Structure-Model Showing AHIC Use Case IERs and DRs AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

27. CTC Scenario 1 (Consults) HITSP ConstructsRoutine Security and Privacy Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30,) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

28. CTC Scenario 2 (Transfers) HITSP ConstructsRoutine Security and Privacy Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30,) These table and model developments are in progress as a part of the HITSP CTC Requirements Design Standards Specification (RDSS) document transformation into the HITSP CTC Interoperability Specification (IS), considering RDSS public comments and recent IS template changes. The template changes incorporate this report’s recommended IER and DR tables and UML Component models. This Phase 1 Report will be updated along with the corresponding HITSP CTC IS updates. AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

29. CTC Scenario 2 (Transfers) HITSP ConstructsRoutine Security and Privacy Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30,) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

30. ER-EHR Data Requirements (DRs) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

31. ER-EHR Information Exchange Requirements (IERs) For the full set of UML Use Case Analysis models see, http://hitsp.wikispaces.com/Emergency+Responder-EHR+Use+Case AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

32. ER-EHR HITSP Constructs BOLD indicates ‘2008 new HITSP constructs ISSUE: CAP and DE need separate constructs ISSUE: Only TP13, T30, T31 and TP33 Support PHI AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

33. ER-EHR Scenario 1 (On Site Care) Component Model AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

34. ER-EHR Scenario 1 (Onsite Care) HITSP ConstructsRoutine Security and Privacy Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30,) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

35. ER-EHR Scenario 2 (Emerg. Care) Component Model AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

36. ER-EHR Scenario 2 (Emergency Care) HITSP ConstructsRoutine Security and Privacy Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30,) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

37. ER-EHR Scenario 3 (Definitive Care) Component Model AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

38. ER-EHR Scenario 3 (Definitive) HITSP ConstructsRoutine Security and Privacy Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30,) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models