Ask a hospital about logs and the answer is almost always "we collect them" — EMR access logs, server logs, firewall logs. That much is usually true.
The next question is where it stops. "Did anyone look at them last month?" Collected but never reviewed; retention left at the product default and quietly overwriting after thirty days; discovering only during an incident that the relevant period is gone — none of this is unusual.
Logs have the property that if they were not designed in advance, it is already too late when they are needed. Detecting an intrusion, scoping the damage, and meeting your duty to explain to patients all depend on being able to reconstruct events. This article covers what to collect, how long to keep it, and how to review it with limited staff.
Disclaimer: This is general information. Guideline interpretation and the application of retention requirements are governed by MHLW publications and the relevant laws and notices.
What Logs Are For
Without stating the purpose, log discussions settle into either "collect everything" or "leave the defaults." Neither works. Hospitals log for four distinct reasons.
| Purpose | What it needs | Who uses it |
|---|---|---|
| Detecting improper access | Read logs, permission change logs | IT, patient safety |
| Incident investigation | Network, authentication, endpoint logs | IT, external responders |
| Accountability (patients, regulators) | Who saw what, when | Administrators, executives |
| Integrity of the clinical record | Change history, operator identity | Health information management |
These four differ in both the logs required and the retention needed. Detection needs timeliness; record integrity needs long retention; investigation turns on network logs nobody normally reads.
The third and fourth are hospital-specific. Corporate logging leans on security; in a hospital the nature of the clinical record is added — who wrote it, when it was amended. See Reviewing EMR Access Logs.
What to Collect
| Category | Logs | Priority | Main use |
|---|---|---|---|
| Authentication | Login success and failure, lockouts | High | Signs of intrusion, misuse |
| Permissions | Grants, changes, revocations | High | Detecting escalation |
| Privileged actions | Administrator account activity | High | Tracking the gravest operations |
| Clinical access | Reads, updates, deletions of patient records | High | Accountability, integrity |
| Output | Printing, CSV export, writes to removable media | High | Detecting mass exfiltration |
| Network | Firewall, proxy, VPN connections | Medium–high | The core of investigation |
| Endpoint | Boot, USB attach, software installation | Medium | Endpoint-borne intrusion or exfiltration |
| System | Service start/stop, errors, configuration change | Medium | Fault investigation, tamper detection |
| Backup | Job results, restore operations | Medium | Assuring recoverability |
The five high-priority categories are the minimum, because together they trace who touched which information with what rights, and whether it left the building.
Each record should carry: when (with clocks synchronised across devices), who (user ID, plus terminal or IC card where shared IDs are in use), from where, against what, what action, and the result.
Clock synchronisation is the overlooked precondition. With drifting clocks, correlating several logs into a timeline is impossible — the first wall investigators hit. Synchronise everything via NTP and verify it annually.
Where shared IDs remain, the user ID alone will not identify a person; combine it with operator identification at the terminal. See Access Control and Privileged IDs.
How Long to Keep It
| Purpose | How to think about it |
|---|---|
| Investigation | Must cover the gap between intrusion and discovery — months, ideally |
| Accountability | Long enough to answer patient enquiries and regulator reports |
| Record integrity | Aligned with clinical record retention requirements |
| Fault investigation | Weeks to months usually suffices |
Design from investigation. Discovery often lags intrusion; if the relevant period has already been overwritten, the scope cannot be established — and neither patient communication nor regulatory reporting can proceed without it.
Product defaults frequently fall short, overwriting quickly to save disk. "We collect it" and "we still have it" are different claims.
Decide: retention per log type; storage location (separated from production, and not deletable by a privileged ID); capacity forecasting; treatment of expired logs; and periodic confirmation that collection has not silently stopped after a configuration change or hardware swap.
The storage location matters most. Logs held only on the production server vanish when that server is encrypted. Assume traces will be erased and forward logs elsewhere. See Segmentation and Asset Management.
Statutory retention periods vary by record type. When fixing periods in internal policy, verify against MHLW publications and the applicable laws and notices (primary confirmation required).
Getting Past "Collected but Unread"
Logging becomes theatre for a design reason, not an attitude reason. Nobody can read everything — EMR access logs can run to tens of thousands of entries a day. Review only works alongside a mechanism for narrowing what gets looked at.
| Method | What it is | Feasibility |
|---|---|---|
| Exception extraction | Pull only events that should not normally occur | Straightforward — start here |
| Threshold alerting | Notify when counts or rates exceed a limit | Depends on product features |
| Correlation | Combine multiple sources to judge | Needs dedicated tooling |
Start with exception extraction. Even without dedicated tooling, conditions like these reduce the volume to something a person can handle: administrator logins at night or on holidays; clustered login failures; sudden use of an account dormant for 90 days; permission grants and changes; bulk reads or exports above a threshold; sustained access to records outside one's own department; activity on leavers' IDs; remote access from unusual origins.
These are events that warrant asking why. Most have legitimate explanations — an emergency on a night shift, an export for an audit. What matters is recording that the reason was confirmed.
To make review routine, decide four things: frequency (monthly, with daily automated alerts for the gravest conditions); who does it (IT plus patient safety or health information management); the procedure (extraction conditions, how to verify, where to escalate); and the record (date, volume, findings, escalations).
Spanning departments works well in hospitals, because IT alone cannot judge whether a given access is clinically odd. Health information managers and patient safety staff catch access that is technically normal but operationally implausible.
Figures such as "at least monthly" circulate in secondary commentary but cannot be confirmed as requirements from primary sources. Verify before writing them into policy (primary confirmation required).
The Logs You Actually Need During an Incident
| Question | Logs needed | Check in advance |
|---|---|---|
| When was the intrusion? | Perimeter connection logs, authentication | Is the period still retained? |
| Where did they come from? | VPN and remote access source records | Are source addresses recorded? |
| Which account was used? | Authentication, permission change | Are failures logged too? |
| How far did they reach? | Internal traffic, server logins | Is inter-segment traffic recorded? |
| Did data leave? | Proxy and export logs, removable media | Are output paths logged? |
| Were patient records involved? | Clinical access logs | Can you trace per patient? |
| When can we restore? | Backup job records | Are job outcomes recorded? |
Being unable to answer "did data leave?" is the heaviest failure in practice. Without that, both patient communication and the decision to report to the Personal Information Protection Commission must assume the worst. Output and network logs, which nobody reads on a quiet day, become decisive.
See Breach Reporting Obligations, First Response to Ransomware, Hospital Incident Response Plans, Ransomware Defence for Hospitals, Demarcating Responsibility and ISO/IEC 27001 (ISMS).
With cloud services, most logs sit on the provider's side. Confirm at contract time: which logs exist; what the hospital may view; retention; whether logs will be supplied during an incident, by what process and how quickly; and whether supply is chargeable. See Cloud Security for Medical Institutions and the shared responsibility model.
Connecting to the Requirements
The Electronic Clinical Information Coordination Structure Development Addition sets guideline compliance and a dedicated safety management officer as common requirements, with tier 1 (160 points) adding multi-method backup (part offline) and a cyber BCP with exercises. Logs are the evidence that those things are actually happening:
- Log review and its results sit within the safety management officer's duties
- BCP exercises hinge on being able to scope damage from logs
- Backup job records are the material for explaining recoverability
See the FY2026 revision overview and Appointing a Safety Management Officer.
Conclusion
- Logs serve four purposes — detection, investigation, accountability, record integrity — with different requirements for each
- With limited resources, cover authentication, permissions, privileged actions, clinical access and output first
- Clock synchronisation across all devices is the precondition for traceability
- Design retention from investigation needs; product defaults are frequently insufficient
- Forward logs to storage separated from production, not somewhere a privileged ID can erase
- "Collected but unread" is a design problem: narrow by exception extraction, review across departments, and record the confirmation
- The heaviest failure in an incident is being unable to answer whether data left — secure output and network logs while things are quiet
If you need to assess whether your logging would withstand an investigation, or what to ask a cloud provider, 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
- Personal Information Protection Commission
- On the FY2026 Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
Note: retention and review-frequency requirements are governed by the applicable laws, notices and MHLW publications, and change over time.