The questions your compliance officer will ask — answered.
FLAVORx LogBook was architected to give you airtight traceability for every reconstitution and flavoring event without bringing protected health information into scope. Below are the concerns we hear most from pharmacy directors, hospital compliance managers, and IT security teams.
⚖️ HIPAA & PHI
The data LogBook stores is de-identified machine telemetry, not protected health information (PHI). Because we never receive, create, or maintain PHI on your behalf, we do not meet the definition of a Business Associate under 45 CFR § 160.103.
That said, many customers prefer to execute a BAA as a belt-and-suspenders measure, and we are happy to sign one. It does not change how the system operates — it simply documents the relationship.
No. Under HIPAA's re-identification provision, 45 CFR § 164.514(c), a code or other means of record identification is not considered PHI as long as:
- the code is not derived from or related to information about the individual, and
- the entity that holds the key does not disclose the mechanism for re-identification.
The transaction number is generated natively by your pharmacy system as an internal tracking code. The mapping from that code back to a patient lives entirely inside your pharmacy and is never uploaded to us. To LogBook, TX-4471-0098 is an opaque string with no patient meaning.
None of them. Our data model was deliberately designed against the Safe Harbor list in § 164.514(b)(2). We capture no names, no addresses, no dates of birth, no SSNs, no medical record or account numbers, no contact information, no biometrics, and no images.
What we do capture is machine-level: water volumes, ingredient lot/UPC/expiry, NDC of the drug stock bottle, device serial, firmware version, timestamps, and operator initials (not full names).
See the full identifier-by-identifier table on the HIPAA & Legal page.
The Safe Harbor identifiers concern the individual who is the subject of the health information (the patient) and their relatives, employers, and household members — not the workforce member operating a device. Logging the technician who performed an operation is standard, expected practice for compounding and dispensing records.
Even so, we minimize: we store initials and role (e.g., E.E. · CPhT), not full legal names or employee SSNs. Identity resolution is handled by your own staff directory.
Because the telemetry is de-identified and contains no consumer personal information, it falls outside the scope of consumer-privacy statutes like the CCPA/CPRA, which exclude de-identified and aggregate data.
For state Board of Pharmacy record-keeping, LogBook is an asset: it produces a durable, time-stamped, attributable log of reconstitution/flavoring activity that supports compounding documentation requirements. We can configure retention to match your state's record-retention period.
🔒 Security & Access
LogBook runs on Microsoft Azure infrastructure. Data is encrypted in transit (HTTPS/TLS) and at rest. We apply enterprise health-IT rigor even though the data is non-PHI: hardened cloud configuration, network isolation, and continuous monitoring.
Access is governed by role-based access control (RBAC) with multi-factor authentication (MFA) required for staff accounts. Users only see the stores and data their role permits.
(In this demo environment, sign-in is simulated and accepts any credentials — production enforces MFA and SSO.)
The dispenser uses outbound-only encrypted connections to push logs to the cloud. It does not accept inbound connections, which closes off edge-level network intrusion vectors. There is no listening service for an attacker to reach on your pharmacy LAN.
Yes. A continuous audit trail logs exactly who accessed which telemetry and when. Administrative actions in the portal are themselves recorded, so access to the records is as accountable as the records.
🧾 Audit & Traceability
Seconds. Search by your transaction number to jump straight to the full compliance record — operator, drug, NDC, lot, expiry, BUD, storage, water/dispensed volume, and every flavoring ingredient with its own lot and expiry. The record is printable for inclusion in a survey packet.
Try it: open the LogBook portal and look up a sample transaction.
Yes — this is one of LogBook's strongest use cases. Because every fill records the lot number of the drug and each flavoring ingredient, you can filter by a recalled lot and immediately see every affected transaction across every store, with the operator and timestamp attached.
Records are written from the device and treated as append-only telemetry. The portal is a read/review surface — it is not a place to edit dispensing facts. Combined with the access audit trail, this gives you a tamper-evident chain from device to review.
Each operation is stamped at the device and again on cloud ingestion.
⚙️ Operations
Roughly six seconds — one badge tap and one barcode scan. Both use hardware the device already has. After that, the workflow is identical to today.
Walk the flow on the How It Works page.
Dispensing is not held hostage by the network. The device captures the record locally and pushes it to the cloud when connectivity returns, using the same encrypted outbound channel. No records are lost to a transient outage.
Both steps are positioned as gates at the start of the workflow, before any drug scan — so a fill cannot proceed without them. This is by design: the whole value of LogBook depends on every record being attributable and linkable.
🏛️ Deployment & Data Ownership
You do — 100%. The pharmacy maintains complete ownership and control of the mapping key that links our tracking code back to a patient record. That key is never shared with us and never uploaded to our cloud. Our database remains structurally blind to patient identity.
Retention is configurable to your organization's policy and state record-retention requirements. Records are exportable/printable for surveys, internal QA, and archival.