Part1では電子カルテ登場以降、FHIRが必要とされるに至った背景を解説してきました。
複数の医療機関で相互に活用できる医療データベース基盤がFHIRによって構築されたことで、FHIR活用は大きな期待を以てみられるようになりました。
Part2では各データ連携を可能としたFHIRへの期待を、診療データ流通と意思決定支援の観点から解説します。
大阪大学大学院医学系研究科
医療情報学 教授 松村泰志
Part 1 はこちらから→
診療データの流通への期待と FHIR
病院情報システムは、病院内のシステム化が目標でした。ところが、電子カルテシステムとして完成しますと、医療機関の外に向けて診療データを流通させるニーズがあることに気付かされます。
考えてみると、阪大病院でも、例えばがんの患者さんについては、他院で診断され、手術をするために阪大病院で入院治療を受けられますが、その後は、また、別の病院でフォローアップされることになります。この一連の記録を、通して見ることができる診療記録が欲しいところですが、現状では、各医療機関に分散して存在することになります。
既に、病院の電子カルテデータを、Web 技術で外部の医療機関から閲覧可能とする方式による地域医療連携システムが広まっています。現実的な良いソリューションだと思います。しかし、慢性疾患の場合で生涯の記録を作成したり、小児期の治療内容を成人してから参照するといったニーズに対しては、現状の地域医療連携システムでは対応できません。はやり Personal Health Record の導入も必要になってくると思います。
このように、大きな視点で見ると、日本では本当の意味での医療記録が無い状態であることに気付かされます。海外の進んだ国では、EHR・PHR が既に整備されており、国民の健康管理に役立てられていると聞きます。日本でも、これを実現させなければなりません。
EHR・PHR を実現させるにも、様々なレベルが考えられます。まずは、人が読めたら良いレベルで良いので実現させるべきと考えますが、欲を言えば、自動要約機能が欲しいところです。一人の患者といえども大量のデータが存在することになりますので、ページを切り変えるだけのビューでは全体像を把握することができません。
例えば、薬のデータについて、毎回の処方箋データが閲覧できるだけであれば、過去データは単に堆積するだけのデータとなります。このデータを編集して何時からどの薬を開始し、何時から量を変更したのかが、一目で分かるビューが作れると良いと思います。こうした気の利いたビューを作るためには、統一化されたデータ構造で標準コードが付いた形でデータを取得する必要があります。
標準規格への変換は、データ収集側では難しく、データ送付側で実行する必要があります。これについては何等かの標準規格であれば良く、HL7 version 2.5 形式でも問題はありません。現状の問題は、SS-MIX２ 標準化ストレージが導入されているとは言え、標準コードが振られていないものが多いことにあります。これではせっかくの標準化ストレージの意味が半減します。標準コードを振った形にしようとした場合、ストレージの考え方では全てのデータを作り直す必要があります。もし、一部にコードの間違があった場合、やはり全体を作り直すことになってしまいます。これに対し、API の考え方を取り入れますと、実体は電子カルテ本体のデータベースにありますので、そこに対してデータをリクエストした時にこの API がデータを変換することになります。この API はハウスコードと標準コードの対応テーブルを持つことになりますが、もし、一部に間違があったとしても、この対応テーブルを修正して、対象データだけを取得し直すことで対処できます。
ここでも、レガシーデータベースに対して、データ取得メソッドを定義し、FHIR 形式のデータをその戻り値とする FHIR の Web API を構築すれば良いということになります。この API が作成される範囲が広がるにつれ、EHR・PHR に細かな粒度で提供できるデータ種が増えることになります。
ちなみに、戻り値の形は、標準化されておれば良いので、version 2.5 でも良いのですが、データ交換する場合にはバリデーションが必要であり、そのためには、XML か JSON の形式が対応しやすくなります。リソースのデータをそのままデータベースのフィールド値として保存するのであれば、XML より JSON の方が、データ量が小さくなるメリットがあります。RESTful の Web API が利用できると、簡単にデータの受け渡しができるようになるはずです。
FHIR は、最新の優れた考え方を取り入れた分かりやすい規格になっていると思います。
意思決定支援システムへの期待と FHIR
最後に意思決定支援システムへの期待について簡単に述べさせて頂きます。
これからの電子カルテのテーマは、医療の質・安全の向上への貢献です。医師に対して、医師が見逃している問題を指摘して確認させるような機能が登場してくると思います。こうした高度の意思決定支援システムの場合、その判断ロジックを記録した知識ベースが必要になりますが、これを各病院で作ることは非効率です。どこかのセンターで作って配布することになるはずです。その時に、この知識に記載されている医療データのコード体系と、それぞれの電子カルテ内で使われているデータのコード体系がマッチしなければ機能しません。
ここでも、FHIR の Web API があって、コードの標準化に対応した形でデータを取得できるようになれば、外から標準コード体系で記録された知識ベースを取り込むことが可能となります。
意思決定支援システムでは、患者の状態を表すデータが必要になりますが、検体検査結果データだけではかなり寂しいことになります。テンプレートで収集したデータや自然言語処理した後の構造化データに対して標準コードが必要となります。そのためには、日本語語彙のシソーラス体系を構築する必要があります。
意思決定支援システムについては、FHIR 化もさることながら、日本の医療用語のシソーラス体系の構築という大きな課題が待ち受けています。
