Colorado Vendor Neutral Archive (aka CTN Cloud VNA)

1. 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

2. 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.

3. 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

4. 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) Jan 6 • Questionnaire emailed to participating organizations. • 1 ½ hour Cloud VNA Architecture Discussion with participating organizations. Jan 24 • Vendor RFI’s due back to CTN. • Participant Questionnaires due back to CTN. Jan 25 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. Feb 6th

5. Introduction to the Vendor Neutral (enterprise) Archive • Michael J. Gray, Gray Consulting • graycons@well.com

6. Learning Objectives • 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

7. Itemize the Enterprise Problems • Multiple Silos (typical with multiple free-standing PACS) • Introduce redundant, often disparate platforms • Expensive to purchase and manage • Incompatible Data • There are Data Exchange issues between disparatePACS caused byVariances 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

8. Itemize the Enterprise Problems • Insufficient Information Lifecycle Management strategies • Many PACS applications do not support an intelligent ILM strategy and have no Purge application • 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

9. Itemize the Enterprise Problems • Need a solution for the image-producing departments that will not have their own local PACS. • Image Acquisition, ID Association, QA and QC Operations • 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!

10. Itemize the Enterprise Problems • 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

11. Problems with today’s PACS archives • 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 • Limited ability to aggregate a patient’s data spread across other vendor’s PACS

12. Problems specifically with today’s PACS archives • Data is controlled by the PACS vendor, not the Healthcare Organization • Difficult or expensive to share an Enterprise-class Storage Solution tied to the Radiology PACS with all of the other departmental PACS application servers • Data management applications designed to match lifetime of the PACS, not the lifetime of the data… there is no data purge mechanism! • 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

13. The Solution to the Problem?

14. The Solution? • Insisting that the vendors modify their PACS to be 100% DICOM-conformant is impractical • The vast majority of PACS being sold today are technically “DICOM-conformant” • 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

15. The Solution? • Placing faith in the evolution ofXDS-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

16. The Solution? • 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… • that the receiving PACS can fully utilize the data created by another PACS • XDS-I does not perform DICOM tag mapping

17. The Solution! • The Vendor-Neutral Enterprise Archive Cardiology PACS Radiology PACS • Acquisition & QC • Dept. Workflow • Specialty Viewers • Short-term Cache • Acquisition & QC • Dept. Workflow • Specialty Viewers • Short-term Cache 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 Visible Light • Data Conversion • Export to VNA “X”-ology PACS • Acquisition & QC • Dept. Workflow • Specialty Viewers • Short-term Cache

18. VNA Cache The Solution! This high-level graphic suggests the size and redundancy aspects of a VNA properly configured for a single Organization PACS C-PACS X-PACS R-PACS PACS Facility B LAN Facility A LAN Enterprise WAN VNA Data Center B Data Center A

19. The Solution! • 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 non-DICOM 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

20. The Solution! • 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)

21. CTN Cloud VNA • Project Overview • Owen Hathaway, CTN Architecture Consultant • ohathawa@gmail.com

22. 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-per-Study pricing model. CTN will receive sustainability revenue for each study stored in the CTN Cloud VNA.

23. How the Architecture Evolved for the CTN Cloud VNA • Michael J. Gray, Gray Consulting • graycons@well.com

24. Minimal Solution: Cloud-based DR

25. R-PACS C-PACS R-PACS C-PACS R-PACS C-PACS X-PACS Facility C LAN Facility B LAN Facility A 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

26. R-PACS C-PACS R-PACS C-PACS R-PACS C-PACS X-PACS Gateway Gateway Gateway Facility C LAN Facility B LAN Facility A LAN CTN WAN 1 - Remote (Cloud-based) Disaster Recovery Solution, where Gateway servers pass individual PACS Data (in original data formats) to individual storage solutionsin the Cloud Data Center LAN Storage Server Storage Network Cloud Data Center

27. R-PACS C-PACS R-PACS C-PACS R-PACS C-PACS X-PACS Gateway Gateway Gateway Facility C LAN Facility B LAN Facility A LAN CTN WAN 2 - Remote (Cloud-based) PACS-Neutral Disaster Recovery Solution, where Gateway Servers pass individual PACS Data (in original data formats) to Vendor-Neutral Archive in the Cloud, where the VNA application normalizes the data before forwarding it to the Storage Server Cloud Data Center LAN VNA Storage Server Storage Network Cloud Data Center

28. Remote PACS-Neutral DR Solution • 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)

29. Remote PACS-Neutral DR Solution • 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

30. Solution! - Image-enabling the EMR • 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

31. The Solution! -The Enterprise UniViewer Electronic Medical Record Physician Portal • Single Access • Single Session • Ability to “aggregate” data from multiple sources URL call UniViewer Radiology PACS Cardiology PACS DICOM Vendor-Neutral Archive • Consolidated Enterprise-wide Patient Record • Enterprise Image Directory • Enterprise Image Data Visible Light “X”-ology PACS

32. The Solution! -The Enterprise UniViewer Electronic Medical Record Physician Portal URL call UniViewer CTN Cloud VNA DICOM Vendor-Neutral Archive • Second Copy of Data

33. Proposed Solution: CTN Cloud VNA

34. R-PACS C-PACS R-PACS C-PACS R-PACS C-PACS X-PACS Gateway Gateway Gateway Facility C LAN Facility B LAN Facility A LAN CTN WAN 3 - Remote (Cloud-based) PACS-Neutral 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 Cloud Data Center LAN VNA Storage Server Uni-Viewer Storage Network Cloud Data Center

35. Remote PACS-Neutral DR/BC Solution • 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 • New studies can be interpreted on modality workstations and Cloud-based UniViewer can provide access to Second copy for comparison • Modalities can forward new data to the Cloud when local PACS is unavailable • New image data can be downloaded from Cloud to the PACS when PACS are back on-line

36. Remote PACS-Neutral DR/BC Solution • 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 • Image acquisition • QA/QC • 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

37. Optional Add-on Solution: Local VNA Deployment

38. R-PACS C-PACS R-PACS C-PACS R-PACS C-PACS X-PACS Gateway Gateway Facility C LAN Facility B LAN Facility A LAN Facility C WAN CTN WAN Facility C Data Center LAN Cloud Data Center LAN Storage Server VNA Uni-Viewer VNA Storage Server Uni-Viewer Storage Network Storage Network Cloud Data Center Facility C Data Center Facility C Upgrade to the Hybrid VNA

39. Upgrade to local VNA Functionality • 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

40. Upgrade to local VNA Functionality • 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 • Image acquisition • QA/QC • Study Reconciliation • Supports ILM functionality for the Primary Copy of the data

41. Upgrade to local VNA Functionality • 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

42. Key Features of VNA Addressed in RFI to Vendors

43. Key Features of the CTN Cloud VNA • Bi-Directional, Dynamic Tag Morphing to facilitate data exchange (on-the-fly conversions of data formats in support of data exchange between disparate PACS) • Fundamentally a manager of DICOM Objects…but must support methodologies for accepting/managing non-DICOM Objects(DICOM-wrapping, DICOM encapsulation, Web Services) • Sophisticated Information Lifecycle Management, including policy-based Study Deletion, driven by patient/study meta data • Pseudo Master Patient Index (MPI) MRN matching capabilities and optional full-featured MPI • Automated / scheduled Pre-fetching and Auto-routing using user-defined Relevant Prior Algorithm • Compensation for smaller PACS Cache

44. Key Features of the CTN Cloud VNA • Logical Segregation of Data by Organizational Node (departments, facilities, outside groups) • Creation of XDS-I Manifest and OptionalXDS-I Registry and Repository • Flexible, Auditable Transaction Logging • 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)

45. Key Features of the CTN Cloud VNA UniViewer • 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

46. Sharing Images through CORHIO and QHN • Owen Hathaway, CTN Architecture Consultant • ohathawa@gmail.com

47. Considerations for HIE Image Sharing • 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

48. Considerations for HIE Image Sharing • 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

49. Considerations for HIE Image Sharing

50. Summary • Michael J. Gray, Gray Consulting • graycons@well.com