National Cancer Institute   U.S. National Institutes of Health www.cancer.gov
caBIG® Knowledge Center: A part of the Enterprise Support Network

CCTS COPPA Gap Analysis

From CTMS_WIKI

Jump to: navigation, search

Contents

Introduction

Background

The caBIG Clinical Trials Suite (CCTS) is an enterprise clinical trials system being designed primarily for use in trial sites. The suite is comprised of a collection of interoperable modules covering a broad range of key areas in cancer clinical trials management. These include patient registration via C3PR, patient scheduling via PSC, adverse events reporting via caAERS, lab analysis via LabViewer, and clinical data management via C3D. Integration between these applications is centered around five key scenarios: Study Creation, Register Subject, Load Labs in CDMS, Lab-driven AE Creation, and AE-Triggered Schedule Change. The implementation is based upon the caGrid infrastructure with caXchange as the Enterprise Service Bus for reliable message routing and GAARDS providing robust security.

Scope

This document analyzes the potential gaps between the planned functionality of the January, 2009 release of COPPA and the needs of CCTS 2.0. The primary focus is on informational semantics and service semantics. At the time this document was written, the information model and services of COPPA could be found at:

This document is a work in progress used strictly for planning for the CCTS 2.0 release. Up until that release, it could be altered in any way.

Related Documentation

End User Technical CCTS Architecture Guide
Analysis Planning

C3PR

Information Model

General

Is the COPPA model an analysis model, implementation model, or something else (information model?)?

All 3. From Service perspective – we are working in the Information model – Draft3

In some cases the associations have directionality and in some cases they do not. In some cases the association ends are named, in others they are not. It appears that in all cases, cardinality is defined.

being cleaned up

There does not appear to be a tight link between Organization and II. We have this in C3PR (for Organization-assigned identifiers) and see this as a potential gap.

The identifiers assigned by other Organizations are captured in IdentifiedEntity role

What is the scope attribute of II used for?

Scope is an HL7 attribute that has HL7 terminology defined against it with values like -- BUSN, OBJ, VER, VW. I don’t think we have exactly figured out it’s usage.

Persons

C3PR has Investigators and Research Staff. It appears that the core attributes of these Persons map well with COPPA Persons. For example, the following attributes seem to map appropriately:

  • Name
  • Postal Address
  • Email Address
  • Telephone Number
  • Fax Number

It appears that an Investigator in C3PR can be mapped to a Person with a Structural Role of Health Care Provider. It appears that Research Staff in C3PR can be mapped to a Person with a Structural Role of Clinical Research Staff.

sounds right, in COPPA a Health Care Provider is a licensed physician with a MD, DO, etc. The requirement as we understand is that for Treatment trials, a study investigator MUST be a Health Care Provider, whereas for Observational trials, they do not need to be. Observational trial PI’s could be Nurses, other researchers, etc. and therefore a Clinical Research Staff for COPPA

We have identified the following potential gaps/inconsistencies in the model related to Persons:

  • Does Maiden Name map appropriately into EN.PN?
  • C3PR Research Staff and Investigators have assigned NCI Identifiers. The identifier attribute in COPPA at the Structural Role class appears to identify the Role, not the Person. We don't see any easy way to mitigate this gap with the current COPPA model.

CTEP Identifiers for Persons are captured thru the Identified Entity class

Structural Roles appear to be work in a similar fashion between C3PR and COPPA. However, I do not see an apparent way to represent some of the roles in C3PR. C3PR currently has the following roles for Research Staff:

  • System Administrator
  • Site Administrator
  • Study Coordinator
  • Registrar

How do these map to the COPPA model?

these could potentially become StudyParticipation.functionCode values. Each needs evaluation

Functional Roles seem to map appropriately.

C3PR has a notion of Groups of Investigators. This seems not be supported by the COPPA model.

GAP

Organizations

The core attributes of Organizations seem compatible. For example:

  • Name
  • Description
  • Postal Addres

It is not clear where NCI Identifier in C3PR for an Organization would be placed in the COPPA model. It appears that Organization.identifier may be appropriate for this.

CTEP Identifiers for Organizations are captured thru the Identified Entity class. Organization.identifier is a unique identifier assigned by NCI Enterprise

In C3PR we don't really have the notion of a Structural Role for an Organization. However, we do have the notion of a Functional Role, which includes:

  • Coordinating Center
  • Funding Sponsor
  • Participating Site

It is not clear to me how these map to COPPA Organization Roles nor how they are appropriately tied to a Study. In C3PR, any Organization can take on one or more of these roles in a Study. However, it seems that you have to create Structural Roles for each of these before creating Functional Roles. I am not sure this is the optimal way or appropriate way to model this (at least from a C3PR perspective).

Coordinating Center is broken down into it’s functions – Data Center, Stat center, Protocol Mgmt., Registration center – these are values of StudyParticipation.functionCode. The rules for which Structural role can take on which Functional role are documented on the Information model as a note.

Studies

Issues with the structure of the study:

  • Clearly missing Epochs - we can have different arms on different epochs. Same with stratum groups.
    GAP
  • Stratum groups in C3PR are actually broken into stratification factors with questions. We cannot consume of StratumGroups alone.
    GAP

Issues with attributes/classes:

  • assignedIdentifier - we allow for multiple identifiers
    IdentifiedEntity?
  • participatingOrganizationTypeCode - can we use this for multi-site indicator?
    No longer in the Study class
  • StudyResourcing - we can use this for funding sponsor, though we only capture one - or do we get it from StudyParticipation?
  • How should we differentiate StudySiteInvestigator and StudyInvestigator? In C3PR we only have Study Site Investigator
    Study Investigator would be the Study level PI – sounds like C3PR may not need this
  • There is no amendment/protocol version? Is StudyProtocol.revision the same as this?
    GAP, not in current COPPA scope. Planned for next coming release
  • PlannedEligibilityCriterion seems to map to our eligibility criteria. Each of these instances seems to be a separate question. Why then would you capture eligibleGenderCode for each question? What is operator? How is it used?
    EligibleGenderCode is a CT.gov requirement. Operators =, <, >, etc. The thought here is to see if we can capture eligibility criteria in a computerized fashion. We are testing it out. For example,
    • Eligibility Criteria Name: WBC
    • Operator: =
    • Criteria Value: 1000uom
    • Criteria Type: Exclusion
    • Criteria Description: free text to write the eligibility criteria as in the Protocol document
  • It appears we can use blindingSchemaCode to determine whether the study is blinded. However, does it have a value that means not blinded? We don't appear to use blindedRoleCode
    the value of blindingSchemaCode and blindedRoleCode are from Ct.gov – one of the values is Open that you can use:
    • Open: no masking is used. All involved know the identity of the intervention assignment.
    • Single Blind: one party, either the investigator or participant, is unaware of the intervention assignment; also called single-masked study.
    • Double Blind: two or more parties are unaware of the intervention assignment
  • We don't have maximumTargetAccrualNumber or monthlyTargetAccrualNumber - should we?
    CT.gov requirement – does C3PR have this req.?

Some items that look like good overlap:

  • We can get coordinating site and participating sites from StudyParticipation
  • targetAccrualCeiling
  • phaseCode
  • etc.

Services

General Interfaces

It is not clear how fully filled object graphs are when they are retrieved from a service call. In an ideal case, they would be pretty fully filled. However, this seems unlikely, and in that case, it would be best if there is a higher level service that can wrap these.

It is not clear how one would get notifications of changes to the domain objects. For COPPA to be the source of truth, it is imperative that we are able to get updates when something changes (say, the name of an investigator changes).

Does a query with all empty attributes return all the objects? How is the performance for this type of query? Is it possible to iterate over results rather than get them all at once?

What is a ConformanceProfile, and how is it used?

C3PR Workflow

I believe that the workflow for most (all?) of the CCTS use cases will be:

  1. Download all objects and store locally - one time event
  2. Register for notifications
  3. Update/add local objects when notified

I believe that we can use just the Person Service Query and Organization Service Query interfaces as long as we are notified of changes to Roles and can retrieve them. However, it is not completely clear whether this is sufficient or we need to use the Person and Organization Correlation Service and the Person Organization and Study Protocol Service. The same should go for Study.

This workflow gets more complex when C3PR wants to be selective about the entities it imports. This occurs when COPPA has more information than is immediately needed (e.g. Persons from Organizations that are not being used in C3PR, Studies that are not being run through that instance of C3PR, etc.). In this case, there may need to be functionality to selectively import entities and act selectively on notifications.

Amendments

It does not appear that COPPA handles Study Amendments, which is a critical workflow in C3PR.

LabViewer

General Questions: - Will patient-level lab data be part of COPPA (under Activity)?

Information Model

For the LabViewer project, it appears that we will access the following classes and attributes from COPPA:

StudyProtocol

  • phaseCode: CD
  • assignedIdentifier (does this map to the Identifier extension for Study?)
  • publicTitle / officialTitle (which of these maps to ShortTitle and LongTitle of the Study?)
  • StudyOverallStatus -- statusCode

Study Resourcing

  • organizationIdentifier (can we use this for sponsor code? or do we need to get it from StudyParticipation?)

StudyContact

  • StudyInvestigator -- identifier

OrganizationRole

  • HealthCareFacility -- identifier

ObservationalStudyProtocol - if the message contains this information, we populate this in CTODS LabViewer database.

Services

PlannedActivity

Assuming that lab data falls under the definition of planned activity, LabViewer would retrive laboratory data through the PlannedActivity Service of COPPA.

StudyProtocolQuery

LabViewer would request the Study information through the StudyProtocolQuery Service of COPPA. Question: Does Organization information come along with the Study information? LabViewer needs the organization info for the study.

PSC

Person

The only persons within PSC are either subjects or users of the system. COPPA does not seem to represent the subjects on a study, and we do not anticipate using COPPA for user management.

Organization

PSC's concept of StudySite is in COPPA. PSC captures a minimal set of data regarding sites, so COPPA is more complex than is needed by PSC. The most significant example of data represented in COPPA buy not PSC is "lead organization."

Protocol Abstraction

Are we supposed to be able to represent our templates in terms of this model? COPPA appears to be an arbitrary subset of classes in BRIDG and is insufficient for representing a PSC study template. Most significantly, Study Segments and Epochs are missing. As is the case with C3PR, amendments are an important part of the PSC model.

If we are simply meant to query the existence of a protocol or a protocol's relationship to a site, the COPPA model should be fine.

caAERS

General

Most of the objects from caAERS are found in COPPA logical model. There are some differences as far as the associations between these objects are concerned in COPPA model. At number of places the association is through some intermediate objects in COPPA model, whereas in caAERS, these associations are more direct. For example, caAERS does not have objects like “Functional Role” and “Structural Role” but caAERS still incorporates these concepts in other fashio and has counterparts of these objects. Organizations and Persons assume these roles with more direct association and not the way it is modeled in COPPA.

The definitions of some of the objects are quite exhaustive, whereas caAERS just has a subset of these attributes in an object definition. There seems to be a general confusion about the II data type. According to information model, “Person” can only have one identifier. But Analysis model allows for multiple identifiers through the association of identifiedIdentity. If COPPA information model is to be followed then there is a substantial gap in the approach the way caAERS handles the identifiers for “Person”, “Study” and “StudyParticipantAssignment”. caAERS allows for multiple identifiers for these objects. But the definition of identifier is pretty close to what is there in caAERS.

The specific gaps with objects and services are discussed further in details in following sections.

Gaps specific to Objects

Gap specific to Person

caAERS has the notion of Participant, Investigator and ResearchStaff. All these objects are sub types of Person Object, which has the following attributes

  • Address
  • First name
  • Last name
  • Middle name

All these attributes seem to map appropriately. But how will one map “Middle Name”? Is it to be mapped to EN.PN?

Other attributes such as gender and race, which are specific to Participant, also seem to map appropriately with COPPA model but ethnicity can’t be mapped to any attribute.

It appears that an Investigator in caAERS can be mapped to a Person with a Structural Role of Health Care Provider. It appears that Research Staff in caAERS can be mapped to a Person with a Structural Role of Clinical Research Staff.

We have identified the following potential gaps/inconsistencies in the model related to Persons:

  • Does Maiden Name map appropriately into EN.PN?
  • Does Middle Name map appropriately into EN.PN?
  • How does one map ethnicity and date of birth for a person?
  • caAERS Research Staff and Investigators have assigned NCI Identifiers. The identifier attribute in COPPA at the Structural Role class appears to identify the Role, not the Person. We don't see any easy way to mitigate this gap with the current COPPA model.

Structural Roles appear to be work in a similar fashion between caAERS and COPPA. However, there does not seem an apparent way to represent some of the roles in caAERS. caAERS currently has the following roles for Research Staff:

  • System Administrator
  • Site Administrator
  • Study Coordinator
  • Subject Coordinator
  • StudySite Coordinator

How do these map to the COPPA model?

Functional Roles seem to map appropriately though.

Gaps specific to Organization

The core attributes of Organizations seem compatible. For example:

  • Name
  • Description

It is not clear where NCI Identifier in caAERS for an Organization would be placed in the COPPA model. It appears that Organization identifier may be appropriate for this.

In caAERS we don't really have the notion of a Structural Role for an Organization. However, we do have the notion of a Functional Role, which includes:

  • Coordinating Center
  • Funding Sponsor
  • Study Site

All these roles are incorporated in caAERS by sub typing StudyOrganization object. It means that an organization can participate in a conduct of study in various aforementioned roles.

It is not clear as to how these map to COPPA Organization Roles or how they are appropriately tied to a Study. In caAERS, any Organization can take on one or more of these roles in a Study. However, it seems that you have to create Structural Roles for each of these before creating Functional Roles.

Other roles in caAERS that a person can assume are as follows

  • Study Investigator
  • Study Site Investigator

These roles have three context involved in defining these roles 1) Study 2) organization 3) Investigator roles itself. There seem to be similar notion in COPPA but it can only be achieved through a complex navigation of association. It navigates from Study to Functional Role to Organization Functional Role to StudyParticipation to StudyParticipation contact to StudySiteInvestigator. This is a very complex way to define these types of roles. caAERS does the same thing but in much simpler fashion.

Gaps specific to Studies

In general, the study definition in COPPA has lot more attribute than caAERS captures but at the same time there are few attributes that we have to find the mapping for.

Issues with attributes/classes:

  • assignedIdentifier - we allow for multiple identifiers
  • AECodingSystem – does it mean like MedDRA or CTCAE?
  • participatingOrganizationTypeCode - can we use this for multi-site indicator?
  • StudyResourcing - we can use this for funding sponsor, though we only capture one - or do we get it from StudyParticipation?
  • The concept of EPOCH is not there in COPPA model
  • There is no attribute about Diseases terminology
  • Does Study Agent maps to StudyIndlde?

Gaps specific to Adverse Event

I did not see anything related to AdverseEvent in COPPA model. And I think it is out of scope.

Gaps specific to Services

If the goal is to use COPPA services as a source of truth then not only the use of person, protocol and organization services is warranted but there is a need to use to correlation services in order to keep the data in sync.

Once the data is brought to caAERS, the data has to be updated in caAERS as soon as there is a change in the data in COPPA. For that, just the usage of the services is not enough but we need to get clarity on the notification scheme between caAERS and COPPA.

The gap analysis above raises some concerns about the use of these services, as there are still some missing mapping between caAERS and COPPA model. For effective use of these services, it is essential that we first map these missing attributes.

C3D Connector

General

For the most part, the CDMS receives data from external sources and does not use "GET" methods for data aquisition. The C3D Connector acts as a data push gateway to the CDMS, C3D.

General Questions/Concerns:

  • Is the COPPA Informational Model based on the BRIDG 2.1 Model?
  • Are there entities for StudySubject?
    • Services for StudySubject?
    • Is the idea of StudySubject only related to a Person (Human)?
  • How are Subject identifiers related to Studies, or is this only maintained with C3PR?
  • Are there services for deletetion/rollback?
KC Projects