SECURITY & DATA
Review how RAKT controls staff access, records consent, and handles changes. Use this page and the linked policies when assessing your proposed setup.
INSPECT THE CONTROLS
WHO CAN DO WHAT
Staff access is scoped through department and action permissions. Your role setup should reflect the work each person is responsible for.
Ask us to demonstrate: one user with access to the intended department, and another without it.
BEFORE A REPORT LEAVES
Patient-bound lab and radiology report messaging checks consent before sending. The provider and delivery integration also need to be configured.
Ask us to demonstrate: report delivery with consent granted and consent withdrawn.
BEFORE AN API WRITE
API key permissions include a writable check. Review integration scope and the intended actions before issuing credentials.
Ask us to demonstrate: the expected read request and a write request with a read-only key.
IDENTITY HANDLING
Government identity fields in the patient model use encrypted fields. Review the full data handling and deployment arrangements for your setup.
Ask us to demonstrate: which fields are encrypted, who can access them, and how your deployment handles keys.
01 / Access control
RAKT scopes staff permissions by department and responsibility. Patient and operational records belong to an organisation. Review your role and branch setup with us as part of implementation.
02 / Patient communication
Patient consent records are part of the platform. Lab and radiology messaging workflows check consent before sending reports. Your messaging provider and delivery settings also need to be configured.
03 / Record accountability
The platform includes activity logs and change-request workflows. Ask us to demonstrate the audit coverage and correction process for the departments and records in your review.
04 / Your deployment
Ask for the hosting region, backup and recovery arrangements, integrations, and data handling terms for your proposed deployment. The Data Processing Addendum and privacy policy set out the applicable terms.
PRODUCT CONTROLS, EXPLAINED
The permission model combines the department, the module, and the action a person is trying to perform. Department membership and role grants determine access, with organisation and branch administration handled explicitly. During the security demonstration, test reception, clinical, pharmacy, and accounts roles against your staff responsibilities.
Organisation API keys have a writable setting. Read-only keys are prevented from making write requests by the API permission layer. Installed applications can also have granted scopes. Review the owner, scope, and permitted operations for each integration, and agree who is responsible for changing or revoking access.
Government identity fields on the patient model use application-level field encryption. Patient consent records store the purpose, notice version, and grant or withdrawal details. Report-delivery workflows consult consent for patient-bound communication. These are specific product controls; they should be reviewed alongside the hosting and operational arrangements for your deployment.
Outbound app webhooks include a signature generated from the payload and a shared secret. The receiver needs to verify that signature as part of the integration. Data destinations, access credentials, permitted events, retention, and incident contacts should be agreed for each external system that receives information.
Ask for the proposed hosting region, backup schedule, retention, recovery process, monitoring, and access arrangements. Review recovery evidence and responsibilities with the team managing the deployment. The privacy policy and Data Processing Addendum provide the relevant terms; a product feature list is only one part of a security assessment.
FOR YOUR SECURITY REVIEW