Consent, Access Control, and Audit Trails in Health Analytics

Access control that reflects real roles

Our platform uses role-based access control with four levels: external users (customers), team members, admins, and super admins. Each role sees different things and can do different things. A customer can upload data and view results but cannot see internal notes, failed payment records, or gateway debug information.

This is not just about privacy. It is about ensuring that people see information appropriate to their role. A programme manager does not need to see internal task assignments. A customer does not need to see which payment gateway returned an error. The system enforces these boundaries automatically.

The role structure maps to how institutional analytics partnerships actually work. The external user (customer) is the partner who provides data and receives results. They need access to their project files, their invoices, their deliverables, and their project messages. They do not need to see how the internal team organises its work. Team members need to see the data, the analysis in progress, and internal coordination notes. Admins need to see all of that plus financial information, workload distribution, and project assignment controls. Super admins need the full picture, including user management, system audit logs, and operational telemetry.

Each role boundary is enforced at the API level, not just the UI level. Hiding a button in the interface is not access control. A determined user with browser developer tools can call the API directly. Our access checks run on the server for every request, verifying that the authenticated user has the required role and, where applicable, the required project assignment before returning any data. This means a team member cannot access a project they are not assigned to, even by crafting a direct API call.

Consent and data handling

In health analytics, consent is not a one-time checkbox. Patients consent to their data being used for a specific purpose. If the analysis expands beyond that purpose, the consent may not cover it. Our platform supports project-level data scoping so that data uploaded for one project cannot be accessed from another project, even by the same user.

When a partner uploads patient data for a specific analytical engagement, that data is confined to the project scope. It does not appear in global search results, it is not accessible to team members working on other projects, and it is not included in aggregate statistics or training data for other models. These boundaries are enforced by the database access layer, not by UI-level filtering.

Data retention is another consent issue. When a project is completed and the data sharing agreement specifies a retention period, the platform supports scheduled data deletion. Project files can be marked for deletion after a specified date, and the system notifies both the partner and the admin before deletion occurs. This ensures that data is not retained beyond the consented period, which matters both for regulatory compliance and for maintaining partner trust.

Audit trails that answer real questions

Every significant action on the platform is recorded in an audit log: who did what, when, and to which project. File uploads, payment confirmations, stage changes, user assignments, quote responses, all logged with timestamps and the acting user's identity.

When a partner asks 'who accessed our data file on March 15th,' the platform can answer that question. When an internal review asks 'who changed the project stage from review to delivered,' the audit log has the entry. This is basic accountability infrastructure, and it is built into the platform from the start, not added as an afterthought.

The audit log is immutable. Entries cannot be edited or deleted, even by super admins. This is a deliberate design decision because an audit log that can be modified is not an audit log. It is a narrative. Immutability ensures that the log represents exactly what happened, which is what auditors, compliance officers, and institutional review boards require.

File access logging deserves specific mention. Every file download is recorded with the user identity, timestamp, IP address, and the file that was accessed. If a data file is downloaded 50 times, the audit log contains 50 entries showing exactly who downloaded it and when. This level of detail is necessary for health data governance and is required by most institutional data sharing agreements.

• All file downloads are logged with user identity and timestamp
• Project stage changes are recorded with the user who made the change
• Payment confirmations and refunds are audit-logged
• User assignments and removals are tracked

Governance is infrastructure, not documentation

A governance policy that exists only as a PDF on a shared drive is not governance. It is aspiration. Real governance is enforced by the system: role-based access that cannot be bypassed, audit logs that cannot be edited, and file access tracking that runs automatically.

We built these features because institutional partners (hospitals, universities, government agencies) expect them. And because doing health analytics responsibly requires them.

The difference between documented governance and implemented governance becomes clear during procurement reviews. When a university data protection officer asks 'how do you ensure that only authorised personnel access the research data,' a governance policy document says 'we have procedures in place.' Our platform says 'role-based access control is enforced at the API level, project assignment is required for data access, and every access event is recorded in an immutable audit log.' One is a promise. The other is a verifiable fact.