Waroku Hospital Karte

Waroku Hospital Karte là nền tảng hồ sơ bệnh án điện tử và workflow lâm sàng trên cloud dành cho bệnh viện tâm thần tại Nhật Bản. Đây không chỉ là nơi xem bệnh án: bác sĩ, điều dưỡng và các bộ phận hỗ trợ dùng hệ thống để tìm bệnh nhân, vận hành điều trị nội trú và ngoại trú, quản lý ward và giường bệnh, lịch, task, bàn giao — và quan trọng nhất là tạo, xác nhận, tiếp nhận và thực thi clinical order.

Giai đoạn 2021–2022, tôi là Tech Lead của team phát triển tại Việt Nam. Phạm vi của team là frontend bằng Vue, Nuxt và TypeScript, trên codebase và cấu trúc component có sẵn; team gồm frontend developer, IT communicator và các thành viên junior, còn specification đến từ phía Nhật.

Vì sao đây là dự án hệ thống quản lý: một hệ thống bệnh viện là hàng chục module dùng chung một bệnh nhân, một tổ chức và một bộ nhân sự, giường bệnh và order. Một thao tác nhỏ có thể đổi trạng thái bệnh nhân, giường bệnh, order, lịch và người phải hành động tiếp theo. Màn hình trông đúng vẫn có thể làm sai clinical workflow — nên dẫn dắt team nghĩa là phải hiểu workflow đủ sâu để chặn điều đó.

Các module và cách người dùng đi vào

Mọi module dùng chung một lõi: định danh bệnh nhân, hospital và organization, định danh bác sĩ và điều dưỡng, khoa, ward, buồng và giường, order, lịch, trạng thái thực thi và lịch sử lâm sàng.

Authentication và context của hospital đi trước; chúng quyết định header và menu hiển thị những gì.

Vai trò của tôi

Nắm kiến trúc tổng thể của frontend và cách tích hợp với API, hướng dẫn team phát triển theo codebase và cấu trúc component có sẵn.
Review implementation và pull request, giữ component dùng chung, modal dùng lại và convention nhất quán trên một số lượng màn hình rất lớn.
Cùng team phân tích screen specification và API specification, giải thích nghiệp vụ lâm sàng phía sau.
Nhận các màn hình có business rule phức tạp và dependency giữa nhiều màn hình / module; đánh giá ảnh hưởng của thay đổi lên các workflow liên quan.
Hỗ trợ debug các vấn đề giữa frontend và API.
Theo dõi tiến độ kỹ thuật của team, hỗ trợ thành viên junior và intern.
Làm cầu nối kỹ thuật giữa specification phía Nhật và implementation phía Việt Nam.

Một điểm vào: đăng nhập, context bệnh viện và tìm bệnh nhân

Nhân viên đăng nhập bằng login ID và mật khẩu, có reset và đổi mật khẩu; xác thực hai lớp nằm trong yêu cầu. Session không chỉ quyết định quyền truy cập mà còn quyết định menu và workflow người dùng được phép dùng. Một người dùng có thể thuộc và chuyển giữa nhiều hospital trong cùng group và organization, và một số menu — ví dụ sub-menu rehabilitation và instruction — khác nhau theo hospital, nên menu lấy từ API thay vì hard-code.

Global header cho phép tìm bệnh nhân từ bất kỳ đâu: tên Katakana tìm theo forward match, số bệnh nhân tìm theo exact match. Kết quả mở Karte của bệnh nhân, biến tìm kiếm thành điểm vào của clinical workflow.

Từ đăng nhập tới hồ sơ bệnh nhân chỉ qua vài bước, dù người dùng bắt đầu từ màn hình nào.

Menu đi theo role

Global menu là bản đồ công việc của bệnh viện, không phải thanh điều hướng tĩnh. Menu gom các chức năng dùng chung (work task, schedule, countersignature, announcement, handover), công việc ward / nội trú (nhật ký quản lý điều dưỡng, danh sách trạng thái bệnh nhân, danh sách bệnh nhân cho bác sĩ và cho điều dưỡng, bed map, nhập liệu khi đi buồng, flow sheet, ra ngoài và ngủ qua đêm, hạn chế vận động, nhật ký điều dưỡng ward), danh sách và nhật ký ngoại trú, order (order list, execution list, order đã hoàn tất, xác nhận booking, output xét nghiệm), rehabilitation cá nhân và nhóm, instruction cá nhân và nhóm, conference, và consultation log / PSW log.

Bác sĩ và điều dưỡng không có cùng menu, cũng không có cùng quyền; role quyết định cả hai.

Karte

Karte — hồ sơ bệnh nhân — là trung tâm workflow của bệnh nhân: basic tab và thông tin bệnh nhân, lịch của bệnh nhân, life history, ghi chép vào chart, order entry và order history, thông tin lâm sàng. Từ đây bác sĩ và điều dưỡng xem lịch sử, nhập thông tin lâm sàng, tạo order, quản lý lịch và chuyển sang các module chuyên môn. Lịch không chỉ là calendar: nó kết hợp lịch hẹn của bệnh nhân với lịch của staff, của facility, task và ToDo.

Clinical order: module lớn nhất

Order là một trong những workflow cốt lõi của cả hệ thống. Có năm loại cơ bản — kê đơn, tiêm, xét nghiệm, điều trị và chẩn đoán hình ảnh — cùng các order chuyên biệt như xét nghiệm tâm lý và sinh lý, CT và X-Ray, bữa ăn, chuyển khoa / buồng, chỉ định task, ra viện hoặc chuyển sang ngoại trú. Loại order mới có thể được thêm qua API, nên module vận hành như một order framework, trong đó mỗi loại mang form và rule riêng.

Một order framework, nhiều loại order, mỗi loại có form và rule riêng.

Order thường và order có điều kiện. Bên cạnh order thường, IF order chỉ được thực thi khi một điều kiện xác định xảy ra, nên phải lưu trigger condition, title, comment, state và execution logic.
Order cart. Trên Karte, bác sĩ nhập order theo từng tab; order chỉ được tạo cho tab hiện tại khi thêm vào cart, còn dữ liệu đã nhập ở các tab khác vẫn được giữ. Cart đóng vai trò staging area trước khi xác nhận clinical order.
Xác nhận. Một số order cần approval, consent, countersign hoặc nhiều mức xác nhận, và order list thể hiện từng bước xác nhận.
Tiếp nhận và thực thi. Sau khi được xác nhận, order chuyển sang các danh sách order toàn hệ thống, nơi staff phù hợp tiếp nhận và trở thành người phụ trách thực thi. Lần thực thi ghi lại ngày giờ, người thực thi, trạng thái và các input riêng của order; X-Ray, tiêm và điều trị có màn hình thực thi riêng.
Thực thi hàng loạt chỉ được phép khi hợp lý: checkbox bị disable với các order không thể thực thi cùng nhau, tùy loại order, trạng thái, yêu cầu booking, yêu cầu tiếp nhận và mức sẵn sàng.
Tìm kiếm lọc theo bệnh nhân, tuổi, giới tính, ngày order, khoa, ward, bác sĩ, điều dưỡng và team rehabilitation; người dùng có thể lưu, xóa và dùng lại điều kiện tìm kiếm.

Order không đi thẳng từ tạo tới hoàn tất. Nó được xác nhận, tiếp nhận và thực thi bởi những người khác nhau — và có thể bị đổi, suspend hoặc cancel dọc đường.

Các loại order có rule riêng

Kê đơn: nội trú hoặc ngoại trú, khoa, bảo hiểm, loại đơn, ngày bắt đầu và kết thúc, thông tin thuốc, đơn trước đó, comment, phiếu thông tin thuốc, IF order và thực thi ngay. Hệ thống có thể đưa ra cảnh báo trước khi tạo order; bác sĩ xác nhận cảnh báo, quay lại sửa, hoặc tiếp tục — một bước an toàn lâm sàng nằm ngay trong workflow.
Xét nghiệm và hình ảnh: xét nghiệm tâm lý, sinh lý, xét nghiệm cận lâm sàng, CT và X-Ray, mỗi loại có khoa, bảo hiểm, lịch, cách chỉ định và trạng thái thực thi. Chỉ định hình ảnh có thể là tạm thời hoặc định kỳ, cho một ngày, nhiều ngày, một khoảng ngày hoặc ngày chưa xác định; thực thi X-Ray ghi số order, thời gian, người thực thi, và yêu cầu xác nhận lại khi order thay đổi.
Điều trị: tạm thời hoặc định kỳ, có lịch thực thi, comment và staff phụ trách.
Bữa ăn: order và lịch sử bữa ăn, loại bữa và khung giờ, thay đổi tạm thời, comment và thời gian áp dụng thay đổi.
Chuyển khoa / buồng / giường: ngày giờ, khoa, bảo hiểm, tòa nhà, buồng, giường và bác sĩ chính.
Ra viện và chuyển sang ngoại trú: một thay đổi trạng thái mà các module khác phải đi theo.

Nội trú và điều dưỡng

Công việc nội trú có danh sách và màn hình riêng: danh sách trạng thái bệnh nhân, danh sách bệnh nhân cho bác sĩ và cho điều dưỡng, bed map theo ward / buồng / giường, nhập liệu của bác sĩ khi đi buồng, flow sheet, nhật ký điều dưỡng ward và ngoại trú. Ra ngoài và ngủ qua đêm có cả vòng đời yêu cầu — thời hạn, trạng thái, lịch sử, hủy yêu cầu và trạng thái trở về — còn hạn chế vận động có danh sách riêng. Vì chuyển buồng và ra viện làm đổi trạng thái giường, bed map phải luôn khớp với việc di chuyển của bệnh nhân.

Bệnh nhân nội trú nằm ở trung tâm của trạng thái, vị trí, chăm sóc và order — và tất cả đều thay đổi.

Lịch, task và giao tiếp trong team

Việc chăm sóc được tổ chức thành task của team: mỗi task có người thực thi, nội dung chỉ định, comment, người ra chỉ định, deadline và trạng thái, và có thể đăng ký ngay từ hồ sơ bệnh nhân. Xung quanh task là bàn giao, announcement, notification và entry point tới chat trên header.

Lịch của bệnh nhân, staff và facility gặp nhau ở một chỗ và biến thành task trong ngày.

Xây một frontend quy mô lớn

Frontend dùng file-based routing của Nuxt, tách riêng components, components dùng chung, hooks, pages, plugins và assets. Các phần dùng chung — staff selector, modal, form component dùng lại — được viết một lần; Vuetify là UI framework, SCSS để override style, Axios để gọi API. Để phát triển nhiều màn hình song song khi API chưa xong, project định nghĩa API mock bằng axios-mock-server, nên frontend không phải chờ backend.

Specification thành mock và component trước; API thật đến ở cuối, không phải ở đầu.

Kiến trúc

Trình duyệt chạy ứng dụng Nuxt, Vue và TypeScript, gọi backend API qua Axios. Tài liệu development mô tả PostgreSQL trên AWS RDS, Redis trong luồng đăng nhập, và S3 cho image / content ở một số luồng. Backend framework không được nêu ở đây vì tài liệu nguồn chưa đủ để xác định chắc chắn.

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 Hospital Karte
Nhiều role, một hệ thống	Menu bác sĩ, điều dưỡng và bộ phận hỗ trợ dựng từ role và authority
Cấu hình nhiều tổ chức	Context group, organization và hospital; menu riêng theo hospital lấy từ API
Workflow có nhiều người tham gia	Order được tạo, xác nhận, tiếp nhận và thực thi bởi những người khác nhau; đổi, suspend, cancel; order có điều kiện
Kiểm tra an toàn ngay trong workflow	Cảnh báo kê đơn, approval, consent và countersign trước khi order được phát hành
Tài nguyên phải luôn nhất quán	Vị trí ward / buồng / giường khớp với chuyển buồng và ra viện
Lập lịch cho người và nơi chốn	Lịch bệnh nhân, staff và facility đổ vào task của team
Số lượng màn hình rất lớn	Component dùng chung, modal dùng lại, convention và API mock để làm song song
Specification bằng ngôn ngữ khác	Screen / API specification tiếng Nhật chuyển thành implementation bởi team tại Việt Nam

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, source code độc quyền và dữ liệu thật của bệnh nhân hay bệnh viện. Ảnh chụp là wireframe demo với dữ liệu mẫu.

Ảnh 1 trên 9