English Site

５．２．１　本実証により判明したこと

RWF統合プロファイルの実装については、株式会社日立メディコの考察が興味深い。一部に加筆し語彙等を修正の上報告する。

＜プロファイルの問題点＞

レポーティングシステムを導入している病院であれば、放射線科医は特定の検索条件（検査日：過去1週間、検査種別：CT、進捗：未読影 など）を指定し、読影対象のWorklist絞り込みを行い、表示されたワークリストに従い読影することが一般的な運用である。

しかし、RWF統合プロファイルに準拠したReport Creator上では、これら条件を指定した検索を行う術がない。

これは、Report ManagerとReport Creator間のQuery Reporting Worklistトランザクションに、日本の運用で一般的に使用している検索項目が定義されていないためである。

例えば、製品版のNatural-Reportと本事業で使用した実証用システム（RWF版Natural-Report）における、検索条件の比較を表５．１に示す。

また、検索結果のWorklist内容についても同様に情報不足が認められる。

放射線科医は、検査オーダに記載されている患者基本情報および検査依頼内容（検査種別、検査手技、検査目的、臨床経過など）を参照し、検査を依頼した医師の意図を把握した上で、撮影画像の読影を行う。

また、現在稼動中の多くのレポーティングシステムは、HIS/RISと接続することにより、これらの情報をオンラインで取得し、レポーティングシステムの端末上に表示している。

RWF統合プロファイルでは、Report ManagerはDSS/Order FillerからProcedure ScheduledおよびProcedure Updateのトランザクションを通して、患者情報および検査依頼情報を取得することができる。

しかし、Report ManagerとReport Creator間のQuery Reporting Worklistトランザクション（応答）では、これらの情報が規定されていないため、実際に放射線科医が読影を行うReport Creator上まで、必要十分な患者情報および検査依頼情報を表示することができない。

前例に従い、製品版のNatural-Reportと本事業で使用した実証用システム（RWF版Natural-Report）における、連携可能なオーダ情報（項目）の比較を、表５．２に示す。

この様に、現状のRWFで規定されている項目のみで、システム化を行ったとしても「Reporting Worklistの検索条件が不十分」、「読影時に必要となるオーダ情報を参照できない」などの理由により、検査依頼用紙等の意思伝達手段が別途必要になり、折角入れたシステムが使いづらいものとなってしまう可能性が示唆された。

５．２．２　本実証の考察

過去の事業において実装したSINR統合プロファイルに基づくレポーティングシステムでは、読影業務を機能単位（作成、参照、保存、管理）のアクタに細かく分解することで、他のアクタとの組合せの自由度を向上させていた。しかし、機能を分割したが故にReport Managerが、進捗管理のほとんどに関与する結果となり、日本におけるレポーティング・ワークフローを実現できない結果となった。（当施設でも臨床稼動には至らなかった。）

RWF統合プロファイルでは、レポート作成のための手順を、ユースケースに基づき規定しており、ワークフローとしての齟齬はないように思える。

しかし、ワークフロー自体に齟齬が無くとも、ワークフロー上必須となる情報連携のための手段が欠如していれば、レポートの作成に多大な労力が必要となりかねない。

本状況を、実装ベンダである日立メディコは、RIS（Radiology Information System）の実装を引用して、この様に考察している。
「RISにおいては、RISサーバとRISクライアントが、別アクタとして分解されていない。これにより、両者間の通信はメーカ独自に定義できるため、情報通信内容の自由度は高いと言える。」と。

つまり、レポーティングシステムにおいては、各アクタを分割する必要がなく、レポート関連アクタ以外との連携にのみIHE-Jガイドラインを採用すべきとの見解と取れる。本問題は、一医療機関の実装では解決できない問題を包含しており、IHE-J臨床企画委員会報告書ワークフローWGとJIRA読影レポート検討委員会の合同委員会である、読影レポート検討委員会に報告し、今後の方向性を検討することとする。

５．２．３　事業成果から期待される効果

RWFの実装実績を構築すると共に、IHE-JにおけるRWF統合プロファイル内の当該ユースケースが臨床現場でどの程度通用可能かの知見が得られたことで、今後の実装方針における先例となった。

本事業におけるRWF統合プロファイルの検討が、日本国内で稼動するレポーティングシステム実装の方向性に必ずや資するものと考えている。

放射線部門の最終結果（アウトプット）となる画像診断報告書（レポート）部分で、IHE-Jの統合環境が構築可能であることを示せたと考えている。

ただし同時に、多くのベンダの意見や臨床現場の使い勝手、そしてIHE-Jとして費用を投入しただけの効果が果たして存在するかなどについて、多くの意見をふまえた上で、IHE-Jの委員会がRWF統合プロファイルの実装方法について、再度検討を行うよう、本事業から報告したいと考えている。
（参考）日立メディコによる本事業への考察から

注意：以下の内容は、本事業に参加したベンダのコメントであり、現時点でIHE-J委員会の見解として、本方向性が示されたわけではない。

レポーティングシステムの実装としては、

1. Report ManagerとReport Creator / Report Reader(内部）間の通信をIHE準拠で実装するメリットはないため、独自仕様通信で行う。
2. Report ManagerとDSS/Order Filler間、Report ManagerとPerformed Procedure Step Manager間、Report ManagerとImage Manager / Image Archive間の通信は、IHE準拠のトランザクションとして実装する。
3. Report Repository（内部）とReport Creator / Report Reader(内部）間の通信をIHE準拠で実装するメリットはないため、独自仕様通信で行う。
4. Report Repository（外部）からDICOM DRオブジェクトを検索/取得できるように、Report Creator / Report Reader(内部）には、Query Reports、Retrieve Reportsのトランザクションを実装する。
5. Report Reader（外部）からDICOM DRオブジェクトの検索/取得に対応できるように、Repository（内部）には、Query Reports、Retrieve Reportsのトランザクションを実装する。

この様に、実運用に支障が発生しない範囲で、IHE-Jの一部トランザクションのみを実装することも選択肢としては考えられるが、本問題点はIHE-Jをより一般に普及させる上で大きな支障になる。一般的に普及しているレポートシステムでは、ワークリストの絞込み検索、患者情報および検査依頼情報の参照をサポートしており、あえてIHE-Jを利用するメリットは少ない。むしろIHE-Jにこだわったがために使い辛いシステムとなってしまう可能性が高いといえる。日本でRWF統合プロファイルを実用レベルで使用するためには、IHE Technical Frameworkの記載で不足しているこれらの内容を明確に定義し、一般に普及したレポートシステムと同等のレベルまで高めることが必須と考える。

« 前へ | 目次 | 次へ »