Evaluate a cloud EMR or departmental system and the question always arrives: "is this alright under the three-ministry guidelines?" The vendor answers "we're compliant," the hospital has no way to test the claim, and the project proceeds. That is a common enough sequence.
What gets missed is that using the cloud is entirely unproblematic under the guidelines. They do not prohibit it. What is asked is whether the hospital followed the required procedure. However robust the service technically, if there is no record of selection, no documented demarcation, and no knowledge of where the data sits, the hospital's own compliance does not stand up.
This article walks through that procedural side. Encryption, key management, and zero trust are covered in Cloud Security for Medical Institutions; here the focus is what to confirm and what to keep on file.
Disclaimer: General information only. External storage requirements and cloud decisions are governed by the publications of MHLW, METI, and MIC and by Japan's personal information protection law. These are revised; work from current primary sources.
It Starts as a Question of External Storage
Putting clinical information in the cloud means, as a regulatory matter, storing medical records outside the institution. So the starting point is not a feature comparison but the conditions that external storage must satisfy.
Electronic storage consistently requires the three principles:
| Principle | Meaning | What to confirm in the cloud |
|---|---|---|
| Authenticity | Records are correct, attributable to who created or amended them and when, and unaltered | Identity management, retention of edit history, traceable accountability |
| Legibility | Records can be displayed or output for human reading immediately when needed | How records are read during an outage or line failure; output formats; response guarantees |
| Preservability | Records remain recoverable for the required period | Backup method, retention period, the provider's custody arrangements |
Legibility is the one the cloud most often exposes. On premises, reading a record was contained within the building; in the cloud it depends on your line and the provider's uptime. Whether you can read a chart when the line is down is a question you must settle. Without a local read-only cache, periodic PDF export, or a paper fallback, a network outage becomes a suspension of care.
Preservability now also connects to reimbursement: level 1 of the electronic clinical-information coordination system enhancement addition requires backups by multiple methods with some held offline, so "we're on the cloud, preservation is the provider's problem" no longer holds. See External Storage Requirements for Medical Information and Backup Design for Hospitals.
The Procedure for Selecting a Provider
For compliance purposes, which provider you chose matters less than whether there is a record of how you chose. Being able to explain the reasoning afterwards is the substance of supplier management.
Five records cover it:
- Criteria decided in advance — what was mandatory, what was a plus. Criteria written after the decision carry no weight
- Material obtained from candidates — compliance statements, certificates with their scope, responsibility matrices, SLAs
- The comparison — evaluation against the criteria, including why others were rejected
- The decision — who approved it and when, with executive involvement visible
- Accepted residual risk — no provider satisfies everything. Record what was not satisfied and the reasoning for accepting it
The fifth is the most often omitted and the most valuable. "We could not satisfy this point, so we adopted this compensating measure and accepted the remainder" is compliance. Without the record, the identical situation reads as non-compliance.
See Criteria for Selecting a Cloud Provider, Questions to Ask a Vendor, and The METI/MIC Guidelines.
How to read third-party certifications
ISO/IEC 27001, ISO 27017, ISMAP — providers will present several. They are useful selection material, with two cautions.
First, read the scope. Certificates state their scope, which is frequently limited to a business unit or a particular service rather than the whole company. Unless the service you will use falls within that scope, the certificate tells you little.
Second, none of them evidences compliance with the three-ministry guidelines. They show that security management is established; healthcare-specific requirements — the three storage principles, explicit demarcation, the duty to inform the institution — sit outside their remit. Use certification to confirm the foundations, then ask the healthcare-specific questions separately. See What Is an ISMS (ISO/IEC 27001)?.
Agree Demarcation, Then Write It Down
Cloud compliance most often collapses because demarcation exists only as a verbal understanding. "We will operate the system" in a proposal is unenforceable until the contract says what "operate" includes and excludes.
At minimum, classify these six domains as hospital / provider / joint:
| Domain | Common misconception | What to confirm |
|---|---|---|
| Accounts and permissions | The provider handles it | Almost always stays with the hospital — including removing leavers' IDs |
| Backup and restore | The provider does all of it | Who takes them is one question; who restores, and how long it takes, is another |
| OS and middleware updates | SaaS means the provider | Even in SaaS, notification and downtime scheduling are joint |
| Audit logs | Collecting them is enough | Retention and disclosure terms, and who reviews |
| Decisions during an incident | The provider responds | Who has authority to suspend the service |
| Data at termination | We'll get it back | Is the format migratable? Is a deletion certificate issued? |
The first row bears repeating. Moving to the cloud does not move account and permission management. Looking at the structure common to publicly reported incidents, the entry point is more often this hospital-side remainder than the provider's platform.
See Demarcating Responsibility, Writing SLAs and Responsibility Boundaries, and AI EMR Security Design.
Confirming Region and Data Location
Surprisingly many vendors cannot answer "where is the data?" immediately, because most cloud services run on an IaaS provider's regions rather than their own data centres.
Four things to confirm:
1. The storage region. Can you specify it contractually, or can the provider change it at discretion? Are you notified?
2. Where backups and replicas live. Production may be domestic while disaster-recovery copies sit elsewhere. Do not stop at production.
3. Where maintenance access originates. Data may be stored domestically while support staff connect from abroad. Who can reach it, from where, is a separate question from where it rests.
4. Subcontractors' locations. If your provider uses another provider, that location is in scope too.
Where data sits abroad, or is accessed from abroad, the personal information protection law's rules on provision to third parties in foreign countries may come into play separately. Clinical information is sensitive personal information, so handle this carefully. The guidelines likewise indicate that overseas storage requires confirmation extending to applicable law and governing law, so if this may apply to you, check the Personal Information Protection Commission's publications and the guideline text directly.
The practical landing point: get written answers on storage location, backup location, and maintenance access origin, and contract for notification of changes. You may not be able to freeze them, but you can stay informed.
What Remains After Go-Live
Implementation is not the end. Several procedures stay with the hospital, and skipping them means that however carefully you ran the project, document and reality will diverge within a few years.
| Frequency | Procedure | Content |
|---|---|---|
| As needed | Account review | Deleting IDs and adjusting rights on departure or transfer. The most common path to an incident |
| Monthly–quarterly | Log review | Keep a record of having reviewed. Collection alone is not compliance |
| Annually | Restore test | Confirm you can actually recover; schedule with the provider if joint |
| Annually | Receive the provider's report | Posture, subcontractors, incidents. Put it in the contract |
| Annually | Review the responsibility matrix | Have the service spec or subcontractors changed? |
| On revision | Reflect guideline revisions | Assign someone to track. See Revision Trends |
Build these six into the annual plan and keep the records, and supplier management is in shape. For most hospitals this is less about building something new than about turning existing practice into records.
See The Three-Ministry Compliance Checklist and Implementation Steps.
Conclusion
- Using the cloud is not itself a problem. What matters is whether the hospital followed the procedure
- The starting point is the three storage principles; in the cloud, legibility — reading records when the line is down — is the blind spot
- In selection, criteria set in advance and recorded acceptance of residual risk are what carry weight
- Read certifications for scope; none of them evidences three-ministry compliance
- Account and permission management stays with the hospital in the cloud — and that is where reported incidents commonly begin
- Confirm data location across four points: region, backups, maintenance access origin, subcontractors
- Procedures remain after go-live. Put them in the annual plan and record them
For help building cloud selection requirements or assessing a service already in production, contact us.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Version 6.0 full text (PDF) | MHLW
- On the FY2026 fee revision | MHLW
- Personal Information Protection Commission
- Information-technology Promotion Agency (IPA)
Note: external storage requirements and the treatment of overseas storage and cross-border provision are governed by the guideline text and Japan's personal information protection law. Both are subject to revision; always confirm against current primary sources.