ユーザーとベンダーの協力を深めるためのHL7 FHIR第03回 「施設共通ワークフロー」と「個別ワークフロー」の作成と長期運用維持

FHIRを含むHL7規格が目指してきた「共通化」

第3回は、FHIRを含むHL7規格が目指してきた「共通化」について考察します。「共通化」の課題を考えるとき、私がまず思い浮かべるのは、院内でのタスクの順序や分岐と、それにかかわる職種、患者、実施の時刻などです。以下の文章では、これらを総称して「ワークフロー」と呼びます。さて、「共通化」という用語については、読者の方には「標準化」という用語の方が馴染みが深いと思います。しかしここでは敢えて「共通化」の用語で進めたいと思います。その理由は、HL7 FHIRは、v3以前のHL7 規格のように「どこかの特定の委員が作る」プロセスではなく、「現場のために作ったもののうち、他所でも役立つように作られたモジュールやフォーマット」が、役立つという理由を伴って広まり、その数が増えることから「JP-Core」のような国別の共通化になったり、あるいは国際的な共通化となって定着する、という方向でFHIRが広まることが期待されているからです。もちろん、専門家が提案、議論を重ねて案が策定され、パブリックコメントを通じて意見が寄せられたのちに制定される、これまで通りの活動も活発に継続しており、日本ではNeXEHRS研究会の活動がこれに相当します。それでもなお、FHIRは「ユーザー起点の」利便性を伴った視点でのフォーマット貢献が期待されています。

開発、というと何か特別なもののように感じられる言葉ですが、医療情報における「開発」とは、「現場に既に存在している何らかの課題・プロセスに対し、従前とは異なる方法を適用することで、課題やプロセスが医療の推進に貢献する活動」と考えていただければよいかと思います。またFHIRで多用されるフォーマットは「テキストファイル」(JavaScript Object Notation : JSON）ですので、メモ帳アプリとキーボードがあれば誰でも開発に参加できます。ではここで、JSONの基本的な記述の一部をごく簡単に紹介します。

JSONの基本的な記述

JSONは"label:value"と呼ばれる形でデータの構造を定めます。ここで、医療用にlabelの「名前」を、またvalueの「様式」を、医療に便利に使えるように定めよう、というのが、FHIRでの「開発」と呼ばれる部分です。例えば、患者さんに関する情報を例にとりますと、少なくとも「ID」と「姓」「名」の関連付けは最低限必要だと思います。
そこで、これをJSONで記述してみますと、例えば次のようになります：
{
 "ID" : "0123567",
 "姓" : "群馬",
 "名" : "花子"
}
ここで""はlabel名や文字列であることを示す記号です。「意外と簡単そう」と思っていただけるのではないかと思います。連絡先電話のように、複数の内容を記載する場合には、配列[]または{}を用います：
{
 "連絡先電話例1" : [ "012-3456-7890", "109-876-5432" ],
 "連絡先電話例2" : {
  { "012-3456-7890"},
  { "109-876-5432"}
 }
}
ここまできて、FHIRの公式Webページをご覧になった方や、v2/v3からHL7に関わったことのある方は、「そうは言っても、規格に準拠するとなると格段に難しいのではないか」と感じられるのではないかと思います。確かに、一定の手間は必要ですが、FHIRの実装をWebアーキテクチャとして捉えていれば、「リファクタ」（ユーザーには同じ機能を提供するが、コードの内部を将来的な機能追加に沿うように作り替えること）や「アジャイル」（現場業務の必要性を聞き、現場で使える試作を迅速に進める技法）というコンセプトによって、これまでよりも「ユーザーもベンダーも楽に」FHIR化への移行ができると考えています。
医療情報業界、学会が共に課題とするのは、「コードの信頼性をどの組織が担保するか」ではないかと思います。コードの中には、OSやライブラリの変化に即して調整を求められる箇所と、医療アルゴリズムのように、長い期間同一であるべき箇所とが含まれています。長期間の保守の中には、昨今危機感が高まるサイバーセキュリティに対する持続的な対応が含まれます。詳細は成書に譲りますが、今使っているソフトウェアのどこに、いつ脆弱性（ユーザー側が意図しない外部操作を可能とするようなバグ）が発見されるかが誰にも完璧に見通せないのがITの現状です。幸いWebセキュリティの研究が進んでおり、多要素認証（注1）やOAuth（注2）などのセキュリティ向上技術が広まりつつありますが、以前からのソフトウェア資産を抱えるサービスほどセキュリティモジュールの組み込みに多くの工数がかかること、Webテクノロジーへの移行にはエンジニアのスキルセットの変更が必要であることが実際に重い課題であるのではないかと推測しています。止められない電子カルテを保守しつつ、Webテクノロジー移行を段階的に進められるかという問題には、繰り返しますがユーザーとベンダーの相互理解と相互協力こそが本質的に重要です。

ユーザーが必要なこと

これはFHIR以前からずっと変わらないポイントですが、「医療現場で自分達が日々実践しているワークフローを、図や言葉で表現してみる」作業が必要です。ベンダーのエンジニアさんは確かにプログラミングや自社の医療アプリケーションについては詳しいですが、医療施設ごとに異なるワークフローを透視する超能力に期待するのは無理があります。時には「良き聞き手」が必要でしょう。ユーザーの「表現力」も、医師視点、看護師視点、技師視点や、診療科など、得意な分野も異なることと思います。できれば、医療情報セクションに携わる私達は、医療を実施される現場の「良き聞き手」となり、また時にはワークフロー表現のお手伝いをすることが求められているかと思います。こう書きながらも、私について正直に言えば、「聞き手を続けるのは精神的にタフな仕事だな」と感じていますし、「誰か（ベンダーさん含めて）肩代わりしてくれないかな」と日々思います。
医療側には、医療CIOや医療CISOが必要だ、という医療情報学会の主張は的を射たものと感じています。医療機関における医療CIO/CISO職の創設は、今後の病院組織の存否を決する要素となるのではないか、と私は推測しています。
医療情報職は「組織横断」を旨とする職務を遂行しますが、この実施には「組織としての意思決定」を伴わせることが必要な場面が多々存在します。もちろん、それはあくまで「合理性に基づいた合意」であるべきで、「管理者の強行」であるべきではないことは周知の通りです。「自分達の活動を、他者に知ってもらう」表現の研鑽は、医療情報セクションのスタッフにとって依然重要な能力であることに変わりはありません。
院内のスタッフに対しては「なぜその要望に至ったのか」を聞き出す力の重要性を強調したいと思います。この「なぜ」は、もう少し意味をはっきりさせるなら、「なぜその要望が、その部署が果たすべき役割に、どのように役立っているのか」を聞き出すこと、とも言えます。また、こうした「聞き出し」の内容を、ベンダースタッフさんが「ソフトウェアをどのように変化させればいいか」を連想しやすくなるように表現することも必要です。

ベンダーが必要なこと

これまでベンダーさんと関わってきた経験から、ベンダースタッフさんは、現場に滞在する時間が短く、また「外部」として対応される場面も多いため、医療者がOJTで経験を積むような形で医療現場の実情を知ることは少ないのではないかと思います。
しかし、医療者の「ネタバレ」を敢えてするなら、医療者も「タネ本」を頑張って読み込んでいたりします。医学書院や南江堂などが出版している医学系図書は、イラストも多く、用語も豊富です。例えば大学病院であれば、敷地内の書店に数千円で揃っています。看護系の書物は専門用語を解説しているものも多いです。こうした書物から「医療者の言葉と思考の構造」を知ろうとすることで、話題にできる医療行為が増え、医療者から「実は...」と要望につながる話につながることも多く経験しました。その病院さんの「真の悩み」に触れる機会をどのように増やせるかが、「本当に喜ばれる機能」を提供するために大切です。そしてコーディングを担当するエンジニアさんも、ぜひ現場でじかに医療者と話してもらう機会があるとよいと思います。
この時気をつけたいことは、医療者の要望を聞いた際に「コンピュータの世界ではこのようなので」という形のみで即断しないことです。よくヒアリングすると、実は紙の運用の方がよい場合や、要望の理由を聞き出すと、最初に思いついた複雑なコーディングとは違う、より単純な改造法が思いつくことも多々あります。どうしても「依頼される立場」になりがちなベンダースタッフさんという印象があります（もちろん凄腕のアーキテクトやスペシャリストもいらっしゃる前提です）が、ソリューションというものは「医療者との建設的な対話の中から自然と生じてくるもの」というイメージが持てるようになると、医療情報という仕事によりやりがいが持てるようになるのではないかと思います。
Webテクノロジーは、現状は「オープンソースに手探りで挑戦し、理解した人」が「事業を起こして成長する」という状態でありますから、ベンダーの経営者は、もしオープンソースのセミナーがあれば、参加助成を積極的に行う、技能習得のための時間を業務として組み込む（大変難儀なのは重々承知の上で...）などの環境整備を進めることで、Webテクノロジーへの移行が加速されるのではないかと思います。

注1 多要素認証
認証の3要素である「知識情報」、「所持情報」、「生体情報」のうち、2つ以上を組み合わせて認証することを指します

注２ OAuth
複数のWebサービスを連携して動作させるために使われる仕組み