"The systems are handled by our administrator and the vendor." Read the public disclosures of institutions hit by ransomware and this state of affairs keeps appearing in the background. Nobody was lying. Everyone was doing their job honestly. It is just that no one had decided how much risk the institution as a whole would accept.
The governance part of Edition 6.0 of the MHLW's Guidelines for the Safe Management of Medical Information Systems addresses exactly that state. Up to Edition 5.2, board-level decisions and technical specifications sat in one document; Edition 6.0 splits the material into four parts by reader, and the part for executives now stands alone. This is not an editorial convenience — it is a deliberate location of responsibility.
The FY2026 fee revision then made compliance with the guidelines, and the appointment of a dedicated medical information system security manager, conditions of the new electronic clinical information coordination add-on. What only executives can decide has become directly tied to revenue.
This article sets out what directors, board members, and administrators should take from the governance part. 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, notices, and Q&A. Base filing decisions on those and on confirmation from your Regional Bureau of Health and Welfare.
What the Governance Part Asks of Executives
The structure is the same as any corporate management system: set policy, put a structure in place, allocate resources, receive reports, and review. Healthcare has its particularities, but the categories of executive work do not change.
| Executive duty | What it means in practice | Delegable? |
|---|---|---|
| Setting policy | Establish and communicate a basic policy for safe management of medical information | No — approval is an executive act |
| Establishing structure | Appoint the security manager; define authority and reporting lines | No — appointment is an executive act |
| Allocating resources | Assign budget, people, and time; set priorities | No |
| Accepting risk | Own, as the institution, the risks you decide not to treat | No |
| Reviewing | Receive reports periodically; revisit policy, structure, and investment | No (preparation may be delegated) |
The right-hand column reads "no" throughout by design. Preparation and execution can be delegated; deciding cannot. Signing off is itself the executive act, and what you sign, you answer for.
The fourth row is the one most often missed. Security work does not aim to reduce every risk to zero — budget and staffing are finite, so some risks will always be left untreated. The problem is when that outcome belongs to nobody's decision. A staff member shelving something because no budget was granted is not the institution accepting the risk. If you accept it, record that you accepted it. That is what the governance part asks.
Outsourcing Does Not Transfer Responsibility
The most common question from institutions is: "Our EMR vendor complies with the three-ministry guidelines — isn't that enough?"
It is not.
The structure is a division of labour: the MHLW guidelines address the institution, the METI/MIC guidelines address the vendor. A vendor's compliance means the vendor is discharging its own duties — it does not move the institution's responsibility onto them. Accountability for patient data stays with the institution throughout.
In practice, three things belong on the executive's checklist.
- Is the boundary between vendor responsibility and institutional responsibility written down?
- For your own side of that boundary, can you say who actually does what?
- Do you have a means of confirming the vendor is discharging its side (reports, audits, certification)?
Point 1 is frequently left vague. "Backups are the vendor's job, presumably." "The access rights review is ours, presumably." That presumably is where incidents begin. See Demarcating Responsibility Between Institution and Vendor, Cloud Security for Healthcare Institutions, and The Shared Responsibility Model.
On point 3, ISMS (ISO/IEC 27001) certification is the mechanism by which a vendor evidences its security posture to a third party. For what to look at as the buyer, see What Is an ISMS (ISO/IEC 27001)?.
What "Dedicated" Means in the New Requirement
The FY2026 add-on merged the medical information acquisition add-on and the healthcare DX promotion structure add-on, and absorbed the cybersecurity requirements previously attached to medical records management structure add-on 1. For the shape of the revision as a whole, see FY2026 Fee Revision: Cross-Specialty Changes.
For the inpatient tiers:
| Tier | Points | Requirements |
|---|---|---|
| Tier 1 | 160 | Common requirements + multi-method backups (some offline) + a cyberattack BCP with drills |
| Tier 2 | 80 | Common requirements only |
The common requirements are compliance with the guidelines and a dedicated medical information system security manager.
The weight for executives sits in the word dedicated. Most institutions have until now had an administrator or IT lead acting as de facto manager alongside other duties. Requiring dedication means carving that person's time out of everything else — a staffing decision the floor cannot make.
Three questions for the board:
- Who: appoint internally or hire? Which matters more here, medical informatics knowledge or the standing to move people internally?
- What is given up: if the role is dedicated, who absorbs that person's current work?
- What authority: when the manager demands remediation, does the structure make that stick?
The third is the most neglected. Hand over responsibility without authority and you have created someone who writes reports. Appointment, whether the role may be combined, and how qualifications are treated are covered in The Medical Information Security Manager: Role and Appointment.
Specific qualification requirements and transitional deadlines circulate in secondary sources but could not be confirmed against primary material here (verify against the primary text).
What Executives Should Receive, and How Often
Making the "review" duty work requires deciding in advance what gets reported. Without a fixed format, what reaches the board is a single line saying there are no problems.
At minimum, receive the following periodically (once or twice a year, plus on incident):
| Report item | What to look for |
|---|---|
| Risk assessment results | What changed since last time; what risks are new |
| List of untreated risks, with reasons | The item requiring an executive decision. This is the core |
| Incidents and near-misses | A nil return deserves suspicion — reporting lines may not be working |
| Backup status and restore-test results | Not "we take backups" but "we confirmed we can restore" |
| Access rights review | Are accounts of leavers and transferees still active? |
| Training and drills | Completion rates — and whether you know who has not completed |
| Vendor status | Contract renewals, changes to the responsibility boundary, vendor-side incidents |
Of these, the list of untreated risks matters most from a governance standpoint. Everything else confirms whether something is being done; this one cannot move without an executive decision.
You do not need a new committee. A standing item on an existing management meeting is enough. What matters is that it lands in the minutes: a record that the report was received and the approach approved is the evidence that the structure functions.
The First Ninety Days
Trying to set policy and build structure at once stalls. In order:
- Establish where you stand (by day 30). Have your staff complete the MHLW's cybersecurity checklist for healthcare institutions, published on 14 May 2025. This is the first time you will see, in one list, what is and is not in place
- Appoint the manager (by day 60). Put the appointment, authority, reporting line, and the duties being lifted in writing. If you are targeting the add-on, decide the "dedicated" question here
- Decide which risks you accept (by day 90). Sort the gaps from the checklist into "this period," "next period," and "not treating (accepted)." Minute the decision
With those three done, you are in a position to start the operational work covered in The Planning and Management Part and The System Operations Part. Smaller practices should see Guideline Compliance for Small Clinics. For the overall route, see Practical Steps for Three-Ministry Guideline Compliance and The Three Ministries' Two Guidelines Explained.
Conclusion
- The governance part locates policy, structure, resources, risk acceptance, and review with the executive. Preparation is delegable; deciding is not
- Outsourcing does not transfer responsibility. Vendor compliance is a precondition, not a defence
- Confirm the responsibility boundary is written down. Anything running on "presumably" is where incidents start
- FY2026 made a dedicated security manager a condition of the add-on — and only the board can make a staffing decision
- Give the manager authority to force remediation, not responsibility alone
- Fix the reporting format. The list of untreated risks is the item that exists for the board to decide on
Building a security structure is less about specialist knowledge than about designing who decides what. If you would like to talk through how to assemble it, or how to prioritise ahead of filing for the add-on, get in touch.
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
- Personal Information Protection Commission
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: the guidelines are revised and fee-schedule requirements are clarified through official Q&A. This article reflects material published at the time of writing.