A compliance page is usually a list of logos. This one is a list of mechanisms. For each control it says what the rule is, where in the system it lives — the database, the application, or your procedure — and what evidence it leaves. Where a control is a matter of your validation or your state's rules rather than ours, it says that too.
The principle: enforce in the database, record everything
Application code can be bypassed — by a different screen, a script, a direct API call, or a bug. So the controls that matter most in Pharmacy Flow are not in the screens. The allowed order and lot status transitions are tables in Postgres; triggers reject any update not in them and check the interlocks; status changes go through database functions that check the caller's permission; and the tables that hold evidence — events, approvals, audit log, comments — refuse updates and deletes from application roles. Screens then become one way of asking the database to do something it would refuse to do wrongly.
21 CFR Part 11: signatures and audit trail
Part 11 sets the conditions under which electronic records and electronic signatures are accepted in place of paper. The controls in the platform map to its sections as follows.
- §11.10(e) audit trail
- Every material action writes an event with actor, timestamp and summary. Events, approvals and the audit log are append-only for application users — the database revokes update and delete on those tables from the application roles.
- §11.10(d),(g) access and authority checks
- Users authenticate individually; permissions are rows in a role-permissions table checked by the database functions that change status and by the application before each guarded action.
- §11.50 signature manifestation
- Each signature records the printed name of the signer, their role, the date and time, and the meaning of the signature from a fixed list: Reviewed, Approved, Released, Verified, Witnessed, Rejected.
- §11.70 signature/record linking
- A signature row references the entity type and entity id it applies to (batch, lot, prescription, formulation, deviation, CAPA, change control, document) and cannot be edited or removed by application users.
- §11.200 signature components
- Signing requires two distinct components: the authenticated session identity and a fresh password entered at the moment of signing. If re-authentication fails, no signature is applied.
The Part 11 explainer covers what this looks like in a quality workflow and why a PDF on a shared drive fails it.
Order and lot lifecycles enforced by triggers
An order's allowed transitions — Received, Eligibility, Clinical Review, In Production, Packed, Shipped, Delivered, On Hold, Cancelled — are rows in a transitions table. A BEFORE UPDATE trigger rejects any status change not in the table and enforces the interlocks: Shipped requires a recorded pack verification; Packed requires a finished lot; an order tied to a prescription cannot be Packed or Shipped unless the prescription is Filled. Finished lots move Quarantine → Available only when at least one QC test exists, every test is Pass and a release signature is recorded; raw lots move to Available only after QA release; a lot cannot be marked Consumed while it has quantity; Rejected and Consumed are terminal. Every change writes a history row with actor and time. The 503B page walks the release interlock in detail.
Permissions checked in the database
Roles and their permissions are rows, not code. Lot release requires
qa.release, held by Pharmacist and QA and not by Technician; QMS sign-off and formulation approval require permissions held by QA; moving an order to Packed, Shipped or On Hold requires dispense or orders.manage, and other order transitions require orders.manage. The status functions check these before acting, so separation of duties is enforced by the database rather than by which buttons a screen shows. Platform-operator access is a distinct permission that an organisation admin's wildcard does not grant. A demo "view as" feature lets a real Admin see the application as another role but cannot be used to escalate.DEA, state licensure and the pharmacist's screen
The compliance rules are one pure module called by every intake path. A formulation's DEA schedule is the most restrictive of its components. Schedule II refills are refused (21 CFR 1306.12). Schedule III–V refills are refused beyond five or beyond six months from the written date (21 CFR 1306.22 for III and IV; the platform applies the same limit to V as a conservative default). A controlled material without a parseable schedule, or a missing refill count, holds the refill rather than allowing it. The ship-to-state licence gate fails closed: no licence for the state, an expired or inactive one, or a controlled product into a state whose record does not permit compounded controlled substances all hold the order. Before verification the pharmacist sees a DUR screen built only from data the pharmacy holds — duplicate therapy, GLP-1 class duplication, controlled-with-refills, quantity versus days-supply, a GLP-1 counselling reminder, and an explicit statement that no allergies are on file. The 503A page lists each rule as applied.
USP <795>/<797>/<800> records
Beyond-use dating: a finished lot's BUD is the formulation's BUD or the earliest expiry among the raw-material lots consumed, whichever is sooner, computed in the database; a unit past BUD fails the fill scan. Environmental monitoring: readings are recorded per room and ISO class with the action limit stored on each reading and the Pass/Alert/Action status derived from it; Action readings link to the environmental deviation category. Hazardous drugs: materials flagged hazardous are routed to segregated hazmat storage on putaway and carried as a hazardous packout; controlled materials go to vault storage; refrigerated and frozen to matching storage, with the reason recorded. Quality system: deviations, CAPA, change control and controlled documents with signed approvals. The sterile compounding page and the USP <800> checklist cover the chapters.
Serialization, carrier events and recall
Each dispensed unit carries a serial on a GS1 DataMatrix label with GTIN (01), lot (10) and serial (21); cartons and pallets carry an SSCC on a GS1-128 label. Fill, pack, verify and ship each write an EPCIS-style event with read point, business step and disposition. Document and serial numbers come from a database sequence with unique indexes, so duplicates cannot be created. Carrier scans are stored one row per carrier event with a unique index, so retries never duplicate; delivery cascades to the order but honours a QA hold. Recalls are initiated from a lot's trace, classified under 21 CFR 7, and tracked per unit to reconciliation; a recalled unit fails the fill scan. See serialization and DSCSA.
Bring your quality and IT leads to a demo
We will show the trigger refuse a bad transition, the signature refuse a wrong password, and the audit table refuse a delete — on live software, not slides.
Data protection and tenant isolation
- ✓Tenant isolation by row-level security. Every tenant-scoped table has RLS enabled and policies that restrict rows to the caller's organisation, evaluated once per query. Anonymous roles have no write access to application tables.
- ✓Append-only evidence. Events, approvals, audit log and comments cannot be updated or deleted by application roles.
- ✓Individual accounts. Each user has their own credentials; new accounts are created with a random one-time password that is never reused. Signing requires password re-entry.
- ✓Permissions in the database. Role permissions are rows checked by the status functions; a platform-operator permission is separate from tenant admin.
- ✓Encrypted transport. All connections use TLS. Storage encryption at rest is provided by the managed database platform the service runs on.
- ✓Minimal PHI in integrations. The ordering API accepts a partner-supplied patient reference rather than requiring full demographics, and partner notifications carry order identifiers rather than clinical detail.
- ✓Outbound protections. Server-side fetches are guarded against SSRF; inbound webhooks are signature-verified; unsubscribe links are signed.
Pharmacy Flow is designed to support HIPAA's administrative, physical and technical safeguards for a covered entity's use — access control, audit, integrity and transmission security are described above. Whether a Business Associate Agreement is required for your deployment depends on your role and ours; raise it on the demo call and we will address it directly rather than in a footnote.
Partner API and public endpoints
The ordering API authenticates each request with a per-brand API key, is idempotent on a client order id (a retried request returns the existing order rather than creating a duplicate), and runs the same fail-closed licence gate as every other intake path before an order is accepted. Public endpoints — demo requests, directory enquiries, RFQs, claim-code sends — are rate-limited by a Postgres token bucket. Outbound partner notifications go through an outbox with retries so a partner's outage does not lose an event. The ordering API page has the request shape; the partners page covers the portal.
What we do not claim
We do not currently hold a SOC 2 report or HITRUST certification and do not say we do. We do not claim the platform is "Part 11 certified" — Part 11 compliance is a property of your validated system and procedures as a whole; we provide the mechanisms and the evidence to support your validation. We do not offer multi-factor authentication today; ask us about timing if it is a requirement. Electronic DSCSA transaction exchange with trading partners and carrier label purchasing are on the roadmap, not in the product. Where this page says "designed to support" it means exactly that. If you find a statement here the software does not bear out, tell us and we will correct the page.
Related: pricing, compare, all resources, cold-chain shipping, mail-order pharmacy, specialty pharmacy.
Frequently asked questions
Is Pharmacy Flow HIPAA compliant?+
It is designed to support HIPAA's safeguards: tenant isolation by row-level security, individual accounts, role permissions checked in the database, append-only audit tables, TLS transport, and a minimal-PHI integration design. HIPAA compliance is a property of a covered entity's programme, not a software certificate; we will walk your compliance team through each control and discuss a BAA for your deployment.
Does it support 21 CFR Part 11 electronic signatures?+
Yes, by mechanism: signatures record signer, role, time and a fixed meaning; are linked to the entity signed; require password re-authentication at the moment of signing; and are stored in a table application users cannot update or delete. We describe this as designed to support Part 11, since compliance is a property of your validated system.
How are controlled substances handled?+
A formulation's schedule is the most restrictive of its components. Schedule II refills are refused; Schedule III–V refills are limited to five within six months; unclassified controlled materials hold the refill. Controlled lots route to vault storage, and controlled orders into states whose licence record does not permit compounded controlled substances are held at eligibility.
Can an administrator edit or delete an audit record?+
Not through the application. Update and delete on events, approvals, audit log and comments are revoked from the application roles at the database level. Maintenance connections used for migrations are exempt by design and are not available to tenant users.
Is the platform SOC 2 or HITRUST certified?+
No, and we do not claim to be. If a third-party attestation is a purchasing requirement, tell us and we will discuss timing honestly.
Is there multi-factor authentication?+
Not today. Accounts are individual with password authentication, and signatures require password re-entry. Raise MFA on the demo call if it is a requirement so we can tell you the plan.
Where does the platform run and is data encrypted?+
On a managed Postgres platform with TLS on every connection and storage encryption at rest provided by that platform. Tenant data is separated by row-level security rather than by separate databases.