When a maintenance contract for an EMR promises "99.9% uptime", it is worth asking what is actually being promised. Over a 30-day month, 99.9% permits roughly 43 minutes of downtime. And those 43 minutes count the same whether they fall during an overnight batch window or in the middle of Tuesday morning clinic.
More significantly, most SLAs put events like a ransomware attack outside the uptime calculation altogether. With a force majeure or third-party-act exclusion in place, weeks of outage need not breach the uptime figure at all. The scenario that hurts a hospital most is precisely the one the SLA does not cover.
An SLA is a document that promises a service level and, in the same breath, fixes the boundary of what is not promised. The practical work is not comparing uptime percentages; it is writing down what happens when the system stops, who does what, and by when it comes back.
This article sets out the SLA and responsibility items to settle before signing. For the underlying model of shared responsibility, see Security Design and the Shared Responsibility Model for AI EMRs.
Disclaimer: This article is general information. The effect and interpretation of contract terms depend on the individual agreement and applicable law — consult counsel. The authoritative texts for guideline requirements are the MHLW, METI and MIC publications.
What Uptime Does Not Protect
| What uptime fixes | What it does not fix |
|---|---|
| The percentage available over a period | When it goes down (clinic hours or not) |
| Whether planned maintenance counts | Who does what in the minutes after it stops |
| The penalty for breach (usually a fee credit) | How many hours until service returns |
| — | How far back the data will be |
| — | How losses from suspended care are treated |
| — | Whether outages from cyberattack are included |
The right-hand column is where real incidents live. Checking whether those items are written at all matters far more than comparing 99.9% against 99.5%.
Note too that uptime penalties tend to lack teeth. Breach typically triggers a credit of a few to a few tens of percent of the month's fee — on a maintenance contract of a few hundred thousand yen a month, that is pocket change against the lost activity and staff burden of an EMR being down for a day. Penalties deter weakly; the value of an SLA is not the money but the fact that it fixes the response procedure in advance.
The Four Times an SLA Must State
| Metric | Definition | How to decide it |
|---|---|---|
| Detection to notification | From the vendor detecting an anomaly to telling you | Decide together with the notification threshold |
| Time to first response | From your call to a named person responding | Set separately for weekday hours, nights, and weekends — healthcare runs 24/7 |
| RTO | Target time from failure to service restoration | Define whether it means full service or degraded operation |
| RPO | Target point to which data can be recovered | Ties directly to backup frequency; 24 hours means losing a day of records |
Translate RPO into clinical language
RPO looks technical but is a floor-level question: how many hours of records will have to be re-entered? An RPO of 24 hours means that, at worst, a full day of notes, orders and results is gone. What was written on paper can be re-keyed; what was typed straight into the EMR cannot.
Shortening RPO means more frequent backups, which costs money. That is exactly why it should be decided after telling the hospital, in plain terms, that this number means re-entering a day of records in the worst case — a clinical agreement, not only a technical one. See Backup Design for Hospitals: the 3-2-1 Rule.
Fix the notification threshold first
A detection-to-notification time means nothing without a definition of what gets notified. Three tiers work:
- Immediate — successful unauthorised access, possible exfiltration, service outage
- Same day — detected attempts at unauthorised access, disclosure of a critical vulnerability and start of impact assessment
- Periodic report — minor events, patching, configuration changes
Tier 2 varies most between vendors. Calling every time an attempt is detected is unworkable for them — but knowing that sustained attempts are aimed at your systems is exactly what justifies raising the alert level internally. Agree where the line sits before signing.
Writing the Responsibility Boundary
Trying to draw responsibility as a single line always fails, because who performs a task and who is accountable for the outcome are frequently different people. A four-column table handles it.
| Subject | Performs | Accountable | Typical agreement |
|---|---|---|---|
| OS/middleware patching | Vendor | Vendor | Set timing and advance-notice rules |
| Application vulnerability fixes | Vendor | Vendor | Target days by severity |
| User account creation/removal | Hospital | Hospital | Leaver de-provisioning is an internal process |
| Role design | Joint | Hospital | Vendor presents options, hospital decides |
| Taking backups | Vendor | Joint | Vendor performs; hospital defines requirements and verifies |
| Restore testing | Joint | Hospital | Write an annual test into the contract |
| Endpoint management | Hospital | Hospital | State how vendor-supplied devices are treated |
| Network equipment / VPN | Confirm | Confirm | The most commonly dropped row |
| Log capture | Vendor | Vendor | Specify what is captured and retention |
| Log review | Hospital | Hospital | Set internal frequency and method |
| Staff training | Hospital | Hospital | If the vendor supplies material, state the scope |
The network and VPN row is the dangerous one. A recurring structure in published breach cases is a known vulnerability in a VPN appliance serving as the entry point. Inside the hospital, that appliance was delivered by the network contractor, sits outside the EMR vendor's scope, and the network contractor's maintenance covers the circuit but not firmware — so nobody is watching it. Lay the contracts side by side and ask, device by device, who owns firmware updates. See Managing VPN Appliance Vulnerabilities.
Do not leave "joint" as it stands
Any row marked joint is a vacuum until you decompose it into steps and assign each one. For restore testing:
- Produce the test plan: vendor
- Schedule the test: hospital
- Perform the restore: vendor
- Verify the restored data is clinically valid: hospital, including clinical staff
- Record and retain the result: hospital
Written out, the vendor's assumption — "we restore, you verify" — becomes explicit, and the internal conversation about who verifies can actually happen. See Demarcating Responsibility.
Where the Fee Criteria Meet the SLA
The FY2026 electronic clinical information coordination system development addition shapes SLA design. Its common criteria include compliance with the MHLW guidelines and appointment of a dedicated medical information system safety management officer; level 1 adds backups by multiple methods, part of them held offline, and a BCP for cyberattacks with exercises.
| Fee criterion | What the SLA/contract should say |
|---|---|
| Guideline compliance | Name the guidelines binding the vendor; require a table of who performs each requirement |
| Safety management officer | An internal role, but map it to a named counterpart on the vendor side |
| Multi-method backup | Specify method, generations and offline copy; state who is accountable for each |
| BCP and exercises | Whether the vendor takes part, at what frequency, and who pays |
Vendor participation in BCP exercises becomes a chargeable engagement every time unless the contract says otherwise. Building an annual exercise into the maintenance contract makes the exercise meaningful and makes the fee criteria easier to evidence. See A BCP for Cyberattacks and The FY2026 Fee Revision.
Official Q&A indicates several backup approaches satisfy the criterion: separate physical media with generation management; automatic transfer to a NAS kept permanently disconnected from the network; or backup to a logically separated area within a cloud service where prompt recovery is possible. For daily backups, at least three generations are indicated. Which approach is available depends on how your vendor delivers the service — confirm before contracting.
When the SLA Is Missed
| Layer | Content | Effectiveness |
|---|---|---|
| Reporting | Written root-cause analysis and prevention plan | High — it costs the vendor effort and deters repetition |
| Fee credit | Reduction of service or maintenance fees | Low — small relative to the harm |
| Termination | Right to terminate after repeated or prolonged breach | Medium — but EMR switching costs make exercise unrealistic |
The reporting obligation does the most work. A clause reading "where RTO is exceeded, submit within two weeks a written account of the cause, the sequence of events and preventive measures, and present it at a meeting with the hospital" bites harder than any credit clause.
On termination: for an EMR, being able to terminate is worthless if you cannot take the data with you. Pair any termination right with a data-return clause covering format, deadline, migration cooperation and cost. See Security Requirements for EMR Replacement and Questions to Ask Your Vendor.
Conclusion
- Uptime says nothing about when you go down, how fast you return, or how far back the data goes. Comparing the percentages is nearly meaningless
- State four times: detection-to-notification, first response, RTO, RPO — split by hours, nights and weekends
- RPO is "how many hours of records get re-typed." Agree it with clinical staff, not only IT
- Split the boundary table into performs and accountable. Network equipment and VPN is the row that falls through
- Decompose every "joint" row into steps with named owners, or it becomes a vacuum
- On breach, the reporting obligation is the effective remedy; credits do not match the harm
- A termination right only functions paired with a data-return clause
Reviewing SLAs starts with an inventory of existing contracts — laying several vendors' agreements side by side to find the gaps in responsibility. That is heavy work to carry in-house. For help with that, or with requirements ahead of a replacement, contact us.
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)
Note: fee calculation criteria are governed by the official notifications and Q&A; the effect of contract terms depends on applicable law and the individual agreement. Decide on the basis of the latest published material and advice from counsel.