Waroku Home-Visit Nursing

Waroku Home-Visit Nursing is a cloud platform for home-visit nursing in Japan. Nurses and care staff visit patients where they live, so the system has to hold more than a chart: who the patient is, the home they live in, what care was ordered, how it is planned and scheduled, what happened at each visit, and how the patient is progressing.

In 2022 I was the Project Leader and Tech Lead of the development team in Vietnam. Our scope was the web frontend, in Vue with Vuetify, built against a REST API that the team in Japan delivered in stages. The team had several developers and an IT communicator; the specifications, designs and APIs came from Japan.

Why it is a management-system project: every module comes back to one patient — their information, home, case records, orders, plans, schedules, visit records, reports and assessments — and to one organisation of offices, staff and roles. A single visit touches the schedule, the record, the diary, the report and the next assessment. Keeping dozens of screens consistent with that model, while designs and APIs kept changing, was the core of the job.

Modules and how they connect

About twenty groups of screens cover sign-in, the header and global menu, patients, patient information and living environment, case records and handover, home-visit nursing records, nursing orders, plans, schedules, diaries and reports, patient assessment, the monthly inventory, a feedback report for a research partner, and the management of offices, staff, organisations and files.

Everything starts from the context set at sign-in, and almost everything leads back to one patient.

My responsibilities

Reviewed implementation and pull requests, and checked that the UI and forms matched the design.
Owned the shared components and kept them consistent across developers.
Split and tracked tasks, handled issues that came up during each sprint and prioritised work to meet the client's milestones.
Resolved conflicts between the design and the API, and supported the team when an API was incomplete or differed from the design.
Tracked the progress of API integration.
Clarified requirements with the IT communicator and the team in Japan.
Controlled quality before screens went to QA testing, and assessed schedule and release risk.

Sign-in, organisation and office

Staff sign in with a user name and password, with a password reminder and a password change. A first sign-in with an initial password leads straight to changing it, which keeps account provisioning apart from the user's ownership of their password; otherwise the user lands on their initial page, usually the patient list. The sign-in and password APIs use an API key; after sign-in, every business API is called with the user's access token.

The sign-in response carries the context the rest of the system depends on: organisation, office, staff member, role, account type, initial page and token expiry. The header shows the organisation, the current office and the signed-in user, and lets the user switch office. The global menu is not hard-coded: the API returns its levels, order and names for the account and role, so one platform serves different organisations and account types — the standard account, a variant for a research partner with some screens and reports of its own, and management accounts.

Organisation, office, staff and role decide the menu — and the menu decides what the user can do.

The sign-in requirements also anticipate sharing accounts with Waroku Hospital Karte within the same organisation. That is a direction in the documents, not a feature I can confirm as shipped.

The care cycle

The system organises home-visit nursing as a cycle rather than a single chart. An assessment of the patient leads to a nursing order, which says what needs to be done, and the order to a nursing plan, which says how and when. The plan becomes monthly and daily visit schedules; each visit produces a record, a diary entry and a report, and the report feeds the next assessment.

What is learnt at one visit becomes the input of the next assessment and plan.

One patient at the centre

The patient list is the main entry point: search, filters, groups, care levels and summary counts, then the patient's information. Patient information — the patient's chart — holds identity, date of birth and age, blood type, height, weight, BMI and BSA, address and contact details, and related doctors, hospitals and departments. From it, staff move into every other workflow of that patient.

Information, home, records, files and the whole chain from order to report hang off one patient.

The patient's home

The living environment is specific to care at home, because the care that can be given depends on the place. The system records the floor plan; the room — private or not, floor, lift, bed or mattress, lighting, heating and air conditioning; the toilet — type, handrails and steps; the bathroom — handrails and steps; and facilities such as the washing machine, water heater, refrigerator and kitchen. Every area can carry notes and photos, so staff record the conditions as they are, not only in words.

Five areas of the home, each with its own notes and photos.

Case records and handover

A case record is a flexible model shared by many kinds of care information: a title and free text, the author, receivers who are staff members or groups, a linked order and order type, tags, flags for important, urgent, handover, private and history, and attachments. The handover flag turns a record into information passed between shifts, staff, groups and offices, and comments on a record were expected to behave close to a real-time chat. Tags have their own create, read, update and delete APIs.

One record model carries receivers, flags, tags and files — and marks what must be handed over.

Orders, plans and schedules

Nursing orders are the instructions for care at home, with list, create, edit and detail screens. The list comes in normal, special and psychiatric variants.
Nursing plans sit between the order and the actual schedule: list, detail and edit, with assessment-related data and a variant for the research partner.
Visit schedules come in two views, monthly and daily, and tie together the patient, staff, time, office and the state of the plan.

Visit records, diaries and reports

Home-visit nursing record I has a history list, create and edit, detail, business forms, conversion into a case record, printing and attachments. Record II has PC, mobile and research-partner variants, and part of it belongs to a later phase. After visits, staff write the nursing diary, with a list, detail and edit, a calendar and printing. Nursing reports come in normal, psychiatric, combined and attachment types, with detail, edit and print screens and, on some screens, an electronic stamp for approval; the combined type adds GAF data.

A visit is recorded, written up, reported and reviewed — and becomes part of the patient's history.

Assessments that track progress

Assessment is split by method — bedsore (pressure ulcer), ADL, IADL and GAF — and by time, so the system follows change rather than a single score. Bedsore assessments keep their images through a file route of their own. The personal assessment shows one patient's domains block by block; the overview assessment brings many domains onto one screen, with many APIs, blocks and data formats. The month-end inventory summarises a month of home-visit nursing for each patient and links to patient information and assessment progress, and the research-partner variant adds a feedback report of its own.

Four assessment methods feed one patient's assessment — and, over time, a history of progress.

Files everywhere

Attachments cut across the whole system and go through one file service. A file is uploaded first; the API stores it in Amazon S3 and returns its UUID, name, size, URL, thumbnail URL and content type; the business record then refers to it by UUID. Upload routes are scoped by purpose: bedsores, prescriptions, living environments, nursing orders, case records and staff stamps.

Upload first, then link: the clinical record keeps only a reference to the file.

API, authentication and permissions

The REST API speaks JSON with GET, POST, PUT, PATCH and DELETE, grouped into authentication, accounts, patients, staff, organisations, offices, assessments, case records, nursing records, orders, plans, schedules, reports, files, tags and master data. Select boxes and forms take their options — roles, care levels, assessment methods, body parts, prefectures, departments, order types — from master-data APIs instead of hard-coding them. Not every user may call every API: permission checks combine role, organisation, office and account type, and errors distinguish invalid parameters, authentication, permission, missing resources, unsupported methods, database errors and unexpected failures.

An API key to sign in, a bearer token after that, and a permission check on every call.

Leading a team through changing designs and staged APIs

APIs arrived after the UI. The team built screens first on mock data, read the API specifications, integrated the real API later and fixed the places where the API differed from the design.
Designs kept changing. New designs, conflicting pages, APIs that disagreed with the design, blocks to rebuild, tabs and menus that moved, screens without a full design. My job was to keep those changes from turning into different implementations by different developers.
Shared components — header, global menu, patient header, tables, form blocks, popups, select boxes, notifications, assessment blocks — so that many domains used the same pieces. Assessment domains were split across several developers on top of them.
Quality before QA. A screen went through implementation, pull request and review, deployment to development and QA testing; bugs came back for fixing and retesting, and the daily meetings tracked where each page stood.
Tablet as well as desktop. Lists and tables needed horizontal scrolling, alignment that holds, and layouts for 4:3 and tablet screens. The 2022 phase was a responsive web application; the documents do not show a native app in it.

The Phase 1 release covered sign-in and password, patients and their chart, living conditions, assessment, case records, nursing records, orders, plans, reports and departments, with their detail and edit screens.

Mocks let screens move before the API was ready; review and QA decided when they were done.

Architecture

The browser or tablet runs the web frontend, built with Vue and Vuetify, which calls the REST API. The API checks the API key or access token, then the role and permission, before the business services run; files go through the file service to Amazon S3. The backend framework, the database engine and the rest of the infrastructure are not named here: the API was built on the Japanese side, and the documents are not specific enough to state them.

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 Home-Visit Nursing
One entity at the centre	Information, home, records, files, orders, plans, visits, reports and assessments all hang off the patient
Multi-organisation context	Organisation, office, staff and role set at sign-in; office switching; menus served by the API
Variants of one product	Standard, research-partner and management accounts, with screens and reports that differ by account type
A workflow that loops	Assessment, order, plan, schedule, visit, record, diary, report, and back to assessment
Information passed between people	Case records with receivers, flags, tags and handover
Files as part of the record	One file service on S3 for bedsores, prescriptions, homes, orders, records and stamps
Security on every call	API key, bearer tokens, permission checks by role, organisation, office and account type
Delivery under moving specifications	Mock data, shared components, review and QA while designs and APIs changed

The diagrams are reconstructed at component level from the project's specifications. They omit internal URLs, identifiers, API routes, proprietary code and real patient data. The screenshots are demo wireframes with sample data; the operator's name, the research partner's label, portrait photos and street addresses in them are blurred.

Image 1 of 8