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.

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

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.

Đ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 đó.

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

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.

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.

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.

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.

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.

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.

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.

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

Ảnh 1 trên 8