"Compliant with the three-ministry guidelines." There is no year in which that sentence fails to appear in a proposal for a medical information system. Yet surprisingly few vendors can explain what exactly the sentence asserts — and surprisingly few hospitals ask.
The framework consists of two documents, as the name suggests. One, from the Ministry of Health, Labour and Welfare (MHLW), addresses medical institutions. The other, issued jointly by the Ministry of Economy, Trade and Industry (METI) and the Ministry of Internal Affairs and Communications (MIC), addresses service providers. When a vendor claims compliance, the document they mean is the second one. Knowing what it demands is what lets you test the claim.
This article sets out, in practical terms, what the provider-side guideline requires — usable by providers as a self-check, and by hospitals as a lens for evaluating the vendors they are about to depend on.
Disclaimer: This article is general information. The authoritative texts are the guidelines published by MHLW, METI, and MIC themselves. Guidelines are revised; base practical decisions on the current primary sources.
What the "Two" Refers To
| Document | Ministry | Addressed to | Core question |
|---|---|---|---|
| Guidelines for the Safe Management of Medical Information Systems | MHLW | Medical institutions | As custodian of patient data, what must you manage? |
| Safety Management Guidelines for Providers of Information Systems and Services Handling Medical Information | METI and MIC (jointly) | Service providers | As a party entrusted with that data, what must you guarantee? |
Three ministries, two guidelines. You may still encounter the older label "three ministries, four guidelines"; today METI and MIC maintain a single joint document (consult each ministry's own publications for the history of the naming).
The point that matters is that the two documents describe the same situation from opposite sides. The hospital-side guideline says "manage your suppliers appropriately"; the provider-side guideline says "explain yourself to, and give assurances to, the institution that engaged you." Only when the two mesh does a single coherent information-management arrangement exist. Read only one and the boundary of responsibility stays invisible.
For the MHLW side, see The Three Ministries' Two Guidelines Explained and Implementation Steps for Compliance.
Six Pillars of What Providers Must Do
Reorganized around the question "what must a provider have ready" — rather than around the document's own structure — the requirements fall into six pillars.
| Pillar | What the provider must do | What a hospital should ask to see |
|---|---|---|
| ① Organizational governance | Executive involvement, an appointed officer, procedures and training | Organization chart, named officer, training records |
| ② Demarcation of responsibility | A documented definition of where the provider's duty ends | Responsibility matrix, SLA, the relevant contract clauses |
| ③ Risk management | Assess the risks of the service, decide treatments, operate them | Whether risk assessment happens, and how often |
| ④ Subcontractor management | Control extending to the IaaS, maintenance, and data-centre providers they themselves use | List of subcontractors, rules on further subcontracting |
| ⑤ Continuity and end-of-service | Continuity under failure, disaster, or attack; return and deletion of data at termination | BCP, data return format, certificate of deletion |
| ⑥ Disclosure to the institution | Supply the information the hospital needs to meet its own obligations | Compliance statement, audit rights, scope of log disclosure |
Of these, ⑥ is where vendors differ most in hospital eyes. A provider may do ①–⑤ well, but if it cannot explain itself at the granularity the hospital needs, the hospital cannot evidence its own compliance. The disclosure duty exists precisely because the hospital-side guideline demands supplier oversight.
Testing the compliance claim
"Compliant with the three-ministry guidelines" carries no verifiable content on its own — no third-party certification attests to it — so the hospital has to ask for the artifacts in the table above.
The productive question is not "are you compliant?" but "can you produce the evidence?" Nearly every vendor answers yes to the first. The second separates them. See Questions to Ask a Vendor and Security Check Sheets for Vendors.
Converting It into a Buyer's Lens
For a hospital, the provider guideline is "a rule that applies to the other party." Read differently, it is an evaluation framework: what the guideline asks of providers is exactly what a hospital should verify.
- Is there a written demarcation of responsibility? Without it, nothing else stands. Ambiguity here guarantees a dispute during an incident. See Demarcating Responsibility
- Is the subcontracting structure disclosed? In cloud services the actual storage usually sits with an IaaS provider. Can you see that far?
- Is termination settled? Barely discussed at signing; a problem at exit
- Will they accept your audit? If not, is there a substitute — a third-party audit report, for instance?
- Are incident-notification terms concrete? "Promptly" is not operable. What, to whom, within how many hours?
Items 1 and 5 directly determine whether the hospital's own compliance work can be completed. A weak vendor leaves the hospital unable to close the loop no matter how much it does internally.
The relationship with ISMS and other certifications
Where a provider holds ISO/IEC 27001 certification, much of pillars ①, ③, and ④ is likely already in place: the standard requires governance, risk assessment, and supplier management.
But ISMS certification does not evidence compliance with the three-ministry guidelines. Its scope may be narrow, and healthcare-specific requirements — the three principles of electronic storage, explicit demarcation — sit outside what ISO/IEC 27001 covers. Treat certification as a signal that foundations exist, then verify the healthcare-specific points separately.
From the provider's side, see What Is an ISMS (ISO/IEC 27001)? and ISMS as a Procurement Requirement.
Where the Requirements Land in Contracts
Requirements only function once they sit in a contract, SLA, terms of service, or specification. Verbal assurances and proposal text are weak ground during an incident.
| Requirement | Where it lands | How to write it |
|---|---|---|
| Demarcation | Contract or annex | A table classifying each domain as hospital / provider / joint |
| Availability and recovery | SLA | RTO and RPO as numbers, plus what happens on a miss |
| Incident notification | Contract or SLA | Defined trigger events, recipients, and a deadline |
| Subcontracting | Contract | Prior consent or notification; duty to supply the list |
| Return and deletion of data | Contract | Format, deadline, certificate of deletion |
| Audit and reporting | Contract | On-site audit rights, or the substitute report and its frequency |
See Writing SLAs and Responsibility Boundaries and Putting Security into Procurement Requirements.
Note also that the electronic clinical-information coordination system enhancement addition, newly established in the FY2026 fee revision, includes compliance with the MHLW guidelines and the appointment of a dedicated medical information system safety management officer among its requirements. Guideline compliance has moved from "advisable" to a condition of claiming a fee. Vendor selection now bears on reimbursement. See The FY2026 Fee Revision.
Conclusion
- The "two" splits as MHLW for institutions, METI/MIC for providers
- Provider requirements reduce to six pillars: governance, demarcation, risk management, subcontractor management, continuity and termination, and disclosure
- Disclosure is where vendors differ most — not whether they do it, but whether they can show it
- A compliance claim carries no verifiable content. Ask for the evidence instead
- ISMS certification is a foundation signal, not proof of guideline compliance
- Requirements work only once contracted. Demarcation, notification terms, subcontracting, and data return are the irreducible four
If you need help building vendor-evaluation criteria or reviewing existing contracts, contact us. Providers building out their own posture may also find ISMS Certification Support useful.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Version 6.0 full text (PDF) | MHLW
- Ministry of Economy, Trade and Industry
- Ministry of Internal Affairs and Communications
- Personal Information Protection Commission
Note: version numbers, revision dates, and the detail of requirements are governed by each ministry's own publications. Guidelines and their interpretation are subject to revision; always confirm against current primary sources.