Mô hình bệnh viện thông minh không phải là một sơ đồ gồm HIS, EMR, LIS, PACS và một vài ứng dụng được đặt cạnh nhau. Để các hệ thống thực sự hoạt động như một bệnh viện thống nhất, cơ sở cần một kiến trúc nhiều lớp, bắt đầu từ hạ tầng kỹ thuật, đi qua thiết bị y tế kết nối, các ứng dụng chuyên môn, nền tảng tích hợp và dữ liệu, rồi mới đến phân tích, điều hành và AI. Có thể hình dung một mô hình tham khảo gồm sáu lớp:

1. Hạ tầng kỹ thuật và kết nối.

2. Thiết bị y tế, cảm biến và IoMT.

3. Các ứng dụng chuyên môn và vận hành.

4. Tích hợp, định danh và dữ liệu.

5. Phân tích, điều hành và AI.

6. Quản trị, an toàn và vận hành liên tục.

Các lớp này không hoạt động độc lập. Một bệnh viện có phần mềm hiện đại nhưng mạng không ổn định vẫn có thể gặp gián đoạn. Thiết bị có khả năng kết nối nhưng thiếu lớp tích hợp phù hợp vẫn khiến nhân viên phải nhập dữ liệu thủ công. Kho dữ liệu lớn nhưng thiếu quản trị dữ liệu cũng khó tạo ra thông tin đáng tin cậy cho điều hành. WHO nhấn mạnh rằng các sáng kiến y tế số cần được dẫn dắt bởi cơ chế quản trị mạnh, đồng thời dựa trên tiêu chuẩn và kiến trúc cho phép các thành phần tích hợp với nhau.

Mô hình bệnh viện thông minh khác danh sách phần mềm như thế nào?

Một danh sách phần mềm có thể cho biết bệnh viện đang sử dụng:

- HIS.

- EMR.

- LIS.

- RIS/PACS.

- Phần mềm dược.

- Phần mềm quản lý thiết bị.

- ERP.

- Ứng dụng người bệnh.

Nhưng danh sách đó chưa giải thích:

- Các hệ thống sử dụng chung mã người bệnh như thế nào.

- Thiết bị y tế kết nối vào đâu.

- Dữ liệu được truyền qua giao diện nào.

- Hệ thống nào là nguồn dữ liệu chính có thẩm quyền cho từng miền thông tin.

- Khi một ứng dụng ngừng hoạt động thì quy trình tiếp tục ra sao.

- Dashboard lấy dữ liệu từ đâu.

- Nhà cung cấp nào chịu trách nhiệm khi một luồng tích hợp gặp lỗi.

Kiến trúc bệnh viện thông minh cần trả lời những câu hỏi này bằng cách xác định vai trò, mối quan hệ và ranh giới trách nhiệm giữa từng lớp. WHO cũng nêu rằng một chiến lược y tế số vững chắc cần tích hợp đồng thời các nguồn lực tài chính, tổ chức, con người và công nghệ. Mô hình sáu lớp dưới đây là khung kiến trúc tham khảo phục vụ lập kế hoạch và trao đổi kỹ thuật, không phải bộ tiêu chí pháp lý chính thức dành cho bệnh viện tại Việt Nam.

Tổng quan sáu lớp của mô hình bệnh viện thông minh

Lớp	Vai trò chính	Thành phần điển hình
1. Hạ tầng kỹ thuật	Tạo nền tảng để toàn bộ hệ thống hoạt động	Điện, UPS, mạng, máy chủ, lưu trữ, trung tâm dữ liệu
2. Thiết bị và IoMT	Thu nhận dữ liệu và thực hiện chức năng tại điểm chăm sóc	Monitor, máy xét nghiệm, thiết bị hình ảnh, cảm biến, gateway
3. Ứng dụng	Hỗ trợ chuyên môn, quản trị và tương tác	HIS, EMR, LIS, RIS/PACS, dược, ERP, cổng người bệnh
4. Tích hợp và dữ liệu	Kết nối hệ thống, quản lý định danh, chuẩn hóa và tổ chức dữ liệu	Integration engine, API gateway, định danh, danh mục dùng chung, nền tảng/kho dữ liệu
5. Phân tích và điều hành	Khai thác dữ liệu để hỗ trợ quyết định và tự động hóa phù hợp	BI, dashboard, cảnh báo, phân tích vận hành, AI
6. Quản trị và vận hành	Kiểm soát vòng đời và mức độ an toàn của toàn bộ kiến trúc	Bảo mật, phân quyền, sao lưu, phương án khi hệ thống gián đoạn, quản lý thay đổi

Điểm quan trọng là lớp phía trên thường phụ thuộc vào độ trưởng thành của các lớp phía dưới. Nếu dữ liệu nguồn thiếu chính xác, AI khó tạo ra khuyến nghị đáng tin cậy. Nếu định danh người bệnh không thống nhất, một dashboard đẹp vẫn có thể tổng hợp sai. Nếu mạng và máy chủ thường xuyên gián đoạn, quy trình số khó duy trì ổn định. Riêng lớp quản trị và vận hành không nên được hiểu là lớp nằm trên cùng theo nghĩa kỹ thuật. Trên thực tế, lớp này cần bao phủ toàn bộ kiến trúc, từ hạ tầng đến dữ liệu và ứng dụng.

Lớp 1: Hạ tầng kỹ thuật và kết nối

Bệnh viện thông minh bắt đầu từ những thành phần ít được người bệnh nhìn thấy nhất. Hạ tầng có thể bao gồm:

- Nguồn điện.

- UPS.

- Máy phát dự phòng.

- Mạng LAN.

- Wi-Fi.

- Cáp quang.

- Switch.

- Hệ thống tường lửa.

- Máy chủ.

- Nền tảng ảo hóa khi áp dụng.

- Hệ thống lưu trữ.

- Hệ thống sao lưu.

- Trung tâm dữ liệu.

- Hệ thống làm mát.

- Phòng máy chủ.

- Hạ tầng cloud hoặc hybrid khi phù hợp.

Ở cấp độ bệnh viện, mạng không chỉ phục vụ máy tính văn phòng. Cùng một hạ tầng có thể phải hỗ trợ:

- Máy trạm bác sĩ.

- Thiết bị điều dưỡng.

- Máy xét nghiệm.

- Thiết bị chẩn đoán hình ảnh.

- Monitor.

- Kiosk.

- Thiết bị di động.

- Camera.

- Điện thoại IP.

- Thiết bị định vị.

- Cảm biến môi trường.

Vì vậy, thiết kế mạng cần được đặt trong bối cảnh lưu lượng, mức độ ưu tiên, bảo mật và nhu cầu vận hành của từng nhóm.

Hạ tầng phải tính đến khả năng tăng trưởng dữ liệu

Dữ liệu của bệnh viện không tăng đều giữa các hệ thống. Một hồ sơ hành chính có kích thước nhỏ hơn đáng kể so với:

- Hình ảnh CT.

- Hình ảnh MRI.

- Video nội soi.

- Dữ liệu monitor liên tục.

- Các tệp hình ảnh chuyên khoa.

- Dữ liệu sinh học phân tử khi áp dụng.

Do đó, bệnh viện cần dự báo:

- Dung lượng hiện tại.

- Tốc độ tăng dữ liệu.

- Thời gian cần lưu.

- Dữ liệu nào cần truy cập nhanh.

- Dữ liệu nào có thể lưu trữ dài hạn.

- Mức dự phòng.

- Thời gian phục hồi sau sự cố.

Không nên xác định dung lượng lưu trữ chỉ dựa trên mức sử dụng tại thời điểm nghiệm thu.

Hạ tầng thông minh không đồng nghĩa với hạ tầng phức tạp nhất

Một hệ thống có thiết kế phù hợp phải đáp ứng nhu cầu thực tế và có khả năng duy trì lâu dài. Cơ sở cần hỏi:

- Đội nội bộ có đủ khả năng vận hành không?

- Phần nào cần nhà cung cấp hỗ trợ?

- Khi một thành phần lỗi có phương án thay thế không?

- Có phụ thuộc vào một công nghệ độc quyền không?

- Có thể mở rộng từng bước không?

- Hạ tầng có được giám sát tập trung không?

Một kiến trúc quá phức tạp so với nguồn lực của bệnh viện có thể làm tăng chi phí và kéo dài thời gian xử lý sự cố.

Lớp 2: Thiết bị y tế, cảm biến và IoMT

Lớp thứ hai đưa thế giới vật lý của bệnh viện vào hệ sinh thái số. Các thiết bị và công nghệ có thể tạo dữ liệu gồm:

- Máy xét nghiệm.

- CT.

- MRI.

- X-quang.

- Siêu âm.

- Monitor theo dõi bệnh nhân.

- Máy thở.

- Bơm truyền.

- Bơm tiêm điện.

- Thiết bị tại phòng mổ.

- Một số thiết bị phục hồi chức năng.

- Cảm biến nhiệt độ.

- Cảm biến môi trường.

- Hệ thống định vị tài sản.

Khi các thiết bị y tế và công nghệ liên quan được kết nối để trao đổi dữ liệu với các hệ thống khác, chúng có thể trở thành một phần của hệ sinh thái Internet of Medical Things (IoMT). Tuy nhiên, không phải mọi cảm biến hoặc thiết bị IoT được sử dụng trong bệnh viện đều mặc nhiên là thiết bị y tế. Một thiết bị kết nối cần làm rõ:

- Thiết bị gửi dữ liệu gì?

- Thiết bị nhận dữ liệu gì?

- Giao thức nào được hỗ trợ?

- Có cần gateway không?

- Có cần bản quyền riêng cho kết nối không?

- Thiết bị được xác thực ra sao?

- Ai quản lý tài khoản kỹ thuật?

- Phiên bản phần mềm được cập nhật thế nào?

- Khi mất mạng, thiết bị có tiếp tục thực hiện chức năng chính không?

Không phải mọi dữ liệu thiết bị đều cần đưa vào EMR

Một monitor có thể tạo nhiều giá trị theo thời gian, trong khi hệ thống bảo trì lại quan tâm đến:

- Số giờ hoạt động.

- Mức pin.

- Mã lỗi.

- Phiên bản firmware.

- Trạng thái kết nối.

Hai nhóm dữ liệu phục vụ những mục đích khác nhau. Bệnh viện cần phân biệt: Dữ liệu lâm sàng → phục vụ chăm sóc hoặc hồ sơ người bệnh. Dữ liệu kỹ thuật → phục vụ quản lý thiết bị, bảo trì và vận hành. Dữ liệu môi trường → phục vụ giám sát điều kiện cơ sở. Không nên chuyển toàn bộ dữ liệu đến cùng một hệ thống chỉ vì về mặt kỹ thuật có thể thực hiện được.

Lớp 3: Các ứng dụng chuyên môn và vận hành

Đây là lớp người dùng tiếp xúc thường xuyên nhất. Có thể chia thành ba nhóm lớn.

Ứng dụng chuyên môn

Ví dụ:

- HIS.

- Hồ sơ bệnh án điện tử.

- LIS.

- RIS/PACS.

- Phần mềm dược.

- Điều dưỡng điện tử.

- Quản lý phòng mổ.

- Hệ thống ICU.

- Phần mềm chuyên khoa.

Vai trò của lớp này là hỗ trợ những quy trình cụ thể của từng đơn vị. Bài toán kiến trúc không phải là yêu cầu một hệ thống thực hiện mọi chức năng. Quan trọng hơn là xác định:

- Hệ thống nào chịu trách nhiệm chính cho loại dữ liệu nào?

- Hệ thống khác truy cập dữ liệu bằng cách nào?

- Có phải nhập lại thông tin không?

- Khi một thông tin thay đổi, hệ thống nào có thẩm quyền cập nhật?

Ứng dụng quản trị

Có thể gồm:

- Quản lý tài chính.

- Nhân sự.

- Kho.

- Mua sắm.

- Tài sản.

- Quản lý thiết bị.

- Quản lý giường.

- Quản lý hợp đồng.

- Quản lý chất lượng.

Các ứng dụng này không trực tiếp tạo chẩn đoán hoặc điều trị nhưng ảnh hưởng lớn đến khả năng vận hành bệnh viện. Ví dụ, phần mềm quản lý thiết bị có thể cung cấp dữ liệu về:

- Thiết bị đang hoạt động.

- Thiết bị đang bảo trì.

- Vị trí.

- Chi phí.

- Tình trạng phụ tùng.

Thông tin này có thể hỗ trợ quyết định mua sắm hoặc phân bổ tài sản.

Ứng dụng tương tác với người bệnh

Có thể gồm:

- Website.

- Ứng dụng di động.

- Cổng người bệnh.

- Đặt lịch.

- Kiosk.

- Thanh toán số.

- Tra cứu kết quả.

- Telehealth.

- Nhắc tái khám.

Điểm cần kiểm tra là những kênh này có thực sự kết nối với quy trình chính hay không. Một ứng dụng đặt lịch chỉ tạo giá trị khi:

- Lịch hiển thị chính xác.

- Hệ thống trung tâm nhận được lịch.

- Thay đổi được đồng bộ.

- Người bệnh không phải đăng ký lại toàn bộ khi đến bệnh viện.

Lớp 4: Tích hợp, định danh và dữ liệu

Đây là lớp quyết định các phần mềm và thiết bị có thể hoạt động như một hệ sinh thái hay chỉ là những hệ thống riêng lẻ. WHO thúc đẩy việc sử dụng các tiêu chuẩn cho interoperability và data sharing; SMART Guidelines cũng hướng đến các hệ thống dựa trên tiêu chuẩn, có khả năng trao đổi dữ liệu chính xác và giảm phân mảnh. Lớp này có thể bao gồm:

- Integration engine.

- API gateway.

- Message broker khi phù hợp.

- Hệ thống quản lý định danh.

- Danh mục dùng chung.

- Master data.

- Nền tảng dữ liệu.

- Kho dữ liệu.

- Nền tảng tích hợp thiết bị.

- Công cụ quản lý log và giao dịch.

Định danh là nền móng của tích hợp

Các hệ thống cần thống nhất hoặc có khả năng ánh xạ:

- Mã người bệnh.

- Mã lượt khám.

- Mã mẫu.

- Mã dịch vụ.

- Mã thuốc.

- Mã thiết bị.

- Mã khoa phòng.

- Mã giường.

- Mã nhân viên.

Nếu cùng một người bệnh được tạo nhiều mã mà không có cơ chế liên kết, dữ liệu có thể bị phân tách ngay cả khi các hệ thống đã kết nối về mặt kỹ thuật.

Danh mục dùng chung cũng quan trọng như giao thức

Hai phần mềm có thể truyền dữ liệu cho nhau nhưng vẫn hiểu khác nhau nếu:

- Tên dịch vụ khác.

- Đơn vị đo khác.

- Mã thuốc khác.

- Cách đặt trạng thái khác.

- Danh mục khoa phòng không đồng nhất.

Vì vậy, bệnh viện cần xác định:

- Ai quản lý danh mục/master data?

- Ai được tạo mã?

- Hệ thống nào là nguồn chính có thẩm quyền?

- Khi một mã ngừng sử dụng, các hệ thống khác được cập nhật ra sao?

“Có API” chưa có nghĩa là đã có kiến trúc tích hợp

Khi đánh giá một giải pháp, cần hỏi sâu hơn:

- API thực hiện chức năng gì?

- Dữ liệu nào có thể đọc?

- Dữ liệu nào có thể ghi?

- Có giới hạn truy cập không?

- Có môi trường kiểm thử không?

- Cách xác thực như thế nào?

- Có nhật ký giao dịch không?

- Phiên bản API được quản lý ra sao?

- Khi API thay đổi, các hệ thống phụ thuộc được thông báo thế nào?

Tích hợp là một năng lực cần được duy trì trong toàn bộ vòng đời, không phải một bước kỹ thuật hoàn tất duy nhất trong ngày nghiệm thu.

Kho dữ liệu thuộc lớp dữ liệu, không phải lớp phân tích

Kho dữ liệu hoặc nền tảng dữ liệu có nhiệm vụ:

- Tập hợp dữ liệu từ nhiều nguồn.

- Tổ chức dữ liệu.

- Lưu trữ.

- Chuẩn hóa.

- Hỗ trợ truy xuất.

- Tạo nền tảng cho các lớp phân tích phía trên.

Do đó, trong mô hình này, data warehouse được xếp ở lớp 4. Lớp 5 sẽ sử dụng dữ liệu đã được tổ chức ở đây để thực hiện phân tích, dashboard, cảnh báo hoặc AI.

Lớp 5: Phân tích, điều hành và AI

Trên nền dữ liệu đã được tích hợp và quản trị ở lớp phía dưới, bệnh viện có thể triển khai các năng lực khai thác dữ liệu như:

- Business Intelligence.

- Dashboard.

- Báo cáo điều hành.

- Hệ thống cảnh báo.

- Phân tích vận hành.

- Công cụ dự báo.

- Các ứng dụng AI khi có bài toán và dữ liệu phù hợp.

Dashboard cần trả lời câu hỏi quản trị

Ví dụ:

- Khoa nào đang có thời gian chờ tăng?

- Giường nào dự kiến trống?

- Thiết bị nào đang dừng?

- Máy nào có mức khai thác thấp?

- Xét nghiệm nào đang có thời gian trả kết quả kéo dài?

- Kho nào có nguy cơ thiếu vật tư?

- Phòng mổ nào đang chậm lịch?

Không nên bắt đầu bằng câu hỏi: “Dashboard nên có bao nhiêu biểu đồ?” Mà nên bắt đầu bằng: “Người quản lý cần đưa ra quyết định gì?”

AI là lớp khai thác, không phải nền móng

AI có thể hỗ trợ:

- Dự báo nhu cầu.

- Phân tích hình ảnh.

- Ưu tiên công việc.

- Phát hiện bất thường.

- Bảo trì dự đoán.

- Hỗ trợ điều hành.

- Phân tích văn bản.

- Hỗ trợ ra quyết định.

Nhưng AI phụ thuộc vào:

- Dữ liệu.

- Định danh.

- Tích hợp.

- Hạ tầng.

- Quy trình.

- Cơ chế quản trị.

WHO năm 2026 cũng nhấn mạnh ba nền tảng chung của digital health và AI là trusted data, interoperable systems và strong governance. Trong mô hình sáu lớp này, AI được đặt tại lớp phân tích để thể hiện sự phụ thuộc vào dữ liệu, tích hợp và hạ tầng phía dưới. Tuy nhiên, trên thực tế chức năng AI không nhất thiết tồn tại như một nền tảng độc lập. AI cũng có thể được nhúng trực tiếp trong:

- Phần mềm chuyên môn.

- Thiết bị y tế.

- PACS.

- Hệ thống quản lý thiết bị.

- Một quy trình hỗ trợ quyết định.

Vị trí trong mô hình nhằm mô tả vai trò kiến trúc, không phải vị trí vật lý cố định của một sản phẩm.

Lớp 6: Quản trị, bảo mật và vận hành liên tục

Lớp này cần bao phủ toàn bộ kiến trúc. Các nội dung có thể gồm:

- Chính sách.

- Phân quyền.

- Quản lý tài khoản.

- An toàn thông tin.

- Quản lý thay đổi.

- Quản lý phiên bản.

- Kiểm thử.

- Sao lưu.

- Phục hồi sau sự cố.

- Quy trình khi hệ thống gián đoạn.

- Quản lý nhà cung cấp.

- Quản lý hợp đồng.

- Đào tạo.

- Quản trị dữ liệu.

- Kiểm soát quyền truy cập từ xa.

WHO xem governance là nền tảng quan trọng để các sáng kiến y tế số có thể tích hợp, mở rộng và được triển khai an toàn.

Kiến trúc phải có người sở hữu

Một vấn đề có thể phát sinh khi:

- HIS do phòng CNTT phụ trách.

- LIS do phòng xét nghiệm làm việc với nhà cung cấp.

- PACS do khoa chẩn đoán hình ảnh quản lý.

- Thiết bị do bộ phận kỹ thuật phụ trách.

- ERP do tài chính triển khai.

Nếu không có một lớp quản trị kiến trúc chung, mỗi dự án có thể đưa ra quyết định riêng. Bệnh viện nên xác định:

- Ai phê duyệt kiến trúc?

- Ai quản lý tiêu chuẩn tích hợp?

- Ai quản trị danh mục?

- Ai phê duyệt kết nối mới?

- Ai chịu trách nhiệm với từng miền dữ liệu?

- Ai xử lý xung đột giữa các nhà cung cấp?

Kiến trúc phải tính đến ngày hệ thống gặp sự cố

Một thiết kế tốt không chỉ mô tả trạng thái bình thường. Cần chuẩn bị khi:

- Mạng dừng.

- Máy chủ chính lỗi.

- PACS không hoạt động.

- LIS mất kết nối với máy.

- Thiết bị gửi dữ liệu trùng.

- Một API ngừng hoạt động.

- Hệ thống cloud không truy cập được.

- Nhà cung cấp cập nhật phần mềm.

- Dữ liệu cần khôi phục.

Mỗi tình huống cần xác định:

- Quy trình tạm thời.

- Người chịu trách nhiệm.

- Cách ghi nhận dữ liệu.

- Cách đồng bộ sau phục hồi.

- Tiêu chí để quay lại vận hành bình thường.

Dữ liệu đi qua sáu lớp như thế nào?

Có thể hình dung bằng một chỉ định chẩn đoán hình ảnh.

Bước 1: Người dùng tạo chỉ định

Bác sĩ tạo chỉ định trên hệ thống chuyên môn. Lớp tham gia: ứng dụng.

Bước 2: Dữ liệu được tích hợp

Chỉ định được gửi đến RIS thông qua cơ chế tích hợp. Thông tin cần gắn với đúng:

- Người bệnh.

- Lượt khám.

- Dịch vụ.

- Thời gian.

- Khoa.

- Người chỉ định.

Lớp tham gia: tích hợp và dữ liệu.

Bước 3: Thiết bị nhận danh sách công việc

CT hoặc MRI nhận thông tin phù hợp để kỹ thuật viên chọn đúng người bệnh và thủ thuật. Lớp tham gia: thiết bị và IoMT.

Bước 4: Hình ảnh được tạo và lưu

Thiết bị tạo hình ảnh và chuyển dữ liệu đến PACS. Quá trình phụ thuộc vào:

- Mạng.

- Máy chủ.

- Hệ thống lưu trữ.

Lớp tham gia: thiết bị + hạ tầng + ứng dụng.

Bước 5: Bác sĩ đọc và trả kết quả

Báo cáo được xác nhận và chuyển trở lại hồ sơ người bệnh. Lớp tham gia: ứng dụng + tích hợp.

Bước 6: Dữ liệu được sử dụng cho điều hành

Bệnh viện có thể phân tích:

- Số lượt chụp.

- Thời gian chờ.

- Thời gian trả kết quả.

- Công suất thiết bị.

Lớp tham gia: dữ liệu + phân tích và điều hành.

Bước 7: Toàn bộ quá trình được quản trị

Bệnh viện kiểm soát:

- Tài khoản.

- Quyền truy cập.

- Nhật ký.

- Sao lưu.

- Bảo mật.

- Phục hồi.

Lớp tham gia: quản trị và vận hành. Một quy trình tương đối đơn giản với người bệnh có thể đồng thời đi qua gần như toàn bộ kiến trúc.

Bệnh viện nên dùng một nền tảng chính hay nhiều hệ thống chuyên biệt?

Đây là một quyết định về chiến lược lựa chọn và tổ chức các hệ thống ứng dụng, không hoàn toàn đồng nghĩa với kiến trúc tập trung hay phân tán theo nghĩa kỹ thuật. Có thể gặp ba cách tiếp cận phổ biến.

Mô hình một nền tảng hoặc suite chính

Một nền tảng hoặc nhóm giải pháp từ một nhà cung cấp đảm nhiệm phần lớn các chức năng cốt lõi. Ưu điểm có thể có:

- Ít giao diện tích hợp hơn.

- Quản trị đơn giản hơn.

- Trải nghiệm người dùng có thể đồng nhất hơn.

Điểm cần kiểm tra:

- Khả năng thay đổi nhà cung cấp.

- Quyền xuất và sử dụng dữ liệu.

- Mức đáp ứng của các module chuyên sâu.

- Nguy cơ phụ thuộc vào hệ sinh thái riêng.

Mô hình nhiều hệ thống chuyên biệt

Bệnh viện lựa chọn các giải pháp chuyên sâu cho từng lĩnh vực và kết nối chúng với nhau. Ưu điểm có thể có:

- Có thể lựa chọn giải pháp phù hợp hơn với từng chuyên khoa.

- Linh hoạt hơn khi thay đổi một thành phần.

Điểm cần kiểm tra:

- Độ phức tạp của tích hợp.

- Quản trị danh mục và định danh.

- Số lượng tài khoản và giao diện.

- Trách nhiệm khi xảy ra lỗi liên hệ thống.

Mô hình kết hợp

Một số nền tảng cốt lõi được chuẩn hóa, trong khi các hệ thống chuyên sâu kết nối thông qua lớp tích hợp. Mô hình này chỉ hoạt động tốt khi bệnh viện kiểm soát được:

- Kiến trúc.

- Giao diện.

- Dữ liệu.

- Quyền sở hữu.

- Trách nhiệm của từng nhà cung cấp.

Không nên lựa chọn mô hình chỉ dựa vào số lượng nhà cung cấp. Quan trọng hơn là bệnh viện có đủ năng lực để quản trị kiến trúc đó trong dài hạn hay không.

Năm nguyên tắc khi xây dựng mô hình bệnh viện thông minh

1. Quy trình đi trước sản phẩm

Không nên bắt đầu bằng: “Bệnh viện cần mua AI, IoT và một data lake.” Nên bắt đầu bằng: “Quy trình nào đang có vấn đề và dữ liệu phải đi qua những bước nào?”

2. Mỗi miền dữ liệu cần xác định nguồn dữ liệu chính có thẩm quyền

Với từng miền dữ liệu, bệnh viện nên xác định hệ thống nào là nguồn chính có thẩm quyền để tạo và cập nhật thông tin, đồng thời quy định cách các hệ thống khác tiếp nhận hoặc đồng bộ dữ liệu. Ví dụ:

- Dữ liệu nhân sự do hệ thống nào quản lý?

- Danh mục thuốc lấy từ đâu?

- Mã thiết bị nằm ở hệ thống nào?

- Danh mục khoa phòng do ai cập nhật?

- Thông tin người bệnh được tạo và hợp nhất ở đâu?

Điều này không có nghĩa dữ liệu chỉ được tồn tại trong một cơ sở dữ liệu duy nhất. Vấn đề là phải xác định nguồn có thẩm quyền để hạn chế nhiều hệ thống cùng sửa một thông tin theo các quy tắc khác nhau.

3. Tích hợp phải được đưa vào yêu cầu mua sắm

Cần làm rõ từ đầu:

- Giao thức.

- API.

- Bản quyền.

- Gateway.

- Trách nhiệm tích hợp.

- Tài liệu.

- Môi trường kiểm thử.

- Tiêu chí nghiệm thu.

Không nên mua thiết bị hoặc phần mềm trước rồi mới xác định khả năng tích hợp.

4. Không xây lớp trên khi lớp dưới chưa đủ sẵn sàng

Ví dụ:

- Chưa có mã thiết bị chuẩn → khó phân tích mức sử dụng.

- Chưa chuẩn hóa danh mục → dashboard khó đáng tin cậy.

- Chưa có dữ liệu lịch sử → AI khó dự báo.

- Mạng chưa ổn định → IoMT khó vận hành.

Điều này không có nghĩa bệnh viện phải hoàn thiện tuyệt đối từng lớp trước khi triển khai lớp tiếp theo. Tuy nhiên, cần xác định rõ những phụ thuộc quan trọng để tránh xây thêm một hệ thống trên nền dữ liệu chưa ổn định.

5. Kiến trúc phải có khả năng thay đổi

Bệnh viện thường có vòng đời dài hơn nhiều hệ thống phần mềm. Trong thời gian hoạt động, cơ sở có thể:

- Thay HIS.

- Nâng PACS.

- Đổi máy xét nghiệm.

- Thêm nhà cung cấp.

- Chuyển mô hình lưu trữ.

- Triển khai AI mới.

Kiến trúc cần cho phép thay đổi từng thành phần mà không bắt buộc xây dựng lại toàn bộ hệ thống.

Lộ trình xây dựng mô hình bệnh viện thông minh

Giai đoạn 1: Vẽ kiến trúc hiện tại

Liệt kê:

- Hạ tầng.

- Phần mềm.

- Thiết bị kết nối.

- Nguồn dữ liệu.

- Giao diện.

- Nhà cung cấp.

- Người sở hữu hệ thống.

Sau đó vẽ các luồng dữ liệu và quy trình chính.

Giai đoạn 2: Xác định điểm đứt gãy

Tìm những nơi:

- Phải nhập lại dữ liệu.

- Dùng Excel trung gian.

- Chuyển file thủ công.

- Không thống nhất mã.

- Không có nhật ký.

- Không có phương án dự phòng.

- Không rõ trách nhiệm nhà cung cấp.

Giai đoạn 3: Xây dựng kiến trúc mục tiêu

Xác định:

- Những nền tảng nào giữ lại.

- Những hệ thống nào cần thay thế.

- Lớp tích hợp cần có.

- Nguồn dữ liệu chính có thẩm quyền.

- Kiến trúc lưu trữ.

- Cách kết nối thiết bị.

- Các yêu cầu an toàn.

Giai đoạn 4: Ưu tiên theo giá trị

Không nhất thiết triển khai mọi lớp cùng lúc. Có thể ưu tiên:

- Định danh người bệnh.

- Luồng xét nghiệm.

- Chẩn đoán hình ảnh.

- Hồ sơ điện tử.

- Quản lý thuốc.

- Thiết bị tại giường.

- Nền tảng dữ liệu.

Thứ tự phụ thuộc vào vấn đề thực tế của từng bệnh viện.

Giai đoạn 5: Kiểm thử tích hợp

Không chỉ kiểm thử từng phần mềm. Cần kiểm thử xuyên hệ thống với các tình huống như:

- Người bệnh trùng tên.

- Hủy chỉ định.

- Sửa thông tin.

- Chuyển khoa.

- Mất mạng.

- Thiết bị gửi dữ liệu trùng.

- Máy chủ lỗi.

- Khôi phục dữ liệu.

Giai đoạn 6: Đo hiệu quả

Có thể theo dõi:

- Tỷ lệ nhập lại dữ liệu.

- Thời gian chờ.

- Tỷ lệ lỗi tích hợp.

- Thời gian gián đoạn.

- Thời gian trả kết quả.

- Mức sử dụng hệ thống.

- Tỷ lệ thao tác thủ công.

- Phản hồi người dùng.

Những sai lầm thường gặp khi xây dựng mô hình bệnh viện thông minh

Vẽ kiến trúc theo tên nhà cung cấp

Kiến trúc nên mô tả vai trò và chức năng trước, sản phẩm sau. Nếu sơ đồ chỉ gồm logo nhà cung cấp, bệnh viện khó đánh giá khả năng thay đổi trong tương lai.

Mỗi dự án tạo một cơ sở dữ liệu riêng

Điều này dễ hình thành nhiều bản sao không được quản trị thống nhất của:

- Người bệnh.

- Nhân viên.

- Dịch vụ.

- Thiết bị.

- Khoa phòng.

Kết nối điểm – điểm quá nhiều

Khi mỗi hệ thống kết nối trực tiếp với nhiều hệ thống khác, số lượng giao diện có thể tăng nhanh và khó kiểm soát. Một lớp tích hợp trung gian có thể hữu ích khi quy mô và nhu cầu của cơ sở phù hợp.

Chỉ xây dựng kiến trúc công nghệ

Một sơ đồ đầy đủ máy chủ và phần mềm vẫn chưa đủ nếu thiếu:

- Người sở hữu dữ liệu.

- Quy trình quản trị.

- Chính sách.

- Phương án vận hành.

- Trách nhiệm nhà cung cấp.

Bắt đầu bằng AI

AI là một năng lực khai thác dữ liệu. Nếu dữ liệu và tích hợp chưa ổn định, triển khai AI trước có thể tạo thêm một hệ thống riêng cần duy trì.

Không tính chi phí tích hợp

Giá phần mềm hoặc thiết bị chưa chắc bao gồm:

- API.

- Bản quyền.

- Gateway.

- Middleware.

- Tùy chỉnh.

- Kiểm thử.

- Bảo trì giao diện.

Những chi phí này cần được làm rõ từ giai đoạn mua sắm.

Checklist rà soát kiến trúc bệnh viện thông minh

Hạ tầng

- Có sơ đồ mạng cập nhật.

- Có dự phòng nguồn.

- Có hệ thống sao lưu.

- Đã kiểm thử phục hồi.

- Dung lượng lưu trữ có kế hoạch mở rộng.

- Thiết bị và hệ thống được giám sát phù hợp.

Thiết bị

- Danh sách thiết bị kết nối được xác định.

- Có tài liệu giao diện.

- Phạm vi dữ liệu rõ ràng.

- Có phương án khi mất kết nối.

- Phiên bản phần mềm được quản lý.

Ứng dụng

- Vai trò của từng hệ thống rõ.

- Hạn chế trùng chức năng không cần thiết.

- Nguồn có thẩm quyền của từng miền dữ liệu được xác định.

- Có khả năng xuất dữ liệu.

Tích hợp

- Có chiến lược giao diện.

- Có môi trường kiểm thử.

- Có nhật ký lỗi.

- Có quản lý phiên bản.

- Có người chịu trách nhiệm.

Dữ liệu

- Định danh được quản lý thống nhất.

- Có danh mục dùng chung.

- Quyền sở hữu và trách nhiệm dữ liệu rõ.

- Chất lượng dữ liệu được theo dõi.

- Có chính sách lưu trữ.

Phân tích

- Dashboard gắn với quyết định cụ thể.

- Chỉ số có định nghĩa.

- Có thể truy xuất nguồn.

- AI có bài toán rõ ràng.

Quản trị

- Phân quyền rõ.

- Có quản lý thay đổi.

- Có kế hoạch khi hệ thống gián đoạn.

- Có phương án phục hồi.

- Nhà cung cấp có trách nhiệm cụ thể.

- Có cơ chế rà soát kiến trúc định kỳ.

Câu hỏi thường gặp về mô hình bệnh viện thông minh

Bệnh viện thông minh gồm những lớp nào?

Có nhiều cách mô hình hóa. Một khung tham khảo có thể gồm hạ tầng kỹ thuật, thiết bị và IoMT, ứng dụng, tích hợp và dữ liệu, phân tích – điều hành – AI, cùng lớp quản trị và vận hành bao phủ toàn hệ thống.

HIS có phải là trung tâm của bệnh viện thông minh không?

HIS có thể là một nền tảng quan trọng nhưng không nhất thiết phải chứa mọi chức năng. Vai trò cụ thể phụ thuộc vào kiến trúc của từng bệnh viện.

Có bắt buộc dùng một nhà cung cấp cho toàn bộ hệ thống không?

Không. Mô hình một suite chính và mô hình nhiều hệ thống chuyên biệt đều có ưu và nhược điểm. Quan trọng là khả năng tích hợp, quản trị dữ liệu, quyền kiểm soát hệ thống và năng lực vận hành lâu dài.

IoMT khác IoT thông thường như thế nào?

IoMT thường đề cập đến hệ sinh thái thiết bị y tế và công nghệ kết nối phục vụ môi trường chăm sóc sức khỏe. Không phải mọi thiết bị IoT được sử dụng trong bệnh viện đều là thiết bị y tế.

Bệnh viện có nên xây data warehouse trước khi hoàn thiện tích hợp không?

Có thể triển khai theo từng giai đoạn, nhưng giá trị và chất lượng của kho dữ liệu phụ thuộc lớn vào khả năng tích hợp, định danh và chuẩn hóa dữ liệu từ các hệ thống nguồn.

AI nằm ở đâu trong kiến trúc bệnh viện thông minh?

Trong khung này, AI được đặt ở lớp phân tích và điều hành để thể hiện sự phụ thuộc vào dữ liệu và tích hợp. Trong thực tế, AI cũng có thể được nhúng trực tiếp trong một phần mềm hoặc thiết bị cụ thể.

Có một kiến trúc bệnh viện thông minh chuẩn áp dụng cho mọi bệnh viện không?

Nội dung bài viết mang tính chất thông tin tham khảo. Mô hình sáu lớp được sử dụng nhằm hỗ trợ cách tiếp cận kiến trúc và lập kế hoạch, không thay thế các tiêu chí, tiêu chuẩn hoặc yêu cầu pháp lý đang áp dụng cho từng cơ sở.

Đối chiếu từng lớp của bệnh viện thông minh với giải pháp thực tế tại PHARMEDI & HEALTHCARE VIETNAM 2026

Một sơ đồ kiến trúc chỉ thực sự hữu ích khi bệnh viện có thể đối chiếu từng lớp với những công nghệ, thiết bị và giải pháp có khả năng triển khai trong thực tế. Từ thiết bị y tế kết nối đến nền tảng dữ liệu, y tế số và chăm sóc sức khỏe thông minh, mỗi thành phần đều cần được xem xét trong mối quan hệ với toàn hệ thống.

Tại PHARMEDI & HEALTHCARE VIETNAM 2026, Khu vực Trưng bày sản phẩm tập hợp nhiều nhóm sản phẩm và giải pháp của ngành y tế. Nội dung chính thức của sự kiện đề cập các lĩnh vực từ thiết bị y tế, chẩn đoán hình ảnh, xét nghiệm đến y tế số và công nghệ chăm sóc sức khỏe thông minh.

Với bệnh viện đang xây dựng hoặc rà soát kiến trúc mục tiêu, tham quan PHARMEDI VIETNAM 2026 có thể là dịp để đánh giá giải pháp theo từng lớp thay vì xem từng sản phẩm riêng lẻ:

- Thiết bị có thể kết nối với kiến trúc hiện tại bằng cách nào?

- Giải pháp cần thêm gateway, middleware hoặc bản quyền tích hợp nào?

- Hệ thống có cho phép xuất và trao đổi dữ liệu với nền tảng khác không?

- Những thành phần nào cần triển khai cùng nhau để tạo thành một quy trình hoàn chỉnh?

- Khi một hệ thống mất kết nối, những chức năng nào vẫn có thể tiếp tục hoạt động?

- Giải pháp có phụ thuộc vào định dạng dữ liệu hoặc hệ sinh thái riêng của nhà cung cấp không?

- Việc mở rộng thêm thiết bị, khoa phòng hoặc mô-đun trong tương lai được thực hiện như thế nào?

- Nhà cung cấp chịu trách nhiệm đến đâu đối với tích hợp, kiểm thử và hỗ trợ sau triển khai?

Nội dung giới thiệu chính thức của PHARMEDI cũng cho thấy sự kiện hướng đến một hệ sinh thái trải rộng từ thiết bị y tế, chẩn đoán hình ảnh, xét nghiệm, y tế số đến công nghệ chăm sóc sức khỏe thông minh. Chính sự đa dạng này tạo điều kiện để cơ sở y tế quan sát mối liên hệ giữa nhiều thành phần của kiến trúc, thay vì chỉ tìm kiếm một phần mềm hoặc một thiết bị riêng lẻ.

Từ kiến trúc công nghệ đến chiến lược đầu tư và vận hành

Góc nhìn về kiến trúc bệnh viện còn được mở rộng tại Chuỗi Hội thảo Quốc tế về Đầu tư và Đổi mới trong ngành Chăm sóc Sức khỏe, diễn ra trong hai ngày 22–23/09/2026.

Trong Ngày 1 – 22/09, chương trình tập trung vào Ngành Chăm sóc Sức khỏe Việt Nam – Thập Kỷ Tăng Trưởng Tiếp Theo, với các thảo luận xoay quanh nhu cầu chăm sóc sức khỏe, xu hướng đầu tư, quyết định mua sắm vật tư và đầu tư bệnh viện, cũng như ứng dụng AI trong chăm sóc sức khỏe.

Tiếp nối vào Ngày 2 – 23/09, trọng tâm chuyển sang Quản lý & Vận hành Bệnh viện, bao gồm mô hình bệnh viện tương lai thông minh, bền vững và lấy người bệnh làm trung tâm; vận hành và chứng nhận bệnh viện; đổi mới lâm sàng; chiến lược tăng trưởng và bài toán cân bằng giữa chất lượng, khả năng tiếp cận với hiệu quả tài chính.

Với một dự án bệnh viện thông minh, hai nhóm nội dung này có mối liên hệ trực tiếp với kiến trúc công nghệ: Day 1 đặt câu hỏi nên đầu tư vào đâu và công nghệ nào tạo giá trị, trong khi Day 2 mở rộng sang cách các hệ thống đó cần hỗ trợ mô hình vận hành bệnh viện trong dài hạn.

B2B Matchmaking – Đi sâu vào bài toán tích hợp với từng đối tác

Khi đã xác định kiến trúc mục tiêu và những khoảng trống cần bổ sung, B2B Matchmaking tại PHARMEDI tạo thêm cơ hội kết nối 1-1 giữa khách chuyên ngành và doanh nghiệp dựa trên nhu cầu và mức độ phù hợp.

Với bệnh viện, buổi trao đổi có thể đi sâu hơn vào những câu hỏi mang tính kiến trúc như: hệ thống nằm ở lớp nào, trao đổi dữ liệu với những nền tảng nào, cần gateway hoặc middleware gì, quyền truy cập dữ liệu ra sao, bên nào chịu trách nhiệm tích hợp và hệ thống có thể mở rộng hoặc thay thế từng thành phần trong tương lai hay không.

Qua đó, PHARMEDI & HEALTHCARE VIETNAM 2026 có thể giúp bệnh viện chuyển từ câu hỏi:

“Cần mua hệ thống nào?”

sang câu hỏi quan trọng hơn:

“Giải pháp này sẽ nằm ở đâu trong kiến trúc, kết nối với những gì và được vận hành như thế nào trong dài hạn?”

Thời gian: 22–24/09/2026

Địa điểm: Trung tâm Hội chợ và Triển lãm Sài Gòn (SECC), TP. Hồ Chí Minh

Đăng ký gian hàng:https://pharmed.vn/exhibitor/application-form

Đăng ký tham quan:https://ers-vn.informa-info.com/pha2026?cid=FB

Liên hệ:

Đặt gian hàng: [email protected] (Thanh Thuý)

Hỗ trợ truyền thông: [email protected] (Anita Pham)

Hỗ trợ tham quan: [email protected] (Ciel Le)

Tin liên quan

• Hợp Tác Y Tế Việt - Pháp Thúc Đẩy Nâng Tầm Dịch Vụ Y Tế Việt Nam
• Hướng Dẫn Toàn Diện Về Phân Nhóm Thiết Bị Y Tế Theo Tiêu Chuẩn Tại Việt Nam
• Thông tư số 40/2025/TT-BYT thay thế hoàn toàn Thông tư số 07/2024/TT-BYT ngày 17/5/2024
• Lô thiết bị y tế trị giá 126 tỷ đồng từ Thụy Sĩ đến Việt Nam
• City to host int’l pharma, health expo (http://vietnamnews.vn/economy)