> ## Documentation Index
> Fetch the complete documentation index at: https://docs.haau3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Patient data

> Which operations receive protected health information, what they keep, where patient data goes, and what the logs hold.

Most of the platform serves public data: provider availability, the provider directory,
terminology, questionnaires and health plan benefits. Two operations receive protected health
information (PHI). This page says how each one handles it. It changes when a service does, and the
date at the end says when it last did.

## Before you send PHI

Send PHI only once your organization is on the Team or Scale plan and has a business associate
agreement (BAA) executed with haau3, as the [terms](https://platform.haau3.com/terms) require. Write
to [hello@haau3.com](mailto:hello@haau3.com) to request one. Until both are in place, the operations
below accept only [test data](#test-data) and refuse anything else.

## Test data

Without a BAA in force and the Team or Scale plan, MedList and a member's Pharmacy Benefits request
accept only test data marked as such, on every plan. Mark a request with HL7's test data label in
`meta.security`, on the request and on every resource in it:

```json theme={null}
"meta": {
  "security": [
    {
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "HTEST",
      "display": "test health data"
    }
  ]
}
```

The request itself (the `Bundle` or `Parameters`) carries the label, and so does each resource in
it: every Bundle entry, every resource part, and the entries of a Bundle sent as a part. A resource
contained in another goes with the one that contains it. The example requests on the
[MedList](https://docs.haau3.com/medlist/medlist.md) and [Pharmacy Benefits](https://docs.haau3.com/benefits/pharmacy.md) pages carry the label
already. Pharmacy Benefits' check without patient details carries no patient, so it needs none.

A request without the label is refused before the operation runs, with a `403` whose
`OperationOutcome` is coded `forbidden` and carries `phi-agreement-required` from
`https://haau3.com/fhir/CodeSystem/api-error` in `issue.details.coding`. When some resources carry
the label and some do not, `expression` names the first resources without it. A test data request
counts toward your plan like any other request.

Label only made-up data. The label says a record is not about a real person, and it is never a way
to send PHI without a BAA.

## The operations that receive PHI

| Operation | What it receives | Page |
| - | - | - |
| MedList, `POST /v1/fhir/r4/$reconcile-medications` | A patient's medication records | [MedList](https://docs.haau3.com/medlist/medlist.md) |
| Pharmacy Benefits, `POST /v1/fhir/r4/$process-message` | A member's request to check what a medication would cost under their plan. The check without patient details carries none. | [Pharmacy Benefits](https://docs.haau3.com/benefits/pharmacy.md) |

Pharmacy Benefits is not yet open to customers.

## What they keep

Nothing. Each request is answered on its own, and nothing it carries is stored, cached or kept after
the answer is sent. Every answer, errors included, carries `Cache-Control: no-store`, so no cache
between you and the API keeps one either. An error never repeats a record's contents: MedList names
a record it skipped only by its `fullUrl` or `{resourceType}/{id}`, and Pharmacy Benefits names an
element it refused only by its path.

## Where patient data goes

* **MedList** returns its answer to you and sends nothing that identifies the patient anywhere else.
* **Pharmacy Benefits** sends a member's request to the one health plan that answers for the
  member's coverage, with the member's `Payer-Authorization` when you include one, for that one
  check. It never sends patient data to a source of cash prices.

The platform runs on Google Cloud, under Google's business associate agreement with haau3. Data
moves to and from the API over TLS. haau3's email runs on Google Workspace under the same
agreement, so a message about an incident, or one you send us, that holds patient data stays under
it.

## What the logs hold

For each request, the logs hold its route, method and status; its timing and counts; your
organization and API key; haau3's request id and any [request id](https://docs.haau3.com/errors.md#request-ids) you send;
an error's type, never its message; whether a member's authorization was sent; and the names of
any query parameters the API refused, never their values. They hold no request body and no answer
body. Google Cloud's own request log also records each request's URL, IP address and user agent;
the two operations above take no query parameters but `_format`, so their URLs carry no patient
data.

Each request also leaves a usage record of its route, method, status, service, organization and
API key.

<sub>Last updated 2026-10-25.</sub>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.