Medical Contract Signing on Blockchain: How CareChain Records Treatment Consent

The Problem: Treatment Consent Without a Shared Source of Truth

// Doctors and patients need to agree on the same terms and verify what was approved later

A treatment agreement can pass through forms, messages, and separate systems. When the terms change or a dispute appears later, it may be difficult to prove which treatment was proposed, which patient received it, and whether the agreement was approved.

CareChain turns that process into a structured medical contract. The agreement connects a doctor, a patient, a treatment type, and a description to a visible approval state that can be retrieved and verified after the original interaction.

▪One contract represents one defined treatment agreement.
▪Both parties work with the same terms and status.
▪Creation and approval remain traceable over time.

The Signing Flow: Create, Review, and Approve

// A familiar web process hides blockchain mechanics from doctors and patients

The doctor opens a role-specific workspace, selects the patient, and creates a contract containing the proposed treatment and its description. The assigned patient sees that agreement in a separate personal area and can approve it after reviewing the terms.

The application validates each request before submitting the relevant state change to Ethereum. Users stay inside the CareChain interface while the backend manages transaction submission and confirmation through its configured signer.

▪The doctor creates a contract for an assigned patient.
▪The patient reviews the treatment terms and current status.
▪Approval becomes a recorded change in the contract lifecycle.

What the Smart Contract Adds to the Agreement

// A durable identifier, integrity Hash, timestamps, and approval state

CareChain keeps the readable agreement in encrypted, access-controlled storage and uses one central smart contract to manage verification records for many medical agreements. Each on-chain record connects a stable identifier and opaque reference to the agreement Hash, timestamps, and approval state.

Creation and approval update blockchain state, so the agreement does not rely solely on an editable application database. Authorized users can compare the stored document with the on-chain Hash and verify that the approved content remains unchanged.

▪A stable identifier connects every contract action.
▪The Hash detects changes without exposing the agreement contents.
▪The approval flag gives both sides a shared contract status.

Role-Aware Architecture Around the Contract

// The blockchain trail is useful only when the application enforces who may act

React presents separate interfaces for administrators, doctors, and patients. Node.js and Express verify the JWT, determine which contract actions the role can perform, and confirm that the requested agreement belongs to the active user before communicating with the blockchain.

MongoDB supports user accounts and application data, while password hashing, TLS, digital certificates, and object-level authorization protect the path into the signing workflow. A valid login alone does not grant access to every patient contract.

▪Doctors create contracts inside their assigned workflow.
▪Patients view agreements linked to their own identity.
▪Administrators manage accounts without replacing contract ownership checks.

Blockchain Preserves Contract State, but It Does Not Create Privacy

// Traceability and confidentiality solve different problems

CareChain uses blockchain as the agreement verification layer rather than as a confidentiality mechanism. The public chain contains the minimum state required for integrity and approval verification, while readable medical content remains encrypted behind access controls.

The distinction is essential: transaction history provides traceability, while encryption and authorization protect confidentiality. Each layer solves a separate part of the medical contract lifecycle.

▪Transaction history supports traceability and integrity.
▪Access control still belongs in the application and smart contract.
▪Sensitive readable content requires separate encryption and storage controls.

The Privacy Boundary: Keep the Contract, Minimize the Public Data

// Preserve verifiable consent while protecting the medical content behind it

The readable medical agreement stays in encrypted, access-controlled storage, while the public chain contains only a Hash, an opaque reference, and the state required to verify approval. The Hash reveals whether the signed agreement changed without publishing its contents.

Managed keys, contract-level authorization, immutable audit logs, independent smart contract review, monitoring, recovery, and transaction reconciliation protect the complete workflow. Together these controls preserve the purpose of CareChain: a clear medical agreement with a verifiable signing trail.

▪Encrypt the full agreement outside the public chain.
▪Anchor only a Hash and opaque reference on-chain.
▪Audit authorization, recovery, and smart contract behavior before launch.