English Site

２．１　画像・レポートの電子カルテ配信連携技術における標準化への提案

埼玉医科大学で実施された経済産業省の実証事業では、XDS-i統合プロファイルに規定された、施設間での画像（オブジェクト）連携手法の一部である、WADO技術を、施設内の電子カルテを用いたオブジェクト連携（画像・レポートの配信）として採用し、独自に提案された拡張を用いて、臨床の要望を満たす仕様としている。

埼玉医大が独自に提案するソリューションは、以下の通りであるが、本技術を国内で広く応用可能とするためには、拡張部分の標準化が必要となる。

本事業の担当者としては、本技術が高い汎用性を持つことから、臨床現場の要求に応えられるだけの拡張を実現することで、国内における電子カルテの機能向上に資するものと考えており、標準化の実現を切に願うものである。

なお、本提案は臨床企画委員会のXDS統合プロファイルを検討するワーキング・グループ委員長である、京都医療技術短期大学の細羽教授に提出済みである。

以下は、本事業により埼玉コンソーシアムが採用した拡張とその考察である。

２．１．１　オブジェクトの到着を電子カルテに連携する機能

（1） DICOM/HL7を変換するGateway機能。（仮想Order Filler相当）
（2） 画像サーバに画像が到着したことを電子カルテに知らせる仕組み
（3） レポーティングシステムから、レポートが完了（Verification）したことを電子カルテに知らせる仕組み。

【今回の実装】

今回の実証事業では、Order Fillerへの独自拡張は行わず、拡張に相当する特定の機能のみを分離し、「仮想Order Filler（DICOM/HL7-Gateway）」として構築することで、画像やレポートのステータスを、電子カルテに連携した。
仮想Order Fillerの機能としては、DICOMのGP-PPS（N-Create、N-Set）を受信し、HL7のORU/ACKを発行する事にある。今回はORU/ACKメッセージについて、R01イベントにて、OBR-4の検査項目ID（本来のORU/ACKではJJ1017-16Pが格納される）に識別子を入れ、この値を通知することにより、電子カルテデータベースに、オブジェクトの進捗ステータスフラグを変更するような連携を実装・構築した。

【問題点】

現在のIHE-JガイドラインにおけるSWF統合プロファイルには、この配信予定オブジェクトの進捗を連携するための受け皿が存在しない。（Order Fillerの機能としての規定もない。）
また、今回利用したHL7メッセージは、本来別の目的に利用されるべきフィールドで、オブジェクトの種別定義が確立されていない。（もともと転用なのでしかたがない？）

【標準化されるべきポイント】

本ケース（本手法が最適かどうかの議論は別途必要であるが。）では、SWFとしてOrder Filler・Image Managerに、RWFとしてReport Repository（Report Manager）に、以下の様な実装が定義されることが望ましい。
ア、 IM/IAは、画像到着時に「RAD-49 Instance Availability Notification（DICOM-IAN）」トランザクションをOrder Fillerに向けて発行する。
イ、 Order Fillerは、IM/IAから「RAD-49 Instance Availability Notification（DICOM-IAN）」トランザクションを受けた場合、電子カルテに対し、特定のHL7電文を発行する。
ウ、 Report Repository（現状のRWFにおける定義の場合は、Report Manager）は、レポート確定時（Report Repositoryでのレポート保存時か、Report Managerでのレポート確定操作時）に「RAD-42 Performed Work Status Update（DICOM GP-PPS）」トランザクションをOrder Fillerに向けて発行する。
エ、 Order Fillerは、Report Repository（現状のRWFにおける定義の場合は、Report Manager）から「RAD-42 Performed Work Status Update（DICOM GP-PPS）」トランザクションを受けた場合、電子カルテに対し、特定のHL7電文を発行する。
オ、 Order Fillerが発行するHL7の電文は、「RAD-xx実施情報通知（HL7 ORU）」相当と予測されるが、現在のOrder Filler→Order Placer連携（ステータスの連携）では、不十分であるため、以下のバリエーションから標準化を策定する必要がある。
(ア) 新規に、必要な情報連携メッセージのセット（トランザクション）を策定する。
(イ) 既存のメッセージ連携で、臨床上必要なステータス連携の仕組みを標準化（フィールドの拡張追加）する。
(ウ) 既存メッセージ連携のどこか（フィールド等）に、同情報を埋め込む手法（既存フィールドの何処にどの様な形で値を埋め込むかのやり方）を標準化する。
カ、 HL7のメッセージ交換においては、DICOMのオブジェクト種別を特定/連携可能な手法（どのオブジェクトから戻った値なのか）を確立するために、メッセージを区別する情報として、イベントタイプを新たに定義する必要がある。

２．１．２　オブジェクトのインスタンスを電子カルテに連携する機能

（1） 画像やレポートなど、WADOにより取得したいオブジェクトの、URL（httpリクエスト）を電子カルテに知らせる仕組み。
【今回の実装】
今回の実証事業では、それぞれDICOMをサポートするシステム側が、内部ロジックを用いて、元来ORMとしてOrder Fillerから連携した、患者名・患者ID・患者誕生日・患者性別・受付番号・オーダ番号と、オブジェクトの呼び出しに必要なStudy Instance UIDを、N-Create時に「仮想Order Filler（DICOM/HL7-Gateway）」に伝達している。
さらに「仮想Order Filler（DICOM/HL7-Gateway）」は、N-Set時のPPS-IDを検索キーとして、各種値をORUに展開し、HL7メッセージに変換することで、電子カルテへの連携を実現している。

【問題点】

現在のWADOにおける実装手法としては、電子カルテにおいて指定したURLを直接のトリガとして、対象アクタからオブジェクト取得し表示するやり方が、規定されている。
ただ、この実装を臨床利用するためには、電子カルテが必要なオブジェクトを呼び出すためのURLを、オーダを基準としたオーダ内のイベントタイプ毎に電子カルテ側で全て把握している必要がある。言い換えれば、オーダ毎・イベントタイプ毎にオブジェクトを配信するアクタから、電子カルテに通知する仕組みが必要と考えられる。
またこの連携は、想定されるURLを事前に取得するような仕組みだと、途中の想定外の入れ替えに対応出来なかったり、オブジェクトそのものの到着とタイミングがずれたりして、実用に耐えられないため、オブジェクトの到着後にその都度通知されることが望ましい。

【標準化されるべきポイント】

理想的には、Order Fillerが本機能を受け持ち、ORM由来で電子カルテから連携された数々の値から、利用アクタとの調整により、必要な粒度で絞り込みを行い、電子カルテ側の情報を特定した上で、Order Filler上でオブジェクトのUID（オブジェクトのUID連携については、前述のDICOMトランザクションを利用することを想定している。）と結びつけ、HL7のしかるべきフィールドに、必要な連携情報（URL）を返す仕組みが標準化されれば、本仕様が国内の多くの医療機関で利用可能となると考えられる。
よって、標準化が望まれる項目としては、Order FillerにおけるUIDとの結びつけ（利用アクタとの連携）手法や、HL7におけるURL通知の規格そのものである。

２．１．３　オブジェクト（主に画像等）を検索可能なリストの提供機能

（1） 複数のオブジェクト集合（Study単位やSeries単位）をとりまとめ表記可能な、リストオブジェクトの作成機能をサービス提供側に実装し、リストの表示単位（今回の実証事業ではStudy単位）であるStudy UID/Series UIDに由来したURLリクエストが可能な仕組み。（WADOの概念として、オブジェクトを特定してリクエストをかけるのに対し、臨床的要求としては、画像が選択可能な環境の実現が重要である。）

【今回の実装】

今回の実証事業では、WADOの概念通りSOPインスタンスUID由来のURLを直接トリガとすることで、電子カルテ側の機能として用意された、Webブラウザ（IE：インターネット・エクスプローラー）に、画像を表示する連携を実現（正にWADOの概念そのもの）しているが、その他に、StudyインスタンスUIDを連携し、Image Manager側で用意したリスト機能と連携させることで、まず始めにリストを連携（リストはDICOMオブジェクトではないので、単なるURL連携となる）し、リスト上の画像番号を選択することで、WADOが起動する仕組みも実現している。

【問題点】

現在の規格では、全ての画像におけるSOPインタンスUIDに由来するURLを電子カルテが保持し、それぞれの画像毎に、単純なURL連携を行うことが定められているに過ぎない。
これでは、次のような問題が発生する。
ア、 電子カルテ側が全てのSOP由来URLを把握しなくてはならず、オーダとの結びつけ（オーダ1に対し、画像数百）に問題が起きる。
イ、 オーダが完結した後に発生した画像のインスタンスを電子カルテが把握出来なくてはならない。（後処理や追加撮影等）
ウ、 画像1枚を表示する毎に電子カルテを操作することは、臨床の要望と合わない上頻繁なトランザクションが発生し、負荷的にも問題がある。
前述のように本事業では、Study単位で画像リストを作成する手法を採用しているが、Study Instance UIDを基準とした実装は、WADOとしてもIHE-Jとしても定義されていない。また、そもそもWADOには、画像の括りである、シリーズやスタディのインスタンスを受け渡す方法が存在しない。

しかし、オブジェクトの種類として、レポートのように一画面完結型のオブジェクト表示なら、この仕組みで十分と考えられるが、何十枚もある画像セットの一部（一枚）を表示したい場合は、表示後に完結せずに他の画面を続けて呼び出す仕組み等が必要となる。

本技術を病院内で汎用オブジェクト連係に利用する場合、この仕組みのないことが、普及に向けた深刻な阻害要因となることが想定される。

【標準化されるべきポイント】

現在のオブジェクト単位（SOPインスタンスUID由来）の連携手法だけでなく、オブジェクト単位（SOPインスタンスUID由来）の連携を前提とした、リストやアプリケーションの連携が可能な標準的技術や取り決めが提示されれば、本実装（WADO）は、普及に向けて大きく前進するものと考えた。
なお、このアプリケーション呼び出し部分の標準化が実現されれば、WADOを用いない電子カルテ側のオブジェクト呼び出しに関する実装も標準化されることとなり、相互運用性の観点から非常に望ましいと考えられる。
電子カルテベンダは、画像を初めとするオブジェクト連携の実装部分で、多くのインターフェース再構築を余儀なくされているが、この作業が不要となる。
オブジェクト提供側の各ベンダは、インターフェースが標準化されたことにより、WADOはもとより、自社のアプリケーションも自由に呼び出せることで、この部分のインターフェース開発に、リソースを取られる心配が無くなるため、電子カルテへの組み込み（連携）が容易となる。
利用者側も電子カルテの機能向上（容易な画像表示の追加）時やオブジェクト提供システムの入れ替え時に、インターフェースの再構築という余分な作業が必要なくなり、医療の質の向上という恩恵に浴せる。

２．１．４　埼玉医大が実装したWADO連携時のトリガURLの一例

本事業において、埼玉医科大学総合医療センターの実証システムが、稼動試験時に実際に連携するために使用した、URLを示す。

この場合、純粋なWADO連携を行うためのURLは、（2）のオブジェクトを直接指定する手法となる。

（1）、http Request（Study指定の場合）–http://192.168.193.31:8080/WADO/app?requestType=WADO&patientID=5012344555&studyUID=1.392.2000.6.7.555

（2）、http Request（Object指定の場合）
–http://192.168.193.31:8080/WADO/app?requestType=WADO&patientID=5012344555&studyUID=
1.392.2000.6.7.555&seriesUID=1.392.2000.6.7.555.1&objectUID=1.392.2000.6.7.555.1.5440303

２．１．５　埼玉医大におけるWADOのワークフロー（画像配信モデル）

本事業において、埼玉医科大学総合医療センターの実証システムが、稼動試験時に実際に連携するために構築したトランザクションを示す。

（注意）
ADTからのPatient Registrationは、埼玉医大の場合採用していない。
Modality Worklist Providedは、実装していないモダリティも存在するため、Image Manager上で、マッチング処理により、受付番号を連携している場合がある。

« 前へ | 目次 | 次へ »