Six months after replacing an EMR, someone inside the hospital asks: how much of the access log are we actually capturing? Are the servers in Japan? What is the recovery target if this goes down? Nobody can answer. The vendor is asked, and the reply comes back: that is not in the contract scope, it would be a paid option.
This does not happen because vendors are dishonest. It happens because of something entirely mundane: a requirement that is not in the specification does not appear in the quote, and therefore does not appear in the design. In procurement, security requirements are not something you negotiate after signing. They are something you settle while writing the specification.
Japan's FY2026 fee revision made this heavier. The newly created electronic clinical information coordination system development addition folded security requirements — compliance with the MHLW safety management guidelines, and appointment of a dedicated medical information system safety management officer — into the criteria for claiming it. Security has moved from "worth doing if we have room" to "a determinant of whether we can claim". How well you procure now feeds directly into whether you qualify.
This article sets out the practice of writing security requirements into a procurement specification: what to write, how to write it, and how to verify what you wrote.
Disclaimer: This article is general information. The authoritative texts are the MHLW notifications and Q&A for fee calculation criteria, and the MHLW "Guidelines for the Safe Management of Medical Information Systems" for guideline requirements. Base actual procurement decisions on those and on advice from your counsel and the relevant authorities.
Why Asking Later Does Not Work
Laying procurement out in time makes the window obvious.
| Stage | Can security requirements be added? | Why |
|---|---|---|
| Requirements and specification | Yes | They become the premise of the quote; vendors propose a conforming design |
| Proposal and quotation | Limited | Clarification questions work; adding requirements is unfair to bidders |
| Contract negotiation | Limited | Can enter as contract clauses, but price and schedule must be reopened |
| Design and build | Rarely | Treated as a change order: extra cost, extra time |
| After go-live | No | Becomes an option, and some configurations make it impossible |
The critical point is that some requirements become technically impossible. "Record every read of the clinical record and retain it for at least a year" depends on how logging was designed. If the product's architecture never assumed it, no amount of post-hoc effort will produce it. Restricting data residency to Japan is the same: relocating after go-live is effectively a rebuild.
The other overlooked point is that the consequence of not writing a requirement stays with the buyer. The guidelines require hospitals to manage their suppliers. If a vendor falls short of something you never specified, there is room to characterise that as a management failure on the hospital's side. See Demarcating Responsibility and Writing SLAs and Responsibility Boundaries.
The Skeleton of What to Specify
Trying to be exhaustive produces a document nobody reads. Start with these eight blocks, in this order; vendors find them easy to answer against.
| # | Block | What to write | What happens if you omit it |
|---|---|---|---|
| 1 | Applicable standards | Which guideline, which edition, which scope | "We comply" cannot be verified |
| 2 | Data residency | Country/region of storage, and of backups | Offshore storage surfaces later and cannot be moved |
| 3 | Access control | Role design, privileged ID handling, where MFA applies | Delivered with every user on one permission set |
| 4 | Logging | What is recorded, retention, how to search and export | You cannot reconstruct who saw what after an incident |
| 5 | Backup | Method, generations, offline copy, restore testing | You fail the fee criteria; backups get encrypted alongside |
| 6 | Incident response | Contact chain, time to first response, reporting, recovery targets | Nobody can even identify who to call |
| 7 | Subcontracting | Whether allowed, prior consent, responsibility for subcontractors | A company you have never heard of touches production data |
| 8 | End of contract | Return format, proof of deletion, migration cooperation | Your data is held hostage at the next replacement |
Blocks 5 and 6 tie directly to the fee criteria. Level 1 of the coordination addition requires backups by multiple methods with part held offline, plus a BCP for cyberattacks with exercises. If the system is not built to support that, no amount of internal process will satisfy it. See Backup Design for Hospitals: the 3-2-1 Rule and A BCP for Cyberattacks.
Write the state to be achieved, not the product feature
A common failure is naming products. "Deploy EDR" is satisfied by buying that product; whether unusual endpoint behaviour can actually be detected and traced is a separate question.
Weak: "The system shall have audit log functionality."
Better: "For each read, create, update, delete, print and export of a clinical
record, the system shall record the operator, timestamp, subject patient
and operation type; retain them for at least one year; and allow hospital
staff to search and export them by period, operator and patient."
The second version forces differences into the open at proposal time: "we do not log reads", "export is a chargeable engineering task". The purpose of a specification is to make vendors differ visibly.
Making Guideline Compliance an Actual Requirement
"Shall comply with the three-ministry guidelines" is common and does not function as a requirement. The guidelines split into a hospital-facing set (MHLW, Guidelines for the Safe Management of Medical Information Systems, 6.0) and a provider-facing set (METI/MIC, for providers of information systems and services handling medical information). Vendors are bound by the latter. Demanding compliance with the former from a vendor blurs where responsibility sits.
Three layers work in practice.
| Layer | How to write it | Example |
|---|---|---|
| Declaration | Name the guideline and edition | "Shall comply with the METI/MIC guidelines for providers handling medical information" |
| Allocation | Require a mapping table of who does what | "Submit a table stating, for each requirement in the Planning and Operations volumes of MHLW 6.0, whether the hospital, the vendor, or both performs it" |
| Individual clauses | Write the important items out separately | The eight blocks above as their own clauses |
The mapping table in layer two does the most work. A single line of "we comply" cannot be checked; a table forces blanks and "performed by the hospital" entries into view. That table then doubles as the blueprint for your internal arrangements and as audit evidence. See The Three-Ministry Guidelines and Implementation Steps for the Three-Ministry Guidelines.
MHLW also published a cybersecurity checklist and manual for healthcare organisations on 14 May 2025, more concrete than earlier material and covering cloud, BCP, IoT and BYOD. It is a usable source of specification line items — see Using the MHLW Checklist.
Mandatory Requirement or Scored Criterion?
Whether to require third-party certification — ISO/IEC 27001, ISO/IEC 27017, the Privacy Mark — is argued every time.
| Treatment | When it fits | Risk |
|---|---|---|
| Mandatory (disqualifying) | Core systems at large hospitals; patient data held in the vendor's environment; formal public procurement | Local mid-size vendors cannot bid; you lose geographic proximity for maintenance |
| Scored | Departmental systems; incumbent suppliers in the field; thin candidate pools | Scoring can be set so low it becomes decorative |
| Not a requirement | Small in-house systems where certification says nothing about the actual risk | You carry the burden of checking posture case by case |
The axis for deciding is how far the vendor reaches into patient data. Holding medical information in the cloud, entering production through remote maintenance, carrying data out during a migration — any of these makes third-party evidence of the vendor's posture reasonable to demand. A device that never touches the hospital network is a different matter.
Know what each certification means:
- ISO/IEC 27001 (ISMS) — general information security management. The most broadly applicable evidence of a vendor's posture
- ISO/IEC 27017 — cloud-specific controls. Meaningful when medical information sits in a cloud service
- Privacy Mark — personal information handling. Well recognised in Japan, but limited to personal data
The crucial caveat: certification evidences that a mechanism existed at audit time. It is not a guarantee about your data. Always check the certified scope — which sites, which services — and whether your engagement falls inside it. Certificates whose scope covers only a head-office function, while the actual development site sits outside, do exist. See Defining ISMS Scope and What Is an ISMS?.
Vendors without certification
A local integrator who has maintained your systems for fifteen years may hold nothing. Disqualifying them outright narrows the field and can raise operational risk. A workable design:
- Make the mandatory requirement "can evidence its posture", citing certification as one acceptable form and allowing an equivalent (checklist responses plus supporting documents)
- Score certification with a meaningful point differential
- Make remediation a contract condition — a clause requiring the posture to be built out within a set period
The third creates a reason for vendors to pursue certification. A buyer stating a standard is what raises the supply side's standard; that is procurement's largest lever.
Verifying That Requirements Were Met
Writing a requirement does not satisfy it. Write the verification method into the specification too.
| When | How | Example wording |
|---|---|---|
| Proposal | Checklist responses, mapping table, copy of certificate | "Complete and submit the attached security check sheet" |
| Contract | Clauses in the agreement | "Obtain prior written consent before any subcontracting" |
| Acceptance | Configuration evidence, a live log export | "Include the permission matrix and a sample log export in the deliverables" |
| Operation | Annual reporting, audit rights | "Report the status of security measures in writing once per year" |
| Termination | Data return and proof of deletion | "Return data in the specified format and provide written proof of deletion" |
Acceptance evidence earns its keep. "Logs are available" may turn out to mean only an administrator can export them, or that there is a screen but no CSV — and you will not discover it until after go-live otherwise.
Include an audit-rights clause. Even unexercised, an obligation to accept audit affects how the vendor manages itself. Keep it realistic — written reporting as the norm, on-site inspection available for serious events — or it prices itself into the quote.
For the check sheet itself see Security Check Sheets for Vendors; for questions to ask at proposal stage, Questions to Ask Your Vendor; for cloud engagements, Selecting a Cloud Provider.
Conclusion
- Requirements only go in at specification stage. After go-live they become options — or are architecturally impossible
- Build the skeleton from eight blocks: standards, residency, access control, logging, backup, incident response, subcontracting, termination
- Write states to be achieved, not product names, so differences surface at proposal time
- For guideline compliance, demand a mapping table of who performs each requirement, not a declaration
- Decide mandatory-versus-scored certification by how far the vendor reaches into patient data — and always check the certified scope
- Write the verification method for each stage into the specification as well
Procurement requirements and internal arrangements are two sides of one thing: until you decide what the vendor carries and what you carry, you cannot write the requirements. If that allocation is unresolved, or you want to start by reviewing existing contracts, contact us. Pottech builds medical information systems and also provides ISMS certification support to healthcare vendors, so we can bring both sides of the table into the analysis.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines, edition 6.0 (PDF) | MHLW
- FY2026 Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- Personal Information Protection Commission
Note: guideline requirements and fee calculation criteria change with revisions and official Q&A. Check the latest published material before committing them to a specification.