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 ClassCombination 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 UIDUnique identifiers

Application Entity (AE Titile)Application's Formal DICOM name

DICOM Data Model

Image/Instance

Series

Study

Patient

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 DICOM File 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

Discovery

Retrieve

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

Harvest

Index/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

Harvest

Index/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