MediPact Docs← Back to App

Consent & Patient Rights

How MediPact collects, verifies, and proves patient consent for ethical, compliant data sharing on Hedera.

Consent as a First-Class Primitive

Consent is at the core of MediPact. Every patient whose data is contributed to the marketplace must have provided valid consent, and that consent must be verifiable on Hedera and linked to their anonymous patient ID (PID).

The system is designed so that hospitals can collect consent once (e.g., during patient registration or via SMS), and the MediPact adapter will automatically enforce consent checks during data collection and querying — without adding manual burden to hospital staff.

Identity, Contact & Payment

To ensure that consent and revenue share are correctly linked to each person, MediPact uses a combination of identifiers and contact channels:

  • Unique Patient Identifier (UPI): Deterministic ID derived from name + date of birth and optional phone/email. The same person gets the same UPI across hospitals, enabling cross-facility linkage without sharing raw PII.
  • Anonymous Patient ID (PID): A random identifier (e.g., PID-001, PID-002) generated during Stage 1 anonymization. This is the only identifier used on-chain and in research datasets — no original PII is ever stored on Hedera.
  • Unique Contact Channels: Patient phone numbers and emails are enforced as unique in the identity database. The same phone/email cannot be registered for two different patients. This guarantees a single contact (and payout) channel per person.
  • Default Payment Method: For bulk hospital uploads, the patient's phone number (if present) is used as the default payment destination via mobile money.

Consent Types

The system supports multiple consent types to reflect real-world clinical workflows:

  • Individual: The patient explicitly consents (e.g., via the patient portal, SMS link, or in-person digital form). This is the primary consent method.
  • Hospital Verified: The hospital confirms that it has collected valid consent from the patient (e.g., on paper or via existing processes). Used especially in early integrations and bulk onboarding.
  • Bulk: For historical data where hospitals have broad consent that covers a cohort of patients, and they attest to that via the backend API.

All consent records are stored without PII, using the anonymous patient ID (PID) and cryptographic hashes. The original consent artifacts (e.g., signed forms) remain in the hospital's secure systems and are never uploaded to the marketplace.

Where Consent is Stored

Consent is stored in two places to provide both operational flexibility and public verifiability:

  • Off-chain (Database): The backend stores consent records in the patient_consents table, including:
    • anonymous_patient_id (PID-xxx)
    • upi (patient identity link)
    • consent_type (individual / hospital_verified / bulk)
    • status (active / revoked / expired)
    • Optional: hcs_topic_id, consent_topic_id, data_hash, expires_at, hospital_id
  • On-chain (Hedera):
    • HCS Consent Topic: Stores a SHA-256 consent hash with timestamp and metadata. Publicly verifiable on https://hashscan.io.
    • ConsentManager Contract: Stores a ConsentRecord(anonymousPatientId, hcsTopicId, dataHash, timestamp, isValid) keyed by the anonymous patient ID. This provides an immutable, on-chain registry of which PIDs have active consent.

Primary Consent Flow (Today)

Today, the primary consent flow is designed around hospitals collecting consent and using the CSV adapter for bulk data uploads:

  1. Patient Registration: Hospital registers the patient with name, date of birth, and a unique phone number or email. A UPI and anonymous patient ID (PID) are generated.
  2. Consent Collection at Hospital: Patient signs a consent form (paper or digital) authorizing the use of their anonymized data for research. The hospital stores this consent record securely.
  3. CSV Data Export: Hospital exports EHR data (including PII, demographics, and clinical data) as a CSV file and uploads it via the MediPact “Upload Data” page.
  4. Adapter Processing:
    • Applies Stage 1 (storage) anonymization to remove PII and generate PIDs.
    • Aggregates per-patient records and computes a storage hash (H1) per PID.
    • Generates a consent hash per PID using only:{ anonymousPatientId, consentDate, consentType, timestamp }— no raw PII.
    • Submits the consent hash to the configured Hedera HCS consent topic, and optionally records a consent entry on the ConsentManager contract.
  5. Stage 2 Anonymization & Provenance:
    • Applies Stage 2 (chain) anonymization for maximum privacy.
    • Computes a chain hash (H2) per anonymized record.
    • Creates a provenance record per record with:{ storage: { hash: H1, anonymizationLevel: 'storage' }, chain: { hash: H2, anonymizationLevel: 'chain', derivedFrom: H1 }, anonymousPatientId, hospitalId, provenanceProof }
    • Submits the provenance record to the Hedera HCS data topic.

This flow ensures that for every patient included in a bulk upload, there is: (a) a consent record in the backend, (b) a matching consent proof on Hedera (by PID), and (c) a cryptographically linked storage & chain hash pair for each anonymized record.

Consent-First Mode (EMR Integrations)

For hospitals with direct EMR integrations, MediPact offers an optional consent-first mode in the index-universal.js adapter:

  • Enable by setting REQUIRE_ONCHAIN_CONSENT=true and configuring CONSENT_MANAGER_ADDRESS in adapter/.env.
  • Before storing any data or writing HCS proofs, the adapter calls the isConsentValid view function on the ConsentManager contract for each anonymousPatientId.
  • If consent is not active on-chain for a patient, the adapter skips that patient's data (no storage, no HCS messages).

This ensures that when using direct EMR connectors, no patient data is ever processed or uploaded unless there is a valid, verifiable consent on-chain for that patient's anonymous ID.

For CSV-based bulk uploads, the adapter currently acts as the consent creator by generating and recording consent proofs for each patient. The consent-first pre-check is not yet enabled on the CSV path, but the code is structured so it can be added later in a similar way to the EMR adapter.

Verification on HashScan

All consent and data proofs are written to Hedera Consensus Service (HCS) and can be independently verified on https://hashscan.io.

  • Consent Proofs: Stored on a dedicated HCS topic (configured via HCS_PATIENT_APPROVAL_TOPIC_ID). Each message contains a consent hash and timestamp, keyed by anonymous patient ID.
  • Provenance Records: Stored on a separate HCS data topic (configured via HCS_DATA_TOPIC_ID) with both Storage (H1) and Chain (H2) hashes and a provenanceProof that links them.
  • On-Chain Consent Registry: The ConsentManager contract stores a per-patientConsentRecord with the PID, consent HCS topic, data hash, and validity flag. This can be queried via the isConsentValid view function or inspected directly on-chain.

This triad (backend consent table, HCS consent proofs, and on-chain consent registry) provides a robust, auditable trail for regulators, researchers, and patients.

Configuration & Environment

The consent and proof flows are controlled via environment variables in adapter/.env:

  • HEDERA_NETWORK — Hedera network to use (testnet, previewnet, mainnet).
  • HCS_PATIENT_APPROVAL_TOPIC_ID — HCS topic for consent proofs.
  • HCS_DATA_TOPIC_ID — HCS topic for data & provenance proofs.
  • CONSENT_MANAGER_ADDRESS — Hedera EVM address of the ConsentManager contract. When set, the adapter will record on-chain consent records.
  • REQUIRE_ONCHAIN_CONSENT (optional) — When set to true, the universal EMR adapter will operate in strict consent-first mode and only process PIDs that already have valid consent on-chain.