The executive has set policy and appointed a manager. The next people to get stuck are the ones who have to do the work. "I've been told to run a risk assessment — where do I start?" "How many procedures am I supposed to write?" "How much documentation is enough?" A great many institutions stall right here.
The planning and management part of Edition 6.0 is written for this layer: system administrators. In a hospital that means the medical informatics or IT function; in a small practice it is usually the administrator wearing another hat.
In one line, this part is the blueprint for a mechanism that makes rules, enforces them, and keeps records. It is about the operating framework rather than the technology itself. How individual devices and accounts are handled belongs to The System Operations Part; the planning part sits one step earlier, covering what gets decided and how.
This article reorders the content into the sequence you would actually work in, and states the minimum that puts you in a position to explain yourself. For how the four parts fit together, see Key Points of Edition 6.0.
Disclaimer: This article is general information. The authoritative sources are the MHLW's published text and Q&A.
Risk Assessment Starts with an Asset Inventory
Risk assessments stall because people begin by trying to "identify risks." With nothing to anchor on, you produce a list of abstract anxieties that lead to no controls.
Work the other way round: start by listing what you are protecting.
| Step | What you do | Output |
|---|---|---|
| ① Inventory assets | List every system, device, medium, and line that handles medical information | Information asset register |
| ② Rate importance | For each asset, what happens if it stops, leaks, or is altered | Importance column in the register |
| ③ Identify threats and weaknesses | What could happen to each asset, and where it is weak | Risk list |
| ④ Evaluate | Prioritise by likelihood × impact | Risk evaluation table |
| ⑤ Decide treatment | Reduce, transfer, avoid, or accept | Risk treatment plan |
Step ① is the foundation. Leave it blank and everything downstream is guesswork. Fill it in and steps ③ onward become almost mechanical.
The register holds more than the EMR server and the client PCs. The commonly missed assets are:
- Online eligibility terminals, billing computers, PACS, and terminals attached to diagnostic equipment
- Networked medical devices (patient monitors, infusion pumps, endoscopy systems)
- VPN appliances, routers, wireless access points — published incident disclosures repeatedly show a known vulnerability at this layer as the entry point
- Backup media and removable media (USB drives, external disks)
- Staff-owned devices — if BYOD is being tolerated, admit it and enter it in the register
- Cloud service accounts — specifically, who holds administrator rights
A register is not a one-off. It must be updated whenever equipment is added, replaced, or disposed of; an unmaintained register diverges from reality within a couple of years. The trick to making it stick is to bind the update to a business step — touch the register at acceptance and at disposal — rather than to an intention.
Whatever you decide to accept at step ⑤ must be recorded as an executive decision. Something a staff member shelved for lack of budget is not acceptance. See The Governance Part.
How Many Procedures Do You Need?
The question that follows "establish your procedures" is always how many. The answer: there is no set number. What is required is not a page count but being able to answer four questions:
- Who may do what, and what is prohibited?
- When someone is unsure, who do they ask?
- When something happens, who is told, and how?
- Where does the record of that live?
If one document answers all four, one document is enough. If it does not, ten will not help.
In practice, a three-layer structure is easiest to maintain.
| Layer | Document | Content | Revision cadence |
|---|---|---|---|
| 1 | Basic policy | The institution's stance on safe management; approved by the executive and presentable externally | Rarely revised |
| 2 | Management procedures | Structure and roles, risk management, supplier management, training, incident response, audit — what is decided | Reviewed annually |
| 3 | Work instructions and manuals | Account issuance, backup steps, removal request forms — how it is done | As needed |
The point of the split is to separate layers by how often they change. If changing a work step requires re-approving a board-level document, documents and reality diverge immediately. Layer 3 should be revisable on the floor.
Small practices do well folding layer 2 into a single "medical information system safety management procedure" with a handful of layer-3 instructions. Large hospitals with department-specific operations need layer 3 split by department. Let the thickness of each layer follow your size and how operations actually differ.
This three-layer shape is close to the documentation structure of a vendor certified to ISO/IEC 27001, which makes it a useful shared vocabulary in vendor discussions. See What Is an ISMS (ISO/IEC 27001)?.
Supplier Management: Contract, Then Verify
Healthcare information systems are almost always dependent on outside parties — EMR vendors, maintenance contractors, cloud providers, network carriers, sometimes billing services. What this part asks for is two-stage: settle it in the contract, verify it in operation.
Settle in the contract
| Item | What to write |
|---|---|
| Responsibility boundary | Where the vendor's duties end and yours begin — separately for backups, patching, monitoring, and log retention |
| Subcontracting | Whether it is permitted, whether prior consent is required, duties over subcontractors |
| Incidents | Contact point, notification deadline, and content of reports when the vendor suffers an incident |
| Audit and reporting | How you can verify — periodic reports, acceptance of audit, provision of third-party certification |
| Termination | How data is returned or destroyed, and how that is evidenced |
| Declared compliance | Compliance with the METI/MIC guidelines |
Verify in operation
A clause is not management. Roughly annually, confirm:
- Whether the premises of the responsibility boundary have changed (service specification or cloud architecture changes)
- Whether the vendor has had incidents
- Whether third-party certification is still valid — and whether its scope covers the service you actually use
- Whether the named contacts have changed
Point 3 hides a trap: the certification scope often does not include the specific service you consume. When you take a copy of the certificate, read the scope statement.
See Security Check Sheets for Vendors, Demarcating Responsibility, and Cloud Security for Healthcare Institutions.
Because FY2026 made guideline compliance and a dedicated security manager conditions of the new add-on, supplier management is now also something you may need to evidence when filing. See FY2026 Fee Revision: Cross-Specialty Changes.
Design Training Around Completion Rates
Training is the part that most easily becomes a formality. A record says "annual training delivered to all staff," while in fact nobody knows who did not attend.
Decide the operating pattern before the content.
| Decision | The workable choice |
|---|---|
| Who | Permanent, part-time, agency, and on-site contractor staff (as a rule, include them) |
| How | Classroom-only misses shift workers; materials plus a confirmation quiz works better |
| Records | Per person, who completed and when. Treat "we can identify who has not completed" as the requirement |
| Follow-up | Who chases, and by when it must be closed |
| Refresh | Fold in recent incident patterns and near-misses from your own institution |
Figures such as "at least twice a year" circulate in secondary sources for frequency but could not be confirmed against primary material (verify against the primary text).
On content, what changes behaviour is the situations where staff actually have to judge, not a reading of the procedure:
- An email with an attachment arrives under a vendor's name, but from an unfamiliar sender address
- A patient asks to see a family member's test results
- A colleague asks you to let them enter data under your ID
- Someone wants to take data out on a USB drive for a conference presentation
- A physician asks to view the EMR from outside the building
These are operational rather than technical questions, and what matters is less whether the rule is written down than whether everyone knows who to ask when unsure. Pairing this with practical exercises such as phishing drills makes it stick.
How Much Documentation Is Enough?
The hardest judgement in this part is scope of documentation. Overbuild and you cannot maintain it; underbuild and you cannot explain yourself.
There is a single test: can you explain to a third party what you decided and how you operate? That is what is asked at filing, at audit, and after an incident alike.
Seven items are the minimum that puts you in that position.
| # | Document or record | Why it is needed |
|---|---|---|
| 1 | Information asset register | The starting point — without it nothing else can be explained |
| 2 | Risk evaluation table and treatment plan | What you judged dangerous and what you decided to do |
| 3 | List of untreated risks with acceptance record | Shows that inaction was a decision |
| 4 | Safety management procedure | The rules on who may do what |
| 5 | Organisation chart and appointment record | Identifies the manager — directly relevant to the add-on |
| 6 | Per-person training records | Evidence that the rules were communicated |
| 7 | Supplier list with contracts and verification records | Evidence that suppliers are managed |
Conversely, mass-producing work instructions before these seven exist does not improve your ability to explain anything. A workable order of attack is 1 → 5 → 4 → 2 → 3 → 7 → 6.
For how far a small practice can compress this, see Guideline Compliance for Small Clinics; for the operational content, The System Operations Part; for appointment, The Medical Information Security Manager. See also Practical Steps for Three-Ministry Guideline Compliance and The Three Ministries' Two Guidelines Explained.
The MHLW's cybersecurity checklist and manual for healthcare institutions, published on 14 May 2025, is a useful instrument for establishing where you stand — it now covers cloud environments, BCP, IoT, and BYOD, which also makes it a good cross-check against gaps in your asset register.
Conclusion
- Start risk assessment from the asset register, not from imagining risks
- The assets most often missed: networked medical devices, VPN appliances and wireless APs, removable media, and cloud administrator accounts
- There is no required number of procedures. Three layers — policy, management procedures, work instructions — split by revision cadence are easiest to maintain
- Supplier management is contract plus verification. Check certification scope, not just validity
- Design training's operating pattern before its content. Treat identifying non-completers as the requirement
- The documentation test is "can you explain it to a third party." Seven items get you there
Building the register and running the assessment are things an institution can do in-house once the pattern is set. If you would like help establishing that pattern, or prioritising documentation ahead of filing for the add-on, get in touch. Where a vendor needs to evidence its own posture, we also offer ISMS certification support.
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)
- Personal Information Protection Commission
Note: the guidelines are revised and their interpretation clarified through official Q&A. This article reflects material published at the time of writing.