fingerprint
Authentication
“Who are you?”
Supabase Auth handles email/password sign-in and sessions. The user's role rides in the JWT as a signed claim.
Supabase Auth
shield_lock
Secure EHR · Blockchain-anchored
Electronic health records you can prove were never altered.
VitaSecure encrypts every clinical record with AES-256-GCM, anchors a SHA-256 fingerprint on a permissioned blockchain, and lets an on-chain RBAC contract — not a database flag — decide who may act. Integrity becomes something you can verify, not just trust.
enhanced_encryption
AES-256-GCM
tag
SHA-256 anchored
account_tree
On-chain RBAC
verified_user
Integrity
Verified on-chain
lock
At rest
Encrypted record
3
Enforcement layers
6
Least-privilege roles
256
Bit AES-GCM keys
∞
Immutable versions
The core idea
Three concerns. Three mechanisms.
Authentication, authorization and integrity are deliberately kept separate — each enforced by a different mechanism. The on-chain layers are authoritative; the database is a backstop.
database
Data-layer authz
“Can this row be returned?”
Postgres Row-Level Security, deny-by-default on every table, keyed on the authenticated user id and role claim.
RLS · backstop
account_tree
Policy authz
“May this role do this?”
An on-chain RBAC smart contract makes the real permit/deny decision for every privileged clinical operation. The contract wins on conflict.
On-chain RBAC
link
Integrity
“Has it been altered?”
A SHA-256 hash of each record is anchored on a permissioned EVM chain. Re-hash any time and compare — tampering is mathematically detectable.
SHA-256 anchor
How it works
Every clinical write follows one pipeline.
Records never go on the chain — only their fingerprint does. Updates never overwrite: each change is a new version, re-hashed and re-anchored, while the prior anchor stands.
-
verified_user 01
Authorize
On-chain RBAC
checkAccessbefore any action. -
data_object 02
Canonicalise
Stable field ordering so equal records hash equally.
-
enhanced_encryption 03
Encrypt
AES-256-GCM on sensitive fields; the key never leaves the server.
-
tag 04
Hash
SHA-256 over the canonical record produces its fingerprint.
-
link 05
Anchor & audit
Hash + metadata anchored on-chain; the event is audited.
Tamper-evident by design
Verification returns a verdict, not a guess.
The verify path re-hashes the stored record and compares it to the on-chain anchor. The result is binary and provable — surfaced everywhere clinical data is shown.
-
check_circle
VERIFIED — the record's hash matches its anchor. Untouched since it was written.
-
gpp_bad
TAMPERED — the hashes diverge. The stored record no longer matches what was anchored.
description
Encounter · v3
Hash matches on-chain anchor
running_with_errors
Lab result · v1
Stored hash ≠ anchored hash
hourglass_top
Prescription · v1
Awaiting on-chain anchor
Role-based access control
Six roles. Least privilege, enforced.
Every role sees exactly what its duty requires — and nothing more. Even the Administrator is denied all clinical-content operations. This is enforced technically, not by convention.
manage_accounts
Administrator
Manages users, roles and system health. Denied all clinical content.
stethoscope
Doctor
Creates and reads encounters, lab orders and prescriptions for their patients.
vaccines
Nurse
Records vitals and notes; reads results within assigned care.
biotech
Lab Technician
Processes lab orders, enters results and runs integrity verification.
person_add
Receptionist
Registers patients and manages appointments. No clinical content.
favorite
Patient
Views own records, manages consent and sees a full access log.
Ready to work on records you can trust?
Create an account to explore the role dashboards, or sign in to your clinical node.