The past decade has seen the rapid advance of radiology toward filmlessness, a transition that is occurring at a pace as rapid as the utilization of paperless transmission for patient information. The utility of the fully electronic medical record (EMR) is obvious. There are distinct advantages to the electronic approach to record keeping including decreased loss, costs, and turnaround time. The road to this goal, however, is paved with challenges, the largest with that of connection and integration. Many have solutions to this problem, in both the commercial and academic markets; however, what unifies all of these solutions is the necessity to adhere to conformation of several standards for both the transmission of textual (Health Level 7 [HL-7]) and image (Digital Imaging and Communications in Medicine [DICOM]) data. It is ultimately the integration of these two data sets that is clinically essential.?? The successful implementation of integration of radiological image data as an adjunct to the textual data contained within the patient’s electronic medical record can thus be achieved through the use of standard Internet protocols.
A fully functional departmental picture archiving and communications system (PACS) was installed in a component-based fashion at Massachusetts General Hospital (MGH) from 1996 through 1999. During the same 3-year time frame, the MGH Department of Information Sciences completed the creation of a clinical data repository (CDR) primarily for the purposes of electronic result reporting. The contents encompassed primarily text-based result data recorded by the various departmental information systems already in place throughout the enterprise. This data was made available to the thousands of affiliated physicians throughout the network on thousands of personal computers using the electronic patient record system.
Over the course of our PACS installation, it became apparent that the system began to possess more and more critical imaging data. As the EMR effort rolled out throughout the enterprise and gained widespread acceptance, the need became apparent for the radiology department to electronically deliver not only our legacy text-based report results, but also this critical image data. At that time, several methods of providing this necessary digital image transfer were investigated.
A series of SOLUTIONS
The first proposed solution involved the manipulation of image data in a similar fashion to textual data with the ability to archive to systems such as CDR for later clinical retrieval. This approach was quickly excluded for several reasons. The primary exclusion criteria revolved around the problem that current CDR technology was not capable of expanding to the massive data requirements of medical images.? Additionally, the engines behind CDR access applications had no mechanism for the display of medical image data on the client’s computer.
Due to the shortcomings of the first solution, a second solution was quickly explored. It was proposed that images could be easily identified due to a unique identifier (UID) in the DICOM header. This identifier would allow the EMR application to retrieve from the departmental PACS. When the images were too large to be contained on the CDR, the images could remain on the PACS, and through the use of DICOM UID pointers, the CDR could forward requests to the PACS. These images could then be displayed to the client through a viewer application within the EMR. Again, several issues prevented this approach. First, the existing network infrastructure (a variety of bandwidths ranging from 10Mbs shared to 100Mbs switched) could not support the potential thousands of requests for the transfer of minimally compressed medical image data (PACS 2:1 lossless JPEG). Second, the PACS could not support thousands of requests to its database server without serious performance degradation within the radiology department and at a cost to the work-flow efficiency of the radiologist. Finally, neither within the current iteration of the EMR client nor within the departmental PACS, did there exist a viewer application that was thin enough to execute on the thousands of enterprise-wide personal computers.
The elimination of these two options created the necessity to construct a new data repository, termed the Image Data Repository (IDR).
The MGH IDR
It was quickly decided that the IDR be an Internet-based system with the capability of DICOM communication that would include clinically acceptable images via a lossy image compression algorithm. It was preferred that the system would ultimately be expanded through a distributed architecture versus single focused expansion of a main server. As performance requirements were initially defined, it was apparent that subsecond image access for potentially several hundred simultaneous users would require powerful back-end hardware and software. Thus, it was determined that Windows NT 4.0 and IIS (Internet Information Server) were fully capable of delivering these performance requirements with excellent support and pricing.
Initially, the IDR application was executed using server hardware configurations from an Intel Pentium 90-MHz processor with 128MB of RAM and 40GB of Level V redundant array of inexpensive disks? (RAID), finally evolving into nine distributed Intel-based servers from various vendors. This scaled approach has allowed for increasing performance demands and takeing advantage of the decreasing cost of increasing computing power.
At its core, the IDR is essentially a relational database and Internet Web server. The system communicates with the PACS via DICOM and is set as a storage class provider (SCP) to receive all image data that the PACS receives from modalities. This image data is then wavelet compressed (at various compression ratios ranging from 10:1 to 20:1, depending on modality type) and stored in the database along with the DICOM header information (image type, series details, and UIDs) including medical record number (MRN), and accession numbers, which are received by the PACS from the radiology information system (RIS) during examination validation.
Prior to EMR integration, a stand-alone browser view application was written to support the decompression and display of this transmitted image data for clinical review. This application had been previously used as a viewer for physicians to receive medical image data on hospital-wide PCs distinct from the EMR application. Since the clinicians often were able to provide only medical record numbers or last names, a query mechanism was included in the browser application to search for image data on the basis of any one of these parameters. As the query mechanism became familiar to the user and its back end allowed searching through a very large image repository, it was this mechanism that was used to interface the existing text-based EMR to the IDR.
During the review of radiology textual data within the EMR, the system is provided with the MRN and the accession number of the patient’s examination being viewed. Using this information, the EMR with the IDR viewer is able to open a browser and populate with the associated images via a request to the IDR for the image data. The hypertext (HTTP) request is similar to the manual request sent by the radiology-only viewer (described above) to the IDR.
The Experience
Since the integration of the IDR client with the EMR in 1997, the IDR and EMR have served the MGH clinical community without major technical problems. The unlimited concurrent user access to image data has been occurring for several years and appears to be without serious limitation to the clinical needs. As with any installation of this magnitude, there are several challenges and exceptions to this smooth operation. These exceptions are as follows:
1. Missing Accession Number. Examinations often are performed without knowledge of the patient’s MRN (eg, trauma patients with no identification). The images of these examinations can enter the PACS prior to accurate MRN data and be retained there until the RIS assigns the appropriate accession number. The IDR application without the accession number,? however, is not capable of retrieving the necessary image data.
2. IDR Archive Limitations. As the majority of clinical data requested is usually the most recent studies performed within the institution, the image archive of the IDR has been limited to maintain compressed image data for approximately 6 months. Any information requested prior to 6 months from the current date is sent to another browser application that allows the user to request the data from the long-term PACS archive. As a request of this sort can often take extended lengths of time (depending on the current load on the PACS archive), the requesting user has the option to enter their pager number so they may be notified when the images are ready for viewing. During the initial implementation of this technology, it became apparent that the majority of requests were needed for conferences or clinical trials and often a bulk request with time delays of several minutes were acceptable.
3. Workstation Limitations. The addition of image display on thousands of end user workstations was without problems in a large portion of the installed user base within the enterprise. However, there were several PCs being used for clinical review that were limited in their display capabilities. On many of these workstations, certain video modes were not capable of displaying medical image data acceptably, and it was deemed that the decision regarding the quality of the display should be the responsibility of the IDR client. It was determined that if the machine’s video system was not capable of acceptable display, the images were not shown and a message was displayed instructing the user to contact the help desk for upgrade options.
Final Thoughts
The incorporation of medical images into the EMR has proven to be a critical effort for the successful deployment of PACS and the reduction of film consumption at Massachusetts General Hospital. During the past 5 years, the IDR system has adequately met the needs of clinical requests by both radiology-only users as well as users of the EMR. The system has reduced dramatically the need for film and concurrently provided a vehicle for display of images and text throughout the enterprise and beyond. n
Amit Mehta, MD, is medical director, Advanced Imaging Laboratory
