Functional Equivalence Between the Aecg and Ctlab Rmims

MAP TO A SPECIFIC CLASS IN BRIDG IN PREFERENCE TO MAPPING TO GENERAL CLASSES (RMActivity, RIMActivityRelationship, etc.)

Functional Equivalence Between the aECG and CTLab RMIMs and BRIDG /
aECG Class / CTLab Class / BRIDG Class / COMMENTARY /
The following set of classes detail the acts being performed to prepare the material to be observed for purposes of generating “results”.
AnnotatedECG (act/OBS) / Accession (act/ACSN)
(author) Agent (role)
BaseSpecimenDefinition (act)
BaseSpecimen (role)
ContainerRegistration (act/CONTREG)
NaturalMaterial (entity)
SpecimenCollectionProcedure (act/PROC) / BT: RIMActivity
E&R: Role
BT: RIMActivity
E&R: Role
BT: RIMActivity
E&R: Entity
BT: RIMActivity
RelativeTimepointEvent (act) / ProtocolSpecimenCollection (act/PROC) / DC: StudyActivityRef / Design Concepts area of BRIDG not clear on how to handle nested planned tasks. DC: PlannedTask should probably have a recursion, with StudyActivityRef pointing to the definition of a leaf-level act.
ProtocolTimepointEvent (act) / ProtocolStudyEvent (act/CLNTRL) / DC: PlannedTask
ReferenceEvent (act) / ReferenceEvent (act) / DC: StudyActivityRef
TimepointEvent (act) / StudyEvent (act/CTTEVENT) / DC: ProtocolEvent?
(has no links to participants in BRIDG)
(performer) StudyEventPerformer (role) / (E&R:ActivityRoleRelationship thru new association) E&R:Role
no author of a DC: ProtocolEvent in BRIDG
Person (entity shadow - player) / E&R:Entity
SubjectAssignment (act) / SubjectAssignment (act/CLNTRL) / BO: RandomizationAssignment / this class needs to be integrated with the others in BRIDG for purposes of defining required business functionality
TreatmentGroupAssignment (act) / randomizationCode attribute of BO:RandomizationAssignment
(subject) TrialSubject (role) / (recordTarget) EnrolledSubject (role)
(recordTarget) ScreeningSubject (role)
(playedRole) ScreeningSubject2 (role)
(playedRole) SpareSubject (role) / (E&R:ActivityRoleRelationship thru new association) E&R:Role
no subject/recordTarget of a BO:RandomizationAssignment in BRIDG / subject id appears in many individual BRIDG classes. These will all be relationships to a subject role in HL7.
BRIDG does not enumerate “participations”. When it does, it needs to have the notion of “Record Target” as a participation.
DemographicPerson (entity) / Person (entity) / E&R: Entity/LivingEntity/Person
For CTLab, the overall ClinicalTrial act is “unrolled” into three components – the trial as a whole (ClinicalTrial), the portion of the trial being done at a particular site (TrialAtSite), and the portion of the trial being done by a particular investigator at a particular site (InvestigatorAtSite). Because these represent partitions of the overall trial, they all have the classCode “Clinical Trial”. This unrolling was done to expose, in the HL7 standard, the hierarchical structure explicit in the CDISC Lab Model. Exposing this structure will, in the future, allow information specific to each of these partitions (e.g., enrollment statistics) to be captured, although that capability is not exploited in either the CDISC Lab model or CTLab standard today.
For aECG, there is not likely to be a need to expose this information in the future, so the “Clinical Trial” act was not unrolled. Instead, the particular Site and Investigator appropriate to the AnnotatedECG are attached to the trial as a whole for that ECG. This is possible not only because no partition details are anticipated, but also because ClinicalTrial is not the root class of this message (as it is in CTLab) – which allows this class to appear many times in a single transmission of this payload.
ClinicalTrial (act/CLNTRL) / ClinicalTrial (act/CLNTRL)
TrialAtSite (act/CLNTRL)
InvestigatorAtSite (act/CLNTRL) / BO: Study
-- OR --
E&R: Study
ClinicalTrialProtocol (act) / Plans: ProtocolPlan
(author) ClinicalTrialSponsor (role) / if using BO:Study - E&R:Role (thru BT:RIMActivity/ E&R:ActivityRoleRelationship)
if using E&R:Study – E&Role (thru E&R:ActivityRoleRelationship)
Organization (entity) / E&R: Entity
(location) TrialSite (role) / (location) TrialSite (role) / for BO:Study - E&R:Role (thru BT:RIMActivity/ E&R:ActivityRoleRelationship)
for E&R:Study – E&Role (thru E&R:ActivityRoleRelationship)
Location (entity) / Site (entity) / E&R: Entity
(responsibleParty) TrialInvestigator (role) / (responsibleParty) TrialInvestigator (role) / for BO:Study - E&R:Role (thru BT:RIMActivity/ E&R:ActivityRoleRelationship)
for E&R:Study – E&Role (thru E&R:ActivityRoleRelationship)
Person (entity shadow) / NamedPerson (entity) / E&R: Entity
(location) TestingSite (role) / (location) TrialSite (role – by context conduction) / E&R: Role
Location (entity shadow) / Site (entity – by context conduction) / E&R: Entity
RelatedObservation (act-control variables only) / AgeAtVisit (act/OBS)
FastingStatus (act/OS) / BT:StudyDatum
(author) AssignedEntity (role shadow) / no author of a BT:StudyDatum in BRIDG
BT:StudyDatum s/b related to E&R:ActivityRoleRelationship
FindingComment (act) / SpecimenComment (act/OBS) / BT: StudyDatum
(author)AssignedEntity (role shadow) / (E&R:ActivityRoleRelationship thru new association) E&R:Role
Note: the set of acts “Series/SequenceSet/Sequence” in aECG and the set of acts “BaseBattery/BaseUnitaryResult” in CTLab are functionally equivalent. All record what is commonly called a “result”. Each “unrolls” the overall result of testing on the tested material (an ECG and a Specimen, respectively) using the appropriate test/result types for the material.
Roles (e.g., author) and related acts (e.g., related observations) that apply to overall testing are distributed as appropriate to each of the “unrolled” acts. Thus “authoring” is done at the “Series” level in aECG, and at the “BaseUnitaryResult” level in CTLab. These two “authoring” participations are functionally equivalent because they both derive from the notion of “authoring” of an overall testing act, although they are applied at different depths in the unrolling of that act in the two specifications. Note also that the same overall-related role or act can appear repeatedly in the “unrolled” acts, but need not appear at evey level. Thus in aECG, “authoring” is captured at the Series level and at the AnnotationSet level, but not at any of the others. In CTLab, “performing” is captured for the BaseUnitaryResult, but not for the BaseBattery.
Series (act)
SequenceSet
Sequence / BaseBattery (act)
BaseUnitaryResult (act) / DC:EventTask
DC:EventTask
BT: StudyDatum / DC:EventTask needs recursion
(author) SeriesAuthor (role) / (E&R:ActivityRoleRelationship thru new association) E&R:Role
no author of a DC:EventTask in BRIDG
SeriesDevice (entity-player) / E&R:Entity
Organization (entity shadow-scoper) / Laboratory (entity) / E&R:Entity
(secondaryPerformer) SeriesPerformer (role) / (performer) Agent (role-performer of BaseUnitaryResult) / (E&R:ActivityRoleRelationship thru new association) E&R:Role
no secondaryPerformer of a DC:EventTask in BRIDG
Person (entity shadow-player) / E&R:Entity
SequenceSet (act)
Sequence (act)
ControlVariable (act) on Sequence / BT: StudyDatum
ControlVariable (act-shadow) on Sequence Set / BT: StudyDatum
ControlVariable (act-shadow) on Series / BT: StudyDatum
ROI (act) / BT: StudyDatum
Boundary (act) / BT: StudyDatum
AnnotationSet (act) / DC:EventTask
Annotation (act) / ToxicityGrade (act)
TestComment (act) / BT: StudyDatum
BT:StudyDatum
ROI (act reused) / BT: StudyDatum
Boundary (act reused) / BT: StudyDatum
ControlVariable (act shadow) / BT: StudyDatum
(author) AssignedEntity (role) / (E&R:ActivityRoleRelationship thru new association) E&R:Role
Person (entity-player choice) / E&R:Entity
Device (entity-player choice) / E&R:Entity
ManufacturedDevice (role) / E&R:Entity
Organization (entity shadow-scoper) / E&R:Entity
AuthoringOrganization (entity-scoper) / E&R:Entity
(played role)IdentifiedEntity (role) / E&R:Role
ReportToSite (act) / BT: RIMActivity
Range (act) / BT: StudyDatum

BRIDG CLASSES ORGANIZED FOR MAPPING

NOTES ON THE MAPPING

Some BRIDG characteristics make it difficult to determine whether the concepts in the CTLab and aECG RMIMs are adequately and accurately represented in BRIDG.

- BRIDG is a combination of business requirements, and style preferences or application approaches for representing those business requirements. For example, BRIDG asserts that the association between two acts (Basic Types: ActActRelation) can be represented in one of four ways: 1) using a RIM-style ActRelationship (Basic Types: RIMActivityRelationship), 2) using an OID reference (Design Concepts: StudyActivityRef), 3) using a Sequential Analysis Strategy or 4) using an Abstract Rule. However, the model further asserts that Design Concepts: PlannedTask uses exclusively StudyActivityRef to define subactivities; Statistical Concepts: Analysis uses exclusively SequentialAnalysisStrategy to link acts together; and Basic Types: RIMActivity uses exclusively RIMActivityRelationship to link acts together. The business requirement is that acts be linked together, which is embodied in ActActRelation. Thus all requirements to link acts together should refer to ActActRelation, which would allow each requirement to use any style or method as appropriate.

- BRIDG classes are at a variety of levels of abstraction

o RIMActivity; RIMActivityRelationship; ActivityRoleRelationship; Entity are present along with specific actions (as detailed as ActivityDerivedData) and dedicated relationships among those actions

o very specific actions (e.g. E&R: Study) have association to the very general ActivityRoleRelationship, Role and Entity classes – so that although the specific action is recognized, the appropriate participations, roles and players have not been.

-  There are multiple representations of the same, or essentially the same, concept

- BRIDG has very few classes representing the performance of planned activities, beyond collection of observations and findings.

The E&R: Study act associated with E&R: ActivityRoleRelationship is an example of a BT: RIMActivity. The multiplicities seem to be wrong (there should be more than one ActivityRoleRelationship associated with a study; but each ActivityRoleRelationship should be limited to a single study). Unless the multiplicities are actually correct, E&R: Study should be removed from the model.

E&R: Role should include ClinicalResearchSubject. The HL7 “subject” participation is a general use of the term, and should not be confused with the specific role of a person participating as record target in a clinical trial. This role id must be used in many situations beyond the assignment of a person to a study. For example, real-time observations will be tagged with this id – and since it is globally unique there will be no need to include any further study information. Note that, once used for a particular participation (e.g. for the participation id of a person in a study), the same id cannot be used for any other participation (i.e. it cannot then be used as the id for a participation in an individual observation, even if the participation.typeCode is also “subject”).

Why is Protocol Concepts: DesignCharacteristics modeled as a role?

Why isn’t Plans: Protocol/Plan connected to PC: StudyDocument and/or BO: Study?

Classes in BRIDG of interest to CTLab and aECG standards:

Acronymns used here for partitions of BRIDG

DC (Design Concepts) Plans BT (Basic Types) BO (Business Objects)

PC (Protocol Concepts) SC (Statistical Concepts) PS (Protocol Structure) E&R (Entities And Roles)

SDDC (Study Design and Data Collection)

Classes/relationships in bold italic are on the BRIDG “Events” diagram prepared for this presentation.

.

DC: StudySchedule <PROPOSED> Container Element which defines a study schedule. There can be multiple schedules associated in a study. Each may be associated with one or more arms

(owns part) DC: ProtocolEvent <PROPOSED> Base of all study events that are calendarized events. If they are non overlapping sequential events such as visits, then they are contained in an ordered collection by Element. If they can span Elements or are unordered they are contained at the schedule level. Events of this type are "daily dose" to which might be attached the task "aspirin"

(owns part) DC: UnscheduledEvent <PROPOSED> An unschedule event, such as an SAE may have a collection of associated tasks to be performed. It is unscheduled, but still expected to occur

(owns part) DC: Element <PROPOSED> This maps to a CDISC element, but I we have used the term element elsewhere.

(owns part) DC: Element (recursion)

(owns part) DC: ProtocolEvent

(owns part) DC: Arm undefined

(owns part) DC: Element

(part of) Plans: Protocol/Plan <PROPOSED> A representation for the events, timing, milestones, resources and participations needed to achieve the goals of a study.
The description of planned activities to assemble study resources, execute the study, and analyse and report the study. Includes Logistics Plan.
A detailed formulation of a program of action.

(has part) DC: PlannedTask <PROPOSED> An activity whether planned or unplanned that is performed in the context of a protocol event. The granularity maps to a CPT code, and therefore is often not 1:1 with an observation. A single task may result in multiple subtasks or observations. Hence StudyActivityRef
Task does not need to be an abstract activity because as a concept it has no linkages to time, order, origin. Only instances of that task, or children of that task to.

(owns part) DC: StudyActivityRef <PROPOSED> An object in the planning mood that defines an instance of a specific subtask or subactivity that is going to be conducted in the planning mood

(defined by) DC: StudyActivityDef <PROPOSED> The base class of definitions for the finest granularity task components we will be tracking. These are essentially the smallest quantifiable output or unit of work within a task.

(1..*) DC: EventTask <PROPOSED> The intersection between a discreet Planned Task and a Study Event whether scheduled or not. It describes how the task is to be performed at this point. In the execution mood, this relation generates one or more studyData, depending on whether the PlannedTask is 1:1 with an intervention/observation, or is 1:*

(has part) BT: StudyDatum <PROPOSED> The base class of instances of study variables. Derived types can be Observations, Findings, AnalysisVariables, SummaryStatistics, etc.

(specialization) BT: AnalysisVariableInst undefined

(specialization) DC: SubjectDatum (subjectID) <PROPOSED> An Atomic Data Instance, or Confirmation of an actual Intervention. Maps to an ODM ItemData and only exists in the execution mode. Must refer to a valid StudyVariable some type

(specialization) DC: Observation (trxType) undefined

(specialization) DC: DiagnosticImage undefined

(specialization) DC: TreatmentConfirmed undefined

(defined by) DC: StudyActivityDef

(specialization) BT: StudyVariable <PROPOSED> Any quantity that varies; any attribute, phenomenon or event that can have different qualitative or quantitative values. Could be input to or output from a statistical method and can be collected or derived. In particular, summary statistics are also variables.
Endpoint is a special case of an AnalysisVariable.
Note, this class defines a type of variable, but does not represent an instance. StudyDatum is the instance class - with an ID referencing the defining StudyVariable.

BO: Study <PROPOSED> A systematic evaluation of an observation or an intervention (for example, treatment, drug, device, procedure or system) in one or more subjects. Frequently this is a test of a particular hypothesis about the treatment, drug, device, procedure or system. [BRIDG] A study can be either primary or correlative. A study is considered a primary study if it has one or more correlative studies. A correlative study extends the objectives or observations of a primary study, enrolling the same, or a subset of the same, subjects as the primary study.
A Clinical Trial is a Study with SubjectType = "human". Pre-clinical Trials may have subjectType "non-human", "animal", or "rat".