Vì sao chúng tôi mở mã nguồn schema triệu chứng tiền khám — Từ bản đồ stakeholder đến 26 kết luận đã được luật sư xác nhận

Bắt đầu từ một quan sát hơi khó xử

Thành thật mà nói, theo những gì chúng tôi tìm hiểu được, hiện rất ít công ty phần mềm lâm sàng đang triển khai tính năng "bộ câu hỏi triệu chứng tiền khám có cấu trúc". iRehab (Đài Loan) là một trong số ít đó. Chúng tôi không tìm thấy nhiều đối thủ — cả ở Đài Loan lẫn quốc tế — đang xây dựng đúng tính năng này.

Điều đó có nghĩa là vấn đề chưa xảy ra? Không — nó có nghĩa là vấn đề sắp xảy ra.

Nhìn lại lịch sử y tế số: mỗi bệnh viện tự xây EHR / HIS riêng, các cấu trúc dữ liệu không liên thông được, và rồi hàng thập kỷ nợ tích hợp xuất hiện. Tại Việt Nam, dù đã có Nghị định 38/2019/NĐ-CP về hồ sơ bệnh án điện tử và Quyết định 2628/2020/QĐ-BYT về số hóa y tế thúc đẩy chuyển đổi số, thực tế tại các bệnh viện vẫn còn nhiều thách thức: hệ thống của bệnh viện tỉnh, bệnh viện tuyến trung ương ở Hà Nội hay TP.HCM, và các phòng khám tư thường vận hành như những "ốc đảo thông tin" độc lập. Bệnh nhân chuyển viện vẫn phải mang sổ giấy hoặc làm lại các xét nghiệm.

Nếu "thu thập triệu chứng tiền khám có cấu trúc" trở thành tính năng phổ biến tiếp theo trong phần mềm lâm sàng — và sự lan tỏa của AI khiến điều đó gần như chắc chắn — chúng ta có thể chứng kiến cùng một mô hình phân mảnh:

Trong 3 năm đầu, mỗi nhà cung cấp xây format riêng
Áp lực cạnh tranh đẩy các cuộc đàm phán chuẩn hóa vào năm thứ 5-7
Nhưng đến lúc đó, schema nội bộ đã đóng cứng, nợ tích hợp đã chồng chất, và chi phí di trú trở nên quá cao

Khi chúng tôi đối chiếu lộ trình này với những stakeholder thực sự sẽ quan tâm — nhà cung cấp HIS, nền tảng đặt lịch của bên thứ ba, hội chuyên khoa, các bác sĩ chuyên khoa cá nhân, người trích dẫn học thuật, đối tác thiết bị y tế / bảo hiểm tư nhân — chúng tôi thấy một mô hình. Mỗi nhóm rồi sẽ cần một format. Nhưng dưới chế độ độc quyền (proprietary), mỗi con đường hợp tác đều có ma sát cao, chậm và tốn kém — cho cả hai phía.

Một nhà cung cấp duy nhất sẽ cần gấp 10 lần nguồn lực để làm việc này thông qua phát triển kinh doanh (BD) song phương, và vẫn có nhiều khả năng thất bại.

Vậy nên — thay vì chờ mọi người tự phát minh lại rồi đàm phán, chúng tôi đặt một format tham chiếu lên bàn ngay bây giờ, làm điểm khởi đầu cho cuộc trò chuyện đó.

Bản thiết kế này có thể không trở thành chuẩn cuối cùng. Nhưng ít nhất nó đưa cuộc thảo luận lên đúng vị trí cần thảo luận.

Một khung tư duy: bộ phân phối vs động cơ

Nếu mổ xẻ tính năng Brief, có hai lớp.

Lớp "định dạng" là JSON schema, định nghĩa các trường, và các điểm kích hoạt cho red-flag modules — về mặt kỹ thuật không có gì đặc biệt. Bất kỳ ai đã đọc đặc tả FHIR Questionnaire đều có thể tái tạo lớp này trong một ngày cuối tuần.

Lớp "logic" là nơi công việc thực sự diễn ra: red-flag pipeline đánh giá thế nào (ngưỡng / trọng số / câu chữ leo thang), tích hợp AI SOAP được prompt và tinh chỉnh ra sao, kho dữ liệu override của bác sĩ tích lũy thế nào, Composer editor thiết kế trải nghiệm tác giả cho bác sĩ ra sao.

Hai lớp này từ trước đến nay luôn được bán gộp, vì bản năng SaaS là "bán mọi thứ". Nhưng bán gộp có cái giá: bất kỳ nhà cung cấp HIS nào muốn hỗ trợ format của bạn theo cách nguyên bản đều phải ký giấy phép, trả phí bản quyền, qua duyệt pháp lý. Ma sát quá cao; không ai động vào.

Vào khoảnh khắc bạn tách hai lớp ra, chiến lược trở nên rõ ràng:

Định dạng có thể mở. Logic luôn luôn đóng kín.

Định dạng là bộ phân phối. Logic là động cơ. Giữ động cơ đóng để bảo vệ con hào thương mại; thả định dạng miễn phí để khuếch đại sự áp dụng.

Mở mã nguồn mở khóa điều gì

Khi format được công khai, các sự kiện sau trở nên có thể về mặt cấu trúc — không chỉ "trơn tru hơn", mà là điều gần như không xảy ra dưới điều kiện độc quyền:

Nhà cung cấp HIS có thể đọc schema và tích hợp nguyên bản — không NDA, không phí bản quyền, không xét duyệt pháp lý dài hạn
Nền tảng bên thứ ba có thể triển khai tương hỗ định dạng (format reciprocity) — "câu hỏi của bạn và của tôi đọc bằng cùng một parser" là điều không thể trong hệ đóng
Bác sĩ bên ngoài có thể đóng góp specialty pack qua pull request (sản phụ khoa, thần kinh, tâm thần, phục hồi chức năng…) — kênh đóng góp không tồn tại trong code đóng
Bài báo học thuật có thể trích dẫn schema này như một tiêu chuẩn có thể trích dẫn (citable standard)

Mỗi việc trên đều tốn gấp 10 lần nếu làm qua phát triển kinh doanh song phương, với tỷ lệ thất bại cao. Mở mã nguồn biến "chúng tôi phải đẩy" thành "họ có thể đến".

Điều gì sẽ luôn đóng kín — vĩnh viễn

Ranh giới phải rõ ràng. Không có nó, chiến lược open-core dễ bị tấn công với lập luận "các bạn chỉ là chưa mở đủ thôi".

Sáu thành phần sau sẽ không bao giờ vào repository này (đã ghi trong LICENSE_STRATEGY.md §6):

Logic nội bộ của red-flag pipeline (ngưỡng, trọng số, thuật toán chấm điểm, quy tắc tổ hợp đa câu hỏi, câu chữ leo thang) — đây là logic ra quyết định y tế; mở ra thì mất cổng kiểm soát chất lượng, đồng thời đây cũng là con hào thực sự của chúng tôi
Prompt và tinh chỉnh tích hợp AI SOAP — kỹ thuật prompt là tài sản trí tuệ thương mại liên tục tiến hóa
Code xử lý PII của bệnh nhân — tuân thủ quyền riêng tư không phải thứ chạm vào nhẹ nhàng được; mọi sửa đổi mã nguồn mở đều kích hoạt audit tuân thủ
UI / UX của iRehab Doctor PWA — thiết kế quy trình làm việc là sự khác biệt thương mại
Pipeline dữ liệu outcome registry — cốt lõi của dòng doanh thu B2B
Composer (editor GUI để tạo schema) — sự khác biệt then chốt trong trải nghiệm bác sĩ

Quan trọng hơn nữa: nhu cầu của mỗi phòng khám, bệnh viện, nhà cung cấp dịch vụ ở các khu vực này quá khác biệt. Chúng tôi không nghĩ những quyết định này nên tập trung ở một nhà cung cấp duy nhất. Để mỗi tổ chức và AI của họ tự xây mới là thiết kế lành mạnh hơn.

Cấu trúc giấy phép kép

Nội dung	Giấy phép
File schema (`spec/v0.1/schema/*.json`), code validator	Apache-2.0 (kèm điều khoản cấp quyền sáng chế / patent grant)
Tài liệu spec, ví dụ, hướng dẫn, README	CC BY 4.0 (cho phép sử dụng thương mại / chỉnh sửa / phân phối lại với ghi nguồn)

Hai giấy phép này không thể hoán đổi — khi trích dẫn, áp dụng đúng giấy phép theo loại file.

Sự kết hợp này có chủ đích: điều khoản cấp quyền sáng chế rõ ràng của Apache-2.0 cung cấp sự bảo vệ mạnh mẽ cho các nhà cung cấp HIS và nền tảng bên thứ ba khi áp dụng schema validator. CC BY 4.0 là chuẩn quốc tế cho cấp phép nội dung mở và quen thuộc nhất với người trích dẫn học thuật.

Vì sao luật áp dụng là Republic of China (Đài Loan)

Bên cấp phép là một công ty Đài Loan (De Novo Orthopedics 谷盺生物科技股份有限公司). Thương hiệu được đăng ký tại Đài Loan ("iRehab 愛復健 with logo" bao phủ Nice classes 9/10/35/44; "DE NOVO ORTHOPEDICS / 谷盺生物科技" bao phủ 5/9/10/35/42/44). Trách nhiệm và giải quyết tranh chấp đi qua Đài Loan là trực tiếp nhất.

Khai báo này nằm trong repository và README. Nó không sửa đổi văn bản giấy phép Apache-2.0 / CC BY 4.0 chính nó (cả hai cấm sửa văn bản). Thay vào đó, nó hoạt động như "tuyên bố luật áp dụng (governing law statement)" của bên cấp phép — một khai báo riêng đi kèm, nhưng không thay đổi, văn bản giấy phép gốc. Tòa sơ thẩm: Taichung District Court, nơi De Novo Orthopedics đăng ký.

Xem docs/governing-law.md để biết tuyên bố đầy đủ.

26 kết luận pre-draft đã được luật sư xác nhận

Trước khi công bố, chúng tôi soạn thảo bốn nhóm ý kiến pháp lý pre-draft:

Nhóm A: Luật bảo vệ dữ liệu cá nhân (9 kết luận)
Nhóm B: Hồ sơ y tế điện tử và Luật chăm sóc y tế (6 kết luận)
Nhóm C: Cấp phép mã nguồn mở và sở hữu trí tuệ (8 kết luận)
Nhóm D: Audit của Ủy ban bảo vệ dữ liệu cá nhân và các vấn đề khác (3 kết luận)

Luật sư đại diện của chúng tôi đã xác nhận vào 2026-05-06: 26/26 kết luận được xác nhận, 0 chỉnh sửa yêu cầu.

Điều này không có nghĩa là "không rủi ro" — nó có nghĩa là "thiết kế hiện tại đứng vững dưới khung pháp lý hiện hành của Đài Loan". Mục duy nhất "cần bổ sung" là D-1c, một Personal Data File Security Maintenance Plan văn bản, một tài liệu sao lưu audit nội bộ. Không công khai, không cản trở phát hành.

Tín hiệu cho nhà cung cấp HIS / nền tảng bên thứ ba / hội chuyên khoa: nền tảng pháp lý của repository này thực sự đã được luật sư xem xét — không chỉ được công bố vì nhiệt huyết.

Workflow trực tiếp nhất cho bác sĩ

Nếu bạn là bác sĩ và đang đọc bài này với câu hỏi "tôi có thể thực sự làm gì với cái này" — đây là workflow trực tiếp nhất:

Đưa URL GitHub này cho trợ lý AI của bạn — ChatGPT / Claude / Gemini / Microsoft Copilot — và yêu cầu nó làm các việc sau:

Thiết kế một brief tiền khám có cấu trúc 8-10 câu hỏi cho chuyên khoa của bạn (sản phụ khoa, thần kinh, tâm thần, gia đình, cấp cứu, nhi, tim mạch…)
Chuyển bộ câu hỏi giấy hiện có thành JSON brief tương thích với schema này
Lập kế hoạch tích hợp brief vào hệ thống phòng khám / bệnh viện của bạn

Không cần kỹ năng kỹ thuật. Khi AI có URL repository, nó sẽ tự đọc spec/v0.1/authoring-spec.md, examples/orthopedics-complete.json, docs/overview.md, và docs/for-doctors.md, sau đó hướng dẫn bạn từng bước trong thiết kế — tạo ra một file JSON bạn có thể dùng trực tiếp.

Môi trường tuân thủ dùng LLM cục bộ cũng được. Nhiều bệnh viện cấm gửi nội dung lâm sàng đến dịch vụ AI bên ngoài. Tại Việt Nam, các bệnh viện công và tư thường có quy định nội bộ chặt chẽ về bảo mật dữ liệu bệnh nhân. Nhưng "thiết kế format câu hỏi" không liên quan đến dữ liệu bệnh nhân — schema bản thân nó là công khai, và AI nhận được chỉ là một bản thiết kế format cộng với yêu cầu chuyên khoa của bạn. Workflow vẫn tương thích ngay cả trong môi trường nghiêm ngặt nhất. Tùy chọn: Azure OpenAI trên tenant bệnh viện, Ollama chạy trên server cục bộ, hoặc LLM nội mạng do nhà cung cấp HIS cung cấp. Microsoft có chiến lược triển khai tuân thủ phía bệnh viện tích cực nhất — nếu cơ sở của bạn đã dùng Microsoft 365 / Azure, Copilot có thể đã được kết nối qua kênh tuân thủ; xác nhận với phòng IT.

Một số ví dụ prompt:

"Tôi là bác sĩ tâm thần; ca ngoại trú của tôi chủ yếu là lo âu / mất ngủ / rối loạn cảm xúc. Dùng spec tại https://github.com/Denovortho/open-irehab-brief-schema, thiết kế một brief tiền khám có cấu trúc 8-10 câu hỏi tạo ra JSON hợp lệ theo brief-template.schema.json. Bao quát PHQ-9 / GAD-7 về tinh thần nhưng không sao chép nguyên các thang đo đó."

"Tôi có một bộ câu hỏi tiền phẫu giấy 12 câu (đính kèm hình). Chuyển nó thành JSON iRehab Brief Schema v0.1 (repo: https://github.com/Denovortho/open-irehab-brief-schema). Giữ nguyên ý gốc, cấu trúc hóa nơi nào có thể, đảm bảo i18n ít nhất zh-TW + en."

Lần thử đầu sẽ không hoàn hảo, nhưng nó cho phép bạn bắt đầu hôm nay — thay vì chờ "kỹ sư / ngân sách / chu kỳ IT".

Repo + Releases

Repository: github.com/Denovortho/open-irehab-brief-schema
v0.1.0 release (chỉ spec): releases/tag/v0.1.0
v0.1.1 release (kèm JSON Schema + 2 ví dụ + overview): releases/tag/v0.1.1

Mười file: spec + giấy phép kép + luật áp dụng Đài Loan + bằng chứng ý kiến luật sư.

Reference validator (Apache-2.0): mục tiêu v0.2, thực thi cross-field rules
Thêm specialty examples: hoan nghênh đóng góp cộng đồng qua PR
Tài liệu HIS integration patterns
Webhook receiver reference implementation
v1.0 stable release: mục tiêu Q4 2026, kích hoạt cam kết tương thích về sau (forward compatibility)

Nếu bạn muốn đóng góp specialty pack cho lĩnh vực của bạn, xem CONTRIBUTING.md để biết quy trình.

Tích hợp thương mại / cấp phép / câu hỏi về thương hiệu: service@denovortho.com

Vì sao điều này quan trọng

Không phải vì "mã nguồn mở = tốt".

Quan trọng vì lịch sử mỗi bệnh viện tự xây HIS riêng — và hàng thập kỷ nợ tích hợp theo sau — không nên lặp lại. Đối với Việt Nam, vấn đề liên thông dữ liệu giữa bệnh viện tỉnh và bệnh viện tuyến trung ương vẫn còn hạn chế; bệnh nhân chuyển viện vẫn phải mang sổ giấy hoặc lặp lại các xét nghiệm. Đó là cái giá của việc để sự phân mảnh ban đầu phát triển không kiểm soát. Nếu "thu thập triệu chứng tiền khám có cấu trúc" đi cùng con đường, năm 2035 chúng ta sẽ có cuộc trò chuyện chuẩn hóa lẽ ra cần có hôm nay, kèm thêm một thập kỷ nợ tích lũy.

Và không phải vì "mã nguồn mở = hào phóng".

Quan trọng vì "thực thể đặt format lên bàn trước" thường, khi nhìn lại, trở thành người đặt chuẩn cho lĩnh vực đó. HTTP — Tim Berners-Lee đã công bố nó —, TCP/IP — Vint Cerf và Bob Kahn đã xuất bản nó —, FHIR — HL7 đã phát hành nó — không có ai thắng nhờ giá bán cao nhất. Họ thắng nhờ để format hiển thị công khai từ đầu.

Chúng tôi có thể không kết thúc ở vị trí đó. Nhưng hôm nay chúng tôi đặt một đề xuất lên bàn để xem nó có thể trở thành điểm khởi đầu chung hay không.

Nếu bạn cũng tin rằng "thu thập triệu chứng tiền khám có cấu trúc" xứng đáng có một định dạng chung, chúng tôi hoan nghênh phê bình, trích dẫn, fork, và pull request. Chúng tôi cũng hoan nghênh thách thức với các lựa chọn thiết kế của chúng tôi — toàn bộ mục đích của spec là đặt các lựa chọn lên bàn để tranh luận.

Đọc thêm

Tiêu chuẩn quốc tế và giấy phép

HL7 FHIR Questionnaire — HL7 FHIR R5 Questionnaire Resource. Cùng miền vấn đề, với phạm vi rộng hơn và độ phức tạp cao hơn. Đáng so sánh các trade-off thiết kế.
Apache License 2.0 toàn văn — Apache Software Foundation. Bao gồm điều khoản cấp quyền sáng chế. Là giấy phép được dùng cho schema và validator code trong repo này.
Creative Commons CC BY 4.0 toàn văn — Creative Commons. Tiêu chuẩn quốc tế cho cấp phép nội dung mở. Được dùng cho tài liệu spec và ví dụ trong repo này.

Tiền lệ lịch sử của các tiêu chuẩn mở

Berners-Lee, T. (1989). Information Management: A Proposal. CERN. — Memo gốc đề xuất Web, sau đó được phát hành không phí bản quyền như một tiêu chuẩn mở.
Cerf, V., & Kahn, R. (1974). A Protocol for Packet Network Intercommunication. IEEE Transactions on Communications. — Bài báo nền tảng TCP/IP làm nên tính tương thích của internet hiện đại.
Mandl, K. D. & Kohane, I. S. (2012). Escaping the EHR Trap — The Future of Health IT. NEJM. — Hai chuyên gia tin học y tế của Harvard về lý do sự phân mảnh lịch sử của EHR có chi phí dài hạn mà chúng ta vẫn đang trả.