The final part covers the non-functional requirements and how to use the spec when adopting. Beyond features, quality attributes such as staying up, staying protected, and being migratable often decide the outcome.
Non-functional requirements are hard to see in normal times and easily deferred, yet they matter most during incidents, disasters, or security events, underpinning the continuity of care itself.
Part 1 gave the overview and Part 2 the functional requirements. This part addresses the other pillar, non-functional requirements, broken into availability, performance, operations, migration, and security with practical checkpoints.
What non-functional requirements are (IPA grades)
The spec's non-functional requirements are organized on IPA's Non-Functional Requirements Grades, a framework covering availability, performance, operations, migration, and security systematically.
Items useful for hospitals were selected and listed as disclosure items that vendors present on request, letting hospitals ask each vendor to disclose on the same criteria.
Compliance items vs. disclosure items
Non-functional criteria are easier to grasp as two kinds: compliance items to be satisfied, and disclosure items whose levels are disclosed for comparison and judgment.
- Compliance items: conditions to be met, such as safety management
- Disclosure items: levels of availability and performance disclosed on request
- In practice, the point is judging whether disclosed levels meet your needs
Availability (1): operating hours and planned outages
Availability is most critical to not disrupting care. First check operating hours and whether, when, and how often planned maintenance occurs, and whether it fits your night and holiday operations.
A hospital with 24-hour emergency care needs different uptime than a daytime outpatient one. Check specifically whether planned outages fall in acceptable windows for your operations.
Do not judge by a figure like 99.9% alone; in practice you must check its breakdown, whether it includes planned outages and what alternatives exist during downtime.
- Operating hours, including whether 24-hour
- Whether planned outages occur, their timing, frequency, and notice
Availability (2): RTO and RLO
When incidents occur, RTO (recovery time objective) and RLO (recovery level objective) matter: RTO is how quickly recovery is targeted, RLO is to what level.
For example, recover within four hours to the latest records, expressed in both time and scope. Confirm before contracting that these fit your tolerance for continuity.
- RTO: the target time to recover
- RLO: the target scope or level of recovery
Availability (3): disasters, DR, redundancy
Disclosure items also include restart goals for large-scale disasters, disaster-recovery (DR) policy, and data redundancy and backup scope, important in disaster-prone Japan.
A benefit of cloud-native systems is holding data across geographies to improve recoverability after disasters. Check that the vendor's DR policy aligns with your BCP.
- Restart goals and data-recovery scope for large-scale disasters
- DR policy and remote backup
- Data redundancy, backup frequency, and retention
Combining with paper-based BCP
However highly available a system is, downtime during incidents or disasters cannot be reduced to zero. That is why a business-continuity plan, including paper-based operation, is important for continuing care when the system stops.
The point of checking RTO and DR is not to collect numbers but to combine them with on-the-ground paper procedures for bridging the recovery time, which is what makes preparedness effective.
- Prepare paper forms and procedures for system downtime in advance
- Decide the procedure and owner for restoring data after recovery
Performance and scalability
Performance and scalability disclose supported user counts, concurrent access, and online response times. Whether it stays smooth at peak affects staff satisfaction.
Confirm that screens respond usefully fast under many simultaneous terminals at peak, given your scale of terminals across doctors, nurses, and clerks.
Scalability also matters, whether growth in beds, departments, or contracted checkups can be accommodated. Ask for disclosure covering not just current scale but the outlook a few years ahead.
- Supported user counts and concurrent access
- Online response times for key screens
Operations and maintainability
Operations and maintainability disclose vendor response time on incident detection and on-site dispatch. When and how support arrives matters most where IT staff are few.
- Vendor response availability on incident detection
- On-site dispatch availability, lead time, and remote support
- Methods and frequency of regular updates and patches
Migratability
Migratability discloses the division of migration work between hospital and vendor and the scope and frequency of rehearsals. For hospitals switching systems, this is especially important.
Migration is the biggest hurdle of a project. With the common migration layout from Part 2, agreeing early on what data, by whom, and how tested greatly reduces trouble.
Migration failure leads directly to chaos right after go-live. Nailing down the range of past data, handling of non-migratable items, and how to fix mismatches found in rehearsal, based on the disclosed details, is key to a safe cutover.
- Division of migration work between hospital and vendor
- Scope and frequency of rehearsals and the cutover procedure
Security and related guidelines
The non-functional requirements connect to guidelines for handling medical information. The spec maps relationships to the safe-management guidelines for medical information systems and the METI guidelines for providers handling such information.
It also references the Digital Agency's GCAS guide and the government's guideline on introducing vulnerability diagnostics. With cloud use assumed, complying with these underpins trust.
Medical information is highly sensitive, and any leak severely affects both patients and the hospital. The spec maps these guidelines so hospitals can grasp the key checkpoints without researching from scratch.
- MHLW guidelines for the safe management of medical information systems
- METI safety-management guidelines for providers handling medical information
- Digital Agency GCAS guide and the vulnerability-diagnosis introduction guideline
The vulnerability-diagnosis perspective
An appendix covers vulnerability diagnosis, the practice of periodically checking systems for security weaknesses, important for reducing the risk of external attacks.
Since small and mid hospitals cannot easily run advanced diagnostics themselves, it is reassuring to confirm how often and how broadly the vendor runs them and how it responds to findings.
Cloud-native products can have the vendor handle such diagnostics and updates centrally, an advantage that matters more for hospitals unable to keep advanced security staff in-house.
Disclosure-item interview checklist
Non-functional requirements easily stay vague verbally. Having vendors disclose specific levels in writing via the disclosure items makes comparison clear. Here are minimum checks.
- Are operating hours, planned outages, and RTO/RLO given as concrete figures?
- Do DR and redundancy policies align with your BCP?
- Do concurrent access and response withstand your peak scale?
- Do vendor response and dispatch match your operating hours?
- Are migration roles and rehearsals a realistic plan?
- Compliance with safety guidelines and vulnerability-diagnosis practice
How to adopt using the spec (RFP)
The spec is a common language for hospitals and vendors. Using it as the backbone of an RFP or requirements definition improves comparison accuracy and negotiation transparency.
Concretely, check the function list for needed features and have vendors disclose availability, security, and migration via the disclosure items, enabling objective evaluation free of sales talk.
- Trim the function list to essentials and have vendors answer implementation status
- Present disclosure items and require written levels for each area
- Tabulate answers side by side and decide jointly across management, staff, and IT
Review after contracting and go-live
Non-functional requirements are not settled at contract time. Required levels change over time with new departments, more patients, or policy revisions. It is important to periodically compare actual operating results with the original targets.
For example, recording the actual RTO during an incident and whether response stayed within expectations, and reviewing these regularly with the vendor, helps maintain and improve quality over time.
- Keep records of uptime and incident handling and compare to targets periodically
- Revisit performance and availability needs as departments and patient volume change
Anticipated Q&A
- Q. Can non-functional wait? A. No. It governs continuity during incidents; check early.
- Q. Is a shorter RTO always better? A. Safer but costlier; balance against your tolerance.
- Q. Are you worried about cloud security? A. Confirm guideline compliance and vulnerability diagnostics to judge.
Summary
Non-functional requirements determine whether an EHR can be relied on over time. Using the disclosure items, even small and mid hospitals can objectively check availability, performance, operations, migration, and security.
Sakigake aims for a cloud-native EHR aligned with the standard's philosophy. Across three parts we read the spec from both functional and non-functional sides. As rules may be revised, always confirm the latest via MHLW and Digital Agency primary sources.
RELATED ARTICLES