DICOM Migrations Kiley Rodgers Product Manager/Senior Solutions Architect DataFirst Corporation

Objectives  Understanding DICOM  High level discussion on DICOM and it's role within PACS and/or migrations  Migration Types/Methodologies  Discussion on different types/approaches to Radiology/Cardiology migrations  Why we migrate  Discussion on reasons to migrate and how those reasons can affect a migration  Lessons Learned  Discussion on common mistakes made during the planning and execution of data migrations

DICOM Basics

Brief History  Jointly developed by American College of Radiology (ACR) and Electrical Manufacturers Associa/on (NEMA)  First published in 1985 as ACR-NEMA 1 Standard  ACR-NEMA 2 released in 1988  DICOM 3 published in 1993  Typically updated every 2 years  Developed to allow for the communication of digital imaging information between disparate systems  Meant to facilitate the growth of PACS and prevent vendor from locking customers into vendor specific solutions

What is DICOM and how does it work ?  "Digital Imaging and Communications in Medicine"  DICOM is a software integration standard that is used in medical imaging  All modern medical imaging systems support DICOM and use it extensively  Everything treated as an object  Every object is stored, processed or transferred

Where does DICOM data come from ?  PACS  Modalities  Scanners  DICOM convertors  Outside media/DICOM Importers  Advanced visualization software  Video capture/visible light device (endoscopy, pathology, burn/wound care)  Third party software

Basic DICOM Terms  Information Object Definition (IOD) "The image" Example: CT, MR, CR.....  DICOM Serivce Element (DISME) "The action" Example: C-STORE, C-GET, C-FIND, C-MOVE  Service Object Pair - SOP Class Combination of service command (ex: store) and an object (ex: MR)  Tranfer Syntax (TS) How an object is serialized (if VR is explicit, byte order, pixel compression) during transfer  Service Class User (SCU) Uses DICOM service (STORE, FIND, MOVE)  Service Class Provider (SCP) Provides DICOM service (STORE, FIND, MOVE)  Study, Series, Image (SOP) Instance UID Unique identifiers  Application Entity (AE Titile) Application's Formal DICOM name

DICOM Data Model Image/InstanceSeriesStudyPatient

Migration Methodologies

Why we migrate...  Current PACS is End of Life  Upgrading to newest version  Current PACS is not meeting clinical needs  Hanging protocols not working  Prefetch not working  License restrictions  Lacking features/functionality  Environment/Infrastructure refresh  RSNA

Migration Phases Discovery DICOM based Extract based Harvest DICOMFile based Cleanse Data Tag Mapping EMPI Crosswalk Reconcilation Migrate Validate

Types of migrations  DICOM Query/Retrieve  Share based  Hyper/Media  Archive to Archive

DICOM Query and Retrieve  Standard DICOM migration  "Store and Forward"  Source system is queried to build catalog of studies to be migrated  Source system will typically update DICOM header with current information from database  Allows for DICOM prefetch DiscoveryRetrieve Data Cleansing Migrate to Target

Share to DICOM  Images are pulled from a filesystem (share, FTP)  Requires 'Source of Truth' as most PACS do not write changes to DICOM header of archived studies  Typically query of source PACS  Data must be indexed and parsed to inventory images/studies  Ideal when source PACS is failing  Not condusive to DICOM prefetch  Only local exams are available HarvestIndex/Parse Data Cleansing Migrate to Target

Hyper Media  Similar to 'Share to DICOM' approach  Disaster Recovery service for “downed” or “broken” media based systems  Images are pulled from legacy media (tape, CD, DVD)  Requires 'Source of Truth' as most PACS do not write changes to DICOM header of archived studies  Data must be indexed and parsed to inventory images/studies  Manual process HarvestIndex/Parse Data Cleansing Migrate to Target

Archive to Archive  Storage level migration  Moving data from one archive platform to another (Cloud based or onsite)  Requires database updates to the PACS allowing for location reconciliation.  Faster than DICOM and highly efficient when moving within the same OEM

Source of Truth  What is a "Source of Truth" and what is it for?  Source of the data  PACS  RIS/HIS  Studies without orders  Outside studies  Research studies  Auto Incrementing Accession Numbers

DICOM Tag Management  "Data Cleansing"  Perhaps the most important aspect of migrations  DICOM Field tags can be evaluated, modified, or replaced during the migration process  Data typically sourced from HIS/RIS  Required for Share to DICOM and Hyper media migrations

Lessons Learned

What you should know before doing a migration  If you have done ONE migration, you have done ONE migration  Each PACS (both source and target) has it's own unique issues and requirements  Prefetch is not a valid migration methodology  Assess clinician's need to access historical data  Timing is different based on clinician  JIT (ER & STAT exams)  No scheduled event  Days prior to next scheduled imaging appointment  Protocol  Office visit (without associated office visit)

What you should know before doing a migration  Not all DICOM is the same  Proprietary tags  To keep or not to keep  Can remove valuable information/functionality  Can cause problems on target systems  Proprietary formats  Know your long term storage (type and rules)  For both source and target  Disk vs tape  Archived once daily? Based on workflow?  Not all data/information is DICOM  measurements specifically in cardiology (many times contained in CVIS)  PDF reports/charts

Know your data...  How dirty is your data  There are many reasons data can be "dirty"  Legacy devices not using DMWL  Lack of QA/QC process  Bad PACS configuraion  Technologist error  ILM policies  Does everything need to be migrated  Type of data  DICOM  PDF  HL7  DSR/TIFF  ????

Know your source(s)....  Current SLA  Will the incumbant vendor support the current environment  Required licenses  Incumbant vendor releationship  How to get the data? Query/Retireve vs share based migration  Don't just consider PACS, rather the modalities sending to it  Hardware/Application resources  Current infrastructure  Tiered storage  workflow/technology based backlog  Data source  Post processing workstations  Modalities (past and present)  DICOM Conformance Statement

Know your target....  RIS/HL7 dependencies  Supported SOPs (image types)  Can the target accept all migrated data  Hmmm.... Wonder what tags I should map in?  Do not simply do a Control-F and search the DICOM Conformance Statement  Understand how the PACS will folder studies  What criteria is used to match incoming images to RIS orders  Patient level match  Studies level match  Review DICOM Conformance Statements  How is migration volume going to effect your system  Is there storage available to accomadate the data to be migrated  Is there enough system resources to handle both migration and production data

Prefetch  What triggers will prefetch act upon?  DMWL  When are studies placed and removed from DMWL  Differ from vendor to vendor  Could affect image availability  HL7  SIU/S12  Allows for preftech independant of imaging appointment  Usually allow for configuration several days in advance  Example: Annual mammogram, repeat CT/MR  On-Demand/Priority  Manual/ADHOC migration of data

Clinical Validation  Is the data relevant (data cleansing)  Image Quality  Lossless/Lossy  Once compressed lossy?  Photometric Interpretation  Cine functionality  US (Echo)  XA (Angio)

In Summary  Plan, plan, plan....  DO NOT wait until your PACS Go-Live to start  Know your systems and data