Khi ký hợp đồng triển khai một phần mềm quản lý bệnh viện (HIS), ban lãnh đạo không chỉ mua giải pháp cho quy mô hiện tại - mà đang đặt cược vào năng lực vận hành của 5 đến 10 năm tới. Một bệnh viện hôm nay có 200 giường, ba năm sau mở thêm cơ sở 2, năm năm sau số lượt khám ngoại trú tăng gấp đôi. Câu hỏi sống còn là: hệ thống có lớn lên cùng bệnh viện, hay sẽ trở thành điểm nghẽn buộc phải thay thế toàn bộ giữa chừng?
Đó chính là vấn đề về khả năng mở rộng phần mềm bệnh viện (scalability). Đây là tiêu chí kỹ thuật hiếm khi xuất hiện nổi bật trên brochure, nhưng lại quyết định trực tiếp đến tổng chi phí sở hữu và tính liên tục của hoạt động khám chữa bệnh. Bài viết này đưa ra khung đánh giá theo ba trục: tải hệ thống, kiến trúc module - API, và mô hình triển khai.
Khả năng mở rộng là gì và vì sao nó là rủi ro tiềm ẩn?
Khả năng mở rộng là năng lực của HIS duy trì hiệu năng và độ ổn định khi lưu lượng người dùng, khối lượng dữ liệu và số cơ sở triển khai gia tăng - mà không phải thay toàn bộ nền tảng. Một hệ thống có khả năng mở rộng tốt cho phép bệnh viện tăng tải đầu cuối (thêm khoa phòng, thêm máy trạm tiếp đón, thêm điểm thu ngân viện phí) chỉ bằng việc bổ sung tài nguyên, thay vì viết lại lõi phần mềm.
Ngược lại, giới hạn mở rộng thường ẩn rất sâu và chỉ bộc lộ vào đúng thời điểm bệnh viện không thể chịu gián đoạn: giờ cao điểm tiếp đón buổi sáng, kỳ cao điểm dịch bệnh, hoặc thời điểm vận hành thêm một cơ sở mới. Khi đó, chi phí khắc phục không còn là chi phí kỹ thuật đơn thuần mà là chi phí gián đoạn dịch vụ y tế và suy giảm trải nghiệm của người bệnh.
Để bóc tách rủi ro này một cách có hệ thống, hãy đánh giá HIS lần lượt theo ba trục dưới đây.
Trục 1: Tải hệ thống - hệ thống chịu được bao nhiêu trước khi "nghẽn"?
Trục đầu tiên trả lời câu hỏi định lượng: hệ thống xử lý được bao nhiêu phiên làm việc đồng thời, và điều gì xảy ra khi vượt ngưỡng? Một HIS thiết kế tốt cho khả năng mở rộng theo chiều ngang (scale-out) - tức là khi tải tăng, hệ thống bổ sung thêm node xử lý và dùng load balancer để phân phối lưu lượng, thay vì phụ thuộc vào việc nâng cấp một máy chủ duy nhất đến giới hạn vật lý (scale-up).
Đi kèm với tải là cam kết về tính sẵn sàng, thường được lượng hoá bằng SLA (Service Level Agreement) - tỷ lệ thời gian hệ thống hoạt động ổn định trong năm. Với một bệnh viện vận hành 24/7, vài giờ gián đoạn không báo trước có thể làm tê liệt toàn bộ quy trình tiếp đón, chỉ định và thanh toán. Bảng dưới đây giúp quy đổi các mức SLA thành thời gian gián đoạn thực tế:
| Mức cam kết (SLA) | Thời gian gián đoạn tối đa / năm | Ý nghĩa với bệnh viện |
|---|---|---|
| 99% | ~87,6 giờ (≈3,65 ngày) | Ngưỡng tối thiểu chấp nhận được |
| 99,9% | ~8,76 giờ | Phù hợp phần lớn bệnh viện |
| 99,99% | ~52,6 phút | Mức cao, đòi hỏi hạ tầng dự phòng đầy đủ |
| 99,999% | ~5,26 phút | Hiếm gặp, chi phí hạ tầng rất lớn |
Lưu ý quan trọng: con số SLA trên hợp đồng không phản ánh tất cả. Cần đọc kỹ cách tính downtime - thời gian bảo trì định kỳ có được loại trừ khỏi cam kết hay không, cơ chế bồi thường khi vi phạm SLA là gì, và ai chịu trách nhiệm khi sự cố đến từ hạ tầng đám mây của bên thứ ba. Một con số 99,9% đẹp đẽ nhưng loại trừ toàn bộ "bảo trì có kế hoạch" có thể yếu hơn một con số 99% được tính trọn vẹn.
Trục 2: Kiến trúc module và API - mở rộng tính năng có dễ không?
Nếu trục 1 nói về việc gánh thêm tải, thì trục 2 nói về việc thêm năng lực. Khi bệnh viện muốn bổ sung module quản lý dược, kết nối hệ thống xét nghiệm (LIS), tích hợp chẩn đoán hình ảnh (PACS) hay nối với hệ thống tài chính, kiến trúc phần mềm quyết định việc này dễ hay khó, nhanh hay chậm.
Monolith và modular: hai triết lý kiến trúc
Kiến trúc monolith đóng gói toàn bộ tính năng trong một khối thống nhất. Ưu điểm là đơn giản khi triển khai ban đầu, nhưng mỗi lần thêm hoặc sửa một module đều phải can thiệp vào lõi chung - rủi ro lan toả lỗi cao, thời gian kiểm thử kéo dài, và không thể nâng cấp riêng một phần chịu tải nặng.
Kiến trúc modular / microservice tách hệ thống thành các dịch vụ độc lập, kết nối qua một API Gateway. Cách tiếp cận này cho phép bệnh viện bật/tắt từng module theo nhu cầu, mở rộng riêng phần chịu tải cao (ví dụ module tiếp đón giờ cao điểm) mà không đụng đến phần còn lại, và tích hợp thiết bị y tế hay phần mềm bên thứ ba qua API mà không phải viết lại lõi.
API và chuẩn liên thông: chìa khoá của tích hợp
Khả năng mở rộng tính năng phụ thuộc trực tiếp vào chất lượng API. Yếu tố cần kiểm tra là mức độ hỗ trợ chuẩn liên thông y tế quốc tế HL7 FHIR R4 - nền tảng để trao đổi dữ liệu lâm sàng giữa các hệ thống. Một HIS hỗ trợ FHIR R4 và công khai tài liệu API (Swagger/OpenAPI) sẽ rút ngắn đáng kể thời gian tích hợp với LIS, PACS, hệ thống bảo hiểm y tế hay bệnh án điện tử của tuyến trên.
Tại Việt Nam, định hướng liên thông dữ liệu y tế và bệnh án điện tử cũng đặt ra yêu cầu ngày càng cao về chuẩn hoá. Bộ tiêu chí ứng dụng công nghệ thông tin tại các cơ sở khám chữa bệnh (Thông tư 54/2017/TT-BYT và các văn bản cập nhật) nhấn mạnh năng lực kết nối, liên thông - do đó một HIS "đóng", không có API mở, sẽ là rào cản dài hạn cho lộ trình chuyển đổi số của bệnh viện.
Trục 3: Mô hình triển khai - multi-tenant hay multi-instance?
Trục thứ ba liên quan đến cách dữ liệu và hạ tầng của bệnh viện được tổ chức trên nền tảng đám mây. Đây là quyết định ảnh hưởng đồng thời đến chi phí, mức độ tuỳ chỉnh và an toàn dữ liệu.
Trong mô hình multi-tenant, nhiều bệnh viện cùng chia sẻ một hạ tầng và một codebase, dữ liệu được phân tách bằng logic phần mềm. Mô hình này tối ưu chi phí và dễ cập nhật đồng loạt, nhưng mức độ tuỳ chỉnh bị giới hạn và khả năng cô lập dữ liệu phụ thuộc hoàn toàn vào thiết kế của nhà cung cấp.
Trong mô hình multi-instance (dedicated), mỗi bệnh viện có một phiên bản và hạ tầng riêng. Đổi lại chi phí cao hơn, bệnh viện nhận được khả năng tuỳ chỉnh sâu, dữ liệu cô lập hoàn toàn và lịch cập nhật chủ động - đặc biệt phù hợp với bệnh viện đa cơ sở hoặc đơn vị có yêu cầu bảo mật và tuân thủ nghiêm ngặt.
| Tiêu chí | Multi-tenant | Multi-instance (dedicated) |
|---|---|---|
| Hạ tầng | Dùng chung | Riêng biệt cho từng bệnh viện |
| Chi phí | Thấp hơn | Cao hơn |
| Mức tuỳ chỉnh | Hạn chế | Sâu, linh hoạt |
| Cô lập dữ liệu | Phụ thuộc thiết kế vendor | Cô lập hoàn toàn |
| Cập nhật phiên bản | Đồng loạt | Theo lịch riêng |
| Phù hợp với | Phòng khám, cơ sở quy mô vừa | Bệnh viện lớn, đa cơ sở, bảo mật cao |
Không có lựa chọn "tốt hơn" tuyệt đối - chỉ có lựa chọn phù hợp với quy mô, ngân sách và khẩu vị rủi ro của từng bệnh viện. Điều cần làm rõ với nhà cung cấp là: mô hình hiện tại là gì, và liệu có lộ trình chuyển đổi từ multi-tenant lên dedicated khi bệnh viện lớn lên hay không.
Checklist đánh giá khả năng mở rộng trước khi quyết định
Để biến ba trục trên thành công cụ thẩm định thực tế, bộ phận CNTT và ban quản lý có thể đặt cho nhà cung cấp những câu hỏi sau:
- Về tải: Hệ thống mở rộng theo chiều ngang (scale-out) hay chỉ chiều dọc (scale-up)? Có dùng load balancer không? SLA cam kết bao nhiêu và downtime được tính như thế nào?
- Về kiến trúc: Đây là monolith hay modular/microservice? Có thể bật/tắt và scale riêng từng module không?
- Về API: Có hỗ trợ HL7 FHIR R4 không? Tài liệu API có công khai (Swagger/OpenAPI)? Một tích hợp thiết bị điển hình mất bao lâu và cần nguồn lực gì từ phía bệnh viện?
- Về triển khai: Mô hình là multi-tenant hay multi-instance? Dữ liệu được cô lập ở mức nào? Có lộ trình nâng cấp khi quy mô tăng không?
Khả năng mở rộng không phải tính năng để "ngắm" mà là lớp bảo hiểm cho khoản đầu tư dài hạn của bệnh viện. Một HIS chọn đúng ngay từ đầu sẽ âm thầm gánh tải qua từng mùa cao điểm và từng lần mở rộng cơ sở - còn một lựa chọn sai sẽ bộc lộ giới hạn vào đúng lúc bệnh viện cần nó nhất. Hãy thẩm định kỹ ba trục này trước khi đặt bút ký.
