2026年第1回openEHR研究会

2026年第1回openEHR 研究会 小林慎治

全国医療情報共有プラットフォーム https://www.mhlw.go.jp/content/10808000/001620512.pdf

• https://www.mhlw.go.jp/content/10808000/001620512.pdf

PFの課題とその解決 • 共通課題 • 仕様書通りだと読みづらい • 診療情報提供書 • 閲覧保留の仕組みが実装困難 • 退院時サマリー • 情報提供を段階的に行う方法 • 検査 • JLAC11の運用について • 処方 • 診療情報提供書から抽出 • 退院時サマリーから抽出

2文書6情報（病院からPFへ） • 2文書 • 診療情報提供書 • 退院時サマリー • （健康診断情報報告書） ← 保険診療では行われない • 6情報 • 傷病名 • 感染症 • 薬剤禁忌 • アレルギー • 検査

診療情報提供書（紹介状）のワークフロー 紹介 退院 診療情報提供書 ＋ 退院時要約 病院A • 想定されていたフロー • 患者が退院時に診療情報提供書と共に退院サマリーが添 付される。退院時要約は退院前に準備される。 • 退院後でないと退院日時が確定しないのにもかかわらず、 退院後に退院時サマリーの編集ができなかった。 • 例外フロー • 退院前に転院の打診として診療情報提供書と仮退院サマ リーを送る。 • 退院後に結果が出た検査を退院時要約に追記して紹介先 に送る。 病院B

診療情報提供書 • 人間可読性が前提 • 誰かが読んで判断するものであり、検査値のように自動でalertを流すこ となどは想定されていない。 • 実はさまざまな診療情報で構成される。 • その全てに対応するには膨大なスキーマが必要となる。 • 患者氏名、医師、病院、紹介目的、症状経過、治療内容、投薬内容、手術、機器 • 病院によって差異がある • 紹介目的（特に検査目的）によって事前に求められるデータ項目が増える ことがある。 • FHIRで対応する場合、独自のProfile、APIなどを別個に開発すること となる。（Profile爆発問題）

処方データ • 院内処方箋 • 頻繁に処方される • 変更・中止あり • 電子カルテ内部データとして処 理される • 退院時サマリー・診療情報提供 書 • 確定した処方情報が含まれる • ただし、含まれないこともある • きちんとUIを作り込まないと形 式が変わる • 外部出力が前提とされる

処方データの取得元変更 • 入院処方箋は院内で処方されるため外部には出ていかない。 • したがって、診療情報提供書・退院サマリーからデータを抽出している こととしていた。 • しかし、診療情報提供書に記載される処方箋にYJコードなどが付与さ れていないことが多くデータの抽出が困難。 • 院内処方箋も電子処方箋管理サービスに登録することで対応していく。

Medication関連FHIR Resource • Medication • 複数の薬剤をまとめるResource、注射薬剤で使用(JP Core) • MedicationRequest • 処方オーダー情報 • MedicationDispense • 薬剤払い出し情報 • MedicationAdministration • 薬剤投与情報 • MedicationStatement • 薬剤使用状況 • Immunization • ワクチン接種

診療情報提供書内の処方情報 構造化Resourceを使用 テキストのみとする • メリット • メリット • 再利用性が高まる • そのまま処方情報として利用できる • 確実に使われる薬剤情報を取得で きる • デメリット • 電子カルテ側のUIなどを作り込む 必要がある。 • 採用薬剤などの違いもあるので結 局再入力になりがち • コードが違うと伝わらない • 実装が楽 • 見た目はあまり変わらない。 • デメリット • 処方データとして再利用することが できなくなる。

FHIR診療情報提供書全体構造

HL7 FHIR 診療情報提供書(JP CLINS)？

Bundle-CLINS-Referral-NoEntryExample-01 - JSON Representation
{
"title" : "投薬指示",
"code" : {
"coding" : [
{
"system" :
"http://jpfhir.jp/fhir/clins/CodeSystem/document-section",
"code" : "430",
"display" : "投薬指示セクション"
}
]
},
"text" : {
"status" : "additional",
"div" : "<div
xmlns=¥"http://www.w3.org/1999/xhtml¥">タケキャブ錠10mg1錠
¥u3000１日2回¥u3000朝食後、就寝時<br/>レバミピド錠100mg1錠
¥u3000¥u3000１日3回毎食後</div>"
}
}

https://jpfhir.jp/fhir/clins/igv1/Bundle-Bundle-CLINS-Referral-NoEntry-Example-01.json.html

• https://jpfhir.jp/fhir/clins/igv1/Bundle-Bundle-CLINS-Referral-NoEntry-Example-01.json.html

Example-JP-MedReq-eCSfukintouByDay - JSON Representation

FHIR paradims

FHIRの特徴と課題 • 特徴 • Fast. 実装しやすい。 • REST, JSONなどの汎用ツールを利用できる。 • HL7 V2, V3との互換性も高い • 過去の資産を容易に転用できる。 • 課題 • Terminologyを併用しないと相互運用性が保てない • Profile設計にはそれなりのスキルが必要 • 文書など複雑な構成に対応するとその特性であるFastでもなくなる。 • FHIRインスタンスをデータベースに格納する運用も検討はされているが 一般的とはされていない

海外でのFHIR-EHR運用例 • 病院からセンターサーバへの APIとしてFHIRを利用。 • センターサーバはopenEHR で構成。 • Terminologyとしては SNOMED CTを全面的に採 用。 勝ち確パターン

openEHRとは • openEHR is NOT • Open-source EHR • EHR(電子カルテ）のオープンソースソフトウェア実装ではない • Open EHR • 誰でもアクセスできるように公開された電子カルテというわけではない • openEHR is • Open specification for EHR implementation • EHRを実装するための公開された仕様 • Open clinical concept models for EHR semantic interoperability • EHRの相互運用性のために、公開の元で開発された臨床概念モデル

openEHRとHL7 FHIR FHIR openEHR • Message志向 • Record志向 • 「情報交換規約」 • 構造 • 診療情報を長期にわたって記録 していくための規格 • Resource • Profile • 構造 • Observation • 概念モデル • 概念モデル • 多段階モデル • 参照モデル、アーキタイプ、テンプ レート • Observation以下に相当する 概念モデルが500程度ある。

HL7-FHIR × openEHR Collaboration Workshop • Joint Workshop in Amsterdam • 2025年6月2－3日 • 約50名での会議 • openEHRとHL7の主要メン バーが参加し、相互運用性の未 来を議論

HL7 FHIRとopenEHRが協力する背景 と目的 • 両団体の共通点 • 目的：患者・臨床・研究に資するグローバルな相互運用性の実現相互運用 性の実現 • 運営：コミュニティベース • 双方に共通するツール・モデル・コミュニティの強みを融合し、相補 的な関係性を追求 • HL7の強み：国際的な組織力 • openEHRの強み：臨床概念モデル構築などの実績

会議の成果 • Rachel Dunscombe （openEHR CEO） • 「相乗効果を生む未来に向けた明確 なビジョンが得られた」 • Daniel Vreeman（HL7 CSDO） • 「お互いの強みを結集して相互運用 性を前進させられる」（抜粋） • 関係するコラボ領域に関して共 同グループを設立し、継続的な 「進捗報告会」の開催とオープン 情報共有を実践

仕様の比較 openEHR CEN/ISO 13606 HL7 FHIR An extract of an EHR Extract of EHR Multi document message Folder Folder Bundle Composition (versions) Composition (+/‐versions) Composition Section Section Section (ENTRY) Entry (ENTRY) Health Record •Observation •Observation •Action (Administration, etc) •Evaluation •Condition •Instruction •ServiceRequest Cluster Cluster Element Element

openEHR参照モデルの構造

臨床概念を表現するアーキタイプ • アーキタイプ – 診療における各実体に対して合議のもとで形式化された相互運用 性のあるデータモデル仕様 • 観察事項，検査，治療計画や処置の記録など – オントロジーベースでのデータモデリング • openEHRプロジェクトで開発 – ISO 13606で認証され標準規格に – 臨床家と技術者が相互に協力 – 多言語対応，複数のターミノロジーにも対応

アーキタイプの構造

「血圧」の臨床概念 at0004 – DV_QUANTITY at0005– DV_QUANTITY at0000 - concept name

アーキタイプとテンプレート Sam Heard, EHR標準ISO13606 and openEHR, 第28回医療情報学連合大会2008

openEHRのTemplate • Better studio供覧

EHRの設計と採用が成功するために要求される 取り組み(engagement) • 臨床での取り組み(clinical engagement) • どのようなソリューションが便利で利用できるのか合意形成を開始 • 臨床家をすべての過程において巻き込み続ける • 社会的取り組み（Societal engagement） • 患者の安全と機密の保護を保証する • ベンダの取り組み（Vendor engagement） • レガシーシステムと既存のデータ品質と完全性を受け入れる • 新しいソリューションの複雑さを最小化する • 新しい投資のためのビジネスケースを提案する • 国家的取り組み（National engagement） • 国家的保健行政と公衆衛生上の優先度をよく調和させることを保証する • もう一度臨床での取り組み(Clinical engagement again) • 記録を共有する文化，記録を再利用する文化，機密保護とセキュリティ信頼を保証するシステ ム 2013年日本医療情報学会でDipak Kalra教授の講演より