Chỉ cần phần mềm của bạn chạm tới tên một bệnh nhân nằm cạnh chẩn đoán của họ, là bạn đang xử lý ePHI — và HIPAA trở thành chuyện của bạn. Rủi ro không hề trừu tượng: một vụ rò rỉ dữ liệu (breach) tốn kém để khắc phục, lâu để hồi phục, và vi phạm HIPAA có thể kéo theo mức phạt dân sự đáng kể. Tệ hơn, bệnh viện hay payer sẽ không ký với bạn nếu bạn không chứng minh được mình xây đúng. Phần lớn các team coi tuân thủ là thứ "để sau làm". Đó là sai lầm. Checklist phần mềm HIPAA này nói về những thứ cần làm đúng trước khi ra mắt, để bạn ship trong tư thế sẵn sàng audit thay vì chạy chữa về sau.
Đây là bài cho founder và CTO đang xây phần mềm y tế, không phải cho compliance officer soạn chính sách. Chúng tôi tập trung vào các quyết định kỹ thuật và kiến trúc — những thứ quyết định sản phẩm của bạn có thực sự "đứng vững" được hay không, và là những thứ đau đớn, tốn kém nếu phải sửa lại sau. Nếu bạn đang tìm đối tác phát triển, đây cũng là danh sách câu hỏi để hỏi họ. Nếu họ không trả lời được từng mục dưới đây, tìm chỗ khác.
Một lưu ý về từ ngữ. "Phần mềm tuân thủ HIPAA" là một chuẩn thật, nhưng "HIPAA compliant" không phải tấm chứng chỉ mua được. Không có con dấu HIPAA chính thức nào cả. Tuân thủ là một trạng thái bạn duy trì xuyên suốt con người, quy trình và công nghệ. Bài này là phần công nghệ và kiến trúc — phần bạn phải tự xây.
Bạn cần giữ hai thứ trong đầu cùng lúc.
Luật hiện hành yêu cầu gì. HIPAA Security Rule hiện chia các yêu cầu triển khai thành "required" (bắt buộc) và "addressable". "Addressable" không có nghĩa là tùy chọn — nó nghĩa là bạn phải đánh giá xem một biện pháp bảo vệ có hợp lý và phù hợp với môi trường của mình không, triển khai nếu có, và ghi lại lý do nếu không. Mã hóa ePHI hiện đang là addressable theo luật hiện hành, chưa bắt buộc tuyệt đối. Nhưng trong thực tế, với gần như mọi app y tế hiện đại, mã hóa là hoàn toàn hợp lý và phù hợp — nên "addressable" đừng bao giờ là cái cớ để bỏ qua.
Luật đang đi về đâu. Tháng 12/2024, Office for Civil Rights của HHS ra Thông báo dự thảo quy định (công bố 6/1/2025) siết Security Rule chặt hơn đáng kể. Nếu được thông qua, nó sẽ bắt buộc mã hóa ePHI cả khi lưu trữ lẫn khi truyền (with limited exceptions), bỏ phân biệt required/addressable (mọi yêu cầu đều thành bắt buộc), và thêm các nghĩa vụ rõ ràng như multi-factor authentication, continuous monitoring, vulnerability scanning, penetration testing, network segmentation, và kiểm thử kiểm soát an ninh hằng năm.
Lưu ý quan trọng: tính tới giữa 2026, đây vẫn là dự thảo. Chưa có luật chính thức, nên chưa phải luật. Nhưng hướng đi thì rõ mười mươi. Lời khuyên của chúng tôi đơn giản: xây theo chuẩn dự thảo nghiêm hơn ngay từ bây giờ. Đó là nơi quy định đang hướng tới, là thứ buyer sành sỏi đã kỳ vọng sẵn, và thành thật mà nói nó chỉ là kỹ thuật tốt thôi. Đập đi lắp lại mã hóa và MFA trên một hệ thống đang chạy xử lý ePHI đau hơn nhiều so với thiết kế cho chúng ngay từ ngày đầu.
Dùng checklist này trước khi ship. Mỗi mục là một thứ mà buyer cẩn thận hoặc auditor sớm muộn cũng sẽ hỏi. Làm đúng sớm thì "tuân thủ theo thiết kế" thôi là khẩu hiệu mà trở thành hình hài thật của hệ thống.
Nếu sản phẩm của bạn dùng AI, chuẩn còn cao hơn, không thấp đi. Một mô hình có thể hallucinate, làm rò rỉ dữ liệu vào prompt, hoặc thực hiện một hành động không ai review. Đó là lý do framework Kite của chúng tôi mặc định coi mô hình là không đáng tin: luật xác định chạy trước, mô hình hoạt động trong guardrail, và luôn có human-in-the-loop cho bất cứ điều gì hệ trọng. Trong bối cảnh HIPAA, đó không phải tính năng "có thì tốt" — đó là cách bạn giữ một thành phần khó lường khỏi trở thành mắt xích yếu nhất. Nếu một vendor cắm thẳng LLM vào dữ liệu bệnh nhân mà không có các ràng buộc này, đó là dấu hiệu đáng ngại.
Chúng tôi xây phần mềm y tế tuân thủ HIPAA để sẵn sàng audit ngay từ ngày đầu, không phải vá víu hướng tới tuân thủ sau khi ra mắt. Nghĩa là checklist ở trên là điểm khởi đầu của một dự án, không phải thứ nghĩ tới sau cùng. Mô hình của chúng tôi loại bỏ những ma sát quen thuộc: giá cố định và thời gian cố định khóa trong SOW nên không có hóa đơn bất ngờ, và bạn sở hữu 100% code, hạ tầng và IP ngay từ ngày đầu. Đội chỉ senior, do founder dẫn dắt, làm trực tiếp — không có rào cản PM giữa bạn và những người ra quyết định kỹ thuật. Triết lý của chúng tôi là thà đáng tin còn hơn gây ấn tượng — mà trong y tế, đó là triết lý duy nhất sống sót được khi đối mặt auditor. Xem chúng tôi làm gì để hiểu đầy đủ cách chúng tôi làm việc.
Phát triển phần mềm HIPAA phần lớn là kỷ luật xây phần 99% không hào nhoáng — kiểm soát truy cập, audit log, backup đã kiểm thử — để 1% thông minh của sản phẩm thực sự sống được trên production.
Tuân thủ không phải một giai đoạn lắp vào phút cuối. Những quyết định định đoạt việc phần mềm của bạn có đứng vững không — mã hóa, kiểm soát truy cập, khả năng audit, thiết kế mạng — đều là chuyện kiến trúc, và đảo ngược chúng rất tốn kém. Hãy dùng checklist này khi bạn còn lựa chọn rẻ. Xây theo chuẩn dự thảo nghiêm hơn ngay bây giờ, ghi tài liệu dọc đường, và bạn sẽ bước vào các vòng review bảo mật của buyer và các cuộc audit với bằng chứng thay vì lời bào chữa.
Nếu bạn đang xây phần mềm y tế và muốn nó sẵn sàng audit ngay từ ngày đầu, đó đúng là việc chúng tôi làm. Đặt lịch tư vấn và chúng ta sẽ đi qua kiến trúc cụ thể của bạn cùng những chỗ rủi ro thật sự nằm ở đâu.