Executive summary
LogBook ingests, transmits, and stores de-identified machine telemetry — water volumes, ingredient lot numbers, NDCs, device identifiers, and timestamps — generated by Fillmaster reconstitution and flavoring devices. It does not ingest, transmit, or store any of the eighteen identifiers enumerated in the HIPAA Privacy Rule's Safe Harbor method.
Health information that has been de-identified in accordance with § 164.514(a)–(b) is no longer protected health information, and the Privacy Rule's restrictions on use and disclosure do not apply to it (45 CFR § 164.502(d)(2)). LogBook is engineered to remain within this de-identified state at all times.
The de-identification standard45 CFR § 164.514(a)–(b)
Section 164.514(a) establishes the core principle: health information is not individually identifiable — and therefore is not PHI — if it "does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual."
The regulation provides two routes to meet this standard:
Expert Determination — § 164.514(b)(1)
A person with appropriate statistical/scientific expertise determines that the risk of re-identification is very small and documents the analysis. LogBook's data model contains no individual identifiers, making such a determination straightforward.
Safe Harbor — § 164.514(b)(2)
Removal of all eighteen enumerated identifiers of the individual (and of relatives, employers, and household members), provided the covered entity has no actual knowledge that the residual information could identify the individual. LogBook is designed to the Safe Harbor list — it never collects any of the eighteen in the first place. The table below maps each.
Safe Harbor — the eighteen identifiers45 CFR § 164.514(b)(2)(i)(A)–(R)
Each identifier the rule requires to be removed, and how LogBook handles it:
| # | Safe Harbor identifier | LogBook handling | Collected? |
|---|---|---|---|
| 1 | Names | Patient names never received. Operators recorded as initials + role only. | No |
| 2 | Geographic subdivisions < a state | Store location is the pharmacy's own facility, not a patient address. | No |
| 3 | Dates related to an individual (DOB, admission, etc.) | Only device event timestamps are stored — machine activity, not patient dates. | No |
| 4 | Telephone numbers | Not collected. | No |
| 5 | Fax numbers | Not collected. | No |
| 6 | Email addresses | Patient email never received. Staff portal logins are workforce credentials, not patient data. | No |
| 7 | Social Security numbers | Not collected. | No |
| 8 | Medical record numbers | Not collected. Telemetry is keyed to a pharmacy-generated transaction code (see § 164.514(c)). | No |
| 9 | Health plan beneficiary numbers | Not collected. | No |
| 10 | Account numbers | Not collected. | No |
| 11 | Certificate / license numbers | Not collected. | No |
| 12 | Vehicle identifiers & license plates | Not applicable / not collected. | No |
| 13 | Device identifiers & serial numbers | The serial recorded is the dispenser's, not a device implanted in or assigned to a patient. | No* |
| 14 | URLs | Not collected. | No |
| 15 | IP addresses | Not stored as part of the telemetry record. | No |
| 16 | Biometric identifiers | No fingerprints, voiceprints, or other biometrics are captured. | No |
| 17 | Full-face photographs & comparable images | No images of individuals are captured. | No |
| 18 | Any other unique identifying number, characteristic, or code | The transaction code is expressly permitted under the § 164.514(c) exception (see below). | No |
* Identifier #13 targets device IDs associated with the individual (e.g., implants, assigned equipment). The Fillmaster serial number identifies the pharmacy's equipment, not a patient, and is the kind of operational metadata that supports — rather than undermines — de-identification.
Re-identification codes45 CFR § 164.514(c)
The transaction number is the single most scrutinized element, so it warrants the rule's exact language. Section 164.514(c) provides that a covered entity may assign a code or other means of record identification to allow de-identified information to be re-identified, provided that:
- (c)(1) — the code "is not derived from or related to information about the individual and is not otherwise capable of being translated so as to identify the individual"; and
- (c)(2) — the covered entity "does not use or disclose the code or other means of record identification for any other purpose, and does not disclose the mechanism for re-identification."
How LogBook satisfies each prong
- Not derived from the individual. The transaction number is generated natively by your pharmacy management system as an internal workflow identifier. It is not computed from a name, DOB, SSN, MRN, or any patient attribute. We do not hash, derive, or transform an Rx number — we simply carry the pharmacy's opaque code.
- Mechanism never disclosed to us. The mapping that links the transaction code back to a patient record resides exclusively within your pharmacy systems. It is never shared with FLAVORx and never uploaded to the LogBook cloud. We hold no key, and we have no means of translation.
Authoritative text: eCFR — Title 45 · Subtitle A · Subchapter C · Part 164 · Subpart E · § 164.514.
Business Associate status45 CFR § 160.103
A Business Associate is a person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Because LogBook handles only de-identified telemetry and never receives PHI, FLAVORx does not meet the definition of a Business Associate, and a Business Associate Agreement is not legally required.
Other relevant regulations & standards
HITECH Act & the HIPAA Security Rule — 45 CFR Part 164, Subpart C
Although the stored data is non-PHI, LogBook applies the technical safeguards expected of health-IT systems, mirroring § 164.312: access control (RBAC), audit controls (a continuous trail of who accessed what), integrity controls (append-only, tamper-evident records), and transmission security (HTTPS/TLS encryption in transit, encryption at rest).
FDA 21 CFR Part 11 — Electronic Records & Signatures
For organizations that align electronic record-keeping to Part 11 principles, LogBook supports the spirit of those controls: attributable actions (badge/operator capture), time-stamped events, and protected, reviewable records. The badge step provides the operator attribution that underpins electronic-record trustworthiness.
State Boards of Pharmacy — compounding & record retention
Reconstitution and flavoring documentation requirements vary by state. LogBook produces durable, attributable, time-stamped records of each operation — drug, lot, expiry, BUD, storage, volumes, and flavoring ingredients — and supports configurable retention to meet your state's record-retention period.
Consumer privacy laws (CCPA / CPRA)
De-identified and aggregate information is excluded from the definition of personal information under the CCPA/CPRA. LogBook telemetry therefore falls outside the scope of these consumer-privacy statutes.
Disclaimer. This page is provided for informational purposes to describe the design and regulatory posture of the FLAVORx LogBook platform. It is not legal advice and does not create an attorney–client relationship. Regulatory obligations depend on your specific facts, jurisdiction, and organizational policies; consult your own privacy officer and legal counsel before relying on any statement here. Regulatory citations reflect 45 CFR Part 164 as published on the eCFR and are subject to amendment. This environment is a demonstration; all data shown elsewhere in the portal is simulated.