Access control is the area of hospital security most prone to drifting into idealism. Least privilege, separation of duties, strict privileged ID control — all correct, and all capable of producing a ward where a night-shift nurse cannot perform a necessary action, a bank nurse cannot open a chart, or nobody can respond in an emergency. Care cannot be paused, and access design has to work inside that constraint.
At the same time, in disclosed incidents where damage spread across an entire hospital, excessive privilege and shared IDs recur. What decides the outcome is how short the distance is from the first compromised machine to everything else.
This article looks for the workable line between the ideal and the ward: role design, where least privilege actually belongs, offboarding and transfer reviews, vendor maintenance accounts, and what to do where shared IDs cannot be eliminated.
Disclaimer: This is general information. Guideline interpretation and reimbursement requirements are governed by MHLW publications and regional health bureau notices.
Roles by Profession, or by Function?
Most EMRs ship professional roles — physician, nurse, pharmacist, radiographer, billing, administration. A reasonable starting point, but profession and required access do not coincide.
- A "nurse" needs different information on a ward, in outpatients, and in theatre
- "Billing" covers both reception and claims, which differ in scope
- Sessional and salaried physicians may need different ranges
- Students, residents and agency staff fit no professional role cleanly
In practice you end up with two layers: professional roles as the base, functional roles as the delta — plus exceptions. The critical rule is not to create unlimited per-person exceptions, because once they multiply nobody can state who can see what, and review becomes impossible.
| Layer | Unit | Defines | Change rate |
|---|---|---|---|
| Base role | Profession | Normal scope for that profession | Low (yearly) |
| Functional role | Department / function | Ward, outpatient, theatre deltas | Medium |
| Individual grant | Person | Only unavoidable exceptions | Minimal, and always time-limited |
Always attach an expiry to individual grants. Access granted "temporarily for a project" that survives for years is the classic failure. With an expiry, it tidies itself up without a review cycle.
Note too that in healthcare withholding access is itself a risk: if a patient's history cannot be read during an emergency, that is a patient safety problem. Hospital access design therefore breaks if built as deny-by-default in the corporate style. The realistic answer combines a relatively broad read scope with recorded access and after-the-fact review — which is exactly why logging matters more in hospitals. See Logging and Audit Trails and Reviewing EMR Access Logs.
Where Least Privilege Actually Belongs
Applying least privilege everywhere stops the ward. Narrow it to where it counts.
| Target | Why |
|---|---|
| System administrator rights | Losing them reaches everything |
| Direct database access | Permits changes that bypass the audit trail |
| Write/delete on backup storage | Creates the structure where backups are encrypted too |
| Deletion of audit logs | Permits erasing the traces |
| The right to grant rights | Lets an attacker escalate on their own |
| Bulk export | The path for mass exfiltration |
These six come first. The third in particular: as covered in Backup design, a configuration where production administrator rights can also delete backups means losing the recovery path the moment those rights are taken. Separate the credentials for backup storage from production.
Conversely, over-restricting read access to clinical information collides with patient safety. That is territory for recording and reviewing, not restricting.
For privileged IDs, four basics:
- Separate from everyday accounts — do not read email as an administrator
- Do not share; if you must, record issuance so use can be attributed
- Require multi-factor authentication — the highest priority for MFA rollout (Multi-Factor Authentication)
- Store privileged-ID logs where that ID cannot delete them
Rights given to integrations and API automation follow the same logic. "Grant broadly, it's a system account" passes easily there, yet the necessary scope can be derived from what the process actually does — covered in the AI integration context in Permission Design and Security Checks for MCP in Healthcare.
Why Offboarding and Transfer Reviews Matter Most
The highest-yield practice is not elegant design but systematised review. However correct the design, a leaver's account left enabled negates it.
Hospitals make this hard: transfers cluster at the start of the fiscal year; people who never appear in the HR system (sessional, agency, contracted, students) exist; multiple systems hold their own accounts; and there is often no defined route by which a resignation reaches IT.
| Event | Action | Deadline |
|---|---|---|
| Joining | Grant per professional role; exceptions by request | Start date |
| Transfer | Remove the old department's rights before granting the new | Transfer date |
| Leave of absence | Suspend the account | First day of leave |
| Leaving | Disable accounts on every system | The leaving date itself |
| End of contract | Disable supplier accounts | Contract end date |
| Periodic | Full account review | At least annually |
"Remove before granting" on transfer is the most-missed step. Adding the new department's rights while leaving the old ones produces staff whose access accumulates with tenure — which is how a ten-year employee ends up able to reach almost everything.
Useful review queries: accounts with no login in 90 days; accounts with no matching person in the HR roster; every account holding administrator rights; expired individual grants; and every account issued to a supplier.
Vendor Maintenance Accounts
Staff accounts are managed; accounts handed to suppliers often are not. Yet spread via maintenance and supplier paths is one of the recurring patterns in disclosed incidents.
The reasons are structural: the vendor configured the account at installation so it never entered the internal register; the same account is reused as their engineers change; and the contract sits with administration while IT never sees it.
| Item | Define |
|---|---|
| Issuance unit | Per company or per engineer (per engineer as the rule) |
| Source | Which origins may connect |
| Hours | Always on, or opened only on request (on request is preferable) |
| Scope | Limited to what maintenance requires |
| Work records | Who did what, when — and which party retains them |
| Change of engineer | Duty to notify the hospital |
| End of contract | Account deletion, with confirmation |
| Subcontracting | Whether permitted, and who is accountable |
Opening the path only on request cuts risk substantially. A permanently connected maintenance link combines badly with perimeter vulnerabilities — design it together with Managing VPN Device Vulnerabilities.
To assess the supplier's own posture, knowing the certification framework helps frame the questions: see ISO/IEC 27001 (ISMS), Security Check Sheets for Vendors, and Demarcating Responsibility.
Where Shared IDs Cannot Be Eliminated
This is the heart of the matter. "Eliminate shared IDs" is correct, and hospitals have real reasons why they persist:
- Ward terminals used by nurses rotating through every few minutes
- Theatre and emergency settings where personal authentication is impossible mid-procedure
- Night shifts where few staff use many terminals
- Departmental reception terminals shared in rotation
- Departmental systems that do not support individual IDs at all
Dismissing these as poor awareness stops progress, because they arise from physical constraints on the work. The realistic policy is to reduce shared IDs progressively while layering measures that cap the damage from those that remain.
| Stage | Measure | Effect |
|---|---|---|
| 1 | Inventory every shared ID | You can see where the risk is |
| 2 | Strip privilege from shared IDs | Compromise grants no administrative action |
| 3 | Restrict what they can do (read-centric, no bulk export) | Lowers the ceiling on damage |
| 4 | Record who is using the terminal (IC card, biometrics, quick login) | Makes attribution possible after the fact |
| 5 | Define password rotation and frequency | Prevents leavers from continuing to use them |
| 6 | Migrate to individual IDs where the workflow allows | The real fix |
Stages 2 and 3 can be done while keeping the shared IDs. Even if the ID itself cannot go, "shared IDs cannot perform administrative actions" and "shared IDs cannot bulk export" meaningfully lower the ceiling on an incident.
Stage 4 is especially effective in hospitals. With an IC card or quick login identifying the operator, individual attribution becomes possible without abolishing the shared ID. Where read scope must stay broad, recording beats restricting — it coexists with the work and usually achieves more.
See also Password Policy Design and Logging and Audit Trails.
Connecting to the Requirements
The Electronic Clinical Information Coordination Structure Development Addition requires guideline compliance and a dedicated medical information system safety management officer as common requirements, with tier 1 (160 points) adding multi-method backup (part offline) and a cyber-attack BCP with exercises.
Access design underpins these:
- Separating backup credentials is what makes the tier 1 backup requirement real
- The safety management officer cannot decide without a list of who holds what
- BCP exercises cannot run unless it is settled who acts with which rights in an emergency
See the FY2026 revision overview and Appointing a Safety Management Officer.
Conclusion
- Design as professional roles + functional deltas + minimal, time-limited individual grants
- Apply least privilege strictly to six things: administrator rights, direct database access, backup storage, audit log deletion, the right to grant rights, and bulk export
- Separate backup credentials from production — otherwise losing production rights loses the recovery path
- In healthcare, withholding access is itself a risk. For read access, record and review rather than restrict
- Systematised review yields the most. Remove before granting on transfer, and do not lose sessional, agency and contracted people who never enter the HR system
- Govern vendor accounts by contract: per engineer, opened on request, work records, deletion confirmed at contract end
- Shared IDs arise from physical constraints. Stripping privilege, restricting actions, and recording the operator all work while the shared ID remains
If reviewing your access lists or drafting maintenance account clauses is where you are stuck, contact us.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Edition 6.0 | MHLW
- On the FY2026 Fee Revision | MHLW
- Personal Information Protection Commission
- Information-technology Promotion Agency (IPA)
Note: guideline interpretation and reimbursement requirements are governed by MHLW publications and notices, and change with revisions.