"Surely the three-ministry guidelines are a hospital problem." Clinic directors say this often, and the reaction is understandable. The guidelines run to hundreds of pages and much of the text presumes an organisational apparatus. With one full-time physician and five to ten staff, building that apparatus looks impossible.
But the guidelines do not turn on size. Edition 6.0 applies to "all those involved in the introduction, operation, use, maintenance, and disposal of medical information systems" — hospitals, clinics, dental practices, and pharmacies alike. If you run an EMR, submit claims electronically, and operate online eligibility verification, you are in scope.
Being in scope, however, is not the same as building what a large hospital builds. The guidelines call for treatment proportionate to risk, and risk scales with the volume and breadth of data handled. The question is not whether to act but where to start, with the people and budget you have.
This article sets out what a small practice should realistically do, and in what order. For the structure of the guidelines overall, see Key Points of Edition 6.0.
Disclaimer: This article is general information. The authoritative sources are the MHLW's published text, notices, and Q&A.
Small Does Not Mean Low Risk
Being small cuts both ways.
| Dimension | Position of a small practice |
|---|---|
| Volume of data | Lower — fewer patients affected by a single breach than at a hospital |
| System complexity | Simpler — few departmental systems, a narrower estate to manage |
| Likelihood of attack | No advantage. Attacks are largely untargeted, sweeping mechanically for vulnerable devices |
| Ability to recover | Disadvantaged. No IT staff to judge or restore during an incident |
| Business continuity | Disadvantaged. If clinics stop, income stops immediately, with no slack |
The bottom three rows are the point. The entry route does not care about your size, and resilience after an incident is weaker the smaller you are. The structures that recur in published disclosures — a known VPN vulnerability as the entry point, backups on the same network encrypted alongside production, undocumented recovery steps making the switch to paper slow — happen at any size.
So the accurate reading is not "small practices can skip this" but small practices especially need to act in order of effect.
Backups and Access Control First
With limited effort to spend, backups and access control come first, because these two are most directly tied to the outcome when something goes wrong.
Why backups first
How long your clinics stay down is determined by recovery speed, not by the thickness of your defences. You cannot prevent every intrusion, but if you can restore, the time to resuming care shortens dramatically.
For a small practice:
- Keep a copy in a different place, on a different path. A NAS on the same network is, against ransomware, equivalent to having nothing
- Keep part of it off the network. An external disk or RDX cartridge taken periodically and normally disconnected. The simpler the routine, the longer it survives
- Keep generations. Overwrite-only exposes you to overwriting good data with encrypted data
- Confirm once that you can restore. "We take backups" and "we can restore" are different claims. Once a year is enough — restore for real and record how long it took
The FY2026 electronic clinical information coordination add-on requires, for inpatient tier 1 (160 points), backups by multiple methods with some held offline. The examples given are separate media (RDX and similar, with generation retention), automatic transfer (to a NAS kept permanently disconnected from the network), and within-cloud backup to a logically separated area. For daily backups, at least three generations. Even for a clinic with no beds and no inpatient claim in view, the design principle is still worth adopting. See FY2026 Fee Revision and Backup Design: the 3-2-1 Rule.
Why access control next
The most common reality in a small practice is everyone sharing one ID, or everyone holding full rights. Convenient day to day, it creates two problems:
- You cannot say who did what — so you cannot answer a patient query or an internal question
- One stolen credential exposes everything
The work is not large.
- Issue individual IDs. Stop shared accounts. This alone transforms your ability to explain events
- Disable leavers' accounts the same day. Small practices are where dormant accounts linger longest
- Restrict administrator rights. Not everyone needs to be an administrator
- Review every account once a year. With five to ten staff, that is thirty minutes
What Can Wait
Prioritising means deciding what to defer. In a small practice the following can sit lower initially — but anything you decide not to do should be recorded as a decision (an executive one: see The Governance Part).
| Item | Priority for a small practice | Why |
|---|---|---|
| Backup redundancy and restore testing | Highest | Directly determines the outcome |
| Individual IDs and rights | Highest | Determines explainability and blast radius |
| Network equipment update management | High | The layer that recurs as an entry point |
| Paper fallback procedure | High | Whether you can keep seeing patients |
| Staff awareness (email, USB) | High | Free, and effective |
| Written procedures | Medium | One document is fine — it is about having decided, not length |
| Periodic log review | Medium | Confirm collection settings now; review at a sustainable cadence |
| Asset register | Medium | One spreadsheet. Ten to twenty devices takes an hour |
| Detailed work instructions | Low | The fewer the people, the more this runs on conversation and practice |
| Independent audit function | Low | Disproportionate; an outside look once a year suffices |
Do not read the lower rows as "never." This is an order, not an exemption: start at the top and work down once the routine holds.
The test for documentation is "can you explain to a third party what you decided and how you operate?" A hundred-page manual in a five-person clinic will go unread, unrevised, and out of step with reality. One short procedure plus a register plus records explains far more. See The Planning and Management Part.
What the Vendor Can Carry — and What It Cannot
In a small practice, technical work is almost entirely vendor-dependent. That is not the problem. The problem is that what has been handed over is not written into the contract.
| Area | Can the vendor carry it? | Watch for |
|---|---|---|
| Backup configuration, execution, retention | Yes | Put restore testing and reporting into the contract, not just "backups taken" |
| Server and software patching | Yes | State the scope — check clinic PCs are not excluded |
| Network equipment updates | Yes | Confirm it is within the maintenance contract; end-of-support devices linger |
| Log collection settings | Yes | Confirm retention period and that rollover does not erase |
| Remote maintenance | Yes | Require records of source, time, and work performed |
| Account issuance and suspension | Partly | Request and approval are institutional acts; only execution is outsourced |
| Who gets which rights | No | A judgement based on internal duties |
| Which risks to accept | No | An executive decision |
| Staff awareness and training | No | Materials can come from outside; delivery and records stay internal |
| First-line judgement during an incident | No | Whether to suspend clinics is the director's call |
The "no" rows are, essentially, the complete list of what a small practice must do itself — and it is not a long list.
Useful contract language runs at the level of: "taking, retaining, and restore-testing backups falls within the provider's responsibility, with results reported monthly"; "firmware updates for network equipment are within the maintenance scope, and material vulnerability information will be notified promptly." Converting 'presumably' into 'contractually' is the highest-return control available to a small practice.
See Security Check Sheets for Vendors, Demarcating Responsibility, and Cloud Security for Healthcare Institutions.
And again: outsourcing does not transfer the institution's responsibility. Vendor compliance with the METI/MIC guidelines is a precondition, not a defence. See The Three Ministries' Two Guidelines Explained and What Is an ISMS (ISO/IEC 27001)?.
A Workable First Three Months
Sized for two people — the director and the lead administrator.
Month 1: find out where you stand
- Complete the MHLW's cybersecurity checklist for healthcare institutions (published 14 May 2025) for your practice
- Build an asset register as a single spreadsheet: EMR, billing computer, eligibility terminal, PCs, tablets, NAS, router, wireless APs, USB drives, and cloud service accounts
- Ask your vendor, in writing, exactly what the maintenance scope currently covers
Month 2: fix the two that matter
- Review the backup arrangement and add one offline copy; configure generation retention
- Retire shared IDs in favour of individual accounts; restrict administrator rights
- Delete every leaver's and transferee's account
Month 3: put it into shape
- Write one short safety management procedure: who the manager is, what is permitted and prohibited, who to ask when unsure, who to call in an incident
- Appoint the medical information system security manager and record it (see The Medical Information Security Manager)
- Decide the paper fallback for an EMR outage and run it once; print the forms and keep them to hand
- Hold one awareness session — email attachments, USB drives, handling of patient information. Record the date and attendees
That gives you the skeleton of being able to explain what you decided and how you operate. After that, it is an annual cycle: update the register, review accounts, test a restore, run the training. For daily operations see The System Operations Part, and for the overall route Practical Steps for Three-Ministry Guideline Compliance.
Conclusion
- The guidelines apply regardless of size, though the depth of treatment scales with risk
- Small practices are not less likely to be attacked — they are less able to recover. Which is exactly why order matters
- Backups and access control come first: they determine the outcome when something goes wrong
- Backups: separate path, part offline, keep generations, restore once. The tier 1 principle is sound design guidance even for a clinic with no beds
- Access control: individual IDs, same-day suspension for leavers, restricted admin rights, an annual review — thirty minutes at this size
- Documentation is judged on explainability, not length. One short procedure plus a register plus records is enough
- Let the vendor carry the technical work, but convert 'presumably' into 'contractually'. Rights design, risk acceptance, training, and first-line judgement stay with you
Where the line sits for your practice depends on your size and how much is outsourced. If you would like a second opinion, or help sorting out the responsibility split with your vendor, get in touch.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Edition 6.0 full text (PDF) | MHLW
- On the FY2026 medical fee revision | MHLW
- Information-technology Promotion Agency (IPA)
- Personal Information Protection Commission
Note: the guidelines are revised and fee requirements clarified through official Q&A. This article reflects material published at the time of writing; base filing and billing decisions on current notices and confirmation from your Regional Bureau of Health and Welfare.