Data Management

Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

This policy sets the requirements and controls Bioscope Foundry uses to manage data across its lifecycle, creation or acquisition, classification, storage, backup, retention, and disposal. Protected health information (PHI) that Foundry handles for a physician practice lives only inside Foundry’s clinical data plane: a Foundry-operated clinical workflow database (the source of truth for clinical workflow, appointments, tasks, encounter state, messaging) and a private FHIR R4 service that serves clinical resources. Both stores are Foundry-operated software running on Foundry’s cloud infrastructure subprocessor under the Business Associate Agreement (BAA) between Foundry and the practice. Bioscope Foundry is a HIPAA business associate, not a covered entity; the practice remains the covered entity.

1. Purpose & scope

This policy outlines the requirements and controls Bioscope Foundry has implemented to manage the end-to-end data lifecycle, from creation or acquisition through retention and deletion, across the MSO operating platform, internal business systems, and the public marketing site.

It also defines how Foundry creates and maintains retrievable exact copies of electronic PHI (ePHI) and other critical business data, so that information remains available for the physician practices we support and for Foundry’s own operations in the event of a disruption.

Data backup is part of Foundry’s day-to-day operations. To protect the confidentiality, integrity, and availability of ePHI, and of customer and business data, Foundry runs scheduled backups so data remains available when needed and recoverable in case of a disaster. PHI backups are operated within HIPAA-eligible cloud provider services covered by Foundry’s BAA with the provider.

2. Policy statements

Foundry policy requires that:

(a) Data is classified at time of creation or acquisition according to the Foundry data classification model and labeled or tagged where the storage system supports it.

(b) An up-to-date inventory and data-flow map is maintained for all critical data, including the flow of PHI into and out of Foundry’s FHIR service.

(c) Business data is stored or replicated in a company-controlled repository. Data on end-user computing devices is treated as transient and must be backed to an approved company repository (for example, the managed document store) for any business record.

(d) Data is backed up according to its level in the Foundry data classification.

(e) Data backups are validated for integrity.

(f) Retention periods are defined, kept to the minimum required by business need, and aligned with regulatory and contractual obligations. In particular:

PHI handled on behalf of a physician practice is retained and disposed of as required under HIPAA and the practice’s BAA, with a six-year minimum for required HIPAA documentation;
Data and records belonging to member practices are retained per the Master Services Agreement and any specific contractual addenda;
Workforce, financial, and tax records are retained per applicable Delaware and U.S. federal requirements.

(g) By default, security documentation and audit trails are retained for a minimum of six years, unless the data classification, a specific regulation, or a contractual agreement requires a longer period.

(h) PHI is never copied to local disk, agent worktrees, prompts, memory, generated documents, or logs. PHI lives only in Foundry’s FHIR service (R4); audit records refer to PHI by FHIR resource identifier rather than by content.

3. Controls & procedures

3.1 Data classification model

Foundry defines four classifications of data. Examples are illustrative, not exhaustive.

PHI

Protected Health Information that Foundry creates, receives, maintains, or transmits on behalf of a physician practice. Strictest controls apply.

Patient demographics, encounters, clinical notes, medications, lab orders and results, and related FHIR resources;
FHIR audit events that reference patient resources;
Communications metadata that ties an individual to a clinical encounter.

PHI is stored and processed only within Foundry’s FHIR service (R4). External disclosure is permitted only as authorized by the BAA, by the practice, or by law.

Confidential

Information that represents Foundry’s or a practice’s business secrets, or is otherwise of significant value to the company or its members. Unauthorized disclosure may disrupt operations and erode trust. Disclosure requires an NDA and management approval.

Physician contracts, MSAs, BAAs, and addenda (executed and in-flight);
Financial records, banking details, and payment-processor data;
Workforce / HR data and applicant data outside what Foundry’s HRIS exposes;
Pre-announcement business plans, fundraising materials, and product strategy;
Non-production secrets, access keys, private certificates, and related material;
Non-production security audit logs, incident records, security architecture documents, and internal audit reports.

Internal

Non-sensitive business data used for day-to-day operations. Unauthorized disclosure may be undesirable but is not likely to cause material harm. Disclosure outside Foundry generally requires management approval; an NDA is usually required and may be waived case by case.

Internal documentation, runbooks, and standard operating procedures;
Policies and procedures (this Trust Center is the public-facing extract);
Product plans, design documents, and engineering specifications;
Most source code in Foundry’s GitHub organization (bioscope-foundry).

Public

Information intended for public consumption. Public data is not confidential. Foundry protects its integrity and availability.

Content on bioscopefoundry.com and other Foundry-owned marketing surfaces;
Post-announcement news, press, and brand assets;
Public product documentation;
This Trust Center.

3.2 Data handling requirements matrix

Requirements for data handling, encryption, retention, access, and recovery, are defined according to Foundry’s data classifications.

Data	Labeling or tagging	Segregated storage	Endpoint storage	Encrypt at rest	Encrypt in transit	Encrypt in use	Controlled access	Monitoring	Destruction at disposal	Retention period	Backup & recovery
PHI	Required (FHIR resource type)	Required (Foundry’s clinical data plane, segregated cloud environment)	Prohibited	Required (AES-256; CMEK available on BAA)	Required (TLS 1.2+)	Required	Blocked by default; least-privilege, role-based, audit-logged access via the conductor platform only	Required (cloud audit logs; FHIR audit events)	Required (cryptographic erasure or BAA-defined return/destruction)	Six-year minimum for required HIPAA documentation; longer where the practice or law requires†	Required
Confidential	Required	N/R	Allowed (encrypted endpoint, MDM-managed)	Required	Required	Required	Need-to-know	Required	Required	Six years for official documentation; otherwise per business or contractual need	Required
Internal	Required	N/R	Allowed (encrypted endpoint, MDM-managed)	N/R	N/R	N/R	Workforce and contractors (read); data owners and authorized individuals (write)	N/R	N/R	Six years for official documentation; otherwise per business need	Optional
Public	N/R	N/R	Allowed	N/R	N/R	N/R	Everyone (read); data owners and authorized individuals (write)	N/R	N/R	Per business need	Optional

N/R = Not required. † Practice-owned PHI is retained for as long as the practice remains a Foundry member, or as required by HIPAA and applicable state record-retention law, whichever is longer. On offboarding, PHI is returned or destroyed per the BAA.

Symmetric encryption uses AES-256. Hashing for integrity uses SHA-256 or SHA-3 family algorithms. Password hashing, where applicable to Foundry-issued credentials, uses argon2id; Foundry is largely passwordless in practice (see Access Control).

3.3 Data inventory and lifecycle management

Foundry maintains a data inventory across its cloud-based infrastructure and core SaaS, including:

FHIR datasets and stores (PHI);
Amazon S3 object storage buckets, Amazon RDS datastores, and AWS Secrets Manager;
Cloudflare Workers and R2 storage (marketing surfaces);
GitHub source-code repositories in the bioscope-foundry organization;
the identity provider (Drive, Gmail, Calendar) for internal records;
Operational SaaS systems used by the back office (CRM, billing, e-signature, HRIS, ticketing).

The inventory captures owner, classification, storage location, and data flows. PHI flows are tracked separately as part of the BAA evidence package and are referenced in the HIPAA Security Rule mapping.

Object lifecycle and storage classes

For non-PHI bulk storage in the cloud managed object storage, Foundry uses object lifecycle policies to transition data between storage classes (Standard, Nearline, Coldline, Archive) based on age and access pattern. Lifecycle policies also age out backups and historical artifacts on a schedule consistent with the retention rules in this policy.

PHI in the FHIR store is not subject to discretionary tiering by Foundry. Versioning and cloud audit logs preserve the change history that HIPAA requires.

Other business data

Internal and confidential business records, product plans, financial models, decisions, presentations, contracts, are stored in managed repositories, not on workforce laptops:

Source code & reviews: GitHub (bioscope-foundry);
Tickets & planning: Linear;
Documents & spreadsheets: the managed document store;
HR & payroll: the HRIS / payroll platform;
Contracts & e-signature: the e-signature system;
Accounting & AP/AR: the accounting / bill-pay platform.

Confidential business documents are stored in encrypted form with access controlled on a need-to-know basis.

Transient data

Foundry does not use transient storage for PHI. Where transient processing is required for non-PHI workloads (for example, intermediate computation in a worker), the data is purged immediately after use and the worker tier is configured so it cannot persist outside its sandbox.

3.4 Backup and recovery

PHI and clinical platform data

PHI is stored in Foundry’s clinical data plane on Foundry’s cloud infrastructure subprocessor: the clinical workflow database (a provider-managed relational service) and the private, Foundry-operated FHIR R4 service (running as a container workload on the provider’s managed compute). Foundry relies on the provider’s HIPAA-eligible managed services for durability and runs scheduled backups consistent with the BAA between Foundry and the provider. Data is replicated within the provider’s regional infrastructure; backups are encrypted under the same customer-managed KMS keys as live data. Customer-managed encryption keys (CMEK) are available on request via the practice’s BAA.

Recovery is exercised on a defined cadence as part of the BCDR program. Practices may export their FHIR data through the conductor platform; standard API usage applies.

Source code

Foundry source code lives in GitHub. Repositories in the bioscope-foundry organization are mirrored to a Foundry-controlled cloud project on a recurring schedule. In the event of catastrophic loss at GitHub, source can be restored from the mirror. Git’s commit log preserves a full change history independent of the host.

Business records and documents

Each data owner is responsible for moving working files off their local device to the appropriate location in the managed document store (or the system of record above). Local backups of non-PHI personal productivity material are self-managed by the device owner, are restricted to encrypted, password-protected media, and may never include PHI or other Critical data. Confidential business records are stored in encrypted form with access controls on a need-to-know basis.

3.5 Data deletion and offboarding

For member practices

Foundry’s Master Services Agreement supports a 90-day clean offboarding for member practices. On voluntary termination:

The practice may export its FHIR data through the conductor platform during a defined offboarding window;
At the practice’s election in the BAA, Foundry returns the PHI to the practice or destroys it (cryptographic erasure of CMEK-protected data, or BAA-defined destruction for provider-managed key environments);
Non-PHI operational records (configurations, integrations, account metadata) are removed from active systems and aged out of backups on the standard backup schedule.

If a practice’s account is involuntarily suspended for non-payment or terms-of-service violations, there is a grace period during which the account is inaccessible but recoverable. After the grace period, the account is closed and data is deleted in line with the BAA, except where law requires retention.

For Foundry workforce

When a workforce member departs, their account is deactivated, devices are wiped through MDM, and access to PHI-bearing systems is revoked through identity provider workflows. Personal work product moves to a Foundry-controlled location before access is removed. See HR & personnel security.

Foundry’s covered-entity status

Foundry is not a covered entity and does not provide healthcare services directly to patients. If Foundry’s posture were to change, this policy would be updated to incorporate the patient-record retention requirements that apply to providers, and the change would be communicated under Policy management.

4. Roles & responsibilities

Security Officer: owns this policy, the data classification model, and the lifecycle / retention defaults.
Privacy Officer: owns the BAA evidence package and the interface to member practices on PHI handling.
Engineering leads: implement classification, retention, and deletion in the platforms they own; review FHIR audit data and lifecycle policies.
Data owners: keep records inside Foundry-controlled repositories, tag confidential material, and request retention exceptions in writing.
Workforce members: follow handling requirements for the classifications above and never copy PHI to local disk, prompts, or generated documents.

5. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the Policy Management process.

6. Related policies

Facility & Physical Security Data Protection