Bỏ qua tới nội dung
Duall Master
Hệ thống kiểm soát ra vào bệnh viện: checklist triển khai từ khu vực đến quy trình article background
← Quay lại tin tức
Hướng dẫn 15 tháng 9, 2026 · 9 phút đọc

Hệ thống kiểm soát ra vào bệnh viện: checklist triển khai từ khu vực đến quy trình

Checklist triển khai kiểm soát ra vào bệnh viện theo khu vực, nhân viên, khách thăm, nhà thầu, quyền tạm thời và vận hành offline-first.

Hệ thống kiểm soát ra vào bệnh viện: checklist triển khai từ khu vực đến quy trình

Bệnh viện là môi trường có lưu lượng người cao nhưng không phải mọi khu vực đều có cùng mức độ mở. Bệnh nhân và người nhà cần di chuyển thuận tiện đến nơi khám; nhân viên y tế cần vào đúng khoa và đúng ca; nhà thầu phải tiếp cận khu vực kỹ thuật theo công việc; còn kho thuốc, phòng máy chủ, phòng xét nghiệm hoặc khu lưu trữ hồ sơ cần chính sách chặt hơn.

Vì vậy, hệ thống kiểm soát ra vào bệnh viện không nên được thiết kế như một danh sách cửa và đầu đọc riêng lẻ. Bài toán cần bắt đầu từ luồng người, mức rủi ro, thời gian hiệu lực và trách nhiệm vận hành. Thiết bị chỉ là một phần của mô hình gồm định danh, khu vực, quyền, lịch, sự kiện và nhật ký.

1. Phân vùng trước khi chọn thiết bị

Một đầu đọc phù hợp ở cửa văn phòng chưa chắc phù hợp với lối cấp cứu, khu vô trùng hoặc cổng kỹ thuật. Trước khi chọn thẻ, QR, PIN hay nhận diện khuôn mặt, đội dự án nên lập bản đồ các nhóm khu vực:

  • Khu công cộng: sảnh, khu đăng ký, hành lang khám, khu chờ và các lối được phép cho bệnh nhân.
  • Khu chăm sóc có kiểm soát: khoa điều trị, phòng thủ thuật, khu lưu bệnh hoặc tầng nội trú.
  • Khu hạn chế: kho thuốc, phòng xét nghiệm, kho vật tư, phòng hồ sơ, phòng server và khu kỹ thuật.
  • Luồng nhân viên: cửa nhân viên, phòng thay đồ, lối theo ca và khu hành chính.
  • Luồng dịch vụ: giao nhận, suất ăn, vệ sinh, bảo trì, chất thải và nhà thầu.
  • Điểm phương tiện: cổng xe nhân viên, xe dịch vụ, xe cấp cứu hoặc khu đỗ xe nếu thuộc phạm vi dự án.

Mỗi khu vực cần có chủ sở hữu nghiệp vụ, nhóm người được phép, lịch truy cập, cách xử lý ngoại lệ và mức độ lưu vết. Không nên áp dụng một nhóm quyền rộng cho toàn bệnh viện chỉ vì cấu hình nhanh hơn.

2. Tách nhóm người dùng và vòng đời quyền

Các nhóm người trong bệnh viện có thời hạn và phạm vi rất khác nhau. Hệ thống cần phản ánh đúng khác biệt đó:

  • Nhân viên chính thức: quyền theo đơn vị, vai trò, cơ sở làm việc, khoa/phòng và lịch công tác.
  • Nhân viên luân phiên hoặc hỗ trợ: quyền tại site hoặc khoa khác trong khoảng thời gian cụ thể.
  • Thực tập sinh và học viên: quyền theo chương trình, người phụ trách, khu vực và ngày kết thúc.
  • Bệnh nhân và người nhà: chỉ cấp quyền nếu quy trình thực tế cần, với phạm vi và thời hạn phù hợp lượt khám hoặc đợt điều trị.
  • Khách làm việc: gắn với cuộc hẹn, người tiếp đón, mục đích và khu vực được duyệt.
  • Nhà thầu và đội dịch vụ: gắn với công việc, đơn vị, người bảo lãnh, lịch làm và ngày hết hạn.

Một hồ sơ định danh có thể dùng xuyên suốt nền tảng, nhưng quyền phải thay đổi theo trạng thái thực tế. Khi nhân viên chuyển khoa, kết thúc hợp đồng hoặc nghỉ việc, quyền cũ cần được rà soát và thu hồi. Khi công việc của nhà thầu kết thúc, quyền tạm thời phải tự hết hạn thay vì phụ thuộc vào việc trả lại thẻ.

3. Thiết kế quyền theo vai trò, khu vực và lịch

Quyền ra vào nên trả lời đồng thời bốn câu hỏi: ai, được vào đâu, khi nào và vì lý do gì. Chỉ phân quyền theo chức danh thường chưa đủ.

Ví dụ, một nhân viên dược có thể được vào kho thuốc tại cơ sở chính trong ca được phân công, nhưng không mặc định có quyền tại mọi kho thuốc của các cơ sở khác. Đội kỹ thuật có thể cần vào phòng máy ngoài giờ để xử lý sự cố, nhưng thao tác đó nên có lịch hoặc phê duyệt phù hợp. Bảo vệ có thể được mở cửa thủ công trong tình huống đã quy định, nhưng hệ thống cần ghi người thao tác và lý do.

Khi xây dựng nhóm quyền, nên kiểm tra:

  • quyền có giới hạn theo site, tòa nhà, tầng và vùng không;
  • lịch có phản ánh ca ngày, ca đêm, cuối tuần và trực khẩn không;
  • quyền tạm thời có ngày bắt đầu và kết thúc rõ ràng không;
  • thay đổi vai trò hoặc khoa/phòng có kích hoạt rà soát quyền cũ không;
  • các khu vực nhạy cảm có yêu cầu phê duyệt hoặc mức audit cao hơn không.

4. Quản lý khách thăm phải kết nối với quyền ra vào

Một sổ khách điện tử chỉ ghi tên và số điện thoại chưa giải quyết được bài toán ra vào. Luồng quản lý khách thăm bệnh viện cần xác định ai mời hoặc xác nhận khách, khách đến đâu, trong thời gian nào và quyền được thu hồi khi nào.

Tùy phạm vi triển khai, một lượt khách có thể gồm:

  • đăng ký trước hoặc tiếp nhận tại quầy;
  • xác minh thông tin theo chính sách của đơn vị;
  • ghi nhận người hoặc bộ phận tiếp đón;
  • chỉ định sảnh, tầng, khoa, cửa hoặc thang máy được phép;
  • cấp QR, thẻ tạm hoặc phương thức xác thực phù hợp;
  • check-out hoặc tự hết hạn sau khung giờ;
  • lưu lại lượt được phép, bị từ chối và can thiệp thủ công.

Khách thăm bệnh nhân, đối tác làm việc, đội giao hàng và nhà thầu không nên dùng chung một quyền mặc định. Mỗi nhóm có mục đích, điểm đến và mức độ kiểm soát khác nhau.

5. Nhà thầu và đội dịch vụ cần được quản lý theo công việc

Bệnh viện thường có nhiều đội bảo trì thiết bị, hệ thống điện, HVAC, vệ sinh, suất ăn, CNTT hoặc xây dựng. Đây là nhóm quay lại thường xuyên và dễ tích lũy quyền quá rộng nếu chỉ cấp một thẻ dài hạn.

Một hồ sơ nhà thầu nên có công ty, người phụ trách nội bộ, nội dung công việc, khu vực được vào, lịch làm, thời hạn và thông tin xác thực. Nếu công việc thay đổi từ khu hành chính sang khu kỹ thuật, quyền cũng phải được thay đổi theo phạm vi mới. Mọi lượt ngoài giờ, ngoài khu vực hoặc bị từ chối cần có khả năng tra cứu để đội an ninh xử lý.

6. Vận hành offline-first để cửa không phụ thuộc vào đường truyền

Bệnh viện không thể coi mất kết nối mạng là lý do để toàn bộ cửa dừng hoạt động hoặc phải mở tay hàng loạt. Với mô hình offline-first, quyền hợp lệ được đồng bộ xuống thiết bị; thiết bị xử lý quyết định tại chỗ; máy chủ đồng bộ chính sách và tổng hợp sự kiện.

Đội mua hàng và nghiệm thu nên kiểm tra thực tế:

  • cửa xử lý quyền hiện có thế nào khi mất kết nối máy chủ;
  • thiết bị lưu được bao nhiêu sự kiện cục bộ;
  • sự kiện được gửi lại ra sao khi mạng phục hồi;
  • quyền mới và quyền vừa thu hồi được xử lý thế nào trong thời gian offline;
  • đồng hồ thiết bị được đồng bộ và giám sát thế nào;
  • trạng thái mất kết nối có cảnh báo cho người vận hành không;
  • phương án nguồn dự phòng và thao tác an toàn tại cửa là gì.

Những yêu cầu liên quan đến lối thoát hiểm, phòng cháy chữa cháy và cơ chế mở cửa khi khẩn cấp phải được thiết kế, kiểm thử và nghiệm thu theo tiêu chuẩn, quy định và phạm vi kỹ thuật áp dụng cho từng cơ sở; không nên suy ra chỉ từ cấu hình phần mềm.

7. Nhật ký cần hỗ trợ điều tra, không chỉ đếm lượt vào

Khi có sự cố, đội vận hành cần tìm được bối cảnh đầy đủ thay vì chỉ thấy trạng thái “được phép” hoặc “bị từ chối”. Một sự kiện hữu ích nên liên kết được với:

  • người hoặc thông tin xác thực;
  • site, khoa/phòng, vùng, cửa và thiết bị;
  • thời điểm, kết quả và lý do từ chối;
  • lịch hoặc chính sách đã áp dụng;
  • trạng thái online/offline của thiết bị;
  • người mở cửa thủ công và lý do;
  • camera hoặc video liên quan nếu hệ thống đã được cấu hình kết nối.

Cũng cần tách sự kiện tại cửa khỏi audit quản trị. Một lớp cho biết điều gì đã xảy ra ở điểm truy cập; lớp còn lại cho biết ai đã tạo người dùng, đổi lịch, cấp hoặc thu hồi quyền, mở cửa từ xa hay xuất dữ liệu.

8. Pilot một khu vực đủ đại diện trước khi mở rộng

Pilot không nên chỉ chọn một cửa văn phòng ít người. Phạm vi thử nghiệm tốt cần có ít nhất một luồng nhân viên theo ca, một khu vực hạn chế, một quyền khách hoặc nhà thầu có thời hạn, một tình huống mất mạng và một kịch bản tra cứu sự kiện.

Trước nghiệm thu, hãy kiểm thử cả trường hợp hợp lệ và không hợp lệ: đúng người nhưng sai giờ, đúng thẻ nhưng sai khu vực, quyền vừa hết hạn, thiết bị offline, sự kiện gửi lại sau khi có mạng, mở cửa thủ công và quyền bị thu hồi. Sau pilot, chuẩn hóa cấu hình, tài liệu, đào tạo và tiêu chí bàn giao rồi mới mở rộng theo khoa, tòa nhà hoặc cơ sở.

Checklist dành cho đội mua hàng và vận hành

  • Sơ đồ site, tòa nhà, tầng, khoa/phòng, vùng và cửa đã được thống nhất chưa?
  • Mỗi khu vực có chủ sở hữu nghiệp vụ và mức rủi ro rõ ràng không?
  • Nhân viên, học viên, bệnh nhân, khách và nhà thầu có luồng riêng không?
  • Quyền có giới hạn theo vai trò, khu vực, lịch và thời hạn không?
  • Chuyển khoa, nghỉ việc hoặc kết thúc hợp đồng có dẫn đến rà soát quyền không?
  • Khách thăm có người tiếp đón, phạm vi, thời gian và cơ chế tự hết hạn không?
  • Nhà thầu có được quản lý theo công việc và người bảo lãnh không?
  • Thiết bị có ra quyết định tại chỗ khi đường truyền gián đoạn không?
  • Sự kiện offline, đồng bộ lại và trạng thái thiết bị đã được kiểm thử chưa?
  • Có tra cứu được lượt bị từ chối và thao tác mở cửa thủ công không?
  • Audit thay đổi quyền có tách bạch với sự kiện tại cửa không?
  • Có thể pilot và mở rộng từng khu vực mà không phải tạo lại toàn bộ dữ liệu không?

Duall Master phù hợp với mô hình này như thế nào?

Duall Master đặt Access Control, Visitor Management, Attendance, Parking, Video Management và Video Intercom trên cùng nền móng định danh, khu vực, quyền, thiết bị, sự kiện và nhật ký. Bệnh viện có thể bắt đầu từ Access Control cho nhân viên và khu vực hạn chế, kết nối Visitor Management cho các luồng khách phù hợp, rồi mở rộng theo phân hệ dựa trên nhu cầu đã kiểm chứng.

Theo nguyên tắc offline-first, thiết bị xử lý quyết định ra vào tại chỗ bằng quyền đã đồng bộ; máy chủ đảm nhiệm quản lý chính sách và tổng hợp sự kiện. Phạm vi thiết bị, tích hợp, quy trình khẩn cấp và yêu cầu tuân thủ vẫn cần được khảo sát, thiết kế và nghiệm thu riêng cho từng dự án.