We built PepKey from the ground up so that identifiable patient health information never reaches our servers. This page explains exactly how we achieve that — and what it means for you.
PepKey does not provide healthcare services, process insurance claims, or operate as a health plan.
We do not create, receive, maintain, or transmit PHI on behalf of covered entities. Our architecture prevents it.
Our system is designed so patient-identifying data stays on clinic devices and patient phones — never on PepKey servers.
HIPAA establishes privacy and security standards for the handling of Protected Health Information (PHI). It applies to three types of entities:
PepKey fits none of these categories. We are a transparency and information platform in the peptide therapy market. Our current live platform does not provide clinical care, process healthcare transactions, or handle PHI. PepKey Clinic™ — currently in development — is designed with this same principle: PHI will never reach PepKey servers by architectural design.
Important: Even though HIPAA does not technically apply to PepKey as a company, we have voluntarily designed our systems to exceed HIPAA standards for patient data protection. Our anonymous patient architecture goes beyond what law requires.
Understanding PepKey's data architecture requires understanding which data lives where. The fundamental principle: patient identity never leaves the clinic's control.
Patient name
Date of birth
PKP ID ← mapping
Medical history
Random token
No identifying info
Shared with patient
PKP ID only
Medication list
Questionnaires
Dose logs
PKP ID + PIN
Medication view
Dose log entry
A PKP ID (PepKey Patient Identifier) is a cryptographically random token generated when a clinic creates a patient record. It looks like: pkp_a7f3b2c1d9e4f8. It has no mathematical relationship to the patient's name, date of birth, or any other attribute.
"Jane Smith" → pkp_a7f3b2...pkp_a7f3b2... → [medication list]If a PepKey employee or attacker viewed the database, they would see anonymous medication records — completely unconnected to any real person.
Patient-facing API endpoints strip and discard the client IP address at the load balancer level. This means:
HIPAA provides two methods for de-identifying health information such that it is no longer considered PHI and is not subject to HIPAA's restrictions:
PepKey's patient data model satisfies the Safe Harbor method without requiring expert certification — because we architecturally prevent collection of any of the 18 identifiers from the beginning.
The following table lists all 18 identifier categories from 45 CFR § 164.514(b)(2) and PepKey's status for each:
| # | Identifier Category | PepKey Status | Notes |
|---|---|---|---|
| 1 | Names | ✓ Not Stored | Patient names stored on clinic device only |
| 2 | Geographic subdivisions smaller than state | ✓ Not Stored | No patient addresses or ZIP codes |
| 3 | Dates (except year) | ✓ Not Stored | No DOBs, admission/discharge dates, or death dates linked to patients |
| 4 | Phone numbers | ✓ Not Stored | No patient phone numbers collected |
| 5 | Fax numbers | ✓ Not Stored | Not applicable to patient records |
| 6 | Email addresses | ✓ Not Stored | No patient email addresses collected |
| 7 | Social Security Numbers | ✓ Not Stored | Never collected from patients |
| 8 | Medical record numbers | ✓ Not Stored | PKP IDs are not medical record numbers — no linkage |
| 9 | Health plan beneficiary numbers | ✓ Not Stored | No insurance data collected |
| 10 | Account numbers | ✓ Not Stored | No patient financial account data collected |
| 11 | Certificate/license numbers | ✓ Not Stored | Not collected for patients |
| 12 | Vehicle identifiers and serial numbers | ✓ Not Stored | Not collected |
| 13 | Device identifiers and serial numbers | ✓ Not Stored | Not collected. Patient phone device IDs are not stored. |
| 14 | Web URLs | ✓ Not Stored | No patient-associated URLs collected |
| 15 | IP addresses | ✓ Not Stored | Stripped at load balancer for patient endpoints |
| 16 | Biometric identifiers | ✓ Not Stored | No fingerprints, voice prints, or other biometrics collected |
| 17 | Full-face photographs | ✓ Not Stored | No patient photos collected |
| 18 | Any other unique identifying number or code | ✓ Not Stored | PKP IDs are random — they have no identifying relationship to patients |
Safe Harbor satisfied: PepKey's patient data model removes all 18 HIPAA Safe Harbor identifiers. The data we store (anonymous PKP IDs + medication records) is legally de-identified and does not constitute PHI under 45 CFR § 164.514(b)(2). Expert determination is not required because Safe Harbor is fully satisfied.
For encrypted clinic backup data, PepKey invokes the HIPAA breach notification encryption safe harbor under 45 CFR § 164.402.
Under 45 CFR § 164.402, a "breach" requiring notification under HIPAA does not include the unauthorized acquisition, access, use, or disclosure of PHI that is encrypted in a manner that renders it unusable, unreadable, or indecipherable to unauthorized individuals, where the decryption key has not also been compromised.
What this means in practice: Even if PepKey's servers were breached and backup data was exfiltrated, the attacker would receive only AES-256-GCM encrypted blobs. Without the clinic's master password (which PepKey never has), the data is computationally unbreakable with current technology. The encryption safe harbor would apply — no HIPAA breach notification would be required.
The backup cannot be recovered by PepKey, the clinic, or anyone else. This is intentional — the unrecoverability of the data is what guarantees the security of the system. We strongly recommend clinics:
While PepKey's architecture provides strong baseline protections, providers using PepKey Clinic tools should follow these best practices to maintain full HIPAA compliance:
Use a unique, randomly generated password of at least 20 characters for your PepKey Clinic master password. Store it in a clinical-grade password manager. Never reuse passwords across systems.
Keep clinic devices updated with the latest OS patches. Enable full-disk encryption (FileVault on Mac, BitLocker on Windows). Enable automatic screen lock after 5 minutes of inactivity.
Do not enter patient names or identifying information in any fields that sync to PepKey cloud. Patient names belong only in the local clinic database. The PKP system is designed for this — use it as designed.
If you suspect your PepKey account, clinic device, or master password may have been compromised, contact [email protected] immediately. We will assist with incident response.
Periodically verify that you can restore from your encrypted backup by testing the decryption with your master password in a test environment. Do not wait for a disaster to discover your backup is unrecoverable.
As a covered entity, you are responsible for your own HIPAA compliance. PepKey's architecture supports compliance but does not replace your obligation to implement appropriate administrative, physical, and technical safeguards within your practice.
We take security seriously and work to prevent breaches. But it's important to be transparent about the worst-case scenario so providers and patients understand the actual risk:
Hypothetical breach scenario: An attacker gains full access to PepKey's production database and backup storage.
For anonymous patient records (PKP ID + medications): Because these records are de-identified per HIPAA Safe Harbor, they do not constitute PHI. There is no HIPAA breach for de-identified data.
For encrypted clinic backups: The encryption safe harbor under 45 CFR § 164.402 applies. As long as the clinic's master password was not also compromised, the encrypted backup breach does not require HIPAA notification.
Bottom line: A PepKey server breach, while serious, would not expose patient identities or create a HIPAA breach notification obligation for encrypted data or de-identified records. We will still notify affected providers about any security incident affecting their account data.
The following regulations and guidance documents are referenced in this disclosure:
The HIPAA Privacy Rule's de-identification standards, including the Safe Harbor method (§ 164.514(b)(2)) listing the 18 identifiers that must be removed.
Defines "breach" under the HIPAA Breach Notification Rule and provides the encryption safe harbor for encrypted data where the decryption key was not also compromised.
The Department of Health & Human Services' official guidance on the two methods of HIPAA-compliant de-identification, including examples of Safe Harbor application.
HHS guidance on when mobile health apps are subject to HIPAA, including when app developers are and are not business associates.
The Federal Trade Commission's interactive tool for determining which federal health privacy laws apply to mobile health applications.
The NIST specification for the AES-GCM encryption mode used in PepKey's clinic backup encryption.
If you have HIPAA compliance questions about PepKey's architecture, your obligations as a covered entity using PepKey Clinic tools, or any security concerns, contact us:
PepKey, Inc. — Newport Beach, California
[email protected]See also: Privacy Policy • Terms of Service • Disclosure