Members & Parties

Olly uses a unified Party model to represent any person or organisation that interacts with the platform — members, employers, brokers, and providers all share the same table, distinguished by a Type field.

The Party Model

type Party struct {
    ID          uuid.UUID
    Locator     string     // e.g. "PTY-2026-000123"
    Type        string     // INDIVIDUAL | ORGANISATION | PROVIDER
    FirstName   string     // individuals only
    LastName    string     // individuals only
    Name        string     // organisations and providers
    Email       string
    Phone       string
    Address     []byte     // jsonb: domain.Address
    DateOfBirth *time.Time // individuals only
}

`Type`	Who	Examples
`INDIVIDUAL`	A natural person	Member, dependent, broker contact
`ORGANISATION`	A legal entity	Employer group, TPA, insurer
`PROVIDER`	A healthcare provider	GP practice, hospital, specialist

All PHI on a Party is encrypted at the application layer before being stored in Aurora. The Locator is the stable, externally shareable reference — UUIDs are internal only.

PartyRole — Roles on Policies and Accounts

A Party acquires meaning in context through PartyRole. One party can hold multiple roles across multiple entities (e.g., an individual can be an ACCOUNT_HOLDER on one account and an INSURED on two policies).

type PartyRole struct {
    PartyID    uuid.UUID
    EntityType string    // ACCOUNT | POLICY | QUOTE
    EntityID   uuid.UUID // the specific account, policy, or quote
    Role       string    // ACCOUNT_HOLDER | INSURED | BENEFICIARY
}

Role	Description
`ACCOUNT_HOLDER`	The party responsible for the account (typically the employer or the primary individual)
`INSURED`	A party covered under a specific policy
`BENEFICIARY`	A party designated to receive benefits (e.g., life insurance payout)

Account — The Billing Entity

An Account is the financial container that owns policies and receives invoices. Accounts come in two flavours:

`BillingLevel`	Description
`ACCOUNT`	All policies under this account are billed together (typical for employer groups)
`POLICY`	Each policy is billed independently (typical for individual or voluntary benefit schemes)

An employer group scheme has one Account (the employer organisation's party) linked to many policies — one per employee. Each employee is a PolicyElement on their own Policy, but all invoices roll up to the employer Account.

Employee vs. Dependent

Within a Policy, covered individuals are modelled as PolicyElement records:

`ElementType`	Who	Notes
`"employee"`	The primary insured (subscriber)	Always present; linked to the employer's `Account`
`"dependent"`	Spouse, domestic partner, child	Added via an `ENDORSEMENT` transaction; shares the employee's `PolicyElement.CoverageTerms` or has its own

Dependents are linked to their own Party record (with their own DOB, name, etc.) via PolicyElement.PartyID. The relationship between an employee's element and their dependents' elements is tracked through the shared Policy context — both carry the same PolicyID.

Employer Group Scheme → Member Relationship

The consent service tracks member preferences for data sharing. Each ConsentRecord is keyed by (PartyLocator, ConsentType) — there is at most one record per combination. The Granted boolean captures the current preference.

`ConsentType`	What it controls
`NHS_DATA_SHARING`	Whether health data may be shared with NHS systems for care coordination
`WEARABLE_SYNC`	Whether data from wearables (Apple Health, Fitbit) may be ingested for wellness programmes
`EMPLOYER_WELLBEING_REPORTING`	Whether anonymised health metrics may be included in employer wellbeing dashboards
`RESEARCH_PARTICIPATION`	Whether de-identified data may be used in clinical research
`MARKETING_COMMUNICATIONS`	Whether the member may receive marketing emails and push notifications

Every change to a consent preference is recorded in ConsentAuditEntry — an immutable log of who changed what, when, and why.

Members may exercise their right to erasure under UK GDPR Article 17. A DeletionRequest is created with the requested DeleteType:

`DeleteType`	What happens
`SOFT`	PHI fields are zeroed/anonymised; the party record remains for referential integrity
`HARD`	All party data is purged; records replaced with tombstones

The deletion workflow (implemented as a Temporal activity) fans out deletion requests to each service that holds PHI for that PartyLocator. DeletionStatus tracks progress: PENDING → PROCESSING → COMPLETED (or FAILED with retry logic via AttemptCount).

Regulatory retention

Certain data (e.g., billing records, claim history) must be retained for 6 years under HIPAA / FCA rules even after a deletion request. The deletion workflow anonymises PHI while preserving required audit records.

Members & Parties ​

The Party Model ​

PartyRole — Roles on Policies and Accounts ​

Account — The Billing Entity ​

Employee vs. Dependent ​

Employer Group Scheme → Member Relationship ​

Consent Types and Why They Matter ​

GDPR Deletion Workflow ​