Waroku Hospital Karte

Waroku Hospital Karte is a cloud-based electronic medical record and clinical workflow platform for psychiatric hospitals in Japan. It is much more than a chart viewer: doctors, nurses and support teams use it to find patients, run inpatient and outpatient care, manage wards and beds, schedules, tasks and handovers — and, above all, to create, confirm, accept and execute clinical orders.

From 2021 to 2022 I was the Tech Lead of the development team in Vietnam. Our scope was the frontend, in Vue, Nuxt and TypeScript, on an existing codebase and component structure; the team had frontend developers, an IT communicator and junior members, and the specifications came from Japan.

Why it is a management-system project: a hospital system is dozens of modules sharing one patient, one organisation and one set of staff, beds and orders. A single action can change a patient's status, their bed, an order, a schedule and who has to act next. Screens that look right can still get the clinical workflow wrong — so leading the work meant understanding that workflow well enough to prevent it.

Modules and how people reach them

Every module shares the same core: patient identity, hospital and organisation, doctor and nurse identity, department, ward, room and bed, orders, schedules, execution status and clinical history.

Authentication and the hospital context come first; they decide what the header and the menu offer.

My responsibilities

Held the overall frontend architecture and its integration with the APIs, and guided the team to build within the existing codebase and component structure.
Reviewed implementation and pull requests, and kept shared components, reusable modals and conventions consistent across a very large number of screens.
Analysed screen and API specifications with the team and explained the clinical business behind them.
Took on screens with complex business rules and the dependencies between screens and modules, and assessed how a change would affect related workflows.
Debugged issues between the frontend and the APIs.
Tracked the team's technical progress and supported junior members and interns.
Acted as the technical bridge between the Japanese specifications and the implementation in Vietnam.

One entry point: sign-in, hospital context and patient search

Staff sign in with a login ID and password, with password reset and change; two-factor authentication appears in the requirements. The session decides more than access: it decides which menus and workflows a user may use. A user can belong to, and switch between, several hospitals in a group and organisation, and some menus — rehabilitation and instruction sub-menus, for example — differ by hospital, so the menu is served by the API rather than hard-coded.

The global header searches patients from anywhere: Katakana names by forward match, patient numbers by exact match. A result opens the patient's Karte, which makes search the entry point into the clinical workflow.

From sign-in to the patient's chart in a few steps, whichever screen the user starts from.

Menus that follow the role

The global menu is a map of the hospital's work, not a static navigation bar. It groups shared functions (work tasks, schedule, countersignature, announcements, handover), ward and inpatient work (nursing management diary, patient status list, doctor and nurse patient lists, bed map, ward-round input, flow sheet, leave and overnight stays, movement restriction, ward nursing diary), outpatient lists and journals, orders (order list, execution list, completed orders, booking confirmation, laboratory output), individual and group rehabilitation, individual and group instruction, conferences, and PSW consultation and PSW logs.

Doctors and nurses do not get the same menu or the same authority; the role decides both.

The Karte

The Karte — the patient chart — is the centre of the patient's workflow: the basic tab and patient information, the patient schedule, life history, chart entries, order entry and order history, and clinical information. From it, doctors and nurses view history, record clinical information, create orders, manage the schedule and move into the specialised modules. The schedule is more than a calendar: it combines the patient's appointments with staff and facility schedules, tasks and to-dos.

Clinical orders: the largest module

Orders are one of the core workflows of the whole system. There are five basic types — prescription, injection, examination, treatment and imaging — plus specialised orders such as psychological and physiological examinations, CT and X-ray, meals, transfers, task instructions and discharge or transition to outpatient care. More types can be added through the API, so the module works as an order framework in which each type brings its own form and rules.

One order framework, many order types, each with its own form and rules.

Regular and conditional orders. Besides regular orders, an IF order runs only when a set condition occurs, so it has to store its trigger condition, title, comment, state and execution logic.
The order cart. On the Karte, a doctor fills in orders tab by tab; an order is created for the current tab only when it is added to the cart, and what was entered on other tabs stays in place. The cart works as a staging area before a clinical order is confirmed.
Confirmation. Some orders need approval, consent, countersignature or several levels of confirmation, and the order list shows each confirmation step.
Acceptance and execution. Once confirmed, an order moves to the global order lists, where the appropriate staff accept it and become responsible for executing it. Execution records the date and time, the executor, the status and inputs specific to the order; X-ray, injection and treatment have their own execution screens.
Bulk execution is allowed only where it makes sense: the checkbox is disabled for orders that cannot be executed together, depending on type, state, booking, acceptance and readiness.
Search filters by patient, age, sex, order date, department, ward, doctor, nurse and rehabilitation team, and users can save, clear and reuse their search conditions.

An order does not go from created to done. It is confirmed, accepted and executed by different people — and can be changed, suspended or cancelled along the way.

Order types with their own rules

Prescription: inpatient or outpatient, department, insurance, prescription type, start and end dates, drug information, previous prescriptions, comments, a medicine information sheet, IF orders and immediate execution. The system can raise warnings before the order is created; the doctor confirms them, goes back to edit, or continues — a clinical safety step inside the workflow.
Examinations and imaging: psychological, physiological and laboratory examinations, CT and X-ray, each with department, insurance, schedule, ordering method and execution status. Imaging instructions can be temporary or recurring, for one day, several days, a date range or a date not yet fixed; X-ray execution records the order number, time and executor, and asks for re-confirmation when the order changes.
Treatment: temporary or recurring, with an execution schedule, comments and responsible staff.
Meals: meal orders and history, meal types and time slots, temporary changes, comments and the period a change applies to.
Transfers: date and time, department, insurance, building, room, bed and primary physician.
Discharge and transition to outpatient care: a status change that other modules have to follow.

Inpatient care and nursing

Inpatient work has its own lists and views: the patient status list, doctor and nurse patient lists, a bed map by ward, room and bed, ward-round input for doctors, the flow sheet, and ward and outpatient nursing journals. Leave and overnight stays have a full request lifecycle — period, status, history, cancellation and return — and movement restrictions have their own lists. Because transfers and discharges change bed status, the bed map has to stay in step with patient movement.

The inpatient sits at the centre of status, place, care and orders — and every one of them moves.

Schedules, tasks and team communication

Care is organised as team tasks: each has an executor, the instruction, comments, who issued it, a deadline and a status, and it can be registered straight from the patient chart. Around the tasks sit handover, announcements, notifications, and an entry point to chat in the header.

Patient, staff and facility schedules meet in one place and turn into the day's tasks.

Building a frontend of this size

The frontend uses Nuxt's file-based routing, with components, general components, hooks, pages, plugins and assets kept apart. Shared pieces — a staff selector, modals, reusable form components — are written once; Vuetify is the UI framework, with SCSS for overrides, and Axios talks to the API. To build many screens in parallel before the APIs were ready, the project defined API mocks with axios-mock-server, so frontend work did not wait on backend work.

Specifications become mocks and components first; the real API arrives at the end, not the start.

Architecture

The browser runs the Nuxt, Vue and TypeScript application, which calls the backend APIs through Axios. The development documents describe PostgreSQL on AWS RDS, Redis in the sign-in flow, and S3 for images and content in selected workflows. The backend framework is not named here: the source documents are not specific enough to state it.

A component-level view of what the project documents show — not a copy of the production infrastructure.

What the project covers

Concern in a large management system	How it shows up in Waroku Hospital Karte
Many roles, one system	Doctor, nurse and support menus built from role and authority
Multi-organisation configuration	Group, organisation and hospital context; hospital-specific menus served by the API
A workflow with many actors	Orders created, confirmed, accepted and executed by different people; change, suspend, cancel; conditional orders
Safety checks inside the workflow	Prescription warnings, approval, consent and countersignature before an order goes out
Resources that must stay consistent	Ward, room and bed placement kept in step with transfers and discharges
Scheduling across people and places	Patient, staff and facility schedules feeding team tasks
A very large screen surface	Shared components, reusable modals, conventions and API mocks for parallel work
Specifications in another language	Japanese screen and API specifications turned into implementation by a team in Vietnam

The diagrams are reconstructed at component level from the project's specifications. They omit internal URLs, identifiers, proprietary code and real patient or hospital data. The screenshots are demo wireframes with sample data.

Image 1 of 9