The Evolution of PACS Data Migration

Transcription

1 Your First Choice for PACS Services & VNA Solutions The Evolution of PACS Data Migration A Discussion of Current Migration Strategies & Their Use James F Maughan Vice President Business Development Services March 2011

2 Your First Choice for PACS Services & VNA Solutions Introduction: Starting around 2000, for various technological & feature/functionality reasons, the users of PACS systems began replacing their original PACS. The replacement decision included the need to move study data from the old system to the new system. The term migration became the popular term to describe this task. Over time, methods and approaches have been developed to address the various challenges that can be encountered during a PACS data migration. This paper will describe these strategies and discuss their applicability in migration projects. Learning Objectives: o o o Historical Perspectives Early PACS Design Limitations Description of Migration Strategies & Their Use Historical Perspectives Early PACS Design Limitations: Apparently PACS architects either completely overlooked or marginalized the requirements to migrate studies from their design considerations. Early on, there really was no way for an outside source to effectively request studies from a PACS. Query Retrieve (Q/R) services arrived with the adoption of the DICOM standard but few systems completely implemented it. So getting data out of the PACS was challenging. And even if DICOM Q/R was implemented, the systems could not efficiently respond to queries in high volumes over short periods of time. PACS study export & study import uses the same DICOM interface. Computer processing resources can be added to balance the import & export resource requirements, but the ability for the PACS to simultaneously respond to high volume export requests while managing current study imports is limited. Many PACS have limits set on the number of C- Find/C-Move transactions that the system will handle at any time. Once that threshold has been met, additional requests beyond the limit will enter a queue and once that is full no other requests will be accepted. Many times the requesting source is unaware that the request cannot be retrieved. There are constraints on getting data out of the old PACS which limits how fast & how much data can be exported. Not a very effective way to move hundreds of thousands of studies in a short period of time. On top of these architectural challenges early PACS were often delivered as a turnkey solution; software, hardware, and services. The turnkey solution was typically sized for a normalized ingest volume with periodic, if not rare, export requirements. Some PACS are entirely designed for import without a provision for export as previously mentioned. Since the system was sized for a specific ingest capacity and the ability to balance access to resource across ingest and export didn t exist, or wasn t very mature, the need to rapidly export data using Q/R services simply wasn t reliable. In short, vendors and customers alike didn t size their systems to export data at rates of 5, 10, or 50 times faster than the expected normalized ingest volume. PACS systems to this day have limitations on their ability to import studies. It would appear that the PACS architects focused on the number of studies that would be received per hour

3 Your First Choice for PACS Services & VNA Solutions from the modalities as the design requirement. A busy radiology department might send up to 100 studies per hour to the PACS. In order to migrate hundreds of thousands of studies in a reasonable period of time, several hundred studies per hour need to be imported into the new system. Some PACS simply limit the number of DICOM associations that can be managed at one time after which no others will be accepted. The import bottleneck is related to the gateway functions that every PACS performs as new studies are received from the modalities. There are study verification steps, database entry steps and DICOM transactions among others that the gateway applications address. This simply takes time. Once again computer processing power can be assigned that can increase the number associations but it usually ends of being a migration limitation that needs to be addressed. Early efforts to use DICOM Q/R services to migrate studies quickly revealed these limitations and their impact on migration project duration. The effort involved to manually manage the Q/R requests and verify successful receipt of all of the study images was greater than many institutions had resources to apply. Even scripted batch Q/R requests only marginally improved migration rates. Early PACS architects simply depended on the modality technologist to manually enter the required patient demographic, accession numbers, medical record numbers and other study information at the modality console. HIS/RIS interface support was not an early requirement of PACS systems and was not implemented until many years after the installation of many PACS. The resulting data integrity of study information was suspect. Transposition errors alone could account for 80% or more of study information errors. Missing information and duplication of information was common place. And study data hygiene efforts to correct these problems were not always undertaken largely due to the lack of availability of easy to use system administration tools (another design oversight). The implication of this so called dirty data became known as the new PACS systems were unable to verify the study data being imported from the old PACS. Unverifiable studies are then placed in an exception queue or folder where they will stay until the invalid or missing data elements are corrected (so called data cleansing ). This is a time consuming step that requires a substantial institutional effort to undertake. Most PACS have limits to the number of studies than can occupy the exception folder, either intentional limits or unintentional oversights. Once that limit is reached the ability to receive new studies into the PACS can be limited or becomes unruly for the end user to manage. The implication on migration is that the study transfer process slows down substantially or completely when the dirty historical study data causes exception folders to fill up. Over time migration methods and approaches have evolved to address some of the idiosyncrasies of the way PACS deal with importing and exporting study data, the quality of the study data, the order in which studies can be transferred and the final verification & reconciliation of the migrated data. This white paper will explore that evolution.

4 Your First Choice for PACS Services & VNA Solutions Description of Migration Strategies & Their Use: The following graphic depicts four approaches that can be considered for performing PACS. They are used separately or in combination depending on the migration project requirements. These approaches have been developed and refined by companies like Acuo Technologies, which specialize in the PACS data migration services business. They are intended to deliver faster, more accurate and cost effective migration projects completions. An individual description of each approach will be provided in the following sections. Standard DICOM Query Retrieve Migration: This is one of the more common approaches currently in use for performing PACS Data Migration. The requirement is that the Source PACS is a DICOM Query Retrieve Service Class Provider. With this approach a dedicated migration server receives the studies via DICOM C-Move from the Source PACS and then transmits them across the network to the Target or New PACS. Transfer rates & project duration are dependent upon many variables including the number of studies to be migrated, the extent of removable media storage, the capacity of the Source PACS to respond to queries, the institutional constraints on migration activities, Target PACS import resources & the quality of Source PACS data.

5 Your First Choice for PACS Services & VNA Solutions ` Media Migration: This is another PACS approach that bypasses the DICOM interface and reads the study files directly from removable media or spinning discs. This approach doesn t necessarily require that the Source PACS studies are DICOM Part 10 files, but rather that the data migration vendor has, or can, provide an adapter to read any proprietary files from the source PACS. This also requires access to the Source PACS database, and possibly the RIS database, in order to ascertain the latest version of the patient/study meta-data which won t be present in the files but needs to be applied to the images prior to receipt by the destination PACS. The data migration vendor may be required to perform some custom development if an adapter doesn t already exist. The data migration vendor should be able to perform standard DICOM Q/R migration while any development is occurring to assure the most rapid extraction possible. Once the adapter is available the migration should be switch fully to a media migration.. Directly reading the media significantly increases that rate at which studies can be migrated off of the Source PACS.

6 Your First Choice for PACS Services & VNA Solutions Current Study Migration Combined With Historical Study Migration: One of the problems encountered with many migrations is that current studies are often being added to Source PACS while historical studies are being migrated off of the Source PACS on a Last in First Out basis starting at a defined point in time. This creates a situation commonly referred to as gaps. The gap studies are those that have been received by the Source PACS since the migration of the historical studies started. Periodically, the gap studies need to be migrated to the Target PACS which requires a temporary suspension of the historical study migration so that the gap studies can be moved to the Target PACS. This is referred to as Gap filling. Gap filling slows down the historical migration. In order to eliminate Gap filling, an intelligent router is installed and all modality study traffic is re-directed to the router. The router in turn sends the new studies to the Source PACS AND the Target PACS applying any necessary data cleansing policies to the newly acquired data as-if it would be passed through the normal migration process. Priority Migration: Historical Study migration is basically the movement of studies off of the Source PACS in reverse chronological order. The last studies in are the first studies to be migrated out (LIFO). Start at a defined point in time and work backward until then Source PACS is empty. While a practical approach, it does not reflect the practice of radiology where patients don t show up in reverse chronological order. They arrive in random order. The migration implication being that the most relevant study may not yet be available on the Target PACS so some sort of intervention is required. The Priority Migration approach has been developed to mitigate this situation. The approach involves prefetching studies based on schedule

7 Your First Choice for PACS Services & VNA Solutions messages for scheduled studies (HL7) and DICOM Modality Work List (DMWL) messages for emergent studies, in many cases Priority Migration can be enhanced through custom HIS/RIS interfaces based on customer requirements. The Priority Migration application processes the Schedule or DMWL requests & prioritizes the study migration. The entire study folder is migrated (or the folder for a specific date range), not just the relevant prior study, thus completing that study migration. Priority Migration can easily be combined with standard migration. Priority Migration transactions take priority over historical migration tasks. Radiologist confidence improves when they have reliable access to relevant prior studies. Data Cleansing: As previously mentioned, the integrity of the study information in the Source PACS can be suspect particularly for the years of service that the Source PACS operated without the benefit of Admission, Discharge & Transfer (ADT) interfaces. Data integrity problems can be addressed with automated data cleansing tools that can correct or repair identification problems. Missing and duplicate Medical Record Numbers, patient name misspellings, and other common data integrity problems can be repaired but comparing the gold standard or system of truth data source to the Source PACS data and then creating rules to define the conditions that need to be met that would in turn trigger the automatic correction of the suspect data. Rules can also be created to prepend or append medical records numbers with identifiers intended to differentiate the study data. Missing and duplicate accession numbers duplicate or missing Study Instance Unique Identifier (SUID) can be corrected

8 Your First Choice for PACS Services & VNA Solutions using a combination of study and patient level matching conditions. Additional tags can be added to drive PACS workflow based upon customer requirements. Automated data cleansing must be carefully undertaken and the changes must be closely scrutinized and approved by the institution prior to permanent commitment to the Target PACS. It must be noted that automated data cleansing is never 100% successful. Certain exceptions will still exist after cleansing efforts that will require manual intervention. The effort to address these exceptions will be far less than that required to address all of them. Summary & Conclusions: PACS data migration projects present a number of challenges. This paper has described the various approaches that have developed over time, largely as a result of the efforts of a handful of PACS service providers including Acuo Technologies to address these challenges. The approaches can be and quite frequently are used together to affect the orderly and timely migration of study data from the Source PACS to the Target PACS. When planning a PACS data migration project, careful consideration of these approaches should be given in order to design a plan that incorporates the methods and approaches that meet the technical, clinical and business requirements of the institution.