Overview
TheAccessGrant is a public struct that represents a temporary access permission granted by a patient to a healthcare provider. It is stored in the public access_grants mapping, allowing doctors to verify their access rights without revealing the actual medical data.
Fields
The address of the patient who granted access. This field identifies who owns the medical record and who has the authority to revoke access.
The address of the healthcare provider who has been granted access. This must be different from the patient address - the contract enforces
assert_neq(patient, doctor) during grant creation.The unique identifier of the medical record to which access is granted. This references a specific
MedicalRecord but does NOT contain the actual medical data.Cryptographic proof of permission generated as a hash of the record ID, doctor address, patient address, and client-provided nonce using BHP256:This token should be encoded in a QR code for the doctor to scan.
Block height when access was granted. This is set automatically to
block.height during the finalize function and provides an immutable timestamp of when the permission was created.Block height when access expires. Calculated as
granted_at + duration_blocks where duration is clamped to the following bounds:- Minimum: 240 blocks (~1 hour)
- Maximum: 40,320 blocks (~7 days)
- Default: 5,760 blocks (~24 hours)
Manual revocation flag. When set to
true, access is immediately invalidated even if the expiration block height hasn’t been reached. Only the original patient can revoke access.Access Duration
Access duration is specified in blocks, where approximately:- 1 block = ~15 seconds
- 4 blocks = ~1 minute
- 240 blocks = ~1 hour (minimum)
- 5,760 blocks = ~24 hours (default)
- 40,320 blocks = ~7 days (maximum)
Block times may vary slightly. These durations are approximate based on Aleo’s target of ~15 seconds per block.
Granting Access
Access grants are created using thegrant_access transition:
Verifying Access
Doctors verify their access using theverify_access transition:
Access Validation Checks
Theverify_access function performs the following checks:
- Token Exists: Access token must exist in
access_token_validmapping - Doctor Match: Provided doctor address must match
grant.doctor - Record Match: Provided record ID must match
grant.record_id - Not Revoked:
grant.is_revokedmust befalse - Not Expired: Current
block.heightmust be ≤grant.expires_at
Revoking Access
Patients can manually revoke access before expiration:- Sets
is_revokedtotruein the AccessGrant - Sets
access_token_validmapping tofalse - Is irreversible - the same token cannot be un-revoked
- Can only be performed by the original patient (
grant.patient)
Public Mappings
AccessGrant data is stored in two public mappings:access_grants
access_token_valid
Security Model
Token Unpredictability: Access tokens include a client-provided nonce in their hash, making them cryptographically unpredictable. Doctors cannot guess or pre-compute valid tokens.
Automatic Expiration: Access automatically expires at the specified block height. No manual cleanup is required - the blockchain enforces expiration.
Integration Example
Complete flow for patient-doctor data sharing:Related Structures
- MedicalRecord - Private record structure containing encrypted health data
- Record Types - Medical record categories
- AccessTokenInput - Helper struct for token generation
Querying Access Info
Anyone can query access grant details usingget_access_info: