Health Records
A healthcare smart contract is a blockchain-based program designed to automate and securely manage various processes within the healthcare ecosystem, such as patient data access, provider accreditation, insurance claim processing, and treatment record keeping. These contracts enforce logic through code, ensuring that only authorized entities can perform sensitive actions like registering patients, submitting medical claims, or accessing health records. By using cryptographic consent and role-based access control, healthcare smart contracts give patients greater control over their data while reducing the administrative overhead for providers and insurers. All interactions are logged immutably, providing transparency and accountability for regulators and auditors.
The use of healthcare smart contracts supports a wide range of applications, including the creation of national electronic health record systems, streamlined insurance claim workflows, public health campaign tracking, and secure sharing of health credentials. These contracts help address major challenges in the healthcare sector such as data fragmentation, fraud, manual processing delays, and lack of traceability. They ensure compliance with legal frameworks by encoding privacy rules directly into the system and by enabling real-time auditability of care delivery and financial transactions.
Disclaimer
This smart contract implementation is provided for educational and illustrative purposes only. It represents a conceptual framework for blockchain-based healthcare systems.
Key considerations before any production use:
-
Legal Compliance: healthcare systems are highly regulated and vary significantly by jurisdiction. This implementation would require substantial modification to meet specific legal requirements in any given location.
-
Security Review: The contract should undergo comprehensive security auditing by qualified blockchain security professionals before handling real user or financial transactions.
-
No Warranty: The authors and contributors disclaim all liability for any use of this code. Users assume all risks associated with implementation and operation.
-
Consultation Required: Any organization considering using this template should obtain advice from qualified legal counsel, and blockchain security experts before deployment.
Detailed explanation:
1. Upgradeability and initialization
-
Upgradeable architecture:
The contract uses the UUPS (Universal Upgradeable Proxy Standard) pattern to allow its implementation to be updated without losing state. The_authorizeUpgrade
function restricts upgrades to addresses that hold theDEFAULT_ADMIN_ROLE
and ensures that the new implementation address is valid (non-zero). -
Initialization process:
Instead of a traditional constructor, the contract has aninitialize
function that:- Initializes inherited modules such as access control, upgradeability, pausing, and reentrancy guards.
- Sets up key roles (
DEFAULT_ADMIN_ROLE
,ADMIN_ROLE
, andAUDITOR_ROLE
) with a provided super administrator. - Increments the patient ID counter during initialization so that the first patient receives an ID of 1, thereby avoiding potential ambiguity with an unregistered state.
2. Access control and role management
-
Defined Roles:
The contract establishes three main roles:- ADMIN_ROLE: Grants permissions for administrative actions including patient and provider registration, status updates, and claim management.
- PROVIDER_ROLE: Assigned to healthcare providers after successful registration and accreditation.
- AUDITOR_ROLE: Intended for users responsible for oversight and auditing without direct control over system operations.
-
Modifiers for Security:
Several modifiers enforce strict access control and state validations:onlyActiveProvider
: Ensures that a provider is active and not suspended before they can execute certain functions.onlyValidPatient
: Confirms that a patient is registered by checking for a non-zero patient ID.onlyWithConsent
: Validates that a provider has been granted consent by the patient.validDiagnosisCode
: Checks that a diagnosis code is within the acceptable ICD-10 length range (between 3 and 7 characters).
3. Patient registry
-
Patient Data Structure:
ThePatient
struct holds critical information including:- The wallet address.
- A SHA-3 hashed version of the national ID.
- An active status flag.
- Timestamps for registration and the most recent update.
-
Patient registration process:
TheregisterPatient
function (accessible only by an admin) performs several validations:- It confirms that the hashed national ID has not been registered before.
- It ensures that the wallet address is not already associated with another patient.
- It verifies a government signature (currently a placeholder) to authenticate the registration.
On successful validation, a new patient ID is generated (starting from 1), and the patient’s data is stored. The mapping from wallet address to patient ID is also updated for quick lookups.
-
Updating patient status:
Administrators can change the active status of a patient using theupdatePatientStatus
function, which also updates the patient’s last modified timestamp.
4. Provider registry
-
Provider data structure:
TheProvider
struct contains:- The provider's name, license number, and type (e.g., "HOSPITAL", "CLINIC", "LAB").
- Flags indicating if the provider is active or suspended.
- Timestamps for when the provider was registered and last updated.
-
Provider registration and tracking:
TheregisterProvider
function allows an admin to add a new provider after:- Checking that the provider is not already registered.
- Verifying the provider’s accreditation using a placeholder function.
Once validated, the provider’s data is stored, the
PROVIDER_ROLE
is granted, and the provider’s address is added to a dedicated array (_providerAddresses
). This array is later used to retrieve all provider addresses for operations like consent management. -
Provider suspension:
Administrators can suspend or reinstate a provider using thesuspendProvider
function, which updates the provider’s suspension status and last updated timestamp.
5. Consent management
-
Consent data structure:
TheConsent
struct records:- The provider’s address for which consent is granted.
- A flag indicating whether the consent is active.
- Timestamps for when the consent was granted and, if applicable, when it was revoked.
- The purpose for which consent is provided (e.g., "TREATMENT", "CLAIMS", "RESEARCH").
-
Granting and revoking consent:
- Granting consent:
Patients can callgrantConsent
to allow a provider to access their data for a specific purpose. This function checks that the provider exists and that consent has not been previously granted. - Revoking consent:
TherevokeConsent
function allows patients to withdraw consent, updating the consent status and recording the time of revocation.
- Granting consent:
6. Electronic health records (EHR) Management
-
EHR data structure:
TheEHR
struct is used to store:- An IPFS hash that points to the off-chain location of the health record.
- The provider’s address that is adding the record.
- The document type (such as "PRESCRIPTION", "LAB_RESULT", or "IMAGE").
- A timestamp of when the record was added.
- A data hash for ensuring the integrity of the record.
-
Recording EHRs:
TheaddEHR
function enables an active provider (with valid consent from the patient) to add an EHR. The record is stored in an array associated with the patient’s address and an event is emitted to log this addition.
7. Insurance claims management
-
Insurance claim data structure:
TheInsuranceClaim
struct encapsulates:- Addresses for both the patient and the provider.
- The diagnosis code (which must adhere to ICD-10 length requirements).
- The requested amount and the amount that gets approved.
- A status field using an enum (
PENDING
,APPROVED
,DENIED
,SETTLED
). - Timestamps for submission, approval, settlement, and denial.
- A string to record the reason for denial.
- An array to hold supporting EHR document references (e.g., IPFS hashes).
-
Claims workflow:
- Submission:
ThesubmitClaim
function lets a provider submit a claim on behalf of a patient (with proper consent). It validates the diagnosis code, accepts supporting EHRs, and logs the claim submission. - Approval:
Through theapproveClaim
function, an admin can approve a claim, ensuring the approved amount does not exceed the requested amount. The approval timestamp is recorded. - Denial:
ThedenyClaim
function allows an admin to deny a claim, documenting the reason and timestamp for the denial. - Settlement:
The newly addedsettleClaim
function permits an admin to mark an approved claim as settled, updating its status and recording the settlement timestamp.
- Submission:
8. Emergency controls
-
Pausing operations:
The contract integrates a pausing mechanism using OpenZeppelin’s pausable module.- The
emergencyPause
function allows an admin to pause all contract operations, which is useful in a crisis or security incident. - The
emergencyUnpause
function restores normal operations.
Both functions emit events to provide an audit trail of emergency actions.
- The
9. View functions and private helpers
-
Retrieving patient consents:
ThegetPatientConsents
function gathers all active consents for a given patient by iterating through the tracked provider addresses. It compiles and returns an array of active consent records. -
Private helper functions:
_providerExists
: Checks if a provider is registered by verifying the existence of a license number._getAllProviders
: Returns the list of all registered provider addresses stored in_providerAddresses
._verifyGovernmentSignature
and_verifyAccreditation
: These are stub functions that currently always return true; they serve as placeholders where robust external verification logic will be integrated.