⚕️

「いにしえの医療システム」は「最先端のイベント駆動アーキテクチャ」だったのか？――オーダリングシステムからPHR、そしてAIエージェントへ

2026/02/05に公開

Pub/Subアーキテクチャを設計する際、そのルーツがどこにあるか考えたことはありますか？
実は、モダンなマイクロサービスが追い求めている「疎結合」や「イベント駆動」の理想形は、数十年も前から病院のオーダリングシステムで実践されていました。そして2026年現在、その思想はスマートフォンの中で生き続け、AIとFHIRによって新たな進化を遂げています。

 オーダリングシステムは「元祖Pub/Sub」であるモダンなシステム設計において、サービス間を仲介するメッセージブローカー（Google Cloud Pub/SubやKafkaなど）は欠かせません。
実は、病院のオーダリングシステムはこれと全く同じ構造を持っています。

 構造の比較

役割
現代のPub/Sub
医療オーダリング


イベント発生 (Publisher)
Microservice A
電子カルテ（医師の入力）

メッセージ形式
JSON / Protobuf
HL7 v2.x / FHIR

仲介役 (Broker)
Topic / Bridge
オーダリングサーバー

受信者 (Subscriber)
Microservice B, C...
薬剤・検査・医事会計システム

医師が「処方」ボタンを押した瞬間、そのイベントはメッセージとして中継サーバーに飛び、複数の部門システムへ一斉配信（ファンアウト）されます。「送り主は受け手が誰かを知らなくていい」という疎結合の思想は、まさに現代のアーキテクチャそのものです。

 オーダー＝イベントの永続化さらに注目すべきは、オーダーが「命令の記録」として全て保持される点です。
医療現場では、「いつ、誰が、何を指示したか」の記録は法的にも臨床的にも極めて重要です。そのため、オーダリングシステムは発行されたオーダーを全てイベントとして永続化します。
これは現代のイベント駆動アーキテクチャにおけるイベントソーシング（Event Sourcing）と同じ考え方です。


概念
イベントソーシング
医療オーダリング


イベントの永続化
Event Store
オーダー履歴

現在状態の導出
イベントのリプレイ
オーダーステータスの集計

監査証跡
イベントログ
指示履歴・実施記録

変更不可性
Append-only
オーダー修正も新規イベントとして記録

オーダーは一度発行されると「削除」されません。中止や変更も、新たなイベント（中止オーダー、変更オーダー）として追記されます。これにより、「誰がいつ何を指示し、それがどう変更されたか」の完全な履歴が残ります。
医療安全の観点から生まれたこの設計思想は、現代のマイクロサービスにおける監査ログやイベントソーシングの要件と完全に一致しています。
日本では1983年に鹿児島大学病院が「オーダリングシステム」を稼働させ、1990年代から導入が本格化しました。ただし、日本の医療システム間標準化の歴史は複雑で、ベンダー独自仕様の乱立を経て、現在もFHIRへの移行が進行中です。この標準化の詳細は別の機会に譲りますが、病院内では「イベント駆動」の思想が数十年にわたり実践されてきたことは間違いありません。

 「いにしえの知恵」はどう魔改造されたかでは、この「いにしえのオーダリングシステム」が現代のクラウド技術でどう進化したのか。「メッセージの形」「スケーラビリティ」「信頼性の担保」の3点で見ていきましょう。

 1. 「手紙（HL7）」から「パケット（JSON）」へ昔のオーダリングシステムで使われていた HL7 v2.x は、パイプ記号（|）で区切られた非常に「いかつい」テキスト形式です。
# HL7 v2.x（人間がパッと見ても意味不明な暗号のよう）
MSH|^~\&|ORDERING|HOSPITAL|PHARMACY|...
PID|||12345^^^HOSP||山田^太郎||19800101|M|||...
ORC|NW|ORD001|...
RXO|HOT12345^ロキソニン錠60mg^HOT9||1||錠|...
// 現代のJSON（人間も読めるし、プログラムも扱いやすい）
{
  "resourceType": "MedicationRequest",
  "id": "ORD001",
  "status": "active",
  "medicationCodeableConcept": {
    "coding": [{"system": "urn:oid:1.2.392.200119.4.403.1", "code": "HOT12345"}]
  }
}
現代のPub/Subは、中身のフォーマットを問いません。HL7という「特定の言語」に縛られず、どんなデータでも高速に流せる「究極の汎用パイプライン」に進化しました。そして、この「JSON化」の正体こそがFHIRです。

 2. 「物理サーバー」から「無限のクラウド」へここが一番の進化ポイントです。


観点
いにしえのオーダリング
現代のPub/Sub（Cloud Native）


インフラ
病院の地下のサーバーラック
Google Cloud Pub/Sub、Amazon SNS/SQS

スケール
限界が来たらサーバー増設（大工事）
秒間1億メッセージでも自動スケール

運用
1台のエンジンが1件ずつ処理
「詰まる」という概念をインフラが吸収


 3. 「届かなかった時」の執念医療システムは「オーダーが消える＝命に関わる」ため、再送処理（リトライ）には執拗なまでのこだわりがありました。現代のPub/Subでは、この「執念」が**デッドレターキュー（DLQ）**という形で洗練されています。


機能
いにしえのオーダリング
現代のPub/Sub


再送処理
管理画面で人間がポチポチ再送
指数バックオフで自動リトライ

エラー隔離
エラーで全体の配信が止まることも
DLQへ自動隔離、他は継続

順序保証
シーケンス番号で厳密に管理
オプションで選択可能


 まだ「いにしえ」のまま残っている闘い技術は進化しましたが、「本質的な悩み」は30年前から変わっていません。
マスタの不一致：送信側で「鎮痛剤」のIDが「A01」なのに、受信側が「B99」だと思っていると、いくらPub/Subが高速でもシステムは崩壊します。この「マスタ合わせ」の苦しみは、現代のマイクロサービスでも全く同じです。
べき等性（Idempotency）の確保：「ネットワークの瞬断で2回オーダーが飛んじゃった！」という時に、2回薬を出さないようにする仕組み。これは今もエンジニアを悩ませる「永遠の課題」です。
こうして見ると、医療システムは「絶対に失敗できない環境」でイベント駆動のプロトタイプを数十年かけて完成させてきたと言えるかもしれません。

 PHR（Personal Health Record）とFHIR：手のひらの上のPub/Sub病院内のオーダリングシステムは、あくまで医療機関の内部で完結していました。ここに変革をもたらしたのが、FHIR（Fast Healthcare Interoperability Resources）とスマートフォンの組み合わせです。

 FHIRは「共通言語（スキーマ）」であり「イベント通知基盤」でもあるFHIRはREST API（Req/Res）のイメージが強いですが、実は「いにしえのPub/Sub思想」と「モダンなWeb技術」を繋ぐミッシングリンクのような存在です。
1. 共通スキーマとしてのFHIR
Pub/Subにおいて最も困るのは、「メッセージの中身が送り主によってバラバラ」なこと。FHIRが登場したことで、「患者データならこの形」「処方ならこの形」という標準スキーマが決まりました。
また、FHIRは「マスタ不一致問題」に対してIdentifier（識別子）とCoding（コード体系）という概念で戦っています。「これはA病院のID」「これはHOTコード」と、複数のIDやコード体系を並列で持てるため、システム間の「翻訳」が容易になります。
2. FHIR Subscriptionという名のPub/Sub機能
ここが面白いポイントです。FHIRにはSubscription（サブスクリプション）というリソースが定義されています。
これはまさに、REST APIの世界にPub/Subの概念を持ち込んだものです。Req/Res（こちらから聞く）ではなく、イベントが起きたら「あちらから送ってもらう」仕組み。
!「通信手段はAPIだけど、設計思想はPub/Sub」――いにしえのオーダリングシステムが現代のWeb技術で蘇ったような形なのです。

 医療システムの進化：系統樹

世代
通信スタイル
形式
思想


第1世代（HL7 v2）
Push（一方通行）
パイプ区切り
「とにかく送るから、あとはよろしく」

第2世代（Web API）
Pull（Req/Res）
JSON（独自）
「必要な時に、必要な分だけ取りに行く」

第3世代（FHIR）
Hybrid（API + Subscription）
JSON（FHIR）
「標準形式で管理し、変化があれば通知する」


 Apple Health Records（2018年〜）AppleはHL7 FHIRとSMART on FHIRプロトコルを活用して、2018年にHealth Records機能をリリースしました。

FHIR R4 / DSTU2対応で、電子カルテ（EHR）からiPhoneへ直接データをダウンロード

SMART on FHIR（OAuth 2.0ベース）による患者ポータル認証
アレルギー、処方、検査結果、予防接種歴などをHKClinicalRecordとして端末に保存
現在、米国で700以上の医療機関がHealth Recordsに対応
「APIなのにイベント駆動っぽく見える」カラクリ
一度連携すると、病院側で「検査結果が出た」というイベントが発生した際に、iPhoneがバックグラウンドでFHIRデータを取得し、ユーザーに「新しい検査結果があります」と通知を出します。これはポーリング＋通知のハイブリッドで「イベント駆動」を実現している例です。
重要なのは、データが端末に保存される形式です。HealthKitは臨床データをHKClinicalRecordサンプルとして保存し、その中にFHIR JSONがfhirResourceプロパティとして格納されます。開発者はHealthKit APIを通じてこのFHIRリソースにアクセスできます。
// HKClinicalRecordからFHIRリソースを取得
let clinicalRecord: HKClinicalRecord = // HealthKitから取得
let fhirResource = clinicalRecord.fhirResource
let fhirJSON = fhirResource?.data // FHIR JSON形式のデータ

 Android Health Connect（2024年〜）GoogleはGoogle Fit APIの後継としてHealth Connectを開発し、Android 14からシステムに統合しました。そして2024年11月のAndroid 16 Developer Preview 1で、Medical Records APIが発表されました。

FHIR R4形式で医療記録データの読み書きをサポート
最初は免疫記録（Immunization）から開始し、今後検査結果、投薬情報などに拡大予定

READ_MEDICAL_DATA_IMMUNIZATION / WRITE_MEDICAL_DATA権限による明示的な同意モデル
Health Connect内でデータは暗号化され、端末にローカル保存
Health Connectの医療記録APIは、まさにFHIRを前提とした設計です。
// Health Connect Medical Records API（Android 16〜）
// FHIR形式のリソースを書き込み
val immunizationRecord = MedicalResource(
    fhirResource = fhirImmunizationJson,  // FHIR R4 JSON
    medicalResourceType = MEDICAL_RESOURCE_TYPE_IMMUNIZATION
)
healthConnectClient.insertMedicalRecords(listOf(immunizationRecord))

 PHRがもたらす構造的変化Apple HealthとHealth Connectは、医療データの流れを医療機関中心からユーザー中心へと転換しました。
従来：医療機関中心
PHR + FHIR：ユーザー中心
スマートフォンが「個人のFHIRサーバー」となり、複数の医療機関からのデータを集約する。これはまさに、手のひらの上のPub/Subハブと言えます。

 2026年の転換点：AIがFHIRを直接解釈する時代へ2026年1月、OpenAIとAnthropicは相次いで医療ドメイン向けの機能強化を発表しました。注目すべきは、両社ともFHIRを基盤としている点です。

 OpenAI: ChatGPT Health（2026年1月7日）OpenAIは週に2億3000万人以上がChatGPTで健康関連の質問をしているという分析結果を公開し、専用の「ChatGPT Health」体験をリリースしました。
技術的な特徴：

b.well Connected Healthと提携し、FHIRベースのAPIで220万以上の米国医療機関、320の健康保険プランからの臨床データ接続を実現

Apple Health、MyFitnessPal、Weight Watchersなどウェルネスアプリとの連携
専用の隔離空間（サンドボックス）で健康データを管理
医療会話はモデル学習に使用されない
ユーザー体験：
ChatGPT内の「Health」タブが独立した空間として機能し、検査結果のPDFをアップロードして平易な言葉で説明を受けたり、診察前の質問準備を支援してもらったりできます。

 Anthropic: Claude for Healthcare（2026年1月11日）OpenAIの発表から4日後、Anthropicも「Claude for Healthcare」を発表しました。JPMorgan Healthcare Conferenceに合わせたタイミングです。
技術的な特徴：

HIPAA対応インフラをエンタープライズ向けに提供

HealthEx、Functionとの連携（ベータ版）

Apple Health / Android Health Connect連携をiOS/Androidアプリで展開開始

Connectors：CMS Coverage Database、ICD-10、National Provider Identifier Registry、PubMedなど医療データベースへの接続
Agent Skillsによる自動化：
Anthropicが発表した中でも注目すべきはFHIR developmentとPrior Authorization ReviewのAgent Skillsです。
FHIR development skill:
- 医療システム間の相互運用性を改善
- 開発者がより少ないエラーでより速くシステムを接続できるよう支援

Prior Authorization skill:
- カバレッジ要件、臨床ガイドライン、患者記録、アピール文書の
  クロスリファレンスを自動化
Eric Kauderer-Abrams（Anthropic Life Sciences責任者）は「ヘルスケアと生命科学セクターはAnthropicの最大の賭けの一つ」と述べており、単なるチャットボット機能を超えたエンタープライズ向け展開を明確にしています。

 何が変わったのか？これまでの「システム間連携」は、人間がプログラムを書いてFHIRリソースをマッピングし、ビジネスロジックを実装する必要がありました。
これからはAIがFHIRメッセージを動的に解釈し、次のアクション（オーダー）を生成する時代へと突入しています。
従来のFHIR連携
AI + FHIRの時代
Anthropicの発表によれば、FHIRのAgent Skillは「医療システム間の相互運用性を改善し、開発者がより少ないエラーでより速くシステムを接続できるようにする」ことを目的としています。

 PHRとAIの融合：個人の健康データがAIの「コンテキスト」になるApple HealthとHealth Connectに蓄積されたFHIRデータが、AIとの対話の「コンテキスト」として活用される。これが2026年に起きていることの本質です。
この構造により、AIは単なる「医療の一般的な質問に答える」存在から、**「あなたの健康履歴を理解した上で対話する」**存在へと進化しています。

 まとめ：温故知新のアーキテクチャ「Pub/Subは新しい」「イベントソーシングは新しい」と思われがちですが、医療現場では「命を守るための疎結合」と「医療安全のための完全な履歴保持」として、オーダリングシステムという形で長年実践されてきました。

Pub/Sub：オーダーを複数の部門システムへファンアウト配信

イベントソーシング：全てのオーダーを変更不可のイベントとして永続化
それが今、3つの進化を経て新しい姿を現しています：

FHIR：医療データの標準フォーマットとして確立

PHR：Apple Health（2018年〜）とHealth Connect（2024年〜）により、スマートフォンが個人のFHIRハブに

AI：ChatGPT HealthとClaude for Healthcare（2026年1月）により、FHIRデータをAIが直接解釈・活用
いにしえのオーダリングシステムの思想を理解することは、これからのAI×Healthcareアプリを設計する上で、最大の武器になるはずです。

 おわりに本記事は、医療ITの「いにしえの知恵」と現代技術の接点を探る試みとして執筆しました。
!筆者はここ数年、医療ITの現場から離れています。 特にFHIR周りの最新動向（Subscription R5の変更点、各国のImplementation Guideの進展など）については、キャッチアップが追いついていない部分があるかもしれません。
もし「ここは違うよ」「最新情報はこうだよ」というご指摘があれば、ぜひコメントでお知らせください。医療ITに携わる皆様からのフィードバックをお待ちしています。

 参考資料
 AI医療プラットフォーム（2026年発表）
Introducing ChatGPT Health | OpenAI（2026年1月7日）

Advancing Claude in healthcare and the life sciences | Anthropic（2026年1月11日）
OpenAI Selects b.well to Power Secure Health Data Connectivity | PR Newswire

 Apple Health + FHIRTechnical requirements and specifications for Health Records | Apple Support
Accessing Health Records | Apple Developer Documentation
Handling FHIR without getting burned - WWDC20

 Android Health Connect + FHIRMedical Records | Android Developers
Health Connect | Android Developers
Android FHIR SDK | Google for Developers

役割	現代のPub/Sub	医療オーダリング
イベント発生 (Publisher)	Microservice A	電子カルテ（医師の入力）
メッセージ形式	JSON / Protobuf	HL7 v2.x / FHIR
仲介役 (Broker)	Topic / Bridge	オーダリングサーバー
受信者 (Subscriber)	Microservice B, C...	薬剤・検査・医事会計システム

概念	イベントソーシング	医療オーダリング
イベントの永続化	Event Store	オーダー履歴
現在状態の導出	イベントのリプレイ	オーダーステータスの集計
監査証跡	イベントログ	指示履歴・実施記録
変更不可性	Append-only	オーダー修正も新規イベントとして記録

観点	いにしえのオーダリング	現代のPub/Sub（Cloud Native）
インフラ	病院の地下のサーバーラック	Google Cloud Pub/Sub、Amazon SNS/SQS
スケール	限界が来たらサーバー増設（大工事）	秒間1億メッセージでも自動スケール
運用	1台のエンジンが1件ずつ処理	「詰まる」という概念をインフラが吸収

機能	いにしえのオーダリング	現代のPub/Sub
再送処理	管理画面で人間がポチポチ再送	指数バックオフで自動リトライ
エラー隔離	エラーで全体の配信が止まることも	DLQへ自動隔離、他は継続
順序保証	シーケンス番号で厳密に管理	オプションで選択可能

世代	通信スタイル	形式	思想
第1世代（HL7 v2）	Push（一方通行）	パイプ区切り	「とにかく送るから、あとはよろしく」
第2世代（Web API）	Pull（Req/Res）	JSON（独自）	「必要な時に、必要な分だけ取りに行く」
第3世代（FHIR）	Hybrid（API + Subscription）	JSON（FHIR）	「標準形式で管理し、変化があれば通知する」

オーダリングシステムは「元祖Pub/Sub」である

構造の比較

オーダー＝イベントの永続化

「いにしえの知恵」はどう魔改造されたか

1. 「手紙（HL7）」から「パケット（JSON）」へ

2. 「物理サーバー」から「無限のクラウド」へ

3. 「届かなかった時」の執念

まだ「いにしえ」のまま残っている闘い

PHR（Personal Health Record）とFHIR：手のひらの上のPub/Sub

FHIRは「共通言語（スキーマ）」であり「イベント通知基盤」でもある

医療システムの進化：系統樹

Apple Health Records（2018年〜）

Android Health Connect（2024年〜）

PHRがもたらす構造的変化

2026年の転換点：AIがFHIRを直接解釈する時代へ

OpenAI: ChatGPT Health（2026年1月7日）

Anthropic: Claude for Healthcare（2026年1月11日）

何が変わったのか？

PHRとAIの融合：個人の健康データがAIの「コンテキスト」になる

まとめ：温故知新のアーキテクチャ

おわりに

参考資料

AI医療プラットフォーム（2026年発表）

Apple Health + FHIR

Android Health Connect + FHIR

Discussion