How we vet subprocessors
A subprocessor is a third party we engage to process data on behalf of our customers (the clinics and pharmacies that use neolife). Before any subprocessor touches PHI or personal data, we put a contract in place that binds it to the same data-protection commitments we make to you.
- BAA where there is PHI. If a subprocessor creates, receives, maintains, or transmits PHI, we execute a HIPAA Business Associate Agreement before it goes live.
- DPA for personal data. For personal data covered by the GDPR, UK GDPR, or US state privacy law, we sign a Data Processing Agreement with the relevant transfer mechanism attached.
- Least data. We share the minimum a subprocessor needs to do its job, and no more. Where a function can run without PHI, we keep PHI out of it.
- Security review. We check for current third-party attestations (such as SOC 2 Type II or ISO 27001), encryption in transit and at rest, access controls, and breach-notification terms before onboarding and on an ongoing basis.
Current subprocessors
The table below is representative of the categories of subprocessors we rely on. It is not a complete, point-in-time list. The current, authoritative list is available on request (see below).
| Subprocessor | Purpose | Data | Location | Safeguard |
|---|---|---|---|---|
| Amazon Web Services (AWS) | Cloud hosting, application compute, and encrypted storage | Order records, provider-approval logs, and PHI held inside our isolated VPC | United States | BAA; encryption in transit and at rest; HIPAA-eligible services only |
| Anthropic (Claude, via Amazon Bedrock) | Drafting and structured extraction of order data for provider review | PHI-minimized order content; prompts and outputs are not used to train models | United States (within our AWS environment) | BAA; runs inside our VPC; data minimization applied before processing |
| Authentication provider (identity / SSO) | Single sign-on, multi-factor authentication, and session management | User identifiers and account metadata; no clinical PHI | United States | DPA; BAA where applicable; SAML/OIDC, enforced MFA |
| Twilio (SMS) and Amazon SES (email) | Transactional notifications and tracking updates | Contact identifiers and message routing; PHI kept out of message content wherever it can be avoided | United States | BAA / DPA; content minimization; opt-out handling |
| Error and product analytics (privacy-first) | Application error monitoring and aggregate usage analytics | Diagnostic and event data; PHI scrubbed from logs and payloads | United States / EU | DPA; PII/PHI redaction; IP anonymization; data-retention limits |
What they touch
neolife is the rail that carries a compounded-prescription order from a clinic to its pharmacy and brings tracking back. The pharmacy that fills and dispenses the order is a separately licensed compounding pharmacy; compounded medications are prepared by that pharmacy and are not FDA-approved finished drug products. Our subprocessors support that flow and nothing beyond it.
- Hosting and storage subprocessors hold the order record and the audit trail of provider approvals.
- The AI subprocessor drafts and structures order data so a licensed provider can review it. A licensed provider approves every order. The AI does not approve, dispense, or prescribe.
- Authentication subprocessors verify who is signing in. Communications subprocessors deliver status and tracking messages.
AI processing and PHI minimization
Where we use a large language model to draft or extract order information, that model runs under a BAA inside our own cloud environment. We apply the minimum-necessary standard before any data reaches it: identifiers that are not required for the drafting task are stripped or tokenized, and the content passed to the model is limited to what the task needs.
Prompts, completions, and any PHI processed by the model are not used to train or improve the model. The output is always returned to a human: a licensed provider approves every order before the pharmacy fills it. Always.
International transfers
Our core infrastructure is hosted in the United States. Where a subprocessor processes personal data subject to the GDPR or UK GDPR outside the originating region, we rely on an approved transfer mechanism — the European Commission's Standard Contractual Clauses, the UK International Data Transfer Addendum, or an adequacy decision — together with supplementary measures such as encryption and access controls. These terms are part of each subprocessor's DPA.
Notice of changes
We may add or replace a subprocessor as the product evolves. When we intend to engage a new subprocessor or replace an existing one for a function that involves your PHI or personal data, we give advance notice in the manner and within the timeframe set out in your DPA, so that you have a reasonable opportunity to object on legitimate data-protection grounds.
If you have an active DPA with neolife and want to receive these notices, contact us at the address below to confirm the right recipient.
Request the current list
The table above is representative. To receive the current, complete list of subprocessors that process data on your behalf — including specific legal entities, processing regions, and the safeguard in force for each — email [email protected] and we will share it under your existing agreement.
Contact
Questions about our subprocessors, our BAAs, or our DPAs can be sent to [email protected].
This page is provided for transparency and may be updated from time to time. The “Updated” date above reflects the most recent revision.