Purpose We report on our experience in extending the PACS of our university hospital to a number of other hospitals and on migrating from the legacy systems. All PACS servers and storage are pooled in the central location. A number of hospitals, with in total about 6,000 beds, want to cooperate closely to optimize care for a considerable portion of the Flemish population. It is considered essential for this cooperation to use one single electronic medical record. All hospitals are therefore migrating to the central EMR and RIS hosted at the university hospital. It is not considered essential to replace ancillary systems such as the PACS in each hospital with a central system. It can be beneficial to do so, however. One motivation to use a single PACS is that it becomes much easier to share images between the partners. Another motivation is the cost-quality ratio. There are obvious economies of scale for the central systems such as storage and servers. Less obvious but even more important is that economies of scale also apply to the expertise needed to set up the system and support it, and to the implementation of all kinds of solutions such as for secure image transfer over the Internet, hospital-wide import of images from CDs, or Internet access to diagnostic images. Methods Our first experience was with extending our PACS (Agfa Impax) to a 200 bed secondary care hospital located 30 km away. There was no hospital-wide PACS at that site. Wide area connection is using a leased (dark) fiber. The PACS was introduced in that hospital together with the RIS and the EMR. A more recent experience was with migrating a 850 bed hospital that during the previous decade operated a radiology and a cardiology PACS by a different vendor. The distance to this hospital is about 50 km. The wide area connection to the central PACS is over a private network (leased bandwidth from a telecom provider). A first challenge in this project was migrating 1.7 million historic imaging exams. This was accomplished by making a copy of the legacy database (of which we knew the structure) so images could be fetched and decompressed by our own software without slowing down routine operations on the legacy PACS. The images were transmitted by a batch of DICOM processes to the central PACS that imported them while in full operation. At night we allowed network traffic to go up to several hundreds of megabits per second. About 40 Terabytes of images could be transferred in a few weeks. A second challenge in this project was that we wanted to already switch that hospital to the central PACS before the migration to the central RIS could be completed. It was therefore decided to temporarily interface the central PACS to the legacy RIS and during that period to continue using the legacy patient IDs. The central PACS was thus interfaced to the central RIS/EMR as well as to the legacy RIS/EMR of the other hospital. A third challenge was the subsequent transition to the central RIS/EMR, which includes changing the patient IDs of the imaging exams in the PACS from the legacy IDs to the IDs of the university hospital’s RIS/EMR. The radiologist must perceive a PACS that is fully integrated in the legacy RIS before the weekend but fully integrated in the new RIS after the weekend. The images now indexed with the new IDs must still be accessible from the legacy EMR using old patient IDs, however. The fact that the cardiology information system is not migrated at the same time but is nonetheless affected by the change in patient IDs in the PACS, makes this exercise even more interesting. We have recently started the migration to the central PACS of a 400 bed hospital located about 80 km away. The current PACS, by yet another vendor, is relatively recent and operating to satisfaction but will be replaced to ease medical cooperation and to benefit from economies of scale. The migration of that PACS will also be performed before the migration of the RIS, but many departments that also store images in that PACS have already started to use the central EMR. Results A recurring concern by physicians in first discussions is that images would appear slower on the screen if they have to come from a system located tens of kilometers away. We did not experience any problem in this respect. In fact, bandwidth monitoring suggests that the current connection speed of about a gigabit/s to the larger hospital is more than needed. So far we did not extend the servers of the central PACS. Migrating the historic images went smoother than originally feared. We believe that migrating to a new local system by a different vendor would not have been easier then migrating to the central PACS, given the wealth of experience and expertise we could share in our migration project. During the transition period in which the legacy RIS was still used, we stored the images in the central PACS using the legacy patient IDs. Ultimately there will be one single ID for the same physical patient as only in this way all images of that patient are easily accessible regardless in which hospital they were acquired. Using legacy IDs in the central PACS had additional drawbacks, however, which we had to work around. If a patient presents at the university hospital with a DICOM CD from the partner hospital, the images on that CD are not directly visible from the EMR even if they are already in the PACS because the patient ID is different—but importing that CD into the PACS does not work either as the images are already in the system. Importing the images from the other hospital using the legacy patient IDs enabled us to rapidly migrate radiology, but subsequent migration to the common IDs is far from trivial as the different departmental information systems in that hospital (radiology, cardiology, gynecology,...) do not all migrate at the same time to the central system and to common IDs. In the current migration projects we tend to immediately convert images to the central patient ID.