Security & data protection

A hospital holds some of the most sensitive personal data there is. BridgeERP HMS is built to protect it: roles that limit who sees what, record rules that wall off one site’s patients from another’s, an audit log that records who did what, plus two-factor login, backups and the controls you need to satisfy Kenya’s Data Protection Act and comparable regimes. This page is the administrator’s checklist for locking the system down.

Where to find it

• Settings → Users & Companies → Groups — the BridgeERP HMS roles and their access rights.
• HMS Core → Configuration → Operations → Audit Log — the record of portal and patient-record activity.
• HMS Core → Patients → Consents — the consents patients have signed.
• Settings → Users & Companies → Users — where two-factor authentication is enforced per user.

Layer 1 — least-privilege roles

The first line of defence is giving each person the narrowest role that lets them work. The clinical ladder (Reception → Nurse → Doctor) and the separate Pharmacist, Lab Technician, Lab Supervisor, Radiologist, Cashier, Manager and Administrator roles are described in Staff & roles. A Cashier never opens the clinical chart; a Lab Technician cannot prescribe; only the Administrator manages security groups. Reserve Manager and Administrator for the few who truly need them.

The roles are grouped into two categories under Settings → Users & Companies → Groups so you can tell staff access from patient access at a glance.

Layer 2 — record rules and confidentiality

Even within an allowed app, record rules limit which rows a user sees. Patient, visit, appointment, triage, queue, vitals and facility records are company- and facility-scoped: a user only sees records belonging to the company they are signed into, so staff at one site cannot browse another site’s patients. The patient portal is tighter still — a patient signing into the portal can read only their own patient and appointment records, with no ability to create or delete.

The portal rules are deliberately read-only. A patient signed into the portal may view their own patient record, appointments and visits, but the rules grant no write, create or delete permission — so the portal can never alter clinical data.

Layer 3 — the audit log

Sensitive access is recorded. Open HMS Core → Configuration → Operations → Audit Log to see activity captured against patient and portal records — who acted, on what, and when. In addition, key fields on the patient, visit and other clinical records are tracked, so every change is written into the record’s own message history with the author and timestamp. Together these give you the “who looked at / changed this patient” trail that data-protection audits and incident investigations require.

Because tracked changes live in each record’s message thread, a clinician or auditor reviewing a single patient can see the full history of edits without leaving the record — when the diagnosis was changed, when the VIP or Do-Not-Contact flags were set, and by whom. Treat the audit log as evidence: it is read-only operational data, not something front-line staff edit.

Layer 4 — consent and patient rights

Patient consent is a first-class record. Capture and store signed consents under HMS Core → Patients → Consents, and use the Do Not Contact flag on the patient record to honour communication-preference requests. Because the patient master record is one place, a data-subject access or erasure request — a right under Kenya’s Data Protection Act 2019 and the EU GDPR — can be answered from the single patient form and its linked visits, documents and consents.

Layer 5 — two-factor authentication

Enable two-factor authentication for every account that can reach patient data, and make it mandatory for Manager and Administrator accounts. Each user turns it on from their own preferences using an authenticator app; an administrator can require it. Combine it with a sensible password policy and prompt de-activation of leavers’ accounts.

1. Have each user open their Preferences → Account Security and enable two-factor authentication.
2. Scan the QR code into an authenticator app and confirm the six-digit code.
3. For privileged accounts, verify two-factor is active before granting the Administrator role.

Layer 6 — backups and continuity

Clinical data must survive hardware failure. The platform stores its data in a PostgreSQL database and a filestore for attachments — both must be backed up on a schedule, with at least one copy held off-site, and restores tested periodically so you know they work. Agree a retention period that meets your regulator’s requirements, and ensure backups are encrypted at rest since they contain the same patient data as the live system.

Data-protection posture

Taken together — least-privilege roles, facility-scoped record rules, the audit log, tracked fields, consent capture, two-factor login and encrypted off-site backups — the suite gives you the technical and organisational measures that the Kenya Data Protection Act and GDPR expect. Document who your data controller and processor are, register with the regulator if required, and keep this configuration under change control so it does not drift. For multi-country operators, the localisation packs add the local identifiers and reporting formats each jurisdiction’s health authority requires, which keeps patient identifiers consistent with national schemes.

Security go-live checklist

1. Every staff account has exactly one HMS role, set to the lowest that fits the job.
2. No clinical or portal user has access to more companies than they need.
3. Two-factor authentication is on for all Manager and Administrator accounts.
4. Database and filestore backups run on a schedule, are encrypted, and a restore has been tested.
5. Consent capture and the Do-Not-Contact flag are in use at registration.
6. A monthly review of the audit log and privileged-role holders is booked.

Related

• Staff & roles
• Creating your facility
• Getting started overview