In March 2026, MHLW and the Digital Agency published version 1.0 of the Standard Specification (Basic Requirements) for EHRs and receipt computers for small and mid hospitals. It bears directly on how such hospitals select and replace EHRs.
As the first of three parts, this article places the document within the broader flow of medical DX, explaining why it was created and how it is structured. Part 2 covers functional requirements, Part 3 covers non-functional requirements and adoption.
For small and mid hospitals with limited IT staff, this specification becomes a common yardstick for discussing requirements in the same language as vendors. Grasping the overall picture is the first step toward a realistic adoption plan.
What the standard specification is
The document is a specification setting out basic requirements for EHRs and receipt computers at small and mid hospitals, developed jointly by MHLW and the Digital Agency. It does not point to any specific vendor product.
In short, it is a national baseline of the functional and non-functional (quality) requirements an EHR should meet. Hospitals can build their own additional requirements on top of this foundation.
Crucially, it is both a minimum baseline and a common comparison sheet. The key is to separate what must be satisfied as an obligation from where products differ.
Five points to grasp first
Before the details, here is a five-point overview of the background. Sharing this big picture first makes later discussion smoother in a busy setting.
- Under the medical DX roadmap, the government aims for roughly universal EHR adoption by 2030
- An amendment to the Medical Care Act legally sets a target of roughly 100% adoption by end of 2030
- Escaping the high-cost structure of on-premise, heavily customized systems is a key challenge
- The government formulated the basic requirements during FY2025 as a common foundation for cloud-native systems
- Rules and figures may be revised, so the latest must be confirmed via MHLW and Digital Agency primary sources
Background: the medical DX roadmap and the nationwide platform
Under the medical DX roadmap, Japan is building a nationwide health-information platform and standardizing EHR data step by step, aiming to safely share clinical information across institutions.
For such a platform to deliver value, each institution must first have an EHR and be able to output standardized data. EHR adoption and standardization sit at the foundation of the platform vision.
The specification is thus not a standalone measure but one piece of a larger picture of nationwide data linkage. Understanding this context clarifies why the requirements are so detailed.
The roadmap advances several measures in stages, such as electronic prescriptions and EHR information-sharing services. The specification moves in step with these and may be revised as policy evolves.
The 2030 goal and the Medical Care Act amendment
For EHRs, the aim is roughly universal adoption by 2030 at the latest. A 2025 amendment to the Medical Care Act legally states a target of roughly 100% adoption by the end of 2030.
A legally stated target carries different weight than a mere aspiration. With this in law, EHR adoption is shifting from something to consider eventually into a management issue with a deadline.
Especially for small and mid hospitals with no EHR or aging systems, the timing of replacement and alignment with the standard should be discussed early at the management level.
Why a standard specification is needed
Traditional hospital EHRs were largely on-premise systems premised on bespoke customization. With in-house servers and per-site tailoring, both initial and renewal costs tended to be high, producing a high-cost structure.
The government set a direction to shift toward cloud-native systems and formulated the standard requirements during FY2025 as a shared foundation. A common baseline helps avoid excessive customization and opaque quotes.
The aim is to let hospitals and vendors check requirements against the same yardstick, reducing personalized requirements work and improving the transparency of comparison and negotiation.
What changes with cloud-native adoption
Cloud-native adoption is not merely moving servers off-site. It changes how software updates, disaster resilience, and security are handled. It helps to organize what this means for small and mid hospitals.
With on-premise systems, each legal or fee revision meant individual modification work, raising cost and effort. Cloud systems tend to deliver such updates centrally, easing the burden.
At the same time, new points arise, such as network conditions and compliance with cloud safety-management guidelines. Understanding both benefits and checks lets you choose what fits.
- Responses to legal and fee revisions tend to come from the shared platform
- Remote data holding improves recoverability after disasters
- New checks arise, such as network conditions and safety-management compliance
Structure: Chapter 1 and Chapter 2
The specification has two main parts: Chapter 1 is the EHR standard specification, and Chapter 2 is the receipt-computer standard specification, covering clinical recording and ordering, and receipt claims respectively.
Each chapter covers functional and non-functional requirements, architecture, data migration, and system integration. Separating features from quality attributes forms the document's backbone.
Along this backbone, Part 2 of this series covers functional requirements (the presented-function list) and Part 3 covers non-functional requirements (disclosure items based on IPA grades).
Overview of the appendices
In addition to the main text, the specification includes many practical appendices tied directly to comparison, migration, integration, and security work.
- Presented-function list: a systematic inventory of EHR functions (detailed in Part 2)
- IPA non-functional grades: compliance items and disclosure items for quality attributes (Part 3)
- Common data-migration layout: shared item definitions for migration when switching systems
- Common integration specs and inter-departmental APIs: how to connect existing lab or imaging systems
- Efficiency-service APIs: APIs to link external services and streamline operations
- Vulnerability-diagnosis guideline: the approach to checking security vulnerabilities
How functional and non-functional requirements relate
Functional requirements express what a system can do; non-functional requirements express how reliably it can be used over time. The former is visible in demos, while the latter concerns availability and security that are hard to see in normal times.
In selection, attention often goes to flashy features, yet operational failures frequently stem from overlooked non-functional aspects. Evaluating both together is essential.
The specification separates the two clearly so hospitals check both without gaps. Parts 2 and 3 dig into each, but the starting point is recognizing that features and quality are distinct.
What it means for small and mid hospitals
The specification gives small and mid hospitals, often with limited IT capacity, a common basis for comparing and selecting EHRs. Its greatest benefit is making it easy to check side by side how far each product meets the requirements.
Procuring along the standard also helps avoid excessive lock-in to a single vendor and improves the outlook for future switching and data migration.
That said, the specification is only a baseline. Requirements specific to a hospital's departments and workflows must be added on top. Treating the standard as a starting point is the realistic stance.
Procuring along the standard may also relate to subsidy or support requirements. To ease adoption costs, it is worth regularly checking, via primary sources, how current support programs relate to the specification.
Common misconceptions (anticipated Q&A)
Several misconceptions tend to arise about the specification. Here are representative questions.
- Q. Does compliance remove all customization? A. No. The standard is a shared base; hospital-specific needs are added on top.
- Q. Is the specification mandatory? A. Its status and application may change with policy, so confirm the latest primary sources.
- Q. Is this only for large hospitals? A. It is designed for small and mid hospitals, intended to be workable with limited resources.
- Q. Is cloud risky? A. It presumes compliance with safety-management guidelines and can offer benefits for disaster resilience and updates.
First steps for adoption (checklist)
To close Part 1, here are first tasks for a hospital holding the specification. Rather than jumping to product comparison, organizing your current state is the shortcut.
- Inventory renewal timing and support deadlines of current systems against the 2030 timeline
- Map your departments to the 30-plus categories to gauge needed functions
- Estimate the scope of data migration early, such as how many years of which data
- Articulate required levels for availability and security from actual clinical needs
- Set up early consensus-building among management, clinical staff, and IT
Mini glossary
- On-premise: running servers within the hospital; flexible but tends to be costly.
- Cloud-native: systems designed for the cloud, with benefits for updates and disaster resilience.
- Non-functional requirement grades: an IPA framework for organizing quality requirements like availability and performance.
- Receipt computer: a system that produces and submits medical-fee claims (receipts).
Summary
The standard EHR specification presents a common baseline, set against the 2030 adoption goal and the push toward cloud-native systems, comprising Chapter 1 (EHR), Chapter 2 (receipt computer), and many appendices.
Part 2 covers reading the functional requirements, and Part 3 covers non-functional requirements and adoption. As the specification may be revised, always confirm the latest via MHLW and Digital Agency primary sources.
RELATED ARTICLES