Japan's Medical Information System Safety Management Guidelines v7.0: what the text actually says about cloud and AI

Hello, this is Ryuta Hamamoto from TIMEWELL.

Japan's Ministry of Health, Labour and Welfare has moved its Guidelines for the Safety Management of Medical Information Systems (医療情報システムの安全管理に関するガイドライン) to version 7.0. It was issued on 29 June 2026 (Reiwa 8) under notification number Sanjohatsu 0629 No. 1 (産情発0629第1号), addressed to prefectural governors, mayors of cities operating public health centres, and heads of special wards. The signatory is the Councillor for Pharmaceutical Industry Promotion and Medical Information in the Minister's Secretariat¹.

I am writing this mainly for people who sell into Japanese hospitals from outside Japan. If you build an electronic medical record system or a clinical SaaS product, this document is the one your prospect's IT committee will hold up when they ask where the data sits and who patches the servers. It is not a statute, and nobody is going to fine you for breaching it. It is, in practice, the thing that decides whether procurement moves forward.

Two claims about it come up again and again. The first is that medical information must be stored inside Japan. The second is that the new version says something about AI. I could not find either one in the text.

So I extracted all five volumes, 169 pages, as plain text and searched them mechanically. "Japan domestic" (日本国内), "cross-border" (越境), and "data sovereignty" (データ主権) all returned zero hits. "Generative AI" (生成AI), "artificial intelligence" (人工知能), "machine learning" (機械学習), and "large language model" (大規模言語モデル) also returned zero. What follows is a record of reading the five volumes side by side with the notification and with version 6.0. Every page number below is one I opened and checked myself.

While you are working through a document like this, it helps to know where your own AI adoption currently stands, because that shapes how much of the guideline you actually have to argue about internally. If you want a quick read on your position, there is a free AI readiness assessment.

Decide which volume you are actually the reader of

Version 7.0 comes in five volumes. The Overview volume (概説編) runs 11 pages, the Executive Management volume (経営管理編) 21 pages, the Planning and Management volume (企画管理編) 59 pages, the System Operation volume (システム運用編) 51 pages, and the newly added Maintenance Contractor volume (保守委託機関編) 27 pages. That comes to 169 pages in total².

If you have been tracking this document since version 6.0, the first thing that will confuse you is pinning down which version you are holding. Open the ministry's landing page and the dates attached to the download links do not line up across the volumes. The Overview, Executive Management, and System Operation volumes are dated June 2026 (令和8年6月). The Planning and Management volume alone says May 2026 (令和8年5月). The Maintenance Contractor volume carries no date at all, only a file name and a file size. The PDF cover pages do not print a date either, so the only way I could establish that all five were published together was that every file has a modification timestamp of 29 June 2026. If you are going to cite the version inside an internal policy, or inside a response to a hospital's security questionnaire, I would anchor on the notification date rather than on the date printed against any single volume.

Section 1 of the notification, "Overview of the revision", sorts the changes into three groups¹. The first is the restructuring of the document, which is where the new Maintenance Contractor volume sits. The second covers institutional developments: the addition of the Basic Act on Cybersecurity to the list of related laws, new text on supply chain risk, alignment with the revision of the guidelines aimed at service providers, and the promotion of active use of cloud services. The third covers technical and social developments, and lists passwords, two-factor authentication, and the deemed-compliance route created by the Maintenance Contractor volume. Those three groups are the whole shape of this revision.

On the addition of the Basic Act on Cybersecurity (サイバーセキュリティ基本法, Act No. 104 of 2014, promulgated 12 November 2014), the text sits in section 4.3 of the Overview volume, printed page 6³⁴. The stated reason is alignment with the revision of the Guideline for the Formulation of Safety Standards for Critical Infrastructure Cybersecurity (重要インフラのサイバーセキュリティに係る安全基準等策定指針, decided by the Cybersecurity Strategic Headquarters on 4 July 2023). The same section attaches a caveat, which is worth reading twice: the set of critical infrastructure operators covered by that Act and the scope of these guidelines are not the same set. A hospital does not become a critical infrastructure operator automatically because this guideline now cites the Act.

The way the volumes are split maps directly onto internal roles. Presenting to a board, you want the Executive Management volume. Specifying or procuring a system, the Planning and Management volume. Running access control and day-to-day operations, the System Operation volume. Nobody has to read 169 pages front to back. Working out which volume applies to you before you start reading is faster, and it is the part that most teams skip.

The Maintenance Contractor volume is a landing spot for facilities running SaaS electronic medical records

The most structural change in this revision is the new Maintenance Contractor volume. Section 3.1.5 of the Overview volume says, in substance, that a medical institution which has fully outsourced security updates for all of its servers to a service provider is deemed to have complied with the guidelines as a whole if it complies with the Overview volume and the Maintenance Contractor volume³.

The arithmetic makes the effect obvious. Instead of five volumes and 169 pages, you are looking at 11 pages plus 27 pages, so 38 pages. The 110 pages of the Planning and Management and System Operation volumes drop out. For a clinic or a small hospital with no dedicated systems staff, that is not a small difference.

The text is explicit about who it has in mind. The Overview volume says the route is aimed at smaller medical institutions with no dedicated systems staff, and then adds that it envisages those institutions actively adopting cloud services, SaaS-type systems in particular, so that maintenance can be outsourced without negotiating a bespoke contract. Read plainly, this volume was written to accommodate facilities running a cloud electronic medical record on the vendor's standard terms of service, exactly as supplied.

There is a condition attached to the deemed-compliance route, and it is a contractual one. The footnote to Figure 1 on printed page 2 of the Maintenance Contractor volume says that "YES" can be selected only where the provider's responsibility for security updates is stated in the contract, in the standard terms of service, in an SLA, or similar⁵. It then adds: "Where this is unclear, always confirm directly with the contracted provider and clarify where responsibility lies." The test is not what happens in practice. It is what the paperwork says.

That sentence is not somebody else's problem if you are the vendor. How your terms of service or your SLA describes responsibility for security updates changes the reading your customer has to do by 110 pages. If you sell clinical SaaS in Japan, I would work out which clause of your contract you are going to point at when that footnote comes up, and I would do it before the sales deck rather than after the question arrives. In my experience this is the sort of thing that gets located under time pressure, halfway through a procurement review.

A thin volume does not mean the storage requirement goes away, though. Item 3 of section 5 of the same volume, "Personnel management for safety management", carries the domestic law requirement I discuss below as a checkbox item, sitting there in full⁵.

Nowhere does it say "store it in Japan"

This is the clause where the text diverged most sharply from what I expected going in.

The provision is the final item under compliance requirement 5, Chapter 7 of the Planning and Management volume. Printed page 26, which is page 32 of the PDF. In translation it reads: "Ensure that the information equipment and the like storing the retained information is within the scope of the application and enforcement of domestic law."⁶

Notice that the requirement is framed around the reach of law, not around geography. The equivalent line in version 6.0 read: "Confirm that the information equipment and the like storing the retained information is subject to domestic law."⁷ Version 7.0 adds "and enforcement" to "application", and changes "confirm" to "ensure". The direction of travel is that being able to say on paper that Japanese law applies is no longer enough, and you are expected to look at whether enforcement can actually reach the equipment. No geographic requirement was introduced. The bar did move up.

To check myself, I ran a mechanical search across roughly 500,000 characters of concatenated text from the five volumes. "Japan domestic" returned zero. "Stored in Japan" returned zero. "Cross-border" returned zero. "Data sovereignty" returned zero. The location-related terms that do appear are "domestic law" (国内法) three times, "foreign law" (国外法) once, and "region, country" (地域、国) once⁸. The search covers the text layer of the PDFs, so any characters baked into a figure as an image are outside it. That is a limit of the method, and I would rather state it than leave it implied.

That does not mean location is irrelevant. Printed page 27 of the Planning and Management volume lists items to confirm about an outsourcing partner, and item h is "the location (region, country) where the information equipment storing medical information is installed", with item i being "the possibility that foreign law applies to the outsourcing provider"⁶. These are confirmation items rather than prohibitions, and they are word for word identical to version 6.0. Section 5.2.2 of the Executive Management volume, on organisational management, takes the same posture on the use of an overseas provider as a subcontractor, asking for attention to the requirements of the Act on the Protection of Personal Information and related law rather than forbidding it⁹.

The shape of this becomes clearer when you set it against another Japanese government document. The Digital Agency's Basic Policy on the Appropriate Use of Cloud Services in Government Information Systems (DS-310, decided by the Steering Committee of the Digital Society Promotion Council on 27 May 2025) takes it as the baseline that data centres are located in Japan, and where they are located overseas it asks for confirmation of governing law and international jurisdiction¹⁰. Government procurement makes geography the default rule. The health ministry's guidelines decline to make geography the test at all and write the requirement around the reach of law instead. The word "domestic" carries a different demand in each case. I covered the cloud infrastructure side of this question separately, in running LLMs in Japanese regions.

What I find genuinely interesting is that the ministry itself has acknowledged this clause sits awkwardly. Material submitted to the Working Group on the Utilisation of Medical and Related Information on 29 May 2026 lists, among the items carried over after the public comment round, the possibility that the regulation concerning enforcement of domestic law does not match operational reality, and gives cancer gene panel testing as a concrete example of a field where overseas storage is already the norm¹¹. It is flagged for continued discussion toward version 7.1. If you are deciding on an architecture right now, I would design on the assumption that this clause can move.

Cloud use is something the ministry now says it will actively promote

The mirror image of the storage question is how cloud is positioned. The revision summary in the notification includes, among the institutional developments, the single line: "Added text to the effect that active use of cloud services will be promoted."¹ For an administrative document, that is a fairly forward statement.

The body text holds the same posture. Section 4.7 of the Overview volume, on external storage of medical information, states on printed page 8 that outsourcing safety management to a provider through appropriate use of cloud services is desirable³. For a facility that cannot staff a full-time operations role, the judgement is that outsourcing is safer than keeping servers in the building. The framing of cloud as the exceptional choice is no longer present in version 7.0.

The criteria for selecting a provider were updated as well. The list of certifications and equivalents on printed page 27 of the Planning and Management volume differs from version 6.0 in four places. ISMAP now carries the exclusion "ISMAP-LIU not included", and FedRAMP carries "LI-SaaS not included". The "Evaluation of Cloud Services Related to Medical Information Provided by Private Operators" run by the Health, Medical and Welfare Information Security Management Conformity Assessment Association was added as an option. The auditor qualification moved from "Systems Auditor" to "person who has passed the Systems Auditor Examination"⁶⁷. Alongside those, AICPA SOC2 and SOC3, which were on two separate lines in version 6.0, were merged into a single entry reading "AICPA SOC2/SOC3 (or an equivalent audit report by a certified public accountant)". The line being drawn is that the lightweight tiers of a certification scheme do not satisfy the requirement.

One point that is easy to get wrong. Compliance requirement 5 in Chapter 7 of the Planning and Management volume asks that, when outsourcing external storage, compliance with the guidelines for service providers be set out clearly in the contract, and that compliance be verified through periodic reporting. It gives requesting a service specification conformity disclosure statement as an example of how to verify. That is a heavy obligation in practice, and it is not new in version 7.0. It is word for word identical to the Planning and Management volume of version 6.0⁶⁷. If a revision briefing presents that clause as a new demand, it will send internal priorities to the wrong place.

A note on vocabulary, since it trips up non-Japanese readers in particular. People in this field routinely say "the three-ministry, two-guideline framework" (3省2ガイドライン). That is industry shorthand, not the ministry's own terminology. The phrase does not appear once in the five volumes of version 7.0, nor in the notification. The term the text uses is "the two-ministry guidelines" (2省ガイドライン)¹²⁸. If a document is going outside your organisation, flagging the shorthand as shorthand saves an argument later. Getting an internal audience to share what a regulation actually asks for, rather than what everyone assumes it asks for, is its own problem, and it is one of the reasons a knowledge platform such as ZEROCK exists.

Periodic password changes are gone, but the notice and the body text use different words

Of everything technical in this revision, the authentication changes are the ones that land closest to daily operations.

Printed page 38 of the System Operation volume states that "in either case, periodic changes of passwords are not required."¹³ The 90-day and 180-day rotation rules that have sat in hospital policies for years lose their basis. In their place, reuse of passwords is prohibited explicitly, and length is now specified. Where two-factor authentication is in use, eight characters or more mixing letters and numbers, with four or more for a PIN. Where it is not, thirteen characters or more. Where the system cannot be configured that far, the instruction is to set the maximum length the system does allow and address it at the next system replacement.

If a hospital asks me where to start rewriting its internal policy, I start here. It is the one change that reduces what users are asked to do, which makes it the easiest thing in the whole revision to explain to clinical staff.

Now a warning about citation. The revision summary in the notification uses the term "account lockout" (アカウントロック) when it condenses the change. Searching the full text of all five volumes of version 7.0 for that term returns zero hits⁸. The provision it corresponds to is compliance requirement 6(6) in the System Operation volume: "Implement a mechanism whereby, after authentication has failed a certain number of times, login attempts become impossible for a certain period."¹³ If you are writing this into a hospital policy or into a vendor specification, quote the body text rather than the summary term in the notification. Quoting the summary wording is how you end up in a meeting where you and the person who read the original are describing different documents.

Two-factor authentication now has a defined scope. Compliance requirement 5 on printed page 35 of the System Operation volume calls for two-factor authentication at application login for electronic medical record systems and the like on client terminals, and at the OS level for servers¹³. Handling the terminal side alone does not close it out. The reference date is 1 April 2027 (令和9年4月1日), with a transitional allowance until the next system replacement where meeting the date is difficult. Measured against a normal replacement cycle, April 2027 is already inside the planning window.

Two-factor authentication for medical devices, on the other hand, was deferred in this revision. The working group material cited above gives as the reason that it is not mandatory internationally either, and says the scope of what should require two-factor authentication remains under consideration¹¹. That question and the domestic law enforcement question are the two items carried into version 7.1. If you make medical devices, I would not read "out of scope this time" as "safe to ignore for a while".

On AI, there is not one line

As I said at the top, across the 169 pages of the five volumes of version 7.0 there is no mention of generative AI, artificial intelligence, machine learning, LLMs, or large language models. The string "AI" matches in two places, and in both cases the actual text is the audit standard name "AICPA SOC2/SOC3". I downloaded the accompanying checklist (2 pages) and manual (18 pages) and searched them separately, with the same zero result⁸. Version 2.0 of the Safety Management Guidelines for Providers of Information Systems and Services Handling Medical Information (68 pages, established August 2020, revised March 2025), which is the provider-facing counterpart, is no different¹².

What the official record does show is where AI was filed. The breakdown table of public comments in the working group material records that, of 294 comments received, three were classified as "other", with the explanation "AI, data sovereignty, and other issues outside the body of the guidelines"¹¹. AI and data sovereignty were sorted as issues outside the main document. That is as far as the published material goes. It does not say why they were not written into the body, and I am not going to speculate about it.

The timeline is worth holding onto as well. The public comment round ran for three weeks, from 27 March to 17 April in Reiwa 7, which is 2025¹¹. That is more than a year before publication. Anyone who has watched how generative AI is actually being used in clinical settings will have a strong sense of how much changed over that year, and the consultation had closed before any of it. The same material states that only two items will be carried into version 7.1, two-factor authentication for medical devices and the regulation concerning enforcement of domestic law, and that other matters will in principle not be revisited in that revision.

The practical difficulty is that as of 6 September 2026 there is still no Q&A collection for version 7.0. The landing page carries a notice saying it is currently being revised and that it is scheduled for publication during July 2026 (令和8年7月)². That schedule has now slipped by two months. For the moment, the body text is the only thing there is to reason from.

Here is my own reading. The absence of AI from the body text does not mean AI is unconstrained. Sending medical information to a generative AI service is external storage, it is the selection of an outsourcing partner, and it falls under access control and audit logging. Every clause version 7.0 already has reaches it without ever using the word. Because there is no dedicated chapter, the ability to explain for yourself which existing clauses your use of AI lands under becomes the accountability, and I would treat building that explanation as part of the deployment work rather than as something to produce when asked.

Let me be clear about what this article is and is not. It is a reading of the source text against version 6.0, and nothing in it is a judgement about whether any particular configuration is lawful or acceptable. Which volume covers your institution or your product, and which clauses your design actually falls under, has to be settled with the administrator and the legal function at each medical institution, and with the relevant supervisory authority where that is appropriate. Patient safety is on the other side of these decisions, and I would rather be slow than confident here.

If there is one thing to do first, it is to open the contract and the standard terms of service and read what they say about who is responsible for security updates. That sentence decides how many volumes your customer has to read. If you are working through how to fit AI into regulated operations, in healthcare or anywhere else with rules like these, you are welcome to get in touch.

Footnotes

1. Ministry of Health, Labour and Welfare, "Formulation of the Guidelines for the Safety Management of Medical Information Systems, version 7.0" (「医療情報システムの安全管理に関するガイドライン第7.0版」の策定について), Notification Sanjohatsu 0629 No. 1, 29 June 2026 (Reiwa 8), Councillor for Pharmaceutical Industry Promotion and Medical Information, Minister's Secretariat, MHLW. Addressed to prefectural governors, mayors of cities operating public health centres, and heads of special wards. The three items under "Section 1 Overview of the revision", and the line "Added text to the effect that active use of cloud services will be promoted", are from this notification. Retrieved 6 September 2026. https://www.mhlw.go.jp/content/10808000/001716656.pdf ↩ ↩² ↩³

2. Ministry of Health, Labour and Welfare, landing page for the Guidelines for the Safety Management of Medical Information Systems. The PDF links for the five volumes, the per-volume date notation, and the notices regarding the Q&A collection ("currently being revised", "scheduled for publication during July 2026") are from this page. Page counts for each volume were measured on the retrieved PDFs (Overview 11, Executive Management 21, Planning and Management 59, System Operation 51, Maintenance Contractor 27, for a total of 169 pages). Retrieved 6 September 2026. https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html ↩ ↩² ↩³

3. Ministry of Health, Labour and Welfare, Guidelines for the Safety Management of Medical Information Systems, version 7.0 (Overview volume / 概説編). Section 4.3 (printed page 6) on related laws and the caveat concerning the Basic Act on Cybersecurity, section 4.7 (printed page 8) on external storage, and section 3.1.5 on deemed compliance and the profile of medical institution it envisages, are all from this volume. https://www.mhlw.go.jp/content/10808000/001716290.pdf ↩ ↩² ↩³

4. Basic Act on Cybersecurity (サイバーセキュリティ基本法, Act No. 104 of 2014, promulgated 12 November 2014). The act number and date of promulgation were retrieved and verified through the e-Gov law search API (v2). Retrieved 6 September 2026. https://laws.e-gov.go.jp/api/2/laws?law_title=サイバーセキュリティ基本法 ↩

5. Ministry of Health, Labour and Welfare, same guidelines, version 7.0 (Maintenance Contractor volume / 保守委託機関編). The conditions for selecting "YES" in the footnote to Figure 1 on printed page 2, the sentence "Where this is unclear, always confirm directly with the contracted provider and clarify where responsibility lies", and item 3 of section 5 "Personnel management for safety management" concerning domestic law, are from this volume. https://www.mhlw.go.jp/content/10808000/001716297.pdf ↩ ↩²

6. Ministry of Health, Labour and Welfare, same guidelines, version 7.0 (Planning and Management volume / 企画管理編). The requirements on outsourcing external storage in Chapter 7, compliance requirement 5 (printed pages 25 to 26), the final item of the same requirement, "Ensure that the information equipment and the like storing the retained information is within the scope of the application and enforcement of domestic law" (printed page 26, PDF page 32), and the certification list under selection criterion g together with confirmation items h and i (printed page 27, PDF page 33), are all from this volume. https://www.mhlw.go.jp/content/10808000/001716292.pdf ↩ ↩² ↩³ ↩⁴

7. Ministry of Health, Labour and Welfare, Guidelines for the Safety Management of Medical Information Systems, version 6.0 (Planning and Management volume), May 2023. The line on printed page 27, "Confirm that the information equipment and the like storing the retained information is subject to domestic law", and the certification list under the provider selection criteria (no exclusions on ISMAP or FedRAMP, auditor qualification given as "Systems Auditor", AICPA SOC2 and SOC3 on two separate lines), are from this version. Differences against version 7.0 were established by comparing the PDFs of both versions. https://www.mhlw.go.jp/content/10808000/001102575.pdf ↩ ↩² ↩³

8. The full-text search behind this article was run on the five volumes of version 7.0 retrieved from the landing page in note ², extracted to text with pdftotext, stripped of spaces and line breaks, and concatenated into roughly 500,000 characters (performed 6 September 2026). "Japan domestic" (日本国内), "stored in Japan" (国内に保存), "cross-border" (越境), "data sovereignty" (データ主権), "generative AI" (生成AI), "artificial intelligence" (人工知能), "machine learning" (機械学習), "LLM", "large language model" (大規模言語モデル), "account lockout" (アカウントロック), and "three-ministry two-guideline" (3省2ガイドライン) all returned zero hits; "domestic law" (国内法) 3, "foreign law" (国外法) 1, "region, country" (地域、国) 1, and "AI" 2 (both AICPA). The accompanying checklist (2 pages) and manual (18 pages) were retrieved and searched separately in the same way. Because the method targets the text layer of the PDFs, characters embedded in figures as images are outside its scope. https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html ↩ ↩² ↩³ ↩⁴

9. Ministry of Health, Labour and Welfare, same guidelines, version 7.0 (Executive Management volume / 経営管理編). The text in section 5.2.2 "Organisational management" (printed page 17) on the use of an overseas provider as a subcontractor is from this volume. https://www.mhlw.go.jp/content/10808000/001716291.pdf ↩

10. Digital Agency, "Digital Society Promotion Standard Guidelines DS-310: Basic Policy on the Appropriate Use of Cloud Services in Government Information Systems", decided by the Steering Committee of the Digital Society Promotion Council on 27 May 2025 (Reiwa 7), 49 pages. The text taking domestic location of data centres as the baseline, and requiring confirmation of governing law and international jurisdiction where they are located overseas, is from this policy. Note that the MHLW Planning and Management volume cites it under the abbreviated title "Basic Policy on the Use of Cloud Services in Government Information Systems". https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a612d406/20250619_resources_standard_guidelines_guideline_08.pdf ↩

11. Ministry of Health, Labour and Welfare, Health Policy Bureau, Office of the Councillor for Medical Information, "Material 5", 32nd Working Group on the Utilisation of Medical and Related Information under the Study Group on the Utilisation of Health, Medical and Long-Term Care Information, 29 May 2026 (Reiwa 8). The public comment period (27 March to 17 April, Reiwa 7, three weeks) and the total of 294 comments, the breakdown table entry "Other 3 AI, data sovereignty, and other issues outside the body of the guidelines", carried-over item 1 (two-factor authentication for medical devices) and item 2 (regulation concerning enforcement of domestic law, with cancer gene panel testing as an example), and the statement that "other matters will in principle not be considered in the revision to version 7.1", are all from printed pages 7 to 8 of this material. On the ministry's landing page the same material is offered under the title "Overview of the Guidelines for the Safety Management of Medical Information Systems version 7.0 and the main revisions". https://www.mhlw.go.jp/content/10808000/001102596.pdf ↩ ↩² ↩³ ↩⁴

12. Ministry of Economy, Trade and Industry, "Safety Management Guidelines for Providers of Information Systems and Services Handling Medical Information, version 2.0", established August 2020 (Reiwa 2), revised March 2025 (Reiwa 7; the revision history gives 28 March 2025 for version 2.0), 68 pages. Full-text search of the retrieved PDF confirmed no mention of generative AI, artificial intelligence, machine learning, LLMs, or large language models, and that the only two matches for "AI" are AICPA (SOC2/SOC3). https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20250328_rev1.pdf ↩ ↩²

13. Ministry of Health, Labour and Welfare, same guidelines, version 7.0 (System Operation volume / システム運用編). Two-factor authentication under compliance requirement 5 (printed page 35, PDF page 41), the prohibition on password reuse under compliance requirement 6(2), the text of compliance requirement 6(6) "Implement a mechanism whereby, after authentication has failed a certain number of times, login attempts become impossible for a certain period", and "in either case, periodic changes of passwords are not required" together with the length requirements (printed page 38, PDF page 44), are all from this volume. https://www.mhlw.go.jp/content/10808000/001716295.pdf ↩ ↩² ↩³