1 / 80

Supplement 145 Whole Slide Imaging – background and design decisions

Supplement 145 Whole Slide Imaging – background and design decisions. Harry Solomon GE Healthcare. DICOM Basics. Patient Name Patient ID Patient Sex Patient Birthdate. Patient Module. Study Unique ID Accession Number Study Date/Time Study Description Referring MD. Multi- frame

sylvia
Download Presentation

Supplement 145 Whole Slide Imaging – background and design decisions

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. Supplement 145 Whole Slide Imaging –background and design decisions Harry Solomon GE Healthcare

  2. DICOM Basics

  3. Patient Name Patient ID Patient Sex Patient Birthdate Patient Module Study Unique ID Accession Number Study Date/Time Study Description Referring MD Multi- frame Module General Image Module Patient Study Module General Study Module Frame of Reference Module General Equipment Module General Series Module Contrast/ Bolus Module Image Pixel Module Modality Image Module VOI LUT Module SOP Common Module Image Plane Module Rows/Columns Bits per Pixel Photometric … DICOM Image Information Object Definition DICOM Composite Information Model Hierarchy Patient Information Study Information Series Information Image (Instance) Information Dwight Simon

  4. Data Element Encoding Attributes are the logical concepts associated with an information entity Data elements are how attributes are encoded in an information object Data Set order of transmission Data Elem. Data Elem. Data Elem. Data Elem. Data Element ValueRepresen-tation Similar to TIFF Value Tag Value Field Length optional field - dependent on negotiated Transfer Syntax 0020000Dhex UI 26hex 1.2.840.1.113709.9.0.0.5743.14575602.1 Study InstanceUnique Identifier(0020,000D) Instance UID encoded as “dotted decimal”

  5. Patient Information Study Information Series Information Image (Instance) Information Part of a DICOM object Tags in increasing numeric order Value length always an even number Attributes related to modules and information model levels all jumbled up

  6. Attributes • Logical concepts in the description of an Information Entity • May have 0, 1 or many Values • 0 (empty) means the creating application doesn’t know the value of the attribute, e.g. Accession Number (0008,0050) • Multi-value example: Specific Character Set (0008,0005) • Value Multiplicity (VM) specified in Part 6 (possibly further constrained in Part 3) • Attribute value will be a complex data structure for a Sequence attribute

  7. Sequence Attributes and Items • Sequence attribute has a “value” of a structure of subsidiary attributes • Sequence Attribute name typically includes word “Sequence” • Subsidiary attributes specified in Part 3 with > character • Each instantiated set of attributes is a Sequence Item • Number of allowed Items specified in Part 3 • For editorial convenience the attributes of a Sequence are often documented in a separate Table as a Macro • Include ‘x Macro’ Table m-n • Facilitates reuse of structure in other sequence attributes

  8. Example: Scheduled Protocol Code Sequence attribute

  9. Scheduled Protocol Code Sequence attribute

  10. Sequence attribute encoding • Sequence Items are the “values” of Sequence attributes • Structure placed in the Data Element Value Field • Item structure is a “nested data set” of attributes • Attributes in each Item in tag order • Item “wrapped” using special data elements specified in Part 5 • Sequence attributes and wrappers may have an “undefined length” flag • Length of Sequence or Item terminated by explicit Delimiter data elements May be “undefined length” Sequence Data Element ValueRepresen-tationSQ Value Tag Value Field Length Item Introducer Attribute 1 Attribute 2 Item Delimiter Item Introducer Attribute 1 Attribute 2 Item Delimiter Sequence Delimiter Specifies length of Item, or may say “undefined length” Required if “undefined length” Item Required if “undefined length” Sequence Attribute

  11. Image Compression • Pixel data can be monochrome, color (RGB or YCbCr), or palette color (monochrome colorized through LUT) • No definitions yet for hyperspectral, but it has been discussed • Pixel data can be ‘native DICOM’ (with color by-plane or by-pixel) • Pixel data can be compressed using standard compression schemes, and compressed stream put in pixel data element • JPEG, JPEG-LS, JPEG2000 (each lossy or lossless) • MPEG2 • Run-Length Encoding (Packbits) • Private compression schemes can also be used

  12. Compressed Image Encoding • Uses structure similar to Sequence attribute • Allows “undefined length” attribute – eliminates 232 byte limitation • 1st Item is ‘Basic Offset Table’ - pointers to individual frames of a multi-frame image (optional) • JPEG and JPEG2000Part1 encode each frame of a multi-frame image in a separate Encapsulated Stream Fragment • JPEG2000Part2 (multicomponent) allows arbitrary mapping of frames to stream fragments to allow component collections (inter-frame compression) May be “undefined length Pixel Data Element ValueRepresen-tation OB Value Tag Value Field Length (7FE0,0010) Item Introducer Basic Offset Table Item Introducer Encapsulated Stream Fragment 1 Item Introducer Encapsulated Stream Fragment 2 Sequence Delimiter Specifies length of Basic Offset Table Specifies length of Stream Fragment Required if “undefined length” Pixel Data Attribute

  13. Multiframe Images

  14. Enhanced Multi-frame paradigm • Basic concept used for all new multiframe IODs • MR (Image and Spectroscopy), CT, XA, US, PET • Multi-frame object to support 1000+ image studies • Dynamic image header supports functional or acquisition attributes changing during scan • Dimensions allow multiple views of data • File size flexibility through concatenations

  15. Fixed Header Dimension data Pixel data Per-frame header Single-frame to MultiFrame N Objects, N Headers N Frames, One Header

  16. Functional Groups and the Per-Frame Header

  17. Functional Groups • Collection of set of closely related attributes • A “mini Module” • Structured as a sequence of (usually 1) item under a main Sequence attribute • Invoked as a ‘Macro’ in either Shared Functional Groups Sequence or Per-Frame Functional Groups Sequence • Keeps items together in encoding under the main Sequence attribute

  18. Dimensions – properties that may change echo cardiac phase b-value orientation time position volume time

  19. Physical Location (Stack) Index 6 6 6 5 5 5 4 4 4 3 3 3 2 2 2 1 1 1 Multi-phase / Multi-slice Phase (Time) Position Index 1 2 3 Slice Order for phase 1 Phase order for slice 2 Frame number 1-6 Frame number 13-18 Frame number 7-12 Image frames can be sorted/displayed independent of encoded frame order

  20. Concatenations • What is a concatenation? • set of image objects • in the same series • with the same dimension indexes • uniquely identified with a Concatenation UID (0020,9161) • “contained” image objects must have the same Instance Number • Why? • file system limits – e.g., 600 MB CD-R • pseudo real-time transfer of a stream of images • workstation needs to post process images in near real time to figure out when the scan is to be terminated

  21. Legend: Dimension data (not on scale) Fixed Header Per-frame header Pixel data (not on scale) Concatenations An object may be split up into two or more SOP Instances, using the same concatenation UID

  22. Image Retrieval

  23. Query Request PACS Query Match(es) Retrieve Request Image(s) Send Store Response(s) Query/Retrieve SCP Retrieve Response DICOM Query/Retrieve • Allows a system to query another system for a list of available images (query) • Also allows a system to request another system to send images (retrieve) Workstation Query/Retrieve SCU

  24. Hierarchical Query • DICOM query is not a full SQL-type feature • Limited attributes, no Join capability • Directed toward production imaging department requirements • Hierarchical data structure • (Patient), Study, Series, Image levels • Patient attributes typically subsumed in Study level • Query at any level requires specification of unique entity at each higher level

  25. PACS Query/Retrieve SCP Typical Hierarchical Query Level: STUDY Patient ID: D73001 Date: 20090521-20090524 Study ID: 09-35541 Study UID: 1.2.789.45.63 Patient ID: D73001 Date: 20090521 Study ID: 09-35819 Study UID: 1.2.789.154.3 Patient ID: D73001 Date: 20090524 Study ID: 09-35602 Study UID: 1.2.789.87.11 Patient ID: D73001 Date: 20090522 Workstation Level: SERIES Study UID: 1.2.789.87.11 Study UID: 1.2.789.87.11 Series Num: 1 Series UID: 1.2.405.31.1 Modality: CT Study UID: 1.2.789.87.11 Series Num: 2 Series UID: 1.2.405.31.2 Modality: CT Query/Retrieve SCU Level: IMAGE Study UID: 1.2.789.87.11 Series UID: 1.2.405.31.1 Study UID: 1.2.789.87.11 Series UID: 1.2.405.31.1 Image UID: 1.2.405.31.1.99.1 Study UID: 1.2.789.87.11 Series UID: 1.2.405.31.1 Image UID: 1.2.405.31.1.99.2 Study UID: 1.2.789.87.11 Series UID: 1.2.405.31.1 Image UID: 1.2.405.31.1.99.3

  26. Classical Hierarchical Retrieve • Retrieve can be at any hierarchical level • (Patient), Study, Series, Image • Retrieve at any level requires unique ID of entity at each higher level • Object transfer can be on separate Association (C-MOVE) or on same Association (C-GET) • C-MOVE object transfer can be directed to third party • Examples: • Retrieve all objects under Study UID 1.2.789.87.11 • Retrieve all objects under Study UID 1.2.789.87.11 / Series UID 1.2.405.31.1 • Retrieve single object Study UID 1.2.789.87.11 / Series UID 1.2.405.31.1 / Instance UID 1.2.405.31.1.99.1 • Retrieved objects sent and confirmed as wholes

  27. Interactive JPIP Retrieve • Image Store SCU and SCP can negotiate a JPEG 2000 Interactive Protocol (JPIP) Transfer Syntax • Image header (i.e., entire object minus pixel data) transferred and confirmed as usual • Pixel data replaced by URL to JPIP service for this image • Limitations • Pixel data must be in JPEG 2000 format • Storage Commitment not allowed • Duration of availability of JPIP not specified or guaranteed • Capabilities • Retrieve subset of image (ROI) • Retrieve at a lower resolution (e.g., for quick navigation)

  28. New in 2009Supplement 119 Frame-based retrieve • Retrieve subset of frames from a multi-frame image • Selected frames of a volumetric stack (ROI) • Decimated volume (e.g., every 10th slice) • Single dimension of a multi-dimensional image • Time snippet of motion image (video) • SCU & SCP negotiate “Instance Root Retrieve” SOP Class • SCU specifies selected frames or time interval • SCP creates new multi-frame image with derivation attributes • Frame Derivation Module and Contributing Equipment Sequence • Correct subset of Functional Group Sequence Items

  29. Vocabulary and Structured Reporting

  30. Vocabulary-intensive messaging • There’s a lot of things we want to say about imaging that cannot be pre-defined in fixed DICOM attributes • E.g., specimen processing • How do we define message attributes to handle what we need to say?

  31. 00180015 ABDOMENPELVIS 00180015 = Body Part Examined Name-value pairs < BodyPartExamined “ABDOMENPELVIS” /> <el> <name “BodyPartExamined” /> <value “ABDOMENPELVIS” /> </el> <el> <name code=00180015 system=DICOM meaning=“Body Part Examined” /> <valuecode=R-FAB57 system=SNOMED meaning=“Abdomen and pelvis”/> </el> Why would we want to do this?

  32. External coded/concept terminologies • Flexibility and extensibility • Leverage externally defined/maintained concepts • Semantic rigor through referenced dictionary/ ontology • General structure – higher layer of abstraction • Allows generalized messaging applications • Shared vocabulary across disparate systems

  33. SNOMED • Systematized Nomenclature of Medicine • Most comprehensive clinical healthcare terminology • 375,000 concepts; 900,000 relationships between concepts • Multi-hierarchically organized • Primary external vocabulary system for DICOM • Anatomy • Procedures (including radiographic views and methods) • Clinical findings • Originally developed by the College of American Pathologists, now managed by an international consortium of governmental agencies (IHTSDO)

  34. LOINC • Logical Observation Identifier Names and Codes • Standard coding system for laboratory and clinical observations • Hosted by Regenstrief Institute • Supported by National Library of Medicine • Particularly focused on names of laboratory and clinical tests • 50,000 codes; over 275,000 relationships • Major external code system for DICOM and HL7

  35. Code Sequences DICOMPart 3 “Triplet coding” : code value, scheme, meaning (version seldom used)

  36. Context Groups (Value Sets) DICOMPart 3 DICOMPart 16

  37. Content Items • Generic Name:Value pair using external coding for Name concept • Encoded as Item in Sequence attributes: • Acquisition Context Sequence (in image IODs) • Protocol Context Sequence (in Modality Worklist) • Content Sequence (in Structured Reporting IODs) • Specimen Preparation Step Sequence (in Specimen Module) Person Name Value (0040,A123) DateTime Value (0040,A120) Referenced SOP Sequence(0008,1199) Text Value (0040,A160) UID Value (0040,A124) SOP Class UID(0008,0050) SOP Instance UID(0008,0055) Content Item Concept Name Sequence (0040,A043) Value Type (0040,A040) Concept Value Sequence (0040,A168) Numeric Value (0040,A30A) Measurement Units Sequence(0040,08EA) Code(0008,0100) Scheme(0008,0102) Meaning(0008,0104) Code(0008,0100) Scheme(0008,0102) Meaning(0008,0104) Code(0008,0100) Scheme(0008,0102) Meaning(0008,0104)

  38. Templates • Structure for Content Items - like Modules are a structure for Attributes • Specified in DICOM Part 16

  39. Annotation and Segmentation

  40. DICOM annotation principles • Annotations are conveyed in information objects separate from the original image • Annotations may be created at a time much later than the image acquisition, and in a completely different environment • Multiple annotation objects can reference the same image • Selection of an annotation object for display implicitly invokes display of the referenced image

  41. Annotation types • Presentation States • Structured Reporting • Segmentation

  42. Presentation State • Softcopy Presentation States define how referenced image(s) will be displayed • Transforms to device independent grayscale/color space (LUTs) • Selection of display area (ROI) of the image • Image rotate or flip • Graphical and textual annotations, overlays, shutters • Grayscale, color, and pseudo-color SPSs • Blending SPS overlays a pseudo-color image on a grayscale image • E.g., for PET/CT • Blending on grayscale originals (currently no standard for blending of color originals)

  43. Structured Reporting • Presentation State annotations are for human reading, not interoperable for automated applications • No controlled and coded vocabulary, no structural semantics (relationships between annotations) • SR important for (semi-)automated imaging analysis and review processes

  44. Key Image Note • SR-type object that provides a classification and a textual comment for a referenced object • Formally known as “Key Object Selection”, but commonly denoted “Key Image Note” after IHE use case and profile • Classifications typically identify intended subsequent use of referenced objects • “For Referring Provider”, “For Research”, “For Report Attachment” • “Rejected for Quality Reasons”, “Signed Complete Study Content”

  45. Segmentation • Derived image object • Uses enhanced multi-frame mechanism • Multiple segments per object • Each segment linked to a categorization • Pixels show presence of category at pixel location • Binary (1-bit/pixel) or fractional (probability or occupancy) • Segmentation object is typically in same Frame of Reference as source image • Segments can be displayed as overlays on source image

  46. Segmentation Example

  47. Pathology in DICOM – Specimen and Workflow

  48. What’s NOT in Sup145 • All the modules already standardized • Patient, Study, Series, Equipment, General Image • Multi-Frame Functional Groups and Dimensions • Sup122 Specimen Module • Explicit description of workflow • Use of Modality Worklist, Modality Performed Procedure Step, Image Availability Notification, etc.

  49. Sup 122 Specimen Identification • Support for pathology lab workflow, specimen-based imaging • Gross specimens, blocks, vials, slides • Image-guided biopsy samples • Specimen Module at image level of hierarchy • Identification, processing history • May be used with current Visible Light image object definitions • Update to Modality Worklist to convey Specimen Module • Enables automated slide scanning devices to fully populate header • Update to Modality Performed Procedure Step to identify imaged specimen • Allows LIS/APLIS to track images for specimens

  50. Specimen Imaging Information Model Disambiguates specimen and container Container is target of image Container may have more than one specimen Specimens have a physical derivation (preparation) from parent specimens When more than one specimen in an imaged container, each specimen is distinguished (e.g., by position or color-coding) Basic DICOM Information Model

More Related