De Novo Orthopedics
為什麼我們把診前問卷格式開源 — 從利害關係人推演到 26 條律師意見
Blog/
||||||

為什麼我們把診前問卷格式開源 — 從利害關係人推演到 26 條律師意見

iRehab Brief Schema v0.1 今天公開了。寫的是「醫師設計診前症狀問卷的格式標準」 — 不是產品、不是平台、不是醫療器材，只是一份結構化的格式藍圖。這篇紀錄從利害關係人（stakeholder）推演開始，怎麼一路推到「格式可以開源、邏輯永遠封閉」這個結論，雙授權怎麼選、台灣法準據法為什麼這樣寫、26 條律師預擬意見書全綠燈代表什麼，最後給醫師一個直接的工作流：把這個 GitHub 連結丟給自己的 AI 助手，請它幫你設計自己科別的問卷。

open-sourceirehabbrief-schemamedical-softwareopen-standarddenovortho

從一個尷尬的觀察開始

老實說，目前在做「結構化診前症狀問卷」這個功能（feature）的，就我們所知，iRehab 是少數先行者 — 我們找不到其他做類似事情的台灣同業 / 國際同業。

這代表問題還沒發生嗎？不 — 這代表問題即將發生。

回頭看醫療資訊系統的歷史：每家醫院都自己寫一套醫院資訊系統（HIS），結構各不互通；幾十年下來形成今天無法跨醫院整合、病患資料無法跟隨個人移動的局面。

如果「結構化診前問卷」變成下一個普及的功能 — 而 AI 普及之後它幾乎一定會 — 大概率會重演同樣的歷史：

  • 每家先各做各的（前 3 年）
  • 然後在競爭壓力下開始談標準化（5-7 年）
  • 但那時各家內部格式已寫死、整合債堆疊、翻新代價極高

我們在思考 iRehab 下一階段該怎麼走時做了一輪利害關係人（stakeholder）推演 — 把所有未來可能跟「診前問卷」發生關係的角色列出來：醫院資訊系統廠商、第三方掛號平台、學會、外部專科醫師、學術引用者、醫材 / 商業險夥伴⋯⋯

每群人未來對問卷格式都會有自己的需求；但這些合作路徑在「專屬封閉（proprietary）」起步下，會像今天的醫院系統整合一樣 — 我們得一家家簽合約、客製對接，10 倍成本而且仍常失敗。

所以 — 與其等大家各做各的、5-7 年後才痛苦地談標準化，不如現在先丟一份格式藍圖出來，作為討論起點。

這份藍圖不一定會被採納成最終標準。但它至少把「該長什麼樣」這個討論搬到桌上。

一個思考框架：分發器 vs 引擎

把 Brief 這個功能拆開看，技術上有兩層。

「格式」這層就是 JSON 格式定義、欄位名稱、紅旗判斷的觸發點 — 技術上沒什麼了不起，任何看過 FHIR Questionnaire（國際醫療資料交換標準裡的問卷模組）的人都做得出來。

「邏輯」那層才是 De Novo 真正的東西：紅旗判斷流程怎麼判（觸發門檻、權重、警示文案）、AI 整理 SOAP 病歷的提示詞怎麼調、醫師覆寫 AI 建議的紀錄庫怎麼累積、編輯器（Composer）怎麼設計醫師體驗。

這兩層長期被綁在一起賣，因為軟體即服務（SaaS）廠商的本能就是「全包」。但全包的代價是：每一個醫院資訊系統廠商想原生支援都要簽授權、付錢、過法務 — 阻力（friction）太高，沒人會主動做。

把這兩層分開的瞬間，策略就清晰了：

格式可以開源，邏輯永遠封閉。

格式是分發器，邏輯是引擎。引擎留封閉守護，分發器可以免費。

開源後解鎖了什麼

格式公開之後，下面這些事情變成「結構性可能」 — 不是「比較順」，是專屬封閉下根本不會發生的：

  • 醫院資訊系統廠商可以直接讀格式做原生整合，沒有保密協議（NDA）、沒授權金、沒法務審查
  • 第三方平台可以做格式互通互讀（reciprocity） — 這件事在專屬封閉下不可能
  • 外部醫師可以透過提交修改（pull request / PR）貢獻自己科別的模板（specialty pack）（婦泌、神內、身心、復健…），這條貢獻通道在閉源世界根本不存在
  • 學術論文可以引用本格式作為可被學術引用的標準（citable standard）

要 De Novo 一家家業務開發（business development / BD）推到位，成本是 10 倍而且還可能失敗。開源後變「自然發生」。

什麼永遠不會開源

但要明確切一條線 — 沒這條線，「開源核心、商業化加值」（open-core）策略很容易被質疑「你只是還沒開源更多而已」。

下列六項永遠不會進到本程式碼倉庫（已寫在 LICENSE_STRATEGY.md §6）：

  1. 紅旗判斷流程的內部邏輯（觸發門檻、權重、評分算法、組合判斷、警示文案）— 這是醫療判斷邏輯，公開後失去品質把關（quality gate）；同時是 De Novo 真正的護城河
  2. AI 整理 SOAP 病歷的提示詞與調校 — 提示詞工程（prompt engineering）是持續演進的商業智慧財產（IP）
  3. 病患個人識別資料（PII）的處理程式碼 — 個資合規碰不得，任何開源版本變動都會引發合規稽核
  4. iRehab Doctor 漸進式網頁應用（PWA）的介面設計 — 工作流程設計是商業差異化
  5. 成效登錄資料庫（outcome registry）的資料管線 — 企業對企業（B2B）收入流的核心
  6. 編輯器（Composer）的圖形介面 — 醫師體驗的關鍵差異化

更重要的：各家醫院 / 診所 / 服務商對這些東西的需求差異太大。 我們覺得這些不該由 De Novo 一家替整個產業決定。留給各位與自己的 AI 去打造，反而是更健康的設計。

雙授權結構

內容授權
格式定義檔（spec/v0.1/schema/*.json）、驗證程式碼Apache-2.0（含專利授權條款 / patent grant）
規格文件、範例、教學、本說明文件等CC BY 4.0（標示來源即可商用、改編、再散布）

兩個授權不互通 — 引用時依檔案類型適用對應條款。

選這組合有具體理由：Apache-2.0 對醫院系統廠商、第三方平台採用本格式驗證程式時提供強保護（專利授權條款）；CC BY 4.0 是國際通用的開放內容標準，學術論文引用最常見。

為什麼準據法選台灣

授權人是台灣公司（De Novo Orthopedics 谷盺生物科技），商標在台灣已註冊（iRehab 愛復健及圖、DE NOVO ORTHOPEDICS 兩個商標分別涵蓋 Nice 9/10/35/44 + 5/9/10/35/42/44 類），責任、爭議解決都在台灣處理最直接。

宣告寫在程式碼倉庫跟 README 裡，不修改 Apache-2.0 / CC BY 4.0 條文本身（兩者皆禁止本文修改），而是作為授權人的「準據法選擇陳述」（governing law statement）。第一審管轄法院為臺灣臺中地方法院 — 我們公司登記地。

詳見 docs/governing-law.md。

律師預擬意見書 26 條全綠燈

開源前，我們寫了四組律師預擬意見書：

  • A 組：個資法（9 條）
  • B 組：電子病歷與醫療法（6 條）
  • C 組：開源授權與智慧財產（8 條）
  • D 組：個資保護委員會稽查 + 其他（3 條）

委任律師於 2026-05-06 確認結果：26/26 全部確認，0 條修正。

這不代表「沒風險」，代表「現有設計在台灣現行法律下站得住腳」。唯一一個「待補強」項目是 D-1c —《個人資料檔案安全維護計畫》內部稽查備援（backup）文件，不對外、不擋上線。

對醫院系統廠商 / 第三方平台 / 學會的訊號是：這個程式碼倉庫的法律基礎是真的有人看過的，不是丟出來自己嗨。

醫師最直接的用法

如果你是醫師，看到這篇想著「我能拿這個做什麼」 — 最直接的工作流：

把這個 GitHub 連結丟給你自己的 AI 助手 — ChatGPT / Claude / Gemini / Microsoft Copilot 都行 — 請它幫你做以下事情：
  • 為你的科別（婦科、神經科、身心科、家醫、急診、兒科、心臟科…）設計一份 8-10 題的結構化診前問卷
  • 把現有的紙本問卷轉成符合本格式的 JSON 數位格式
  • 規劃如何把這份問卷接進你的診所 / 醫院系統

不需要會工程。 AI 拿到倉庫連結後，會自己讀 spec/v0.1/authoring-spec.md + examples/orthopedics-complete.json + docs/overview.md + docs/for-doctors.md，依照那份藍圖一步步幫你規劃，產出一份能直接用的 JSON 檔。

院內合規環境用本地端大型語言模型（LLM）也行。很多醫院規範臨床資料不能送到院外 AI — 但你「設計問卷格式」這件事不涉及病患資料，格式本身是公開的，AI 拿到的只是一份格式藍圖 + 你的科別需求。所以即使是最嚴格的合規環境，本工作流也適用。可選：Azure OpenAI 醫院租戶（tenant）部署、Ollama 跑在本地伺服器、HIS 廠商提供的內網 LLM。Microsoft 在醫院端最積極推合規部署 — 如果你醫院已經用 Microsoft 365 / Azure，Copilot 多半已透過合規通道接入，問院方資訊室確認即可。

幾個 AI 提示詞範例：

「我是身心科醫師，門診常見焦慮 / 失眠 / 情緒障礙。請根據 https://github.com/Denovortho/open-irehab-brief-schema 這個倉庫的規格，幫我設計一份 8-10 題的結構化診前問卷，輸出符合 brief-template.schema.json 的 JSON。題目要照顧到 PHQ-9 / GAD-7 風格但不要直接抄量表。」

「我這份紙本術前問卷有 12 題（附圖），幫我轉成符合 iRehab Brief Schema v0.1 的 JSON 格式（倉庫: https://github.com/Denovortho/open-irehab-brief-schema）。維持原意但結構化，多語至少中文 + 英文。」

第一次嘗試的成果不會完美，但讓你今天就有起步，而不是等到「有工程師 / 有預算」才開始。

倉庫與釋出版本（Repo + Release）

10 個檔案，規格 + 雙授權 + 台灣準據法 + 律師意見軌跡（trail）。

接下來

  • 參考驗證程式（reference validator）：以 Apache-2.0 釋出，用來檢查跨欄位規則（cross-field rules），目標 v0.2
  • 更多科別範例：歡迎社群（community）透過 PR 貢獻
  • 醫院系統整合模式（HIS integration patterns）文件
  • Webhook 接收端範例實作（webhook receiver reference implementation）
  • v1.0 穩定釋出：目標 2026 Q4，啟動向後相容（forward compatibility）承諾

如果你想為自己科別寫一份共通模板範例，CONTRIBUTING.md 有貢獻流程。

商業整合 / 授權 / 商標問題：service@denovortho.com

為什麼這件事重要

不是因為「開源 = 善」。

是因為醫院資訊系統各做各的歷史不該重演一次。台灣現在跨醫院病歷互通有多痛、整合一個新院所要花多少時間 — 都是 30 年前各家寫各家的代價。如果「結構化診前問卷」這個功能普及後也走同一條老路，等到 2035 年才開始談標準化，又是一個十年的整合債。

也不是因為「開源 = 我們很大方」。

是因為「最早把格式公開的人」這個位置，事後看常常是該領域的標準制定者。HTTP（網頁協定，Tim Berners-Lee 把它開源）、TCP/IP（網際網路骨幹協定，Vint Cerf / Bob Kahn 把它公開）、FHIR（國際醫療資料交換標準，HL7 把它釋出）— 沒有一個是賣斷價最高的勝出，都是先把格式攤開放著的勝出。

我們不一定會佔到那個位置。但我們今天先丟一份提案出來，看會不會被採納成共通起點。

如果你也覺得「結構化診前問卷」這件事該有共通格式，歡迎指教、引用、複製分叉（fork）、提交修改（PR）。也歡迎挑戰我們的設計選擇 — 這份規格的目的本來就是把選擇攤在桌上讓大家辯論。

延伸閱讀

國際技術標準與授權

  • HL7 FHIR Questionnaire — HL7 FHIR R5 Questionnaire Resource. 國際醫療資料交換標準裡的問卷模組，與 iRehab Brief Schema 同類但更通用、更繁複。值得對照看兩者設計取捨的差異。
  • Apache License 2.0 全文 — Apache Software Foundation. 含專利授權條款（patent grant），是本格式程式碼層採用的授權。
  • Creative Commons CC BY 4.0 全文 — Creative Commons. 國際通用的開放內容標準，是本格式文件層採用的授權。

開放標準的歷史先例

De Novo blog 相關文章