Information Security Policy

This Information Security Policy describes the security principles, architectural controls, and operational practices BrilLiquid LLC applies to BRILL.health for the protection of Protected Health Information.

Version: 1.3 Prepared by: Andrew MacInnes, Managing Member, BrilLiquid LLC Distribution: Confidential — for partners, regulators, and security reviewers under appropriate confidentiality protection

Document Control

This document is the property of BrilLiquid LLC and is classified CONFIDENTIAL. Distribution is limited to authorized personnel, partners under mutual NDA, regulators conducting lawful review, and third parties conducting due diligence at our invitation.

0. Maturity Note (Read First)

BRILL.health is an early-stage platform built by a small team. This policy describes our security principles, our architecture and technical controls as deployed today, and our roadmap for formalized operational practices. We distinguish clearly between what is in place today, what is implemented but not yet formally documented, and what remains on the roadmap.

Partners conducting due diligence are encouraged to ask specific questions about the current state of any control. We prefer candor to checklist theater: we will say "we are establishing X" rather than "we do X" when the latter would overstate our current operational maturity.

Our security posture is strengthened by the architectural choice to hold as little sensitive data as possible (see §2.1). Many controls that would be critical for a large data-holding platform are less load-bearing for us because we are a relay, not a repository.

1. Purpose and Scope

This policy establishes the information-security framework governing BRILL.health — BrilLiquid LLC's patient-facing health platform — including its infrastructure, personnel, and authorized service providers.

BRILL.health transmits, and incidentally handles, Protected Health Information (PHI) as defined under 45 CFR § 160.103. Its architecture and policies are designed to minimize what Brilliquid itself holds in persistent form; the platform is operated as a standards-based secure relay rather than as a records repository.

This policy is aligned with:

• HIPAA — Privacy Rule (45 CFR §§ 164.500–164.534), Security Rule (§§ 164.302–164.318), and Breach Notification Rule (§§ 164.400–164.414)
• 21st Century Cures Act Final Rule — ONC Information Blocking provisions (45 CFR Part 171) and CMS Interoperability requirements (CMS-9115-F, CMS-0057-F)
• Washington My Health My Data Act (RCW 19.373)
• California Consumer Privacy Act / California Privacy Rights Act
• State breach-notification statutes in the jurisdictions where we serve residents
• NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover) as a design reference

Distribution model. BRILL.health is distributed as a Progressive Web App (PWA), installable to home screen via Safari "Add to Home Screen" (iOS) or the Chrome / Edge install prompt (Android, desktop). The platform is not distributed via the Apple App Store or Google Play, and we have no current plans to. iOS HealthKit and Android Health Connect are out of scope as platform-internal data stores; we do not hold a HealthKit or Health Connect entitlement, and a PWA cannot programmatically reach either store. Patient-mediated uploads of Apple Health or Google Health Connect exports are accepted as Tier 1 patient-uploaded ingestion (the broader ingestion taxonomy is described in §3); records ingested by this path carry full provenance metadata back to their originating sources. Apple's HealthKit-specific data-handling obligations and Google's Health Connect / User Data Policy obligations bind our handling of HealthKit- and Health-Connect-derived data even though we receive it via patient upload rather than live entitlement. See Privacy Policy §4 for patient-facing detail.

Voluntary alignment with NJ MISMO V2 RON Standards. BRILL.health's DIY Remote Online Notarization technology stack (described in §7.6) maintains voluntary alignment with the New Jersey MISMO V2 Remote Online Notarization Standards (May 2024). Our DIY composition under New Jersey notary commission #50239521 — HIPAA-Zoom audio-video, Plaid IDV, AATL-listed digital certificate (IdenTrust IGC Business Identity Hardware Storage Trusted By Adobe), BoldSign or MaxSignatures signature workflow, AWS S3 retention with Object Lock — is structurally ~85–90% MISMO V2-aligned. Where MISMO standards exceed our current implementation (e.g., specific retention-redundancy patterns, document-deletion-on-cancellation), we track those as roadmap items. If DirectTrust adopts a healthcare-RON standard analogous to MISMO V2 in the future, our voluntary alignment positions us as forward-compatible.

Brilliquid operates principally as a Business Associate to the Covered Entities with which its users interact. Our specific obligations flow from each Business Associate Agreement in force.

2. Security Philosophy

2.1 Decentralized by design — patient-curated, verifiably-provenanced record

BRILL.health operationalizes the patient-curated, verifiably-provenanced record framing. Clinical records flow into the platform from credentialed sources (patient-uploaded files, provider FHIR endpoints, payer Patient Access APIs, pharmacy / PBM data sources, cross-platform DHT vendor APIs, and DirectTrust inbound) and are stored as ciphertext bound to per-patient keys; we do not aggregate plaintext clinical data into a centralized repository under our control. Per-patient encryption keys produce per-patient blast radius — a compromise of one patient's storage compromises that patient, not the population.

Three principles govern our handling:

1. Patient sovereignty over readable plaintext. Only the patient can decrypt their Layer 3 clinical content (Stage 2 target architecture; Stage 1 today uses Brilliquid-held Fernet keys — see §5.2 / §5.3 for the full phasing).
2. No population-aggregate honeypot. Per-patient keys, per-patient blast radius. We hold what we need to fulfill the service; we do not aggregate across patients for any single constituent's analytical purposes.
3. Provenance-stamped on every layer, never truth-arbitrating. Original records, platform overlays, and patient annotations each carry their own attribution chain back to origin. Cross-source data conflicts (e.g., differing dates of birth across multiple records — a canonical case in real-world data) are surfaced honestly: each per-source observation is preserved; the most-recent-document-creation-time is used as the canonical display; the dissenting source remains one click away. We do not adjudicate which provider is correct; we make the disagreement visible so the patient and their care team can resolve it at the source. The audit ledger preserves every per-source observation; nothing is silently overwritten.

Our claim is attribution and integrity — we can prove who originated a record, when, through what path it reached us, and that any patient annotation under an IAL2-verified BRILL.health session is the patient's own. We do not claim clinical correctness.

2.2 Patient-held clinical data — Stage 1 / Stage 2 phasing

Clinical records are held as ciphertext on BRILL.health infrastructure under our PWA-only distribution model — patient devices are not the canonical store (a PWA cannot guarantee persistence across browser-state events; bytes-on-device-only would lose patient data on browser cache eviction or device loss). The substantive decentralization lies in decryption authority, which moves from Brilliquid (Stage 1 today) to patient-derived keys (Stage 2 target). Our architectural goal is that BRILL.health holds the bytes of your health records but cannot decrypt them without your authenticated session. See §5.2 / §5.3 for the cryptographic detail and the migration path.

2.3 Defense in depth

We assume that any single control may fail. Controls are layered so that a compromise of any one does not result in data exposure. Layers include perimeter network controls, transport encryption, application-level authentication and authorization, field-level encryption for persisted identifiers, audit logging, vendor contractual protections, and physical security of development environments.

3. Data Classification — Four-Layer Storage Model + 7-tier ingestion taxonomy

Clinical and operational data is partitioned across four storage layers, each with distinct encryption, access, and retention rules. These layers are an architectural commitment and govern every storage decision on the platform.

3.1 Four-Layer Storage Model

• Layer 1 — Metadata (centralized, encrypted at rest). BRILL-IDs, consent records (Universal FHIR Consent resources — see §7.7), ledger entries, message envelope metadata, BoldSign / MaxSignatures envelope IDs, device-provenance records. Stored in AWS RDS + KMS encryption + field-level Fernet for sensitive fields. AWS S3 Object Lock for immutable retention where required.
• Layer 2 — Operational data (server-side, patient-key-encrypted in target architecture). Questionnaire responses, care-team list, education-acknowledgment records. Stage 1 today uses server-held Fernet keys; Stage 2 target uses patient-derived keys via WebAuthn / WebCrypto. Trade-off: under Stage 2, a locked-out patient cannot have prior questionnaire responses recovered by an admin — the platform genuinely cannot read them without the patient's session. This is a deliberate product decision.
• Layer 3 — Clinical data (patient-controlled, platform-held ciphertext). Test results, FHIR-pulled records, C-CDA documents, attached files from Direct messages, payer claims data, prescription history from pharmacies / PBMs, daily metrics from cross-platform DHT vendors. Per-patient encryption keys. Per-patient breach blast radius. Stage 1 (operational today) uses Brilliquid-held Fernet keys; Stage 2 target binds ciphertext to patient-derived keys via WebAuthn / WebCrypto. The Universal FHIR R4 Consent primitive (§7.7) governs every consent attached to L3 data. Ingestion runs through the seven tiers in §3.2 below.
• Layer 4 — Genetic / genome data (render-only, parse-in-memory). Consumer DNA test files (e.g., 23andMe or AncestryDNA raw exports — typically a 600,000+ row genotype) are scanned in memory at parse time and discarded. Only specific findings on a curated allowlist (currently NCCN-aligned hereditary-cancer variants, ~10–12 variants per panel) survive into context. Findings are recorded as Layer 3 ciphertext with provenance tagged back to the source file. Where an allowlisted finding has implications for biological relatives (cascade-testing relevance), we record it as patient-attested family-history context under the patient's own record only — we do not separately profile relatives. Plaintext genetic-data storage is never an acceptable state, even pre-production. Confidential computing (AWS Nitro Enclaves) and Secure Multi-Party Computation are aspirational paths for future research-licensing modes.

3.2 Seven-tier ingestion taxonomy (Layer 3)

Clinical data flows into the Layer 3 ciphertext store through seven distinct ingestion tiers, each with its own provenance chain:

The generic SMART-on-FHIR client architecture handling Tiers 2 and 3 is described in §7.5; current vendor-config inventory is named in §7.4.

3.3 Cross-source data conflict and CSV-as-FHIR-Bridge ingestion

Where multiple sources hold differing observations on the same field (a canonical case: differing dates of birth across two providers, one correct and one a placeholder error), our ingestion preserves every per-source observation with its provenance. A canonical-display rule (most-recent-document-creation-time wins) selects what to show by default; the dissenting source is preserved and visible on inspection. The audit ledger is append-only; nothing is silently overwritten. This implements Decentralized by Design principle 3 (provenance-stamped, never truth-arbitrating — see §2.1).

For payer / EHR vendors where production-FHIR is pending — for example, where we hold a CSV export of claims pending production-FHIR endpoint enablement — we ingest via a CSV-as-FHIR-Bundle bridge adapter. Records ingested by this path carry a meta.source = "csv-bridge:<vendor>" provenance tag so the rendering layer can distinguish them honestly from FHIR-pulled records.

3.4 Data minimization

Data minimization is the rule at every layer. Where a field is optional for operation, it is not collected. Where a field is required briefly (e.g., a photo of an identity document), it is handled, acted upon, and purged in the shortest practical window. Categories we explicitly never collect: country of birth, immigration status, citizenship proxies (countries lived in, visa history, etc.).

4. Access Controls

4.1 Authentication

• All access to the platform requires authentication.
• Patient accounts use email-based identification. Multi-factor authentication is mandatory. Passkeys (WebAuthn, device-bound biometric) are the preferred factor; TOTP authenticator apps are supported as a fallback.
• Administrative access requires multi-factor authentication without exception.
• Account credentials are never transmitted or logged in plaintext.
• Each human has an attributable identity; account sharing is not permitted.

4.2 Authorization

• Role-based access with least privilege. Roles include Patient (self-service), Rep / Provider (scoped view), Operations Staff (program administration), and Administrator (platform governance).
• A patient has access to their own records exclusively. Staff roles do not have patient-record access except in narrowly-defined support contexts, which are logged for review.

4.3 Session Management

• Sessions expire on browser close and after a configured period of inactivity.
• Session identifiers are transmitted only over encrypted channels.

4.4 Account Lifecycle

• Onboarding establishes an attributable identity at the strength appropriate to the action being taken; IAL2 identity verification is invoked at trigger events (e.g., claim a Direct address, execute a RON-witnessed authority instrument, dispute a pricing tier — see §7.1) rather than required at general platform access.
• On offboarding (patient-initiated, staff termination, or contract end) access is deactivated and retained records are reduced to the minimum legally required.

4.5 Sensitive-category access controls

Patient records may include categories that carry heightened access-control requirements under federal law and applicable state law. Examples include adolescent reproductive health, adolescent mental health, sexually-transmitted infection records, and substance-use treatment records. For these categories:

• Personal Representative authority is bounded. A parent may have general HIPAA Personal Representative status for a minor child while NOT having access rights to specific sensitive-category records (per state-specific minor-consent law and the 21st Century Cures Act information-blocking provisions). The platform partitions sensitive-category records via category-aware access controls; Personal Representative scope is recorded explicitly per record-category.
• Adolescent age transitions trigger automatic access recalculation. When a patient transitions through age thresholds defined by applicable state law (typically 12 / 14 / 18, varying by category and jurisdiction), Personal Representative access scope is recalculated and re-disclosed to all parties. The audit ledger records the transition event.
• 21st Century Cures Act information-blocking exceptions are applied per the ONC framework when a sensitive-category record cannot be released without compromising the patient's confidentiality interests under applicable law.

Reference: New Jersey Adolescent and Young Adult Health Confidentiality Guide; HHS OCR guidance on parental access to minor children's medical records; ONC information-blocking exceptions (45 CFR Part 171). Cross-state minor-consent law varies significantly; counsel input is required for any multi-state expansion of sensitive-category handling.

4.6 Layer C patient annotations

Patients may attach annotations to their own records (the "Layer C" of the three-layer annotation architecture — see Privacy Policy §3.7 for the patient-facing description). Each annotation:

• Carries provenance attribution under the patient's IAL2-verified BRILL-ID with timestamp.
• Is append-only — annotations are amendable, but the prior version is preserved in the audit ledger and the new version supersedes it forward; nothing is silently overwritten.
• Is categorized by relevance (current status / baseline / archival / sensitive-category) and may be linked to specific Layer A original records via record references.
• May be patient-ranked for connection to active concerns in the patient's Medical Concerns List.

Annotations sourced from authorized care-team members (collaborative authorship via Direct Secure Messaging) carry both the suggester's and the patient's attribution. Annotations from professional clinicians on the patient's care team (e.g., a clarifying note from a specialist) are recorded as Layer B platform overlays (with the clinician's professional credentials carried as the attribution), distinct from Layer C self-authored content.

Annotations do not modify, replace, or hide the original Layer A record. They do not constitute medical advice. They do not bind any provider's care decisions.

5. Cryptographic Controls

5.1 Data in Transit

All data crossing a network boundary is protected by modern transport-layer encryption (TLS 1.2 or greater). HTTP Strict Transport Security is enforced at the application layer. Legacy protocols are not supported.

5.2 Data at Rest — Stage 1 / Stage 2 phasing

Persistent data is encrypted at rest. Encryption phasing is staged explicitly:

• Stage 1 — operational today (HIPAA-compliant). AWS KMS-managed keys at the database layer, plus Brilliquid-held Fernet keys at the field-level (EncryptedCharField / EncryptedTextField / EncryptedJSONField patterns). Cryptographic keys are managed by AWS Key Management Service under the brill-health AWS account's BAA. This is HIPAA-compliant but not zero-knowledge; Brilliquid retains the technical ability to decrypt for operational and audit purposes. We protect against unauthorized access through access controls, audit logging, MFA, and least-privilege role discipline — not through cryptographic exclusion of Brilliquid itself.
• Stage 2 — target, post-pilot. Layer 3 ciphertext is bound to patient-derived keys via WebAuthn / passkey PRF + WebCrypto. Under Stage 2, Brilliquid LLC cannot decrypt Layer 3 patient clinical data without the patient's authenticated session present. This is a stronger property than HIPAA requires; it is a strategic commitment to the platform's "decentralized by design" thesis. Implementation is a focused 2-to-3-week dedicated build cycle, queued post-pilot per family-beta sequencing (see project memory feedback_move_fast.md for sub-month gap discipline).

Migration path. Stage 1 → Stage 2 transition is via dual-write (encrypt to both keys for a transition window) → flip-the-switch (Stage 2 becomes canonical) → revoke (Stage 1 server-key fields purged). Patients are notified in-platform when Stage 2 launches for their account.

Field-level encryption is applied to categories of data whose sensitivity warrants a tighter blast radius than database-level encryption alone. The EncryptedCharField class enforces a column-width discipline where ciphertext expansion (~1.5× plaintext + ~100 bytes overhead) is accommodated by class default (varchar(500)) rather than per-call-site override, after a series of column-width incidents in May 2026 demonstrated that plaintext-semantic max_length values were footguns.

5.3 End-to-End — Stage 2 architecture

Layer 3 clinical content is the canonical instance of the End-to-End architecture. Stage 2 binds ciphertext to patient-held keys derived via standard WebAuthn ceremonies and backed by device secure-hardware where available. Under Stage 2, the server role is reduced to ciphertext relay, metadata retention, and audit ledger. Implementation is the focused engineering effort described in §5.2; until Stage 2 is operational, Stage 1 server-key encryption remains the production posture, with explicit disclosure to patients in our Privacy Policy §6.

Latency-class tiering. Where storage tiering is needed (hot / warm / cold), the emergency-access subset of Layer 3 — defined narrowly via a default break-the-glass FHIRConsent (category=emergency-access) opt-in at IAL2 onboarding — remains under Stage 1 server-keyed encryption even after Stage 2 patient-keyed rolls out for the rest of L3. This is a deliberate design constraint: an unconscious patient cannot present an authenticated session to decrypt their own emergency-relevant subset; a credentialed emergency clinician must be able to access the subset under a documented break-the-glass protocol, audit-logged at access time. See project memory project_latency_class_tiering.md for the full design.

5.4 Key Management

• Keys are segregated by function; the same key is not reused across authentication, data classes, or signing (except where a standardized protocol requires it).
• Keys rotate on compromise and, for long-lived keys, on a planned basis.
• Cryptographic material is not stored in source code or on unprotected developer workstations.

6. Infrastructure and Network Security

6.1 Hosting and AWS account architecture

The platform runs on Amazon Web Services in United States regions. PHI is not processed or stored outside the United States. Infrastructure is defined as code; builds are reproducible.

BRILL.health operates from a dedicated AWS account (account ID 227014004119, signed BAA, established 2026-04-20). This account is fully isolated from the brilliquid-platform FINRA-side investor platform, which operates from a separate AWS account with a separate BAA scope. Account-level isolation is a security control: a compromise of one account does not propagate to the other, and audit, compliance, billing, and sub-processor relationships are entirely separate. PHI handling is scoped to the brill-health account's BAA.

Account hardening baseline: - Root password in Apple Passwords; root MFA (TOTP / hardware token) bound; no root access keys. - IAM admin user (andrew-admin) with mandatory MFA; YubiKeys registered as additional factors. - CloudTrail multi-region with log validation enabled. - GuardDuty intrusion detection enabled. - AWS Budgets alert armed. - RDS placed in private subnets; no RDS public-access path (eliminates public IPv4 exposure, reduces attack surface, reduces VPC public IPv4 fees).

6.2 Isolation

Production environments are logically separated from development and test environments. No production PHI is used in non-production environments.

6.3 Perimeter Controls

Inbound network access is restricted by default. Only the ports required for public service are exposed. Administrative access to infrastructure requires key-based authentication.

6.4 Monitoring

System activity is logged. Authentication events, access to sensitive resources, and administrative actions receive enhanced logging. Log-review practice is being formalized; interim review is performed at the administrative level on a needs-triggered basis.

7. Identity Verification, Messaging, Third-Party Services, and Architectural Primitives

7.1 Identity Verification

Patient identity verification is invoked at trigger events rather than required at general platform access. The Lite onboarding floor — email + password + email confirmation + 2FA + Terms acceptance + insurance OCR — does not require IDV. IDV is invoked when the patient takes a specific action that depends on it (claim a Direct address, execute a RON-witnessed authority instrument, dispute a pricing tier, substantiate accredited-investor status, etc.).

IDV vendors (operational and queued):

• Plaid, Inc. — IDV at trigger events (document authentication, active-liveness selfie, biometric match). Handles identity attributes only (name, date of birth, address, government-ID images, biometric selfie) — no Protected Health Information is transmitted. Plaid operates as a general identity-verification service, not as a healthcare Business Associate.
• MaxMD-mediated proofing via ID.me (operational path for Tier 1 Direct Secure Messaging activation, today). MaxMD relies on ID.me as its IAL2 Credential Service Provider under DirectTrust-CP-compliant federation. A patient who already holds an ID.me-verified-to-IAL2 credential (e.g., through their IRS Individual Online Account, Veterans Affairs, or other federal agency that uses ID.me for IAL2) can claim a Direct address without a separate verification ceremony. This is the operational IAL2 path today; commercial path with MaxMD is in active conversation.
• Direct federated CSP partnerships (queued). ID.me, Login.gov, and CLEAR (Kantara IAL2 + AAL2 Full Service Accreditation, March 2024) direct integrations are queued. We will name each as an active sub-processor when partnership and integration are in place.
• High-touch fallback — DIY Remote Online Notary IAL2 ceremony. Where federated paths are unavailable, BRILL.health composes IAL2 in-house via the RON technology stack described in §7.6.

NIST SP 800-63-3 Identity Assurance Level 2 (IAL2) identity proofing, as required by the DirectTrust Certificate Policy for Patient Certificate issuance, is performed by accredited Credential Service Providers per the above. Structured attribute outputs are retained in encrypted form; the underlying photographic captures are not retained on the platform after verification completes. See Privacy Policy §12 for the full Registering Agent disclosure.

Other federally-issued verifiable credentials (post-onboarding scope only). For specific post-onboarding events — disputing pricing-tier classification or substantiating accredited-investor status — BRILL.health may accept structured information the patient chooses to provide from their IRS Individual Online Account (or equivalent federal services), via OAuth-mediated structured pull where supported (subject to the federal service's own consent flow and our partnership status) or as a patient-uploaded transcript file. We do not retain underlying federal-service data beyond the specific attributes the patient authorized; we keep an audit record of which attributes were verified and when. We do not use IRS or other federal-service access for general onboarding identity proofing.

BrilLiquid LLC is a DirectTrust Registering Agent under our Health Information Service Provider's certification authority; identity-verification artifacts required by the DirectTrust Certificate Policy §4(iii) are retained accordingly.

7.2 Messaging

Secure clinical messaging is operated through an accredited DirectTrust Health Information Service Provider (HISP) — MaxMD, Inc. — under a Business Associate Agreement. The HISP is responsible for trust-bundle management, message signing, and delivery auditing.

Patient Direct addresses are issued under MaxMD's certification authority as Patient Certificates per the DirectTrust "Compliance Guidance on Issuing a Direct Address to a Patient" (October 28, 2020) — issued to the patient individually, not as a domain-bound certificate; the address appears in the certificate's Subject Alternative Name field.

MaxSignatures — MaxMD's structured signature workflow, supporting native Direct delivery of signed documents — is under integration for Class 2 PHI-bearing consents (advance directives, healthcare POAs, RON-witnessed authority instruments) in the signed-document custody architecture (DECISIONS.md Signed-document custody). MaxSignatures uses real PKI + RFC 3161 trusted timestamping; the cert chain at present is a MaxMD-internal CA (MaxSignatures Sign CA → MaxMD Root CA v1.0), not Adobe AATL-listed. Where AATL-listed signing is required for high-stakes recipient validation in third-party PDF readers (e.g., advance directives, RON-witnessed instruments distributed outside the BRILL.health audit chain), BRILL.health composes the signature in-house via IdenTrust IGC Business Identity Hardware Storage Trusted By Adobe certificates (AATL-listed) under our notarial commission — see §7.6.

7.3 Business Associate Agreements

We execute Business Associate Agreements with service providers that may encounter PHI in the course of rendering service to us. Agreements include confidentiality, use limitation, subcontractor flow-down, breach notification, and return-or-destroy obligations consistent with 45 CFR § 164.504(e).

7.4 Sub-Processors

The current sub-processor list is maintained in canonical form at Privacy Policy v4.1 Appendix A; this section mirrors that list with the security-relevant detail.

Active sub-processors handling data on our behalf:

Sub-processors actively under integration (planned, not yet wired to production):

Vendor-mediated FHIR data sources (your-side OAuth relationships — patient acts as data-recipient party; BRILL.health does not hold a direct sub-processor agreement for these but names them for transparency):

• Payer Patient Access (Tier 3): Aetna ✓, athena ✓, CMS Blue Button 2.0 ✓, Cigna ✓, Anthem (Elevance Health TotalView) ✓, Humana, Kaiser, BCBS family plans, Delta Dental, UnitedHealthcare. Vendor-validation status of each is tracked in brill-health/research/fhir apis/REGISTRATION_POSTURE.md.
• Provider Tier 2 (SMART on FHIR via ONC Lantern endpoint discovery): Epic ✓, Oracle Health (Cerner — sandbox-region service ticket pending), athenahealth, Allscripts/Veradigm, eClinicalWorks, NextGen, MEDITECH.
• Pharmacy / PBM: CVS Caremark, Walgreens, Express Scripts, OptumRx, GoodRx.
• Cross-platform DHT vendors: Withings, Fitbit, Garmin, Oura, Dexcom, Omron.

PhiLife is the first program-side clinical lab partner under a program-specific BAA when activated.

Material additions to the sub-processor list are disclosed in advance of effect.

7.5 Generic SMART-on-FHIR client + per-vendor ProviderConfig pattern

Tier 2 (provider-side FHIR) and Tier 3 (payer-side FHIR) ingestion runs through a single generic SMART-on-FHIR client implementation (Authorization Code + PKCE) that handles all vendors uniformly. Per-vendor configuration lives in a ProviderConfig registry; vendor-specific quirks (audience parameter requirements, scope vocabulary divergence, per-resource search-parameter requirements, request-context headers) are captured as per-vendor configuration fields rather than vendor-specific code paths. Zero vendor branching in client code.

Empirically validated across 7 vendor classes spanning 5 different gateway technologies (IBM API Connect, Okta-backed, Oracle Health gateway, custom CMS gateway, Epic identity provider, Elevance TotalView, IBM ISVA) as of 2026-05-09; see brill-health/research/fhir apis/REGISTRATION_POSTURE.md and DECISIONS.md Generic SMART-on-FHIR client + per-vendor ProviderConfig pattern for the full architectural detail. Each new vendor surfaces 0–N quirks; each quirk maps to a specific ProviderConfig field. The architectural pattern saves engineering work; vendor-portal-config quirks still cost time (~1 day of focused configuration work per new vendor in honest estimation, not the optimistic "≤30 minutes" we initially expected).

OAuth tokens are stored as ciphertext under Stage 1 today (Brilliquid-held Fernet); OAuth-token retention follows the L3 audit-trail discipline. We log token issuance, token use, and token revocation events for security monitoring; we do not log token bodies.

7.6 Remote Online Notarization technology stack

Where IAL2 identity proofing is composed in-house — for high-touch ceremonies where federated CSPs are unavailable, or for authority instruments (advance directives, healthcare POAs, RON-witnessed delegations) that require notarial witnessing — BRILL.health uses a DIY composition under New Jersey notary commission #50239521 (Andrew MacInnes) maintaining voluntary alignment with NJ MISMO V2 Remote Online Notarization Standards (May 2024).

Stack components: - Audio-video session: HIPAA Zoom (BAA-covered) for continuous synchronous AV - Identity proofing: Plaid IDV (documentary + biometric strength factors) + live KBA conducted by Andrew under his commissioned-notary status (knowledge factor) - Digital signature certificate: IdenTrust IGC Medium Assurance Business Identity Hardware Storage Trusted By Adobe® (AATL-listed; chains to IdenTrust Global Common Root; binds Andrew + Brilliquid LLC as institutional sponsoring organization). Hardware token requires physical insertion + PIN at signing time. - Tamper-evident eSignature: BoldSign (today) or MaxSignatures (transition pending Class 2 PHI-bearing consent custody work) - Recording retention: AV recording retained for 10 years in BAA-covered AWS S3 with Object Lock and KMS encryption per New Jersey Treasury Notary Public Division requirements (NJSA 52:7-10.7 et seq.) - Audit trail: every notarial act recorded in append-only ledger linking signer-side activity (sign-in, IDV start/complete, Zoom join, ID presentation, KBA answers, BoldSign / MaxSignatures review/sign) to notary-side activity (KBA conducted, ID visually verified, signature witnessed, journal entry, recording archived to S3, document transmitted)

Conflict-of-interest enforcement. Andrew cannot notarize for himself, his spouse, his parent, his child, or his sibling (Tier 1 hard rule). The platform enforces this at AuthorityInstrument creation time via the family-graph: any Tier 1 conflict auto-routes to an external RON service rather than the in-house notary. Tier 2 relationships (grandparents, in-laws, step-relations) default-route to external RON; Tier 3 (aunts, uncles, cousins, nieces, nephews) are case-by-case. Multi-notary scale-up generalizes the same family-graph-driven routing pattern when volume justifies adding additional commissioned notaries.

See DECISIONS.md RON technology stack: DIY composition and project memory project_notary_conflict_of_interest.md for the full design.

7.7 Universal FHIR R4 Consent primitive

Every consent recorded on BRILL.health — patient platform Terms acceptance, share grants for specific records, advance directives, healthcare POAs, executor designations, RON-witnessed authority instruments, DHT vendor OAuth grants, Tier 2/3 FHIR endpoint authorizations, research-data-licensing consents, emergency-access break-the-glass consents — is a structured FHIR R4 Consent resource. This unifies the consent ledger across all categories; a universal-consent-ledger query is a single SQL hit on the FHIRConsent table.

Architectural properties: - Composition pattern. FHIRConsent is the canonical concrete model; each consent type holds a OneToOneField to FHIRConsent and implements to_fhir_consent_dict() mapping its domain fields to the FHIR shape. A centralized helper invoked from each child's save() override maintains the universal-FHIR-Consent invariant on every write. - BRILL-ID portability. grantor_brill_id and verifier_brill_id are denormalized at save() time; FHIR exports use RelatedPerson/BRILL-H26-XXXXX-shaped references — stable, portable, audit-grade — not Django user PKs. - Authority-instrument linkage. Authority instruments (advance directive, healthcare POA, RON-witnessed delegation, etc.) are FHIRConsent resources with an activation predicate (IMMEDIATE / ON_INCAPACITY / ON_DEATH / ON_AGE_18 / ON_EMERGENCY) that controls when the consent takes effect. End-of-life activation flows naturally — an advance directive with effective_when=ON_INCAPACITY activates a healthcare-POA grant when incapacity is declared; an executor designation with effective_when=ON_DEATH activates posthumous read-grants on death certification. - Multi-consent within a single ceremony. A single RON ceremony or onboarding flow can produce one primary instrument plus one or more secondary share grants in the same notarial session. FHIRConsent.parent_consent self-FK chains them; FHIR Bundle composition produces a single FHIR R4 Bundle (type=document) for delivery via DirectTrust DSM. - Data disposition on revocation. Each consent carries a revocation_data_disposition field (delete / retain / tombstone). Default is tombstone — ciphertext-only, inaccessible until re-consent. Per Decentralized by Design principle 1 (patient sovereignty over readable plaintext).

Operational since 2026-04-30. See DECISIONS.md Universal FHIR Consent primitive — Lisa Nelson lineage (Section 6) for the architectural detail and the Lisa Nelson DirectTrust 2025 panel lineage that grounds this design.

8. Incident Response and Breach Notification

We maintain interim incident-response procedures, including defined decision authority, containment steps, forensic preservation, and notification templates. A formal Incident Response Plan is in preparation and will be maintained as a living document thereafter.

Notification obligations are governed by the applicable law in each case:

• To affected individuals: without unreasonable delay and within the statutory deadline for the affected jurisdiction.
• To the Secretary of HHS: in accordance with 45 CFR § 164.408 where applicable.
• To state attorneys general and media outlets: where required by jurisdiction and scale.

Material incidents are followed by a written post-incident review and corrective actions.

8.5 Compliance email retention

Operational compliance email — communications regarding Business Associate Agreements, sub-processor security, breach disclosures, OCR / regulator inquiries, and counsel correspondence on HIPAA matters — is retained for seven years under Microsoft 365 Purview retention policy with end-of-period "retain only" (no auto-delete). This is the HIPAA §164.530(j) and §164.316(b) six-year baseline plus a one-year safety margin for state-law overlay. The operator mailbox (Andrew MacInnes) is under permanent always-on litigation hold to ensure spoliation defense regardless of regulator timing.

The cost of over-retention is trivial (Microsoft 365 storage is irrelevant at single-operator scale). The cost of over-deletion at a regulator request is severe (FRCP Rule 37(e) sanctions, OCR penalties). Always-on retention eliminates the gap between "should reasonably anticipate litigation" and "I remembered to flip the switch."

E3 license tier limitation: at present, Purview retention is applied tenant-wide rather than per-content-classification (auto-classification by content requires E5 tier). Reassessment is queued for post-family-beta or post-commercial-onboarding when HIPAA-related email volume grows.

9. Personnel and Physical Security

9.1 Personnel

Personnel with access to production systems have signed confidentiality obligations. Security-awareness practices are being formalized; interim expectations are conveyed directly to each person with access.

9.2 Workstations and Devices

Development and administrative workstations require full-disk encryption, automatic lock-on-idle, and modern endpoint protection. Removable media is discouraged.

9.3 Physical Security

Infrastructure is hosted in AWS data centers whose physical security is audited under SOC 2, ISO 27001, and HIPAA attestations. Brilliquid's development environment uses commercial-grade premises security.

10. Vendor Management

Third-party service providers are assessed before engagement, considering financial standing, track record, security posture (including available certifications), and data-handling practices. Vendor relationships are reviewed when material platform changes or new integrations create a change in the scope of vendor access.

11. Business Continuity and Recovery

Critical system components use encrypted backups separated from production. A Business Continuity Plan covering prolonged outages, key-person events, and vendor failures is in preparation. Recovery-time and recovery-point objectives are defined for each critical component.

NJ Notary RON ceremony retention. New Jersey Treasury Notary Public Division requirements (NJSA 52:7-10.7 et seq.) mandate audio-video recording retention for ten years for any RON ceremony performed under New Jersey commission. RON-ceremony recordings are stored in the brill-health AWS account under S3 Object Lock with KMS encryption; access requires authenticated administrative session and is logged. Retention is independent of the patient's account lifecycle (recordings persist past account closure if the ten-year window has not elapsed).

12. Privacy by Design

Features that collect or share new categories of data, or that introduce new sub-processors, undergo review before implementation and are reflected in the Privacy Policy before release.

13. Use of Artificial Intelligence

AI capability — including LLM use for parser generation, corpus cleaning, and editorial-discretion content generation — operates under AWS Bedrock (BAA-eligible AWS-managed Anthropic Claude surface) where PHI is involved. Bedrock provides a HIPAA-compatible Anthropic surface that direct Anthropic SDK access does not.

CDS-boundary discipline holds. AI does not interpret clinical content for patients or clinicians on the live patient path. AI generates code (parser fixes, corpus-cleaning utilities, visualization code), parses structured-but-unstructured-text data (e.g., extracting structured fields from a C-CDA narrative <text> block), or produces patient-facing curated content (NCCN guideline summaries, USPSTF screening schedules) at our editorial discretion. AI-generated code is committed to source control and inspectable; AI is dev-tooling, not a runtime service masking platform decisions.

We will not introduce any AI-assisted feature that handles Protected Health Information without an appropriate Business Associate Agreement with the AI provider (Bedrock under AWS BAA satisfies this). We will update this section in advance of introducing any AI-assisted feature on the live patient path, describing what the feature does, what data it sees, what it does not do, what contractual protections are in place, and how patients can opt out.

14. Policy Governance

This policy is reviewed on material changes to the platform, on changes to applicable law, and at least once per year. Substantive changes are versioned and recorded in the Document Control table.

15. Contact

Questions about this policy, or reports of suspected security issues, are directed to:

BrilLiquid LLC — Information Security Andrew MacInnes, Managing Member 406 Sun Valley Way, Florham Park, NJ 07932 security@brilliquid.com

Security researchers reporting potential vulnerabilities in good faith, and in accordance with industry-standard responsible-disclosure practices, will not be subject to legal action by Brilliquid.

Specific technical implementations — cryptographic algorithm choices, key-rotation intervals, and system-specific defenses — are documented in internal standards made available to authorized auditors under appropriate confidentiality. That level of detail is intentionally omitted from this document to avoid providing a roadmap to potential adversaries.

Partners conducting due diligence are invited to request specific evidence of any control described here; where a control is described as "in preparation" or "being formalized," we will candidly describe what is in place today and what the timeline is for formalization.