やや気まずい観察から始まります
率直に言えば、現時点で「構造化された診前症状問診票」という機能を実際に提供している臨床ソフトウェア企業は、私たちが確認できる範囲ではまだ多くありません。台湾の iRehab は、その少数の先行例の一つです。台湾国内でも、国際的にも、この機能を真正面から作っている同業例はほとんど見つかりませんでした。
では、まだ問題が顕在化していないということでしょうか。そうではありません。むしろ、この問題はまもなく顕在化すると考えています。
医療 IT の歴史を振り返ると、同じ構図が何度も現れます。各病院が独自に電子カルテ(EMR: Electronic Medical Record)や病院情報システム(HIS: Hospital Information System)を構築し、データ構造が相互運用できず、数十年にわたる統合負債が残りました。日本でもこの課題は非常に身近です。400 を超えるベンダー実装・カスタマイズの組み合わせが存在すると言われ、医療 IT は長らく「ガラパゴス化」してきました。厚生労働省は 2010 年代から標準化 EHR を推進してきましたが、ベンダーロックインと既存運用の重さにより、普及は簡単ではありませんでした。
近年の全国医療情報プラットフォーム構想や、電子処方箋の標準化も、まさに同じ教訓を示しています。標準化は必要です。しかし、各システムが先に固まった後で標準化する場合、そのコストは非常に高くなります。後から接続するより、最初から共通形式を置く方がはるかに安いのです。
もし「構造化された診前問診」が次の一般的な臨床ソフトウェア機能になるなら、そして AI の普及によりその可能性はかなり高いと考えていますが、同じ断片化のパターンが繰り返されるおそれがあります。
- 各ベンダーが最初の 3 年で独自形式を作ります
- 5-7 年後、競争圧力により標準化の議論が始まります
- しかしその時点では、内部スキーマはすでに固定化され、統合負債は積み上がり、移行コストは高くなっています
この将来像を、実際に関係する利害関係者と照らし合わせました。HIS ベンダー、第三者の予約・受付プラットフォーム、臨床学会、各専門領域の医師、学術引用者、医療機器企業、民間保険パートナーなどです。どの関係者も、いずれ何らかの形式を必要とします。しかし、プロプライエタリ(proprietary: 独自・閉鎖型)な仕組みから始めると、すべての連携は高摩擦で、遅く、高価になります。双方にとってそうです。
一社のベンダーが、二者間の事業開発だけでこれを進めようとすれば、10 倍のリソースが必要になり、それでも失敗する可能性が高いでしょう。
だからこそ、全員がそれぞれ再発明し、その後で交渉するのを待つのではなく、まず参照形式を今、テーブルに置くことにしました。
この設計図が最終標準になるとは限りません。しかし、少なくとも議論をテーブルの上に移すことはできます。
フレームワーク:配布層 vs エンジン
Brief 機能を分解すると、二つの層があります。
「形式」層は、JSON スキーマ、フィールド定義、レッドフラグモジュールのトリガーポイントです。技術的には特別なものではありません。FHIR Questionnaire(HL7 FHIR における問診票リソース)の仕様を読んだことがある人であれば、この層は週末で再現できます。
「ロジック」層に、実際の仕事があります。レッドフラグ判定パイプラインがどのように判断するか、閾値、重み付け、エスカレーション文面、AI SOAP 統合のプロンプトと調整、医師による上書きデータの蓄積、Composer エディタが医師の作成体験をどう設計するか、といった部分です。
この二つの層は、歴史的には一体で売られてきました。SaaS の本能は「全部売る」だからです。しかし、一体化にはコストがあります。HIS ベンダーがあなたの形式をネイティブにサポートしたいと思っても、ライセンス契約、ロイヤルティ、法務審査が必要になります。摩擦が高すぎるため、誰も動きません。
二つを分けた瞬間、戦略は明確になります。
形式は開けます。ロジックは永遠に閉じたままです。
形式は配布層です。ロジックはエンジンです。エンジンは閉じたままにして商業的な堀を守り、配布層は無料で公開して採用を増幅させます。
公開によって何が可能になるか
形式が公開されると、次の出来事が構造的に可能になります。単に「少し楽になる」のではありません。プロプライエタリな条件下では、そもそも起きにくかったことです。
- HIS ベンダーはスキーマを読んでネイティブ統合できます。NDA も、ロイヤルティも、法務審査も不要です
- 第三者プラットフォームは形式の相互運用性(format reciprocity)を実装できます。「あなたの問診票も私の問診票も同じパーサーで読める」という状態は、閉じた形式では成立しません
- 外部の医師は専門領域別パックを pull request で貢献できます。産婦人科、神経内科、精神科、リハビリテーションなど、閉じたソースでは存在しない貢献経路です
- 学術論文はこのスキーマを引用可能な標準として引用できます
これらを二者間の事業開発で実現しようとすれば、コストは 10 倍になり、失敗率も高くなります。オープンソース化は、「こちらが押し込む」状態を、「向こうから来られる」状態に変えます。
永遠に閉じたままにするもの
境界は明確にする必要があります。そうしなければ、オープンコア戦略はすぐに「まだ十分に公開していないだけではないか」と批判されます。
以下の 6 つの構成要素は、決してこのリポジトリには入りません。これは LICENSE_STRATEGY.md §6 に明記しています。
- レッドフラグパイプラインの内部ロジック(閾値、重み付け、スコアリングアルゴリズム、複数質問の合成ルール、エスカレーション文面)— これは医療判断ロジックです。公開すれば品質ゲートを失い、同時に私たちの実際の堀も失います
- AI SOAP 統合のプロンプトと調整 — プロンプトエンジニアリングは継続的に進化する商業 IP です
- 患者 PII 取り扱いコード — プライバシーコンプライアンスは軽く扱える領域ではありません。オープンソース改変はすべてコンプライアンス監査の対象になります
- iRehab Doctor PWA の UI / UX — ワークフロー設計は商業差別化です
- Outcome registry データパイプライン — B2B 収益の中核です
- Composer、つまりスキーマ作成用 GUI エディタ — 医師体験の重要な差別化要素です
さらに重要なのは、診療所、病院、サービス提供者ごとに、これらの領域で必要なものが大きく異なるという点です。これらの意思決定を一つのベンダーに集中させるべきではありません。各組織と、その組織の AI が自分たちで構築できる余地を残す方が、健全な設計だと考えています。
デュアルライセンス構造
| Content | License |
|---|---|
Schema files (spec/v0.1/schema/*.json), validator code | Apache-2.0(特許許諾条項を含みます) |
| Spec documents, examples, tutorials, README | CC BY 4.0(出典表示により、商用利用・改変・再配布が可能です) |
この二つのライセンスは相互に置き換えられるものではありません。引用や利用の際は、ファイル種別に応じて正しいライセンスを適用してください。
この組み合わせは意図的です。Apache-2.0 の明示的な特許許諾条項は、スキーマバリデータを採用する HIS ベンダーや第三者プラットフォームに強い保護を提供します。CC BY 4.0 はオープンコンテンツライセンスとして国際的に広く使われており、学術引用にもなじみがあります。
なぜ準拠法を Republic of China (Taiwan) としたのか
ライセンサーは台湾法人である De Novo Orthopedics(谷盺生物科技股份有限公司)です。商標は台湾で登録されています。「iRehab 愛復健 with logo」は Nice 分類 9/10/35/44 を、「DE NOVO ORTHOPEDICS / 谷盺生物科技」は 5/9/10/35/42/44 をカバーしています。責任と紛争解決は、台湾を通すのが最も直接的です。
この宣言はリポジトリと README に記載されています。これはApache-2.0 / CC BY 4.0 のライセンス本文そのものを変更するものではありません。両ライセンスは本文の変更を禁じています。したがって、これはライセンサーによる「準拠法声明」であり、基礎となるライセンス本文に付随する別個の宣言です。第一審管轄裁判所は、De Novo Orthopedics の登記地である Taichung District Court です。
全文は docs/governing-law.md を参照してください。
弁護士確認済みの 26 の事前結論
公開前に、私たちは 4 つのグループの事前法務意見を作成しました。
- Group A: 個人情報保護法関連(9 結論)
- Group B: 電子医療記録および医療法関連(6 結論)
- Group C: オープンソースライセンスと知的財産関連(8 結論)
- Group D: 個人資料保護委員会監査およびその他(3 結論)
委任弁護士は 2026-05-06 に、26/26 の結論を確認し、修正は 0 件であると確認しました。
これは「リスクがない」という意味ではありません。「現在の設計は台湾の現行法制の下で成立している」という意味です。唯一の「補足予定」項目は D-1c、内部監査用バックアップ文書である Personal Data File Security Maintenance Plan です。これは公開対象ではなく、リリースの阻害要因でもありません。
HIS ベンダー、第三者プラットフォーム、臨床学会へのシグナルは明確です。このリポジトリの法的基盤は、単なる熱意による公開ではなく、実際に専門家レビューを受けています。
臨床医にとって最も直接的な使い方
医師としてこの記事を読み、「実際に何ができるのか」と考えている場合、最も直接的なワークフローは次の通りです。
この GitHub URL を、あなたの AI アシスタント — ChatGPT / Claude / Gemini / Microsoft Copilot — に渡し、以下を依頼してください。- 自分の専門領域向けに、8-10 問の構造化診前 Brief を設計すること(産婦人科、神経内科、精神科、家庭医療、救急、小児科、循環器内科など)
- 既存の紙の問診票を、このスキーマに準拠した JSON Brief に変換すること
- その Brief を診療所または病院システムにどう統合するかを計画すること
エンジニアリングは不要です。 AI がリポジトリ URL を受け取れば、spec/v0.1/authoring-spec.md、examples/orthopedics-complete.json、docs/overview.md、docs/for-doctors.md を自分で読み、段階的に設計を支援し、直接使える JSON ファイルを生成できます。
コンプライアンス環境ではローカル LLM を使えます。 多くの病院では、臨床内容を外部 AI サービスに送信することが禁じられています。日本でも、医療情報システムのガイドラインや院内規程により、外部クラウド利用には慎重な審査が必要です。しかし「問診票の形式を設計する」作業には患者データは含まれません。スキーマ自体は公開情報であり、AI に渡すのは形式の設計図と専門領域上の要件です。厳格な環境でも成立します。選択肢としては、病院テナント上の Azure OpenAI、院内サーバー上の Ollama、HIS ベンダーが提供する院内 LLM などがあります。Microsoft は病院側の準拠展開に積極的です。すでに Microsoft 365 / Azure を利用している施設では、Copilot がコンプライアンス経路に接続されている可能性があります。情報システム部門に確認してください。
プロンプト例をいくつか示します。
"I'm a psychiatrist; my outpatient cases are predominantly anxiety / insomnia / mood disorders. Using the spec at https://github.com/Denovortho/open-irehab-brief-schema, design a structured 8-10 question pre-consult brief that outputs valid JSON conforming to brief-template.schema.json. Cover PHQ-9 / GAD-7 territory in spirit, but do not directly transcribe those instruments."
"I have a 12-question paper pre-op questionnaire (attached as image). Convert it into iRehab Brief Schema v0.1 JSON (repo: https://github.com/Denovortho/open-irehab-brief-schema). Preserve the original intent, structure where possible, ensure i18n with at least zh-TW + en."
最初の試行は完璧ではないでしょう。しかし、今日から始められます。「エンジニアが必要」「予算が必要」「IT サイクルを待つ必要がある」という状態から、一歩前に進めます。
Repo + Releases
- Repository:
github.com/Denovortho/open-irehab-brief-schema - v0.1.0 release(spec only):
releases/tag/v0.1.0 - v0.1.1 release(with JSON Schema + 2 examples + overview):
releases/tag/v0.1.1
10 個のファイルで構成されています。仕様、デュアルライセンス、台湾準拠法、弁護士意見のトレイルです。
次に行うこと
- Reference validator(Apache-2.0): v0.2 を目標とし、クロスフィールドルールを検証します
- より多くの専門領域別の例: コミュニティによる PR 貢献を歓迎します
- HIS integration patterns ドキュメント
- Webhook receiver reference implementation
- v1.0 stable release: 2026 Q4 を目標とし、前方互換性のコミットメントを有効化します
自分の専門領域の specialty pack を貢献したい場合は、手順について CONTRIBUTING.md を参照してください。
商業統合、ライセンス、商標に関するお問い合わせ: service@denovortho.com
なぜこれが重要なのか
「オープンソースは良いことだから」ではありません。
重要なのは、各病院が独自の HIS を作り、その後に数十年の統合負債を残した歴史を、繰り返すべきではないからです。日本の医療 IT も、まさにこの課題と向き合ってきました。電子カルテのベンダーごとの差異、部門システム間の分断、院内カスタマイズの蓄積、紹介状や検査結果の連携負担、ベンダー切り替え時の横断コスト。これらはすべて、初期段階で共通形式を十分に置けなかったことの代償です。
全国医療情報プラットフォームや電子処方箋の標準化は、必要な前進です。しかし同時に、遅れて標準化することの高コストも示しています。処方箋のように社会的に重要なデータでさえ、後から統一するには制度、ベンダー、現場運用、既存システムの調整が必要になります。構造化された診前問診が同じ道を進めば、2035 年には、今すべき標準化の議論を、さらに 10 年分の統合負債とともに行うことになるでしょう。
また、「オープンソースは寛大だから」でもありません。
重要なのは、「最初に形式をテーブルに置いた主体」が、後から振り返るとその領域の標準設定者になっていることが多いからです。HTTP(Tim Berners-Lee が無償で公開しました)、TCP/IP(Vint Cerf と Bob Kahn が公開しました)、FHIR(HL7 が公開しました)は、最大販売価格によって勝ったわけではありません。形式を先に公に見える場所へ置いたことで勝ちました。
私たちがその位置に立てるとは限りません。しかし、今日、共通の出発点になり得る提案をテーブルに置きます。
「構造化された診前問診」には共通形式が必要だと考える方からの批評、引用、fork、pull request を歓迎します。設計選択への異議も歓迎します。この仕様の目的は、選択肢をテーブルに置き、議論できるようにすることだからです。
参考資料
国際標準とライセンス
- HL7 FHIR Questionnaire — HL7 FHIR R5 Questionnaire Resource. 同じ問題領域を扱いますが、より広い範囲と複雑性を持ちます。設計上のトレードオフを比較する価値があります。
- Apache License 2.0 全文 — Apache Software Foundation. 特許許諾条項を含みます。このリポジトリではスキーマおよびバリデータコードに使用しています。
- Creative Commons CC BY 4.0 全文 — Creative Commons. オープンコンテンツライセンスの国際標準です。このリポジトリでは仕様文書と例に使用しています。
オープン標準の歴史的先例
- Berners-Lee, T. (1989). Information Management: A Proposal. CERN. — Web を提案した原文メモです。後にロイヤルティなしのオープン標準として公開されました。
- Cerf, V., & Kahn, R. (1974). A Protocol for Packet Network Intercommunication. IEEE Transactions on Communications. — 現代インターネットの相互運用性を可能にした TCP/IP の基礎論文です。
- Mandl, K. D. & Kohane, I. S. (2012). Escaping the EHR Trap — The Future of Health IT. NEJM. — ハーバードの医療情報学者による論考です。EHR の歴史的断片化が、今なお支払っている長期的コストを生んだ理由を論じています。
De Novo blog の関連投稿
- Design Thinking in the AI Age: From Bottleneck to Multiplier — このスキーマ設計図の背後にある Composer エディタ、つまり作成用 GUI が、単一専門領域の pilot から横断的な専門領域ツールへ pivot した経緯を説明しています。
- When AI Brings Software Cost to Zero — Implantable Sensors, Thick Software, and Where the Real Moat Lives — 「配布層 vs エンジン」と隣接する議論です。どの層がコモディティ化し、どの層がしないのか、そして各層をどう価格設定するのかを扱います。
- Compress the Visit, Don't Integrate the Form: The Design Logic of iRehab Doctor AI — Brief における AI SOAP 統合の責任連鎖設計を説明しています。AI が翻訳し、医師が確認し、責任を混ぜないという考え方です。この層が §6 の永遠に閉じる境界に入る理由も示しています。
- 30-Second Daily Check-in — Designing Rehab Software for 80-Year-Olds — 別の「構造化された臨床入力」の問題を扱います。診前入力ではなく、継続的なリハビリ追跡です。設計選択を比較する上で有用です。
