The most common mistake among suppliers to hospitals in Japan is running ISMS certification and three-ministry guideline compliance as two separate projects.
The outcome is predictable. Two sets of procedures, two risk registers, two supplier evaluation sheets. Staff record the same thing twice, one copy stops being updated, and within a year nobody can say which document is authoritative.
There is no need for this. An ISMS provides the mechanism for operating information security; the three-ministry guidelines say what to attend to in this particular field. Build the second on top of the first and the document count drops sharply.
This article sets out the structure of the guidelines, maps them onto ISMS documents, and shows how to derive hospital-facing material from the same source.
Disclaimer: General information only. Interpretation of the guidelines is governed by MHLW, METI, and MIC publications; the standard, by the standard and the accreditation and certification bodies. Confirm the scope of your obligations with your customers and with specialists.
Why Duplication Happens
1. The two start at different moments. ISMS begins because a customer made it a condition of trade; guideline work begins because one specific hospital asked during a deal. Different owners, different external support, two self-contained document sets.
2. "Compliant" has no fixed test. ISMS has certification as a clear finish line. The guidelines have no certification scheme, so "how far is far enough" stays ambiguous — and the default behaviour becomes writing a new document every time a hospital asks something.
3. The readers differ. ISMS documents are read by auditors and your own staff; guideline material is read by hospital staff. It looks reasonable to conclude that different readers need different documents. But if the content is the same, one source of truth with a different presentation is enough.
The third point is the key to integration. Whether you can achieve one source, many outputs determines your ongoing operational load.
How the Guidelines Split
"Three-ministry guidelines" is shorthand for two document families.
| Name | Ministry | Addressed to |
|---|---|---|
| Guidelines for the Safe Management of Medical Information Systems | MHLW | Healthcare providers — hospitals, clinics, pharmacies |
| Safety management guidelines for providers of information systems and services handling medical information | METI and MIC | Suppliers of systems and services |
Read it as hospitals = MHLW, suppliers = METI/MIC. A supplier faces the METI/MIC document directly — but without knowing what your hospital customers are required to do under the MHLW document, your explanatory material misses the mark.
The MHLW guidelines are currently at version 6.0 (revised May 2023), in four books:
| Book | Intended reader |
|---|---|
| Overview | Anyone needing the whole picture |
| Governance | Hospital decision-makers and executives |
| Planning and management | System administrators |
| System operation | Those actually running the systems |
They apply to "everyone involved in the introduction, operation, use, maintenance and disposal of any medical information system," regardless of size or type of institution. MHLW published a Q&A on version 6.0 in May 2025, and on 14 May 2025 released a cybersecurity checklist for healthcare institutions and its manual, adding coverage of cloud environments, BCP, IoT, and BYOD.
What matters to a supplier is that hospitals now hold that checklist. Working through their own status, they pass questions down to you. Preparing your material so it answers the checklist's items turns the exchange into a single round trip. See The Three-Ministry Guidelines and Implementation Steps.
Mapping ISMS Documents onto Supplier Requirements
| Topic expected of suppliers | ISMS document that carries it | What to add |
|---|---|---|
| Stated policy on handling medical information | Information security policy | An external-facing statement naming medical information |
| Executive involvement and accountability | Organisation chart, management review minutes | A one-page structure briefing for hospitals |
| Identifying the medical information handled | Asset inventory | Add medical classification criteria |
| Risk identification and treatment | Risk assessment, risk treatment plan | Add field-specific impacts: care stoppage, patient harm |
| Technical security measures | SoA and operating procedures | Add a guideline-mapping column to the SoA |
| Clear demarcation of responsibility | Contracts, operating procedures | A demarcation table: hospital / supplier / cloud provider |
| Managing subcontractors | Supplier management procedure, evaluations | A disclosable list extending to sub-subcontractors |
| Data location, governing law, jurisdiction | Asset inventory, contracts | A location list: production, backup, logs, monitoring |
| Access control and authentication | Access control procedure, rights register | Reusable as-is |
| Logging and audit trails | Log management procedure, records | State retention and whether logs can be provided |
| Availability and continuity | Continuity and backup procedures | State RTO and RPO; keep drill records |
| Incident response and notifying hospitals | Incident procedure | Add the notification route and time commitment |
| Staff training | Training plan and records | Add a session on handling medical information |
| Data return and disposal at contract end | Disposal procedure | Specify format, deadline, and proof in contract and procedure |
| Explanation and disclosure to hospitals | (no direct ISMS counterpart) | The disclosure pack — covered below |
Most topics are already carried by ISMS documents; what is needed is either a single added column or an output aimed at hospitals. Only the disclosure pack must be built from scratch.
The highest-leverage move is adding a guideline-mapping column to the Statement of Applicability. The SoA already records inclusion, exclusion, and justification for all 93 controls; one more column naming the guideline topic each control answers lets one table explain both the standard and the sector requirement. See Writing the Statement of Applicability and Annex A 2022.
Document Design That Avoids Duplication
Principle 1: one source of truth, derived outputs. Never write the same content twice. The risk register is authoritative for risk; the operating procedure is authoritative for demarcation. Mark every derived document with the source it is based on so revisions propagate.
Principle 2: do not create a separate guideline document set. Almost everything can be an addition to an existing procedure. Genuinely new documents are roughly three:
- Medical information handling policy (external-facing)
- Responsibility demarcation table (hospital / supplier / cloud provider)
- Guideline mapping table (the table above serves directly)
Principle 3: one trigger for updates. Fold guideline review into ISMS management review and internal audit. Guideline revisions, new hospital demands, incidents — route them through the ISMS corrective action and continual improvement process rather than maintaining a second review cycle.
See ISMS Documentation: How Much to Build. Companies handling SaMD or clinical trial systems layer QMS and ER/ES documents on top of the same shared-layer pattern — see SaMD, ISMS and QMS and ISMS for Clinical Trial Systems. For tenant separation, see ISMS for Healthcare SaaS.
Deriving Hospital-Facing Material
Hospital demands arrive as security check sheets in a different format from each customer, compliance briefings, demarcation confirmations, implementation meetings and minutes, and audit requests. Handling each individually makes effort scale with contract count. The workable answer is a standard pack derived from ISMS documents.
| Deliverable | ISMS source | Typical size |
|---|---|---|
| ① Certificate and scope note | Scope definition | 1 page |
| ② Security overview | SoA, operating procedures, risk treatment plan | 10–20 pages |
| ③ Guideline mapping table | The SoA's mapping column | 1–3 pages |
| ④ Responsibility demarcation table | Operating procedures, contracts | 1–2 pages |
| ⑤ Standard check sheet answers | ② ③ ④ converted into Q&A form | Varies |
② is the centre of gravity. Separation model, encryption, access control, logging, backup with RTO and RPO, incident response and notification route, data location, subcontractors — everything hospitals ask, in one document. With it in hand, a large share of any check sheet is answered by a page reference.
Do not underrate ①. Hospitals read the registered scope on the certificate; if operation and maintenance are not in it, questions follow. Anticipate this when designing scope (Designing ISMS Scope for a Healthcare Company).
Minutes from implementation meetings pay off later. Hospitals need a record of what the supplier explained. Recording what was said and what demarcation both sides agreed makes post-incident sorting far easier. For the buyer's view, see Security Check Sheets for Vendors and Demarcating Responsibility.
Conclusion
- Duplication comes from different start points, an undefined bar for "compliant", and different readers. Different readers do not require different sources — one source, many outputs
- Read the guidelines as hospitals = MHLW (version 6.0, four books), suppliers = METI/MIC; without knowing the hospital's obligations, your material misses
- Most supplier topics are already carried by ISMS documents — add a column, or add an output
- Adding a guideline-mapping column to the SoA is the highest-leverage step: one table explains both
- Genuinely new documents number about three — handling policy, demarcation table, mapping table. Fold review into management review and internal audit
- Serve hospitals with a five-part standard pack centred on the security overview, and make sure operation and maintenance appear in registered scope
Pottech offers integration of ISMS documentation with three-ministry guideline material as an option (from ¥1.5M). We keep the new document count to a minimum, link required technical measures back to the ISMS, and support implementation discussions with hospitals, including minutes, disclosure documents, and risk treatment lists. Typical duration is about four months from kick-off.
See ISMS Certification Support or contact us. The overall picture is in What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines version 6.0 (PDF) | MHLW
- Ministry of Economy, Trade and Industry
- Ministry of Internal Affairs and Communications
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
Note: the guidelines are revised over time, and the required depth of compliance varies with the nature of your service and your customers' judgement. Check the ministries' publications for current content.