1 / 33

DICOM explained in the context of Structured Reporting

DICOM explained in the context of Structured Reporting. NEMA workshop, Washington DC March 29-30, 2000. Herman Oosterwijk, OTech Inc. herman@otechimg.com. Objective:. To get a basic understanding of DICOM services and objects in the context of Structured Reporting: DICOM objects (IOD’s)

svega
Download Presentation

DICOM explained in the context of Structured Reporting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DICOM explained in the context of Structured Reporting NEMA workshop, Washington DC March 29-30, 2000 Herman Oosterwijk, OTech Inc. herman@otechimg.com

  2. Objective: • To get a basic understanding of DICOM services and objects in the context of Structured Reporting: • DICOM objects (IOD’s) • DICOM encoding: Data elements, VR, sequences, Codes • DICOM exchange media

  3. Parts of the Standard: 1. Overview 2. Conformance 3. Information Objects 4. Services Class Specifications 5. Data Structures and Semantics 6. Data Dictionary 7. Message Exchange

  4. Parts of the Standard: 8. Network Support 9. Point to point 10. Media Storage and File format 11. Media Storage Application Profiles 12. Physical Media 13. Point to point Print mgt 14. Greyscale display function standard xx. Supplements!!!

  5. DICOM key parts: • Common Information Model • Conformance claims to define functionality: • Matching is critical • Roles: SCU/SCP • Unique Identification of objects: • Each DICOM object is unique • Documentation tools such as Macros

  6. Key DICOM concept==SOP Class (Service defn + Information Object Defn): DIMSE -------------- C-Store Service Elt. Info Object----------- SR Object Defn (IOD) SOP Class------------ C-Store SR SOP Instance-------- C-Store Mrs. Smith SR

  7. SVC Classes: Verification Storage Study notf. Print Mgt Patient Mgt Study Mgt Results Mgt Storage Commnt Query/Retrieve BasicWlist Mgt Relationship between: • Service Class • Information Object Definition(IOD) • DIMSE Service Elements • Service Object Pair (SOP) Class Service Elements: N-Create N-Set N-Get N-Delete N-Action N-Event-rep C-Store C-Get C-Find C-Move C-Echo DCM 7 (=SOP Class) IOD-->Module-->Attrib DCM 3 DCM 4 DCM 5,6

  8. Information Object Definition (IOD): • IOD Description; i.e. what is the real world object (Information Entities-IE) that is represented. Can be one or more IE’s (Composite, Normalized) • Examples: • Image IOD: Patient, Study, Equipment, Image ----> Composite • Patient IOD: Patient info ---->Normalized

  9. Information Object Definition (IOD): • IOD Entity-Relationship model; provide the context (relationships) between the IE’s This information model is critical! • IOD Module table; which modules provide the attributes for the IOD • Modules are defined for “convenience reasons” (all patient info together, all image info together....) • Modules contain Attributes (Pat. name, etc.)

  10. SR Information Model: Patient 1 is the subject of 1,n Study 1 contains 1,n 0,n spatially defines Series creates 1,n 1 1 1 Frame of Reference Equipment contains 0,1 0,n 0,n 0,n Modality Presentation Curve Image LUT State 0,1 0,n 0,n 0,n Stored SR VOI LUT Overlay Print Document

  11. Module Definition: • Attribute Name, Tag, Type, Description

  12. Value of data elements can belong to a Set: • Defined Terms: • Can be extended (e.g. Modality: CT,MR, ES, SR, etc.) • Enumerated values: • No extensions, additions (e.g. Patient Sex: M, F, O) Value Multiplicity: • More than one value, requires separator (e.g. Other Patient Names)

  13. Type Designation: • 1: Required (e.g. pixel spacing) • 1C: Required when condition met (e.g. pixel aspect ratio) • 2: Required, can be “0” if unknown (e.g. Patient Name, Accession number) • 2C: Conditional (e.g. patient positioning) • 3: Optional (e.g. Other Patient Name)

  14. DICOM Part 5-6 Data set and structures: • Data Element Tag, Optional Value Representation, Length, Value Field Data Elem Data Elem Data Elem Data Elem Tag VR Value Length Value Field

  15. Data set and structures (ctd): • Tag: Identifies Attribute • Value representation (VR): Groups similar attributes for identification and definition purposes, e.g.: • Patient name, Physician name, Other Patient names, etc.: VR is “PN” • Birth date, Exam date, etc.: VR is “DA” VR syntaxes specified in part 5

  16. Data set and structures (ctd): • Implicit VR: Assumed based on tag • Explicit VR: Explicitly specified Note: VR is negotiated during association! • Explicit VR: 0010,0010 PN 10 Smith^John • Implicit VR: 0010,0010 10 Smith^John

  17. Example of a DICOM Message:

  18. Sequences: • VR =“SQ” • Sequence contains zero or more items, which contains a set of Data Elements • Used to encode repeating sets • Accommodates multilevel nesting (recursion) • Explicit length SQ: value of bytes in length field • Undefined length SQ: requires flag in length field and SQ and item delimiters (sppt rqd)

  19. has properties Leaf Node CODE margination infiltrative" SR Example: Document Root Node CONTAINER Leaf Node CODE has concept mod " Chest X-ray " (Document Title) " Views = PA and Lateral " contains contains contains contains Leaf Node IMAGE Heading Node Content Node CODE Heading Node CONTAINER " Baseline " CONTAINER " Specific " finding = mass" " Conclusions " Image Findings " contains contains has properties Content Node CODE Content node SCOORD Leaf Node NUM " conclusion = probable " best illustration of " = " diameter = 1.3 cm" malignancy" findings " inferred from inferred from selected from Leaf Node IMAGE Has obs context Has obs context Has obs context Content Node PNAME Content Node UIDREF Content Node PNAME " Recording Observe r = " Study Instance UID of " Patient-Data-Acquisition Smith^John^^Dr^" Evidence Directly Examined Subject = Homer^Jane^^^" * Relationship Modes by RO = 1.2.3.4.5.6.7.100" = By-value = By-reference

  20. has properties Leaf Node CODE margination infiltrative" SR Example:

  21. Codes: • SNOMED: Systematized Nomenclature for Human and Veterinary Medicine; maintained by College of American Pathologists (CAP); anatomic identifiers, observations, etc. • Requires license fee • LOINC: Logical Observation Identifiers, Names and Codes (LOINC); measurements • No license (free) • CPT, ICD9: Procedure Codes • BI-RADS: Mammography • 99SDM, SDM, DTMR

  22. Codes, Why?: • Human language is not exact, many variations are possible: • e.g. Exam type is: • Chest • Thorax • Chest PA/LAT • chest

  23. Codes, where, how to encode: • From CAP, DUKE website, in supplements, eventually in new DICOM Supplement 53. • Encoding: • Coding Scheme • Version # • Code • Meaning • Optional Extended coding for context information

  24. Example from Digital X-Ray (DX) IOD: • Makes extensive use of Coded data entries using standard vocabulary: • Instead of specifying “sagittal” for View Code, one specifies: • Code Value : R-112300 • Coding Scheme : SNOMED • Scheme Version: Version 1.0 • Meaning : Sagittal

  25. DICOM Services: Information System Modality Worklist Management Storage Storage Commit Query/Retrieve MR Print Performed Procedure Step Verification

  26. Storage Service class (ctd): • SCP level of conformance: • Level 0 (local): user defined subset will be stored only • Level 1 (base): Type 1 and 2 attributes will be stored, others may be discarded. SCP is not required to validate the Attributes • Level 2 (full): Type 1,2,3 will be stored SCP is not required to validate Attributes • Patient ID, Study Instance UID and Series Instance UID may be coerced (negotiated)

  27. Waveforms: Why yet another way of encapsulating waveforms ? • Current mechanisms are proprietary; timing seems ripe for standardization • Relationship between images and waveforms is key • Existing Curve specification in DICOM was not sufficient

  28. Waveforms: Relate Images

  29. DICOM Media Specifications: Medical Imaging Application DICOM Application Entity OSI Upper layer svc boundary DICOM File svc boundary DCM Presn. A B C Media Format Media Format Media Format OSI 50 pin TCP/IP Phys. Medium Phys. Medium Phys. Medium

  30. DICOM Media Specifications (ctd): DICOM Application Entity Basic Dir. Service / Object Pairs part 10 DICOM File Format part 11 Media Formats: e.g. File data structures Physical Media: e.g. CD-R; 90 mm MOD, etc. part 12

  31. DICOM SOP Instance DICOM SOP Instance DCM File Meta Info DICOM Data Set DCM File Meta Info DICOM Data Set FILE SET

More Related