Migration Controller

Pukka-j offer extensive experience in the data migration pathway. Each data migration project is deemed to be unique and we deploy several technology methods including bulk transfer, rapid migration and DICOM services to ensure imaging data is copied and if needed decompressed, converted to a non-proprietary format and recompressed as DICOM lossless data.

Deciding on the best method is not manufacturer or PACS specific, but site specific and should be driven by patient safety considerations, local architecture and the final destination of the migrated images.

Rapid Migration

The industry standard method of migrating data from PACS is DICOM query/retrieve. As an alternative, Pukka-j offers a Rapid Migration method that reads the image files directly from the PACS storage devices. Although Rapid Migration is a very different approach to DICOM query-retrieve, the two methods are not mutually exclusive. Indeed, a client choosing Rapid Migration should also expect some studies to be pulled by the standard method.

For Rapid migration methods the Pukka-j migration controller solution bypasses the production service, so called ‘outbound migration’, and retrieves the data directly from the file system, which results in maximum throughput.

Migration Workarounds

In those cases where Rapid Migration is unable to be deployed, (as a result of PACS and LSP Service Level Agreement restrictions), Pukka-j provides an intelligent workaround by making use of multi-threaded migration controllers, utilising existing nodes and devices, to create a migration query and retrieval farm. The migration method allows full control to optimise the task during quiet hours and a production friendly drip-feed method deployed within working hours.

DICOM Query/Retrieve

The standard DICOM query/retrieve method is well supported, but implies a burden on the clinical system. Query-retrieval must, therefore, proceed at a rate such that the localisation goes unnoticed by clinical users. In some cases there is some self-regulation by the PACS; images (or slices) may be sent with some time delay in between (implying transfer speeds relatively low for high slice number studies). A bandwidth threshold should be agreed and ten per cent is usually considered reasonable.

Final Destination

Once copied and converted, the data may reside in a Transitional Environment, a Vendor Neutral Archive (VNA) or a replacement PACS system. For a transitional environment the Pukka-j system features an inbuilt HL7 engine to receive an HL7 feed from a customer PMI/PAS/HIS/RIS which ensures the demographics in the migrated data is matched, updated and synchronised with other customer systems.  The Pukka-j HL7 broker can be configured to act as a Disaster Recovery model to receive RIS order messages, creating a modality worklist in cases of a say a PACS downtime.

Pukka-j provides bespoke migration and conversion projects tailored to the requirements of the client and the originating and destination PACS vendor.

Considerations

A full PACS migration requires many processes for consideration.

  • Pre-requisites
  • Pre-migration assessment and data sampling
  • Data retrieval
  • Data verification
  • Retrieval methods
  • Annotations
  • System requirements
  • DICOM cleansing