“empty” bridg classes first draft: may 29, 2015 last edited: june 1, 2015 prepared by wendy ver...

“Empty” BRIDG ClassesFirst Draft: May 29, 2015Last Edited: June 1, 2015

Prepared by Wendy Ver HoefSamvit Solutions/NCI Contractor

What exactly is an “empty” class?• Subclasses that have…

• No distinct attributes, AND• No distinct associations (aside from the gen/spec

relationship)

• Are we agreed that this does NOT include non-subclasses that have no attributes? These have their semantic in their associations.

• Julie will take first pass of role-based classes that are also candidates

• 1:1 associations are candidates, but they may represent distinct concepts

class Administrativ e Member Roles

BiologicEntityCommon Sub-Domain::Person

+ initials: ST [0..1]+ postalAddress: AD [0..1]+ telecomAddress: BAG<TEL> [0..*]+ raceCode: DSET<CD> [0..*]+ ethnicGroupCode: DSET<CD> [0..*]+ maritalStatusCode: CD [0..1]+ educationLevelCode: CD [0..1]+ primaryOccupationCode: CD [0..1]+ occupationDateRange: IVL<TS.DATE> [0..1]

Common Sub-Domain::ResearchStaff

+ identifier: II [0..1]+ jobTitle: ST [0..1]+ postalAddress: AD [0..1]+ telecomAddress: BAG<TEL> [0..*]+ effectiveDateRange: IVL<TS.DATETIME> [0..1]

Common Sub-Domain::Cooperativ eGroupMember

Common Sub-Domain::Administrativ eMemberPI

Common Sub-Domain::Administrativ eMemberCRA

0..*

is a function performed by{function as}

1

0..*


1

1staffs

{is staffed by}1

1staffs

{is staffed by}1

0..*


1

List of “Empty” BRIDG Classes to Consider• BRIDG classes that have no distinct attributes or

associations:• MicrobiologicalCulture• Manufacturer• Reprocessor• BiologicSpecimen• PrincipalStatisticalAnalysisPlanVersion• Funding (has subclass but that could be child of

Resource)• MaterialResource• SpecimenProcessingProtocol• ImageAcquisitionProtocol• ResearchProject (has 2 subclasses)• InVitroCharacterization• InVivoCharacterization• PhysicoChemicalCharacterization• NonResearchProjectConduct

• DefinedAdministrativeActivity (has 7 subclasses though!)

• DefinedStudyAdministrativeActivity• DefinedSpecimenMove• DefinedEligibilityCriterion• DefinedExclusionCriterion• DefinedInclusionCriterion• DefinedStratificationCriterion• DefinedMedicalConditionResult• PlannedInlusionCriterion• PlannedExclusionCriterion• PerformedInclusionCriterion• PerformedExclusionCriterion• AdverseEventOutcomeResult• PerformedRadiologyCTImaging (but that is a

placeholder with lots of attributes to come)• Image (but that is a placeholder with lots of

attributes to come)

Suggestion: Determine Principles First• What are the modeling principles we should use to decide when to collapse?• Historically, BRIDG has generally avoided subclasses with no distinct attributes or associations, however

exceptions have been made when…• It would not be obvious how to represent a semantic, and/or• The SMEs felt their concept was too important to their domain to hide in vocabulary

• Should we move to a stricter policy, i.e. “empty” subclasses are not allowed period, or are there conditions under which we should allow them?

• If we collapse, how should we represent the subclass?• Do we always need a typeCode or is the nameCode for activities sufficient?• Note that SafetyReportVersion has a subTypeCode so subTypeCode couldn’t be used exclusively for representing

subclasses, and Product has a classCode so subclassCode might erroneously seem like it’s related to that• Should we come up with a standard new attribute, e.g. subclassTypeCode? • At what level should it be defined – the superclass of the lowest collapsed subclass or the top superclass in the lineage

(even if there are other, uncollapsed subclasses)? (affects size of vocab set)• Vocabulary: use the subclass name for the subclassTypeCode’s CD.code or CD.displayName and convert all elements of

the subclass definition into a description of code (held outside the CD since that’s not really an attribute of CD)?

• If we start collapsing

Assessing Impact• What are the impacts on existing users of the model if we collapse

“empty” classes?• Lots of previous mappings will be out of date• More concepts hidden in the data• New mandatory vocabulary is required to use the model

• What are the benefits to users of the model?• Smaller model to learn – could eliminate almost 10% of the classes

MicrobiologicalCulture• No distinct attributes or associations• No subclasses• CellCulture (superclass):

• DEFINITION: Cells propagated in vitro in special media conducive to their growth. Cultured cells are used to study developmental, morphologic, metabolic, physiologic, and genetic processes, among others. [Source: Medical Subject Headings]

• EXAMPLE(S):• OTHER NAME(S):• NOTE(S):

• CellLine:• DEFINITION: An established cell culture that has the potential to propagate indefinitely. [Source:

<http://www.solvobiotech.com/support/glossary?/Literature/glossary.html>]• EXAMPLE(S): human HeLa cells, mouse fibroblast 3T3 cells

• MicrobiologicalCulture:• DEFINITION: A cell culture obtained from multiplying microbial organisms by letting them reproduce in

predetermined culture media under controlled laboratory conditions. [Source NCI-T: Cell Line + Wikipedia]• EXAMPLE(S): yeast, bacteria, and viral cultures• OTHER NAME(S):• NOTE(S):

Discuss collapsing Product subclasses in general – add to WG/BART agenda

class MicrobiologicalCulture

Common Sub-Domain::Material

+ code: CD [0..1]+ formCode: CD [0..1]+ description: ST [0..1]+ characteristicBehaviorCode: DSET<CD>+ actualIndicator: BL [1...1]+ effectiveDateRange:

IVL<TS.DATETIME> [0..1]

Common Sub-Domain::Product

+ typeCode: CD [0..1]+ classCode: DSET<CD> [0..*]+ codeModifiedText: ST [0..1]+ lotNumberText: ST.SIMPLE [0..1]+ expirationDate: TS.DATE.FULL [0..1]+ pre1938Indicator: BL [0..1]

Common Sub-Domain::Biologic

+ riskCode: CD [0..1]+ handlingCode: CD [0..1]+ stabil ityDuration: IVL<TS.DATETIME> [0..1]

Common Sub-Domain::CellCulture

+ biosafetyLevelCode: CD [0..1]

Common Sub-Domain::MicrobiologicalCulture

Common Sub-Domain::CellLine

+ originCellName: ST [0..1]+ passageNumber: INT.POS [0..1]+ sourceAge: PQ.TIME [0..1]+ sourceAnatomicSiteCode: CD [0..1]+ sourceDevelopmentalStage: SC [0..1]+ sourceTissueTypeCode: CD [0..1]

Manufacturer and Reprocessor

• No distinct attributes or associations

• No subclasses

• Processor (superclass):• DEFINITION: An organization defined as being responsible for making,

assembling, refurbishing, packaging, etc. a product.• EXAMPLE(S): The maker identified on the product's box.• OTHER NAME(S):• NOTE(S): In some cases, the responsible organization will actually be

listed as a reprocessor of the item.

• Manufacturer (examples, other names, notes empty):• DEFINTION: The organization responsible for creating the product as

stated on the package in which the product is supplied.

• Reprocessor (examples, other names empty):• DEFINITION: An organization that is typically in the business of re-using or

refurbishing a product (such as a medical device) so that it can be used again. These kind of organizations must comply with the same requirements that apply to original equipment manufacturers.

• NOTE(S): These organizations are typically referred to as third part or hospital reprocessors. Reprocessing of medical devices is done to save costs and reduce wastes.

class Manufacturer and Reprocessor

Common Sub-Domain::Organization

+ name: DSET<ON> [0..*]+ typeCode: CD [0..1]+ description: ST [0..1]+ postalAddress: AD [0..1]+ telecomAddress: BAG<TEL> [0..*]+ actualIndicator: BL [1...1]+ effectiveDateRange: IVL<TS.DATETIME> [0..1]

Common Sub-Domain::

Processor

Common Sub-Domain::

Manufacturer

Common Sub-Domain::

Reprocessor

Common Sub-Domain::

ProcessedProduct

+ identifier: II [0..1]

Common Sub-Domain::

Distributor

Common Sub-Domain::Place

+ identifier: DSET<II> [0..*]+ identifierCode: CD [0..1]+ name: TN [0..1]+ typeCode: CD [0..1]+ physicalAddress: AD [0..1]

MaterialCommon Sub-Domain::Product

+ typeCode: CD [0..1]+ classCode: DSET<CD> [0..*]+ codeModifiedText: ST [0..1]+ lotNumberText: ST.SIMPLE [0..1]+ expirationDate: TS.DATE.FULL [0..1]+ pre1938Indicator: BL [0..1]

Common Sub-Domain::

ProcessingSite

0..*

functions as an outlet for

{have as an outlet} 1..*

0..*

fabricates

{be fabricated by}1..*

0..*


1

0..*is a function performed by

{function as}1

0..*

provides

{be provided by}

1..*

0..1


1

1..*

is produced by

{produces} 1

0..*

manufactures for{manufacture at}

1..*0..*

produces

{be produced by}1

BiologicSpecimen• No distinct attributes or associations• No subclasses• Specimen (superclass):

• DEFINITION: A substance or portion of material originally obtained from an entity for use in testing, examination, or study.

• EXAMPLE(S): Blood obtained by a specimen collection activity performed on a study subject. A few grains of cattle feed obtained from a feed sack. A randomly selected pill from a blister pack. A serum specimen that resulted from Centrifugation procedure performed on a blood specimen. A DNA specimen extraction from a saliva specimen. A Formalin-Fixed, Paraffin-Embedded (FFPE) block that resulted from a paraffin embedding procedure performed on a formalin fixed tissue specimen. A pooled blood sample that resulted from a mixing procedure performed on several blood samples taken from individual animals.

• OTHER NAME(S): Biologic specimen, Product specimen• NOTE(S):

• BiologicSpecimen (examples, other names, notes empty):• DEFINITION: Any material sample taken from a biological entity, including a sample obtained

from a living organism or taken from the biological object after halting of all its life functions. Biospecimen can contain one or more components including but not limited to cellular molecules, cells, tissues, organs, body fluids, embryos, and body excretory products (source: NCIt, modified).

class BiologicSpecimen

Biospecimen Sub-Domain (NEW)::BiologicSpecimen

Biospecimen Sub-Domain (NEW)::Specimen

+ /conditionCode: DSET<CD> [0..*]

«DEPRECATED»+ accessionNumberText: ST.SIMPLE [0..1]+ typeCode: CD [0..1]

PrincipalStatisticalAnalysisPlanVersion• No distinct attributes or associations• No subclasses• StatisticalAnalysisPlanVersion (superclass):

• DEFINITION: A point-in-time snapshot of a statistical analysis plan. • EXAMPLE(S):• OTHER NAME(S):• NOTE(S): The statistical analysis plan evolves during the course of the study and accordingly the

snapshot may address a different issue at varying levels of detail relative to the final plan.

• PrincipalStatisticalAnalysisPlanVersion:• DEFINITION: A type of statistical analysis plan that is the main, comprehensive, pre-specified

collection of analyses that support the Clinical Study Report (CSR) or other similar study report.• EXAMPLE(S):• OTHER NAME(S):• NOTE(S): Analyses that arise after PrincipalStatisticalAnalysisPlanVersion finalization but during

preparation of the clinical study report are handled by SupplementalStatisticalAnalysisPlanVersion.

class PrincipalStatisticalAnalysisPlanVersion

Statistical Analysis Sub-Domain::StatisticalAnalysisPlanVersion

+ identifier: II [0..1]+ typeCode: CD [0..1]+ description: ST [0..1]

Statistical Analysis Sub-Domain::PrincipalStatisticalAnalysisPlanVersion

Funding & Material Resource• No distinct attributes or associations• Funding has a subclass• Resource (other names, notes empty):

• DEFINITION: Items necessary to support a research study.• EXAMPLE(S): Funding, material, labor

• Funding (other names, notes empty):• DEFINITION: Fiscal support for research from industry, government, or non-commercial, non-governmental

organizations.• EXAMPLE(S): Funding from pharmaceutical, device or biotechnology companies, the US NIH or the Gates

Foundation.

• GovernmentFunding (other names, notes empty):• DEFINITION: Fiscal support from governmental organizations.• EXAMPLE(S): United States National Institutes of Health (NIH)

• MaterialResource (other names, notes empty):• DEFINITION: Physical supplies provided by an individual company, institution, or organization for the conduct of

research.• EXAMPLE(S): In kind contributions, donations of study drug, device, etc.

class Funding and MaterialResource

Study Conduct Sub-Domain::Resource

+ activeIndicator: BL [0..1]

Study Conduct Sub-Domain::Gov ernmentFunding

+ serialNumberText: ST.SIMPLE [0..1]+ typeCode: CD [0..1]+ fundingMechanismCode: CD [0..1]+ fundingCategoryCode: CD [0..1]+ nihInstituteCode: CD [0..1]+ nciProgramCode: CD [0..1]

Study Conduct Sub-Domain::

Funding

Study Conduct Sub-Domain::

MaterialResource

Study Conduct Sub-Domain::Serv ice

+ typeCode: CD [0..1]

Study Conduct Sub-Domain::RegistrationCenter

+ telecomAddress: TEL [0..1]

SpecimenProcessingProtocol and ImageAcquisitionProtocol• No distinct attributes or associations• No subclasses• Protocol:

• DEFINITION: A composite activity that serves as a rule that guides how activities should be performed.

• EXAMPLE(S): Specimen Collection Protocol; Specimen Processing Protocol; Image Acquisition Protocol

• OTHER NAME(S):• QUESTION(S): 1. Should BRIDG consider renaming this class to ProcessProtocol

to distinguish it from other kinds of protocols? (See NOTE(S) below.)• NOTE(S): (see next slide – too long to include here)

• SpecimenProcessingProtocol (examples, other names, notes empty):• DEFINITION: A defined set of procedures that governs the processing of

biospecimens.

• ImageAcquisitionProtocol:• DEFINITION: Provides the study-specific details for image capture, such as a

complete description of imaging parameters, appropriate instrumentation, timelines, subject positioning, etc.

class Protocol subclasses

ActivityProtocol Representation Sub-Domain::DefinedActiv ity

+ nameCode: CD [1...1]+ categoryCode: CD [0..1]+ subcategoryCode: CD [0..1]+ repeatFrequencyCode: CD [0..1]+ repeatFrequencyRatio: RTO<INT.NONNEG,PQ.TIME> [0..1]+ repeatQuantityRange: URG<INT.NONNEG> [0..1]+ /repeatDuration: PQ.TIME [0..1]+ description: ST [0..1]+ statusCode: CD [0..1]+ statusDate: TS.DATETIME [0..1]

«placeholder»Common Sub-Domain::

ImageAcquisitionProtocol

Biospecimen Sub-Domain (NEW)::SpecimenCollectionProtocol

+ irbApprovalNumber: ST [0..1]+ shortTitle: ST [0..1]+ targetAccrualNumberRange: URG<INT.NONNEG> [0..1]+ activeDateRange: IVL<TS.DATE.FULL> [0..1]+ aliquotInSameContainerIndicator: BL [0..1]+ consentsWaivedIndicator: BL [0..1]

A

Biospecimen Sub-Domain (NEW)::

SpecimenProcessingProtocol

«Comment_Requested»Common Sub-Domain::Protocol

+ title: ST [0..1]

Full Protocol Description for Reference• DEFINITION: A composite activity that serves as a rule that guides how activities should be performed.

• EXAMPLE(S): Specimen Collection Protocol; Specimen Processing Protocol; Image Acquisition Protocol

• OTHER NAME(S):

• QUESTION(S): 1. Should BRIDG consider renaming this class to ProcessProtocol to distinguish it from other kinds of protocols? (See NOTE(S) below.)

• NOTE(S): In modeling, often the same term is used to mean different things and a single concept can have more than one name. In the healthcare arena, the term "protocol" is somewhat overloaded and must be qualified to provide semantic context. Therefore during the early years of the BRIDG project, the term "study protocol" was chosen to disambiguate the concept of the detailed plan for a clinical study (the scope of BRIDG at that time) from other kinds of protocols such as are common in life sciences. In BRIDG, the notion of a study protocol is very specific in purpose and includes (but is not limited to) the design, statistical considerations, activities to test a particular hypothesis or answer a particular question that is the basis of the study, characteristics, specifications, objective(s), background, pre-study/study/post-study portions of the plan (including the design, methodology, statistical considerations, organization). For a more complete discussion of the notion of the study protocol see the classes StudyProtocol, StudyProtocolVersion, StudyProtocolDocument, StudyProtocolDocumentVersion, StudyConduct and all their associations.

• With the addition of life sciences to the scope of the BRIDG model, there came along (with that scope) the need to identify the kind of protocol that represents a more simple or atomic concept, that of “a composite activity that serves as a rule that guides how activities should be performed.” This concept, represented by the Protocol class, has a more limited size than the concept of a study protocol does and represents a standardized approach to doing tasks or activities that are not as big as the plan for a whole study.

• The BRIDG SCC acknowledges that overloaded terms are problematic. The SCC recognizes that many different users within the BRIDG community will have differing opinions on what the meaning of a term is, which term is the best to use for each concept, and how to define them most effectively. Given that the real “meat” of a concept is in the definition, the BRIDG SCC aims to choose the most unambiguous term to use as the class name, to make the class definition as explicit and clear as possible, to provide sufficient examples and other names to illustrate the range of possible instances that could be represented by the class. The SCC would like to solicit feedback from the community on representational choices that have been made as well as the class name and other aspects of the model.

class Protocol subclasses



«placeholder»Common Sub-Domain::

ImageAcquisitionProtocol

Biospecimen Sub-Domain (NEW)::SpecimenCollectionProtocol

+ irbApprovalNumber: ST [0..1]+ shortTitle: ST [0..1]+ targetAccrualNumberRange: URG<INT.NONNEG> [0..1]+ activeDateRange: IVL<TS.DATE.FULL> [0..1]+ aliquotInSameContainerIndicator: BL [0..1]+ consentsWaivedIndicator: BL [0..1]

A

Biospecimen Sub-Domain (NEW)::

SpecimenProcessingProtocol

«Comment_Requested»Common Sub-Domain::Protocol

+ title: ST [0..1]

Project Related Classes• ResearchProject – has 2 subclasses,

but no distinct attributes and noother associations

• Experiment subclasses have nodistinct attributes and no otherassociations:

• InVitroCharacterization• InVivoCharacterization• PhysicoChemicalCharacterization

• NonResearchProjectConduct – has no distinct attributes, associations or subclasses

class Project its subs and conduct classes

Common Sub-Domain::Project

+ name: ST+ type: SC [0..1]+ description: ST [0..1]

Common Sub-Domain::ProjectConduct

+ dateRange: IVL<TS.DATE.FULL> [0..1]

Common Sub-Domain::

ResearchProject

Common Sub-Domain::

NonResearchProject

Common Sub-Domain::NonResearchProjectConduct

Study Conduct Sub-Domain::StudyConduct

+ /enrolledStudySubjectNumber:INT.POS [0..1]

Protocol Representation

Sub-Domain::StudyProtocol

Experiment Sub-Domain (NEW)::Experiment

+ purposeCode: CD [0..1]+ designType: DSET<SC> [0..*]

StudyProtocol, Experiment, and NonResearchProject all have associations omitted here to save space - none of those are candidates for collapsing due to those associations.

Experiment Sub-Domain (NEW)::InVitroCharacterization

Experiment Sub-Domain (NEW)::InViv oCharacterization

Experiment Sub-Domain (NEW)::PhysicoChemicalCharacterization

0..1

is the execution of

{be the plan for}1

Class Definitions to Consider for ResearchProject• Project (other names, notes empty):

• DEFINITION: A set of coordinated activities that is intended to achieve one or more objectives.• EXAMPLE(S): The Cancer Genome Atlas (TCGA), The Breast and Colon Cancer Family Registries

• ResearchProject (other names, notes empty):• DEFINITION: A set of coordinated activities that is intended to test one or more hypotheses or lead to discoveries.• EXAMPLE(S): A project to identify genetic biomarkers for cancer prognosis. A phase 2 clinical trial to test whether an

experimental treatment is effective. An epidemiological study to determine whether there is a correlation between an exposure and a disease.

• StudyProtocol (other names empty, long note omitted to save space)• DEFINITION: A discrete, structured plan (that persists over time) of a formal investigation to assess the utility,

impact, pharmacological, physiological, and/or psychological effects of a particular treatment, procedure, drug, device, biologic, food product, cosmetic, care plan, or subject characteristic.

• EXAMPLE(S): ClinicalTrials.gov study NCT01632332 Vaccine Therapy in Treating Patients With Previously Treated Stage II-III HER2-Positive Breast Cancer. The study protocol includes the elements identified in the NOTE(S) section.

• Experiment (other names, notes empty)• DEFINITION: A formal investigation, typically not subject to governmental oversight and regulation, that is intended

to test hypotheses or lead to discoveries.• EXAMPLE(S): Gene expression experiment intended to discover novel genetic biomarkers. Physicochemical

characterization of nanoparticles.

Class Definitions to Consider for Experiment Subclasses

• Experiment (other names, notes empty)• DEFINITION: A formal investigation, typically not subject to governmental oversight and

regulation, that is intended to test hypotheses or lead to discoveries.• EXAMPLE(S): Gene expression experiment intended to discover novel genetic biomarkers.

Physicochemical characterization of nanoparticles.

• InVivoCharacterization (examples, other names, notes empty):• DEFINITION: The act of describing distinctive characteristics or essential features of the assay

which is conducted in an artificial environment, such as in a test tube, under a defined and controlled set of solvent and solute conditions.

• InVitroCharacterization (examples, other names, notes empty):• DEFINITION: The appraisal of the biological properties or activities of a substance by testing its

effect on an organism.

• PhysicoChemicalCharacterization (examples, other names, notes empty):• DEFINITION: The determination of the material, structural and chemical properties of a

substance.

• ProjectConduct:• DEFINITION: An ongoing and/or past performance of a project. • EXAMPLE(S):• OTHER NAME(S):• NOTE(S):

• NonResearchProjectConduct:• DEFINITION: An ongoing and/or past performance of a non-research project. • EXAMPLE(S):• OTHER NAME(S):• NOTE(S):

Class Definitions to Consider for NonResearchProjectConduct

Defined Administrative Activities• DefinedAdministrativeActivities (other names, notes empty):

• No distinct attributes or associations• But has 7 subclasses, 2 of which are also candidates for collapsing because they

don’t have distinct attributes or associations• DEFINITION: An activity defined at a global library level that is not directly related

to hypothesis evaluation or testing, but is typically essential to the efficient and/or effective coordination and execution of a study or experiment.

• EXAMPLE(S): assignment to a treatment arm, registration to a study, start of on-study period, end of on-study period, obtain informed consent, verify eligibility criteria, enroll, randomize, complete study visits, exit trial, break treatment blind, protocol violation, premature withdrawal

• DefinedSpecimenMove (notes empty):• DEFINITION: The action of locating or relocating a specimen or specimen

collection group from and/or to its storage location.• EXAMPLE(S): Check-in, check-out, transfer from one location to another• OTHER NAME(S): Specimen Check-in/Check-out, Specimen Return, Specimen

Placement

• DefinedStudyAdministrativeActivity (other names, notes empty):• DEFINITION: An administrative activity defined at a global library level that is

independent of a study subject but is necessary for the conduct of the study.• EXAMPLE(S): IRB Approval, site enrollment, FDA audit

class Defined Administrativ e Activ ities



Protocol Representation Sub-Domain::

DefinedAdministrativ eActiv ity

Protocol Representation Sub-Domain::DefinedExperimentalUnitAllocation

+ methodCode: CD [0..1]

Protocol Representation Sub-Domain::DefinedMaterialStorage

+ nameCodeModifiedText: ST [0..1]

Protocol Representation Sub-Domain::DefinedNotification

+ messageTitle: ST [0..1]+ message: ST [0..1]+ deliveryMechanismCode: CD [0..1]

Protocol Representation Sub-Domain::DefinedStudySubjectMilestone A

Protocol Representation Sub-Domain::DefinedStudyAgentTransfer

Protocol Representation Sub-Domain::DefinedStudyAdministrativ eActiv ity

Biospecimen Sub-Domain (NEW)::DefinedSpecimenMov e

DefinedEligibilityCriterion• DefinedEligibilityCriterion, -InclusionCriterion, & -ExclusionCriterion have no distinct attributes

and no additional associations• DefinedObservation:

• DEFINITION: An activity defined at a global library level whose intention is to obtain a result by observing, monitoring, measuring or otherwise qualitatively or quantitatively gathering data or information about one or more aspects of a subject's physiologic or psychologic state.

• EXAMPLE(S): blood chemistry panel, body mass index calculation, blood pressure measurement, obtaining DNA sequence, genotyping a genetic variant, measuring the pH of a solution, specimen quality review

• DefinedEligibilityCriterion:• DEFINITION: An activity defined at a global library level that identifies one of a set of conditions that a

subject must meet in order to participate in a study, or that a study subject must meet into order to participate in a certain part of the study.

• EXAMPLE(S): At least one pathologically confirmed positive lymph node identified. There must be no evidence of residual involved lymph node disease. At least one lymph node must be found in the pathologic specimen. At least 5 cm of the esophagus must be in the 60 Gy isodose volume in 1.6 to 2.0 Gy fractions.

• DefinedInclusionCriterion:• DEFINITION: An activity defined at a global library level that identifies a characteristic or requirement

intended to be applied to a potential study subject to determine whether they may participate in a study.• EXAMPLE(S): pregnancy

• DefinedExclusionCriterion:• DEFINITION: An activity defined at a global library level that identifies a characteristic or requirement

intended to be applied to a potential study subject to determine whether they may not participate in a study.

• EXAMPLE(S): Must be over the age of 18.

class DefinedEligibilityCriterion



Protocol Representation Sub-Domain::DefinedObserv ation

+ methodCode: CD [0..1]+ bodyPositionCode: CD [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLateralityCode: CD [0..1]+ approachAnatomicSiteCode: CD [0..1]+ /focalDuration: PQ.TIME [0..1]+ focalDateRange: IVL<EXPR<TS.DATETIME>> [0..1]

Protocol Representation Sub-Domain::DefinedEligibilityCriterion


DefinedExclusionCriterion


DefinedInclusionCriterion

DefinedStraficiation-Criterion• No distinct attributes or associations• No subclasses• DefinedObservation:

• DEFINITION: An activity defined at a global library level whose intention is to obtain a result by observing, monitoring, measuring or otherwise qualitatively or quantitatively gathering data or information about one or more aspects of a subject's physiologic or psychologic state.

• EXAMPLE(S): blood chemistry panel, body mass index calculation, blood pressure measurement, obtaining DNA sequence, genotyping a genetic variant, measuring the pH of a solution, specimen quality review

• DefinedStratificationCriterion (other names, notes empty):• DEFINITION: An activity defined at a global library level that identifies pre-treatment factors by

which study subjects are segregated to assure balance of these factors during analysis or before randomization to a study arm or some smaller segment of a study. The decisive factor used to help segregate the study subject into a stratum group for analysis or randomization purposes.

• EXAMPLE(S): Age Years: 18 to 59 vs. = 60. Extra-Cranial Disease Controlled in Months: = 3 vs. > 3. Number of Brain Metastases: 1 vs. 2 vs. 3.

• DefinedStratificationCriterionPermissibleResult (other names, notes empty):• DEFINITION: A reusable, "template" description of an allowable response to a stratification criterion.• EXAMPLE(S): The stratification criterion for gender can have permissible answers of male and female

class DefinedStratificationCriterion

DefinedActivityProtocol Representation Sub-Domain::

DefinedObserv ation

+ methodCode: CD [0..1]+ bodyPositionCode: CD [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLaterali tyCode: CD [0..1]+ approachAnatomicSiteCode: CD [0..1]+ /focalDuration: PQ.TIME [0..1]+ focalDateRange: IVL<EXPR<TS.DATETIME>> [0..1]

Protocol Representation Sub-Domain::DefinedObserv ationResult

+ value: ANY [0..1]+ valueNegationIndicator: BL [0..1]+ typeCode: CD [0..1]+ targetCodingSystem: OID [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLateralityCode: CD [0..1]+ confidentialityCode: CD [0..1]+ derivationExpression: ST [0..1]

Protocol Representation Sub-Domain::DefinedStratificationCriterion

Protocol Representation Sub-Domain::DefinedStratificationCriterionPermissibleResult

Protocol Representation Sub-Domain::StratumGroup

+ groupNumber: INT.NONNEG [0..1]+ description: ST [0..1]

0..*

is a result of

{result in}1

1..*

is characterized by{characterizes}

1..*

DefinedMedicalConditionResult• No distinct attributes or associations• No subclasses• DefinedObservationResult:

• DEFINITION: A reusable, "template" description of possible findings of an observation. • EXAMPLE(S): A blood pressure measurement may result in a diastolic number and a systolic • number.• OTHER NAME(S):• NOTE(S): The DefinedObservationResult class can be used to represent defined ranges for

contingencies by constraining the value attribute from ANY to IVL<PQ>, for instance, or any other range value. Such DefinedObservationResults may be used as criteria for conditional activities or repeated activities.

• DefinedMedicalConditionResult:• DEFINITION: A reusable template description of a sign, symptom, disease, or other medical

occurrence.• EXAMPLE(S): death, back pain, headache, pulmonary embolism, heart attack, pregnancy, flu,

broken bone, menstrual period, depression• OTHER NAME(S): Clinical Events, Medical History• NOTE(S):

class DefinedMedicalConditionResult



Protocol Representation Sub-Domain::DefinedObserv ation

+ methodCode: CD [0..1]+ bodyPositionCode: CD [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLateralityCode: CD [0..1]+ approachAnatomicSiteCode: CD [0..1]+ /focalDuration: PQ.TIME [0..1]+ focalDateRange: IVL<EXPR<TS.DATETIME>> [0..1]

Protocol Representation Sub-Domain::DefinedObserv ationResult

+ value: ANY [0..1]+ valueNegationIndicator: BL [0..1]+ typeCode: CD [0..1]+ targetCodingSystem: OID [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLateralityCode: CD [0..1]+ confidential i tyCode: CD [0..1]+ derivationExpression: ST [0..1]


DefinedMedicalConditionResult

0..*

is a result of{result in}

1

PlannedInclusion/ExclusionCritierion• No distinct attributes or associations; No subclasses

• PlannedActivity (other names empty):• DEFINITION: An activity that is intended to occur or start at some point in the context of a particular study or experiment.• EXAMPLE(S): Pregnancy tests are planned for study subjects who are females of childbearing potential. • NOTE(S): A PlannedActivity may be a container of other activities and have a complex structure involving components, options

and contingencies using the associated relationship classes. This structure allows the representation of concepts in previous versions of BRIDG such as StudyCells, StudySegments and StudySubjectEncounters. A PlannedActivity could also be thought of as an activity at a particular stage in the business process in which the activities occur, i.e., in the "planned" stage rather than the "scheduled" stage or the "performed" stage. An instance of a PlannedActivity is not assigned to a particular Subject, StudySubject, or ExperimentalUnit, but to a "kind of" Subject, StudySubject, or ExperimentalUnit.

• PlannedEligibilityCriterion (Abstract class, has distinct association to DefinedEligibilityCriterionAnswer):• DEFINITION: An activity that is intended to occur at some point in the context of a particular study that represents a

characteristic or requirement intended to be applied to a potential study subject to determine whether or not they may participate in a study.

• NOTE(S): The reason for the PlannedEligibilityCriterion structure is to allow questions defined as agnostic criteria in DefinedEligibilityCriterion, that is, they could be used either as inclusion or exclusion criteria, to be referenced in specific study protocols and allow the inclusion/exclusion distinction to be determined for that study specifically.

• PlannedInclusionCriterion (examples and other names empty):• DEFINITION: An activity that is intended to occur at some point in the context of a particular study that represents a

characteristic or requirement intended to be applied to a potential study subject to determine whether they may participate in a study.

• NOTE(S): [omitted here but same as superclass]

• PlannedExclusionCriterion (examples and other names empty):• DEFINITION: An activity that is intended to occur at some point in the context of a particular study that represents a

characteristic or requirement intended to be applied to a potential study subject to determine whether they may not participate in a study.

• NOTE(S): [omitted here but same as superclass].

class Planned Eligibility subclasses

Activi tyProtocol Representation Sub-Domain::PlannedActiv ity

+ name: ST [0..1]+ description: ST [0..1]+ blindedDescription: ST [0..1]+ transitionDescription: ST [0..1]+ /studyDayRange: IVL<INT> [0..1]+ duration: PQ.TIME [0..1]+ repeatFrequencyCode: CD [0..1]+ repeatFrequencyRatio: RTO<INT.NONNEG,PQ.TIME> [0..1]+ repeatQuantityRange: URG<INT.NONNEG> [0..1]+ /repeatDuration: PQ.TIME [0..1]+ agentAdministrationCareSettingTypeCode: CD [0..1]+ interruptibleIndicator: BL [0..1]

«DEPRECATED»+ purpose: ST [0..1]


PlannedEligibilityCriterionProtocol Representation

Sub-Domain::PlannedExclusionCriterion


PlannedInclusionCriterion


DefinedEligibilityCriterionAnswer

+ requiredIndicator: BL [0..1]

Protocol Representation Sub-Domain::DefinedObservationResult

+ value: ANY [0..1]+ valueNegationIndicator: BL [0..1]+ typeCode: CD [0..1]+ targetCodingSystem: OID [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLaterali tyCode: CD [0..1]+ confidentialityCode: CD [0..1]+ derivationExpression: ST [0..1]

0..*requires for eligibil ity

{be required for eligibil ity for}1 DEFINITION:

A reusable, "template" description of an allowable response to an eligibility criterion question.

PerformedInclusion/ExclusionCriterion• No distinct attributes or associations; No subclasses• PerformedActivity (no other names, notes):

• DEFINITION: An activity that is successfully or unsuccessfully completed. • EXAMPLE(S): CBC performed on a specific StudySubject on a given day. A scheduled blood

draw that is missed by a specific ExperimentalUnit on a given day.

• PerformedObservation (other names, notes empty):• DEFINITION: The completed action of observing, monitoring, measuring or otherwise

qualitatively or quantitatively gathering data or information about one or more aspects of a subject.

• EXAMPLE(S): lab test, taking vital signs, physical exam, specimen quality review, obtaining DNA sequence, genotyping a genetic variant, measuring the pH of a solution

• PerformedEligibilityCriterion (examples, other names, notes empty):• DEFINITION: One of a set of conditions that a study subject must meet in order to participate in

a study.

• PerformedInclusionCriterion (other names, notes empty):• DEFINITION: A characteristic or requirement that a subject must meet to participate in a study.• EXAMPLE(S): Must be over the age of 18

• PerformedExclusionCriterion (other names, notes empty):• DEFINITION: A characteristic or requirement that disqualifies a subject from participation in a

study.• EXAMPLE(S): pregnancy

class Performed Eligibility subclasses

ActivityStudy Conduct Sub-Domain::

PerformedActiv ity

+ /repetitionNumber: INT.POS [0..1]+ nameCodeModifiedText: ST [0..1]+ dateRange: IVL<TS.DATETIME> [0..1]+ dateRangeValidationCode: CD [0..1]+ /studyDayRange: IVL<INT> [0..1]+ /duration: PQ.TIME [0..1]+ /delayDuration: PQ.TIME [0..1]+ negationIndicator: BL [0..1]+ negationReason: DSET<SC> [0..*]+ /fastingStatusIndicator: BL [0..1]+ /medicalHistoryIndicator: BL [0..1]+ statusCode: CD [0..1]+ statusDate: TS.DATETIME [0..1]

Study Conduct Sub-Domain::PerformedObserv ation

+ methodCode: CD [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLateralityCode: CD [0..1]+ approachAnatomicSiteCode: CD [0..1]+ approachAnatomicSiteLateralityCode: CD [0..1]+ bodySystemCode: CD [0..1]+ bodyPositionCode: CD [0..1]+ /focalDateRange: IVL<TS.DATETIME> [0..1]+ /focalDuration: PQ.TIME [0..1]

Study Conduct Sub-Domain::PerformedEligibilityCriterion

+ notApplicableIndicator: BL [0..1]

Study Conduct Sub-Domain::PerformedExclusionCriterion

Study Conduct Sub-Domain::PerformedInclusionCriterion

AdverseEventOutcomeResult• AdverseEventOutcomeAssessment (has distinct association to AdverseEvent,

examples, other names, notes empty):• DEFINITION: The completed action of evaluating the final state of a subject who

experienced an adverse event, which takes place after the adverse event occurs.

• PerformedObservationResult (notes empty):• DEFINITION: The data or finding obtained by observing, monitoring, measuring or

otherwise qualitatively or quantitatively recording one or more aspects of a subject, experimental unit, system, or process.

• EXAMPLE(S): A blood chemistry result. A diagnosis of breast cancer. A pregnancy test result. A blood pressure measurement. Identification of nausea as an adverse event. The conclusion of an adverse event outcome assessment. The finding from an experiment. The data used as input to an experiment. Data produced by computation. An image annotation. The reformatting, transformation, semantic/syntactic normalization or downloading of data from public resources. A cell count. Neoplastic cellularity.

• OTHER NAME(S): Data, Data Acquisition Result, Finding

• AdverseEventOutcomeResult (other names, notes empty):• DEFINITION: The result of evaluating the final state of a person who experienced an

adverse event.• EXAMPLE(S): Recovered/Resolved, Recovering/Resolving, Not Recovered/Not Resolved,

Recovered/Resolved with Sequelae, Fatal, Unknown

class AdverseEventOutcomeResult

Adverse Event Sub-Domain::Adv erseEventOutcomeResult

Adv erse Event Sub-Domain::AdverseEventOutcomeAssessment

PerformedActivityStudy Conduct Sub-Domain::

PerformedObservation

+ methodCode: CD [0..1]+ targetAnatomicSiteCode: CD [0..1]+ targetAnatomicSiteLateralityCode: CD [0..1]+ approachAnatomicSiteCode: CD [0..1]+ approachAnatomicSiteLateralityCode: CD [0..1]+ bodySystemCode: CD [0..1]+ bodyPositionCode: CD [0..1]+ /focalDateRange: IVL<TS.DATETIME> [0..1]+ /focalDuration: PQ.TIME [0..1]

«Comment_Requested»Study Conduct Sub-Domain::

PerformedObserv ationResult

+ identifier: II [0..1]+ typeCode: CD [0..1]+ value: ANY [1...1]+ valueCodeModifiedText: ST [0..1]+ valueNullFlavorReason: ST [0..1]+ confidentialityCode: CD [0..1]+ uncertaintyCode: CD [0..1]+ baselineIndicator: BL [0..1]+ createdDate: TS.DATETIME [0..1]+ reportedDate: TS.DATETIME [0..1]+ comment: ST [0..1]

0..*

is a result of

{result in}

1

Performed-/DefinedRadiologyCTImaging Attributes to be HarmonizedAttribute Name Type DefinitioncontrastBolusAgent CD The text name of contrast/bolus agent given to increase visualization of structures and tissues during medical imaging.

contrastBolusRoute CD Text term to specify the administration route of a contrast/bolus agent.convolutionKernel ST Type of convolution kernel or algorithm used to reconstruct imaging data.ctPitchFactor REAL Numeric value representing the ratio of the Table Feed per Rotation to the Total Collimation Width.dataCollectionDiameter PQ Millimeter value for the diameter of the region over which data was collected as specified in DICOM tag.exposure PQ Current exposure of x-ray image in milliAmp seconds, as calculated from time and x-ray tube current, as specified in

DICOM tag.exposureTime PQ Value for the time of x-ray exposure expressed as number of milliseconds.focalSpotSize PQ Size of the focal spot as normally specified in DICOM tag, typically measured in millimeters.gantryDetectorTilt REAL Numeric degree value for the nominal angle of tilt of the scanning gantry. This value is not intended for mathematical

computations.kvp REAL Numeric value to represent the Kilovoltage Peak (kVp) reading as recorded in a DICOM tag.reconstructionDiameter PQ Numeric millimeter value for the diameter in millimeters of the region from within which data were used in creating

the reconstruction an image. Data may exist outside this region and portions of the patient may exist outside this region.

revolutionTime PQ Period of time required for a single complete turn of the source around the gantry orbit, expressed as a number of seconds.

sliceThickness PQ Numeric value to represent the nominal slice thickness of an image, expressed in millimeters.tableFeedPerRotation PQ Motion in millimeters of the table during a completion revolution of the source around the gantry orbit.tableSpeed PQ Numeric value to represent the distance, generally measured in millimeters, that the table moves in one second

during the gathering of data that resulted in an image.totalCollimationWidth PQ Width of the total collimation over the area of active x-ray detection, expressed as a number of millimeters (mm).

xrayTubeCurrent PQ X-ray tube current, generally expressed in MilliAmp(s), as specified in DICOM tag.

Image Attributes to be HarmonizedAttribute Name Type Definition

imageSeriesIdentifier II Unique identifier of a study series. {source: NCIA}

imageStudyIdentifier II A single set of characters used to identify, name, or characterize a radiographic technique used to evaluate a specific anatomic location for a specific purpose.NOTES:Recommend Class Concept be changed from C15206 (Clinical Study) to C63859 (Image Study) ImageStudy.instanceUID

imageType ST Text name to represent attributes important for image identification characteristics.

modality CD The type of equipment that originally acquired the data used to create the images in this series.

pixelSpacingHorizontal PQ Value to represent the physical distance between the center of each pixel, specified by a numeric pair - adjacent row spacing (delimiter), adjacent column spacing - expressed as a number in millimeters.

pixelSpacingVertical PQ Value to represent the physical distance between the center of each pixel, specified by a numeric pair - adjacent row spacing (delimiter), adjacent column spacing - expressed as a number in millimeters.

sopClassUID II Unique identifier specific for a Service-Object Pair (SOP) class, as specified in the DICOM standard.

sopInstanceUID II Unique identifer for a Service-Object Pair (SOP) instance, as specified in a DICOM tag.

subjectOrientationColumn CD Numeric value to specify the direction cosines of the first row and the first column with respect to the patient, as specified in the DICOM tag.

“empty” bridg classes first draft: may 29, 2015 last edited: june 1, 2015 prepared by wendy ver...

Documents