Protocol Amendments

[dih-cdisc]

Need to ensure that M11 protocol amendments can be supported. Three aspects

1. Amendment support aligns with the updated M11 specification
2. Ensure we can support the detailed rationale for changes. Note we dont need exact details of change as an electronic comparison can be made (see #305)
3. Align with any review comments on Organizations arising from release 3.6. This overlaps because of the need to note enrollment at the time of an amendment being approved.

Item	Ticket
Model	#473
CT	#474
API	#475
Rules	#477
IG	#476
Test Data	#478
Associated Tickets	#305, #264

[BSnoeijerCD]

GeographicScope and dates

Considerations:

• The scope is a direct feature of an amendment according to M11. At the same time it is the feature of the study Version (date) that links to the current amendment. We have included that based on the governance date of the studyVersion.
• An amendment is a feature of a study version. We do not want to include multiple versions of a study in the USDM (using a previous attribute in StudyVersion) as all other classes are nested in the StudyVersion class and that would require to keep submitting all information of previous versions. At the same time we want to store dates, scopes and current enrollment of each amendment which is also required by M11.
• Enrollment, geographic scope and signature dates are all directly related and linked to 1 version of the study/amendment. All three features are required for the amendment history.
• We now have a versionIdentifier in StudyVersion and a StudyAmendment.number which (partly?) overlapping.

Based on this I will propose an idea at the scrum today.

[BSnoeijerCD]

Based on the template, the protocol requires: Front page(s)

• Original Protocol identifier
• Version number
• Version Date – (without a scope)
• Amendment identifier (if applicable)
• Amendment scope (global / country(ies) / region(s) / site(s) )
• Sponsor approval date

Current amendment

• Approximate number/percentage enrolled at time of approval
• Reason(s) for amendment (primary/secondary) o Select closest match / if none apply – choose “other”
• Summary
• Substantial impact on safety or rights of participants
• Substantial impact on reliability and robustness of the data generated in the clinical trial
• Changes o Description o Brief rationale o Section # and Name

Paragraph 12.3 Prior Protocol Amendments

• Summary of changes from previous amendments
• Keep number/percentage enrolled at time of approval
• Listing approximate enrolment by cohort in an option
• The overview of changes from all prior protocol amendment (i.e. description, brief rationale, section # and name)

[BSnoeijerCD]

@dih-cdisc @czwickl @EMuhlbradt @ASL-rmarshall See points to consider for amendments in the comment above. Below the suggested changes. Some points of discussion for scrum today:

• Scope linked to date/direct?
• Date types
• Substantial impact types - separate class? or two attributes?

[daveih]

Suggestions

Impact Class

Make impact a separate class, AmendmentImpact, with attributes

• rationale: string
• substantial: boolean
• type: Code (code list extensible, SafetyRights and ReliabilityRobustness)

This will allow for the two substantial impacts but allow sponsors to add other impacts (substantial or non-substantial) if they wanted.

Geographic Scope

Rather than GeographicScope having a type of 'site' which just feels wrong, keep the existing SubjectEnrollment appliesTo to the StudySite class, feels like a more consistent approach (enrollment statistics apply to either a geographic scope, or a cohort or a site and only one of them).

The site will thus need some geographic info. Site could be an Organization in its own right (type = StudySite) and thus an address or could explicitly state the site's geographic location using a AliasCode attribute (or point at GeographicScope)

Governance Dates

For governance date the referring class provides the context for a date, we might want to consider 'Approval Date' and 'Effective Date' for the code list which then gives:

• StudyVersion Approval
• Amendment Approval
• Document Approval
• StudyVersion Effective
• Amendment Effective
• Document Effective

Thus, from an implementation perspective, from a Document class for example it is "give me my (the document's) effective date"

Might also be useful to nice to have an 'Issued Date' or something similar, for draft versions?

[BSnoeijerCD]

@EMuhlbradt @czwickl @dih-cdisc @ASL-rmarshall See below the updated StudyVersion/amendment part of the data model based on the discussions today. Note that the boolean attribute substantialimpact has been deleted from the studyAmendment class and has been replaced by a relationship called 'substantialImpacts to the new StudyAmendmentImpact class.

[BSnoeijerCD]

corrected small typo in substantialImpacts and pushed UML to Github

[dih-cdisc]

@BSnoeijerCD @EMuhlbradt @ASL-rmarshall @czwickl

Have a think about the name of the relationship from StudyAmendment to StudyAmendmentImpact labelled 'substantialImpacts'. The 'substantialness', if there is such a word, is. incorporated in the 'substantial' attribute of the Impact class. It was to allow a sponsor to add their own 'impacts' that they may not consider substantial in addition to the ones required by M11. Has the downside that you need to set the flag True for the M11 ones. Anyway, the relationship might be better named 'impacts' or something along those lines.

[BSnoeijerCD]

@BSnoeijerCD @EMuhlbradt @ASL-rmarshall @czwickl

Have a think about the name of the relationship from StudyAmendment to StudyAmendmentImpact labelled 'substantialImpacts'. The 'substantialness', if there is such a word, is. incorporated in the 'substantial' attribute of the Impact class. It was to allow a sponsor to add their own 'impacts' that they may not consider substantial in addition to the ones required by M11. Has the downside that you need to set the flag True for the M11 ones. Anyway, the relationship might be better named 'impacts' or something along those lines.

Good point. For background info, I just found a related protocol reference Article 10(a) of Directive 2001/20/EC of the European Parliament:

[ASL-rmarshall]

@BSnoeijerCD It's interesting that, according to that Article, it's the amendments that are substantial, not the impacts. If M11 is trying to implement that Article, the resultant M11 questions aren't quite accurate.

[BSnoeijerCD]

@dih-cdisc @czwickl @EMuhlbradt @ASL-rmarshall I made the updates as discussed during scrum today. This includes some cardinality changes. See diagram below:

[ASL-rmarshall]

@BSnoeijerCD @EMuhlbradt A couple of thoughts triggered by looking at the new country relationship from StudySite:

• This relationship looks like it's intended to be defined in the same way as the country relationship from Address - i.e., it goes to Code and am I right to assume that the expectation is that the ISO 3166-1 alpha-3 codelist will be used?

• The code relationship from GeographicScope looks like it might perform a similar function when GeographicScope.type = "Country" but, in this case, the relationship is to AliasCode and the CT file says:

  Point out to external dictionaries: Standard code is ISO-3166; Alias codes drawn from GENC, UN Region Codes, etc.

  However, I don't think this will work because the code relationship is also used to identify regions when the GeographicScope.type = "Region" (hence the reference to "UN Region Codes"). In order to use AliasCode, you must specify a standard codelist and always provide a standard code from that codelist - but the ISO-3166 codelist does not contain the type of region codes we need for geographic regions. I think we probably just need to change the comment in the CT file to say:

  Point out to external dictionaries: Standard code is ISO-3166-1 alpha-3 for countries and UN Region Codes for regions; Alias codes drawn from GENC, etc.

  We might then need a rule to ensure the correct standard coding for countries vs regions - but we'd need to define what's checkable for ISO 3166 vs UN Region codes (possibly just the codeSystem).

• Is it OK to insist on only ISO 3166 codes for address and study site, but to allow other types of country coding for geographic scopes? Or should we allow country alias codes for address and study site too?

[ASL-rmarshall]

@BSnoeijerCD Also:

• The target cardinality for StudyEnrollment -- appliesTo -> GeographicScope should be 0..1, not 1..*. A study enrollment applies to either a (single) geographic scope, a (single) study site, or a (single) cohort. If you need to define enrollments for multiple geographic scopes, sites or cohorts, you'd just create additional instances of StudyEnrollment, each with an appliesTo relationship to a single target.
• Does every study amendment have to have a defined study enrollment (even if it's for something as trivial as typographical changes)? If not, the target cardinality for StudyAmendment -- enrollments -> StudyEnrollment should be 0..*, not 1..*. (It may have been defined as 1..* before because StudyEnrollment "was" the geographic scope (via inheritance), and a geographic scope is required for every amendment).

[BSnoeijerCD]

@BSnoeijerCD @EMuhlbradt A couple of thoughts triggered by looking at the new country relationship from StudySite:

• This relationship looks like it's intended to be defined in the same way as the country relationship from Address - i.e., it goes to Code and am I right to assume that the expectation is that the ISO 3166-1 alpha-3 codelist will be used?

• The code relationship from GeographicScope looks like it might perform a similar function when GeographicScope.type = "Country" but, in this case, the relationship is to AliasCode and the CT file says:

  Point out to external dictionaries: Standard code is ISO-3166; Alias codes drawn from GENC, UN Region Codes, etc.

  However, I don't think this will work because the code relationship is also used to identify regions when the GeographicScope.type = "Region" (hence the reference to "UN Region Codes"). In order to use AliasCode, you must specify a standard codelist and always provide a standard code from that codelist - but the ISO-3166 codelist does not contain the type of region codes we need for geographic regions. I think we probably just need to change the comment in the CT file to say:

  Point out to external dictionaries: Standard code is ISO-3166-1 alpha-3 for countries and UN Region Codes for regions; Alias codes drawn from GENC, etc.

  We might then need a rule to ensure the correct standard coding for countries vs regions - but we'd need to define what's checkable for ISO 3166 vs UN Region codes (possibly just the codeSystem).

• Is it OK to insist on only ISO 3166 codes for address and study site, but to allow other types of country coding for geographic scopes? Or should we allow country alias codes for address and study site too?

To make clear that we only want 1 geographic scope defined, we [robably used the aliasCode class instead of the code class to allow for different coding systems used for the same country/region code specification. But that has some implications indeed since (as we defined in the last sprint) there should be a standard coding class specified in the CT. I believe, given the above, to make it consistent we have 2 options : -> or we also define the standard code class in case a region is defined and then we change the country relationship in the Address and StudySite class to AliasCode so that there also alternative coding systems are allowed. -> or we leave it completely open for users what coding system they want to use - move the code relationship for geographic scope to the code class and allow more codes to be defined (e.g. relationship name changes to codes). However, to make it consistent that would imply that you should do the same for country in Address and StudySite. Making them plural changes the relationship name to countries which might be confusing since 1 address should only have 1 country (or maybe countryCodes would work? ). @dih-cdisc: what is your view?