The PHI boundary

neolife is built so that protected health information (PHI) never leaves the platform through a callback. Webhooks and events carry ids and status — never patient names, contact details, clinical answers, or prescription content.

The rule#

• Outbound (webhooks, events): ids + status only. PHI-free by contract.
• Inbound (your GETs): you hydrate the PHI you need over authenticated, access-controlled reads, when you need it.

// A webhook payload — safe to log, safe to route through third-party infra
{
  "type": "order.shipped",
  "id": "evt_1a2b3c",
  "data": {
    "orderId": "ord_123",
    "pharmacyConnectionId": "pc_9",
    "status": "shipped"
  }
}

To get the shipment's tracking number, patient, or prescriptions, you call the authenticated API:

curl https://api.neolife.health/v1/orders/ord_123 \
  -H "Authorization: Bearer $NEOLIFE_API_KEY"

Why it's designed this way#

Webhook infrastructure is notoriously leaky — payloads get logged, queued, forwarded, and retried across systems you don't fully control. By keeping PHI out of every callback:

• Your webhook endpoint stays out of PHI scope. Logs, queues, and observability tooling on the receiving side never see patient data.
• Reconciliation is safe by default. You can pull and replay the full event history to recover from downtime without ever handling PHI in the process.
• The blast radius of a misconfigured integration is small — a leaked event reveals an order id and a status, not a person.

What counts as PHI here#

Intake answers, patient identity and contact details, and prescription content are treated as PHI and are encrypted at rest. They are only ever returned over authenticated, permission-checked API calls — never pushed to you.

Practical guidance#

• Treat every webhook as a signal to fetch, not as a data source.
• Do your PHI reads from a server that's already in scope for patient data, using a scoped API key.
• Verify webhook signatures before acting — see Webhooks & events.