Migration Services

Migration Services

If you think you need migration services, you can contact us on this website or e-mail us at sales@dejarnette.com.  We use MDIG4, our latest migration engine that employs the XOE interface engine to speed our migrations. Depending on the vendor of your source PACS, DeJarnette employs one of two models to migrate your data.

 

Inline DICOM

Inline DICOM migration issues DICOM C-Move requests into the source PACS configured with a XOE listener as the target. It supports pre-fetch in the sense that prior studies for a current order are preferentially migrated. Inline DICOM migration follows these steps:

  1. MDIG4 periodically issues a DICOM Modality worklist C-Find query into the target PACS. In this way, the target PACS can be clinically operational while the migration is in progress. For every order in the worklist, it searches the migration queue for prior studies and raises their migration priority.
  2. MDIG4 searches the migration queue for the next study to migrate. Normally the migration queue is sorted in reverse study date order so that more recent studies are migrated before older studies. We can break the migration queue into contexts and migrate one, some or all the contexts at any one time. We can tune the migration performance for each context using what we call retrieval schedules. MDIG4 takes into account a study’s migration priority. So, the next study is either a prior study or the next study within the designated context.
  3. The source PACS receives the third-party C-Move request and moves the requested study to the XOE listener using DICOM C-Store.
  4. The XOE listener receives each image within the study, corrects the DICOM tags within the image using information matched to data from the RIS, and sends the image to the target PACS using DICOM C-Store. All the processing is performed in line for better performance.

 

Inline DICOM migration model

 

Inline Media

Inline Media migration issues DICOM C-Move requests into a XOE listener. XOE subsequently issues file copy requests into the source PACS. It can only do this if the images are stored on the source PACS in a non-proprietary format and we have read-only access to the PACS database. It supports pre-fetch in the sense that prior studies for a current order are preferentially migrated. Inline Media migration follows these steps:

  1. MDIG4 periodically issues a DICOM Modality worklist C-Find query into the target PACS. In this way, the target PACS can be clinically operational while the migration is in progress. For every order in the worklist, it searches the migration queue for prior studies and raises their migration priority.
  2. MDIG4 searches the migration queue for the next study to migrate. Normally the migration queue is sorted in reverse study date order so that more recent studies are migrated before older studies. We can break the migration queue into contexts and migrate one, some or all the contexts at any one time. We can tune the migration performance for each context using what we call retrieval schedules. MDIG4 takes into account a study’s migration priority. So, the next study is either a prior study or the next study within the designated context.
  3. The XOE listener receives each C-Move request, gets the file names of the images from the PACS database, and using CIFS or NFS, reads each image file in the requested study directly from the source PACS archive.
  4. The XOE listener corrects the DICOM tags within the image using information matched to data from the RIS and sends the image to the target PACS using DICOM C-Store. All the processing is performed in line for better performance.

Inline Media migration model

 

Data migration is not always the most cost effective way to gain access to your archives. In some situations, it might be better to deploy DICOM gateways with pre-fetch capability using Entegra+. Contact us if you are undecided which method is best for your situation.