Part 2 looks at the core of the standard EHR spec, the presented-function list, a systematic inventory of the functions an EHR should provide, tied directly to vendor selection.
As Part 1 showed, the standard rests on two pillars, functional and non-functional requirements. This part addresses the former, down to how to read it and use it in selection.
What the presented-function list is
The presented-function list arranges the functions an EHR should provide by category and lets a product indicate its implementation status, so hospitals can compare multiple products on the same objective basis.
Previously, feature comparison relied on each vendor's materials and demos, with inconsistent granularity. A common list format levels the field and helps spot gaps.
The list is not an endless wish-list of nice-to-haves but a systematic selection of functions needed for standard small and mid hospital operations, which is why it rewards matching item by item to your work.
Reading the table's columns
The list has columns such as item number, category, function name, functional requirement, implementation status, and remarks. Read the requirement description and remarks together with the function name.
The requirement column defines what is expected of the function. Skipping it hides differences behind identical names. The remarks column often notes substitutes or constraints that decide real-world feasibility.
- Item number and category: which business area the function belongs to
- Function name and requirement: what is required and to what level
- Implementation status: the vendor answers with the marks
- Remarks: substitutes, constraints, and supplements
The four implementation marks
Implementation status uses these four marks. Understanding them precisely is the first step, especially not confusing full implementation with substitution or partial.
The four marks are not a yes/no binary but include a gradient of substitution and partial implementation. How you evaluate these middle marks often separates good selection from poor.
- ● Implemented: the described capability is implemented in full
- ○ Substitutable: no dedicated function, but achievable via other functions
- △ Partial: part of the described capability is implemented
- × Not implemented: not present and not substitutable
How to interpret the marks (practical tips)
More filled circles do not simply mean a better product. What matters is full marks on the functions you actually use; marks in unused areas do not count. Narrow down your essential functions first.
Watch out for substitutable and partial marks. Check whether a substitute is an acceptable effort in practice, and which part a partial mark lacks, via remarks or a live demo. Technically possible is not the same as workable.
- Build your essential-function list first, then compare marks only on those items
- For substitutable and partial items, read the remarks and confirm the steps on a live system
- If an unimplemented item is critical, ask the vendor about development plans and timing
Coverage: about 270 items across 30-plus categories
The list spans roughly 270 items across more than 30 categories, covering broad hospital operations from outpatient to inpatient, home care, checkups, and document and master management along the clinical flow.
Below we walk through this range by business cluster. Reading with your departments in mind clarifies which clusters carry heavy requirements.
The roughly 270 items look many, but areas you do not perform can be dropped. Simply sorting used from unused clusters trims the items to a realistic number.
Outpatient: booking, reception, consultation, records
The outpatient area is where patients first engage and where volume is high, from booking and reception through consultation, records, diagnosis management, and referral documents.
- Booking, reception, and patient call-up
- Consultation and progress notes, template entry
- Diagnosis registration, outcome management, referral letter creation
Examinations: specimen, physiology, imaging, endoscopy
Examinations cover ordering and result viewing across many departments, including specimen, bacteriology, pathology, physiology, radiology, and endoscopy. Integration with existing lab and imaging systems is a frequent issue.
- Ordering and viewing for specimen, bacteriology, and pathology
- Ordering and image or report viewing for physiology, radiology, and endoscopy
- Time-series display and reference-range support for results
Treatment: from prescriptions to surgery
Treatment is the most frequent and safety-critical area, from prescriptions, procedures, and injections to dialysis, rehabilitation, guidance, chemotherapy, and surgery.
Chemotherapy regimen management and surgery ordering carry heavy requirements where performed. Separate essential from irrelevant items based on what your hospital actually does.
Since treatment ties directly to safety, dosage checks, interaction alerts, and reliable execution records matter. Beyond the marks, verify how such safety features are built in a live demo.
- Prescription, procedure, and injection ordering and execution records
- Ordering and records for dialysis, rehabilitation, and guidance
- Chemotherapy regimen management and surgery-related functions
Inpatient and bed management
Inpatient functions involve bed management, patient-status management, meals, and billing linkage, spanning many professions. Nursing records and status visualization strongly affect ward efficiency.
- Admission, discharge, transfer, and bed availability
- Patient-status management, nursing records, and observation records
- Meal ordering and billing linkage
Home care: visit care, nursing, rehabilitation
Home care covers off-site work such as visit care, visit nursing, and visit rehabilitation, an area where small and mid hospitals play a large community role, raising issues of mobile recording and plan management.
If your hospital emphasizes home care, coverage here can decide the selection. Check ease of entry on visits and support for creating plans and reports.
In home settings the network can be unstable, so offline entry and later synchronization are practical concerns. The more a hospital carries community-based care, the more this area's design matters.
- Planning, recording, and scheduling for visit care
- Instructions, records, and reports for visit nursing
- Plans and execution records for visit rehabilitation
Checkups, documents, and masters
The list also includes checkups, document creation and management, and master management that underpins the system. Master management is unglamorous but vital to sustainable operation.
- Booking, execution, results, and notification for checkups
- Creation and management of certificates, forms, and consent documents
- Management and updates of drug, diagnosis, and procedure masters
Data migration, departmental integration, and APIs
Beyond the function list, the specification organizes appendices for a common data-migration layout, common integration specs, inter-departmental APIs, and efficiency-service APIs.
These matter for migration when switching and for integrating existing lab or imaging systems. The common migration layout in particular helps avoid lock-in and makes future switching realistic.
In selection, confirm not just the functions but which APIs connect to your existing departmental systems and how far. Integration greatly affects post-adoption workload.
Efficiency-service APIs are gateways to safely link external services for input assistance and clerical automation. Standardized APIs make it easier to combine new services on top of the EHR.
What to verify in a live demo
Even with many filled marks, the table cannot show usability or entry effort. A live demo translates the numbers into a feel for real operation. Involve frontline staff and try daily-workflow scenarios.
Running a full flow for a busy outpatient scene, from reception to billing, reveals hidden burdens like screen transitions and clicks that the table omits, shaping post-adoption satisfaction.
- Prepare representative clinical scenarios in advance and have them operated
- For substitutable and partial functions, confirm the actual steps or missing parts on the spot
- Have usability judged by role, including doctors, nurses, and clerks
How to use it in selection (checklist)
Here is a procedure for turning the list into actual selection. The point is to read from your operations, not from the product.
- List needed functions along the list's categories
- Compare marks side by side, limited to essential functions
- For substitutable and partial items, verify feasibility via remarks and a live demo
- For critical unimplemented items, confirm workarounds or development timing
- Check migration realism and integration via the migration layout and APIs
AI-native EHR as an option
The spec sets a common baseline of functions to provide, but future EHRs also differ in how easily those functions are performed. Products designed around AI, for note-entry assistance or summarization, can greatly change the burden even for the same function.
The key is that AI does not replace the standard. First meet the required functions and quality along the standard, then evaluate AI as a way to enhance the experience, which is the sound order.
Sakigake aims to lighten daily work at small and mid hospitals with an AI-native experience aligned with the standard's philosophy. Consider both function coverage and usability in selection.
Anticipated Q&A
- Q. Are all-filled marks ideal? A. No. Full marks matter only for functions you use.
- Q. Who fills in the marks? A. The vendor. Verify via remarks and a live system.
- Q. Must all 270 items be reviewed? A. Narrow to essentials first, then scrutinize those.
Summary
The presented-function list is a common basis for objectively comparing EHRs. Understanding the marks and checking essentials against your operations improves selection accuracy.
Sakigake aims to provide an AI-native EHR for small and mid hospitals aligned with this philosophy. Part 3 covers non-functional requirements. Always confirm the latest via MHLW and Digital Agency primary sources.
RELATED ARTICLES