Status: Proposed (Pilot for Benefit Connect Campaign)
Date: 2026-02-27
Authors: Architecture / Federated Consent Domain
Decision Type: Cross-Domain Architectural Standard
We are a broker operating across multiple campaigns, carriers, and employer clients. We must govern outbound data distribution to third parties (e.g., Benefit Connect) based on explicit consent provided by:
- Participant
- Policy Holder
- Household
- Client (Employer / B2B)
Legal guidance requires:
-
Policy holder–specific consent for sharing policy data.
-
No embedding of this consent within Terms of Service.
-
Ability to revoke consent.
-
Suppression of only the non-consenting individual’s data (not blanket household suppression).
-
Auditability and defensibility.
Current issues:
-
Consents are fragmented across domains.
-
No systematic tagging of data by consent requirements.
-
Downstream systems lack metadata to determine if distribution is allowed.
-
No consistent enforcement boundary across bounded contexts.
-
No authoritative mapping between partners and consent scope.
We require a standardized, enforceable, metadata-driven solution that governs data distribution based on consent outcomes.
We will implement a Consent-Aware Data Tagging Standard across all bounded contexts, backed by a centralized Federated Consent Domain, and governed through partner registration in Backstage.io (TechHub).
The decision has five pillars:
-
Canonical Consent Model (Federated Consent Domain)
-
Mandatory Data Classification & Consent Tagging
-
Partner Registry as Source of Distribution Authority
-
Enforcement at Distribution Boundaries
-
Data Lake Tag Propagation for Downstream Governance
| Domain | Responsibility |
|---|---|
| Federated Consent BC | Capture, store, version, publish consent outcomes |
| Bounded Contexts (e.g., Enrollment, Profile, Funding) | Protect their own data based on consent tags |
| TechHub (Backstage) | Registry of partners, consent definitions, and data contracts |
| Integration / Eventing | Distribute consent outcome events |
| Data Lake | Store consent-tagged data for governed downstream distribution |
| Type | Description | Example |
|---|---|---|
| Durable Platform | Cross-campaign permissions | Contact preferences |
| Campaign-Specific | Limited to specific partner/program | Benefit Connect ICHRA sharing |
| Event-Driven | Triggered by workflow action | Checkout attestation |
| Regulatory | Legally mandated | HIPAA authorization |
| Marketing | Promotional outreach | TCPA opt-in |
| Level | Description |
|---|---|
| Policy Holder | Required for policy data sharing |
| Participant | Individual-level consent |
| Household | Shared-level permission |
| Client | Employer-level contractual consent |
| Campaign | Program-level gating |
A consent may be conditioned on:
-
Campaign ID
-
Product Type (IFP, Medicare, ICHRA)
-
Carrier
-
Partner (TechHub ID)
-
Channel (Digital, Agent-assisted)
-
Geography
-
Policy status (Active, Effectuated)
Every data element eligible for outbound distribution must include metadata attributes:
| Attribute | Description |
|---|---|
| DataClassification | PII / Non-PII / PHI |
| ConsentRequired | Boolean |
| ConsentIDs | List of required consent definitions |
| ConsentLevel | Participant / Household / Policy |
| PartnerScope | TechHub Partner IDs permitted |
| CampaignScope | Campaign IDs |
| DistributionRule | Allow / Suppress / Conditional |
| RegulatoryBasis | Legal justification (if applicable) |
{
"field": "policyEnrollment",
"classification": "PII",
"consentRequired": true,
"consentIds": ["CONSENT_BC_ICHRA_V1"],
"consentLevel": "PolicyHolder",
"partnerScope": ["TECHHUB_PARTNER_BENEFIT_CONNECT"],
"distributionRule": "CONDITIONAL"
}
All external partners are registered in Backstage.io with:
-
Unique Partner ID
-
Data contracts
-
Consent requirements mapping
-
Permitted data domains
-
Campaign eligibility
-
Regulatory documentation
This registry becomes the authoritative mapping layer between:
-
Consent definitions
-
Bounded context data
-
Distribution eligibility
The Consent BC shall:
-
Store consent outcomes (with attribution)
-
Version consent verbiage (hash-based tracking)
-
Emit integration events:
-
ConsentGranted
-
ConsentRevoked
-
ConsentExpired
-
-
Support querying by:
-
Policy Holder
-
Participant
-
Household
-
Campaign
-
-
Maintain audit trail:
-
Timestamp
-
Channel
-
Agent ID (if applicable)
-
This domain evolves from the existing HIPAA Auth domain and centralizes retention and dissemination of outcomes.
Enforcement occurs at:
-
API boundary before partner distribution
-
Integration event publishing
-
Data Lake extraction layer
-
Batch feed generation
If consent is:
| Status | Enforcement |
|---|---|
| Granted | Data allowed if other conditions met |
| Missing | Suppress data tied to that consent |
| Declined | Suppress data |
| Revoked | Immediately suppress future transmission |
| Expired | Suppress until re-consented |
Where multiple policy holders exist in one household:
-
Evaluate consent at Policy Holder level.
-
Suppress only non-consenting policy data.
-
Never suppress consenting policies.
All events sent to the Data Lake must propagate:
-
ConsentRequired flag
-
ConsentIDs
-
PartnerScope
Downstream distribution jobs must:
-
Join against Consent Domain.
-
Validate required consent.
-
Filter by Partner ID.
-
Produce distribution eligibility logs.
Each BC must:
-
Declare which data requires consent.
-
Tag data at persistence and outbound projection.
-
Refuse to expose consent-restricted data via public APIs without enforcement check.
-
Publish metadata contract to TechHub.
This aligns with DDD: each bounded context protects its own invariants.
Partner: Benefit Connect
Consent Type: Campaign-Specific
Consent Level: Policy Holder
Condition: ICHRA Campaign
If consent not granted:
-
Enrollment workflow may proceed (policy decision dependent).
-
No enrollment payload transmitted.
-
Data Lake tagged as suppressed.
-
Optional status indicator may be transmitted to Benefit Connect.
System shall support:
-
Consent export (PDF / print)
-
Household consent dashboard
-
Agent-assisted capture with identity attribution
-
Audit queries by Compliance
-
Consent removal by policy holder
-
Re-consent triggered by hash change of legal text
-
Deterministic governance of outbound data.
-
Partner-level enforcement.
-
Legally defensible audit trail.
-
Enables federated ownership.
-
Prevents accidental PHI leakage.
-
Scales to additional vendors.
-
Increased metadata overhead.
-
Schema evolution required.
-
Cross-team alignment effort.
-
Requires discipline in tagging.
-
External systems API to query consent.
-
External persistence endpoint for vendor-captured consent.
-
AI agent verbal consent capture.
-
Data Lake analytics dashboard for consent coverage.
-
Migration of legacy consents into centralized model.
-
Durable consents are not re-asked unnecessarily.
-
Campaign consents remain campaign-scoped.
-
Enforcement is data-level, not UI-only.
-
TechHub is source of truth for partner identity.
-
No data is distributed without evaluating consent state.
We adopt a metadata-driven, consent-aware distribution architecture in which:
-
All sensitive data is classified and tagged.
-
Consent outcomes are centralized.
-
Partner eligibility is registry-driven.
-
Enforcement is automatic and deterministic.
-
Bounded contexts remain responsible for protecting their data.
This establishes a scalable governance model suitable for a regulated broker environment supporting multi-partner integrations.