現在、医療現場をリアルに目にする毎日です。藤田医科大学は医療DXの最先端を走っていますが、せっかくの機会なので、自分自身も長年関心をもっていた医療DXのこれまでの経過と現状を整理してみます。
医療機関では患者の診療情報や検査データを電子カルテ（EHR: Electronic Health Record）や病院情報システム（HIS: Hospital Information System）で管理しています。
しかし、病院ごとにシステムが異なり、データ形式がバラバラだと、情報の共有や連携が難しくなります。今日ように、病院と診療所の病診連携や病院間での患者の引継ぎが日常的になると、医療情報システムの重要性はますます高まります。
医療に限った話ではありませんが、ある分野で情報システム、情報プラットフォームを構築する場合、「標準化」というプロセスが非常に重要になります。標準化は記録するデータ（病名等）の標準化に加え、使用するシステムインフラのS/W、H/Wにも及びます。
日本では長い間、標準化に関してベンダー間の覇権やシェア争い、ユーザー間の利害関係等々が障害となって思うように進みませんでした。2000年代初頭（僕が国会議員になった頃）にはそれなりに先進国の先頭集団を走っていた気がしますが、今は昔。その後は遅れました。
現在は2010年代後半以降から始まったキャッチアップの局面にあります。
そこで現在重要な鍵となっているのが HL7 FHIR（Fast Healthcare Interoperability Resources） 呼ばれる国際規格です。
FHIRは、医療データをスムーズにやり取りできるようにするための標準規格であり、特にWeb技術を活用しているのが特徴であり、国際的な医療情報標準化団体 HL7（Health Level Seven International） によって開発された規格です。
HL7は1987年 に米国の医療情報技術の専門家や医療機関、ベンダーが集まり、設立しました。この時代、こういう際に他国や欧州に対抗するために結束できるのが米国の強味。日本はこうした点が残念でしたね。
「Level Seven（レベル7）」は OSI参照モデルの第7層（アプリケーション層） を指します。ちょっと専門的ですが「異なるシステム間でのデータ交換を標準化すること」を目的としています。
当初は HL7 v1 （バージョン1）や HL7 v2 といったメッセージング規格が開発され、医療機関内でのデータ連携を効率化する役割を果たしました。
その後、1990年代に国際的に標準化が進み、HL7のメンバーが世界中に拡大しました。この段階で標準化を巡る覇権争いの今日の帰趨が形成され始めたということです。
各国でもHL7の規格を普及させるために、各国ごとのHL7協会（HL7 Affiliate） が設立され、日本でも1997年に HL7 Japan（日本HL7協会） が設立されました。
2000年代に HL7 v3 や CDA（Clinical Document Architecture） が開発され、より精密なデータ交換が可能になりました。
2010年代には FHIR（Fast Healthcare Interoperability Resources） が発表され、RESTful API技術を活用することで、より柔軟で使いやすいデータ交換が可能になりました。
RESTful API技術の「REST」とは「REpresentational State Transfer」の略で、分散型システムにおける複数のソフトウェアを連携させるのに適した設計原則の集合、考え方のことです。Roy Fieldingというエンジニアが2000年に提唱しました。重要なポイントなので、次項で詳述します。
RESTful API技術は「4の原則」から成り立っています。
第1に「アドレス可能性（Addressability）」。提供する情報がURIを通して表現できること（つまりネットワーク上の所在が明らかなこと）。全ての情報はURIで表現される一意なアドレスを持っていることが原則です。
RESTful APIを使うメリットとして、URI（Uniform Resource Identifire）に規律が生まれることで、APIを利用するサービス開発者が楽になります。URIに規律が生まれることで、API開発者もURIからどの部分のソースなのかが容易にわかります。
URIはデータや機器を一意に認識するためのデータの書式であり、Web技術でよく登場するURLはその一形式です。
第2に「ステートレス性(Stateless)」。HTTPをベースにしたステートレスなプロトコルであること（特定の先に帰属しないこと）。セッション等の状態管理はせず、やり取りされる情報はそれ自体で完結して解釈できることになります。
第3に「接続性(Connectability)」。情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができること。
第4に「統一インターフェース(Uniform Interface)」。情報の操作(取得、作成、更新、削除)は全てHTTPメソッド(GET、POST、PUT、DELETE)を利用すること。
GET、POST、PUT、DELETE等のHTTP標準のメソッドを使うことで、シンプルで一貫性のあるリクエスト標準化が円滑に行えます。統一インターフェースに値します。
HL7協会が推奨してきたRESTful原則に基づくFHIRは、医療データの相互運用性を高め、世界中に広がっています。FHIRを中心に、電子カルテの標準化や医療システムのデータ連携を推進し、医療のデジタル化を支える重要な組織となっています。
HL7は、これまでに以下のような医療データ交換の標準を策定してきました。
1980年代から普及 HL7 v2では、主に病院内システム間のメッセージ交換を想定。例えば、検査結果をLIS（検査システム）から電子カルテへ送信することです。
2000年代の HL7 v3では、XMLベースで厳密なデータ構造を定義しましたが、あまり普及しませんでした。CDA（Clinical Document Architecture）、文書ベースの医療情報交換（退院サマリーなど）は進みました。
続くFHIRは、HL7v２、HL７v３これらの規格の課題を克服し、より柔軟で使いやすい形に進化したものです。FHIRの特徴と仕組みは以下のとおりです。
第1に、上述のとおり、FHIRの最大の特徴は、RESTful API（Web技術を活用したデータ通信）を基本にしている点です。これにより、繰り返しになりますが、「GET（取得）→ 患者情報を取得」「 POST（登録）→ 新しい診療記録を追加」「PUT（更新）→ 既存のデータを修正」「DELETE（削除）→ データを削除」という4つの基本機能でシステムを構築できます。
従来のHL7 v2やv3では、専用の通信プロトコルやメッセージ構造が必要でしたが、FHIRではWeb技術（HTTP）を利用するため、開発しやすくなりました。
第2に、 リソース（Resource）ベースのデータ構造。FHIRでは、医療データを「リソース（Resource）」と呼ばれる単位で管理します。たとえば、以下のようなリソースがあります。
Patient（患者情報） → 氏名、生年月日、性別など、Observation（観察記録） → 血圧や検査結果、Medication（処方情報） → 服薬履歴、Encounter（診療記録） → 診療日時や診療内容、AllergyIntolerance（アレルギー情報） → アレルギーの有無。
FHIRのリソースはJSONまたはXML形式で表現され、API経由でやり取りされます。
第3に、拡張性と相互運用性。FHIRは、標準のリソースモデルを提供しながらも、各国や医療機関のニーズに応じて**カスタマイズ（拡張）**できる仕組みがあります。例えば、日本の医療制度に特有の情報を追加することも可能です。
また、FHIRは既存の医療情報標準（SNOMED CT、LOINC、ICD-10 など）とも連携可能で、データの統一性を確保できます。
FHIRを導入するメリットとしては、以下のようなことが考えられます。
第１に、医療データの共有・連携が容易になります。FHIRを使うと、異なる医療機関やシステム間でのデータ共有がスムーズになります。例えば、A病院の電子カルテとBクリニックのシステムがFHIR対応していれば、患者の診療情報を即座にやり取りできます。
第2に、 開発しやすく、導入コストを削減。FHIRはWeb技術を基盤にしているため、一般的なソフトウェア開発者でも扱いやすく、アプリやシステムの開発コストを削減できます。たとえば、FHIR APIを使えば、モバイルアプリで診療データを参照したり、クラウド上で医療データを管理したりすることが容易になります。
第3に、患者中心の医療（PHR）を促進。FHIRは、患者自身が自分の医療データにアクセスできる環境を整えるのにも適しています。スマートフォンアプリで自分の診療履歴や検査結果を確認することが可能になります。Appleの「Apple Health」もFHIRを活用しています。
米国では医療保険制度（CMS）がFHIRを採用し、医療情報の相互運用性を向上させているほか、民間保険給付のデジタル化も進んでいます。
IBMはHL7 FHIRを活用しており、医療機関と保険会社間のデータ連携を強化し、保険給付手続きのデジタル化を推進。これにより、手続きの効率化と迅速な保険給付が可能となっています。
EU各国ではFHIRを使った電子カルテの相互運用が進んでいます。また、HL7 FHIRを活用した電子ヘルスデータスペースの構築築が進められています。これにより、各国間での医療データ共有が促進され、患者の移動に伴う医療情報の連携が強化されています。
シンガポールは国家レベルでHL7 FHIRを導入し、医療機関間のデータ共有を円滑にする取り組みが進められています。これにより、患者の診療情報がリアルタイムで共有され、医療サービスの質向上に寄与しています。
オーストラリアは全国的な電子ヘルス記録システム「My Health Record」にHL7 FHIRを採用し、医療データの標準化と相互運用性の向上を図っています。これにより、医療従事者は患者の包括的な医療情報にアクセスでき、適切な診療が可能となります。
上記以外の各国でも、HL7 FHIRを活用する先が増えており、医療サービスの質向上や業務効率化、患者の利便性向上が期待されています。
日本でも厚生労働省がHL7 FHIR準拠のクラウドベースの電子カルテの開発・導入を推進しています。医療機関ごとに異なる電子カルテの規格を統一するため、HL7 FHIRに準拠した医療データの標準化が進められています。
日本医療情報学会と日本HL7協会は、HL7 FHIRに基づく「処方情報」「健康診断結果報告書」「診療情報提供書」「退院時サマリー」などの標準仕様を策定し、厚生労働省標準として採択しています。
厚生労働省の医療情報連携ガイドラインにもFHIRが組み込まれつつあり、大手病院の電子カルテ連携（FHIRを活用した地域医療ネットワーク）、民間企業によるPHRアプリ（患者が自分の診療データを管理するアプリ）などにも広がりつつあります。
厚生労働省はがHL7 FHIR準拠のクラウドベースの電子カルテの開発・導入を推進するに至った経緯と時期などについて整理しておきます。
日本の医療情報分野では、従来からHL7「バージョン2.5」「CDAリリース2」などの国際標準規格が使用されていましたが、これらの規格は複雑であり、最新のWeb技術に適応し難いという課題がありました。
その頃海外で注目されていたHL7「 FHIR」は、オープンなWeb技術を採用し、相互運用性と実装性を確保し易い規格として認識され、日本でも導入が検討され始めました。
厚生労働省は、標準規格準拠の電子カルテの普及を推進するために、コスト負担の軽減や拡張性の担保を検討しました。そして、中小規模の医療機関を対象に、既存の電子カルテの更新費用や新規導入費用の一部を支援するための医療情報化支援基金を設立しました。
厚生労働省は2022年3月24日付でHL7 FHIRに関する4つの規格を厚生労働省標準規格として認定しました。厚生労働省がFHIRを標準規格として採用した主な理由は以下の通りです。
第1に医療データの相互運用性向上。FHIRは、電子カルテや健診データ、レセプト情報など、異なるシステム間でデータを効率的に交換できるように設計されています。これにより、医療機関間や医療と介護の連携がスムーズになることが期待されました。
第2にデジタルヘルスの推進。日本政府は「デジタル庁」を設立し、デジタル化を進める中で、医療分野でもデジタルヘルスの推進が求められました。FHIRの採用は、電子カルテ情報共有サービス（EHR）やPHR（パーソナル・ヘルス・レコード）の普及を加速させる目的がありました。
第3にグローバル標準への対応。FHIRはHL7によって策定され、国際的に広く採用されています。日本でも国際基準に準拠することで、医療のグローバル化や海外とのデータ連携がしやすくなることが期待されました。
第4に 保険・診療報酬のデータ活用。FHIRを活用することで、レセプトデータや診療報酬の標準化が進み、保険制度の効率化や医療費の適正化に役立つとされました。
第5に患者の利便性向上。FHIRを用いることで、患者が自身の医療データにアクセスしやすくなり、個人の健康管理がしやすくなることも目的の一つでした。
こうした理由から、厚生労働省はFHIRを標準規格として採用し、医療データのデジタル化と相互運用性の強化を推進することを決定しました。
その後、データの外部出力機能や標準フォーマットでの出力APIの実装など、技術的な対応が進められました。セキュリティや個人情報保護に対応するための仕組みも構築され、クラウドベースの電子カルテの安全性が確保されました。
FHIRは、クラウド技術やAIとの融合 により、さらに発展すると考えられます。例えば、AIを活用してFHIRデータを解析し、患者ごとに最適な治療方針を提案することも可能になります。
クラウドベースで開発され、全国医療情報プラットフォームと連携することが可能なシステムの予定です。2025年中には無床診療所を対象にテスト運用が開始されるようです
厚生労働省でイメージしている無床診療所での業務の流れは以下の通りです。標準型電子カルテα版に搭載されている機能は、・外来受付、・診療記録、・各種オーダー、検体検査・処方）、・電子カルテ情報共有サービス連携などです。現在のところ無床診療所対象のため入院機能は装備されていません。
標準型電子カルテの導入のみでは診療は完結できない。「標準型電子カルテ」には外来受付・診療記録・各種オーダー（検体検査・処方）・電子カルテ情報共有サービス連携の機能が装備されています
レセコン・検査機器・予約システム・WEB問診・経営分析などの機能は装備されていないため、API（連携のための共通インターフェス）を通じて民間事業者のシステムと連携する必要があります
2030年に向けて「標準型電子カルテ」をすべての医療機関に導入することが目標のようです。その実現により国は国民の医療情報を収集でき、病院・クリニックは医療情報の共有によりスムーズな診療を行うことができるというメリットがあります。
現在の電子カルテの普及率は病院で6割弱、診療所で5割弱（厚生労働省令和2年調査）です。ここから100％の普及を目指すため、国が低コストでの電子カルテの導入をサポートするということです
現在は無床診療所を対象にした標準型電子カルテα版のみですが、2030年に稼働を目指す本格版は有床診療所や200床未満の病院も対象となる予定だそうです
既存電子カルテベンダーよりはるかに低価格に設定してしまうと既存のベンダーの業務を圧迫してしまうことになりかねません。今後、標準型電子カルテ、既存の電子カルテベンダーの製品いずれの選択をしても補助金を出すなどの施策が今後出てくる可能性はあるでしょう。
（了）