HIPAA Compliance Checklist cho công ty phần mềm và HealthTech Việt Nam

HIPAA compliance checklist cho công ty phần mềm gồm năm nhóm việc: ký BAA, làm risk analysis bằng văn bản, triển khai administrative, physical và technical safeguards của Security Rule (45 CFR Part 164 Subpart C), có quy trình báo breach, và quản lý vendor chạm tới ePHI. Mỗi mục dưới đây ghi rõ căn cứ: yêu cầu trong quy định (required), yêu cầu phải đánh giá và ghi quyết định (addressable), hay thực hành phổ biến mà khách hàng thường hỏi.

Checklist này dùng cho ai và đọc thế nào?

Checklist dành cho công ty phần mềm và HealthTech Việt Nam làm business associate cho covered entity Mỹ, dù bạn outsource cho khách hay vận hành sản phẩm SaaS của chính mình. Nếu chưa chắc mình có phải business associate không, đọc trước bài HIPAA có áp dụng cho công ty Việt Nam không. Ba nhãn được dùng:

Danh sách đầy đủ 18 standard của ba nhóm safeguard có trong HIPAA safeguards, và hướng dẫn triển khai chi tiết theo từng standard có trong NIST SP 800-66 Rev. 2. Checklist không thay thế tư vấn pháp lý; nó giúp bạn xác định phạm vi và gap.

Hợp đồng và hồ sơ cần những gì?

Hợp đồng là nơi nghĩa vụ của bạn được xác lập, nên làm đầu tiên.

• [ ] BAA đã ký với mọi covered entity hoặc business associate bạn xử lý PHI cho họ (Required, §164.502(e), nội dung theo §164.504(e))
• [ ] Subcontractor BAA với mọi nhà thầu phụ xử lý PHI thay bạn (Required, §164.502(e)(1)(ii))
• [ ] Chính sách, quy trình và hồ sơ hành động, đánh giá được lưu 6 năm kể từ ngày tạo hoặc ngày cuối còn hiệu lực (§164.316(b)(2))
• [ ] Quy trình rà lại BAA khi hợp đồng thay đổi hoặc kết thúc, gồm việc trả hoặc hủy PHI (Thực hành, theo điều khoản BAA)

Administrative safeguards gồm những mục nào?

Administrative safeguards tại §164.308 là nhóm lớn nhất và thường thiếu nhất ở công ty kỹ thuật.

• [ ] Risk analysis bằng văn bản, xác định mọi nơi có ePHI (Required, §164.308(a)(1)(ii)(A))
• [ ] Risk management: kế hoạch giảm rủi ro xuống mức hợp lý (Required, §164.308(a)(1)(ii)(B))
• [ ] Chính sách xử lý vi phạm của nhân viên (sanction policy) (Required, §164.308(a)(1)(ii)(C))
• [ ] Review định kỳ log và báo cáo hoạt động hệ thống (Required, §164.308(a)(1)(ii)(D))
• [ ] Chỉ định security official (Required, §164.308(a)(2))
• [ ] Quy trình cấp, thay đổi, thu hồi quyền truy cập, gồm khi nhân viên nghỉ việc (§164.308(a)(3)–(4)); phê duyệt và giám sát, xác định mức truy cập theo vai trò (clearance) và thủ tục chấm dứt là Addressable
• [ ] Security awareness training cho toàn bộ workforce (§164.308(a)(5)); lưu ai được đào tạo, khi nào, nội dung gì. Quy định không ấn định tần suất; nhiều công ty chọn hằng năm
• [ ] Bốn specification đi kèm training: security reminders, phòng chống mã độc, giám sát đăng nhập (log-in monitoring) và quản lý mật khẩu (Addressable, §164.308(a)(5)(ii)(A)–(D))
• [ ] Quy trình phát hiện, ứng phó và ghi nhận security incident (Required, §164.308(a)(6))
• [ ] Contingency plan: backup, disaster recovery, chế độ vận hành khẩn cấp (Required, §164.308(a)(7)); kiểm thử kế hoạch và phân tích mức độ quan trọng của từng ứng dụng, dữ liệu (applications and data criticality analysis) là Addressable
• [ ] Đánh giá định kỳ và khi môi trường thay đổi (Required, §164.308(a)(8))

Physical safeguards áp dụng thế nào với team làm từ xa?

Physical safeguards tại §164.310 áp dụng cả với laptop của developer làm từ xa, không chỉ văn phòng và server room.

• [ ] Kiểm soát ra vào nơi đặt hệ thống chứa ePHI (§164.310(a))
• [ ] Quy định sử dụng và bảo vệ workstation truy cập ePHI (§164.310(b)–(c)); khóa màn hình tự động là cách làm phổ biến
• [ ] Quy trình hủy và tái sử dụng thiết bị, media chứa ePHI (Required, §164.310(d)(2)(i)–(ii))
• [ ] Ghi lại việc di chuyển phần cứng và media chứa ePHI, ai chịu trách nhiệm (accountability, Addressable, §164.310(d)(2)(iii)); danh sách laptop và điện thoại có truy cập ePHI là cách làm phổ biến
• [ ] Mã hóa toàn ổ đĩa và khả năng xóa từ xa cho laptop (Thực hành, giúp đáp ứng các standard trên và encryption Addressable)

Technical safeguards developer cần triển khai là gì?

Technical safeguards tại §164.312 là phần developer chịu trách nhiệm trực tiếp.

• [ ] User ID riêng cho mỗi người, không dùng tài khoản chung (Required, §164.312(a)(2)(i))
• [ ] Thủ tục truy cập khẩn cấp (break-glass) có log (Required, §164.312(a)(2)(ii))
• [ ] Tự động đăng xuất sau thời gian không hoạt động (Addressable, §164.312(a)(2)(iii))
• [ ] Mã hóa ePHI khi lưu trữ (Addressable, §164.312(a)(2)(iv))
• [ ] Audit controls ghi và cho phép kiểm tra hoạt động trên hệ thống chứa ePHI (§164.312(b)); log nên cho biết ai truy cập dữ liệu nào, khi nào, từ đâu và làm gì. Quy định không ấn định thời gian lưu log; 6 năm trong §164.316(b)(2) áp dụng cho chính sách, quy trình và hồ sơ
• [ ] Cơ chế phát hiện ePHI bị sửa hoặc hủy trái phép (Addressable, §164.312(c)(2))
• [ ] Xác thực người hoặc hệ thống trước khi truy cập ePHI (§164.312(d)); MFA là cách làm phổ biến, quy định hiện hành không nêu tên MFA
• [ ] Mã hóa ePHI khi truyền và kiểm soát toàn vẹn khi truyền (Addressable, §164.312(e)(2)); TLS 1.2 trở lên theo NIST SP 800-52 là mức thường được chấp nhận
• [ ] Review quyền truy cập định kỳ; lưu khóa mã hóa tách khỏi dữ liệu (Thực hành)

Môi trường dev, staging và cloud cần lưu ý gì?

Security Rule áp dụng cho mọi hệ thống tạo, nhận, lưu giữ hoặc truyền ePHI, nên staging hay máy developer có dữ liệu thật cũng thuộc phạm vi. Dùng cloud đủ điều kiện HIPAA không có nghĩa là đã tuân thủ: theo mô hình trách nhiệm chung của AWS, nhà cung cấp lo hạ tầng, còn cấu hình, ứng dụng, quyền truy cập, chính sách và training vẫn là việc của bạn, và bạn phải ký BAA với nhà cung cấp (AWS HIPAA).

• [ ] Không dùng PHI thật trong dev và staging; dùng dữ liệu tổng hợp (synthetic) hoặc đã de-identify (Thực hành, giữ các môi trường này ngoài phạm vi)
• [ ] Không hardcode credential; dùng secrets manager hoặc KMS (Thực hành)
• [ ] Không để ePHI trong URL, log ứng dụng và thông báo lỗi trả về người dùng (Thực hành, hỗ trợ §164.312(b) và (c))
• [ ] Hệ thống chứa ePHI nằm trong mạng riêng, security group mặc định từ chối (Thực hành)
• [ ] Quét SAST/DAST trong CI/CD trước khi deploy (Thực hành)

Quy trình breach notification cần có gì?

Business associate phải báo covered entity khi phát hiện breach PHI chưa được bảo vệ, không chậm trễ vô lý và chậm nhất 60 ngày lịch kể từ khi phát hiện (§164.410); BAA có thể đặt thời hạn ngắn hơn.

• [ ] Kế hoạch ứng phó sự cố bằng văn bản cho ePHI
• [ ] Nhân viên biết báo sự cố cho ai và bằng kênh nào
• [ ] Quy trình đánh giá rủi ro bốn yếu tố để xác định sự cố có phải breach (§164.402)
• [ ] Thời hạn báo cho khách hàng ghi đúng như BAA đã ký
• [ ] Hồ sơ mọi sự cố, kể cả khi kết luận không phải breach

Vendor và dịch vụ cloud cần kiểm tra gì?

Mọi dịch vụ tạo, nhận, lưu giữ hoặc truyền ePHI thay bạn là subcontractor và cần BAA.

• [ ] Danh sách mọi dịch vụ có thể chạm tới ePHI: cloud, email, ticketing, logging, analytics, AI tool
• [ ] BAA đã ký với từng dịch vụ đó, đúng gói và đúng sản phẩm được phủ
• [ ] Công cụ chưa có BAA được cấu hình và quy định để không nhận ePHI
• [ ] Rà lại danh sách mỗi khi thêm dịch vụ mới
• [ ] Rà lại chính sách và quy trình định kỳ và cập nhật khi môi trường hoặc quy định thay đổi (§164.316(b)(2)(iii))

Nên bắt đầu từ đâu và mất bao lâu?

Bắt đầu với BAA và risk analysis, vì hai mục này quyết định phạm vi mọi việc còn lại và là câu khách hàng hỏi đầu tiên trong vendor qualification. Sau đó ưu tiên các technical safeguard required và các gap risk analysis đánh giá rủi ro cao. Thời gian phụ thuộc phạm vi hệ thống và những gì đã có sẵn, nên không có con số chung; bài HIPAA compliance mất bao lâu giải thích cách ước tính theo từng giai đoạn.

pTrackly hỗ trợ checklist này thế nào?

pTrackly giúp bạn quản lý checklist như một chương trình đang vận hành. Framework HIPAA trong pTrackly có compliance matrix map từng yêu cầu Security Rule sang control, và cho phép ghi lý do cùng biện pháp thay thế cho mỗi addressable specification chưa triển khai nguyên văn. Evidence task có tần suất và nhắc nhở trước hạn; access review lấy danh sách tài khoản và lưu kết quả làm evidence; module Vendors ghi trạng thái BAA và nhắc trước khi hết hạn; module Privacy ghi sự cố và tính hạn thông báo theo HIPAA Breach Notification Rule. Việc cấu hình hệ thống, quyết định addressable và ký BAA vẫn do team bạn thực hiện.

Xem thêm HIPAA là gì, HIPAA cho HealthTech Việt Nam, những chỗ policy tự viết hay thiếu và HIPAA với pTrackly.

Câu hỏi thường gặp

HIPAA có bắt buộc MFA không?

Security Rule hiện hành yêu cầu xác thực người hoặc hệ thống truy cập ePHI (45 CFR §164.312(d)) nhưng không nêu tên MFA. MFA là cách phổ biến để đáp ứng yêu cầu này và thường được khách hàng hỏi.

Addressable có nghĩa là không bắt buộc không?

Không. Addressable nghĩa là phải đánh giá; nếu không triển khai nguyên văn, bạn phải ghi lý do và áp dụng biện pháp thay thế hợp lý theo 45 CFR §164.306(d).

Business associate phải báo breach cho khách hàng trong bao lâu?

Không chậm trễ vô lý và chậm nhất 60 ngày kể từ khi phát hiện theo 45 CFR §164.410. Nhiều BAA đặt thời hạn ngắn hơn, và thời hạn trong BAA là thời hạn bạn phải tuân theo.

Dùng AWS, Google Cloud hay Azure có nghĩa là đã tuân thủ HIPAA không?

Không. Các nhà cung cấp này có dịch vụ đủ điều kiện và ký BAA, nhưng theo mô hình trách nhiệm chung, bạn vẫn chịu trách nhiệm cấu hình, ứng dụng, quyền truy cập, chính sách và training, và phải tự ký BAA với nhà cung cấp.

Hồ sơ HIPAA phải lưu bao lâu?

Chính sách, quy trình và hồ sơ hành động, đánh giá phải lưu 6 năm kể từ ngày tạo hoặc ngày cuối còn hiệu lực theo 45 CFR §164.316(b)(2).

Tài liệu tham khảo: 45 CFR Part 164 Subpart C (Cornell LII) · HHS: Security Rule · HHS: Breach Notification Rule