Proposed BRIDG Changes for New Imaging Sub-Domain

Proposed BRIDG Changes for New Imaging Sub-Domain
September, 2016 Wendy Ver Hoef Ed Helton

Agenda Project goal & objectives Project Team
What are we trying to accomplish? Imaging use cases under consideration Iteration 1 – scope and mapping summary Overview of new classes Iteration 2 – scope and mapping summary Changes proposed for existing BRIDG classes

Project Overview

Project Goal & Objectives
Clinical Research Project Goal & Objectives Imaging Genomics Project Goal: To provide the semantic foundation for supporting standards-based interoperability between the imaging, clinical and genomics domains to enable advances in precision medicine. Project Objectives: To align the Imaging concepts from various NCI and external standards initiatives and harmonize or align with the BRIDG model concepts Add Imaging semantics to BRIDG to ensure that BRIDG represents the imaging concepts needed to support NCI efforts – DICOM, NBIA, AIM, Micro-AIM, CIP, CTIIP. Understand requirements and mechanics for modeling by reference the Imaging-related concepts that are already well established in another standard but are required for translational research in BRIDG NOTE: This does not necessarily mean that all imaging concepts will be in BRIDG, but that BRIDG is able to implement modeling-by-reference and point correctly to external standards to enable interoperability. Others

Project Team Wendy Ver Hoef David Clunie Smita Hastak Ulli Wagner
Ed Helton

What are we trying to accomplish?
Leverage BRIDG as the framework to support interoperability between clinical research and imaging Do this by using existing standards – DICOM, AIM, HL7 FHIR Identify and harmonize the touch points with BRIDG when overlap exists Develop a methodology to point to or navigate to other standards from a semantic point of view We are referring to this as “modeling by reference”, meaning enough concepts from one model in another to be able to support interoperability between them Develop and implement real world use case(s) to show how leveraging BRIDG as a framework will enable interoperability

Imaging Use Cases Under Consideration
Identification of entities – person, animal, specimen, image Image acquisition Image Type (modalities) Annotation & Structured Reporting Pathology (WSI); electron microscopy(J Saltz) Archiving (building a single archive for radiology, WSI and proteogenomic) Support gene panels Iteration 1 DICOM First draft done Iteration 2 AIM & DICOM SR TID 1500, first draft done

Iteration 1: Identification of entities, Image acquisition, and Image Type

Project Scope for Iteration 1
Focus of the DICOM to BRIDG mapping was to support the first 3 use cases of Identification of entities, Image acquisition and Image Type (modalities) Scoped to CT, MR, PET Key concepts of Series and Image level of data were summarized in BRIDG Identify the touch points between BRIDG and DICOM to support an implementable interoperability scenario Scoped to interfaces only Include enough imaging concepts in BRIDG to find desired data in a DICOM-based system Scope informed by the QIBA (Quantitative Imaging Biomarker Alliance) CT Tumor Volume Change for Advanced Disease (CTV-AD) Profile.

Out-of-Scope in DICOM to BRIDG mapping
Images and Series themselves are out-of-scope, just key summary-level metadata about the images are in scope Elements from DICOM that were not considered likely search criteria DICOM implementation-specific structures

Summary of DICOM to BRIDG Mapping
Initial draft model completed July, 2016 Worked with David Clunie, DICOM SME Scoped to CT, MR and PET modalities Plus other concepts re general imaging, equipment, acquisition, reconstruction, etc. Mapping done in 2 sets: Spreadsheet 1: Mapped modules, macros or other groups of DICOM concepts (e.g., Subject, parts of Imaging Study, Series & instance, equipment, etc.) 794 distinct DICOM elements considered in total Artifact: Main DICOM spreadsheet Spreadsheet 2: Mapped DICOM Supplement 121 (Protocol related elements) 178 distinct DICOM elements considered in total Artifact: Supplement 121 mapping spreadsheet Detailed mapping spreadsheets require knowledge of BRIDG, but can be provided if interest exists

Results of the Mapping New draft classes and attributes added to the BRIDG model in the new Imaging Sub-Domain 13 new classes (~approx.) 58 new attributes Existing classes not changed yet, pending approval from the BRIDG WG 8 existing classes, see details in subsequent slides ~ 79% of DICOM elements were designated out-of-scope

Key Imaging Concepts Added to BRIDG
PerformedImagingStudy – subclass of PerformedObservation PerformedImagingTimepoint – subclass of PerformedActivity ImagingProcessProtocol – subclass of ProcessProtocol GenericImagingProcessProtocol – DICOM’s “defined” protocol SpecificImagingProcessProtocol – DICOM’s “performed” protocol ImagingProcessProtocolElement – subclass of DefinedActivity ImagingAcquisitionProtocolElement ImagingReconstructionProtocolElement Each of these have 3 subclasses: one each for CT, MR, PET Radiopharmaceutical – subclass of Drug

PerformedImagingStudy & PerformedImagingTimepoint
PerformedImagingStudy class subjectHeight subjectWeight storageSOPClassesInStudy lossyImageCompressionIndicator seriesCount imageCount dicomStudyID imagingAccessionIdentifier description admittingDiagnosisCode nonAcquisitionModalitiesInStudyCode subjectHistory subjectAge PerformedImagingTimepoint class Both classes inherit attributes from Activity, PerformedActivity and PerformedObservation parent classes

ImagingProcessProtocol
ImagingProcessProtocol has no attributes aside from inherited ones (e.g. identifier, nameCode, title) 2 Subclasses: GenericImagingProcessProtocol – template protocol SpecificImagingProcessProtocol – template applied to subject

ImagingProcessProtocolElement
Reconstruction Subclasses Acquisition Subclasses

Radiopharmaceutical One attribute radionuclideCode

Iteration 2: Annotations and Structured Reporting

Scope for Iteration 2 Focus of iteration 2 was to support the 4th of the BRIDG Imaging use cases of Annotations and Structured Reporting Identify the touch points between BRIDG and AIM or DICOM to support an implementable interoperability scenario Scoped to interfaces only Include enough annotation and structured reporting concepts in BRIDG to link between a BRIDG-based system and an AIM- or DICOM-based system Scoped to CT, MR, PET regions of interest in a cancer context Examined known implementations for use cases (ePAD, AIM ClearCanvas, QIICR 3DSlicer, etc.) Size and intensity Simple (e.g., RECIST length) and complex (e.g., 3D volume) Categorical statements (Q/A; name-value pairs with codes) Scope informed by the CDISC Study Data Tabulation Model (SDTM) Oncology domains (TU, TR) already in BRIDG

Scope for Iteration 2 (continued)
Focus of the AIM to BRIDG mapping was particularly annotation-related concepts: Scoped to annotations, basic calculation info, observations, person ID and equipment used Out of scope were most other person info, the studies, series & images themselves, all Statements, spatial/dimensional/geometric information, referenced DICOM info, task context, adjudication info Focus of the DICOM SR TID 1500 to BRIDG mapping was reporting structures: Scoped to observation, subject and timepoint contexts, observer device or person, measurements, measurement groups and measurement reports Out of scope were fetus-related concepts, language, image library-related concepts, image/spatial/waveform/temporal coordinates, measurement properties

AIM Mapping Summary 508 concepts in AIM to map
511 mappings made – a couple items had more than one mapping: 49 concepts were supported with existing BRIDG classes 19 concepts were considered implementation-specific 440 concepts are out of scope – too much detail for the BRIDG use case 2 concepts suggest potential BRIDG changes, see subsequent slides No BRIDG changes are done in the model yet as they are pending BRIDG WG approval

DICOM SR TID 1500 Mapping Summary
296 concepts in DICOM SR TID 1500 (plus associated macros and other TIDs) to map 307 mappings made – a few items had more than one mapping: 91 concepts were supported with existing BRIDG classes 1 concept was considered derived 10 concepts were considered implementation-specific 199 concepts are out of scope – too much detail for the BRIDG use case 6 concepts suggest potential BRIDG changes, see subsequent slides No BRIDG changes are done in the model yet as they are pending BRIDG WG approval

Conclusion First drafts from Iteration 1 and 2 complete Next steps:
Significant reuse of existing semantics, with only 13 new classes Modest changes to existing BRIDG classes proposed Sufficient imaging representation in BRIDG for CT, MR and PET Sufficient image-related annotation information in BRIDG for cancer CT, MR and PET region of interest measurement and categorical statement use cases Next steps: BRIDG WG review proposed changes to existing BRIDG classes Stakeholders (e.g., FDA, DICOM experts) review and incorporate feedback Include imaging concepts in the overall BRIDG vocabulary plans (identification of DICOM value sets in process) Tag model with DICOM/AIM mapping tags (in process) Include new Imaging Sub-Domain in next BRIDG release and ballot cycle Potentially eventually extend use case representation to whole slide images

BRIDG Imaging Sub-Domain
The Imaging Sub-Domain diagram contains more than just the new imaging classes. It also includes all existing BRIDG classes to which DICOM concepts were mapped.

Changes Proposed to Existing BRIDG Classes

Device.locatingOrganization(Organization)
APPROVED Device.locatingOrganization(Organization) Source concept: DICOM General Equipment Module - Institution Name (0008,0080): Institution where the equipment that produced the composite instances is located. Add association on Device: Device [locatedDevice] (0..*) be located at / be the location for (0..1) [locatingOrganization] Organization DESCRIPTION: Each Device might be located at one Organization. Each Organization might be the location for one or more Device. DEFINITION: EXAMPLE(S): OTHER NAME(S): NOTE(S):

Animal.breedCode => BiologicEntityClassification
APPROVED Animal.breedCode => BiologicEntityClassification Source concept: DICOM Patient Module - Patient Breed Description (0010,2292): "The breed of the patient. … Required if the patient is an animal and if Patient Breed Code Sequence (0010,2293) is empty. May be present otherwise.“ Move breedCode from Animal to BiologicEntityClassification DEFINITION: A coded value specifying a group of animals presumably related by descent from common ancestors and are visibly similar in most characteristics. EXAMPLE(S): Holstein, Angora, Himalayan cat, Labrador Retriever OTHER NAME(S): NOTE(S):

BiologicEntityClassification.strain(ST) => strainCode(CD)
APPROVED BiologicEntityClassification.strain(ST) => strainCode(CD) Source concept: Patient Module - Strain Description (0010,0212): “The strain of the patient.”; and Strain Code Sequence (0010,0219): “A coded identification of the strain of the patient. … One or more Items are permitted in this sequence. If more than one item is present, each item represents the same information but encoded using a different coding scheme (rather than post-coordinated modifiers).” Change data type and attribute name on strain(ST) to strainCode(CD) DEFINITION: A coded value specifying a group of presumed common ancestry with clear-cut physiological but usually not morphological distinctions.WENDY to update definition per convention for SC EXAMPLE(S): Minnesota5 (swine strain), DXL (poultry strain) For DICOM'sStrain Code Sequence (0010,0219): Code Value = " “, Coding Scheme Designator = "MGI => MGI_2013“, Code Meaning = "C57BL/6J“ <=use this as the string OTHER NAME(S): NOTE(S): The specific genotypic or phenotypic variant of an animal, microorganism, fungus, or pathogen. DICOM defines this to be a group of animals that are genetically uniform. CHANGE: strain(SC) not CD

BiologicEntityClassification.strainNomenclatureIdentifier
APPROVED BiologicEntityClassification.strainNomenclatureIdentifier Source concept: DICOM Patient Module - Strain Nomenclature (0010,0213): The nomenclature used for Strain Description (0010,0212) This is like a syntax or parsing scheme for what can go in the code. Add BiologicEntityClassification.strainNomenclatureIdentifier(II) DEFINITION: A unique symbol that establishes the identity of the conventions used to construct the value in the original text of strain code. EXAMPLE(S): II.extension = MGI_2013 II.root = <oid for DICOM assigned terms for strain nomenclature> OTHER NAME(S): NOTE(S): This should be the codeSystem of the SC.code on the previous slide, so this concept is not needed – tag should be added to strain(SC)

BiologicEntityClassification.strainComment
APPROVED BiologicEntityClassification.strainComment Source concept: DICOM Patient Module - Strain Additional Information (0010,0216): “Additional information about the strain of the patient that is not encoded in the formal nomenclature used in Strain Description (0010,0212).” Add BiologicEntityClassification.strainComment(ST) DEFINITION: Additional information about the strain. EXAMPLE(S): "Athymic nude" mouse which is not described by the nomenclature of "NCr-nu/nu“ OTHER NAME(S): Strain Additional Information NOTE(S):

BiologicEntityClassification.strainStockIdentifier
APPROVED BiologicEntityClassification.strainStockIdentifier Source concept: DICOM Patient Module - Strain Stock Sequence > Strain Stock Number (0010,0214): “The stock number of the strain of the patient issued by the organization identified by Strain Source (0010,0217).”; and Strain Stock Sequence > Strain Source (0010,0217): “Identification of the organization that is the source of the animal, issued by the registry identified by Strain Source Registry Code Sequence (0010,0215).” Add BiologicEntityClassification.strainStockIdentifier DEFINITION: A unique symbol that establishes the identity of the sub-population of the strain as obtained from a particular source. EXAMPLE(S): II.extension = II.root = <oid for Jrep> OTHER NAME(S): Strain Stock Sequence NOTE(S):

BiologicEntity.responsibleOrganization(Organization)
APPROVED BiologicEntity.responsibleOrganization(Organization) Source concept: DICOM Patient Module - Responsible Organization (0010,2299): "Name of organization with medical decision making authority for the patient. Required if patient is an animal. May be present otherwise.“ Add association on BiologicEntity: BiologicEntity [caredForBiologicEntity] (0..*) have decisions made by / have medical decision making authority on behalf of (0..1) [responsibleOrganization] Organization DESCRIPTION: Each BiologicEntity might have decisions made by one Organization. Each Organization might have decision making authority on behalf of one or more BiologicEntity. DEFINITION: The link between a person or animal and the organization who has decision making authority for them. EXAMPLE(S): In non-human primate research, such as at UC Davis Primate Center, the Center is responsible for the health and well-being of the primates, irrespective of the research. <NEED EXAMPLES FROM DAVID> OTHER NAME(S): NOTE(S):

DefinedSubstanceAdministration.productDose
APPROVED DefinedSubstanceAdministration.productDose Source concept: Enhanced PET Isotope Module - Radiopharmaceutical Information Sequence > Radionuclide Total Dose (0018,1074): “The radiopharmaceutical dose administered to the patient measured in MegaBecquerels (MBq) at the Radiopharmaceutical Start DateTime (0018,1078).” Add example to attribute definition - Units are units of radioactivity - MilliCuries or MegaBecquerels, e.g. 370MBq DEFINITION: The quantity of a substance or medication to be administered. EXAMPLE(S): 5 mg 20 mg of drug per kg of subject weight 370MBq OTHER NAME(S): NOTE(S): DefinedSubstanceAdministration.productDose can contain a dose expressed in absolute or relative terms (e.g., mg or mg/kg). ScheduledSubstanceAdministration.activeIngredientDose and PerformedSubstanceAdministration.productDose must contain a dose expressed in absolute terms (e.g., mg). If the DefinedSubstanceAdministration.productDose was expressed in relative terms (e.g., mg/kg), then the absolute dose must have been calculated using one or more observed factors as identified by the DefinedExpressionVariableRelationship.

Material.code APPROVED
Source concept: Enhanced PET Isotope Module - Radiopharmaceutical Information Sequence > Radiopharmaceutical Code Sequence (0054,0304): “Sequence that identifies the radiopharmaceutical. Only a single Item shall be included in this Sequence.” Add example to attribute definition - to cover the new Drug subclass: Fluorodeoxyglucose F^18^ DEFINITION: A coded value specifying the non-unique textual identifier for the material. EXAMPLE(S):aspirin, tobacco, caffeine, tongue depressors, x-ray machine, olive oil, oats, lipstick, skin moisturizer, blisterpack, test tube, specimen slide, urine, blood, plasma, platelet rich plasma, serum, DNA, gDNA, RNA, gRNA, mRNA, Fluorodeoxyglucose F^18^ OTHER NAME(S): NOTE(S):The granularity of the code may vary depending on the specificity of the material. For example, acetaminophen, Tylenol, Tylenol 250 mg gel cap.

StudySiteOversightStatus.effectiveDateRange
APPROVED StudySiteOversightStatus.effectiveDateRange Source concept: DICOM Clinical Trial Context Module - Ethics Committee Approval Effectiveness Start Date and End Date (no definition provided) The existing review board process date (in BRIDG) is not necessarily the same date as the effective date - boards can backdate approval for instance - so this maps to a new attribute in BRIDG Add StudySiteOversightStatus.effectiveDateRange DEFINITION: The date and time span specifying when the review board's oversight status (process code) begins and ends. EXAMPLE(S): OTHER NAME(S): Ethics Committee Approval Effectiveness Start and End Date NOTE(S):

PerformedLesionDescription.lesionNumber
APPROVED PerformedLesionDescription.lesionNumber Source concept: AIM AnnotationEntity.name: “Human readable colloquial name of the annotation not guaranteed to be unique”; DICOM TID 1410 PlanarROIMeasurements - Measurement Group > Tracking Identifier: “DCM - A text label used for tracking a finding or feature,potentially across multiple reporting objects, over time.This label shall be unique within the domain in which itis used. Corresponds to Tracking ID (0062,0020).”; DICOM TID 1411 VolumetricROIMeasurements - Measurement Group > Tracking Identifier: “DCM - A text label used for tracking a finding or feature,potentially across multiple reporting objects, over time.This label shall be unique within the domain in which itis used. Corresponds to Tracking ID (0062,0020).” DICOM TID 1501 MeasurementGroup - Measurement Group > Tracking Identifier: “DCM - A text label used for tracking a finding or feature,potentially across multiple reporting objects, over time.This label shall be unique within the domain in which itis used. Corresponds to Tracking ID (0062,0020).” Change data type and attribute name on PerformedLesionDescription.lesionNumber(INT.NONNEG) to PerformedLesionDescription.lesionIdentifierText(ST) DEFINITION: A human-readable text label used for tracking a finding or feature, potentially across multiple observations, over time, where this label is unique among other findings or features for the same subject. [Adapted from DICOM Tracking ID (0062,0020)] EXAMPLE(S): T01, NT02, T04.2, T02/T03, NEW01 [Adopted from CDISC SDTM's TU.TULNKID examples] OTHER NAME(S): Lesion NumberTracking IdentifierLink ID (TU.TULNKID) NOTE(S): Once a lesion identifier text is designated for a specific lesion that identifier text may not change or be re-used to denote a different lesion for the same subject. Note there is no expectation that lesion identifier texts are unique across all subjects. WG Decision: keep lesionNumber(INT.NONNEG) as is and ADD lesionIdentifier(ST) as defined above

Performer.evaluatorAlias
APPROVED Performer.evaluatorAlias Source concept: AIM User. numberWithinRoleOfClinicalTrial: "An identifier assigned to the author by the clinical trial, for example, role might be ‘reader’, and NumberWithinRole might be ’42’, or numberWithinRoleOfCLinicalTrial might be ‘A12345’.” Add Performer.evaluatorAlias – dependent on a current BRIDG WG discussion topic re consolidation of Performer & Assessor DEFINITION: A non-unique textual identifier for the performer. EXAMPLE(S): OTHER NAME(S): NOTE(S): When multiple performers perform the same activity or result, the value of Performer.evaluatorAlias will attribute an evaluation to a particular performer.

HealthcareProvider.roleCode
APPROVED HealthcareProvider.roleCode Source concept: DICOM TID 1003 PersonObserverIdentifyingAttributes - Person Observer's Role in the Organization: (no definition provided) Add HealthcareProvider.roleCode DEFINITION: A coded value specifying the function) of the person in the context of this organization. EXAMPLE(S): physician, nurse, radiographer OTHER NAME(S): occupation NOTE(S):

PerformedObservation.derivationMethodCode
APPROVED PerformedObservation.derivationMethodCode Source concept: DICOM TID 1419 ROIMeasurements - $Measurement parameter > Derivation: “DCM - Method of deriving or calculating a measured value. E.g.,mean, or maximum of set.”; DICOM TID 300 Measurement - $Measurement parameter > Derivation: “DCM - Method of deriving or calculating a measured value. E.g.,mean, or maximum of set.” Note that this is different from the Measurement Method in that it is a mathematical rather than physical aspect of the observation and supplements the methodCode, meaning that you can have both, and it's NOT a case where you can derive the value from other places in the model - they don't send all the raw data which is used in the derivation to arrive at the sent data. This is a mapping for what people need rather than a mapping reflecting the most normalized representation of the concepts. Add PerformedObservation.derivationMethodCode DEFINITION: A coded value specifying the technique used to calculate a measured value. EXAMPLE(S): <ASK DAVID FOR A DICOM EXAMPLE FOR THIS> OTHER NAME(S): NOTE(S):

Block vote on proposed changes as marked up
0 Abst 0 Neg Unanimously approved as documented in this slide deck (9 positive votes)

For Reference

Acquisition Subclass Attributes
ImagingAcquisitionProtocolElement Class: acquisitionTypeCode imageTypeCode cardiacSynchronizationTechniqueCode respiratoryMotionTechniqueCode dataCollectionDiameter resonantNucleusCode CTImagingAcquisitionProtocolElement Class: singleCollimationWidth totalCollimationWidth gantryDetectorTilt tableSpeed spiralPitchFactor ctdiVol ctdiPhantomTypeCode kVp exposureModulationTypeCode MRImagingAcquisitionProtocolElement Class: echoPulseSequenceCategoryCode diffusionBValue DiffusionDirectionalityCode magneticFieldOfStrength acquisitionContrastCode inversionRecoveryIndicator pulseSequenceName multipleSpinEchoIndicator phaseContrastIndicator timeOfFlightContrastIndicator arterialSpinLabelingContrastCode steadyStatePulseSequenceCode echoPlanarPulseSequenceIndicator saturationRecoveryIndicator spectrallySelectedSuppressionCode PETImagingAcquisitionProtocolElement Class: gantryDetectorTilt

Reconstruction Subclass Attributes
ImagingReconstructionProtocolElement Class: reconstructionFieldOfViewHeight reconstructionFieldOfViewWidth reconstructionDiameter slideThickness reconstructionInterval bodyPositionCode algorithmCode typeCode CTImagingReconstructionProtocolElement Class: convolutionKernal convolutionKernalGroup MRImagingReconstructionProtocolElement Class: (none) PETImagingReconstructionProtocolElement Class:

Proposed BRIDG Changes for New Imaging Sub-Domain

Similar presentations

Presentation on theme: "Proposed BRIDG Changes for New Imaging Sub-Domain"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Proposed BRIDG Changes for New Imaging Sub-Domain

Similar presentations

Presentation on theme: "Proposed BRIDG Changes for New Imaging Sub-Domain"— Presentation transcript:

Similar presentations

About project

Feedback