---
title: "Waroku Hospital Karte — Cloud EMR for Hospitals — Tran Manh Tuan"
description: "A cloud medical record and clinical workflow platform for psychiatric hospitals in Japan: patient charts, multi-step clinical orders, wards, beds, nursing and schedules."
canonical: "https://tmtuan.dev/en/projects/waroku-hospital-karte"
language: "en"
image: "https://tmtuan.dev/_img/projects/waroku-hospital-karte/waroku-hospital-karte.024f06f2-og.jpg"
tokens: 5249
---

# 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.

```mermaid
flowchart TB
    accTitle: Waroku Hospital Karte system overview
    accDescr: Doctors, nurses and other staff sign in through role-based authentication and enter a hospital and organisation context. That context decides the global header and the role-based global menu. The header leads to patient search, and search opens the patient's Karte. The global menu leads to the Karte, inpatient care, outpatient care, order management, schedules and tasks, nursing, rehabilitation, and conference, PSW and support. From the Karte, users create orders and manage schedules.

    STAFF["Doctors / nurses / staff"]

    AUTH["Authentication / role"]
    HOSPITAL["Hospital / organisation context"]

    HEADER["Global header"]
    MENU["Role-based global menu"]

    SEARCH["Patient search"]
    KARTE["Karte / patient chart"]

    INPATIENT["Inpatient"]
    OUTPATIENT["Outpatient"]
    ORDER["Order management"]
    SCHEDULE["Schedule / task"]
    NURSING["Nursing"]
    REHAB["Rehabilitation"]
    SUPPORT["Conference / PSW / support"]

    STAFF --> AUTH
    AUTH --> HOSPITAL
    HOSPITAL --> HEADER
    HOSPITAL --> MENU

    HEADER --> SEARCH
    SEARCH --> KARTE

    MENU --> KARTE
    MENU --> INPATIENT
    MENU --> OUTPATIENT
    MENU --> ORDER
    MENU --> SCHEDULE
    MENU --> NURSING
    MENU --> REHAB
    MENU --> SUPPORT

    KARTE --> ORDER
    KARTE --> SCHEDULE
```

_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.

```mermaid
flowchart LR
    accTitle: From patient search to the patient's workflow
    accDescr: A user signs in, selects or confirms the hospital, then searches for a patient from the global header. The search result opens the patient's Karte, and from the Karte the user moves on to orders, the schedule, history and clinical information.

    LOGIN["Login"]
    HOSPITAL["Select / confirm hospital"]
    HEADER["Global header"]

    SEARCH["Find a patient"]
    RESULT["Search result"]
    KARTE["Karte"]

    ORDER["Orders"]
    SCHEDULE["Schedule"]
    HISTORY["History"]
    CLINICAL["Clinical information"]

    LOGIN --> HOSPITAL
    HOSPITAL --> HEADER

    HEADER --> SEARCH
    SEARCH --> RESULT
    RESULT --> KARTE

    KARTE --> ORDER
    KARTE --> SCHEDULE
    KARTE --> HISTORY
    KARTE --> CLINICAL
```

_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.

```mermaid
flowchart TB
    accTitle: Role-based navigation
    accDescr: A signed-in user is sorted by role and authority into three menu groups. The doctor menu leads to orders, diagnosis, the Karte and the doctor's patient list. The nurse menu leads to the nursing journal, the flow sheet and the nurse's patient list. The common menu leads to tasks and schedules, chat and announcements, and patient search.

    USER["Signed-in user"]
    ROLE{"Role / authority"}

    DOC["Doctor menu"]
    NURSE["Nurse menu"]
    COMMON["Common menu"]

    DOC_ORDER["Orders / diagnosis / Karte"]
    DOC_PATIENT["Doctor's patient list"]

    NURSE_LOG["Nursing journal / flow sheet"]
    NURSE_PATIENT["Nurse's patient list"]

    TASK["Task / schedule"]
    CHAT["Chat / announcement"]
    SEARCH["Patient search"]

    USER --> ROLE

    ROLE --> DOC
    ROLE --> NURSE
    ROLE --> COMMON

    DOC --> DOC_ORDER
    DOC --> DOC_PATIENT

    NURSE --> NURSE_LOG
    NURSE --> NURSE_PATIENT

    COMMON --> TASK
    COMMON --> CHAT
    COMMON --> SEARCH
```

_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.

```mermaid
flowchart TB
    accTitle: Groups of clinical orders
    accDescr: A clinical order has five basic groups: prescription, injection, examination, treatment and imaging. Examinations split into psychological and physiological examinations; imaging includes CT and X-ray. There are also orders for meals, transfers between departments, rooms and beds, task instructions, and discharge or transition to outpatient care.

    ORDER["Clinical order"]

    MED["Prescription"]
    INJ["Injection"]
    EXAM["Examination"]
    TREAT["Treatment"]
    IMG["Imaging"]

    PSY["Psychological exam"]
    PHYS["Physiological exam"]
    CT["CT / X-ray"]

    MEAL["Meal"]
    MOVE["Transfer / department / bed"]
    TASK["Task instruction"]
    DISCHARGE["Discharge / outpatient"]

    ORDER --> MED
    ORDER --> INJ
    ORDER --> EXAM
    ORDER --> TREAT
    ORDER --> IMG

    EXAM --> PSY
    EXAM --> PHYS
    IMG --> CT

    ORDER --> MEAL
    ORDER --> MOVE
    ORDER --> TASK
    ORDER --> DISCHARGE
```

_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.

```mermaid
flowchart TD
    accTitle: The lifecycle of a clinical order
    accDescr: A doctor opens the Karte, chooses an order type, enters the order and adds it to the order cart. The review and confirm step checks for warnings or a required approval: if there are any, they are handled or confirmed first; if not, the order is issued straight away. An issued order joins the order list, the responsible staff member accepts it, executes it, and it is completed. An issued or accepted order can still be changed, suspended or cancelled.

    A["Doctor opens the Karte"]
    B["Choose the order type"]
    C["Enter the order"]
    D["Add to the order cart"]

    E["Review / confirm"]
    F{"Warnings or approval needed?"}

    G["Handle warnings / confirm"]
    H["Issue the order"]

    I["Order list"]
    J["Staff accept the order"]
    K["Execution"]

    L["Completed"]
    M["Change / suspend / cancel"]

    A --> B
    B --> C
    C --> D
    D --> E

    E --> F

    F -- "Yes" --> G
    G --> H

    F -- "No" --> H

    H --> I
    I --> J
    J --> K

    K --> L

    H --> M
    J --> M
```

_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.

```mermaid
flowchart TB
    accTitle: Inpatient workflow
    accDescr: An inpatient has a patient status and a place by ward, room and bed. The status leads to doctor rounds, the nursing workflow and the flow sheet. The patient is also linked to meals, transfers, leave and overnight stays, movement restrictions and clinical orders. Clinical orders can lead to discharge, and a transfer updates the ward, room and bed.

    PATIENT["Inpatient"]

    STATUS["Patient status"]
    BED["Ward / room / bed"]
    ROUND["Doctor round"]
    NURSE["Nursing workflow"]
    FLOW["Flow sheet"]

    MEAL["Meal"]
    MOVE["Transfer"]
    LEAVE["Leave / overnight"]
    RESTRICT["Movement restriction"]
    ORDER["Clinical orders"]
    DISCHARGE["Discharge"]

    PATIENT --> STATUS
    PATIENT --> BED

    STATUS --> ROUND
    STATUS --> NURSE
    STATUS --> FLOW

    PATIENT --> MEAL
    PATIENT --> MOVE
    PATIENT --> LEAVE
    PATIENT --> RESTRICT
    PATIENT --> ORDER

    ORDER --> DISCHARGE
    MOVE --> BED
```

_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.

```mermaid
flowchart LR
    accTitle: Schedules and tasks
    accDescr: The patient's, the staff's and the facility's schedules all feed one schedule. The schedule produces tasks and to-dos, and the tasks connect to the daily clinical workflow.

    PATIENT["Patient"]
    STAFF["Staff"]
    FACILITY["Facility"]

    SCHEDULE["Schedule"]
    TODO["Task / to-do"]

    CLINICAL["Clinical workflow"]

    PATIENT --> SCHEDULE
    STAFF --> SCHEDULE
    FACILITY --> SCHEDULE

    SCHEDULE --> TODO
    TODO --> CLINICAL
```

_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.

```mermaid
flowchart LR
    accTitle: Frontend development flow
    accDescr: Screen and API specifications become API mocks, while the UI designs from XD become Vue components. Components use the mocked data to build Nuxt pages, which go through code review, are integrated with the real API, and are tested and debugged.

    SPEC["Screen / API specification"]
    DESIGN["UI / XD design"]

    MOCK["API mock"]
    COMPONENT["Vue components"]
    PAGE["Nuxt page"]

    REVIEW["Code review"]
    API["Real API integration"]
    TEST["Test / debug"]

    SPEC --> MOCK
    DESIGN --> COMPONENT

    MOCK --> COMPONENT
    COMPONENT --> PAGE

    PAGE --> REVIEW
    REVIEW --> API
    API --> TEST
```

_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.

```mermaid
flowchart TB
    accTitle: Waroku Hospital Karte high-level technical architecture
    accDescr: The hospital staff's browser runs a Nuxt, Vue and TypeScript application whose interface is built with Vuetify and SCSS. The application calls the backend APIs through an Axios API client. The backend APIs work with PostgreSQL on AWS RDS, Redis and AWS S3. The backend framework is not named because the source documents are not specific enough to state it.

    USER["Hospital staff browser"]

    NUXT["Nuxt / Vue / TypeScript"]
    UI["Vuetify / SCSS"]
    HTTP["Axios API client"]

    API["Backend APIs"]

    REDIS["Redis"]
    RDS["AWS RDS PostgreSQL"]
    S3["AWS S3"]

    USER --> NUXT
    UI --> NUXT

    NUXT --> HTTP
    HTTP --> API

    API --> RDS
    API --> REDIS
    API --> S3
```

_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.

## Details

- **Role:** Technical Lead · Frontend

## Technology

- Vue
- Nuxt
- TypeScript
- Vuetify
- SCSS
- Axios
- axios-mock-server
- PostgreSQL
- Amazon RDS
- Redis
- AWS S3

## Services this project shows

- [Custom Business Systems](https://tmtuan.dev/en/services/business-systems)

## Related articles

- [Docs-as-code Knowledge Base + Context Graph for a 15-project portfolio](https://tmtuan.dev/en/articles/knowledge-base-docs-as-code-context-graph)

## Structured data (JSON-LD)

```json
{"@context":"https://schema.org","@graph":[{"@type":"WebPage","@id":"https://tmtuan.dev/en/projects/waroku-hospital-karte#webpage","url":"https://tmtuan.dev/en/projects/waroku-hospital-karte","name":"Waroku Hospital Karte — Cloud EMR for Hospitals","description":"A cloud medical record and clinical workflow platform for psychiatric hospitals in Japan: patient charts, multi-step clinical orders, wards, beds, nursing and schedules.","inLanguage":"en","isPartOf":{"@id":"https://tmtuan.dev/#website"},"about":{"@id":"https://tmtuan.dev/#person"}},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://tmtuan.dev/en"},{"@type":"ListItem","position":2,"name":"Projects","item":"https://tmtuan.dev/en/projects"},{"@type":"ListItem","position":3,"name":"Waroku Hospital Karte","item":"https://tmtuan.dev/en/projects/waroku-hospital-karte"}]}]}
```