dicom migrations kiley rodgers product manager/senior solutions architect datafirst corporation
Post on 23-Dec-2015
218 Views
Preview:
TRANSCRIPT
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
top related