List of HIPAA-Covered Services
List of HIPAA-Covered Services
Legal · Attachment 1 to the BAA · Bioscope Foundry, LLC (a Delaware limited liability company) · Effective date: June 23, 2026 · Last updated: June 23, 2026
Draft for legal review. The services and safeguards listed here describe Foundry’s operating platform as currently architected. Not legal advice; have counsel review before publishing.
The following Bioscope Foundry products and services are “Covered Services” under the Business Associate Agreement (BAA) when used by a physician practice in accordance with the Master Services Agreement and the BAA. Services not listed here are not Covered Services and must not be used to create, receive, maintain, or transmit PHI. PHI is stored in two Foundry-operated stores running on Foundry’s cloud subprocessor: a clinical workflow database (relational) that is the workflow source of truth, and a Foundry-operated FHIR R4 service that serves clinical resources. PHI is never written to local disk, logs, prompts, or generated documents.
1. Operating platform (Conductor)
Foundry’s authenticated operating platform, internally referred to as Conductor, is the system of record for clinical and administrative workflows.
1.1 Clinical workflow database
| Attribute | Detail |
|---|---|
| Function | Source of truth for clinical workflow: appointments, tasks, messaging, encounter state, follow-up tracking, and team coordination. Patient identifiers and clinical workflow context live here. |
| Underlying subprocessor | Cloud infrastructure provider: managed relational database (see Subprocessors). The database is Foundry-configured and Foundry-operated software running on the provider’s managed service. |
| PHI handled? | Yes |
| BAA in place? | Yes, with the underlying cloud subprocessor. |
| Safeguards | AES-256 encryption at rest under customer-managed KMS keys; TLS 1.2+ in transit; network-perimeter isolation; role-based access via the operating platform; short session timeouts; audit logging of all access (≥6-year retention). |
| HIPAA scope | Designated Record Set for the Practice; access and amendment supported through Conductor. |
1.2 FHIR clinical-resource service
| Attribute | Detail |
|---|---|
| Function | FHIR R4 clinical-resource boundary: demographics, encounters, observations, medications, lab orders & results, clinical notes, and related resources served through a private, Foundry-operated HAPI FHIR service. |
| Underlying subprocessor | Cloud infrastructure provider: the FHIR service runs as a Foundry-controlled workload on the provider’s managed compute; the FHIR software itself is HAPI FHIR (open source), self-hosted by Foundry and not a third-party subprocessor. |
| PHI handled? | Yes |
| BAA in place? | Yes, with the underlying cloud subprocessor. No separate FHIR-vendor BAA is required because the FHIR service is Foundry-operated. |
| Safeguards | Private network reachability (no public endpoint); TLS 1.2+ in transit; underlying storage encrypted at rest under customer-managed KMS keys; role-based access via the operating platform’s FHIR client; audit logging of all access. |
| HIPAA scope | Clinical-resource records for the Practice. |
1.3 Audit log & compliance surface
| Attribute | Detail |
|---|---|
| Function | Audit log of access to PHI, who, when, which record(s), outcome, and compliance reporting surface. |
| Underlying subprocessor | Cloud infrastructure provider: managed logging plus application-level audit-events table in the workflow database. |
| PHI handled? | Identifiers only: audit rows record actor, action, target-type, target-id, and outcome using machine-readable codes; PHI content is not written to logs. |
| BAA in place? | Yes |
| Safeguards | ≥6-year retention; access restricted to security and compliance roles; UPDATE and DELETE revoked at the database level for audit rows; integrity monitoring. |
2. Multi-agent system (Atlas & Forge Agents)
Foundry’s agent-orchestration platform, internally referred to as the Foundry Master Agent, coordinates a tiered set of AI agents that support practice operations. Tier eligibility for PHI is enforced at the policy spine; sandboxed public workers cannot hold PHI.
2.1 Atlas (Tier-0 orchestrator)
| Attribute | Detail |
|---|---|
| Function | Tier-0 orchestration: routes work, applies policy, manages placement and migration of tasks across the agent fleet. |
| Underlying subprocessors | AWS-managed compute; Anthropic Claude API (under BAA) for reasoning; Foundry-controlled policy spine. |
| PHI handled? | Yes: Atlas may receive PHI in agent reasoning contexts where Tier-3 clinical workflows require it; PHI flows to the Anthropic Claude API under BAA. The Beacon Layer enforces redaction before PHI crosses into physician-facing surfaces and before any task is dispatched to a Tier-4 Moltworker. |
| BAA in place? | Yes |
| Safeguards | Policy-spine redaction before any cross-tier hop; never exposes raw PHI or peer-private memory to lower tiers. |
2.2 Tier-1 executive assistants (Goose & Maverick)
| Attribute | Detail |
|---|---|
| Function | Foundry-internal executive assistants supporting administrative workflows for Foundry staff (not Practice-scoped). |
| Underlying subprocessors | Anthropic Claude API (Goose), under BAA; OpenAI API (Maverick) operates outside PHI scope. |
| PHI handled? | No, by policy: Tier-1 assistants operate over Foundry-internal data, not Practice PHI. |
| BAA in place? | Yes (defense-in-depth) |
| Safeguards | Policy spine blocks PHI from entering Tier-1 context; workforce confidentiality obligations; audit logs of agent invocations. |
2.3 Tier-2 Foundry ops & specialist agents
| Attribute | Detail |
|---|---|
| Function | Specialist agents for Foundry operations (vendor management, security operations, knowledge curation). |
| Underlying subprocessors | Anthropic Claude API (under BAA); Foundry-controlled hosts. |
| PHI handled? | No, by policy |
| BAA in place? | Yes |
| Safeguards | Operations scope; no Practice or patient-scoped queries permitted. |
2.4 Tier-3 clinic-scoped clinical agents
| Attribute | Detail |
|---|---|
| Function | Practice-scoped agents that may handle PHI to support clinical-adjacent workflows (record summarization, message drafting, intake triage, prior-auth assembly). Outputs are advisory; a clinician reviews material decisions. |
| Underlying subprocessors | Anthropic Claude API (under BAA); the managed FHIR service as the source of record. |
| PHI handled? | Yes |
| BAA in place? | Yes |
| Safeguards | Clinic-scoped data isolation; minimum-necessary PHI in any prompt; PHI not used to train or fine-tune general-purpose models; outputs logged; human-in-the-loop for clinical and compliance decisions; Beacon Layer redaction before any cross-tier surfacing. |
2.5 Tier-4 workers (Moltworkers)
| Attribute | Detail |
|---|---|
| Function | Sandboxed-public workers for non-clinical, non-Practice tasks (for example, public-document drafting, marketing research, public-data ingestion). |
| Underlying subprocessors | Sandboxed compute on Foundry-managed hosts; LLM providers vary by task. |
| PHI handled? | No, never |
| BAA in place? | N/A (PHI is not permitted into this tier) |
| Safeguards | Tier-4 Moltworkers cannot handle PHI, clinic-scoped data, or peer-private memory. The policy spine and host-agent enforcement prevent placement of any such workload on a sandboxed_public host. |
3. Communications surfaces
3.1 Secure in-platform messaging
| Attribute | Detail |
|---|---|
| Function | Authenticated messaging between Practice staff, providers, and patients within Conductor. |
| Underlying subprocessor | Foundry-operated services on AWS, with content persisted in Foundry’s FHIR service. |
| PHI handled? | Yes |
| BAA in place? | Yes |
| Safeguards | TLS in transit; AES-256 at rest; role-based access; audit logging; short idle timeouts; minimum-necessary patient context. |
3.2 Patient notification routing (SMS & email)
| Attribute | Detail |
|---|---|
| Function | Out-of-band notifications (appointment reminders, login codes, secure-message-waiting alerts). Designed to avoid containing PHI: clinical content stays inside authenticated systems. |
| Underlying subprocessors | Amazon SES (AWS, covered by the AWS BAA) for transactional email; SMS delivery, when enabled, will use a provider listed on the subprocessor page. |
| PHI handled? | Identifiers only by design. |
| BAA in place? | Yes for the providers involved. |
| Safeguards | Templates restrict content to non-PHI; rate limiting; audit logging; opt-out support. |
4. Integrations & EHR bridges
| Attribute | Detail |
|---|---|
| Function | Integration with third-party clinical and administrative systems (EHR/EMR connectors, lab interfaces, e-fax, pharmacy connections) where elected by the Practice and listed on the Order. |
| Underlying subprocessors | Vary by integration; each PHI-touching integration is listed on the Subprocessors page. |
| PHI handled? | Yes, where the integration carries PHI. |
| BAA in place? | Yes with PHI-handling integration partners before any PHI flow. |
| Safeguards | BAA execution gates production traffic; data flowing through Foundry is brokered through the FHIR R4 layer; per-integration audit logging. |
5. What is not a Covered Service
The following are not Covered Services and must not be used to handle PHI:
- The public marketing site (bioscopefoundry.com). It does not process PHI. Do not submit patient information through public forms.
- Tier-4 Moltworkers running on
sandboxed_publichosts. - Workforce communication tools Foundry uses internally (e.g., Slack, Linear); these are not on the PHI plane by policy; PHI is not introduced into them.
- Beta, preview, or experimental features not yet listed in this Attachment 1.
- Third-party tools or integrations the Practice elects to use outside the Services.
6. Cross-cutting safeguards
All Covered Services are subject to the safeguards described in the BAA and the Foundry security program, including:
- Encryption: TLS 1.2+ in transit; AES-256 at rest; customer-managed keys available for the FHIR store.
- Identity & access: passwordless authentication, MFA-available, least-privilege role-based access, short idle/absolute session timeouts.
- Audit logging: every access to PHI is logged; logs record identifiers, not PHI content; retained for at least six years.
- Network & secrets: network-perimeter isolation around the PHI-handling account; managed secret broker; credentials never stored in source code.
- Beacon Layer: physician-facing insight surface is sanitized; raw PHI and peer-private memory never leak across tier boundaries.
- Workforce: confidentiality obligations, security and privacy training, sanctions process for violations.
- Subprocessor governance: every PHI-handling subprocessor is under a BAA; current list at Subprocessors.
7. Updates to this list
Foundry may update this list of Covered Services from time to time. Foundry will provide at least 30 days’ prior written notice to the Practice before removing a Covered Service that the Practice is actively using or before adding a new PHI-handling subprocessor under a Covered Service. Emergency security changes may occur on shorter notice with prompt follow-up notification.
See also: Business Associate Agreement · HIPAA Notice · Subprocessors · Data protection policy.
© 2026 Bioscope Foundry, LLC. All rights reserved. This draft is provided for internal and legal review and does not constitute legal advice.