DICOM WG 30 Small Animal Imaging DICOM Training Introduction and Basic Concepts
Embed Size (px)
Transcript of DICOM WG 30 Small Animal Imaging DICOM Training Introduction and Basic Concepts
Digital Mammo Issues
DICOM WG 30 Small Animal Imaging
Introduction and Basic ConceptsDavid Clunie (firstname.lastname@example.org)PixelMed PublishingDICOM Learning ObjectivesBrief historyFile formats and Storage ServicesData Set encoding principlesTransfer SyntaxesInformation Object DefinitionsStorage SOP ClassesOther DICOM services than storageConformance statementsAssociation NegotiationDICOM Message Service Elements (DIMSE)DICOM Upper Layer Protocol (DUL)
2Who Needs to Know What?User/customerservices and objects relevant to domain (esp. storage)conformance statement interpretation and matchingInstaller/integrator+ network addressing, more detail about services+/- integration with non-imaging (IS, workflow) systemsApplication designer/developerdetailed knowledge of (relevant) services, objects, attributesuses toolkit to abstract (most) encoding/network detailsProblem solver/troubleshooter+ data sets: interpret dumps and validation tool output+ network: DIMSE/DUL to interpret network logs/traces/dumpsToolkit designer/developereverything: objects, encoding, services, networkStandard writer: new modalityIOD structure, reusable modules, encoding limits, precedentsDICOM Brief History1982 1st PACS Conference session on standards1982 AAPM Report 10 Standard Format for Image Interchange1983 ad hoc meeting between FDA, ACR & NEMA1983 1st meeting of ACR-NEMA Digital Imaging and Communications Standards Committee1985 ACR-NEMA 300-1985 (version 1.0) issued
1988 ACR-NEMA 300-1988 (version 2.0) issued1990 Inter-vendor testing of version 2.0 at Georgetown1992 Trial of DICOM (version 3.0) at RSNA
1993 DICOM 3.0 issued4DICOM Brief History1982 1st PACS Conference session on standards1982 AAPM Report 10 Standard Format for Image Interchange1983 ad hoc meeting between FDA, ACR & NEMA1983 1st meeting of ACR-NEMA Digital Imaging and Communications Standards Committee1985 ACR-NEMA 300-1985 (version 1.0) issued1985 IEEE 802.3 Ethernet (based on 1976 Metcalfe)1986 Aldus TIFF (version 3; prior versions drafts only)1987 CompuServe GIF1988 ACR-NEMA 300-1988 (version 2.0) issued1990 Inter-vendor testing of version 2.0 at Georgetown1992 Trial of DICOM (version 3.0) at RSNA1992 JPEG (ITU T.81; ISO 10918-1 1994)1993 DICOM 3.0 issued5DICOM Brief HistoryACR-NEMA versions 1 and 250-pin 16 bit parallel interfaceno network (assumed network interface unit)layeredmessages with commands and datatag-value pairsdescribed patients, studies, imagesdescribed modality, acquisition, 3D position, etc.
DICOM Brief HistoryACR-NEMA versions 1 and 250-pin 16 bit parallel interfaceno network (assumed network interface unit)layeredmessages with commands and datatag-value pairsdescribed patients, studies, imagesdescribed modality, acquisition, 3D position, etc.DICOM 3.0TCP/IP network protocol (and OSI semantics)object-oriented description & conformanceDICOM ScopeImplicit in the standards name: Digital Image and Communications in MedicineImages and image-related informationAll acquisition modalities1993: CR, CT, MR, US, NM, SC (DF and DV)2014: XA, XRF, DX, MG (+DBT), IO, PT, VL (Photo, Endo, Slide), WSI, OCT (OP,IV)RT, SR (+CAD), waveforms, OP measurements and maps, surface scans, implants, segmentationsStorage + other servicesDICOM ScopeInterchange of medical imagesradiology, cardiology, pathology .... any ologynetwork (TCP/IP) or media (CD, DVD, MOD)Printinggrayscale and colornetwork rather than point-to-point (TCP/IP)Information System Integrationreports, worklists, performed proceduresWhy does DICOM exist ?Previous solutions closed (proprietary)Real world requires open standardsheterogeneous modalitiesheterogeneous workstationsheterogeneous archives, PACS, etc.Consortium ofindustry (NEMA) users (ACR, ACC, CAP ...)Why interchange images ?ArchivingInterpretationsoftcopy readingfilmless operationAdvanced processing3D visualization, quantitative analysisfusion of images from multiple modalitiesTeaching, research ...Why (open) standards at all ?Too many permutations of ...Acquisition device vendorsgeneralGE, Siemens, Philips, Toshiba,Shimadzu, Hitachi, ...specialBruker, iTheraMedical, Mediso, PerkinElmer ...Processing and archive device vendorsgeneralGE, Siemens, Philips, ... (+ open source)specialInViCRO, ...
Why not existing standards ?Didnt exist when ACR-NEMA formedPure imaging standards (TIFF, etc.)limited support for medical image typesdont encode domain specific informationOther domains inappropriatemilitary, remote sensing, astronomical, etc.ISO standards (e.g., IPI) never adoptedMedical standards that didnt do imagesHL7, MIB (IEEE 1073), etc.Needed more services than just storagequery/retrieve, printing, workflow, etc.DICOM Why?Domain-specific fieldspatient identification & characteristicsdevice identification & characteristicsacquisition protocol parametersstudy management identifiers, dates and timesNeed to handle binary bulk pixel datae.g., HL7 text based and no image supportNeed to be extensibleevolving technology, private extensionsvariable rather than fixed length headersKey goals of DICOMSupport interoperabilityNOT (necessarily) interfunctionalityWITHOUT defining (restricting) architectureDefine conformancespecific services and objectsdocumentation (Conformance Statement)negotiationConsensus standardVoluntary complianceOpen (license fee free)DICOM does NOT define:PACS or IM ArchitecturePicture Archiving Communications SystemImage ManagementDistributed Object ManagementRadiology/Hospital Information SystemComplete Electronic Medical Record
Integrating the Health Care Enterprise (IHE) does define some aspects of architecture on top of DICOM, HL7, etc.What is Interoperability ?Analogy of web server/browser:Interconnectivity - both talk TCP/IPInteroperability - both talk HTTP and HTMLInterfunctionality approached, not guaranteed:versions of HTML poorly controlledlayout and other behavior not constrained by HTMLoptional/additional featuresuse of extensions (plug-ins, applets, scripts, stylesheets)Not (always) sufficient for clinical needsinteroperability is necessary but not sufficientreality check on user/customer expectationsDICOM and InteroperabilityFor example, conformance to DICOMwill guarantee network connectionwill guarantee storage of MR image:from Modality to Workstationwill NOT guarantee (but will facilitate):Workstation will display image correctlyWorkstation can perform analysis (e.g., diffusion tractography)facilitated by mandatory attributes for:identification, annotation, positioning, etc.
IHE profiles define functionality,e.g., DIFF, PERF, MAMMO, Cardiac NMDICOM and InteroperabilityObject-oriented definitiondata structures, e.g., MR image objectcomposite model of real world entitiespatient, study, seriesgeneral image, specialized to MR imageservices, e.g., image storagetogether -> service/object pairs (SOP)Roles (user or provider) (SCU or SCP)Role + SOP Class -> ConformanceDICOM SOP Classes/RolesMR scanner may say:I am an MR Image Storage Service Class User (SCU)Workstation may say:I am an MR Image Storage Service Class Provider (SCP) (amongst other things)
MR images may be transferredDICOM SOP Classes/RolesAngiography device may say:I am an XA Image Storage Service Class User (SCU)Workstation may say:I am not an XA Image Storage Service Class Provider (SCP) (though I do support other kinds of images like CT and MR)
This pair cannot transfer XA imagesWhy is DICOM so specific ?For example,MR Imagesingle frame, 12-16 bit grayscale imageMR acquisition - pulse sequence parameters3D patient relative co-ordinate/vector positionX-Ray Angiography Imagemulti-frame, 8-10 bit grayscale imageXA acquisition - radiation/collimation/motiondynamic C-arm/table relative positioningDICOM SOP Classes/RolesWorkstation may say:I am a Basic Grayscale Print Management Meta SOP Class SCUPrinter may say:I am a Basic Grayscale Print Management Meta SOP Class SCP
Images may be printedDICOM SOP Classes/RolesUltrasound scanner may say:I am a Basic Color Print Management Meta SOP Class SCUPrinter may say:I am only a Basic Grayscale Print Management Meta SOP Class SCP
This pair cannot print imagesModality is ImportantDifferent acquisition characteristicsX-Ray-based v. notcross-sectional v. projectional (planar)transmissive v. emissivestructural v. functionaldifferent mechanisms of contrast (endogenous or exogenous)hybridsModality is ImportantDifferent image characteristicssingle or multiple channels (grayscale, color)use of pseudo-color (palette color)broader dynamic range than displayedvalues may be > 8 bits in depth and signednon-linear transformation (or linear window)physical significance of pixel values (counts, HU, velocity)physical significance of size (measurements)
Modality-specific DICOM IODsInformation Object Definition (IOD)one (or more) for each modalitymore if conformance reason for variantsCompositemultiple real-world entities in same IODObject-oriented (sort of)inherit same (composite) real-world/information modelpatient/study/procedure step/series/image/framere-use common general Modulese.g., Patient, General Study, General Image Modulere-use common technology Modulese.g., Contrast/Bolus, Frame of Reference, X-Ray Grid Modulespecialize with modality-specific Modulese.g., CT Image, MR Image Module
Composite Information Model
MR Image IOD
Image Plane Module
Type: 1 required, 2 may be empty if unknown, 3 optionalEncoding Data ElementsFlat list of sorted unique Data ElementsIOD/Module structure is NOT encodedModule Attributes encoded as Data ElementsEach Data Element is a Tag-Value pairTag-Type-Value triple with explicit type (VR) encodingData Element Tag: pair of 16 bit numbers16 bit group number (historical distinction)16 bit element numberencoded in binary, described in hexadecimale.g., (0008,0020) means Study Datemeaning is not