Int J CARS DOI 10.1007/s11548-014-1123-8

ORIGINAL ARTICLE

DICOM data migration for PACS transition: procedure and pitfalls Peter M. A. van Ooijen · Kadek Yota Aryanto · André Broekema · Steven Horii

Received: 3 July 2014 / Accepted: 14 October 2014 © CARS 2014

Abstract Purpose Transition from one Picture Archiving and Communication System (PACS) to the other is costly and disruptive. Especially the migration of the DICOM data from the legacy to the new PACS is a very challenging task, and although such a migration will happen in every hospital, literature on methodologies to follow and possible problems and pitfalls is scarce. The objective of this work is to provide insight in the prerequisites for the legacy PACS before starting the migration with respect to vendor and DICOM considerations. Methods The steps involved in migration, possible methodologies, and areas of specific interest when planning migration are given. Possible challenges and problems are defined as well as issues that are often overlooked. Results A step-wise approach should be implemented for data migration. Careful planning and testing, continuous observation of the process, and involvement of all stakeholders including the old and new vendors are crucial for a successful transition from one PACS to the other. Conclusion A proper test migration is a crucial step in the PACS transition process, which can eliminate many of the problems in the actual migration. However, with any migration, there has to be a willingness to take a limited amount P. M. A. van Ooijen (B) · A. Broekema Department of Radiology, EB45, University Medical Center Groningen, University of Groningen, Hanzeplein 1, 9713 GZ Groningen, The Netherlands e-mail: [email protected] P. M. A. van Ooijen · K. Y. Aryanto Department of Radiology, Center for Medical Imaging – North East Netherlands, University Medical Center Groningen, University of Groningen, Groningen, The Netherlands S. Horii Department of Radiology, University of Pennsylvania Medical Center, Philadelphia, PA, USA

of risk since not all problems can nor will be identified in the test migration.

Keywords PACS · Picture Archiving and Communication System · Radiology · Data migration

Introduction Being the core infrastructure of the radiology department, efficiency and availability of the Picture Archiving and Communication System (PACS) is of utmost importance. However, when in operation for some years with subsequent updates and upgrades, the demand for a new PACS environment tends to get more prominent, and although it is costly and disruptive, many institutions decide to part from their legacy PACS vendor and implement a new PACS. Main reasons are that the old PACS installed was radiology centered and not suitable for enterprise deployment and that the stateof-the-art PACSs include a higher level of workflow integration and not only support radiology but also, for example, cardiology. In most cases, the procedure followed will include a tender offer resulting in multiple bids from different vendors from which one vendor is ultimately chosen to implement the new PACS. This involves a major overhaul of hardware and software including the transition for the users to a new user interface and perhaps a new workflow. With this replacement, the old image data present in the legacy PACS must also be made available in the new environment. This can be done by maintaining the old PACS environment and retrieving data from that system upon request without actual transfer to the new PACS. Maintaining the old PACS has the downside that, although partly solvable by performing prefetching

123

Int J CARS

and autorouting of data, direct on-the-fly access to old data will always be slow compared to the data natively stored in the new PACS. Furthermore, the technical maintenance and support on the old PACS from the old vendor poses an extra cost on the available budget. Since two systems must be kept operational and up-to-date in hard- and software, the costs of running both systems in both money and manpower will be high. Still running the legacy PACS will also lead to problems with failing hardware that should be replaced requiring budget that should be preferably invested into the new PACS. Furthermore, maintaining a sufficient level and quality of service and maintenance from the legacy PACS vendor will be challenging part because of the most probably downgraded contracts and part because of the diminished involvement and loyalty of the legacy PACS vendor. Because of these obvious disadvantages, most hospitals will opt for a migration of the required history from the legacy PACS to the new PACS and dismantle and remove the old PACS altogether also removing the obsolete, nonmigrated, data contained in the old PACS. Therefore, in PACS transition, the correct and timely migration of the data from the current to the new PACS is one of the key success factors of the transition. However, the correct migration is also one of the major concerns [1] and can be a process of which the time required is often underestimated [2]. The time required is not only dictated by the actual transfer itself, but also because there will undoubtedly be errors that have to be handled and/or corrected. If the legacy PACS has to be kept operational until the replacement is installed and has sufficient historical data migrated so as to be clinically useful, the impact of the migration process on operation of the legacy PACS also has to be considered. Further, the Digital Imaging and Communications in Medicine (DICOM) interface may not always be optimal and information such as annotations, key images, and corrections of patient demographics may cause problems. Since the DICOM standard evolves over time, migration of the data from modalities stored in the old environment could cause problems due to the DICOM changes that were made. To increase complexity of the whole migration process, the legacy PACS must be migrated while maintaining full normal operation. This complexity could partly be reduced by using the redundancy present in the legacy PACS to perform the migration, e.g., by using the backup system. Despite all these issues with data migration, only very few publications on the topic of PACS data migration that provide either the theoretical background or the practical experience [1–5] are available. General advice is to carefully prepare a migration plan that is tailored to the local situation of the individual hospital [1]. Although the general conception is that the data migration is one of the most difficult parts of the PACS transition, the published literature is scarce. This paper provides a proposal

123

for a migration methodology along with possible problems and challenges that can occur during the migration of data from one PACS to another.

Staffing issues To plan a PACS migration, the planning committee should be a multidisciplinary team composed of radiologists, technicians, relevant other physicians, PACS administrators, and IT staff. Besides this, people with knowledge about legal issues and risk management should also be involved. This planning committee should determine the scope of the PACS migration project and make decisions on critical issues such as the amount of data to be transferred and how to handle data cleanup. The migration to a new PACS can be as complicated or even more complicated than the deployment of the original PACS. Therefore, knowledge is required and should be made available with respect to resources in several areas including networking, database migration, project management, archives, DICOM, and HL-7. If local or new PACS vendor personnel do not have the requisite expertise, this is a good argument for including a migration provider in the initial planning. If this decision is made, ideally, it should be part of the contract negotiations with the new PACS vendor, so that the cost of employing a migration provider is not a “surprise” later (more on a migration provider in the next section). If your own personnel are responsible for the technical and operational aspects of the migration process, it may require work beyond their normal hours or tasks. If so, there may be additional labor costs involved for overtime and this should be included in new PACS implementation costs.

Prerequisites legacy PACS solution overview: vendor and DICOM considerations First, the full cooperation of the legacy PACS vendor is essential to maintain the system in operation throughout the migration process, to provide requested information and databases concerning the legacy PACS, and to assist in resolving issues concerning the migration. Although DICOM is the standard for the image file format and the communication of those images, the underlying database structure within the PACS that actually manages the system is not dictated by the DICOM standard. The implementation of this managing database is left to the individual vendor, and thus, a wide variety of different, more or less proprietary, systems are used. For example, many vendors take apart the DICOM data and store it in a proprietary format, or store the DICOM data but record changes, annotations, and

Int J CARS

measurement in the database merging the information only during DICOM export of the images from the PACS. The most prominent technical prerequisite for the legacy PACS is the proper implementation of DICOM both for the file storage and for the transfer protocol [3]. More specifically, the old PACS environment should conform to at least the ability to perform a database search and move of image data based on the DICOM standard (DICOM C-FIND and C-MOVE services as an SCP (Service Class Provider)). This DICOM capability should be provided by the old PACS throughout the migration project in order to allow the full transfer of the required imaging data. The PACS query mechanism (C-FIND) should support queries on study data using range matching and at least return the complete list of studies that meet the query criteria. PACS might have a limited number of possible replies under normal operation conditions to avoid data overload to users that accidentally query large amounts of data. Therefore, if so configured, this limitation should be removed for the migration. During the transfer of the DICOM image data (C-STORE) in response to a DICOM image data move request (CMOVE), the legacy PACS should return meaningful status codes and a full unique identifier (UID) list when failures occur. Another important issue is the maximum number of threads for DICOM image data transfer (C-MOVE/C-STORE) allowed and configured by the old PACS. This number of threads defines the number of DICOM image data transfers that can run in parallel. Prior to the migration, it is advised to configure the old PACS to the maximum number of threads to allow fast transfer of data. The availability of the legacy PACS for data migration should be determined. If the PACS is used clinically 24 h by 7 days per week (24 × 7), then the impact of the migration process on operation should be fully evaluated and, at best, tested since migration will typically slow down PACS operation. If the legacy PACS is not used 24 × 7, then the timing and duration of idle periods should be fully reviewed with the new PACS vendor (or the migration provider). In either case, availability of the legacy PACS for the migration process will directly affect the time it will take to migrate the information in the current system. A common error made by the new PACS vendor is that the migration process can use the legacy PACS full time. This assumption may result in a serious underestimate of the time required for migration. If, due to functional or technical issues, the DICOM query of the data is impossible, full information about the database (typically, but not exclusively, SQL) of the legacy PACS should be obtained to determine database connection, data syntax, and data semantics to allow transition to the new PACS environment.

To ensure the correct transfer of possible changes to images made in the legacy PACS, it should support DICOM Presentation State. It could be beneficial to compare the DICOM conformance statements of both the current and the new PACS. These DICOM conformance statements will provide information about the capabilities with respect to storage and communication of DICOM images. This can help to determine the overlap in supported DICOM functionality and to identify possible caveats of missing functionality in one of the systems causing the data exchange from legacy to new PACS to fail.

Migration steps and methodologies The whole migration process should be prepared carefully and thoroughly investigated with regards to required time, manpower, and equipment resources [1]. In some cases, dedicated migration software tools are provided or created by either one of the PACS vendors (mostly the new one), the hospital [1,4], or third parties. These software tools usually also tackle (part of) the data cleansing and correction functions. Figure 1 shows a typical setup for a migration using a dedicated migration tool. The following steps are most commonly defined in the migration protocol (Fig. 2): Phase 1 Preparation phase The preparation phase contains a number of sub-phases: Phase 1.1 Determining the scope of the migration In this step, it has to be determined what data should be transferred; further, the possible “cleanup” of data should be determined. This requires defining methods and rules as to how to determine which data are obsolete or incorrect and thus should be removed or corrected during the data transfer. Analysis of legacy PACS stored information may also require an investigation of the archived data to estimate how much of the data will need cleanup. This investigation should be more than a projection based on analysis of the DICOM metadata and database tables and should involve at least a sample of the existing archived information. Phase 1.2 Hardware setup In this step, technical tasks such as implementation and installation of the required hard- and software as well as configuration and testing of the connectivity have to be done. It is important that interfaces to other systems (the RIS, HIS, reporting, electronic medical record (EMR),

123

Int J CARS

Fig. 1 Standard setup for a migration using a dedicated migration tool. The migration tool will retrieve nonpixel data (metadata) from the old PACS and validate the nonpixel data with the content of the RIS. After validation, correct studies are sent to the new PACS by instructing the old PACS to perform a DICOM send of those studies, and incorrect data are registered and possibly transferred to a “garbage bin” (or “dead

letter” file) that could be searched for any studies found to be missing at some later time. The RIS can also be used to retrieve reports for inclusion in the new PACS environment. Within the migration tool, rule-based exclusion can be configured to transfer certain data to the garbage bin (e.g., test patient and research related data)

Fig. 2 Phases of the migration process. Phases 1.1 should be the first step after which 1.2 and 1.3 can be performed in parallel

123

Int J CARS

etc.) have to be tested as well, not just the DICOM interfaces to imaging equipment. Phase 1.3 Analysis of the migration process Impact analysis and planning of the migration process should be determined. This also includes transfer speed benchmarking to determine how fast the data migration can be completed and should factor in availability of the archive of the legacy PACS. The migration plan should result from the preparation and should contain information on how the migration will be performed, what kind of monitoring and validation will be done, and the responsibilities of the parties involved (current and new PACS vendors and, if employed, a migration service provider). It should also include how the reporting on progress, any schedule changes, and problems should be done. Phase 2 Test migration phase A test migration is used to identify possible problems that could occur during migration and to configure and adjust the migration plan and data cleanup protocol. Possible problems should be fixed in this phase and the migration tested again to ensure they will not occur during the actual migration. Phase 3 Migration phase This involves installation and configuration of possible migration tools and the actual data cleanup and migration. During the whole process, monitoring and quality assurance should be executed resulting in periodic reports on the migration results. The frequency and nature (electronic, Web, or paper) of the reports as well as their content (for example, total volume and percentage migrated, number of problem studies fixed, and number of studies sent to the garbage bin or dead letter file) should be negotiated with the new PACS vendor and migration provider (if employed). During this migration phase, hard- and software belonging to the legacy PACS that is no longer required can be shutdown and removed. Phase 4 Validation phase In this step, a final evaluation of the validity of the data in the new PACS environment should be performed to determine correctness and completeness of the data received and to provide final acceptance of the data cleanup and migration. There are two common ways of performing a DICOM migration. First, the DICOM data are transferred from the old to the new PACS by DICOM send. A large amount (a typical recommendation being 1–2 years [6]) of the previous study data has to be transferred before the new PACS is used to ensure that most of the requested data will be available in the new PACS at startup. At that point in time, the new PACS will be in use and data transfer will commence in the

background. Ad hoc queries of data not available yet in the new PACS should be possible. Another strategy involves the building of the whole database in the new PACS by DICOM queries to the old PACS getting all nonpixel data into the new PACS’s database. After this, the transfer of the pixel data is started. Again, it is preferable that at least 1–2 years of image data are available on the new system [6]. This initial startup data volume could be estimated by an analysis of requests for prior studies in the legacy PACS; a startup volume that satisfies at least 80–90 % of the requests for prior studies is likely to be satisfactory. If possible, the migration process should accommodate ad hoc requests for prior studies and should a request be in the 10–20 % of the studies not included in the startup migrated volume. This is especially essential for the emergency department and a dedicated procedure should be in place to transfer data from the legacy PACS to the new PACS with the highest priority in case they are required for evaluation of an emergency patient. In both strategies, it is important to realize that most PACSs make demographic and other changes only in the database and not in the DICOM header of the corresponding image data. Therefore, either way the information contained in the database of the legacy PACS should be included into the new database. This can be done either by querying the legacy PACS through the database, thus receiving the updates with the DICOM transfer or by re-applying all changes to the new database by retrieving them from change messages and logs. Careful evaluation is required to assure that all database contained information is indeed transferred to the new environment. Because of these database issues, some vendors or specialized migration companies will not use a DICOM-based approach but a database approach. When the database scheme of both the legacy PACS and the new PACS are known, a conversion of the legacy database to the new PACS could be performed. After this conversion, DICOM files can be transferred to the new PACS including renaming and rearrangement of directories as required by the new PACS. Finally, the pointers to the files in the new database are updated to point to the copies DICOM files. This option is worthwhile to explore since it could significantly speed up the migration process. However, it requires an in-depth knowledge of the database structure of both PACSs which could be difficult to obtain, especially from the legacy PACS vendor.

Involving the RIS To ensure the correctness of data, the information contained in the RIS could be involved in the data migration process. The information in the RIS, which is the original data entry point in many installations, could be used for validation of the

123

Int J CARS

data migration. Using the historic information from the RIS, the new PACS can obtain information about all studies registered in the HIS or RIS and compare this list to the retrieved information from the PACS. This can be used to perform the validation of the received data, to complement missing information from the PACS, and to determine incorrect and obsolete studies for data cleanup. Another way to employ the RIS that could speed up the transition to the new PACS with lower migration progress is to use a DICOM Modality Worklist (DMWL) to determine the patients that are scheduled for examination in the coming days and to migrate data related to these patients with the highest priority. By doing so, relevant priors will always be readily available in the new PACS for the scheduled patients, and thus, less historical migration has to be done subsequently. The historical migration of data from the old PACS can be done in the background with the new PACS already fully operable. As noted, this could include an initial startup migration volume together with the DMWL and ad hoc requests also accommodated. Reporting During the migration process, continuous reporting of the status of the data migration process is crucial since it is a critical time line in the whole PACS migration project. From the data migration, a final report should be made containing information about both the number of studies that are successfully migrated and the number of studies that are not successfully migrated. For each failure, the reason for failure and a possible solution or work-around should be defined. Possible problems and challenges Very common problems that occur during the migration are due to a difference in interpretation of the DICOM standard by different vendors [7]. Although the different interpretations may be valid according to the DICOM standard, they may complicate correct data migration or even successful connection between the two PACS vendors. An example in this is the use of proprietary fields that contain vendorspecific information that can be essential to the functioning of the current PACS or even hampering efficient operation of the new PACS. Other examples are the different interpretation of how to store measurements and annotations into the PACS and the use of other file types encapsulated into DICOM ‘containers’ possibly resulting in DICOM files that can be received and stored into the new PACS environment but are not interpretable by the viewing workstations of the new PACS. Another of the challenges of an image data migration is the availability of old image data on either online or off-line

123

media involving tape, magneto-optical disk (MOD), compact disk (CD), and DVD [2,8]. In some cases, very old data on off-line media are proprietary and with current hardware (e.g., MOD) or calculated time to migrate are very long [9]. When media are still accessible, the question arises if all DICOM data included on those media can still be read and copied into the new PACS since previous publications show that off-line stored digital media might include defects hampering the proper transition of the data even if medical grade media were used [8]. Furthermore, transferring data from older online storage (e.g., tape robots) or off-line media can be quite time-consuming and as such a limiting factor in the time required for transfer of all available data [3]. Especially in the case of off-line stored media, manual actions will be required to manage the media which can be very timeconsuming and costly since this might require someone to load new media on a daily basis for a long period of time. In such cases, one should carefully consider if the old data contained on the off-line media are still relevant and if making it available in the new PACS is still worth the effort. Another approach could be to only retain the knowledge of the existence of the data, for example, by making the corresponding database entries and only uploading data upon request. From the test migration, several issues may arise that hamper the proper migration of the image data from one PACS to the other. These issues need to be solved before the actual migration starts. If this is not strictly discussed with the current and future PACS vendors, this could be a significant delay in the whole PACS transition process. The final responsibility for solving the problems should be assigned to one of the parties involved, and both PACS vendors should address sufficient resources to solve the issues and/or define workarounds as quickly as possible. An advantage of a migration provider is that such a vendor can be an “honest broker” when it comes to resolve migration problems and reduce delays that could result from disagreements between the PACS vendors. This is particularly true if the cost of the migration provider’s services is determined by a separate contract and not bundled with the contract for the new PACS vendor. When performing a test migration, there are a number of issues that deserve special attention to avoid problems in the actual migration. These issues are the transition of measurements and other overlays, the correct transition of patient IDs, and proper filling of DICOM header tags to support display protocols of the new PACS. To allow identification of as much of the issues as possible, a wide variety of studies from different modalities throughout the PACS history should be checked technically and visually. Although there are initiatives to achieve standardization of image markup such as DICOM Structured Report and Annotated Image Markup (AIM), not many vendors support this for their markup and measurements but use proprietary solutions.

Int J CARS

Going live with the new PACS is possible when access can be guaranteed to the historical data. This can be done by performing a full migration before going live but a more preferable solution is to start migration, go live after having about 1–2 years available on the new PACS [6], keep on migrating the old data 24 × 7 (or as feasible based on operational schedule and performance degradation during migration), and provide advanced prefetching capabilities to ensure the availability of the old data from the patients that are scanned during a return visit. This prefetching can be done based on the schedule of patient from the DICOM Modality Worklist, if available old data from each patient scheduled for radiology in the next 2 days will be migrated with priority to ensure availability. However, this does not cover the walkin and emergency patients. For those patients, an active on demand retrieval from the old PACS should be possible. Defining what data to include in the data cleanup is difficult. Basically, the data cleanup concerns three categories. The first category is the data that are obsolete (garbage) such as test images. The second category is the data that cannot be identified properly because of incorrect patient IDs and/or accession numbers. The third category is data that are regarded to be bad because they are using incorrect or unsupported SOP classes or corrupted or invalid DICOM header information. It is likely that in each migration, all three categories will be present and need to be dealt with. The problem surrounding data cleanup is what to do with the rejected data. Test images can easily be discarded, but data with improper identification or bad data have to be handled somehow. Are these data simply discarded? Fixed? or Saved in a separate storage where they can be found and accessed when needed? These decisions need to be made based on the numbers of such studies, their age, and what the local facility legal department (risk management) may require. Studies that are past the time of required retention can likely be discarded. Sites have taken another approach of creating a folder for these that can be searched if necessary, but are not included in the new PACS normal retrieval process. When planning the cleanup of data, it is very important to realize that most cleanup is manual, time-consuming, labor and thus could require up to multiple full-time jobs to perform this task. Even though the benchmarking is performed to determine the migration speed, this still remains a problem and should be monitored constantly over the whole migration. At each point in time, either the old or the new PACS will be in daily operation and thus unable to dedicate all resources to the migration. Therefore, migration speed will depend on the overcapacity in both the old and new PACS and the moment of switching to the new PACS for daily operation. When doing so enough, history should be available on the new PACS to avoid the retrieval on demand from the old PACS as much as possible.

Considerations Although transition to a new PACS vendor can be a necessity, it has to be kept in mind that migration costs and the lifespan of the new PACS should be taken into account. Although the transition to the new PACS should result in improvements, the fact that new solutions tend to bring new problems cannot be ignored. In 1998, Behlen [10] already reported a net cost of about USD $230,000 for DICOM data migration of 10.09 TB from a legacy PACS archive. Although he projected a migration duration of multiple years which is not the current standard, with the enormous increase of data production since then caused by increase in imaging in general and the introduction of new modalities [11], it can be perceived that the costs for migrating data from one PACS to the other will be significantly higher. This especially holds when cost of migration is based on either number of studies migrated or volume of data migrated. In such cases, decisions on data cleansing in the PACS transition process could also partly be cost-driven since using a more strict approach to data cleansing could reduce the amount of data to be transferred from the legacy PACS and thus the cost involved. When deciding upon a new PACS, it is also advised to make sure it is flexible and open and allows easy migration when it is replaced sometime in the future. When the transition to another PACS is made, this can also have a major impact on the whole enterprise and not only on the radiology department. This might hold for the situation where the transition to another PACS requires the transition to another DICOM image viewer embedded into the Electronic Health Record (EHR) or the necessity to properly connect the DICOM image viewer of the EHR vendor to the new PACS database. Another issue that might influence the entire enterprise is the shift to a centralized enterprise PACS instead of having PACS solutions at different departments. This transition adds a whole new dimension to the migration when not only the old radiology PACS has to be migrated to the new environment but also other PACS solutions have to be integrated into the new PACS. Every additional PACS added to this equation introduces new challenges, complexity, and requirement for data validation. It is therefore wise to first migrate the large bulk of data from radiology and subsequently start adding other environments one by one. A test migration is an essential step in the migration process. Conducting such a test migration does take a considerable amount of time and other resources, but can save a lot of time, stress, and negative experience of the users in the new PACS environment since most of the critical problems should already be identified during the test migration. Between the test migration and the actual migration, enough time should be available to allow the current and new PACS vendor to solve the issues found in order to avoid these during the actual migration.

123

Int J CARS

Migration requires a lot of human effort in both implementation and validation/verification. This means in most cases that key users and PACS admins are reallocated to the migration project and not available for other tasks thus laying a heavy burden on the normal PACS operation during the migration time. Therefore, the moment of going live with the new PACS requires careful consideration to determine the optimal switch-over time. A possible method to reduce the amount of data to be migrated and thus the migration time and cost could be to decide to only migrate data less than n years old, where n is the legal storage requirement. The possible pitfall would be that some data could be required to be kept on the legacy PACS archive longer which increases the complexity of the migration rules and could even be a serious delay in the migration process. A way to avoid many of the problems associated with the PACS data migration is to already make a “prenuptial agreement” with the new PACS vendor when buying the PACS. However, what to include in such an agreement can be difficult to decide upon by both customer and vendor. In the future, this could be tackled by having a Integrating the Healthcare Enterprise (IHE) profile covering the requirements for PACS data migration. A brief proposal entitled “Radiology Data Migration” dated October 2012 can be found on the IHE Wiki [12]. However, it is not clear when this will be included in the roadmap and formed into a definitive IHE profile, until then mutual agreement between vendor and customer should be made to ensure PACS data migration. A technical development that could reduce the challenges with PACS data migration in the future is the transition to the use of Vendor Neutral Archives (VNA) as a more independent storage layer that is not necessarily tied directly to the vendor of the PACS [13]. Although a VNA is still tied to the legacy PACS, the new PACS would not require a new storage but utilize the same storage layer. However, in this case, the problems related to the database transition from one PACS to the other still remains.

Some potentially overlooked problems Operating two PACS in parallel (the current and new ones) has a number of requirements beyond just the updating, maintenance, and service of the systems. It may be possible to run the old and new workstation software on the same workstations, but if not, and if the new system is to be operated during the migration process, then accommodations for two sets of PACS hardware will have to be made. There will need to be additional network drops and possibly additional routers and switches installed. Not only for the new PACS but changes might also be required for the legacy PACS environment when available network band-

123

width becomes the limiting factor during the migration process. To identify possible bottlenecks in the network such as latencies and bandwidth utilization at different days and times, transfer speed benchmarking should be performed. Such a benchmark not only identifies possible bottlenecks but could also help in avoiding over utilization of the network by strategically planning the migration. In the computer room, space for the new PACS server has to be available along with sufficient power for it. The power has to be, as for the legacy PACS, uninterruptible. With respect to storage, the legacy PACS is operating with—possibly multiple—storage environments that are in most cases gradually expanded and thus contain storage parts of different age and size. Some of these storage systems could still have useful life left and are not economically depreciated yet. Furthermore, these still useful storage systems are most probably the most recently acquired ones and thus will also contain the most recent and thus most important imaging data. Transferring all data from the legacy to the new PACS requires an equal amount of storage in both systems. Therefore, having to duplicate all data could become very costly and very inefficient. Possible solutions could be to limit the amount of data being transferred by throwing away the oldest, no longer required, data or by planning the data migration such that the most recent data are first transferred to the new PACS after which the most recently purchased storage from the legacy PACS could be reused in the new PACS to store less recent imaging data. For example, if a facility has 150 TB of legacy data stored, it could be that 50–100 TB of that storage still has useful life. If the facility purchases only 50 TB of storage to accommodate migrated data, then that facility could migrate the first 50 TB of data, incorporate those 50 TB into the new PACS, move the next 50 TB, and then repeat that process. In the end, this means that the facility purchases only 50 TB of new storage rather than 150 TB of storage. That can be substantial savings for the facility but it requires a lot of careful planning to achieve that goal. In the reading room, furniture may need to be provided for the new workstations alongside the old if the new workstations cannot run both current and new software. If additional workstations are needed, it may not be possible to accommodate them in existing reading rooms. This means that additional space, at least on a temporary basis, needs to be allocated. If more workstations are to be used, the furniture requirement may be temporary (unless an overall increase in the number of workstations for the new PACS is planned). Leasing, rather than purchasing, such furniture is an alternative. Challenges can also arise for the PACS users when the legacy PACS and new PACS are running in parallel during a migration period. It can be difficult for users to find data across two systems (i.e., not realizing that relevant prior stud-

Int J CARS

ies exist on the legacy system that have not been migrated yet) and potential legal or risk issues associated with available data being overlooked. During its lifetime, a PACS tends to become ‘polluted’ with data that does not belong inside the PACS. Examples are research studies, outside data brought into the hospital on CD and imported into the PACS without proper validation, quality control examinations, etc. During a PACS migration, one of the considerations should be whether to include these examinations into the migration or not. By removing these studies from the migration, extensive data cleansing can be achieved. Pollution of the data could also arise from the fact that the legacy PACS, although setup as a radiology centric PACS, is used to also store DICOM images originating from other departments (e.g., cardiology or nuclear medicine). However, if no constraints are defined for this storage to standardize the image metadata (e.g., accession number, patient ID), reconciliation of this data can be a considerable challenge. Therefore, this data originating outside radiology should also be tested extensively as a separate group in the test migration. Besides the pollution, differences in data can also be caused by the natural process of replacement, updates and upgrades. When imaging equipment changes due to replacement, updates, or upgrades, things such as the study descriptions used, modality type, could also change. Therefore, planning for data migration also requires a detailed analysis of the history of the legacy PACS about what modalities have been in operation over the years to be migrated and how they were configured. Another cause of differences in data can be lack of standardization causing different equipment of the same modality type to use different descriptions and ID for the same examination or critical information to be entered manually. If such data exist in the legacy PACS, it is important to identify possible problems and to either correct them or adjust the new PACS to facilitate the differences. Failing to identify the pollution and differences described above could cause the new PACS be configured in a suboptimal way and thus performing below the expectations. Such a situation could be fatal for the whole process of migration and acceptation of a new system by the users. Since it is not part of the primary workflow, the teaching file collected on the legacy PACS is also often overlooked when planning a PACS migration. However, in many cases, teaching files integrated into the PACS are constructed using proprietary methods and tools and not standardized. Therefore, in most migration projects, the teaching file is either lost and has to be built up in the new PACS from scratch. A manual copy of all information from the legacy PACS teaching file into the new PACS is also an option, but very time-consuming and error prone.

Finally, there are disposal costs for computer hardware. Because of the materials used in workstation components, particularly if the legacy PACS workstations use cathode ray tube monitors, are considered environmental hazards in some countries, there are fees involved in disposing of the old hardware. Also, since any disk drives in the workstations may contain patient personal information (referred to as “protected health information”, or PHI, in the USA) those drives may require separate disposal steps that ensure that no data can be retrieved from them. In some instances, the legacy PACS provider, or third-party specialty recyclers, may offer a recycling service for the old hardware, though this is likely to have a cost associated with it.

Conclusion PACS migration is a very difficult and challenging process that involves many stakeholders including radiologists, IT staff, business office, and vendors. The only way to achieve the migration of the old DICOM data into the new PACS in a reasonable amount of time is with careful planning and continuous observation of the process. A proper test migration is a crucial step in this process which can eliminate many of the problems in the actual migration. However, with any migration, there has to be a willingness to take a limited amount of risk since not all problems can nor will be identified in the test migration. Conflict of interest None of the authors have conflicts of interest to report with respect to the content of this manuscript.

References 1. Jung H, Kim H-J, Kang W-S et al (2004) Migration of medical image data archived using mini-PACS to full-PACS. J Digit Imaging 17(2):100–108 2. Maass M, Kosonen M, Kormano M (2001) Radiological image data migration: practical experience and comparison of the costs of work. Acta Radiol 42:426–429 3. Behlen FM, Sayre RS, Weldy JB, Michael JS (2000) “Permanent” records: experience with Data Migration in Radiology Information System and Picture Archiving and Communication System replacement. J Digit Imaging 13(2):171–174 4. Siriapisith T, Tongdee T (2008) The new effective tool for data migration from old PACS (Rogan) to new PACS (Fuji Synapse) with integrated Thai patient names. J Med Assoc Thai 91(4):520– 526 5. Davies AR (2007) PACS replacement: the perils and pitfalls of upgrading PACS hardware and software. IJCARS 2(suppl.1):S508–S512 6. Wirth S, Treitl M, Mueller-Lisse U-G, Rieger J, Mittermaier I, Pfeifer K-J, Reiser M (2006) Hard disk online chaches in Picture Archiving and Communication Systems: How big is beautiful? Eur Radiol 16:1847–1853

123

Int J CARS 7. Behlen F, Costea-Barlutiu R, Sluis D (2013) An unexamined assumption is not worth assuming: imaging data quality exposed in data migration. IJCARS 8(suppl. 1):S68–S69 8. van Ooijen PM, Viddeleer AR, Meijer F, Oudkerk M (2010) Accessibility of data backup on CD-R after 8 to 11 years. J Digit Imaging 23(1):95–99 9. Baune D, Bookman G (1999) Migration from hierarchal storage management to ASMTM storage server: a case study. J Digit Imaging 12((2)Suppl 1):75–77 10. Behlen FM (1998) A DICOM document-oriented approach to PACS infrastructure. J Digit Imaging 11((3)Suppl 1):35–38 11. van Ooijen PM, Bongaerts AH, Witkamp R, Wijker A, Tukker W, Oudkerk M (2004) Multi-detector computed tomography and

123

3-dimensional imaging in a multi-vendor picture archiving and communications system (PACS) environment. Acad Radiol 11(6):649–660 12. Harvey D (2013) Radiology data migration: brief proposal. IHE Wiki, October 7, 2012. http://wiki.ihe.net/index.php? title=Radiology_Data_Migration_-_Brief_Proposalon. Accessed 21 March 2013 13. Hagland M (2013) Strategic radiology systems implementation. Challenges and benefits of moving to a vendor-neutral archive. Healthcare Inf 30(1):48–50