---
title: "Waroku Home-Visit Nursing — Điều dưỡng tại nhà — Tran Manh Tuan"
description: "Nền tảng cloud cho điều dưỡng tại nhà ở Nhật: bệnh nhân và nơi ở, case record và bàn giao, nursing order và kế hoạch, lịch thăm khám, báo cáo và đánh giá."
canonical: "https://tmtuan.dev/vi/projects/waroku-home-visit-nursing"
language: "vi"
image: "https://tmtuan.dev/_img/projects/waroku-home-visit-nursing/waroku-home-visit-nursing.1da7585d-og.jpg"
tokens: 5920
---

# Waroku Home-Visit Nursing

**Waroku Home-Visit Nursing** là nền tảng cloud cho nghiệp vụ điều dưỡng tại nhà ở Nhật Bản. Điều dưỡng và nhân viên chăm sóc đến tận nơi bệnh nhân sống, nên hệ thống phải giữ nhiều hơn một bệnh án: bệnh nhân là ai, sống trong ngôi nhà thế nào, được chỉ định chăm sóc gì, việc chăm sóc được lên kế hoạch và xếp lịch ra sao, mỗi lần thăm khám đã diễn ra thế nào, và bệnh nhân đang tiến triển ra sao.

Năm 2022, tôi là **Project Leader kiêm Tech Lead** của team phát triển tại Việt Nam. Phạm vi của team là web frontend bằng Vue và Vuetify, xây trên REST API do phía Nhật bàn giao theo từng giai đoạn. Team gồm nhiều developer và một IT communicator; specification, thiết kế và API đến từ phía Nhật.

> **Vì sao đây là dự án hệ thống quản lý:** mọi module đều quy về một bệnh nhân — thông tin, nơi ở, case record, order, kế hoạch, lịch, hồ sơ thăm khám, báo cáo và đánh giá — và về một tổ chức gồm office, staff và role. Một lần thăm khám chạm tới lịch, hồ sơ, nhật ký, báo cáo và lần đánh giá kế tiếp. Giữ hàng chục màn hình nhất quán với mô hình đó trong khi thiết kế và API liên tục thay đổi chính là phần cốt lõi của công việc.

## Các module và cách chúng nối với nhau

Khoảng hai mươi nhóm màn hình gồm: đăng nhập, header và global menu, bệnh nhân, thông tin bệnh nhân và môi trường sống, case record và bàn giao, hồ sơ điều dưỡng tại nhà, nursing order, kế hoạch, lịch, nhật ký và báo cáo, đánh giá bệnh nhân, tổng kết tháng, feedback report cho một đối tác nghiên cứu, và quản lý office, staff, organization và file.

```mermaid
flowchart TB
    accTitle: Tổng quan hệ thống Waroku Home-Visit Nursing
    accDescr: Điều dưỡng, staff và admin đăng nhập; đăng nhập xác định organization, office và role của họ. Từ đó họ vào quản lý bệnh nhân và thông tin của từng bệnh nhân. Thông tin bệnh nhân dẫn tới môi trường sống, case record và bàn giao, đánh giá, và nursing order. Order dẫn tới nursing plan, plan tới lịch thăm khám, lịch tới hồ sơ thăm khám, hồ sơ tới nursing diary, và diary tới nursing report. Đánh giá dẫn tới tổng kết tháng và feedback report của biến thể dành cho đối tác nghiên cứu.

    STAFF["Điều dưỡng / staff / admin"]

    AUTH["Đăng nhập"]
    ORG["Organization / office / role"]

    PATIENT["Quản lý bệnh nhân"]
    INFO["Thông tin bệnh nhân"]
    ENV["Môi trường sống"]

    CASE["Case record / bàn giao"]

    ORDER["Nursing order"]
    PLAN["Nursing plan"]
    SCHEDULE["Lịch thăm khám"]
    RECORD["Hồ sơ thăm khám"]
    DIARY["Nursing diary"]
    REPORT["Nursing report"]

    ASSESS["Đánh giá"]
    INVENTORY["Tổng kết tháng"]
    FEEDBACK["Feedback report cho đối tác"]

    STAFF --> AUTH
    AUTH --> ORG

    ORG --> PATIENT
    PATIENT --> INFO
    INFO --> ENV
    INFO --> CASE

    INFO --> ORDER
    ORDER --> PLAN
    PLAN --> SCHEDULE
    SCHEDULE --> RECORD
    RECORD --> DIARY
    DIARY --> REPORT

    INFO --> ASSESS
    ASSESS --> INVENTORY
    ASSESS --> FEEDBACK
```

_Mọi thứ bắt đầu từ context được xác định lúc đăng nhập, và gần như mọi thứ đều quay về một bệnh nhân._

## Vai trò của tôi

- Review implementation và pull request, kiểm tra UI và form có đúng thiết kế không.
- Phụ trách các component dùng chung và giữ chúng nhất quán giữa các developer.
- Chia và theo dõi task, xử lý vấn đề phát sinh trong từng sprint, ưu tiên công việc để kịp milestone của khách hàng.
- Xử lý conflict giữa thiết kế và API, hỗ trợ team khi API chưa hoàn chỉnh hoặc khác với thiết kế.
- Theo dõi tiến độ tích hợp API.
- Làm rõ requirement với IT communicator và phía Nhật.
- Kiểm soát chất lượng trước khi chuyển màn hình sang QA test, đánh giá rủi ro về lịch và release.

## Đăng nhập, organization và office

Nhân viên đăng nhập bằng tên người dùng và mật khẩu, có nhắc mật khẩu và đổi mật khẩu. Lần đăng nhập đầu tiên bằng mật khẩu khởi tạo sẽ chuyển thẳng sang bước đổi mật khẩu, tách việc cấp tài khoản khỏi quyền sở hữu mật khẩu của người dùng; nếu không, người dùng vào trang khởi đầu của mình, thường là danh sách bệnh nhân. API đăng nhập và mật khẩu dùng API key; sau khi đăng nhập, mọi API nghiệp vụ được gọi bằng access token của người dùng.

Response đăng nhập mang context mà cả hệ thống dựa vào: organization, office, staff, role, loại tài khoản, trang khởi đầu và thời hạn token. Header hiển thị organization, office hiện tại và người đang đăng nhập, và cho phép đổi office. Global menu không hard-code: API trả về các cấp menu, thứ tự và tên theo tài khoản và role, nên một nền tảng phục vụ được nhiều organization và loại tài khoản — tài khoản tiêu chuẩn, một biến thể cho đối tác nghiên cứu với một số màn hình và báo cáo riêng, và tài khoản quản lý.

```mermaid
flowchart TD
    accTitle: Context tài khoản sau khi đăng nhập
    accDescr: Đăng nhập xác định organization, rồi office trong organization đó, rồi staff và role của họ. Role quyết định global menu động, và menu quyết định người dùng dùng được những chức năng nào.

    LOGIN["Đăng nhập"]

    ORG["Organization"]
    OFFICE["Office"]
    STAFF["Staff"]
    ROLE["Role"]

    MENU["Global menu động"]
    APP["Chức năng được dùng"]

    LOGIN --> ORG
    ORG --> OFFICE
    OFFICE --> STAFF
    STAFF --> ROLE

    ROLE --> MENU
    MENU --> APP
```

_Organization, office, staff và role quyết định menu — và menu quyết định người dùng làm được gì._

Requirement đăng nhập còn tính tới việc dùng chung tài khoản với Waroku Hospital Karte trong cùng một tổ chức. Đó là định hướng trong tài liệu, không phải chức năng tôi xác nhận được là đã lên production.

## Chu trình chăm sóc

Hệ thống tổ chức nghiệp vụ điều dưỡng tại nhà thành một chu trình, không phải một bệnh án đơn lẻ. Đánh giá bệnh nhân dẫn tới nursing order — cần làm gì — và order dẫn tới nursing plan — sẽ làm thế nào và khi nào. Kế hoạch trở thành lịch thăm khám theo tháng và theo ngày; mỗi lần thăm khám tạo ra hồ sơ, nhật ký và báo cáo, và báo cáo lại trở thành đầu vào cho lần đánh giá kế tiếp.

```mermaid
flowchart TB
    accTitle: Chu trình điều dưỡng tại nhà
    accDescr: Chu trình bắt đầu từ bệnh nhân và một lần đánh giá. Đánh giá dẫn tới nursing order, order tới kế hoạch chăm sóc và thăm khám, kế hoạch tới lịch theo tháng và theo ngày. Lịch dẫn tới lần thăm khám tại nhà, thăm khám tới hồ sơ thăm khám, hồ sơ tới nhật ký, nhật ký tới báo cáo và báo cáo tới đánh giá tiến triển. Đánh giá tiến triển thành đầu vào của lần đánh giá tiếp theo, khép kín vòng lặp.

    PATIENT["Bệnh nhân"]
    ASSESS["Đánh giá"]
    ORDER["Nursing order"]
    PLAN["Kế hoạch chăm sóc / thăm khám"]
    SCHEDULE["Lịch tháng / ngày"]
    VISIT["Thăm khám tại nhà"]
    RECORD["Hồ sơ thăm khám"]
    DIARY["Nhật ký"]
    REPORT["Báo cáo"]
    REVIEW["Đánh giá tiến triển"]

    PATIENT --> ASSESS
    ASSESS --> ORDER
    ORDER --> PLAN
    PLAN --> SCHEDULE
    SCHEDULE --> VISIT

    VISIT --> RECORD
    RECORD --> DIARY
    DIARY --> REPORT
    REPORT --> REVIEW

    REVIEW --> ASSESS
```

_Điều ghi nhận được ở một lần thăm khám trở thành đầu vào của lần đánh giá và kế hoạch tiếp theo._

## Một bệnh nhân ở trung tâm

Danh sách bệnh nhân là điểm vào chính: tìm kiếm, lọc, nhóm, mức độ cần chăm sóc và số liệu tổng hợp, rồi tới thông tin bệnh nhân. Thông tin bệnh nhân — bệnh án của bệnh nhân — gồm định danh, ngày sinh và tuổi, nhóm máu, chiều cao, cân nặng, BMI và BSA, địa chỉ và thông tin liên lạc, cùng bác sĩ, bệnh viện và khoa liên quan. Từ đây nhân viên đi vào mọi workflow khác của bệnh nhân đó.

```mermaid
flowchart TB
    accTitle: Dữ liệu xoay quanh bệnh nhân
    accDescr: Bệnh nhân liên kết tới thông tin cơ bản, địa chỉ và liên lạc, bác sĩ và bệnh viện liên quan, môi trường sống, đánh giá, case record, file đính kèm và nursing order. Mỗi nursing order dẫn tới nursing plan, plan dẫn tới hồ sơ thăm khám, và hồ sơ thăm khám dẫn tới nursing report.

    PATIENT["Bệnh nhân"]

    BASIC["Thông tin cơ bản"]
    CONTACT["Địa chỉ / liên lạc"]
    DOCTOR["Bác sĩ / bệnh viện liên quan"]
    ENV["Môi trường sống"]

    ASSESS["Đánh giá"]
    CASE["Case record"]
    FILE["File đính kèm"]

    ORDER["Nursing order"]
    PLAN["Nursing plan"]
    VISIT["Hồ sơ thăm khám"]
    REPORT["Nursing report"]

    PATIENT --> BASIC
    PATIENT --> CONTACT
    PATIENT --> DOCTOR
    PATIENT --> ENV

    PATIENT --> ASSESS
    PATIENT --> CASE
    PATIENT --> FILE

    PATIENT --> ORDER
    ORDER --> PLAN
    PLAN --> VISIT
    VISIT --> REPORT
```

_Thông tin, nơi ở, hồ sơ, file và cả chuỗi từ order tới báo cáo đều gắn vào một bệnh nhân._

## Ngôi nhà của bệnh nhân

Môi trường sống là module đặc thù của chăm sóc tại nhà, vì việc chăm sóc làm được đến đâu phụ thuộc vào nơi ở. Hệ thống ghi lại sơ đồ nhà; phòng — phòng riêng hay không, tầng, thang máy, loại giường hoặc nệm, ánh sáng, máy sưởi và điều hòa; nhà vệ sinh — loại, tay vịn và bậc; phòng tắm — tay vịn và bậc; và tiện nghi như máy giặt, bình nóng lạnh, tủ lạnh và bếp. Mỗi khu vực đều có ghi chú và ảnh, để nhân viên ghi lại hiện trạng như nó đang là, không chỉ bằng chữ.

```mermaid
flowchart TB
    accTitle: Môi trường sống của bệnh nhân
    accDescr: Môi trường sống của bệnh nhân được ghi theo năm khu vực: sơ đồ nhà, phòng, nhà vệ sinh, phòng tắm và tiện nghi. Mỗi khu vực đều có thể kèm ảnh và file đính kèm.

    PATIENT["Bệnh nhân"]
    ENV["Môi trường sống"]

    FLOOR["Sơ đồ nhà"]
    ROOM["Phòng"]
    TOILET["Nhà vệ sinh"]
    BATH["Phòng tắm"]
    FACILITY["Tiện nghi"]

    FILE["Ảnh / file đính kèm"]

    PATIENT --> ENV

    ENV --> FLOOR
    ENV --> ROOM
    ENV --> TOILET
    ENV --> BATH
    ENV --> FACILITY

    FLOOR --> FILE
    ROOM --> FILE
    TOILET --> FILE
    BATH --> FILE
    FACILITY --> FILE
```

_Năm khu vực của ngôi nhà, mỗi khu vực có ghi chú và ảnh riêng._

## Case record và bàn giao

Case record là một mô hình linh hoạt dùng chung cho nhiều loại thông tin chăm sóc: tiêu đề và nội dung tự do, người viết, người nhận là staff hoặc nhóm, order và loại order liên quan, tag, các cờ quan trọng, khẩn cấp, bàn giao, riêng tư và lịch sử, cùng file đính kèm. Cờ bàn giao biến một record thành thông tin chuyển giao giữa các ca, staff, nhóm và office, còn phần comment của record được kỳ vọng hoạt động gần giống chat real-time. Tag có API tạo, đọc, sửa và xóa riêng.

```mermaid
flowchart TD
    accTitle: Tạo một case record
    accDescr: Staff tạo case record gồm tiêu đề và nội dung tự do, người nhận là staff hoặc nhóm, cờ quan trọng và khẩn cấp, cờ bàn giao, tag và file đính kèm. Tất cả đi vào lịch sử hồ sơ của bệnh nhân.

    USER["Staff"]

    RECORD["Tạo case record"]

    TITLE["Tiêu đề / nội dung"]
    RECEIVER["Người nhận: staff / nhóm"]
    FLAGS["Quan trọng / khẩn cấp"]
    HANDOVER["Bàn giao"]
    TAG["Tag"]
    ATTACH["File đính kèm"]

    HISTORY["Lịch sử hồ sơ bệnh nhân"]

    USER --> RECORD

    RECORD --> TITLE
    RECORD --> RECEIVER
    RECORD --> FLAGS
    RECORD --> HANDOVER
    RECORD --> TAG
    RECORD --> ATTACH

    TITLE --> HISTORY
    RECEIVER --> HISTORY
    FLAGS --> HISTORY
    HANDOVER --> HISTORY
    TAG --> HISTORY
    ATTACH --> HISTORY
```

_Một mô hình record mang người nhận, cờ, tag và file — và đánh dấu điều cần bàn giao._

## Order, kế hoạch và lịch

- **Nursing order** là chỉ định chăm sóc tại nhà, có màn hình danh sách, tạo, sửa và chi tiết. Danh sách có các biến thể thường, đặc biệt và tâm thần.
- **Nursing plan** nằm giữa order và lịch thực tế: danh sách, chi tiết và sửa, có dữ liệu liên quan tới đánh giá và một biến thể cho đối tác nghiên cứu.
- **Lịch thăm khám** có hai góc nhìn, theo tháng và theo ngày, gắn bệnh nhân, staff, thời gian, office và trạng thái kế hoạch với nhau.

## Hồ sơ thăm khám, nhật ký và báo cáo

Hồ sơ điều dưỡng tại nhà I có danh sách lịch sử, tạo và sửa, chi tiết, các form nghiệp vụ, chuyển thành case record, in và file đính kèm. Hồ sơ II có biến thể cho PC, mobile và đối tác nghiên cứu, và một phần thuộc phase sau. Sau các lần thăm khám, nhân viên viết nursing diary, có danh sách, chi tiết và sửa, lịch và in. Nursing report có các loại thường, tâm thần, kết hợp và file đính kèm, với màn hình chi tiết, sửa và in, và ở một số màn hình có con dấu điện tử để phê duyệt; loại kết hợp có thêm dữ liệu GAF.

```mermaid
flowchart LR
    accTitle: Từ một lần thăm khám tới lịch sử bệnh nhân
    accDescr: Một lần thăm khám tại nhà tạo ra hồ sơ thăm khám, hồ sơ đi vào nursing diary, diary làm đầu vào cho nursing report, report được review và đánh giá, và kết quả đi vào lịch sử của bệnh nhân.

    VISIT["Thăm khám tại nhà"]
    RECORD["Hồ sơ thăm khám"]
    DIARY["Nursing diary"]
    REPORT["Nursing report"]
    REVIEW["Review / đánh giá"]
    HISTORY["Lịch sử bệnh nhân"]

    VISIT --> RECORD
    RECORD --> DIARY
    DIARY --> REPORT
    REPORT --> REVIEW
    REVIEW --> HISTORY
```

_Một lần thăm khám được ghi lại, viết thành báo cáo, được review — và trở thành một phần lịch sử của bệnh nhân._

## Đánh giá để theo dõi tiến triển

Đánh giá được chia theo phương pháp — loét tì đè (bedsore), ADL, IADL và GAF — và theo thời gian, nên hệ thống theo dõi sự thay đổi thay vì một điểm số đơn lẻ. Đánh giá loét tì đè lưu ảnh qua một route file riêng. Đánh giá cá nhân hiển thị các domain của một bệnh nhân theo từng block; đánh giá tổng quan đưa nhiều domain lên cùng một màn hình, với nhiều API, nhiều block và nhiều định dạng dữ liệu. Tổng kết cuối tháng tóm tắt một tháng điều dưỡng tại nhà của từng bệnh nhân và liên kết tới thông tin bệnh nhân và tiến triển đánh giá; biến thể cho đối tác nghiên cứu có thêm feedback report riêng.

```mermaid
flowchart TB
    accTitle: Đánh giá bệnh nhân
    accDescr: Đánh giá bệnh nhân gồm bốn phương pháp: loét tì đè (bedsore), ADL, IADL và GAF. Cả bốn đổ vào đánh giá cá nhân của bệnh nhân đó; đánh giá cá nhân đổ vào đánh giá tổng quan, và đánh giá tổng quan tạo thành lịch sử tiến triển.

    PATIENT["Bệnh nhân"]
    ASSESS["Đánh giá bệnh nhân"]

    BEDSORE["Loét tì đè"]
    ADL["ADL"]
    IADL["IADL"]
    GAF["GAF"]

    PERSONAL["Đánh giá cá nhân"]
    OVERVIEW["Đánh giá tổng quan"]
    PROGRESS["Lịch sử tiến triển"]

    PATIENT --> ASSESS

    ASSESS --> BEDSORE
    ASSESS --> ADL
    ASSESS --> IADL
    ASSESS --> GAF

    BEDSORE --> PERSONAL
    ADL --> PERSONAL
    IADL --> PERSONAL
    GAF --> PERSONAL

    PERSONAL --> OVERVIEW
    OVERVIEW --> PROGRESS
```

_Bốn phương pháp đánh giá đổ vào đánh giá của một bệnh nhân — và theo thời gian, thành lịch sử tiến triển._

## File ở khắp nơi

File đính kèm là mối quan tâm xuyên suốt cả hệ thống và đi qua một file service chung. File được tải lên trước; API lưu file vào Amazon S3 và trả về UUID, tên, dung lượng, URL, URL thumbnail và content type; record nghiệp vụ sau đó tham chiếu file bằng UUID. Route upload được chia theo mục đích: loét tì đè, đơn thuốc, môi trường sống, nursing order, case record và con dấu của staff.

```mermaid
flowchart LR
    accTitle: Tải lên một file đính kèm lâm sàng
    accDescr: Web client tải file lên file API dưới dạng multipart form data. API lưu file vào Amazon S3 và trả metadata của file về client. Sau đó client lưu hồ sơ lâm sàng, trong đó file được tham chiếu bằng UUID nằm trong metadata.

    UI["Web client"]
    API["File API"]
    STORAGE["Amazon S3"]

    META["Metadata của file"]
    DOMAIN["Hồ sơ lâm sàng"]

    UI -->|"multipart/form-data"| API
    API --> STORAGE
    STORAGE --> API

    API --> META
    META --> UI

    UI --> DOMAIN
    DOMAIN -->|"UUID của file"| META
```

_Tải lên trước, liên kết sau: hồ sơ lâm sàng chỉ giữ tham chiếu tới file._

## API, xác thực và phân quyền

REST API dùng JSON với GET, POST, PUT, PATCH và DELETE, chia thành các nhóm authentication, account, bệnh nhân, staff, organization, office, đánh giá, case record, hồ sơ điều dưỡng, order, kế hoạch, lịch, báo cáo, file, tag và master data. Select box và form lấy lựa chọn — role, mức độ cần chăm sóc, phương pháp đánh giá, bộ phận cơ thể, tỉnh, khoa, loại order — từ API master data thay vì hard-code. Không phải người dùng nào cũng được gọi mọi API: kiểm tra quyền kết hợp role, organization, office và loại tài khoản, còn lỗi được phân biệt thành tham số không hợp lệ, lỗi xác thực, lỗi quyền, không tìm thấy resource, method không được hỗ trợ, lỗi database và lỗi không lường trước.

```mermaid
sequenceDiagram
    accTitle: Xác thực và phân quyền ở mọi request
    accDescr: Web client gửi request đăng nhập kèm API key. API nhờ lớp xác thực và phân quyền kiểm tra thông tin đăng nhập, nhận về user, role và organization, rồi trả access token kèm context đó. Sau đó mọi request nghiệp vụ mang access token dưới dạng bearer token, và API nhờ lớp xác thực kiểm tra token cùng quyền truy cập. Nếu được phép, API trả JSON response; nếu không, API trả 401 hoặc 403.

    participant UI as Web client
    participant API as REST API
    participant AUTH as Lớp xác thực / phân quyền

    UI->>API: Đăng nhập + API key
    API->>AUTH: Kiểm tra thông tin đăng nhập
    AUTH-->>API: User / role / organization
    API-->>UI: Access token + context

    UI->>API: Request nghiệp vụ + bearer token
    API->>AUTH: Kiểm tra token và quyền

    alt Được phép
        AUTH-->>API: Cho phép
        API-->>UI: JSON response
    else Không được phép
        AUTH-->>API: Từ chối
        API-->>UI: 401 / 403
    end
```

_API key để đăng nhập, bearer token sau đó, và kiểm tra quyền ở mọi lần gọi._

## Dẫn dắt team khi thiết kế thay đổi và API đến theo giai đoạn

- **API đến sau UI.** Team dựng màn hình trước trên mock data, đọc API specification, tích hợp API thật sau, rồi sửa những chỗ API thực tế khác với thiết kế.
- **Thiết kế thay đổi liên tục.** Thiết kế mới, page bị conflict, API khác thiết kế, block phải làm lại, tab và menu thay đổi, màn hình chưa có thiết kế đầy đủ. Việc của tôi là không để những thay đổi đó biến thành các cách implement khác nhau giữa các developer.
- **Component dùng chung** — header, global menu, header bệnh nhân, table, form block, popup, select box, notification, block đánh giá — để nhiều domain dùng cùng một bộ phận. Các domain đánh giá được chia cho nhiều developer cùng làm trên nền đó.
- **Chất lượng trước QA.** Một màn hình đi qua implementation, pull request và review, deploy lên môi trường dev và QA test; bug quay lại để sửa và test lại, còn daily meeting theo dõi từng page đang ở bước nào.
- **Tablet cũng như desktop.** Danh sách và table cần cuộn ngang, giữ căn lề, và layout cho màn hình 4:3 và tablet. Giai đoạn 2022 là web application responsive; tài liệu không cho thấy có native app trong giai đoạn này.

Bản release Phase 1 gồm đăng nhập và mật khẩu, bệnh nhân và bệnh án, điều kiện sống, đánh giá, case record, hồ sơ điều dưỡng, order, kế hoạch, báo cáo và khoa, cùng các màn hình chi tiết và sửa.

```mermaid
flowchart LR
    accTitle: Một màn hình đi từ thiết kế tới release
    accDescr: Requirement và thiết kế được chuyển thành mock data và mock API, rồi tới implementation. Implementation đi qua code review của leader, deploy lên môi trường dev và QA test. Lỗi phát hiện ở QA thành bug hoặc feedback và quay lại implementation; màn hình đạt QA thì đi tới release.

    SPEC["Requirement / thiết kế"]
    MOCK["Mock data / mock API"]
    DEV["Implementation"]
    REVIEW["Leader review code"]
    DEPLOY["Deploy môi trường dev"]
    QA["QA test"]
    BUG["Bug / feedback"]
    RELEASE["Release"]

    SPEC --> MOCK
    MOCK --> DEV

    DEV --> REVIEW
    REVIEW --> DEPLOY
    DEPLOY --> QA

    QA -->|"Có lỗi"| BUG
    BUG --> DEV

    QA -->|"Đạt"| RELEASE
```

_Mock cho phép màn hình đi trước khi API sẵn sàng; review và QA quyết định khi nào là xong._

## Kiến trúc

Trình duyệt hoặc tablet chạy web frontend xây bằng Vue và Vuetify, gọi REST API. API kiểm tra API key hoặc access token, rồi role và quyền, trước khi business service chạy; file đi qua file service tới Amazon S3. Backend framework, loại database và phần hạ tầng còn lại không được nêu ở đây: API do phía Nhật xây, và tài liệu chưa đủ cụ thể để xác định.

```mermaid
flowchart TB
    accTitle: Kiến trúc mức thành phần
    accDescr: Người dùng trên trình duyệt hoặc tablet dùng web frontend, xây bằng Vue và các UI component của Vuetify. Frontend gọi REST API; API kiểm tra API key hoặc access token, rồi role và quyền, trước khi business service chạy. Business service dùng database của ứng dụng và file service, nơi lưu file vào Amazon S3.

    USER["Trình duyệt / tablet"]

    WEB["Web frontend (Vue)"]
    UI["UI component Vuetify"]

    REST["REST API"]

    AUTH["API key / access token"]
    PERMISSION["Role / phân quyền"]

    BUSINESS["Business service"]

    FILE["File service"]
    S3["Amazon S3"]

    DATA["Database ứng dụng"]

    USER --> WEB
    UI --> WEB

    WEB --> REST

    REST --> AUTH
    AUTH --> PERMISSION
    PERMISSION --> BUSINESS

    BUSINESS --> DATA
    BUSINESS --> FILE
    FILE --> S3
```

_Sơ đồ mức thành phần theo những gì tài liệu dự án thể hiện — không phải bản sao hạ tầng production._

## Dự án bao phủ những gì

| Bài toán của một hệ thống quản lý lớn | Thể hiện trong Waroku Home-Visit Nursing |
| --- | --- |
| Một thực thể ở trung tâm | Thông tin, nơi ở, hồ sơ, file, order, kế hoạch, lần thăm khám, báo cáo và đánh giá đều gắn vào bệnh nhân |
| Context nhiều tổ chức | Organization, office, staff và role xác định lúc đăng nhập; đổi office; menu lấy từ API |
| Nhiều biến thể của một sản phẩm | Tài khoản tiêu chuẩn, đối tác nghiên cứu và quản lý, với màn hình và báo cáo khác nhau theo loại tài khoản |
| Workflow có vòng lặp | Đánh giá, order, kế hoạch, lịch, thăm khám, hồ sơ, nhật ký, báo cáo, rồi quay lại đánh giá |
| Thông tin chuyển giữa người với người | Case record có người nhận, cờ, tag và bàn giao |
| File là một phần của hồ sơ | Một file service trên S3 cho loét tì đè, đơn thuốc, nơi ở, order, record và con dấu |
| Bảo mật ở mọi lần gọi | API key, bearer token, kiểm tra quyền theo role, organization, office và loại tài khoản |
| Giao hàng khi specification còn thay đổi | Mock data, component dùng chung, review và QA trong khi thiết kế và API thay đổi |

Các sơ đồ được dựng lại ở mức thành phần từ specification của dự án. Chúng lược bỏ URL nội bộ, định danh hệ thống, route API, source code độc quyền và dữ liệu thật của bệnh nhân. Ảnh chụp là wireframe demo với dữ liệu mẫu; tên đơn vị vận hành, nhãn của đối tác nghiên cứu, ảnh chân dung và địa chỉ cụ thể trong ảnh đã được làm mờ.

## Thông tin

- **Vai trò:** Project Leader · Technical Lead · Frontend
- **Website:** [nurse.waroku.net/](https://nurse.waroku.net/)

## Công nghệ

- Vue
- Vuetify
- REST API
- AWS S3

## Dịch vụ thể hiện qua dự án

- [Hệ thống quản lý nghiệp vụ](https://tmtuan.dev/vi/services/business-systems)

## Bài viết liên quan

- [Knowledge Base docs-as-code + Context Graph cho portfolio 15 dự án](https://tmtuan.dev/vi/articles/knowledge-base-docs-as-code-context-graph)

## Structured data (JSON-LD)

```json
{"@context":"https://schema.org","@graph":[{"@type":"WebPage","@id":"https://tmtuan.dev/vi/projects/waroku-home-visit-nursing#webpage","url":"https://tmtuan.dev/vi/projects/waroku-home-visit-nursing","name":"Waroku Home-Visit Nursing — Điều dưỡng tại nhà","description":"Nền tảng cloud cho điều dưỡng tại nhà ở Nhật: bệnh nhân và nơi ở, case record và bàn giao, nursing order và kế hoạch, lịch thăm khám, báo cáo và đánh giá.","inLanguage":"vi","isPartOf":{"@id":"https://tmtuan.dev/#website"},"about":{"@id":"https://tmtuan.dev/#person"}},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Trang chủ","item":"https://tmtuan.dev/vi"},{"@type":"ListItem","position":2,"name":"Dự án","item":"https://tmtuan.dev/vi/projects"},{"@type":"ListItem","position":3,"name":"Waroku Home-Visit Nursing","item":"https://tmtuan.dev/vi/projects/waroku-home-visit-nursing"}]}]}
```