Introduction to the HITSP - PowerPoint PPT Presentation

Loading...

PPT – Introduction to the HITSP PowerPoint presentation | free to download - id: 7d4051-ZDk1M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Introduction to the HITSP

Description:

EHR SD RM SAIF Alpha Project EHR System-Design Reference-Model Nancy.Orvis_at_tma.osd.mil, GovProjects; Stephen.Hufnagel.ctr_at_tma.osd.mil, SOA – PowerPoint PPT presentation

Number of Views:79
Avg rating:3.0/5.0
Slides: 62
Provided by: HITSP2
Learn more at: http://hssp.wikispaces.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Introduction to the HITSP


1
EHR SD RM SAIF Alpha Project EHR
System-Design Reference-Model
  • Constructing a Future State
  • EHR Reference Architecture
  • EHR Way Ahead Business Architecture
  • From HL7, HITSP and ARRA Artifacts
  • For presentation at HL7 Cambridge, MA Meeting, 5
    October 2010
  • Slides and White Paper Available at
  • EHR SD RM info http//hssp.wikispaces.com/Referen
    ceArchitecture
  • Also See Practical Guide for SOA in Healthcare
    Vol II Immunization Management Case Study at
    http//hssp.wikispaces.com/PracticalGuide

Nancy.Orvis_at_tma.osd.mil, GovProjects
Stephen.Hufnagel.ctr_at_tma.osd.mil,
SOA Suggestions for Improvement Requested
2
EHR SD RM Milestones
2008
2009
2010
2011
Healthcare SOA Reference Architecture (H-SOA-RA)
EHR SD RM Immunization Response Management
(IRM) Prototype
HSSP Practical Guide for SOA in Healthcare Volume
II Immunization Case Study Oct EHR SD RM
Informative White Paper TBD EHR-S CI-IM HFEA
May EHR SD RM Informative Reference Sep EHR SD
RM DSTU TBD EHR SD RM Normative Standard
DSTU is Draft Standard for Trial Use (ANSI
standards development) EHR-S CI-IM is EHR System
Computationally Independent Information
Model HFEA is Harmonization Framework and
Exchange Architecture
3
2008 initiated H-SOA-RA Healthcare SOA Reference
Architecture
  • This Reference Architecture is built on the HL7
    EHR System Functional Model (EHR-S FM), HITSP
    Interoperability specifications/Capabilities and
    OMG SOA layers. The objective of the H-SOA-RA is
    to assure semantic interoperability at the
    Service Level and consistency within and among
    systems architectural specifications, resulting
    in aligned, interoperable and agile enterprise
    architectures and their system components.
  • EHR SD RM info http//hssp.wikispaces.com/Referen
    ceArchitecture

4
HL7 EHR System Functional Model (EHR-S)gt 160
System Functions in 4 level categorization(separa
te spreadsheet available for full enumeration)
EHR-S FM functions can be grouped into Service
Components aka Capabilities (e.g., Lab Order
Capability, which does eligibility and
authorization function as well as lab order
function).
System Functions
Other O-1 Electronic Resource Planning (ERP)
Other O-2 Finances
Other O-3 Other
NOTE Other Category - The EHR-S model does NOT
include Electronic Resource Planning (ERP) /
Logistics and Financial components, which are
needed for completeness of a Health IT Enterprise.
5
Healthcare SOA FrameworkBased on HL7 EHR System
Functional Model Thomas Erls SOA Layers
HL7 System Functions ? Direct Care Supportive Information Infrastructure Other
Business Process Value Chains
Composite Services Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core Business Services Functional Areas Focal Classes Functional Areas Focal Classes Functional Areas Focal Classes Functional Areas Focal Classes
Entity Services Information Management Information Management Information Management Information Reporting and Management
Agnostic Services C r o s s T e c h n I c a l Common S e r v I c e s (e.g., Security, Privacy, Auditing, Logging) C r o s s T e c h n I c a l Common S e r v I c e s (e.g., Security, Privacy, Auditing, Logging) C r o s s T e c h n I c a l Common S e r v I c e s (e.g., Security, Privacy, Auditing, Logging) C r o s s T e c h n I c a l Common S e r v I c e s (e.g., Security, Privacy, Auditing, Logging)
Application Services Ambulatory Care Systems, In Patient Care Systems Logistics Systems Financial Systems Decision Support Systems Data Marts Repositories Business Objects
Implementation Profiles Integrated Healthcare Enterprise (IHE) Profiles Analysis Profiles Communications Profiles/Stacks Implementation Profiles
4
6
ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
CORE BUSINESS SERVICES
SUPPLY CHAIN (ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
s
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
5
7
HL7 EHR_S-Based Functional Architecture/Services
Analysis
ETC
Manage Business Rules
Infrastructure Functions
Interoperability
  • Infrastructure
  • Services
  • Security
  • Policy
  • Records Management
  • Audit
  • Terminology
  • Registry
  • Workflow
  • Business Rules
  • etc

Terminology
Unique ID, Registry, and Director
Information and Records Management
Security
Lines of Business
Record Management
Manage Patient History
  • Core Clinical
  • Services
  • Entity Identification
  • Resource Location and
  • Updating Services
  • Decision Support
  • Orders Management
  • Scheduling
  • Image Management
  • Etc.

Preferences, Directives, Consents, and
Authorizations
Summary Lists
Management of Assessment
Care Plans, Treatment Plans, Guidelines, and
Protocols
Cross-Cutting Direct Care/ Support Functions
Orders and Referral Management
Documentation of Care, Measurement, and Results
Record Patient Specific Instructions
Clinical Decision Support
Clinical Workflow Tasking
Support Clinical Communication
Support Knowledge Access
ETC
6
8
2009 initiated EHR-SD RM EHR System Design
Reference Model
  • This project matures and integrates the April
    2008 Healthcare Services Oriented Reference
    Architecture (H-SOA-RA) into an EHR System Design
    Reference Model (EHR-SD RM), using the HL7
    SOA-Aware Enterprise Architecture Framework
    (SAIF), HITSP interoperability specifications,
    EHR System Functional Model (EHR-S FM) and ARRA
    artifacts. Emphasis is placed on maintaining
    HITSP, ARRA, NHIN and CCHIT conformance by
    maintaining EHR-S FM traceability. Mapping and
    analysis of the HL7 product portfolio against the
    EHR-S FM is used to integrate the reference
    architecture with HL7 product lines and initially
    mature the resulting model as a technical white
    papers, then an informative reference model and
    finally a standard reference model.
  • EHR SD RM info http//hssp.wikispaces.com/Referen
    ceArchitecture

9
EHR-SD RM Project Description and Plan
  • PROJECT DESCRIPTION HL7 EHR System Design
    Reference Model (EHR SD RM) This project will
    mature the April 2008 Healthcare Services
    Oriented Reference Architecture (H-SOA-RA)
    version 1.0 into H-SOA-RA Version 2.0, for HL7
    Architecture Review Board (ArB) consideration,
    and then integrate it into an EHR System Design
    Reference Model (EHR-SD RM), using the HL7
    SOA-Aware Enterprise Architecture Framework
    (SAIF), HITSP Multi-Enterprise Architecture of
    Networked Services Standards (MEANS), EHR System
    Functional Model (EHR-S FM). Emphasis will be
    placed on maintaining AHIC, HITSP, NHIN and CCHIT
    conformance by maintaining Information Exchange
    Requirements (IERs) and Data Requirements (DRs)
    traceability. Mapping and analysis of the HL7
    product portfolio against the EHR-S FM will be
    used to integrate the reference architecture with
    HL7 product lines and initially mature the
    resulting model as a technical white papers, then
    an informative reference model and finally a
    standard reference model. An HSSP based prototype
    case study architectural specification will be
    built to validate the effort.
  • Phases For Project Information,
    see http//hssp.wikispaces.com/ReferenceArchitect
    ure
  • EHR SD RM Framework
  • Populate the framework with HL7 EHR-S Functional
    Model content, candidate healthcare Information
    Exchanges, HITSP capabilities/ services and data
    architecture
  • Information Model
  • Loosely-coupled top-down Framework
  • Rigorously specified bottom up structure/ content
    based on HITSP Data Architecture
  • Socialize EHR SD RM (HL7 Meeting, Jan 2010)
  • Collaborate with others within HL7 (ongoing)
  • Publish HL7 HSSP Practical Guide for SOA in
    Healthcare Part 2 Case Study (May 2010)
  • Solicit public comment collaborate with IHE
    HL7/OMG SOA Conference (May to Sept)
  • HL7 Informative ballot (Oct 2010)
  • HL7 Normative ballot (Oct 2011)

10
HITSP Harmonization Framework
IS Interoperability Specification
Addressing Business Needs
Available for Independent Implementation
Providing Infrastructure, Security, Privacy
Defining Information Content
Data Architecture
Base and Composite Standards
11
HITSP Constructs
  • A HITSP Interoperability Specification (IS)
    defines a business context, supports a business
    workflow, constrains and orchestrates underlying
    constructs.
  • A HITSP Capability (CAP) is a specification that
    assembles HITSP constructs to fulfill a business
    need for information exchanges. To use a
    Capability, an Interoperability Specification or
    an implementation conformance statement must
    assign Systems to one or more Capability System
    Roles and identify how the Capability Options are
    to be addressed. The use of a Capability shall
  • for each assigned Capability System Role, the
    responsibilities of the assigned System Role must
    be supported, including all interfaces specified
    by the underlying HITSP constructs according to
    the conditions specified for the assigned System
    Role.
  • If a Capability option is selected, the
    implementation must conform to the Capabilitys
    specifications for that option.
  • A HITSP Service Collaboration (SC) binds
    communications infrastructure, security and
    privacy constructs together.
  • A HITSP Transaction Package (TP), Transaction
    (T), Component (C) is where standards-based
    Interface Design Specifications are specified and
    conformance requirements are defined.

12
Constructing a Future State EHR Reference
Architecture
  • OBJECTIVE A system agnostic Future State EHR
    Business Architecture (BA) specified with a
    lexicon, based upon HITSPs data architecture,
    HL7s System Functional Model (EHR-S FM) and
    HL7s Reference Information Model (RIM).
  • A Health IT EHR BA can be modeled as clinical
    stakeholder requirements and their
    workflow-orchestration of
  • HL7 RIM compliant HITSP data modules manipulated
    by
  • HL7 EHR-S FM functions.
  • NIEM Information Exchange Package Documents
  • An EHR Information Model, for a project or
    enterprise, can be constructed from the HITSP
    data models managed by the EHR Functions used
    within the EHR BA, categorized using the HL7 RIM
    Entity, Role and Action foundation classes.
  • These concepts are the topic of this presentation

13
EHR System Design Reference Model (EHR SD RM)
Supporting Requirements/ Architecture
Development Cycle
PROCESS INPUTS -Required Capabilities -Environmen
ts -Constraints
EHR System Design Reference Model
Capabilities, Functions, Information
and Information Exchanges
Stakeholder Requirements Definition
Functions Dependencies
Conformance Criteria
Conformance is a recognition of formal testing,
that prove that a system provides 100 support
for a given standard.
Requirements Loop
Interface Specifications
Requirements Analysis
Test Specifications
Specifications Loop
Architectural Specifications
Verification Validation Loop
Test Loop
PROCESS OUTPUTS -System Architecture, -Test
Specifications -Configuration Management
Baselines
12
14
EHR SD RM Supporting Requirements/ Architecture
Development Cycle
  • Requirements Loop
  • Ensure all requirements are covered by at least
    one function
  • Ensure all functions are justified by a valid
    requirement (no unnecessary duplication)
  • Design Loop
  • Ensure all functions are covered by at least one
    hardware or software element
  • Ensure all elements of physical architecture are
    justified by a valid functional requirement (no
    unnecessary duplication)
  • Verification Validation (VV) Loop
  • Each requirement must be verifiable that the
    solution meets requirements and validated that it
    meets the users needs and expectations.
  • VV can be accomplished by Inspection, Analysis,
    Demonstration, Test
  • Test Loop
  • Ensure all information is covered by test
    specifications
  • Ensure all interfaces are covered by test
    specifications
  • Stakeholder Requirements
  • What is the system supposed to do?
  • Under what conditions will the products be used?
  • Where will the products of the system be used?
  • How often? How long?
  • Who will use the products of the system?
  • Requirements Analysis (HOW? using Action
    Verbs)
  • Analyze functions and Services
  • Decompose higher level functions to lower level
    functions
  • Allocate performance requirements to the
    functions
  • Architecture Design (Which hardware/ software
    elements)
  • Define the physical architecture
  • Each part must perform at least one function
  • Some parts may perform more than one function
  • Test Specifications
  • How Requirements-Specifications are validated

13
15
Value Proposition of Standards Based Approach
  • Analysis Pre-Done Analysts from throughout
    industry have vetted and contributed to the
    development of thorough specifications
  • Less Customization COTS vendors are already
    building applications to meet these
    specifications.
  • Comprehensive View Standards provide a way to
    ensure that requirements and design address all
    of the necessary issues
  • Lack of unexpected dependencies late in project
    All functions and specifications have been
    pre-analyzed and defined
  • Better Interoperability Standards based
    approaches will ensure development between all
    stakeholders are able to communicate at the
    project and technical level
  • Across Project Visibility Normalized
    requirements and design would allow for apples
    to apples comparison across the portfolio

16
Basic UML Legend
17
EHR System Design Reference Model (EHR SD RM)
Constructing a Future State EHR Reference
Architecture
Functional Analysis
Object Analysis
Requirements Analysis
Interface Design Analysis
Service Analysis
16
18
2010 SAIF Alpha ProjectThe Practical Guide For
SOA in Healthcare Volume IIImmunization
Management Case Study
  • The Practical Guide for SOA in Healthcare Volume
    II presents a case study, which adds an
    Immunization Management Capability (IMC) to
    Volume Is SampleHealths Service Oriented
    Architecture (SOA). We used the TOGAF
    Architecture Development Method (ADM) and HL7
    Service Aware Interoperability Framework (SAIF)
    Enterprise Conformance and Compliance Framework
    (ECCF). Volume II demonstrates the use of HL7s
    EHR System Design Reference Model (EHR-SD RM)
    linked artifacts (e.g., EHR System Functional
    Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc)
    to provide an initial architectural baseline
    suitable for an EHR related SOA acquisition,
    development or certification project. We conclude
    with lessons learned.
  • Healthcare Services Specification Project (HSSP)
    Practical Guide
  • http//hssp.wikispaces.com/PracticalGuide

19
Immunization Management ECCF Specification Stack
Subject Specification Enterprise Viewpoint Why Policy Information Viewpoint What Content Computational Viewpoint How Behavior Engineering Viewpoint Where Implementation
CIM (Conceptual) Inventory of Use Cases Capabilities-Services Requirements Contracts Stakeholders Business Scope Business Vision Business Objectives Policy Regulations Inventory of Domain Entities Roles, Activities, Associations. Information Models Conceptual Domain Inventories of Capabilities-Components, Functions-Services. Requirements Accountability, Roles Behaviors, Interactions Functional Profiles, Interfaces, Contracts Conceptual Functional Service Specifications Inventory of Platforms/ Environments.
PIM (Logical) Applicable Rules Use Case Specs Governance. Technology Neutral Standards Wireframes of architectural layers Components and Associations Information Models Localized Constrained Project Message Content Specifications Use Case Specs Component. specs Interface Specs Interaction Specs Collaboration Participations Collaboration Types Function Types Interface Types Collaboration Scripts Service Contracts Existing Platform models, Capabilities, Libraries and Versions.
PSM (Implementable) Business Nodes Business Rules Business Procedures Business Workflow Technology Specific Standards Database Schemas Message Schemas Transformation Schemas (e.g., XSD) Automation Unit Technical Interfaces Technical Operations Orchestration Scripts Application Specs. GUI Specifications Component Designs Deployment Topology Platform Bindings
18
20
(No Transcript)
21
Initiation
Implement Test
SAIF ECCF - Services Aware Interoperability
Architecture - Enterprise Compliance and
Conformance Framework
EHR-S FM EHR-S CI-IM EHR System Function
Model EHR System Computationally-Independent
Information-Model
VV Checkpoint
Analysis
Peer Review Ballot
VV Checkpoint
VV Checkpoint
HL7 Development Framework (HDF)
DSTU - Draft Standard for Trial Use Prototype
Draft Working Document Not for Public
Distribution
  • Specifications for
  • Business Objects
  • Components
  • Capabilities
  • Applications
  • Systems

DAM Domain Analysis Models CDA Clinical
Document Architecture CMET Common Model Element
Types D-MIM Domain Message Information Model
Design
  • Interoperability Specifications for
  • Messages and/or
  • Documents and/or
  • Services

VV Checkpoint
20
VV is Verification and Validation
22
ECCF
SAIF ECCF Viewpoints
CIM
PSM
CIM is Computationally Independent Model PIM is
Platform Independent Model PSM is Platform
Specific Model
Draft Working Document Not for Public
Distribution
PIM
21
23
SAIF Alpha-Project Conclusions
  • Effective SOA programs involve cooperation and
    coordination among a wide variety of business,
    technical and functional participants from across
    an organization, including senior management
    sponsorship, business community ownership,
    program management, governance, architecture,
    project level execution, test and certification
    and sustainment teams. The HL7 EHR-SD-RM helps
    bring these communities together throughout a
    Business Capability Lifecycle. It maps
    capabilities and business Information Exchange
    Requirements (IERs) to the
  • HL7 EHR System Functional Model (EHR-S FM), to
  • Healthcare Information Technology Standards Panel
    (HITSP)
  • Data Architecture,
  • Security and Privacy Architecture,
  • Harmonization Framework,
  • Interoperability Specifications, Constructs and
    their referenced standards
  • Federal Health Information Model (FHIM)
  • National Information Exchange Model (NIEM)
  • Information Exchange Package Documents (IEPDs)
  • Integrating the Healthcare Enterprise (IHE)
    profiles
  • Certification Commission for Health Information
    Technology (CCHIT) criteria and
  • 2009 Health Information Technology for Economic
    and Clinical Health (HITECH) Act selected
    standards for interoperability and meaningful use
    objectives and criteria.

24
EHR-S CI-IM EHR System Computationally-Independen
t Information-Model (Started Jun2010)
  • This project will produce a set of Constrained
    Information Models called EHR-S data profiles.
    Each EHR-S data profile corresponds directly with
    an EHR-S function profile and each EHR-S data
    profile will include one-or-more Reference
    Information Model classes. Pairs of EHR-S
    function profiles and data profiles can be used
    to define business objects, which can be composed
    into software components, capabilities,
    applications, systems and their message exchanges
    and/or document exchanges and/or services. The
    superset of EHR-S data profiles is called the
    EHR-S Computationally-Independent
    Information-Model, which supports the HL7
    Development Process and Service Aware
    Interoperability Framework. The project will
    include the development and execution of a
    communication strategy to ensure that all
    affected stakeholders are engaged.

25
HL7 RIM (Reference Information Model)Six Core
Classes Defining a Semantic Framework
whichMaintains Clinical Data Context
ACT (aka ACTION)
ROLE
ENTITY
Participation
Role link
Act relationship
The HL7 RIM expresses the data content needed in
a specific clinical or administrative context and
provides an explicit representation of the
semantic and lexical connections that exist
between the information carried in the fields of
HL7 messages.
ACT something that has happened or may
happen Entity a person, animal, organization,
or thing Role a responsibility of, or part
played by, an Entity Participation the
involvement of a Role in an Act Act Relationship
a relationship between two Acts Role Link a
relationship between two Roles.
Language / communication
The HL7 RIM supports EHR interoperability an EHR
may needs additional foundation classes (e.g.,
Responsibility)
26
Federal Health Information Model (FHIM) Person
Model (Harmonized with RIM, HIPAA HITSP)
27
HL7 EHR System Computationally-Independent
Information-Model (EHR-S CI-IM) Project
Draft Working Document Not for Public
Distribution
EHR-S CI-IM
RIM Classes
Entity a.b.c EHR-S Data Modules
EHR-S FM

Entity d.e.f
11 Relationship between Function Profiles and
Data Profiles For each EHR-S Function, its
Data Profile Set of RIM Classes and their
EHR-S Data Modules
1N Relationship among Data Profiles and RIM
Classes

Role a.b.c EHR-S Data Modules
DC x.y.z EHR-S Function Profile
Role d.e.f



Act a.b.c EHR-S Data Modules
Act d.e.f
SC x.y.z EHR-S Function Profile



Act Relationship a.b.c EHR-S Data Modules
Act Relationship d.e.f


IN x.y.z EHR-S Function Profile
Role Link d.e.f
Role Link a.b.c EHR-S Data Modules



Participation d.e.f
DC is Direct Care SC is Supportive Care IN is
Infrastructure
Participation a.b.c EHR-S Data Modules


28
Harmonization Framework and Exchange Architecture
(HFEA) Started Jun 2010
  • The first objective of this HL7 Harmonization
    Framework and Exchange Architecture (HFEA)
    project is to define a notional set of
    architectural artifacts for HL7 projects and EHR
    System (EHR-S) development or acquisition
    projects. The second objective is to define the
    relationships among HL7 architectural artifacts
    and how they relate to other healthcare related
    standards and architectural artifacts, which can
    support a Model Driven Architecture (MDA)
    waterfall, spiral, agile or other development
    methodology. The third objective is to be an
    implementation guide for the use of the HL7
    Development Framework (HDF) process and HL7
    Service Aware Interoperability Framework
    Enterprise Compliance and Conformance Framework
    (SAIF ECCF) structure by which architectural work
    products are reused or developed, are organized
    into an Interoperability Specification and used
    throughout an architecture development project,
    the governance that should be enacted on these
    work products, and the scope of the
    standardization effort itself. The fourth
    objective is to define a Healthcare Information
    Exchange Model (H-IEM) for model-driven
    Healthcare Information Exchange Package
    Documentation (H-IEPD) and exchange architecture.
    The fifth objective is to demonstrate how the HDF
    and ECCF can complement other frameworks such as
    TOGAF, Agile Scrum, DODAF and Zachman.

29
Example of SAIF Traceability Using HL7 EHR-S FM
Information Viewpoints Conceptual Independent
Model Platform Independent Model Platform
Specific Model
Business Viewpoints Conceptual Independent
Model Platform Independent Model Platform
Specific Model
NCIDs
NCIDs
Behavioral Viewpoints Conceptual Independent
Model Platform Independent Model Platform
Specific Model
Engineering/Technical Viewpoints Conceptu
al Independent Model Platform Independent
Model Platform Specific Model
NCIDs
NCIDs
HL7 SDO EHR-S FM
Key to Traceability Traceability is achieved by
using Numeric Concept Identifiers (NCIDs) from
the HL7 EHR System Functional Model (EHR-S FM)
as attributes to all SAIF artifacts. This is
analogous to a library system, which uses Dewey
decimal numbers as book identifiers.
30
Notional EHR SD RM Logical View
29
31
EHR SD RM Status (Oct 2010)
  • Supporting EHR System Functional Model R2
  • EHR SD RM foundation (linked XML version) Spring
    2011 ballot
  • HITSP (2010 completion)
  • ARRA Meaningful Use Objectives/ Criteria (Jun
    2010 Final Rule)
  • Sub Projects
  • EHR Computationally Independent Information Model
  • Harmonization Framework and Exchange Architecture
  • SAIF Implementation Guide

32
EHR SD RM Issue
  • 2011 Representation?
  • Linked XML (most flexible for documentation,
    current preference)
  • EHRS FM (R2) and its profiles (2011)
  • HL7 Domain Analysis Models (DAMS) and Detailed
    Clinical Models (DCMs)
  • HITSP (2010) Interoperability Specifications and
    constructs
  • ARRA MU Meaningful Use Objectives Criteria
    (2010)
  • EHR CI-IM, FHIM and NIEM (TBD)
  • Local Profile
  • Investment Portfolio (Capabilities vs. funding
    line items and year)
  • Systems (Configuration Managed Capabilities)
  • Responsible Organizations (Program/Project
    Management Offices)
  • Innovation Projects
  • Modeling Tool (graphically based best for
    presentations)
  • Enterprise Architect
  • Eclipse IBM/ Rational
  • Eclipse Papyrus
  • Other Representation (HL7 MIF)
  • SAIF ECCF integration/ Pre-population Use
  • Project Specific Web-based Ad-Hoc Report
    Generator

33
The National Way Forward (Oct 2010)ONC Standards
and Interoperability Framework
Tools and Services(Use Case Development,
Harmonization Tools, Vocabulary Browser, Value
Set Repository, Testing Scripts, etc) (Stanley)
34
Contact Information
  • Nancy Orvis
  • Chief Integration Architect
  • Office of the Chief Information Officer
  • DoD Military Health System
  • Email nancy.orvis_at_tma.osd.mil

Steve Hufnagel Enterprise Architect, TIAG
contract support Office of the Chief Information
Officer DoD Military Health System Email
steven.hufnagel.ctr_at_tma.osd.mil
HOW TO PARTICIPATE Coordinate with
SHufnagel_at_tiag.net, 703-575-7912-cell. We have
a weekly telecom each Friday 1230-1330
Eastern PHONE 1 770-657-9270, CODE
071582WEB LINK http//my.dimdim.com/hssp PROJ
ECT WIKI http//hssp.wikispaces.com/ReferenceAr
chitecture
Backup Slides Follow
33
35
INTEGRATED REQUIREMENTS DESIGNS Putting the
H-SOA-RA Pieces Together
Ancillary Systems
PT/OT/SPEECH
LABORATORY
SPECIALTY CARE
RESPIRATORY
PHARMACY
CARDIOLOGY
RADIOLOGY
DIETARY
IDENTITY
TERMINOLOGY
Inter-Service
TEST ONLY
AUTHORIZATION
INPATIENT
SCHEDULING
Federated Business Services
SUPPLY CHAIN (ORDERS/CHARGES)
Core Business Services
ER
DOCUMENT
RECORDS MANAGEMENT
ASU
Federated Services, may be categorized by --
Encounter Types -- CMS billing category --
Record type -- Care setting type -- etc.
DECISION SUPPORT
PERFORMANCE
CLINIC
OUTPATIENT OTHER
DATA MANAGEMENT
ANALYTIC
Agnostic Services
SUPPORT
Data sets are defined for each system
functional-capability-service module
IT PLATFORM
34
36
EHR SD RM Supporting Requirements, Governance
Architectural Processes
35
37
The HL7 Services-Aware Interoperability
Framework (SAIF)
  • SAIF Contains
  • Enterprise Conformance and Compliance Framework
    (ECCF) is based on RM-ODP
  • Behavioral Framework (BF)
  • Interoperability Scenarios supporting the RM-ODP
    Computational Viewpoint
  • Governance Framework (GF)
  • Governance is the overarching policy structure
    and set of related processes by which a group
    exercises its authority and demonstrates
    accountability for accepted responsibilities
    within a particular jurisdiction.
  • SAIF Principles
  • Applicable within each of HL7s three
    Interoperability Paradigms (IPs),
  • (i.e., messages, documents, and services).
  • Provide support for measurable conformance and
    compliance.
  • Define appropriate governance structures and
    processes.
  • Provide support for directly implementable
    solutions.
  • Address the growing disparity between the various
    solution sets emerging from HL7.
  • Utilize existing V3/RIM artifacts and expertise
    to the maximum degree possible.

38
Abbreviations
  • B-Case is Business Case
  • BPM is Business Process Model
  • CCD is Continuity of Care Document
  • CCHIT is Certification Commission for Health
    Information Technology
  • CDRL is Contract Deliverable
  • DBT is Defense Business Transformation
  • IHE is Integrating the Healthcare Enterprise
  • NHIN is National Health Information Exchange
  • PCC is Patient Care Coordination
  • RM-ODP is Reference Model of Open Distributed
    Processing
  • SOA is Service Oriented Architecture

39
Federal Enterprise Architecture
(FEA)www.whitehouse.gov/omb/egov
  • Performance Reference Model - The FEA PRM is a
    framework to measure the performance of major IT
    initiatives and their contribution to program
    performance. The PRM leverages performance
    measurement best practices from the public and
    private sectors, including the Balanced
    Scorecard, Baldrige Criteria, Value Measurement
    Methodology, program logic models, the value
    chain, and the theory of constraints. There is an
    increased emphasis placed on linkage of
    investment to agency program performance and the
    PRM will help agencies produce enhanced
    performance information. Furthermore, the PRM
    will assist in improving the alignment of
    program goals and objectives with Mission Area
    goals and objectives improving communication of
    program contributions such as technology (input)
    to outputs and outcomes and in identifying
    improvement opportunities that span traditional
    organizational boundaries.
  • Business Reference Model - The Business Reference
    Model (BRM) is a functional-driven framework for
    describing and organizing the day-to-day business
    operations of the Federal Government into Lines
    of Business (LOBs), independent of the agencies
    that perform the business operation. The BRM is
    the first layer of the Federal Enterprise
    Architecture and it is the organizing construct
    for the analysis of the other four reference
    models performance, service components, data,
    and technology.
  • Service Component Reference Model - The Service
    Component Reference Model (SRM) is a functional
    framework to evaluate to identify government-wide
    opportunities to leverage IT investments and
    assets from a service perspective. This model
    helps understand the services delivered by the
    government and assess if there is an opportunity
    to group like services and create leverage
    opportunities, such as reuse or shared services.
  • Data Reference Model - The Data Reference Model
    (DRM) describes at an aggregate level, the data
    and information required to support the Lines of
    Business (LOBs). The three elements of data
    exchange that have been standardized include data
    description, data context, and data sharing.
    Establishing a common data model streamlines the
    information exchange process within and across
    the Federal Government and facilitates the
    ability to identify duplicative data resources.
  • Technical Reference Model - The Technical
    Reference Model (TRM) establishes a common
    technical framework for categorizing standards,
    specifications, and technologies that support and
    enable the delivery of services. This framework
    can be leveraged to support the development,
    delivery, and exchange of business and
    application components (Service Components) that
    may be leveraged in a Component-based or Service
    Oriented Architecture (SOA). Furthermore, it also
    serves as the foundation to advance the re-use of
    technology and best practices from each of the
    Service Components on a government-wide basis.

40
HITSP Clinical Document Components
HITSP Reuse Paradigm With HITSP/Capability 119
- Communication of Structured Documents, a HL7
Clinical Data Architecture (CDA) document can be
composed, from any group of C83 data modules, and
then it can be communicated. Benefit agile
system interoperability.
41
HITSP/C83 Data Module Categories
Module Category Description
Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person
Support Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts
Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient
Insurance Providers and Payers Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly
Allergies and Drug Sensitivities This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient
Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses
Medications This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities
Immunizations This includes data describing the patient's immunization history
Vital Signs This includes data about the patients vital signs
Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient
Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and email
Procedures This includes data describing procedures performed on a patient
Family History Data defining the patients genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patients health
Social History Data defining the patients occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patients health
Medical Equipment Medical Equipment includes implanted and external medical devices and equipment that a patients health status depends on, as well as any pertinent equipment or device history
Functional Status Data defining the patients functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self
Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient
42
Federal Health Information Model (FHIM) Process
Define Modeling Process
Define Strategy
Define Style Guide/ Tools
Gather Participants
Establish Workgroups
Present UML Models, XML schema
Draft Models / Document Concepts codes
Vet Model Data Dictionary
Harmonize Feedback
Domain Workgroup Plan
Person Workgroup
Enrollment Eligibility Coordination of
Benefits Workgroup
Security Privacy Workgroup
Pharmacy Workgroup
Lab Workgroup
tbd
Behavioral Health
43
PART III Prototype EXAMPLE
  • Vaccination and Adverse Event Reporting Prototype
  • AHIC Use Cases
  • EHR-S FM
  • HITSP Capabilities
  • Information Model

44
SAIF Alpha-Project Description
  • The Practical Guide for SOA in Healthcare Volume
    II presents a case study, which adds an
  • Immunization Management Capability (IMC) to
    Volume Is
  • SampleHealths Service Oriented Architecture
    (SOA). We used the
  • TOGAF Architecture Development Method (ADM) and
  • HL7 Service Aware Interoperability Framework
    (SAIF)
  • Enterprise Conformance and Compliance Framework
    (ECCF).
  • Volume II demonstrates HL7s EHR System Design
    Reference Model (EHR-SD RM)
  • Linking EHR System Functional Model, FHIM, HITSP,
    HITECH, HSSP, IHE, NIEM
  • To provide an Exchange Architecture baseline
    suitable for an EHR related
  • SOA acquisition, development or certification
    project.

45
EHR-SD RM Prototype 2008 AHIC Use Cases
Immunization and Response Management (IRM)
  • The IRM AHIC Use Case and HITSP Interoperability
    Specification are intended to support current
    interoperability approaches between EHRs and
    Immunization Information Systems while allowing
    for a migration toward emerging interoperability
    implementations and document sharing environments
    where PHRs are able to be included in the
    information flow
  • The Interoperability Specification also allows
    for basic electronic information exchanges to
    enable requirement communications and alerting
    mechanisms and to lay the foundation for future
    clinical support capabilities
  • Scenario 1 Vaccine and Drug Administration and
    Reporting and
  • Scenario 2 Vaccine and Drug Inventory Reporting

46
EXAMPLE ARTIFACT Vaccine and Drug Administration
and Reporting Information Exchanges
45
47
EXAMPLE ARTIFACT Vaccine and Drug Administration
and Reporting Use CaseFull use case available
at http//healthit.hhs.gov/portal/server.pt?open
512objID1255parentnameCommunityPageparentid1
mode2in_hi_userid10741cachedtrue
46
48
EHR-SD RM PrototypeInformation Exchange
Requirements (IERs)Vaccine and Drug
Administration and Reporting Use Case
  • IER10 Identify patient
  • IER13 Send/receive notification of document
    availability
  • IER18 Send/receive clinical document
  • IER26 Identify communication recipients
  • IER27 Send non-patient notification message or
    alert
  • IER40 Query for existing data
  • IER42 Request/receive medical concept knowledge
  • IER54 Query/response for clinical message data
  • IER67 Send/receive clinical message
  • IER78 Send/receive Vaccine Inventory Requirements
  • IER79 Query/response for inventory usage data
  • IER80 Send/receive Vaccine Inventory Data

For details, see HITSP IS 10 Immunization and
Response Management, available at www.HITSP.org
47
49
EHR-SD RM PrototypeData Requirements
(DRs)Vaccine and Drug Administration and
Reporting Use Case
  • DR08 Unstructured Data
  • DR11 Immunization response data
  • DR12 Adverse Event Report
  • DR13 Drug/Vaccine Inventory Data
  • DR14 Drug/Vaccine Inventory Usage Data
  • DR15 Drug/Vaccine Inventory Availability Data
  • DR16 Supply Chain Management Vaccine Recall
  • DR17 Decision Support Data
  • DR18 Vaccination Data
  • DR19 Medication Administration data
  • DR20 Aggregate Inventory of Available Vaccine
  • DR21 Terminology Data
  • DR22 Generic Alert Data
  • DR23 Consumer Vaccination View

For details, see HITSP IS 10 Immunization and
Response Management, available at www.HITSP.org
48
50
EHR-SD RM PrototypeHITSP Security and
PrivacyVaccine and Drug Administration and
Reporting Use Case
  • IER01 Provide authorization and consent
  • IER02 Send data over secured communication
    channel
  • IER03 Create audit log entry
  • IER04 Synchronize system time
  • IER05 Verify entity identity
  • IER06 Provide proof of document integrity and
    origin
  • IER55 Anonymize patient identifiable data
  • IER56 Pseudonymize patient identifying
    information

For details, see HITSP IS 10 Immunization and
Response Management, available at www.HITSP.org
49
51
EXAMPLE ARTIFACT HL7 Requirements and
Certification Criteria and HITSP Design
HL7 EHR System Functional Model
HITSP Interoperability Specifications
50
52
EXAMPLE ARTIFACT EHR-S Requirements
51
53
EXAMPLE ARTIFACT EHR-S FM Dependencies
52
54
EXAMPLE ARTIFACTHITSP Interoperability Design
Specifications
53
55
IS10 IRM HITSP Constructs Mapped to Standards
54
56
HITSP and Immunization Use Case
Capability Patient Identification Patient Identification Data Retrieval and Update Data Retrieval and Update Data Retrieval and Update Data Retrieval and Update Decision Support Decision Support
1 Standards Org HL7 HL7 HL7 HL7 HL7 HL7 HL7 HL7
2 Service Specification Identification Service Functional Model Identification Service Functional Model Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Decision Support SFM Decision Support SFM
3 Standards Org OMG OMG OMG OMG OMG OMG OMG OMG
4 Service Specification Identification Service Specification Identification Service Specification Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Decision Support Service Spec Decision Support Service Spec
5 Profile Org IHE IHE IHE IHE IHE IHE IHE IHE
6 SOA Profile SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper
7 Profile Org IHE IHE IHE IHE IHE IHE IHE IHE
8 Immunization Profile PIX/PDQ SC110 PIX/PDQ SC110   Query for Existing Data (QED) CAP123 SC113   Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload)  
9 Profile Org American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC
10 Immunization Profile Draft 2.5 Impl Guide   Draft 2.5 Impl Guide          
11 Immunization Profile 2.3.1 Impl Guide CAP131 CAP132 SC115   2.3.1 Impl Guide CAP131 CAP132 SCII5          
12 Standards Org HL7 HL7 HL7 HL7 HL7 HL7 HL7 HL7
13 Original Standard V2 V3 Patient Admin messaging V2 V3 Care Record messaging V3 (POIZ) Immunization messaging V3 Care Record CDA V3 Care Record messaging V3 POIZ messaging
57
Immunization Use Case - Simplified
Capability Patient Identification Patient Identification Data Retrieval and Update Data Retrieval and Update Data Retrieval and Update Decision Support
1 Standards Org HL7 HL7 HL7 HL7 HL7 HL7
2 Service Specification Identification Service Functional Model Identification Service Functional Model Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Decision Support SFM
3 Standards Org OMG OMG OMG OMG OMG OMG
4 Service Specification Identification Service Specification Identification Service Specification Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Decision Support Service Spec
5 Profile Org IHE IHE IHE IHE IHE IHE
6 SOA Profile SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper
7 Profile Org IHE/American Immunization Registry Association/CDC IHE/American Immunization Registry Association/CDC IHE/American Immunization Registry Association/CDC IHE/American Immunization Registry Association/CDC IHE/American Immunization Registry Association/CDC IHE/American Immunization Registry Association/CDC
8 Immunization Profile PIX/PDQ SC110 PIX/PDQ SC110 Future Draft 2.5 Impl Guide Query for Existing Data (QED) CAP123 SC113 Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload)
12 Standards Org HL7 HL7 HL7 HL7 HL7 HL7
13 Original Standard V2 V3 Patient Admin messaging V2 V3 Care Record messaging V3 Care Record CDA V3 Care Record messaging
58
Immunization Use Case WithinHL7 SAEAF ECCF
Specification Stack
Patient Identification Patient Identification Data Retrieval and Update Data Retrieval and Update Data Retrieval and Update Decision Support
1 Enterprise View (Service Functional Models) Enterprise View (Service Functional Models) Enterprise View (Service Functional Models) Enterprise View (Service Functional Models) Enterprise View (Service Functional Models) Enterprise View (Service Functional Models)
2 Identification Service Functional Model Identification Service Functional Model Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Decision Support SFM
3 Computational View (Service Definitions) Computational View (Service Definitions) Computational View (Service Definitions) Computational View (Service Definitions) Computational View (Service Definitions) Computational View (Service Definitions)
4 Identification Service Specification Identification Service Specification Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Decision Support Service Spec
5 Information View (Payloads) Information View (Payloads) Information View (Payloads) Information View (Payloads) Information View (Payloads) Information View (Payloads)
6 PIX/PDQ SC110 PIX/PDQ SC110 Future Draft 2.5 Impl Guide Query for Existing Data (QED) CAP123 SC113 Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload)
7 Implementation View (Vendor Implementations) Implementation View (Vendor Implementations) Implementation View (Vendor Implementations) Implementation View (Vendor Implementations) Implementation View (Vendor Implementations) Implementation View (Vendor Implementations)
8 Base Standard Base Standard Base Standard Base Standard Base Standard Base Standard
9 V2 V3 Patient Admin msg V2 V3 Care Record msg V3 Care Record CDA V3 Care Record mesg
59
Service DefinitionRef A Service-Oriented
Architecture (SOA) View of IHE Profiles IHE 2009
60
Meaningful Use Rules and Regs
Capability Patient Identification Patient Identification Data Retrieval and Update Data Retrieval and Update Data Retrieval and Update Data Retrieval and Update Decision Support Decision Support
1 Standards Org HL7 HL7 HL7 HL7 HL7 HL7 HL7 HL7
2 Service Specification Identification Service Functional Model Identification Service Functional Model Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Retrieve, Locate, Update SFM Decision Support SFM Decision Support SFM
3 Standards Org OMG OMG OMG OMG OMG OMG OMG OMG
4 Service Specification Identification Service Specification Identification Service Specification Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Retrieve, Locate, Update Spec Decision Support Service Spec Decision Support Service Spec
5 Profile Org IHE IHE IHE IHE IHE IHE IHE IHE
6 SOA Profile SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper SOA White Paper
7 Profile Org IHE IHE IHE IHE IHE IHE IHE IHE
8 Immunization Profile PIX/PDQ SC110 PIX/PDQ SC110   Query for Existing Data (QED) CAP123 SC113   Immunization Content (IC) CAP119 CAP133 SC112 Request for Clinical Guidance CAP133 (IC payload)  
9 Profile Org American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC American Immunization Registry Association/CDC
10 Immunization Profile Draft 2.5 Impl Guide   Draft 2.5 Impl Guide          
11 Immunization Profile 2.3.1 Impl Guide CAP131 CAP132 SC115   2.3.1 Impl Guide CAP131 CAP132 SCII5          
12 Standards Org HL7 HL7 HL7 HL7 HL7 HL7 HL7 HL7
13 Original Standard V2 V3 Patient Admin msg V2 V3 Care Record msg V3 (POIZ) Immunization msg V3 Care Record CDA V3 Care Record messaging V3 POIZ messaging
61
Immunization Management Case StudyQuestions?
Nancy.Orvis_at_tma.osd.mil Stephen.Hufnagel.ctr_at_tma.o
sd.mil Akirnak_at_swpartners.com JohnRitter1_at_verizon
.net
HOW TO PARTICIPATE Coordinate with
SHufnagel_at_tiag.net, 703-681-3929 or
703-575-7912-cell. We have a weekly telecom
each Friday 1230-1330 Eastern PHONE 1
770-657-9270, CODE 071582WEB LINK
http//my.dimdim.com/hssp PROJECT WIKI
http//hssp.wikispaces.com/ReferenceArchitecture
About PowerShow.com