Skip to main content
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 require. Write to hello@haau3.com to request one. Until both are in place, the operations below accept only 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:
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 and Pharmacy Benefits 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

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 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. Last updated 2026-10-25.