‘2008
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

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


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

‘2008 Architectural Lessons Learned from Analyses of AHIC Use Cases and Development 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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

‘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


Introduction

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


Executive summary

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


Background problems and hypothesized solutions

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


Background continued problems and hypothesized solutions

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


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Result lesson learned 2 health reference architecture hra

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


Result lesson learned 3 hitsp reuse and repurposing

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


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Summary of conclusions

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


Recommendations

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


Benefits

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


Proposed phase ii prototype project

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


Proposed phase ii prototype project continued

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


Questions issues and plans

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


Chronology of 2008 events

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


Acronyms and assumption

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


Supporting tables and models

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


Sample ctc bpmn behavior model level 1 2008 consults and transfers of care ctc use case

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


Sample bpmn behavior model level 2 for ctc consultations scenario

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


Sample bpmn behavior model level 2 for ctc transfers of care scenario

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


Sample ctc bpmn behavior model level 3

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


Ctc data requirements drs from bpmn model analysis

CTC Data Requirements (DRs) From BPMN Model Analysis

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Ctc information exchange requirements iers from bpmn model analysis

CTC Information Exchange Requirements (IERs)From BPMN Model Analysis

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Hitsp constructs used by ctc

HITSP Constructs Used by CTC

BOLD indicates ‘2008 new HITSP constructs

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Ctc scenario 1 consults component structure model showing ahic use case iers and drs

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


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Er ehr data requirements drs

ER-EHR Data Requirements (DRs)

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Er ehr information exchange requirements iers

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


Er ehr hitsp constructs

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


Er ehr scenario 1 on site care component model

ER-EHR Scenario 1 (On Site Care) Component Model

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Er ehr scenario 2 emerg care component model

ER-EHR Scenario 2 (Emerg. Care) Component Model

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


Er ehr scenario 3 definitive care component model

ER-EHR Scenario 3 (Definitive Care) Component Model

AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models


Mike lincoln md va peter elkin md mayo clinic allen hobbs phd kaiser permanente

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


  • Login