Skip to content

Add Consent to ODM export (repeating Common event, whitelist-only) - #24

Merged
erikvw merged 1 commit into
developfrom
feature/consent-export
Jun 24, 2026
Merged

Add Consent to ODM export (repeating Common event, whitelist-only)#24
erikvw merged 1 commit into
developfrom
feature/consent-export

Conversation

@erikvw

@erikvw erikvw commented Jun 24, 2026

Copy link
Copy Markdown
Member

Summary

Adds the consent model (settings.SUBJECT_CONSENT_MODEL) to the CDISC ODM export. Because the consent document holds sensitive data, only an explicit, non-PII whitelist of fields is exported — never the admin fieldsets.

Whitelist: subject_identifier, consent_datetime, model_name, version, consent_definition_name (all real model fields).

Reusable "explicit item list per model" facility

  • CONSENT_EXPORT_FIELDS / WHITELIST_FIELDS in constants.py; get_whitelist_fields() resolves the consent model from settings.
  • iter_crf_sections() short-circuits to iter_whitelist_fields() for whitelisted models — so a model holding sensitive data needs no admin registered and exports only the vetted list.

Safety: a sensitive field can't be re-exposed via the whitelist

iter_whitelist_fields() applies the same PII floor as everywhere else: an encrypted field or an EXCLUDED_FIELD_NAMES field is dropped even if whitelisted, with a UserWarning. The whitelist is restrictive, intersected with the hard rules — it can add non-sensitive fields but cannot bypass the no-encrypted-fields rule. Plaintext-sensitive additions are caught by review; lists are kept tiny and explicit.

Repeating event

Consent is unique on subject_identifier + version, so it's a repeating Common event:

  • Metadata: StudyEventDef Type="Common", Repeating="Yes", Alias Context="clinicedc.event_category" Name="consent", OID CE.<consent_model>.
  • Data: one StudyEventData per consent row with StudyEventRepeatKey=<version>.

Common/screening/consent are centralized into iter_subject_level_events() — a single source for the StudyEventDefs, the definition catalog, and the Protocol StudyEventRefs.

Tests

12 tests pass (4 new): consent def is repeating + category alias; consent StudyEventData present with repeat key; encrypted PII (first_name) absent from both metadata and data while version is present; whitelist floor drops an encrypted field even when whitelisted. validate_odm(snapshot) == [].

🤖 Generated with Claude Code

The consent document holds sensitive data, so export ONLY an explicit,
non-PII whitelist of fields (subject_identifier, consent_datetime,
model_name, version, consent_definition_name) — never the admin fieldsets.

Reusable "explicit item list per model" facility:
- CONSENT_EXPORT_FIELDS / WHITELIST_FIELDS in constants; get_whitelist_fields()
  resolves the consent model from settings.SUBJECT_CONSENT_MODEL.
- iter_crf_sections() short-circuits to iter_whitelist_fields() for whitelisted
  models, so a model with sensitive data needs no admin registered and exports
  only the vetted list.
- Safety floor: iter_whitelist_fields() still drops encrypted (PII) and
  EXCLUDED_FIELD_NAMES fields even if whitelisted, emitting a warning — a
  sensitive field cannot be re-exposed by adding it to a whitelist.

Consent is unique on subject_identifier + version, so it is a *repeating*
Common event (Repeating="Yes", Alias event_category="consent", OID
CE.<consent_model>); data emits one StudyEventData per consent row with
StudyEventRepeatKey=version.

Centralized common/screening/consent into iter_subject_level_events() (single
source for StudyEventDefs, catalog, and Protocol refs).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@erikvw
erikvw merged commit 6152b83 into develop Jun 24, 2026
30 of 37 checks passed
@erikvw
erikvw deleted the feature/consent-export branch June 24, 2026 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant