How to Implement Selective Disclosure for Patient Health Records

Selective disclosure is a cryptographic principle that allows a data subject to prove a specific claim derived from a credential without exposing the credential itself. In healthcare, this means a patient can prove they are over 18, have a valid vaccination record, or possess a certain blood type by sharing a zero-knowledge proof (ZKP) instead of their full medical ID or health passport. This shifts control from centralized data custodians to the individual, aligning with regulations like GDPR's data minimization principle and enabling privacy-first health data ecosystems.

The technical foundation relies on verifiable credentials (VCs) and signature schemes that support selective disclosure. A healthcare issuer, like a hospital or lab, signs a credential containing multiple attributes (e.g., name, dateOfBirth, covidVaccineStatus). Using protocols like BBS+ signatures or CL signatures, the patient's wallet can generate a proof that reveals only the necessary attribute (e.g., vaccineStatus: "fully-vaccinated") while keeping all other data hidden and cryptographically verifying the issuer's signature. This proof is then presented to a verifier, such as an event venue or employer.

Implementing this requires a defined architecture. A typical flow involves: 1) Issuance: A trusted entity issues a W3C Verifiable Credential to the patient's digital wallet. 2) Presentation Request: A verifier sends a request specifying the required claims and the accepted issuers. 3) Proof Generation: The wallet uses a ZKP library (like @mattrglobal/bbs-signatures or anoncreds-rs) to create a verifiable presentation. 4) Verification: The verifier checks the proof's validity and the issuer's signature. Open-source frameworks like Hyperledger Aries provide toolkits for building these interactions.

For developers, here's a conceptual code snippet for generating a selective disclosure proof using a BBS+ signature scheme, where only the isOver18 field is revealed:

javascriptCopy
// Pseudocode using a BBS+ library
const derivedProof = await bbs.deriveProof({
  signature: signedCredentialProof,
  publicKey: issuerPublicKey,
  messages: credentialAttributes, // [name, dob, isOver18, ...]
  revealed: [2] // Index of the 'isOver18' attribute to disclose
});
// The `derivedProof` contains no other attribute values.

Key challenges include ensuring user experience is seamless for non-technical patients, managing revocation of credentials (e.g., using revocation registries), and establishing trust frameworks for issuers. Projects like the EU Digital Identity Wallet and IBM's Health Credentials are pioneering these patterns. The outcome is a system where data sharing is minimized, privacy is preserved by default, and trust is maintained through cryptography rather than data exposure.

Selective disclosure allows a patient to prove specific claims from a credential without revealing the entire document. For health records, this is powered by Verifiable Credentials (VCs) and Zero-Knowledge Proofs (ZKPs). The core standard is the W3C Verifiable Credentials Data Model. You will also need a Decentralized Identifier (DID) method for the issuer and holder, such as did:key or did:ethr. For the selective disclosure mechanism itself, BBS+ Signatures (draft-irtf-cfrg-bbs-signatures) are the leading standard, enabling predicate proofs (e.g., "age > 18") and selective attribute revelation.

Your development environment requires specific libraries. For JavaScript/TypeScript projects, install the @mattrglobal/node-bbs-signatures package for BBS+ operations and a VC SDK like @veramo/core. For a Python stack, use py-bbs and the vc-js toolkit. Ensure you have Node.js 18+ or Python 3.9+ installed. You will also need a way to create and resolve DIDs; for testing, use a universal resolver or a simple in-memory DID resolver from did-resolver and ethr-did-resolver.

Define your credential schema. A patient health record VC must have a clear structure. For example, a HealthRecordCredential type would include claims like fullName, dateOfBirth, bloodType, lastCheckupDate, and vaccinationStatus. These claims must be typed and defined in a JSON-LD context. The credential is then signed by the issuing hospital's DID using a BBS+ key pair, which creates a cryptographically verifiable signature that supports future zero-knowledge derivations.

The holder (patient) needs a secure wallet or agent to store this credential. Implement a basic holder agent using the Veramo CLI or framework to create a local DID, receive the signed VC, and store it in an encrypted database. The issuer (hospital) must run a similar agent with a secure key management system for signing. For development, you can use Veramo's KeyManager with a local private key, but production requires an HSM or cloud KMS.

Finally, set up a verifier service. This is a simple web server that will receive presentation requests. The verifier defines which claims it needs (e.g., "proof of vaccination") and optionally predicates (e.g., "lastCheckupDate after 2023-01-01"). The holder's agent uses the BBS+ library to create a Verifiable Presentation containing only the disclosed attributes and a ZK proof, which the verifier can validate against the issuer's public DID. Start by testing the full flow with dummy data before integrating with real EHR systems.

Selective disclosure is a cryptographic principle that allows a data holder to prove specific claims from a larger dataset without revealing the dataset itself. For patient health records, this means a user can prove they are over 18, have a specific vaccination, or meet lab result thresholds without exposing their full medical history, date of birth, or other sensitive details. This is achieved using zero-knowledge proofs (ZKPs) and verifiable credentials (VCs), which shift control from centralized databases to the individual patient. The core challenge is to enable trust and verification by third parties while preserving maximum privacy.

The implementation typically follows the W3C Verifiable Credentials data model. A patient's health data is issued as a signed credential from a trusted issuer, like a hospital. This credential contains all attested claims. To share selectively, the patient generates a verifiable presentation. Using ZKP protocols like BBS+ signatures or zk-SNARKs, the presentation can cryptographically prove statements about the credential (e.g., "credential signature is valid") and its contents (e.g., "labResult > 100") without disclosing the credential in full. The verifier only receives the proof and the disclosed data points, ensuring minimal information leakage.

A practical implementation involves several libraries and standards. For BBS+ signatures, consider the @mattrglobal/bbs-signatures library. First, the issuer creates a BBS+ key pair and signs a credential containing the patient's data. The patient then uses the deriveProof function to create a presentation that discloses only selected fields. For more complex predicates (e.g., ranges), Circom and SnarkJS can be used to create zk-SNARK circuits. The circuit logic would take the private health data as a private input and output a proof that a public statement is true. The proof is verified on-chain or off-chain without revealing the inputs.

Key design decisions include choosing between signature-based (BBS+) and circuit-based (zk-SNARK/STARK) approaches. BBS+ is efficient for selective disclosure of specific fields but less suited for complex computations. zk-SNARKs are more flexible for arbitrary logic but require circuit setup and are computationally heavier. Storage is another consideration: the full credential can be held off-chain (e.g., in the patient's wallet), with only the compact proof shared. Decentralized Identifiers (DIDs) are used to identify issuers and holders cryptographically, avoiding reliance on traditional databases.

For developers, start by defining the credential schema using JSON-LD contexts. Use a credential status registry (like a smart contract or a verifiable data registry) to allow issuers to revoke credentials if needed. The verification step must check the proof, the issuer's DID signature, and the credential's status. This architecture enables use cases like privacy-preserving health passes, clinical trial pre-screening, and insurance claim verification, where patients control what they share. Implementing selective disclosure moves healthcare systems from "all-or-nothing" data access to a granular, user-centric model of data sovereignty.

Selective disclosure transforms patient data sovereignty by enabling granular, consent-based sharing. The system we've described leverages W3C Verifiable Credentials as the data container and BBS+ signatures or zk-SNARKs for creating zero-knowledge proofs. This allows a patient to prove specific claims—like being over 18 or having a recent negative test—without revealing the underlying document or additional personal information. Implementing this shifts the paradigm from bulk data transfer to targeted, minimal disclosure, enhancing privacy and compliance with regulations like HIPAA and GDPR.

For developers, the next step is to integrate these components into a working stack. Start by defining your credential schema for health data using a tool like @digitalbazaar/jsonld-signatures. Issue credentials signed with a BBS+ key from a trusted issuer (e.g., a hospital's system). Then, implement a holder wallet (like Trinsic or Veramo) that can store these credentials and generate presentations. The critical piece is the proving logic, where libraries such as @mattrglobal/bbs-signatures or snarkjs are used to create predicates (e.g., "bloodType == 'O+'" AND "date > 2023-01-01") and generate a verifiable, redacted proof.

To move from prototype to production, focus on key infrastructure and security considerations. You will need a secure key management system for issuer and holder keys, a public verifiable data registry (like a blockchain or a decentralized identifier network) to resolve issuer DID documents, and a standardized API for verifiers to request and check presentations. Audit your zk-circuit logic and signature implementations thoroughly. Furthermore, plan for credential revocation using status lists or novel methods like accumulator-based revocation to maintain the system's integrity over time.

Explore advanced use cases to understand the full potential. Consider tiered disclosure, where proving a higher-level claim (age range) unlocks the ability to prove a more specific one (exact age). Implement predicate proofs for ranges and sets, crucial for medical thresholds. Research cross-border interoperability by aligning with international frameworks like the EHN's GDPR-compliant health data scheme. The ongoing development of standards by groups like the Decentralized Identity Foundation (DIF) and W3C Credentials Community Group is essential to follow for long-term compatibility.

The final step is engagement with the ecosystem. Contribute to open-source projects in the SSI and zk-proof space. Test your implementations against interoperability test suites. For clinical deployment, collaborate with legal and compliance teams to ensure your technical architecture maps correctly to regulatory concepts of data minimization and patient consent. By building on these principles, you can create systems that return control of health information to individuals while enabling secure, privacy-preserving digital health services.