Transcript Document

Colorado
Vendor Neutral Archive
(aka CTN Cloud VNA)
Project and Architecture
Overview
Project Coordination Team:
•
•
•
•
Toria Thompson, CTN Strategic Consultant (Project Coordinator)
Debby Farreau, CTN Program Director
Owen Hathaway, CTN Architecture Consultant
Michael Gray, VNA Consultant
1/23/2012 – Version 7.1
1
Colorado Vendor Neutral Archive
(aka CTN Cloud VNA)
Project Goals:
• This feasibility study is the first part of a potentially multi-part
project to establish a Colorado VNA.
• The feasibility study is being funded by Centura Health and is open
to any health care organization that has a need to house and
share images.
• The feasibility study goal is to make a Go/No Go decision, in
general, about a Cloud VNA not to pick a specific vendor. The
four vendors asked to respond to our RFI are Acuo, Teramedica,
DeJarnette (Iron Mountain), InsightOne (Dell).
• If decision is to “Go”, next steps will be to work with specific
vendor(s) to architect the final solution.
1/23/2012 – Version 7.1
2
Colorado Vendor Neutral Archive
(aka CTN Cloud VNA)
Participating Organizations:
•
•
•
•
•
•
•
•
•
•
•
•
Aspen Valley Hospital
Banner Health
Boulder Community Hospital
Centura Health
Children’s Hospital Colorado
Colorado Springs Health Partners
CORHIO
Custer County Medical Center
Denver Health
Diversified Radiology of Colorado
Estes Park Medical Center
Longmont United Hospital
•
•
•
•
•
•
•
•
•
•
•
Memorial Health System
Metropath
Montrose Hospital
Oncure
Penrad
Poudre Valley Health System
Quality Health Networks (QHN)
Radiology Imaging Associates
University of Colorado Hospital
Valley Wide Health Systems
Yuma Hospital
…and growing
1/23/2012 – Version 7.1
3
Colorado Vendor Neutral Archive
(aka CTN Cloud VNA)
Project Timeline: December 12, 2011 – February 10, 2012
January, 2012
• Request for Information emailed to vendors:
Acuo, Teramedica, DeJarnette (Iron Mountain) and InsightOne (Dell)
• Questionnaire emailed to participating organizations.
• 1 ½ hour Cloud VNA Architecture Discussion with participating
organizations.
• Vendor RFI’s due back to CTN.
• Participant Questionnaires due back to CTN.
February, 2012
• Two hour business meeting with participating organizations to
review vendor responses and pricing and make decision whether
and how to proceed to next step.
1/23/2012 – Version 7.1
4
Introduction to the
Vendor Neutral
(enterprise) Archive
Michael J. Gray, Gray Consulting
[email protected]
1/23/2012 – Version 7.1
5







Itemize the Enterprise Problems
Problems with today’s PACS Archives
A practical solution: Vendor-Neutral Enterprise Archive
Proposed CTN Cloud VNA Architecture
Key Features of the CTN Cloud VNA and UniViewer
Considerations for Sharing Images via HIE
Summary
1/23/2012 – Version 7.1
6
1.
Multiple Silos (typical with multiple free-standing PACS)
 Introduce redundant, often disparate platforms

2.
Expensive to purchase and manage
Incompatible Data
 There are Data Exchange issues between disparate PACS
caused by Variances in the Data Object Header, Inability to
Query/Retrieve with foreign systems, Inability to accept study
originating in another PACS
 Requires complex Data Migrations between subsequent
generations of departmental PACS
1/23/2012 – Version 7.1
7
3.
Insufficient Information Lifecycle Management strategies
 Many PACS applications do not support an intelligent ILM
strategy and have no Purge application
4.
Need for both Specialized and General Display Applications
 Each Department requires modality-specific tools for
Visualization, Image Processing & Measurements, Reporting
 Referring physicians require simple viewer that can
access/display images from all departments
1/23/2012 – Version 7.1
8
5.
Need a solution for the image-producing departments that
will not have their own local PACS.
 Image Acquisition, ID Association, QA and QC Operations
6.
Need a solution for the inevitable Data Migration
 The cost (in dollars and time) of repeated data migrations from
an Enterprise Archive is simply unsustainable!
1/23/2012 – Version 7.1
9

There are major problems with today’s PACS
 Data Object Format or the DICOM Header contents
 Inter-System Communications protocols (compression schemes)
 Archive Solutions


Very few PACS vendors think outside of their box
Workable Solutions for today’s
enterprise image data management
problems will require thinking
outside of
outside of their box
1/23/2012 – Version 7.1
10
1.
2.
3.
4.
Choice of storage media or storage solutions is often limited
Potential for use of Private DICOM Header “tags”
Ability to share only basic image data with another PACS
Key work products may not be transferable to, or compatible
with, other PACS
 Radiology example - Presentation States, Key Image Notes
5.
Limited ability to aggregate a patient’s data spread across
other vendor’s PACS
1/23/2012 – Version 7.1
11
6.
Data is controlled by the PACS vendor, not the Healthcare
Organization
7.
Difficult or expensive to share an Enterprise-class Storage
Solution tied to the Radiology PACS with all of the other
departmental PACS application servers
8.
Data management applications designed to match lifetime
of the PACS, not the lifetime of the data…
there is no data purge mechanism!
9.
Data Migration is inevitable



When one vendor’s PACS is replaced by a different vendor’s PACS
When the PACS vendor changes architectures or storage solutions
When the vendor introduces a new generation of software
1/23/2012 – Version 7.1
12
1/23/2012 – Version 7.1
13

Insisting that the vendors modify their PACS to be 100%
DICOM-conformant is impractical
 The vast majority of PACS being sold today are technically “DICOMconformant”
 Unsupported DICOM functionality is missing, because the customer
doesn’t understand it, and is not demanding it

Insisting that the vendors eliminate their use of private tags or
encrypted data is impractical
 Removing private tags in both modalities and PACS would take years
1/23/2012 – Version 7.1
14

Placing faith in the evolution of XDS-I (Cross-enterprise
Document Sharing for Imaging),recommended by IHE1, is not
the solution either.
 Few (if any) current PACS support XDS-I
 Community efforts to implement cross-enterprise data sharing are
evolving very slowly
 Many PACS vendors remain years behind in implementing DICOM
Objects and SOP Classes, what is their motivation to support the
more esoteric XDS-I?
 XDS-I is intended to solve the more complicated problem of data
exchange between Enterprises, not between disparate PACS within
an Enterprise
1
Integrating the Healthcare Enterprise
1/23/2012 – Version 7.1
15

Placing faith in the evolution of XDS-I (Continued)
 XDS-I imposes another layer of complexity on a PACS or Archive,
typically adding a 30% technology surcharge
 XDS-I assures aggregation of all studies belonging to the same
patient regardless where each study was done and the different
facility MRN’s
 XDS-I does not assure functionality…
o that the receiving PACS can fully utilize the data created by another
PACS
o XDS-I does not perform DICOM tag mapping
1/23/2012 – Version 7.1
16

The Vendor-Neutral Enterprise Archive
Cardiology PACS
Radiology PACS
• Acquisition & QC
• Dept. Workflow
• Specialty Viewers
• Short-term Cache
Visible Light
• Data Conversion
• Export to VNA
Vendor-Neutral Archive
• Enterprise Acquisition & QC
• For Dept. w/o PACS
• For Non-DICOM Objects
• Visible Light Dept. Workflow
• Enterprise Image Directory
• Aggregated Patient Folder
• Data Exchange Engine (Tag Morphing)
• Enterprise Viewer Set
• Long-term Cache
• Enterprise ILM
• Disaster Recovery / Business
Continuity
• Enterprise System Administration
• Acquisition & QC
• Dept. Workflow
• Specialty Viewers
• Short-term Cache
“X”-ology PACS
• Acquisition & QC
• Dept. Workflow
• Specialty Viewers
• Short-term Cache
1/23/2012 – Version 7.1
17
This high-level graphic suggests the size and
redundancy aspects of a VNA properly configured for a
single Organization
PACS
R-PACS
C-PACS
X-PACS
PACS
VNA
Cache
Facility B LAN
Facility A LAN
Enterprise WAN
VNA
Data Center A
Data Center B
1/23/2012 – Version 7.1
18

The only workable solution to solving the problems listed in
this presentation is to deploy a Vendor-Neutral Enterprise
Archive
 Take the “A” out of PACS
 The Vendor-Neutral Archive would accept both DICOM and nonDICOM image data and its related meta data
 Incorporate the tools to dynamically translate between disparate
PACS (Bi-directional Dynamic Tag Morphing)
 Bring sophisticated Information Lifecycle Management tools,
including Purge mechanism to enterprise image data management
1/23/2012 – Version 7.1
19

Arguments for a Vendor-Neutral Enterprise Archive
 Eliminate future data migrations
 Expand choice of storage media
 Easier way for individual and/or dissimilar Departmental PACS to
share a long-term “Archive” and effectively exchange data
 Control of the study data by the Organization, not the vendor,
makes it easier to change PACS
 Support of sophisticated Information Lifecycle Management
strategies (especially Purging)
1/23/2012 – Version 7.1
20
CTN Cloud VNA
Project Overview
Owen Hathaway, CTN Architecture Consultant
[email protected]
1/23/2012 – Version 7.1
21
Project Objectives:
The CTN Cloud VNA will….
 House a secondary (archived) copy of medical images from
healthcare organizations across Colorado.
 Enable sharing of these images among providers in partnership
with CORHIO and QHN.
 Enable access and sharing of these images through a hosted
Universal Viewer.
 Provide disaster recovery and business continuity based on
these copies.
 Be totally vendor-managed and provided under a master Fee-perStudy pricing model. CTN will receive sustainability revenue for
each study stored in the CTN Cloud VNA.
1/23/2012 – Version 7.1
22
Michael J. Gray, Gray Consulting
[email protected]
1/23/2012 – Version 7.1
23
1/23/2012 – Version 7.1
24
R-PACS
C-PACS
Facility A LAN
X-PACS
R-PACS
C-PACS
R-PACS
C-PACS
Facility C LAN
Facility B LAN
CTN WAN
Current State Individual Heterogeneous PACS Environments, each with on-site Primary
and Secondary (DR) copy of the image data
DICOM communication of image data in individual PACS formats
1/23/2012 – Version 7.1
25
R-PACS
C-PACS
R-PACS
X-PACS
R-PACS
C-PACS
C-PACS
Gateway
Gateway
Gateway
Facility B LAN
Facility A LAN
Facility C LAN
CTN WAN
Data Center LAN
Storage
Server
Storage Network
1 - Remote (Cloud-based) Disaster
Recovery Solution, where Gateway
servers pass individual PACS Data
(in original data formats) to
individual storage solutions in the
Cloud
Cloud Data Center
1/23/2012 – Version 7.1
26
R-PACS
C-PACS
R-PACS
X-PACS
R-PACS
C-PACS
C-PACS
Gateway
Gateway
Gateway
Facility B LAN
Facility A LAN
Facility C LAN
CTN WAN
Cloud Data Center LAN
VNA
Storage Network
Cloud Data Center
Storage
Server
2 - Remote (Cloud-based) PACSNeutral Disaster Recovery
Solution, where Gateway Servers
pass individual PACS Data (in
original data formats) to VendorNeutral Archive in the Cloud, where
the VNA application normalizes the
data before forwarding it to the
Storage Server
1/23/2012 – Version 7.1
27

Individual PACS DR solutions are relocated to the Cloud

Gateway Server in each facility receives and forwards
individual PACS data

Vendor Neutral Archive application
 Normalizes data (fixes header idiosyncrasies)
 Manages PACS data from individual facilities in individual logical
partitions of the storage solution (compartmentalizing data at the
more granular department level is optional)
1/23/2012 – Version 7.1
28

This PACS-Neutral DR Solution:
 Supports fully interoperable exchange of the Second Copy of the
data (Image Sharing) between any PACS both in the facility and
across all facilities
 Supports Aggregation of the Second Copy of the patient data across
all PACS and all facilities
 Supports ILM functionality for the Secondary Copy
 Eliminates future data migrations

This PACS-Neutral DR Solution does NOT:
 Image-enable the EMR
 Provide a Business Continuity solution
1/23/2012 – Version 7.1
29

Electronic Medical Record (EMR) systems are typically not
self-contained systems
 EMR does not store image data
 EMR does not include a multi-modality image viewing application

The Portal’s Patient/Study UID can be used to create a URL
pointer to the study data stored in the specific Departmental
PACS
 BUT a Multiple PACS scenario forces the user to learn and use
multiple viewers,
 AND Separate PACS require separate viewing sessions
1/23/2012 – Version 7.1
30
Electronic Medical Record
Physician Portal
•
•
•
Single Access
Single Session
Ability to “aggregate” data
from multiple sources
URL call
UniViewer
Radiology PACS
DICOM
Cardiology PACS
Vendor-Neutral Archive
•
Visible Light
•
•
Consolidated Enterprisewide Patient Record
Enterprise Image Directory
Enterprise Image Data
“X”-ology PACS
1/23/2012 – Version 7.1
31
Electronic Medical Record
Physician Portal
URL call
UniViewer
CTN Cloud
VNA
DICOM
Vendor-Neutral Archive
•
Second Copy of Data
1/23/2012 – Version 7.1
32
1/23/2012 – Version 7.1
33
R-PACS
C-PACS
R-PACS
X-PACS
R-PACS
C-PACS
C-PACS
Gateway
Gateway
Gateway
Facility B LAN
Facility A LAN
Facility C LAN
CTN WAN
Cloud Data Center LAN
UniViewer
VNA
Storage Network
Cloud Data Center
Storage
Server
3 - Remote (Cloud-based) PACSNeutral DR/BC Solution, where
Gateway servers pass individual
PACS Data (in original data
formats) to Vendor-Neutral Archive
in the Cloud, and UniViewer
application image-enables the
EMR with normalized data and
serves as an organization’s BC
solution
1/23/2012 – Version 7.1
34

This PACS-Neutral DR/BC Solution:
 Image-enables each organization’s EMR with the organization’s
Second Copy of its data being managed in the Cloud-based VNA
 Supports internet image access by authorized outside physicians to
the Second Copy of the organization’s data
 Provides the organization with a Business Continuity solution
o New studies can be interpreted on modality workstations and Cloudbased UniViewer can provide access to Second copy for comparison
o Modalities can forward new data to the Cloud when local PACS is
unavailable
o New image data can be downloaded from Cloud to the PACS when PACS
are back on-line
1/23/2012 – Version 7.1
35

This PACS-Neutral DR/BC Solution does NOT:
 Support local exchange of the Primary Copy of the data between
PACS (exchange data must be retrieved from Cloud)
 Support non-PACS departments with
o Image acquisition
o QA/QC
o Study Reconciliation
 Provide ILM functionality for the Primary Copy of the data

VNA Functionality and Benefits can be brought into each
Organization with a local VNA deployment
1/23/2012 – Version 7.1
36
1/23/2012 – Version 7.1
37
R-PACS
C-PACS
R-PACS
X-PACS
R-PACS
C-PACS
Gateway
Gateway
Facility C LAN
Facility B LAN
Facility A LAN
Facility C WAN
CTN WAN
Cloud Data Center LAN
UniViewer
VNA
Storage Network
Cloud Data Center
C-PACS
Storage
Server
Facility C Data Center LAN
Storage
Server
VNA
UniViewer
Storage Network
Facility C Data Center
Facility C Upgrade to the Hybrid VNA
1/23/2012 – Version 7.1
38


Facility’s Gateway Server is eliminated
Primary Vendor Neutral Archive subsystem is deployed in
Facility’s data center
 Normalizes Primary Copy of data for all Facility’s PACS
 Manages the Primary Copy of all data across the Enterprise


Facility PACS storage can be reduced to 18-24 month cache
Local instance of the UniViewer image–enables Facility’s
EMR
1/23/2012 – Version 7.1
39

The Hybrid Solution:
 Supports fully interoperable data exchange of the Primary Copy of
the data between all PACS in a Facility
 Supports Aggregation of the Primary Copy of the patient data across
all PACS in the Facility
 Supports non-PACS departments in the Facility with
o Image acquisition
o QA/QC
o Study Reconciliation
 Supports ILM functionality for the Primary Copy of the data
1/23/2012 – Version 7.1
40

The Hybrid Solution:
 Eliminates future data migrations for Facility/Organization
 Improves performance of EMR and Internet access to Facility’s
images by drawing on the Primary Copy of Facility data
 Lowers cost of Facility PACS storage by cutting back PACS cache to
18 to 24 months
 Secondary subsystem in Cloud provides Facility with both DR and
BC solutions
1/23/2012 – Version 7.1
41
1/23/2012 – Version 7.1
42
1.
Bi-Directional, Dynamic Tag Morphing to facilitate data exchange (on-the-fly
conversions of data formats in support of data exchange between disparate PACS)
2.
Fundamentally a manager of DICOM Objects…but must support methodologies for
accepting/managing non-DICOM Objects (DICOM-wrapping, DICOM encapsulation,
Web Services)
3.
Sophisticated Information Lifecycle Management, including policy-based Study
Deletion, driven by patient/study meta data
4.
Pseudo Master Patient Index (MPI) MRN matching capabilities and optional fullfeatured MPI
5.
Automated / scheduled Pre-fetching and Auto-routing using user-defined Relevant
Prior Algorithm
 Compensation for smaller PACS Cache
1/23/2012 – Version 7.1
43
6.
Logical Segregation of Data by Organizational Node (departments, facilities,
outside groups)
7.
Creation of XDS-I Manifest and Optional XDS-I Registry and Repository
8.
Flexible, Auditable Transaction Logging
9.
Disaster Recovery / Business Continuity configurations with automated Failover
and post-recovery Reconciliation
Not part of requested Vendor Solution
 Image Acquisition, study Reconciliation, manual QC tools (workflow for
departments without PACS)
1/23/2012 – Version 7.1
44
1.
2.
3.
4.
5.
6.
7.
8.
9.
Zero Client, Server-Side Rendering
 Rendering Server operates on loss-less version of the image
 HTML object download
Cache-less (dynamically retrieves image data from local image repositories such
as PACS, VNA)
Supports multiple OS, multiple Browsers
URL-based Interface to EMR (Physician Portal)
Accepts user Authentication from EMR
Auditable Transaction Logging
Optional web services interface to VNA/Storage Solution
Basic to Advanced display features/functions
Compatible with both DICOM and non-DICOM image objects
1/23/2012 – Version 7.1
45
Owen Hathaway, CTN Architecture Consultant
[email protected]
1/23/2012 – Version 7.1
46

Enabling technology is XDS-I
 Requires XDS-I enabling of very PACS repository and Viewer
 Assures aggregation of all studies belonging to the same patient
 Does not assure PACS compatibility


Significant infrastructure “in the middle”…XDS-I Registry &
Repository and associated eMPI
HIE data repositories do not act as DR or BC solutions for the
participating organizations
 Rolling 30 day repositories of image data

Represent Incremental Costs
1/23/2012 – Version 7.2
47

Shared VNA DR/BC is a more pragmatic and less expensive
alternative
 Facilitates PACS-PACS Image sharing with guaranteed data
compatibility
 Any DICOM-conformant PACS/Viewer can participate
 Cost of appropriate DR solution shared across many organizations
 Integrated UniViewer image-enables local EMR, provides BC,
enables both inside and outside Internet Image Sharing

Shared VNA DR/BC can also interface to any HIE
 Requires only one XDS-I and eMPI upgrade
 Guarantees data compatibility in the XDS-I environment
1/23/2012 – Version 7.2
48
1/23/2012 – Version 7.2
49
Michael J. Gray, Gray Consulting
[email protected]
1/23/2012 – Version 7.1
50


Conventional PACS Archives are limiting
PACS effectively create proprietary image data
 Complicating data exchange within the organization and between
organizations participating in a Health Information Exchange
 Necessitating costly data migrations when PACS are replaced
 Giving the vendor control over next PACS decision

Vendor-Neutral Archive is a better, cost-effective way to
manage data for the Clinical/Legal Lifecycle
1/23/2012 – Version 7.1
51

Wide range of real-world problems are resolved by
 DICOM Header Tag Morphing
 Consolidating all image data in an Enterprise Directory
 Providing Physicians with unified multi-modality UniViewer

Strategic First Step is the pro-active Migration of all of the
organization’s PACS Data to the proposed CTN, Cloudbased, VNA-enabled DR/BC Solution
 Shared Infrastructure
 Data Segmentation by Organizational Node
1/23/2012 – Version 7.1
52

Proposed CTN Cloud-based Solution facilitates numerous
applications using each organization’s Secondary copy of its
image data…
 Geographically Separate Disaster Recovery Solution
 Local PACS-to-PACS Image Data Sharing
 Optional participation in HIE data exchange
 Image-enabling each organization’s EMR
 Secure Internet Image Sharing with outside Physicians
 Viable Business Continuity
 Elimination of costly future Data Migrations
1/23/2012 – Version 7.1
53
1/23/2012 – Version 7.1
54