Clinical Staff Security & Workspace Keys
How does ConsentCollect secure clinical staff management and workspace access?
In medical clinics and clinical trial operations, securing the staff workspace is just as critical as protecting patient-side data. Because clinical coordinators, principal investigators, and compliance auditors hold powerful administrative permissions—such as drafting consent forms, configuring pre-flight compliance rules, and exporting completed consent assets—the platform must enforce absolute security boundaries around staff operations.
ConsentCollect implements a Zero-Knowledge Staff Security Architecture. This framework provides institutional primary owners with strict roster controls, distinct role authorization tiers, and an advanced cryptographic key exchange system. This guarantees that only verified staff members can manage or view sensitive clinical records, while preventing platform operators, database administrators, or external servers from ever accessing your private workspace credentials.
How does the platform manage roster seats and invitations?
To maintain clear oversight and control over who has access to the workspace, ConsentCollect enforces strict roster rules:
- Strict Two-Seat Roster Limit: Every organization workspace is hardcoded to a strict limit of two (2) active or pending staff seats (in addition to the Primary Owner). This hard limit prevents unauthorized seat expansion, keeps administrative overhead controlled, and ensures security audits remain highly manageable.
- Clinician-to-Clinician Access: Only the Primary Owner (the primary clinical administrator) can allocate staff seats and dispatch invitations. Staff members themselves are strictly blocked from inviting other users or allocating seats.
- Double-Locked Invitations: When the owner invites a staff member, the owner defines a secure, multi-digit Secret Verification Code that the staff member must enter to accept the seat.
What role-based authorization levels are available?
When inviting a clinical staff member, the Primary Owner assigns a distinct role-based access level to enforce the principle of least privilege:
| Access Level | Permitted Operations | Restricted Operations | Clinical/Compliance Purpose |
|---|---|---|---|
| Primary Owner | Full system control, billing, seating allocation, template creation, data deletion settings, and cryptographic key wrapping. | None. | Canonical administrative control over the entire clinical workspace. |
| Editor | Drafts new consent forms, customizes templates, configures sequential signing workflows, and manages pre-flight compliance checks. | Cannot allocate roster seats, manage subscription billing, or delete primary accounts. | Day-to-day clinical coordinators who actively manage patient intakes and form layouts. |
| Auditor | Read-only access to completed forms, active timelines, verification metrics, and compliance audit logs. | Strictly blocked from editing templates, modifying drafts, or altering pre-flight configurations. | Compliance officers, legal counsel, and Institutional Review Board (IRB) members who need to audit trails without risk of altering data. |
How does client-side hashing protect staff passcodes?
Traditional web applications send passcodes or verification pins over the internet to be validated by the database. If the server is intercepted or database logs are compromised, these codes are exposed. ConsentCollect prevents this using a Double-Hash Verification Exchange:
- Client-Side Sensation: When a staff member inputs their secret verification code to accept an invitation, their browser immediately performs a one-way cryptographic hash (SHA-256) on the code before it is transmitted over the network.
- Zero Plaintext Transmission: The plaintext code never travels over the internet, never enters the server memory, and is never logged in operator databases.
- Hash-to-Hash Matching: The server only receives the secure, scrambled hash and compares it directly to the hashed value stored in the invitation record. If they match, access is granted. This ensures that even in the event of a full server database compromise, your raw invitation passcodes remain completely secure.
How does the Zero-Knowledge cryptographic key handshake operate?
The core of ConsentCollect’s data protection is its Zero-Knowledge design. Plaintext clinical records are encrypted client-side using a master Workspace Key. To share this Workspace Key securely with newly invited clinical staff without exposing it to the server, the platform executes a secure Cryptographic Key Handshake:
Zero-Knowledge Cryptographic Handshake
How the master Workspace Key is securely shared without ever exposing it to platform servers.
Staff Accepts Invite
The invited coordinator accepts their invitation code, initializing their secure local environment.
Local Keypair Generation
Browser generates an asymmetric keypair locally: a Public Lock Key and a Private Key (which never leaves the device).
Public Lock Upload
The staff member's browser uploads only the Public Lock Key to the server ledger. The Private Key remains strictly offline.
Owner Fetches Lock Key
The Workspace Owner logs in. Their browser automatically fetches the pending staff member's Public Lock Key from the server.
Key Wrapping (Encryption)
The Owner's browser encrypts (wraps) the master Workspace Key locally using the staff member's Public Lock Key.
Upload Wrapped Key Blob
The encrypted Workspace Key blob is uploaded and stored in the database. Plaintext keys are never sent to the server.
Fetch & Local Decrypt
The staff member logs in, downloads the encrypted key blob, and decrypts it locally using their secure Private Key to unlock the workspace.
Step 1: The Asymmetric Keypair Generation
When a staff member accepts their invitation, their browser automatically generates a unique pair of mathematical keys:
- The Public Lock Key: Stored publicly on the server. Anyone can use this key to “lock” or encrypt data, but it cannot be used to decrypt anything.
- The Private Key: Remains strictly local in the staff member’s browser. It is secured via a unique, per-user encryption salt and never leaves their local device. Only this Private Key can decrypt data encrypted by the corresponding Public Lock Key.
Step 2: The Key Wrapping Handshake
When the Primary Owner logs in, their dashboard detects a pending staff member who needs access to the workspace:
- The owner’s browser fetches the staff member’s Public Lock Key from the server.
- The owner’s browser retrieves the master Workspace Key (which is already active and decrypted locally in the owner’s browser).
- The owner’s browser encrypts the Workspace Key using the staff member’s Public Lock Key. This process is called Key Wrapping.
- The wrapped (encrypted) key blob is uploaded back to the server.
Step 3: Local Decryption
When the new staff member logs in:
- Their browser downloads the wrapped key blob from the server.
- The browser decrypts this blob locally using their own secure Private Key.
- The decrypted Workspace Key is then used locally in their browser to decrypt clinical forms and templates.
Why this is ironclad: The server only stores the Public Lock Key and the encrypted Workspace Key blob. Because the server does not possess the staff member’s local Private Key, it can never decrypt the Workspace Key or view the plaintext clinical consent documents.
How does administrative revocation protect the roster?
If a clinical coordinator leaves your practice or a security credential is lost, the Primary Owner can execute an immediate Administrative Revocation:
- Instant Roster Purge: Clicking “Revoke” instantly marks the staff invitation status as
revokedin the workspace ledger. - Cryptographic Neutralization: The system automatically sweeps the revoked user’s profile, completely deleting their assigned access level, public key, and encrypted Workspace Key.
- Immediate Lockout: Because the Workspace Key is removed from their profile and their authorization is set to inactive, the user is locked out of the clinical workspace instantly, neutralizing their credentials and protecting institutional data.