The procedures are written and the manager is appointed. Incidents still happen. What recurs across published disclosures from affected institutions is not the absence of rules but operations that did not match them. Backups existed but sat on the same network and were encrypted alongside production. The VPN appliance's vulnerability was known, but patching kept slipping. Recovery steps were undocumented, so switching to paper took far longer than anyone expected.
The system operations part of Edition 6.0 covers how the day-to-day is run. Its readers are the people who actually operate the systems: in-house IT, medical informatics practitioners, and on-site vendor staff.
This article organises that material into five areas — access control, logging, backups, equipment, and incident response — and states, for each, the minimum that counts as actually operating. For the rule-making side, see The Planning and Management Part; for how the four parts fit together, Key Points of Edition 6.0.
Disclaimer: This article is general information. The authoritative sources are the MHLW's published text, notices, and Q&A.
Access Control Is Really About Periodic Review
"Access control" sounds like a design problem, but what matters in operation is review. However carefully rights are designed at go-live, they expand over a few years of use: rights are added on each transfer and forgotten on each departure. The accumulation drives both insider leakage and the blast radius after an intrusion.
Four things to run:
| Activity | Frequency | What it involves |
|---|---|---|
| Issue, change, delete accounts | As they arise | Record the request and the approval. Never create an account on a verbal request |
| Suspension on departure or transfer | Same day | Tie it to the HR process. Do not leave IT to find out afterwards |
| Rights review | At least annually | List every account and confirm necessity against current duties, with department heads signing off |
| Privileged ID management | Continuous, plus at review | Know who holds administrator rights. No shared use; record each use |
The second is structurally weak in many institutions. When HR and IT processes run separately, the fact of a departure can reach IT days later. Putting account suspension into the HR approval route is the reliable fix.
Privileged IDs include the vendor's maintenance accounts. It is not unusual for an institution to be unable to say who used the maintenance administrator account, when, or why. If remote maintenance is permitted, require records of source, time, and work performed. See Demarcating Responsibility and, for the general principle, Permission Design for MCP.
Logs Are About Reading, Not Collecting
The common failure mode is logs collected that nobody reads. In that state you cannot detect an intrusion, and you cannot reconstruct events afterwards.
Four decisions:
| Decision | Approach |
|---|---|
| What to collect | EMR access logs (who viewed which patient's record), authentication logs (success and failure), administrator actions, network device logs, backup job results |
| How long to keep | Set a retention period and provision capacity. Check it is not set to roll over and overwrite |
| Who reviews, and when | Assign an owner and a cadence. You do not need to read everything — decide which signals you are looking for |
| Tamper resistance | Do not let an administrator freely delete logs; store them on a separate system where possible |
The third decision is the one that determines whether this survives. "Review all logs daily" never lasts. Narrowing what you look for does. For example:
- Accounts with a burst of authentication failures
- Administrator rights used at night or at weekends
- Record access beyond the user's normal remit — records of public figures, of staff themselves, or of relatives especially
- Remote maintenance connections reconciled against advance notice
See Reviewing EMR Access Logs and Log Management and Audit Trails.
Backups Are Now a Billing Requirement
Under the electronic clinical information coordination add-on introduced in FY2026, the inpatient tier 1 (160 points) adds two requirements on top of the common ones: backups by multiple methods, with some held offline, and a BCP for cyberattacks together with drills. Tier 2 (80 points) requires only the common items — guideline compliance and a dedicated medical information system security manager. For the revision as a whole, see FY2026 Fee Revision: Cross-Specialty Changes.
Official Q&A gives examples of what "multiple methods" and "partly offline" mean. Each of the following is treated as satisfying the requirement.
| Method | What it is | Implementation notes |
|---|---|---|
| Separate media | Held on distinct media such as RDX, with generation retention | Decide storage location and transport handling; plan for media degradation and loss |
| Automatic transfer | Automatically transferred to a NAS or similar, kept permanently disconnected from the network | The architecture must reconcile "automatic" with "permanently disconnected" |
| Within cloud | Backed up to a logically separated area within the cloud service, allowing prompt recovery | Confirm the provider's specification; document where their responsibility ends |
On generation retention, daily backups should keep at least three generations. For weekly and monthly cycles no single figure is given, as it depends on hospital size and backup method.
Operationally the point is the shift from "we take backups" to "we confirmed we can restore." One structure that recurs in published ransomware disclosures is backups held on the same network and encrypted together with production — which is precisely why an offline copy is in the requirement.
Day to day:
- Check job success and failure daily — and check that failure notifications actually reach someone
- Run restore tests periodically, recording that recovery worked and how long it took
- Manage the storage location and removal records for offline media
- Reconcile the backup coverage against the information asset register to catch anything excluded
Point 4 is easily missed: EMR data is covered, but departmental systems, imaging, or data related to online eligibility verification turn out not to be. See Backup Design for Healthcare Institutions: the 3-2-1 Rule and Building a BCP for Cyberattacks.
Equipment and Media
This part treats everything attached to the network as in scope, not only servers and PCs. In rough order of how often they cause trouble:
1. Network equipment (VPN appliances, routers, wireless APs)
Published incident disclosures repeatedly show a known vulnerability at this layer as the entry point. These devices attract little attention because they are treated as install-and-forget. At minimum:
- Model and firmware version recorded in the register
- A route by which vulnerability notices from the vendor reach you
- A named person who decides on updates — removing "the vendor presumably handles it"
- Maintenance contracts current, with no end-of-support devices still in place
2. Networked medical devices
Patient monitors, infusion pumps, endoscopy and imaging systems. Even where they run a general-purpose OS, device certification may prevent free updating. If you cannot patch it, protect it at the network layer — segment it, restrict its traffic.
3. Endpoints (desktops, laptops, tablets)
Decide whether removal is permitted, whether disks are encrypted, and what happens on loss. Where devices leave the building for home visits, design on the assumption of loss: full-disk encryption, remote wipe, and a configuration that leaves no data on the device.
4. Removable media
Conference presentations, sharing images with another institution, handing data to a vendor — these arise unavoidably. A blanket prohibition simply pushes the practice out of the records. Provide a request-approve-record procedure and decide deliberately to permit it, and you can manage it.
5. Disposal
The step most often forgotten. Medical information persists on PCs, servers, multifunction-printer storage, and backup media. Include the disposal method and the certificate of destruction in the procedure, and update the asset register at disposal.
See Endpoint Management, Managing USB and Removable Media, Security for Networked Medical Devices, and Managing VPN Appliance Vulnerabilities.
Can You Actually Move During an Incident?
What decides an incident is whether who does what in the first hour has been settled. Technical analysis can be brought in from outside later; the initial judgement can only be made in-house.
The minimum to have ready:
| Prepared item | Detail |
|---|---|
| Call list, on paper | Manager, vendors, maintenance contractors, network carrier, external specialists as needed. Printed and stored on the assumption the network is unavailable |
| Initial decision criteria | Which events trigger disconnection, on whose authority, and how far |
| Continuity procedure | Running on paper when the EMR is unavailable — forms, where they are kept, how data is entered afterwards |
| Record format | A timeline of who did what and when; essential for later reporting and root cause work |
| Reporting obligations | Where and by when to report suspected personal data breaches |
The on paper point deserves emphasis. Situations do arise where the network is down and the contact list exists only inside the EMR.
Continuity procedures do not reveal their gaps until you actually run one. Tier 1 requires a BCP and drills precisely because a plan alone does not function. A drill need not be elaborate: running a morning clinic on paper as if the EMR were unavailable will surface missing forms and workflow problems every time.
See Reporting Obligations for Personal Data Breaches, First Response to a Ransomware Incident, and Building an Incident Response Plan.
The MHLW's cybersecurity checklist and manual for healthcare institutions (14 May 2025) adds coverage of cloud environments, BCP, IoT, and BYOD, and works well as a gap check on the operational side.
Conclusion
- Access control is really periodic review. Put suspension on departure into the HR approval route. Vendor maintenance privileged IDs are in scope
- Collecting logs is not enough. Narrow what you look for, and name who reviews them and when. Check retention is not silently overwriting
- Backups by multiple methods with an offline copy are a tier 1 requirement. Separate media, automatic transfer with permanent disconnection, and logical separation within cloud are all given as examples
- For daily backups, keep at least three generations; no single figure is set for weekly or monthly cycles
- Move from "we take backups" to "we confirmed we can restore" — restore tests, recorded recovery times, and reconciliation against the asset register
- VPN appliances, wireless APs, and networked medical devices default to install-and-forget. Name who decides on updates
- Incident response is decided in the first hour. Keep the call list on paper, and actually rehearse the paper workflow
If you would like help establishing an operating pattern, or organising backups and BCP ahead of filing for the add-on, get in touch. For the rule-making side see The Planning and Management Part; for executive responsibility, The Governance Part; for appointment, The Medical Information Security Manager; for smaller practices, Guideline Compliance for Small Clinics. Background on the guidelines is in The Three Ministries' Two Guidelines Explained, and the vendor-side certification regime in What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Edition 6.0 full text (PDF) | MHLW
- On the FY2026 medical fee revision | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: the guidelines are revised and fee requirements clarified through official Q&A. This article reflects material published at the time of writing; base filing and billing decisions on current notices and confirmation from your Regional Bureau of Health and Welfare.