Transcript Infoway Boiler Plate

CALL FOR PARTICIPATION
Please post your discussion comments at
http://www.osehra.org/group/architecture
This DRAFT document is a
Request for Information
(RFI)
EHR Modernization
EHR Services Platform (ESP)
Conceptual Architecture
- Software Development Kit (SDK)
Open Source EHR Custodial Agent (OSEHRA) Architecture Committee
Stephen Hufnagel PhD, Chair
In collaboration with
Health Architecture Interagency Group (HAIG)
Nancy Orvis, MHA, CPHMS and Paul Tibbits, M.D., DoD and VA Co-Chairs
Current 180+ slide set Conceptual Architecture SDK and companion Implementation Guide (IG) is available at:
http://www.osehra.org/node/47/content/documents
October 18, 2011 DRAFT-N
ESP SDK
WORKING DRAFT RFI: not for official use.
1
Preface
In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates agreed on a common Electronic Health Record
(EHR) technical architecture, data and services and exchange standards for the joint integrated EHR system, where the joint
EHR will include both proprietary and open source software. The secretaries of the Veterans Affairs and Defense Departments
met on May 2 and June 30, 2011 to determine their next steps toward developing a common EHR..
“VA is developing an open source track to modernize VistA and will incorporate the approach in the joint EHR", Shinseki said.
“One of my objectives is to have minimal disruption in the hospitals as we evolve from VistA to the joint EHR system What I think
you will see us do is replace modules, do incremental upgrades.” … “In five or 10 years, there may not be one line of code left
from VistA. And in my ideal world, the users will have no idea that I have made any changes,” VA Secretary Eric Shinseki said.
“Our goals are to bring in as many private sector modules as possible and selecting the same thing to run between VA and DOD
so that we end up with a single, common electronic health record system,” Roger Baker, VA CIO said. OSEHRA sees private
modules including both open source or commercial; OSEHRA intends to foster innovation at the module level and encourages
Darwinian selection among competing modules based on cost, performance and support preferences.
"We planned, as part of this EHR framework, to release all the documents, architecture, all these things. It will no longer be,
'you figure it out, you tell us a solution,'" said Col. Hon Pak, the Army medical department's chief information officer. "The opensource custodial agent, largely a VA-led effort but we also participate, really gives you an opportunity in ways that we've never
had before." … "Having that venue now equalizes the playing ground so that small, innovative organizations can come and help
us figure things out." said Pak. Opening the door to nimble, innovative technologies is a core focus for Pak, who said “DoD is
looking for more modular capabilities.” All the Services "have pretty much bet the farm" that patient-centered medical home will
change healthcare, but he said they need the right tools to get there. "This idea around [health information exchange],
telehealth, mobile health, patient-centered medical home are really going to be the necessary ingredients that have to be
formulated to drive some of the transformation," Col. Pak said.
This Software Development Kit (SDK) specifies the EHR Services Platform (ESP) to implement the vision expressed above .
2
ESP SDK
WORKING DRAFT RFI: not for official use.
2
Executive Summary
SAIF
(Service Aware Interoperability Framework)
Conceptual Perspective
EHR Services Platform
SDK Scope
Business Context
Clinical/Work Process Architecture
System Architecture
Information Architecture
Integration & Deployment Options
Potential Applications
Summary & Conclusion
Also See Companion
SAIF Logical Perspective
Implementation Guide (IG)
ESP SDK
WORKING DRAFT RFI: not for official use
3
TALKING POINTS: SDK Purpose
ESP enabled systems are a part of a joint DoD-VA Open Source EHR (OSEHR) Initiative
• The ESP Software Development Kit (SDK) presents the vision (this slide deck) and specifies
the means (see the companion ESP Implementation Guide (IG)) for Open Source and vender
applications to plug-&-play within future-state ESP enabled operating and data-access
platforms; ESP enabled systems are composed of “information” services supporting efficient
plug-&-play application-integration.
• The SDK development, following agile processes, is intended to become a clear, complete,
concise, correct and consistent HL7 SAIF (Service Aware Interoperability Framework)
conformant standards-based ESP enabled system SDK IG for vender and open-source
developers.
• This comprehensive set of slides may be freely used or repurposed with appropriate attribution
YOUR HELP IS REQUESTED IN VERIFYING, VALIDATING AND INCREASING THE
USABILITY OF THE ESP SDK
4
ESP SDK
WORKING DRAFT RFI: not for official use.
4
A five-color star “branding”
indicates that a slide was
adapted from Canada Health
Infoway’s EHR Blueprint
ACKNOWLEDGEMENT
This ESP SDK started with the Canada Health Infoway “Electronic Health
Record Blueprint” as a foundation; the SDK is being adapted to meet the Open
Source EHR modernization situation and needs.
https://www.infoway-inforoute.ca/working-with-ehr/knowledgeway/knowledge-center/657
ESP SDK
WORKING DRAFT RFI: not for official use.
5
DISCLAIMER
THIS DRAFT SDK IS NOT LEGALLY BINDING
AND DOES NOT REPRESENT OFFICIAL DOD OR VA POSITION.
• The DoD and VA wish to openly-and-transparently collaborate with the Open-Source EHR-Community;
this is a new “agile acquisition” approach for the government and MUST evolve with lessons learned.
• This SDK, its companion Implementation Guide (IG) and related artifacts are DRAFT Working
Documents, being coordinated by the Open Source EHR Custodial Agent (OSEHRA) Architecture
Committee with the guidance of the DoD-VA Health Architecture Interagency Group (HAIG). The purpose
is to seek EHR-modernization architectural-input from DoD & VA staff, contractors, partners,
stakeholders, venders and open-source-community in an open-and-transparent collaborative-forum;
• The DRAFT Software Development Kit (SDK), its IG and any related documents MUST be considered a
government Request for Information (RFI); without obligation to the government as we go through this
new open-and-transparent agile-development-process;
• Once feedback has been received, OSEHRA Architecture Committee’s updates have been made and
the SDK has been reviewed and approved by appropriate government leadership, DRAFT can be
removed from the SDK and its IG and they will be versioned, time-stamped and an official government
letter of endorsement MUST be attached.
Only an official government-endorsed-and-versioned SDK, its IG and related artifacts
can be used in any government contract or acquisition process.
6
ESP SDK
WORKING DRAFT RFI: not for official use.
6
Technical Vision: EHR Service Platform (ESP)
INTEGRATED EHR SOLUTION
EHR SERVICES PLATFORM (ESP)
Population
Health
Data &
Services
Population
Health
Data &
Services
EHR
Data &
Services
Registries
Data &
Services
EHR IS
Locator
Information Access & Longitudinal Record Services (LRS)
EHR Information Services (EHR IS)
Point of Service
Applications
ESP SDK
Personal Health
Record Systems
EHR Viewers
WORKING DRAFT RFI: not for official use.
See notes page
7
•
•
•
•
•
•
TALKING POINTS: Technical Vision is to modernize and transition
legacy to an EHR Services Platform (ESP) for Application Integration
An EHR Services Platform (ESP) facilitates application innovation; it is composed of
separated operation, business-rule and information services to integrate plug-&-play
applications; the ESP services MUST be used by ALL applications and ALL
applications MUST be service-based.
As the ESP is fully-specified in the SDK Implementation Guide (IG), as standardized
and reference implementations become available; then, general-purpose and domainspecific “best-of-class” certified applications can be user-selectable and evolve on a
Darwinian basis. This is analogous to a Smart-Phone Application-Markets
Anyone can build and submit ESP services and/or applications for certification
The Open Source EHR Custodial Agent (OSEHRA) will IV&V and CM certified ESP
application services and reference-implementations (e.g., gold builds).
DoD, VA, IHS and others may pick-&-choose, which certified applications they use.
Legacy-systems and ESP enabled systems can co-exist during long legacy transition
periods across large enterprises. This is analogous to the PC and telecommunications
evolution-revolution from the 1980s to now.
8
ESP SDK
WORKING DRAFT RFI: not for official use.
8
Key Concepts: Federated EHR Services Architecture
EHR IS
Enabled
Legacy System
INTEGRATED EHR SOLUTION
EHR IS
EHR SERVICES PLATFORM (ESP)
Tier 3
Plug-&-Play
Data Stores
Population
Health
Data &
Services
Population
Health
Data &
Services
EHR
Data &
Services
EHR IS
Enabled
PHR System
Registries
Data &
Services
EHR IS
Locator
ESP Based
System
EAI IP
Tier 2
EHR
Information
Services
Tier 1
Plug-&-Play
Applications
Data Access
Virtualization Layer
Information Access & Longitudinal Record Services (LRS)
EHR Information Services (EHR IS)
EHR IP
EHR IP
EHR IP
Point of Service
Applications
Personal Health
Record Systems
EHR Viewers
Application
Virtualization Layer
IP is SOA Interoperability Profile aka Service Interface
EAI is Enterprise Application Integration
ESP SDK
WORKING DRAFT RFI: not for official use.
See notes page
9
TALKING POINTS: Benefits
The ESP can become the National and possible International EHR
standard for “best-of-breed” Darwinian innovation, evolution or
revolution where anyone can participate.
The SDK’s Standards-Based Best-Practices ensure consistency across:
– Interoperable Application Service APIs
• Common/ Engineering Service Bus (C/ESB)
• Interoperable Plug-and-Play Applications
– Interoperable Virtual Database (DB) APIs scalable from
• Legacy MUMPS-globals acting as a DB to MS Access, Open or MS SQL, Oracle to
• Massively-parallel high-performance grids running on commodity-hardware-blade-platforms
(i.e., amazon.com & google.com models).
–
–
–
–
ESP enabled Trading Partners
Acquisitions (ESP SDK-IG as GFI for RFIs and RFPs)
VA, DoD and IHS offices, staff and contractors
Open Source and vender community
ESP SDK
D R A F T Talking Points
WORKING DRAFT RFI: not for official use.
10
Legacy Transition Strategy
INTEGRATED EHR SOLUTION
LEGACY EHR SYSTEM
EHR SERVICES PLATFORM (ESP)
EHR-IS ENABLED LEGACY INFRASTRUCTURE
Population
Health
Data &
Services
Data
Warehouse
Data &
Services
EHR
Data &
Services
Data
Warehouse
Data &
Services
Legacy
Point of
Service
Application
Registries
Data &
Services
EHR
Data &
Services
Personal
Health Record
System
Legacy
EAI IP
EHR-IS
EAI IP
Information Access & Longitudinal Record Services (LRS)
Information Access & Longitudinal Record Services (LRS)
EAI IP
Bi-Directional
Information
Exchange
EHR Information Services (EHR IS)
EHR IP
Point of
Service
Application
EHR IP
Personal
Health Record
Systems
EHR Information Services (EHR IS)
EHR IP
EHR Viewer
EAI is Enterprise Application Integration
IP is SOA Interoperability Profile aka Service Interface
ESP SDK
EHR-IS
EHR-IS enabled legacy systems allow users to
transition at a convenient time and then legacy
systems can be shut down.
WORKING DRAFT RFI: not for official use.
11
TALKING POINTS: Transition Strategy based on ESP enabled systems
1. ESP kernel-services and data stores CAN be set-up at one-or-more data-centers (any cloud topology).
2. For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK-IG,
ii) an open-source test virtual-machine (VM) with the ESP set-of operating-and-data services, iii)
clinically-meaningful test-database, test-scripts, certification-criteria.
A. Agile SDK, ESP and application development and certification processes MUST have up-to-date
VMs and ongoing regression testing to obtain/maintain “certified” status.
B. Certified applications, test and certification VMs, test fixtures/scripts, test-results MUST be made
available to anyone (e.g., open source community) to verify and validate test results & attestations.
3. One-or-more user-configurable ESP enabled viewers SHOULD be made freely available.
4. Legacy systems MUST be updated i) to “journal” their clinically-relevant data-store transactions with
the ESP data-store and to query via the ESP, analogous to legacy DoD-VA sharing;
5. Terminology mapping SHOULD be a part of legacy-data transition.
6. To be repurposed to ESP capability, legacy-applications MUST conform to ESP SDK-IG and associated
certification criteria.
7. Once certified ESP enabled viewer(s) and ESP enabled applications are available to clinical users, they
CAN transition to modernized ESP based systems, while others might continue on legacy systems.
8. Clinically-meaningful legacy-data MUST be extracted to ESP before legacy systems are shut down.
12
ESP SDK
WORKING DRAFT RFI: not for official use.
12
EHR Information Services (EHR IS)
within EHR Services Platform (ESP)
EHR SERVICES PLATFORM (ESP)
ORGANISATIONAL INFOSTRUCTURE
Population Health Data
& Services
Registries Data
& Services
Client
Registry
Outbreak
Management
EHR Data
& Services
PHS
Reporting
Shared
Health Record
Drug
Information
Data Warehouse
& Services
Diagnostic
Imaging
Health
Information
Laboratory
Provider
Registry
Location
Registry
Business
Rules
EHR
Index
Terminology
Registry
Message
Structures
Normalization
Rules
Information Access & Longitudinal Record Services (LRS)
IP is SOA Interoperability Profile aka Service Interface
EAI IP
Security Mgmt
Rules/Data
EAI is Enterprise Application Integration
Privacy Mgmt
Rules/Data
Configuration
Rules/Data
EAI IP
Common Information Integration Framework (CIIF) and Common Services
EHR IS
Secure Communications Bus
EHR IP
Public Health
Services
Public Health
Provider
EHR IP
Pharmacy
System
Pharmacist
EHR IP
Radiology
Center
PACS/RIS
Radiologist
EHR IP
Lab System
(LIS)
EHR IP
Hospital, LTC,
CCC, EPR
Lab Clinician
Physician/
Provider
EHR IP
Physician
Office EMR
Physician/
Provider
EHR IP
EHR Viewer
Physician/
Provider
POINT OF SERVICE APPLICATIONS
ESP SDK
WORKING DRAFT RFI: not for official use.
See notes page
13
TALKING POINTS: Common Information Integration Framework (CIIF)
• The Common Information Integration Framework (CIIF) is a business-driven
agile enterprise-information-management methodology and set of softwareservice technologies, which enable semantic interoperability of clinical data.
• The CIIF Team specifies or imposes a standards-based set of information
services that enables any authorized empowered provider to care for any
beneficiary regardless of location, organization or device.
ESP SDK
14
WORKING DRAFT RFI: not for official use.
See notes page
14
ERH Services Platform (ESP) enabled system (conceptual view)
15
ESP SDK
WORKING DRAFT RFI: not for official use.
See notes page
15
TALKING POINTS: EHR Services Platform (ESP)
Addressing Legacy Problems
1.
Innovation to revitalize legacy systems
• Services within a standards-based component-architecture encourage lower-cost component innovation without
requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and avoids stovepipes.
2.
Interoperability among partners.
• CIIF canonical information and terminology models can be used to map among heterogeneous system
information exchanges. By adopting common EHR IS data, terminology, and communications standards; multiple
organizations can share and ultimately harmonize Electronic Medical Records.
3.
Transition from legacy systems and data to an integrated EHR architecture.
• Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and opensource applications, scalable databases and infrastructure to coexist.
4.
Agility to respond to rapid healthcare changes and related legislation.
• Services within a standards-based component-architecture encourage faster and lower-cost changes to be made
and tested within components without requiring enterprise-wide expertise and testing.
5.
High Costs of change and sustainment.
• Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and
infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeablecomponents can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built
In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. .
6.
Patient Safety issues resulting from software changes.
• Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety.
7.
Open Source Community Enablement
• Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications,
databases and infrastructure, which may be combinations of MUMPS, COTS, GOTS and open source code to
meet the specific-needs of various stakeholder-and-user communities.
16
ESP SDK
WORKING
DRAFTTalking
RFI: not for official
use.
DR
AFT
Points
HL7 Service Aware Interoperability Framework (SAIF)
Enterprise Compliance and Conformance Framework (ECCF)
ECCF
Conceptual
Perspective
Logical
Perspective
Implementable
Perspective
Enterprise
Dimension
Information
Dimension
Computational
Dimension
“How” - Behavior
“Where” - Implementation
“Where” - Deployments
 Inventory of
• Domain Entities
• Activities
• Associations
• Information
Requirements
• Information Models
o Conceptual
o Domain
 Inventory of
• Functions-services
 Requirements
• Accountability, Roles
• Functional
Requirements, Profiles,
Behaviors, Interactions
• Interfaces, Contracts
 Inventory of
• SW Platforms, Layers
• SW Environments
• SW Components
• SW Services
• Technical
Requirements
• Enterprise Service Bus
 Key Performance
Parameters
 Inventory of
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Technical Requirements
 Business Policies
 Governance
 Implementation Guides
 Design Constraints
 Organization Contracts
 Information Models
 Terminologies
 Value Sets
 Content Specifications
 Specifications
• Use Cases, Interactions
• Components, Interfaces
 Collaboration
Participations
 Collaboration Types &
Roles
 Function Types
 Interface Types
 Service Contracts
 Models, Capabilities,
Features and Versions for
• SW Environments
• SW Capabilities
• SW Libraries
• SW Services
• SW Transports
 Models, Capabilities,
Features and Versions for
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Business Nodes
 Business Rules
 Business Procedures
 Business Workflows
 Technology Specific
Standards
 Schemas for
• Databases
• Messages
• Documents
• Services
• Transformations
 Automation Units
 Technical Interfaces
 Technical Operations
 Orchestration Scripts
 SW Specifications for
• Applications
• GUIs
• Components
 SW Deployment
Topologies
 HW Deployment
Specifications
 HW Execution Context
 HW Application Bindings
 HW Deployment Topology
 HW Platform Bindings
“Why” - Policy
 Inventory of
• User Cases, Contracts
• Capabilities
 Business Mission, Vision,
Scope
“What” - Content
Engineering
Dimension
Technical
Dimension
Five (5) Categories: Capability | Mission | Business Process | Infrastructure/Enterprise Architecture | Interoperability
17
ESP SDK
WORKING DRAFT RFI: not for official use.
TALKING POINTS: HL7 Service Aware Interoperability Framework
(SAIF) Conformant ESP Implementation Guide (IG)
• To be OSEHRA software-quality certified, ESP enabled applications
MUST be conformant to the companion ESP SDK Implementation
Guide (IG) which follows HL7 SAIF guidance.
– The SDK slide set is the SAIF Conceptual Perspective
– The SDK Implementation Guide is the SAIF Logical Perspective
– Developers & Venders MUST deliver the SAIF Physical Perspective
• SAIF provides guidance; but, OSEHRA, DoD, VA, IHS and
stakeholders MUST establish a consensus ESP IG, defining required
architectural views (e.g., subset of DoDAF views) and appropriate
specification language (e.g., BPMN, UML).
• The ESP companion SDK IG is HL7 SAIF conformant and defines
software-engineering best-practices for interoperability Standards and
Conventions (iSAC).
• Agile processes are being followed to define the SDK slides and IG;
that is, there will be many incremental refinements.
18
ESP SDK
WORKING DRAFT RFI: not for official use.
18
Generally, only the preceding Executive Summary is distributed via e-mail
The most-current 180+ slide ESP SDK Conceptual Architecture and
The most-current evolving ESP SDK Implementation Guide (IG)
can be downloaded at: http://www.osehra.org/node/47/content/documents
ESP SDK Conceptual View
Next: ESP SDK Future-State
SAIF Conceptual Perspective
EHR Services Platform concepts
SDK Scope
Business Context
Clinical/Work Process Architecture
System Architecture
Information Architecture
Integration & Deployment Options
Potential Applications
Summary & Conclusion
CALL FOR PARTICIPATION
Please post your discussion comments at
http://www.osehra.org/group/architecture
ESP SDK
WORKING DRAFT RFI: not for official use
19
Abbreviations
AKA
BITE
CM
DI
DoD
EAI
EHR IS
ESP
ESB
HAIMS
ICIB
IG
IHS
IP
IV&V
LIS
LRS
OSEHR
OSEHRA
RFI
RIS
SAIF
SDK
SDO
SOA
TSA
VA
VHA
VM
Also Known As
Built in Test Environment
Configuration Management
Diagnostic Imaging
Department of Defense
Enterprise Application Integration
EHR Information Services
HER Services Platform
Engineering Service Bus
Health Artifact and Image Management Solution
Interagency Clinical Informatics Board
Implementation Guide
Indian Health Services
Interoperability Profile / Specification
Independent Verification and Validation
Laboratory Information Systems
Longitudinal Record Service
Open Source EHR
OSEHT Custodial Agent
Request for Information
Radiology Information System
HL7’s Service Aware Interoperability Framework
Software Development Kit
Standards Development Organization
Service Oriented Architecture
Telehealth Scheduling Application
Veterans Administration
Veterans Health Administration
Virtual Machine
20
ESP SDK
WORKING DRAFT RFI: not for official use.
20