SaludID — HIPAA Technical Safeguard Architecture · Session 3 · April 2026
Internal — Privileged & Confidential
Technical safeguard specification establishing that Salud Capital is a credential presenter, not a HIPAA covered entity or business associate. No PHI transits Salud infrastructure. Credentials are AES-256 encrypted on-chip and presented directly via NFC — never stored, processed, or transmitted by Salud servers.
01 Regulatory Position Statement
The architecture argument in summary form — for counsel review and refinement
A "business associate" is a person who, on behalf of a covered entity, creates, receives, maintains, or transmits PHI. Salud Capital does none of these. The Tangem chip — hardware manufactured and certified independently — is the container. Salud is the distributor of the container, not the processor of its contents. The credential issuer (Aetna, Medicare/CMS, etc.) writes encrypted data to the chip directly or via a provisioning partner. Salud's servers never participate in that chain.
Credential data (Medicare Beneficiary Identifier, Medicaid ID, Aetna member number) is stored exclusively on the Tangem chip's AES-256 encrypted secure element partition. It is not stored on Salud servers, not transmitted via Salud APIs, not processed by Salud software. Salud's cloud infrastructure has zero bytes of PHI at rest or in transit — ever.
The SaludID token on Polygon PoS stores only a keccak256 hash of the Medicare ID. A keccak256 hash of an identifier is a one-way cryptographic function — it cannot be reversed to recover the original ID. Under HHS guidance and prevailing analysis, cryptographic hashes of PHI that do not permit re-identification of individuals are not themselves PHI. The blockchain layer is an authentication anchor, not a PHI store.
When a Salud Vault cardholder presents credentials at a CVS MinuteClinic reader, the NFC transaction occurs directly between the Tangem chip and the MinuteClinic point-of-care terminal. Salud Capital is not in that transaction path — no Salud servers are called, no Salud APIs mediate the session, no Salud logs contain the credential data. The architecture is point-to-point hardware-to-reader.
02 Architecture Overview
Where PHI exists, where it doesn't, and why Salud is structurally outside the PHI envelope
Credential Provisioning: CMS, Aetna, or state Medicaid agency writes encrypted credential data to the Tangem chip's secure element. This write may occur at activation (over secure NFC) or via a provisioning kiosk. Salud servers are not in this path.
Point-of-Care Presentation: Cardholder taps Tangem card to MinuteClinic NFC reader. Chip decrypts and presents credential data directly to the reader. MinuteClinic's EHR/EPIC system receives the credential. Salud has no log or record of this transaction.
Medicare Beneficiary Identifier (MBI): Stored encrypted on chip. Never written to any Salud database, API, or log file. The raw MBI is not in Salud's possession at any time.
Aetna Member Number: Same treatment — chip-only, AES-256 encrypted, never transmitted to Salud.
Medicaid ID: Same treatment. Salud's operational logs contain device serial numbers and activation timestamps — zero health identifiers.
03 Encryption Specification
Chip-level security architecture — the physical vault for health credentials
| Control | Specification | Standard | HIPAA Relevance |
|---|---|---|---|
| Encryption at Rest | AES-256-GCM with hardware-generated key stored in EAL6+ secure element. Key never exported. | NIST SP 800-111 | Satisfies § 164.312(a)(2)(iv) — Encryption and decryption |
| Secure Element | Samsung S3B2AA — Common Criteria EAL6+ (same certification as US biometric passport chip). Physical tamper protection with attack countermeasures. | CC EAL6+ | Satisfies § 164.312(c)(1) — Integrity controls |
| NFC Channel Security | ISO 14443-A with Secure Messaging (SM). AES-128 session key negotiated per-tap via ECDH. Data encrypted in transit over NFC channel. | ISO 14443 / GP SCP11 | Satisfies § 164.312(e)(2)(ii) — Encryption in transit |
| Key Generation | TRNG (True Random Number Generator) on-chip. Secp256k1 for blockchain ops; AES-256 for credential partition. Keys generated at chip initialization — never exposed post-generation. | FIPS 140-2 aligned | Supports § 164.312(d) — Authentication of person/entity |
| Physical Tamper Protection | Active shield mesh with glitch detection. UV/probe attack countermeasures. Side-channel attack hardening (DPA/SPA resistant). Self-destruct on penetration attempt. | CC EAL6+ AVA_VAN.5 | Supports § 164.310(c) — Workstation security |
| Access Control | PIN/biometric authentication (app-level, NFC proximity required). Three failed attempts → chip lock. NFC range limit ~4cm prevents remote eavesdropping. | FIDO2 / ISO 7816 | Satisfies § 164.312(a)(1) — Access control |
| Credential Partition Isolation | Separate AES-256 encrypted data partition for health credentials, isolated from financial key partition. Cross-partition access architecturally blocked at SE firmware level. | Tangem OS v4.x | Supports § 164.308(a)(3) — Workforce access management |
| Audit / Logging | Chip maintains internal transaction counter (read-only, tamper-evident). No PHI in logs. Salud app logs: device ID, activation timestamp, NFC tap count — zero health data. | Custom | Supports § 164.312(b) — Audit controls (at chip layer) |
A physical insurance card contains the member's ID number printed on its face. The card manufacturer (e.g., Zebra Technologies, Entrust) is not a HIPAA business associate — they produce the carrier, not the healthcare service. Salud Vault is this same model, with cryptographic authentication replacing printed numbers. The Tangem chip is the insurance card. Salud Capital is the card manufacturer and distributor. The fact that the chip stores credentials digitally rather than printing them visually does not transform Salud into a healthcare data processor.
04 Blockchain Layer
The on-chain token stores only a cryptographic commitment — not the underlying identifier
Under 45 CFR § 164.514(b), health information is considered de-identified — and thus not PHI — if either the Expert Determination or Safe Harbor method is applied. The keccak256 hash of a Medicare Beneficiary Identifier with a unique per-user salt satisfies both analyses:
| Factor | Physical Insurance Card | SaludID Blockchain Token | Assessment |
|---|---|---|---|
| Raw MBI Exposure | Printed on card face — visible | Not on blockchain — chip only | Lower Risk |
| On-Chain Identifier | N/A | keccak256(MBI + salt) — one-way function | Not PHI |
| Re-identification Risk | Card loss = MBI exposed | Hash is computationally irreversible without salt; salt stored on chip only | Negligible |
| Ethereum Address → Identity | N/A | Address is pseudonymous. Not linked to real-world identity in Salud's records. | Pseudonymous |
| HHS Safe Harbor | N/A | No enumerated identifiers (§ 164.514(b)(2)) present on-chain | Passes |
For the keccak256 hash to be cryptographically non-reversible, it must incorporate a unique per-user salt that is stored exclusively on the chip's secure element. credentialHash = keccak256(abi.encodePacked(MBI, userSalt)) — where userSalt is a 256-bit random value generated at chip initialization. Without the salt, a rainbow table attack against the finite MBI space is theoretically feasible. With a chip-resident salt, the attack surface collapses. This is a hard implementation requirement, not optional.
05 HIPAA Definitions Analysis
45 CFR § 160.103 — Statutory definitions mapped to Salud Capital's actual operations
A covered entity is a health plan, a healthcare clearinghouse, or a healthcare provider that transmits health information in electronic form. Salud Capital is none of these. It is a fintech / retail distribution company that manufactures and sells hardware devices. It does not provide healthcare services, adjudicate insurance claims, or transmit PHI in the provision of healthcare.
A business associate is a person who, on behalf of a covered entity, performs functions or activities that involve the use or disclosure of PHI. The statutory test has two prongs: (1) the function must be performed on behalf of a covered entity, and (2) it must involve the use or disclosure of PHI. Salud fails both prongs:
| BA Test Prong | Statutory Language (45 CFR § 160.103) | Salud Capital Analysis | Finding |
|---|---|---|---|
| On Behalf Of | Performs functions for or on behalf of a covered entity | Salud manufactures hardware and distributes retail SKUs. It does not perform functions for Aetna, CMS, or MinuteClinic. The provisioning of credentials is performed by the issuer, not Salud. | Fails Prong 1 |
| PHI Use/Disclosure | Creates, receives, maintains, or transmits PHI | Salud servers never create, receive, maintain, or transmit any PHI. Credential data is chip-resident. Salud has no technical capability to access the encrypted credential partition. | Fails Prong 2 |
| Subcontractor BA | Person who creates, receives, maintains, or transmits PHI on behalf of another BA | Same analysis. Salud is not in the PHI data chain at all. It cannot be a subcontractor BA if it never touches PHI. | Not Applicable |
Companies like Entrust or HID Global print physical insurance ID cards that display member numbers. They are not HIPAA business associates. HHS guidance has consistently held that companies providing products or services that facilitate PHI transactions, but do not themselves create, receive, maintain, or transmit PHI, are not BAs.
Salud distributes hardware chips where the credential issuer (not Salud) writes encrypted PHI to the chip. The chip presents credentials to covered entity readers. This is structurally identical to the card printer — Salud never possesses the PHI, it only provides the physical medium. The encryption makes this argument stronger, not weaker.
The BA determination would shift if Salud ever: (a) maintained a credential provisioning server that stored or transmitted PHI during the write process; (b) logged or cached any decrypted credential data for debugging or analytics; (c) operated as an intermediary in the chip-to-reader NFC session; or (d) provided managed services to covered entities that required access to PHI. The architecture must be maintained with zero-PHI discipline at the infrastructure level for this position to hold.
06 Credential Presenter Doctrine
A novel but well-grounded regulatory position — proposed for development with healthcare counsel
The 21st Century Cures Act (2016) and ONC Information Blocking Rule create safe harbors for healthcare technology that facilitates access to health information without itself acting as a data controller. Salud's hardware-only credential presentation model aligns with this framework — the chip is the patient-controlled access device, not a Salud-controlled data asset.
HIPAA's minimum necessary standard (§ 164.502(b)) requires limiting PHI disclosure to the minimum necessary for the intended purpose. The chip architecture satisfies this at a structural level: only the specific credential required for a given interaction is presented, the presentation is authorized by the physical card holder through proximity (NFC), and no data is retained post-presentation by Salud.
Under GDPR, a hardware manufacturer that enables data processing but does not itself determine the purpose or means of processing is not a data controller — the individual (data subject) controls the device. This framework, while from EU law, supports the analytical position that Salud is not a HIPAA BA when it provides only the physical medium and the individual controls the credential.
FIDO2 authentication hardware (YubiKey, Apple Secure Enclave, Google Titan) stores authentication credentials on-chip and presents them to relying parties without exposing the underlying secret to the manufacturer or any intermediary. Hardware manufacturers in this stack — despite enabling authenticated access to sensitive health portals — have not been classified as HIPAA BAs because they do not create, receive, maintain, or transmit PHI.
07 Breach Risk Analysis
Where breach risk lives, and why it's structurally smaller than the incumbent (physical card)
| Breach Vector | Physical Insurance Card | SaludID / Tangem | Δ Risk |
|---|---|---|---|
| Server Database Breach | Insurer DB breach → millions of MBIs exposed (e.g., Change Healthcare 2024) | No PHI on Salud servers. Zero exposure. | Eliminated |
| Card Lost / Stolen | MBI visible on card face — identity theft risk | AES-256 encrypted. PIN/biometric lock. Remote revoke via SaludID contract. | Dramatically Lower |
| NFC Eavesdropping | Passive RFID cards can be skimmed at close range | ISO 14443 SM — encrypted session per-tap. AES-128 ECDH session key. 4cm range limit. | Mitigated |
| Chip Physical Attack | N/A | EAL6+ — active shield mesh, glitch detection. No known successful attack on CC EAL6+ chips without nation-state resources. | Residual / Minimal |
| Salud App Compromise | N/A | App manages NFC communication — no PHI passes through app layer. Signing occurs inside chip. App compromise cannot extract credentials. | Non-Material |
| Blockchain Data Exposure | N/A | keccak256 hash + salt. Cannot reverse-engineer MBI without chip-resident salt. Public blockchain reveals no PHI. | Non-Material |
| Insider Threat (Salud) | N/A (insurer manages) | No Salud insider can access credentials — they are never in Salud systems. Zero insider exposure path. | Eliminated |
Medical identity theft costs the US healthcare system an estimated $30 billion annually. The majority of these breaches occur at centralized database targets — insurer claims systems, hospital EHRs, and clearinghouses (as in the Change Healthcare attack affecting 190 million records in 2024). Salud's architecture structurally eliminates the centralized database attack surface by ensuring no PHI is ever aggregated on its servers. The chip-only model is more secure than any existing insurance card format by a wide margin.
08 Risk Register
Items requiring counsel review, architectural discipline, and partner agreement management
| Risk | Description | Mitigation | Owner | Level |
|---|---|---|---|---|
| Provisioning Path PHI | If credential provisioning is ever routed through Salud servers (even transiently), the BA analysis reverses immediately. | Architectural requirement: all credential writes must occur chip-to-issuer directly (NFC) or via certified HSM provisioning partner. Salud servers must never be in this path. Quarterly architecture audit. | CTO / Architecture | HIGH |
| Salt Implementation | If keccak256 hash is computed without a unique, chip-resident salt, rainbow table attacks against the finite MBI space could reverse the hash — converting it to PHI. | Hard implementation requirement: per-user salt (256-bit TRNG, chip-generated) must be incorporated before hashing. Third-party audit of hash construction prior to mainnet deployment. | Engineering | HIGH |
| HHS Enforcement Novel Risk | No HHS OCR guidance specifically addresses NFC chip-based credential presentation. A future enforcement action could take a broader interpretation of "maintains" PHI. | Obtain written healthcare counsel opinion memorializing the BA analysis. Engage HHS proactively via voluntary inquiry before Q4 2026 health credential launch. Build BA-compliant architecture as fallback. | Legal / Strategy | MEDIUM |
| CVS / Aetna Data Agreement | CVS Health or Aetna may require a BAA as a condition of the MinuteClinic integration, regardless of Salud's legal position. | Negotiate as "hardware partner" not data processor. If BAA is required by CVS, execute as a zero-PHI-scope BAA (acknowledging the architecture but providing contractual protection for CVS). Engage in Q3 2026 partnership discussions. | Business Development | MEDIUM |
| State HIPAA Equivalents | California (CMIA), New York, Texas, and other states have health data privacy laws that may apply different standards. A credential-presenter position may not be recognized in all states. | State law survey by healthcare counsel prior to rollout. Initial pilot in states with federal HIPAA primacy. Map state-by-state exposure before national 9,000-location rollout (Q1 2027). | Legal | MEDIUM |
| Audit Log Discipline | Salud operational logs could inadvertently capture PHI-adjacent data (device serial number linked to a beneficiary record in a third-party database). | Log schema review — ensure logs contain only device IDs, timestamps, event codes. No name, DOB, or health-system identifiers. Annual log audit. Data minimization policy documented. | Engineering / Legal | LOW |
| Tangem Firmware Updates | A Tangem firmware update could alter the credential partition architecture in a way that changes Salud's access model. | Contractual requirement in Tangem partnership: architecture change notification. Salud must approve any firmware update affecting the credential partition or NFC session security model. | Partnerships / CTO | LOW |
Commission a formal written opinion from counsel experienced in HIPAA and HHS OCR enforcement on the BA analysis. The opinion should address: (a) credential presenter classification, (b) keccak256 hash PHI determination, and (c) state law mapping. This opinion is privileged work product and should be obtained before any CVS MinuteClinic integration discussions.
Document and ratify a zero-PHI architecture policy. Any future feature that would route health credential data through Salud servers requires a full HIPAA analysis and board/counsel sign-off before implementation. This policy is the prophylactic control against inadvertent BA classification.
Commission a third-party audit of the SaludID token contract specifically validating: (a) that no PHI appears in contract events or storage, (b) that the keccak256 salting implementation is correct, and (c) that no re-identification path exists via on-chain data correlation. Firms: Trail of Bits, OpenZeppelin, or Certik.
Prepare a negotiating position paper for CVS Health partnership discussions. Lead with the hardware partner / credential presenter framing. If CVS requires a BAA, have a zero-PHI-scope BAA template prepared that can be executed without reversing the Salud infrastructure model.
This specification establishes Salud Capital's HIPAA regulatory position through architecture — not just legal argument. The no-PHI-on-servers design is not a legal workaround; it is the correct technical architecture for a hardware credential product. The legal conclusion (not a covered entity or BA) flows naturally from the architecture. Maintaining this position requires permanent discipline at the infrastructure level: zero PHI transiting Salud systems, ever. The architecture is the moat, the compliance argument, and the security advantage — simultaneously.