AI that works near PHI without sending it anywhere.
Data.co runs private models, retrieval, and agents inside your hospital, health system, or vendor environment. Policies scope access to protected health information by role, purpose, and agent, and every request is recorded in an audit log you hold.
Where PHI goes is the whole question.
Under HIPAA, every system that creates, receives, maintains, or transmits PHI on your behalf is part of your compliance picture. A hosted AI API that receives a discharge summary is a business associate, with the agreements, risk analysis, and oversight that entails. Many organizations stop the project there.
Data.co Control is deployed inside your environment and operated by you or by Data.co Managed Services under your agreements. The hosted account portal at app.data.co handles licensing and billing only and never receives prompts, documents, embeddings, or records. Where Data.co personnel or managed services would have access to PHI, a business associate agreement is required and is scoped to that work.
Concrete patterns we design around.
Clinician summarization
A private model summarizes a patient's chart for a clinician with an active treating relationship. Requests without that relationship are denied with a stated reason.
Prior authorization drafting
An agent assembles the clinical justification from orders and results for a specific request, and a human approves before anything is submitted to a payer.
Policy and procedure search
Staff ask questions across internal policies and forms. These documents are labeled non-PHI and open broadly, while patient records stay out of the index.
Coding assistance
Coders get suggested codes grounded in the encounter documentation they are already authorized to view, with citations back to the source text.
De-identified analytics
Analysts query datasets with direct identifiers removed or masked, while re-identification fields stay restricted to a named group.
Patient correspondence
Drafts of letters and portal replies stay on local models, with outbound text checked for identifiers before it leaves a workflow.
What Data.co provides and what remains yours.
Technical controls support your program; they do not replace it.
| Area | Data.co Control provides | Your organization remains responsible for |
|---|---|---|
| Access | Policy enforcement by identity, role, label, and purpose | Defining roles and minimum-necessary rules |
| Audit | Append-only local log of requests and decisions | Reviewing logs and investigating incidents |
| Data location | Inference and retrieval inside your environment | Securing the underlying infrastructure |
| Agreements | A BAA where Data.co services touch PHI | BAAs with your other vendors and risk analysis |
| Models | Approval status and routing for model endpoints | Clinical validation of any AI-assisted output |
Two rules most health systems start with.
Minimum necessary is a judgment about purpose, not just role. These illustrative policies tie chart access to a treating relationship carried as an attribute on the request, and keep PHI away from any endpoint outside your network. Tests in the same repository must pass before either rule activates.
id: pol_hc_chart_001
description: Chart summaries only for clinicians with a treating relationship
subject: { type: agent, tags: [clinical-assistant] }
resource: { dataset: "ehr.*", classification: [PHI] }
action: [read, search]
when:
purpose: treatment
context.attr.treating_relationship: true
effect: allow
otherwise: deny
explain: "Chart access requires an active treating relationship for this patient."Illustrative example · final API surface documented in /docs
Where the data comes from, and how it is labeled.
Connections are read-only by default. Labels drive policy, so getting them right at ingest matters more than any single rule.
| Source | Typical interface | Default label |
|---|---|---|
| EHR clinical documentation | Reporting replica, FHIR API, or document export | PHI, clinical |
| Patient accounting and claims | Database replica, 837/835 files | PHI, financial |
| Scheduling and referrals | Database replica or HL7 feed | PHI, operational |
| Policies, procedures, forms | Document management or intranet export | Internal, non-PHI |
| Payer contracts and rules | Document repository | Confidential, non-PHI |
| Research and quality extracts | Warehouse views with identifiers masked | De-identified or limited data set |
A first deployment, in order.
- 1
Risk analysis input
Document the data flows for the first workflow so your privacy and security officers can fold them into the organization's risk analysis.
- 2
Non-PHI first
Start with policy and procedure search, which proves the platform and the identity integration without touching patient records.
- 3
One PHI workflow
Add a single PHI workflow, such as coding assistance, with approvals on and a weekly audit-log review by the privacy office.
- 4
Widen by review
Each new dataset or agent arrives as a reviewed policy change with tests, so the access picture stays explainable to an auditor.
Questions your privacy officer will ask.
- Which datasets carry the PHI label, and who applied it
- Which agents can read which record types, and why
- Whether any model endpoint is outside your environment
- How access by a non-treating user is handled
- Where audit records live and who can read them
- How a disputed AI-assisted output can be traced to its sources
Questions buyers ask
Does using Data.co satisfy HIPAA?
HIPAA compliance is a property of an organization's program, not a product. Data.co is designed to support HIPAA safeguards such as access control, audit controls, and minimum-necessary use, deployed inside your environment so PHI does not leave it.
Will you sign a business associate agreement?
Where Data.co or its managed services team would create, receive, maintain, or transmit PHI on your behalf, we expect to sign a BAA scoped to that work. A self-operated deployment where Data.co has no access to PHI may not require one; your counsel should make that determination.
Does any PHI reach app.data.co?
No. app.data.co handles accounts, licensing, billing, and opt-in administration. Prompts, documents, embeddings, and records stay in your deployment.
Which models can we run?
Open-weight models served locally through vLLM or Ollama, registered in the model catalog with an approval status. Policies can restrict PHI to approved local endpoints only.
Can we integrate with our EHR?
Data.co connects through standard interfaces such as database replicas, FHIR APIs, and document exports, and carries source-system permissions forward where they can be mapped. Specific EHR integrations are scoped during assessment.
What does the audit log record about a patient lookup?
The identity, the user an agent acted for, the dataset and action, the decision, the policy IDs, and an explanation. It does not store prompt text or record contents, so the log itself does not become another copy of PHI.
Can we use de-identified data with fewer restrictions?
Yes, if your de-identification method supports it. Datasets can carry a de-identified label with broader policies, while re-identification keys stay restricted. Which method qualifies remains a determination for your privacy team.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.