ユーザーとベンダーの協力を深めるためのHL7 FHIR第01回 HL7 FHIRの「成功する院内導入方法」

皆さんこんにちは、群馬大学医学部附属病院システム統合センターの鳥飼です。2022年7月20日に開催されました電子カルテフォーラム「利用の達人」(以下「利用の達人」)に日本赤十字社愛知医療センター名古屋第二病院の岸真司先生からお招きいただき、HL7 FHIR ®（以下FHIR）に関する講演を行いました。盛夏と新型コロナの対応でご多忙にもかかわらず、多くのご関心を賜り篤く御礼申し上げます。講演後、ご視聴いただきました皆様から「より基礎的な説明」と「より進んだ利活用」の両側面から理解をしたいとの依頼を「利用の達人」事務局様よりいただきました。そこで本稿から4回にわたり、FHIRについてのコンセプトに関する概説と共に、FHIRを医療における情報の利活用に活かす方法について、ユーザーが必要なこと、ベンダーが必要なことの両視点から考察を試みます。私も終わりなき道半ばのユーザーの一人でありますので、読者諸賢のユーザーの皆様、ベンダーの皆様には、このコラムをきっかけとしてFHIRを通じた「働きやすさ」を得るための建設的な議論や実臨床における取り組みが活発になればと心から願います。それでは、しばし駄文にお付き合いください。
各回のテーマは次の通りです。

第１回： HL7 FHIRの「成功する院内導入方法」
第２回：「院内Web化」のためのインフラ整備
第３回：「施設共通ワークフロー」と「個別ワークフロー」の作成と長期運用維持
第４回： 長期展望：「検証された医療プログラム」に貢献する社会モデルへの変革

改めて、HL7やFHIRの特徴について

HL7はHealth Level 7の略号であり、7は「OSI参照モデル（注1）の7番目=アプリケーション層」を対象とするという意味を含んでいます。v2の実装が電文形式、v3の実装はオブジェクト指向モデル（注2）と変遷しており、"7"の定義に当てはまります。しかしv3までは第6層までの実装を実施者に委ねることとなったため、多くの「パーサー（電文やオブジェクトをコンピューター的に解釈する手段）」が発生し、結果として多大な疎通確認、すなわち「コネクタソン（注3）」を必要としていました。日本HL7協会の発足は1998年であり、この頃通信はもっぱらサーバー間のオーダリングに関する標準化が議論されていたこともあって、疎通確認は主に構築時に発生していました。時代が進み、IoT(Internet on Things)コンセプト、すなわち「機械やデバイスが、Internet通信の手段に即して相互に通信する」ことが経済的であるとの認識が市場に定着することにより、検査機器や通信端末を含めて医療の電子デバイスがIoT化される将来像が共有されてきたものと捉えています。この流れに沿うように、2009年にHL7協会で開始されたv3の課題点を抜本的に見直すための活動として"Fresh Look"が開始され、FHIR(Fast Healthcare Interoperability Resources)コンセプトの基礎設立に繋がっていきます。

私見ですが、FHIRの各イニシャルは、「診療現場におけるFHIR導入の順序」を示唆した巧みな名付けだと解釈しています。それは

段階1 : F : Fast、v3が実装までに時間がかかりすぎたことの反省を踏まえ、診療現場に「素早く」導入できる箇所（特にデータ参照）から個々に始める
段階2 : H : Healthcare、医療(Medical)に限らず、PHR(Personal Health Record：パーソナルヘルスレコード)を含むヘルスケア全体で活用できる箇所へ浸透する
段階3 : I : Interoperability、情報と各種指示を共有する段階になり、通信内容や運用方式等の施設間でのすり合わせを行い、共通化する
段階4 : R : Resources、地域、国、世界を単位として、医療情報をインターネットアドレスのように「安定し長期にわたって有効な参照先とする」ためのすり合わせを行い、更なる利活用を進める

のように捉えられるからです。この示唆を仮説としてFHIRの応用を試みていったところ、私個人としては「合理的であった」、そして「良かった」と感じています。

FHIRの示唆する段階から「成功する院内導入方法」を考える

さて、このFHIRの示唆から、ゼロベースの現在から院内導入をいかに始めていくかを考えていきましょう。医療に限らず、おしなべて「データ」や「情報」と呼ばれるものは、これを生成する人の負担や必要な技能が、これを参照する人のそれよりも相対的に大きい傾向にあります。もちろん、参照するデータ量が多くなればこれに限りませんが、その場合は「参照」というよりは「編集」と呼ばれる方が適切かなと思います。医療情報でいえば、医療指示やオーダー、記録を「作成する」人の負担や技能が高い、ということになります。
電子カルテに用いられる技術においても、生成された指示や記録の三原則：真正性、見読性、保存性のうち、医療安全で問題となる「真正性」をいかに担保するかに多くの検証、維持を含む労力が必要です。また、電子カルテではデータベースに1000を超えるテーブルを擁しており、医療データはいつのまにか診療録の法的保存義務である5年を超えて「永続的に」参照できることが常識のようになってしまいましたので、「保存性」の担保もひと苦労です。そこでこの「見読性」に注目してみますと、相対的に「必要な負担が少ない」ことに気が付きます。計算機の能力の特長である「正確な複製」「正確な伝達」を利用する、すなわち、「診療上の必要な場面で、医療情報を参照したい場面を考え、その箇所を電子化する際に、FHIRの方法が使えないか？」と考える、ここにFHIRの導入のヒントがあります。

前項でHL7はOSI7階層を指してきた、と記述しましたが、最初にFHIRの説明を他書にて参照した際の印象は「データフォーマット＝JSON（注4）」（第6階層）や「通信プロトコル＝REST（注5）」（第5階層）に対しても言及がある、という点でした。これは医療以外のWebにおいて、JSON/RESTがデファクトとして普及したということを踏まえての意欲的な取り組みであると解釈しています。まずJSON/XMLの採用については、先に述べたv2における「パーサー共通化の問題」を大きく改善する可能性があります。

私のおすすめする方法は、JSON=JavaScript Object Notationの略号に沿い、アプリケーションをJavaScript（正確にはECMAScript2015以降）で作成することです。この理由は次回以降に改めて詳説します。RESTについては、サーバー、クライアントを含むデータの通信方式を共通化することにより、個別にソケット通信（注6）のプロトコルを定める必要がなくなる利点があります。さらに、Web市場で十分に信頼性の向上した、Web/REST通信モジュール（≒プログラムを構成する部品）を有償/無償のそれぞれで利用することです。これまで医療ITベンダーが苦労して維持管理し、信頼性を高めてきた通信モジュールを手放すのは急には難しいですが、既に稼働信頼性の高いRESTモジュールを活用することで、動作検証にかかる工数の多くを省略できます。この2つの技術活用と併せて、Webブラウザをデータの表示アプリケーションとして活用することが考えられます。Webブラウザを標準的なビューにすることで、デバイス依存性、つまりパソコン端末でもスマートフォンでも、ブラウザが動けばアプリケーションが動く、という状態を将来的にも担保しやすくなります。このように、「社会的に定着し、長期にわたって使われるようになった技術を基盤とする」ことで、デバイスについては市場のスケールメリットの恩恵を受けられるようになり、オープンソースソフトウェアについては多くの検証が為されたコードを活用できるようになります。実装の際に使用する技術やアーキテクチャを賢く選択することにより、FHIRは医療ソフトウェアサービスの経済性にも貢献します。

ユーザーが必要なこと

多くのユーザーは、「ユーザーが求める機能を、合理的な工数や価格で実装し、利用できること」を求めているのではないかと思います。ここで改めて、「ユーザー」とは誰を指すのでしょうか？自分、自部署、自施設、地域、全国まで、「ユーザー」の取りうる意味範囲は様々です。一方で、過去に学ぶのであれば、ユーザーが自施設ごとに異なった改造を行った結果、保守や更なる機能追加が行き詰まったことを思い返す必要があるでしょう。ここに、ユーザーが必要なことのヒントがあるように思います。それは、「自施設のニーズと、全国のニーズが一致する点を模索する」ということです。また、「改造を企図した箇所が、本質的な医療ワークフローやガイドラインに沿っているかを確認する」ことも有益だと考えます。幸いにして、この「利用の達人」というコミュニティが、自施設と全国のニーズの接点を模索するのに役立つでしょう。ベンダーの取り纏めを待つことなく、ユーザーは改造を企図した際には相談し合う、まずそのような取り組みが、持続的なFHIR開発を実り多いものにするために求められる、と言えそうです。

ベンダーが必要なこと

一方、ベンダーは「これまでに積み上げられてきた、非Web化コード資産を段階的にWeb化させるための方針」について検討を進める必要があります。オーダー発行の際のSQLコードやソケット通信プログラムなど、多数の施設で長年利用され検証を重ねたコードは信頼性も高く、部門システム側も対応に慣れており、開発者側にとって手間の少ない資産＝エコシステムが形成されていますから、新しいWeb化技術、新しいプログラミング言語、新しいフレームワークの導入によって、積み上げてきた資産を徐々に失うのは一時的にせよ抵抗が大きいと思います。現在の開発手法は、オブジェクト指向であれば、基底クラスの肥大化を招いているでしょうし、版管理の問題も抱えているかと推測します。しかしながら、Web化は適切な設計を施すことで、従来よりも優れたリファクタ性（注7）を獲得でき、また認証や復旧などサイバーセキュリティ性能の獲得にも有効です。ベンダーエンジニアは、まずWeb移行を行うことを会社の中核ミッションとして位置づけ、今風の表現にするならば「リスキリング」、技能の再習得を始めることが必要であると思います。特に、プロトタイプベース（注8）オブジェクト指向は、アジャイルやリファクタの能力を獲得するために欠かせない設計法であり、オブジェクト指向の開発手法に親しんできたエンジニアの方が、最初からプロトタイプベースオブジェクト指向を学ぶよりも抵抗が大きいと感じています。かくいう私もその一人でした。しかしプロトタイプベースオブジェクト指向の利点を体験した今は、元の開発手法に戻りたいとは思いません。そのような「『将来の見通しが開ける体験」が、ベンダーエンジニアの方々に広まっていくこと』が最初に必要とされること、と言えるかと思います。

注1 OSI参照モデル
コンピュータネットワークで様々な種類のデータ通信を行うために機器やソフトウェア、通信規約（プロトコル）などが持つべき機能や仕様を複数の階層に分割・整理したモデルの一つ。
出典：e-words

注２ オブジェクト指向
コンピュータプログラムの設計や実装についての考え方の一つで、互いに密接に関連するデータと手続き（処理手順）を「オブジェクト」（object）と呼ばれる一つのまとまりとして定義し、様々なオブジェクトを組み合わせてプログラム全体を構築していく手法。
出典：e-words

注3 コネクタソン
「コネクト」と「マラソン」を掛け合わせて「コネクタソン」と称される。
出典：株式会社リベルワークス

注4 JSON
JavaScriptにおけるオブジェクトの表記法を応用したテキスト（文字）ベースのデータ形式。多数の要素が複雑な構造で組み合わせられたデータを簡潔な表記で書き表すことができる。JavaScriptプログラム上ではコードとして実行するだけで読み込みが完了する。
出典：e-words

注5 REST(Representational State Transfer)
分散システムにおいて複数のソフトウェアを連携させるのに適した設計原則の一つ。2000年にロイ・フィールディング（Roy Fielding）氏が提唱した。狭義には、それをWebシステムに適用したソフトウェアの設計様式を指し、一般にはこの意味で用いられることがほとんどである。
出典：e-words

注6 ソケット通信
実行中のプログラム間でデータの送受信を行うための標準的な仕組みの一つにソケットと呼ばれる仕組みがある。
出典：e-words

注7 リファクタ性
リファクタ＝リファクタリング（refactoring）
ソフトウェア開発において、プログラムの動作や振る舞いを変えることなく、内部の設計や構造を見直し、コードを書き換えたり書き直したりすること。
出典：e-words

注8 プロトタイプベース
オブジェクト指向プログラミング言語のうち、元になるオブジェクトを複製し、要素や動作の追加や変更を行うことで新しいオブジェクトを定義する方式。オブジェクトの雛形にあたる「クラス」（class）を定義するクラスベース（class-based）のオブジェクト指向と対比される。
出典：e-words