An Expedient Strategy for Image-Enabling an EHR

Transcription

1 r Neutral ht: ing White PaPer nt is fast becoming the unwieldy easingly expensive to support, and mage data is quickly outpacing the l departmental PACS archive. Various epartmental PACS as well. Most t proprietary metadata into the ity with other PACS. The thin-client, tured by most PACS is no longer iversal viewer. Furthermore, the al PACS viewers to the Electronic cian portal is misguided and unlikely ise-class Vendor Neutral Archive (VNA) focus is on enterprise image data blems associated with departmental age data archiving from all of the iviewer takes over enterprise image res interoperability among disparate ta migrations every time a PACS is ata to the organization, which egies of the PACS vendors. An Expedient Strategy for Image-Enabling an EHR Deploying a UniViewer that does not depend upon a Vendor-Neutral Archive is the first step towards a consolidated Medical Image Repository By Michael J. Gray; Principal, Gray Consulting; September, 2014 Sponsored by an unrestricted grant from Merge Healthcare

2 2 An Expedient Strategy for Image-Enabling an EHR Table of Contents \\ Executive Summary...3 \\ Introduction...4 Department with PACS...5 Departments without a PACS...5 Departments using Informal Image Files...5 \\ Initial Challenge: Accessing Medical Images Across Departments and Platforms...6 Urgent Problem: Achieving a Unified View of a Patient s Medical Image...8 First Step to Image Enabling EHRs is Cumbersome for Providers...8 \\ Ideal Solution: Consolidation of All Patient Medical Images into One Repository...10 What is a Universal Viewer?...11 Challenges Involved with Vendor Neutral Archive Deployment...13 \\ System Requirements of a UniViewer...15 \\ A Suggested Strategy for Enterprise Image Management...19 Financial Arguments in Support of a UniViewer First Strategy...21 A Word About ROI...22 \\ Conclusion...23

3 3 An Expedient Strategy for Image-Enabling an EHR Executive Summary In most healthcare organizations, a patient s Medical Image Record is scattered across multiple locations; facilities, departments, and PACS. Those are the imaging studies that are being formally managed. There are many more sets of images that are clinically relevant, many not even considered studies, that are being stored on standalone workstations, on CD s and thumb drives, and on digital cameras and mobile devices. Achieving the concept of a unified Medical Image Repository that would consolidate and manage all of this image data faces technical and economic challenges. As a first step, organizations can work to image-enable their Electronic Health Record (EHR). That means providing their EHR users with the means to access and display the radiology and cardiology images, as well as all of the images that are not formally being managed by department PACS, including those residing on mobile devices. Opening the subject to non-dicom presents its own set of technical challenges. Key words such as image consolidation, DICOM and non-dicom images, would normally suggest Vendor Neutral Archive (VNA), but the deployment of a VNA is a major endeavor, and the complexities of the selection and deployment process may significantly delay the delivery of images to their EHR user. The focus of this paper is on a strategy of image-enabling an EHR without (or before) a VNA. A standalone UniViewer endowed with ten critical features/functions can effectively image-enable an EHR with access to the full range of the patient s medical images. That includes access to the images currently being managed in the department s PACS, as well as all of those clinically relevant images effectively trapped in workstations, thumb drives and mobile devices. The standalone UniViewer described in this paper is not an alternative to the VNA. The UniViewer s short-term working cache is designed to manage the images that have no other formal repository. This short-term archive will ultimately be replaced by a VNA. Image enabling the EHR with a standalone UniViewer is the first step in a multi-step enterprise image management strategy that eventuates in the deployment of the VNA to consolidate all of the images and provide the enterprise with the unified medical image repository.

4 4 An Expedient Strategy for Image-Enabling an EHR Introduction The patient s medical record is something of an ambiguous construct today. Whether it is a folder full of paper-based information or a compact collection of digital files, it probably only contains histories, care summaries, medication and allergy lists, lab results, diagnostic reports, treatment summaries the usual range of clinical information that is accumulated in the course of patient care over a period of time. At the expense of a great deal of effort, the patient s individual medical record(s) might contain this type of clinical information gathered by each of the healthcare organizations, clinics and physician offices the patient has visited over time. If these medical records are in fact individual paper charts, they are rarely comprehensive. Even if the records are digital, they do not contain many of the medical images associated with any of those diagnostic reports, office visits, or episodes of care. A Medical Record, whether a paper chart or an electronic file is a manageable folder or file size, whereas the Medical Image Record is significantly larger and more difficult to assemble and manage. Yet it is hard to imagine any medical facility or healthcare provider not wanting to include all of the patient s medical images in the Medical Record.

5 5 An Expedient Strategy for Image-Enabling an EHR The problem is not simply the size of the patient s medical image collection. It s the difficulty in aggregating the image files and the multitude of file formats from all of the locations throughout the healthcare enterprise and beyond. The inherent challenge in providing access to all image files lies within the system infrastructure of most organizations. Department with PACS The current generation of department PACS basically does not communicate well with other disparate PACS, or effectively exchange data with external systems. Department PACS were designed to be selfcontained data repositories. In fact, many PACS have difficulties querying and retrieving data from other vendor PACS solutions. Because of idiosyncrasies in the DICOM headers unique to each PACS, images actually retrieved from one PACS may not display properly in another PACS or may be missing the Key images, Presentation states and annotations used in the source PACS. For example, radiology PACS may not even be able to display some types of cardiology images. For these very reasons, attempts to build a unified Medical Image Record by consolidating images from all department PACS in any one PACS have exhibited limited success. Departments without a PACS The unified Medical Image Record would not be complete without including images created in those imaging departments that do not yet have a PACS. Endoscopy and ophthalmology are good examples. If these images are being stored in a digital format, they are probably being kept in standalone workstations or on removable media. They are largely unavailable to PACS in other departments or in a standalone clinical viewing application because these systems most likely cannot communicate with these independent workstations. The communication issue is further complicated by the fact that many of the images created in these non-pacs departments are not DICOM. The images could be saved as Bitmaps, JPEGs, TIFFs, or PNG files. The video files could be one of several MPEG formats, MOV or AVI files. Not only would it be difficult for a department PACS or a standalone viewer to access these images, neither would likely be able to display them. Beyond the immediate exchange difficulties is the fact that these formats become obsolete over time (e.g. TGA and Indeo are examples). Departments Using Informal Image Files There are also a number of departments that use imaging in a more informal manner. The images they create during an office visit or treatment are not formal imaging studies. Nevertheless if they have clinical value or are mentioned in a Progress note, Visit note or report, they do belong in the patient s Medical Image Record. Examples include Dermatology, Burn Centers, Wound Care / Diabetic Care and Surgery. Once again, there is no standard data format, so the images could be JPEG, MPEG, etc. Typically no order is created, so there is no easy way to access or build the patient/study/image identifying information required to properly tag the images as required for formal data management. The imaging process itself is complex and presents many challenges, as many of these images are captured with digital cameras, mobile phones and tablets. Without a data management system that could force a standard data format, organize the data and serve as the formal repository, these images cannot easily be accessed or displayed from an EHR, by a department PACS or by a standalone viewer.

6 6 An Expedient Strategy for Image-Enabling an EHR Initial Challenge: Accessing Medical Images Across Departments and Platforms The initial challenge complicating the creation of the unified Medical Image Record is the inability to access and exchange medical images created in various departments, which are spread across the healthcare enterprise. This inability to share images between departments prevents Radiologists, Cardiologists any imaging specialist from accessing relevant prior imaging studies created in other departments. This could potentially compromise the accuracy of the diagnosis and possibly cause delays in treatment. The inability to share images between organizations both complicates and delays treatment and frequently results in performing redundant imaging procedures on the patient. The uncontrolled informal imaging studies (images captured on digital cameras and mobile devices) are also subject to HIPAA breaches as well as not being properly backed up and generally in violation of formal document and image retention policies.

7 7 An Expedient Strategy for Image-Enabling an EHR Non-PACS Images Figure 1 PACS Images Informal Images The following summarizes the image sharing problems facing most healthcare organizations: Department PACS Challenges Inability to access foreign systems, or studies not originally acquired by the PACS (inability of PACS to aggregate across multiple PACS and less formal department repositories) Despite the use of DICOM in the department PACS, most PACS have difficulties translating idiosyncrasies in the DICOM header produced by other PACS, which complicates even a basic display of the images Non-PACS Department Challenges No organized data management system no formal repository to support access to the data Variety of data formats in addition to DICOM, which complicates image display in an environment primarily based on DICOM-oriented display software EHR isn t aware of these exams that were acquired without an Order Informal Imaging Department Challenges No organized process for image acquisition, including the creation and appending of patient/study/image ID to the image data No organized data management system Variety of data formats EHR isn t aware of these exams that were acquired without an order As Figure 1 illustrates, there is no connectivity no ability to share images between the various imaging departments in the healthcare enterprise, or between healthcare organizations. This lack of connectivity is inherent in the image data management systems currently being used in the imaging departments.

8 8 An Expedient Strategy for Image-Enabling an EHR Urgent Problem: Achieving a Unified View of a Patient s Medical Image The urgent problem facing most healthcare organizations today is not so much the lack of a unified image data repository as it is the lack of a unified view of the patient s Medical Image Record through the EHR. Even if the patient s medical images are spread across multiple department repositories (PACS, workstations, etc.), it would be extremely useful to have a single viewing application that could access all of those images and display the relevant images in the same viewing session. Over the last three years, there has been a surge in EHR deployments as hospitals, clinics, and physicians prepare themselves to meet the Meaningful Use requirements mandated by the government. At present, through Stage 2, most of the requirements address electronic charting and using EHRs to manage and access clinical information. This management of result reports, care summaries, and clinical outcomes is based on data that is ingested and managed by the EHR. At this point in time, EHR solutions do not manage medical images. Furthermore, many EHR solutions do not include even a basic medical image viewer. As we progress to Stage 3, access to comprehensive patient data will be a requirement, and that will certainly include medical images. First Step to Image Enabling EHRs is Cumbersome for Providers A review of the literature available on Electronic Medical Record systems suggests that the major EHR vendors never intended their systems to actually manage the image data, and the embedded EHR viewing application is generally limited to displaying page layouts of chart information, diagnostic reports, and PDF versions of scanned clinical documents. The concept of image-enabling the EHR, as in providing access to and display of the patient s medical images, has initially been focused on interfacing the EHR to the various image data repositories (primarily PACS) that are already in place. There are several advantages to this strategy: This strategy avoids the cost of duplicating massive volumes of image data by copying the data to the EHR This strategy avoids the complexity involved in normalizing all of the various image data formats and making certain that images from the various PACS display properly This strategy allows the EHR vendor to avoid having to develop a medical image oriented, multimodality viewer So in the absence of a single unified medical image data repository with its own embedded image viewer, the initial approach to image-enabling the EHR has been to tap the image management and display resources of each of the department PACS. This is accomplished by interfacing the EHR Physician Portal to each of the clinical viewers associated with each of the department PACS. Unfortunately, interfacing the EHR to individual department PACS and using separate clinical viewers to display the images has proven to be a less than satisfactory approach to viewing the patient s medical images. The three principal reasons for this disappointing result being the following: This strategy requires multiple EHR PACS interfaces, which are expensive to build and maintain This strategy necessitates individual viewing sessions. The Radiology images are accessed

9 9 An Expedient Strategy for Image-Enabling an EHR and displayed in the Radiology viewer and the Cardiology images are accessed and displayed in the Cardiology viewer. Related Radiology and Cardiology studies cannot be displayed on the same screen. The user is forced to learn and use multiple viewing applications. This is replicated for every hospital within the enterprise This strategy does not provide access to or include in the screen presentation those images that were created in non-pacs and Informal imaging departments. These departments have a huge unsolved problem. The number of hospitals in the enterprise multiplies the problem. Physicians need the ability to access and review all of these images, ideally in a single viewing session. Is the solution a single image data repository with an associated universal viewer? Can a standalone universal viewer acting on its own simply access the images from wherever they currently exist and display any relevant combination in a single viewing session? Assuming multiple approaches, which is the ideal approach to image-enabling the EHR? Figure 2 summarizes the problem. Medical images exist in three different environments. Non-PACS Images Figure 2 PACS Images Informal Images?

10 10 An Expedient Strategy for Image-Enabling an EHR Ideal Solution: Consolidation of All Patient Medical Images into One Repository The ideal solution is to consolidate all of the patient s medical images into a single image data repository configured with an embedded or associated universal image viewing application that could present any relevant combination of images to the EHR user in a single viewing session. Figure 2 illustrates the key question. What is the ideal approach to aggregating all of the medical images and providing the unified view? A consolidated medical image repository (i.e. a VNA) with an embedded viewer seems like the ideal solution. However this can be a complex and expensive solution, if deployed in a single phase. In a multi-phase strategy, phase 1 could simply focus on deploying the viewer, and phase 2 could focus on the VNA, In this two-phase strategy, the standalone viewer that did not actually manage the image data would have to be able to aggregate data across the many department repositories, address multiple image formats, and probably manage at least a short-term image database. So, it seems the standalone viewer would have to be more than just a viewing application.

11 11 An Expedient Strategy for Image-Enabling an EHR What is a Universal Viewer? The goal is a single, universal, clinical viewing application that will effectively image-enable the EHR. The term clinical viewer refers to the type of image display used by the physicians that routinely access patient information and study results through the physician portal of the EHR. Compared to the type of viewing application used by the Radiologists and Cardiologists to interpret imaging studies, the clinical viewer provides a basic to medium range of display features and functionality. The concept of a universal viewer refers to an application that can display the DICOM image data being managed by the various department PACS; Radiology, Cardiology, etc. It can display the non- PACS images being managed by workstations, whether they are DICOM images or images that have been converted to XDS-I.b format. As already mentioned, the universal viewer must also be able to display non-dicom image data that might be created in the course of procedures and office visits in Endoscopy, Dermatology, Surgery, etc. and are not being managed by a PACS or a workstation. These images may only reside in a mobile device. The UniViewer (my term for the universal viewer) addresses non-dicom patient-centric viewing by offering a way to associate the Informal image data, on a temporary or permanent basis, by offering to consume that data or by retrieving it from an IHE XDS-compliant infrastructure. The concept of a single viewer is a key issue. The objective is to present the physician with a unified view of all of the associated medical images. That means a single viewing session that presents all image types, side-by-side in the same display window. Another key benefit to the single viewer is that the user would only need to learn to use a single display application. This is the concept presented in Figure 3. Non-PACS Images Figure 3 PACS Images DICOM XDS-I Informal Images UniViewer XDS-I XDS-I Converter

12 12 An Expedient Strategy for Image-Enabling an EHR Addressing the issue of image data management actually presents more of a challenge than the development of a single universal viewer. The more diverse the existing image data repositories in the enterprise, the more complicated the task of accessing those images. The ideal solution to creating a unified longitudinal medical image repository is the vendor-neutral archive (VNA). Figure 4 illustrates how the VNA would fulfill the role of unified medical image repository and the UniViewer simply fulfills the role of the universal viewer. The popular definition of the VNA is an enterpriseclass data management system that consolidates primarily medical image data from multiple imaging departments into a master directory database and associated storage solution, thus replacing the individual archives associated with departmental PACS, systems with unfortunate proprietary characteristics that limit their interoperability. In this sense, the VNA becomes the unified image data repository for the Electronic Medical Record (EHR) system. The high level features and functions of the VNA are reasonably well defined at this point in time. The following succinct list of features of the VNA is offered as a brief reminder. Provides bi-directional, dynamic DICOM tag morphing Manages both DICOM and non-dicom data objects Provides sophisticated Information Lifecycle Management Provides logical segregation of data by organizational node (facilities, departments, etc.) Provides automated, HL7 directed and user-defined pre-fetching and auto-routing Supports dual-sited, mirrored configuration with Non-PACS Images Figure 4 PACS Images DICOM XDS-I Informal Images VNA XDS-I UniViewer XDS-I Converter

13 13 An Expedient Strategy for Image-Enabling an EHR automated failover and reconciliation to support business continuity Assures constant data integrity by synchronizing with all sources of metadata updates Supports full transaction logging The benefits of the VNA are also well documented and include the following: Consolidation of long-term image data storage for all of the department PACS Facilitation of data exchange between disparate image management systems and free-standing workstations Provides image management services for Imaging Departments that do not have a formal PACS Elimination of costly and time-consuming data migrations between existing and replacement PACS Transfer of data ownership from the PACS vendor to the organization Simplification of the universal viewer s access to the image data Challenges Involved with Vendor-Neutral Archive Deployment While the Vendor Neutral Archive is considered the embodiment of the concept of the medical image repository, there are a few major drawbacks to basing the strategy of image-enabling the EHR on the deployment of a VNA. The VNA is by necessity a very complex data management system, because it must address in a reasonable manner all of the idiosyncrasies inherent in the diversity of department PACS and the world of non-dicom data objects. The requirements document is already lengthy before the specifics of the organization are added. As a consequence, the selection process and the actual system deployment are both complex and lengthy. There is also the fact that the VNA represents a substantial financial investment, if for no other reason than the requirement to configure the VNA with two identical subsystems to assure business continuity. In my opinion, including the deployment of a VNA in the strategy to image-enable the EHR will unnecessarily delay the more immediate goal of simply providing image access to the EHR users. The more immediate goal can be met with the deployment of the universal viewer, or UniViewer as I will refer to it from here on in this paper. That being said, the UniViewer itself is not intended to be nor is it designed to be the unified medical image repository. It is an independent, standalone viewing application. Nevertheless it becomes quickly obvious why it must necessarily support certain data management functions. As an independent solution it would have to have an internal directory database and file system designed for at least short-term image data management a working cache from which it would quickly draw the new image studies and related priors. The UniViewer would have to have this local working cache, because it could not meet performance expectations if it was dependent on the relatively slow DICOM interactions with the department PACS to access the images. The size of this working cache could be greatly reduced or its very existence eliminated, if the UniViewer and PACS both support a mechanism to speed up the DICOM transfers from the PACS (i.e. multi-threaded transfers) or another transfer mechanism such as WADO (Web Access to DICOM Objects), or other forms of web services. While some PACS actually support multi-threaded transfers, few currently support any version of web services. If the UniViewer can actually access all images, it would be prudent to hold on to them for some time. Therefore the UniViewer is most likely going to have to be configured with a short-

14 14 An Expedient Strategy for Image-Enabling an EHR term working cache and the corresponding data management capabilities. It is important to point out that the existence of any size working cache associated with the UniViewer adds a degree of complexity due to the fact that the UniViewer must have a methodology for keeping its working cache in sync with the PACS or source of truth of the images. This is not a trivial issue, as most PACS do not communicate effectively with outside systems. This is however an unfortunate requirement of the UniViewer that must somehow be achieved for each PACS and image source that is going to contribute images. Assuming the need for a working cache, the UniViewer would effectively become a short-term medical image repository that would provide the referring physicians access and display of those imaging studies either through direct access to the viewer or through the link to the EHR. In this case, the UniViewer could also provide the PACS users with access to otherwise unavailable priors from other imaging departments. If the PACS cannot query/retrieve these images from the UniViewer, the radiologist or cardiologist could directly access the UniViewer and execute a search on the patient MRN and set up a filter of results to return the relevant priors, which the UniViewer could present on a display separate from the PACS. Alternatively, because the UniViewer stores the image studies with clinical context, demographics, and metadata that the EHR understands, the EHR can present the radiologists and cardiologists with a link to the UniViewer to display those priors. Figure 5 illustrates the UniViewer deployed with a working cache in the absence of a VNA, the connections to various sources, and the two access paths for the radiologists direct and EHR. PACS Images Non-PACS Images Informal Images UniViewer EMR Figure 5

15 15 An Expedient Strategy for Image-Enabling an EHR System Requirements of the UniViewer The following is a list of the ten critical features and functions of the UniViewer that are required to image-enable the EHR in a multi-pacs, multi-object imaging environment in the absence of a Vendor Neutral Archive.

16 16 An Expedient Strategy for Image-Enabling an EHR 1. Technical Infrastructure requirements. a. Zero or near-zero client there is no display application or only a very small display application that has to be downloaded to and run on the viewing platform b. Server-side Rendering technology the application software that actually manipulates the image data based on the commands executed by the user is running on a central server(s) and not on the display platform Note: If the user s display platform supports HTML5, then a number of simple display operations (i.e. Window/level, zoom, etc.) could easily be performed on the client, thus eliminating the need to continuously render the image each time such a simple function is executed c. Multi-platform and multi-os the viewing platform can be a Windows, Mac, or mobile device d. Browser independence the display application can deliver the images to any current generation browser e. No client-side dependencies there is no need for pre-installed auxiliary applications or browser plugins such as Flash, Silverlight, Active X, Java, etc. The UniViewer application could take advantage of HTML5 if available, but not be solely dependent on HTML5 f. No acceleration hardware in the rendering server such as dedicated GPU s, compression cards, etc., as this could preclude running the rendering server application suite in a virtual environment g. Supports VMWare and Hyper-V environments h. Supports dual-sited, (active/active or active/ passive) configurations i. Supports multiple Active Directory domains for simplified user authentication j. Supports multiple data exchange interfaces: i. DICOM with multithreaded / multiple association transfers ii. XDS-I.b or a simple file exchange executed through a shared external file for accessing non- DICOM data objects iii. Web Services such as WADO-RS to support cacheless operations where possible. 2. Display Features. The UniViewer should support a broad range of basic display features and functions for static images, cine studies, and video clips, certainly most of the basic applications used in viewing radiology and cardiology studies. 3. Data Object Types. The UniViewer should have the ability to acquire, manage and display multiple image data object types including DICOM, non-dicom native objects and/or XDS-I.b objects, as well as both structured and unstructured report objects. This implies that all objects being managed by or at least accessible to the UniViewer have the appropriate identifying metadata. With respect to XDS, if the UniViewer supports the XDS-I.b option, it would be highly desirable for the UniViewer to be able to transcode DICOM and XDS-I.b objects in either direction in circumstances where that conversion makes sense. 4. Standalone Configuration. In order to operate as an independent system, the UniViewer must include an internal directory and file system required to manage/store a volume of new studies and related priors on a local cache. Depending on the capabilities of the local PACS and the other image sources, the cache size might range from a minimum of six months to as many as eighteen months. If the UniViewer is going to act as the interim archive for the Informal image studies, then the cache size would have to accommodate the volume of Informal studies until the VNA is deployed. The

17 17 An Expedient Strategy for Image-Enabling an EHR UniViewer should be independent and not a component of a local PACS, so the UniViewer is not encumbered with any of the limitations of that PACS, such as data object format, proprietary compression schemes, limited accessibility to other PACS images, etc. 5. Ability to Aggregate. The UniViewer must have the ability to aggregate (query/retrieve) a patient s longitudinal Medical Image Record across the multiple PACS and standalone image data repositories/workstations in the enterprise using one or combinations of the following interface strategies: a. DICOM interfaces to department PACS b. XDS-I.b interface infrastructure to support image acquisition from non-dicom sources because this is quickly becoming the standard approach to accessing non-dicom data objects from non- PACS repositories and workstations c. Automated query/retrieve from all repositories (every n seconds) for new studies and related priors d. Automated query/retrieve from all repositories of related priors triggered by the Order and/or Schedule associated with the new study 6. Cache Synchronization. The UniViewer requires an effective methodology for synching its working cache with the various department PACS, other department repositories and assorted workstations that will contribute the image data. This methodology must make certain that the UniViewer has the most recent version of the study data being managed by the various PACS / Repositories. There are a few effective approaches to this problem. a. A custom HL7 interface can be developed for each UniViewer/Repository combination that will facilitate the exchange of meta data updates between the systems b. A custom comparison methodology for image data updates can be developed for each UniViewer/ Repository combination. For example the UniViewer can be set up to automatically issue a C-Find command to each designated PACS to get from the PACS the metadata associated with a recent range of studies and compare that at the instance level against the metadata associated with the equivalent studies in the UniViewer to determine if the data in the cache is current. This examination is done when the user attempts to launch the exam c. Alternatively a query/retrieve command can be issued by the UniViewer to each designated PACS for patient data added to the PACS over some preset time frame (the most recent ten minutes, most recent hour, most recent day). The UniViewer then compares the return of this query to the version of the patient data already on the UniViewer. The UniViewer then automatically updates its cache with the latest copy of the data if it detected a new SOP instance UID was added to a series, or a new series instance UID was added to a study d. The IHE Radiology Technical Framework now contains a trial implementation of a synchronization methodology referred to as Imaging Object Change Management (IOCM). This protocol is being designed to simplify and facilitate the synching of two disparate data repositories through effective bi-directional communications of all sorts of changes in the metadata or the actual image data being managed by the two systems. IOCM is not yet a reality, but it will be the future approach to solving this problem, as systems begin to include the methodology 7. Customer-defined Relevant Prior Algorithm. The UniViewer requires a mechanism of its own to determine the relevance of historical studies to the

18 18 An Expedient Strategy for Image-Enabling an EHR new study. The test of relevance must span all of the imaging disciplines in the enterprise, something that most current department PACS cannot do. 8. Customer-defined, Flexible Purge/Retention Application. The UniViewer s Information Lifecycle Management application must support a purge/retention function to manage the contents of the short-term cache. This purge application would be applied to image data after n days or a predetermined high water mark, IF that data that can easily be retrieved back from the PACS/ Repositories if it is once again requested. The retention application would allow the UniViewer to maintain on the cache that data that is not being managed by another repository (i.e. transient images from mobile devices) and therefore cannot be retrieved. 9. Image Acquisition Appliance. The UniViewer will require an optional application or external appliance that would allow the UniViewer to acquire and ingest image data from multiple non-pacs sources. In the absence of the VNA, where else would this application come from? The ingestion process would include applying the appropriate metadata and associating it either with an Order or a Visit / Encounter in the EHR. This application could be an independent web-accessible application running on a PC or a Mac that gets its required metadata associated with the patient and study from the EHR. Some UniViewer vendors are heading down a path to launching the ingestion tool from the EHR and having the EHR pass patient / visit context to the ingestion tool so that the ingestion process can start with clean data. Regardless the approach, this acquisition process would be applicable to the following scenarios. a. Independent image sources. The methodology must support [1] acquiring digital still frame images and video clips from digital cameras and mobile devices, [2] accessing / creating PID (Patient ID), [3] associating PID with the image data, [4] forwarding the resultant study file to the UniViewer. There are numerous options for the nature of this study data file including DICOM wrapping or encapsulation, native object, and XDS-I.b. It is also important to specify that the methodology should allow the creation of a study that is completely comprised of the imported images. It should not be a requirement that these imported images be appended to an existing patient study as in many cases these images ARE the study in and of themselves b. CD / DVD based images. The methodology must support [1] acquiring the image data and reports from CD/DVD media forwarded from external organizations, referral groups, etc. [2] accessing / creating PID, [3] modifying/editing MRN and other basic DICOM tags (i.e. study descriptor) to insure compatibility, [4] associating PID with the image data, [5] forwarding the resultant study file to the UniViewer. This should include not just manual text entry but also provide the ability to match to existing patient identities in the VNA & EHR either as a patient identity lookup, which is most common, or matching to a specific Order as in the IHE IRWF workflow. This approach to image acquisition could easily lead to expansion of the UniViewer to include an image sharing solution for external studies and referral organizations 10. Multiple Avenues for User Access. The UniViewer must allow for multiple access points. First and foremost is access through the EHR and full support for the single-sign-on already supported by the EHR. A second access point would simply be direct access to the UniViewer by users authenticated by the appropriate AD/LDAP, where AD is the Microsoft Active Directory services database, and LDAP (Lightweight Directory Access Protocol) is the standard protocol you can use to talk to it or other user directory systems.

19 19 An Expedient Strategy for Image-Enabling an EHR A Suggested Strategy for Enterprise Image Management While the VNA is the ideal approach to creating a unified medical image repository, this paper presents the argument that the more urgent goal of image-enabling the EHR does not require the complexity or the cost of the VNA. A standalone UniViewer suitably configured and equipped to meet the requirements set forth in this paper is an expedient and relatively affordable strategy for giving the physicians access to the range of medical images being created across the enterprise. The UniViewer should in fact be an initial stage of an overall image management strategy for the enterprise.

20 20 An Expedient Strategy for Image-Enabling an EHR The Enterprise Image Management Strategy suggested here takes into account that the UniViewer is not designed to be, nor intended to be a VNA. It only functions as a tool to aggregate and visualize the patient s longitudinal Medical Image Record scattered across multiple department PACS, independent data repositories, and informal digital image collections, in the absence of a VNA. In some implementations, if the UniViewer is connected to an Enterprise Master Patient Index, the scope of the UniViewer might even be expanded to include a mechanism to gather the results (ingest exams) for all of the identities of a given patient from outside the enterprise. This optional functionality would blur or eliminate the line between Image Viewing and Image Sharing. The UniViewer s shortterm working cache, perhaps able to effectively manage as much as the most recent eighteen months of new studies and related priors is not typically designed for the scalability required to manage all of the enterprise image data over the lifetime of that data. Most importantly, the UniViewer does not possess the features and functions of the VNA that were listed above, and it therefore does not afford to the organization all of the benefits of the VNA. The UniViewer is simply the expedient approach to image-enabling the EHR, while the VNA is still the ultimate medical image data management solution for the enterprise. Deploying a standalone UniViewer with a local cache is a viable first step in the enterprises multi-step, Image Management Strategy. The end point of the strategy is the combined UniViewer / VNA configuration illustrated in Figure 6. UniViewer User s Display Figure 6 Image Cache UniViewer Servers URL Launch EMR Primary Data Center LAN PACS Format Converter VNA Non-PACS Sources Working Cache Informal Images Long-term Storage