Trust · real-data posture

Security, data handling & BAA readiness

Built for covered entities that need 340B clarity without turning analytics into a second EHR. This page is what pharmacy, IT, and legal can review before a pilot.

CSV path: patient-level data stays in the browser

Shares: aggregate only — no line items

FHIR path: server-side, redacted, BAA required

If someone uploads real hospital data

Use CSV upload. Scoring stays in the browser. Do not use FHIR pull for a real site unless you have a signed BAA, encrypted disks, and FHIR_DISABLED is not set. Recommended for this host: keep FHIR_DISABLED on so the server never sees a patient row.

Two data paths — choose deliberately

1. Upload CSV (recommended for pilots)

Dispense extracts are parsed and scored entirely in the browser. Patient-level rows are not uploaded to our servers for qualification. Configuration (entity, policy, price book) and aggregate report totals may be saved when you are signed in.

2. Pull from FHIR (optional)

Our server calls your FHIR R4 endpoint with a token you provide, processes dispenses in memory, then drops MRNs and pseudonymizes patient references before anything returns to the browser. Dispense rows are not written to disk as a durable patient store. Use only with a signed BAA and HIPAA-eligible hosting.

Shared reports & history

Read-only share links store aggregate figures only (savings, counts, trends, readiness). Line-item / patient arrays are stripped server-side before save. Suitable for finance and leadership without attachments.

What we store

Data	Where	Notes
Account (email, password hash, MFA secret)	Server	Hashed passwords (scrypt); MFA optional
Site setup (policy, price book, exclusions, MEF…)	Server per site	Business config — not a patient database
Aggregate report snapshots	Server per site	No dispense events / PHI line items
API audit log	Server (JSONL)	Who/what/when/outcome — never tokens or PHI
CSV dispenses (upload path)	Browser only	Not uploaded for scoring
FHIR bearer token	Request only	Not stored; not written to audit

Controls already in product

Authentication

Email/password sessions (httpOnly cookie) and/or org SSO. Super-users vs site users (tenant isolation).

Tenant isolation

Site users only see their covered entity’s configs and report history. Cross-tenant ?site= is ignored.

Audit trail

Append-only API audit log (business metadata). Super-users and site teams can download for review.

BAA & pilot readiness

CSV-only pilot: many covered entities can evaluate the product with browser-side dispenses and aggregate shares. Confirm with your counsel; we still recommend a written pilot agreement covering use of synthetic or de-identified extracts.

FHIR or any server-side PHI processing: execute a Business Associate Agreement (BAA) and deploy on HIPAA-eligible infrastructure (encryption in transit, access control, logging, workforce training). Turn off FHIR for pilots that must remain browser-only (FHIR_DISABLED).

Qualification rules are configurable heuristics stamped with a rule pack version on every report. They are not a substitute for your 340B program policy or legal advice. Confirm before billing or manufacturer defense.

Your responsibilities as a covered entity

Only authorized workforce access the tool; protect login credentials and MFA.
Do not paste real PHI into support tickets or public share channels.
Treat line-item CSV downloads from the app as operationally sensitive even when generated from your own extract.
Validate savings and eligibility against your 340B program before financial or manufacturer use.

Ready to evaluate?

Tour a fictional hospital in one click, or sign in for a pilot site.

Run the test demo Sign in