English Site

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

本事業では、放射線部門から発生するオブジェクト（画像と画像報告書：レポート）について、電子カルテからのWADOを利用した参照モデルを構築した。

本実証については、IHE-Jとして明確な仕様が確定していない部分が数多く存在したため、結果的に以下のような実装を拡張として施した。

（1） XDS-i自体が、施設間連携を目的とした枠組みとして、策定されており、日本国内の施設内に限定した電子カルテへのオブジェクト配信を想定していない。よって、ebXML等により規定されている、Registry等のアクタは、電子カルテ内のローカルな実装として今回のスコープに入れない。
（2） 現在のテクニカルフレームワークではOrder Placerとなる電子カルテへ、画像到着や読影終了を知らせるためのトランザクションがない。しかし、これらトランザクションの実装は、臨床現場においては必須要件である。本実装では、「オブジェクトが配信可能となった事（進捗状況）」を、Repositoryから電子カルテに連携するための、新トランザクションとして、DICOM側にGP-PPSを、HL7側にORU/ACKにて代用メッセージを採用した。
（3） 同様に、現在のテクニカルフレームワークではOrder Placerとなる電子カルテへ、WADOを用いた連携技術の核となる、オブジェクトのインスタンス（この場合URL）を通知するための、トランザクションがない。本実装では、先の新トランザクションにこの機能を盛り込むことで、オーダに由来した、オブジェクトの連携を実現している。
（4） 現在のWADOにおけるオブジェクトの呼び出し方としては、前述のようにオブジェクトのインスタンスを特定し、直接URLで連携する手法である。当然、対象オブジェクトはユニークなインスタンスを持った単一のオブジェクトに限定される。本手法では、レポートのように単一のオブジェクトで完結する場合は問題が起きないが、例えばCT検査画像のように、複数枚のオブジェクトから、一部を表示する場合、欲しい画像の特定が煩雑となり、臨床においては使いにくい。よって、単一のオブジェクトを呼び出す手法の他に、検査単位のURL連携を提案し、画像リストから、初めて最終のオブジェクトインスタンスを選択し、WADOとして連携する手法も併せて構築する。

この新しい仕様の策定については、ベンダと埼玉医科大学が十分な意見交換を行い、将来本技術が多くの方面で展開可能な様、IHE-Jガイドラインの概念から逸脱しない配慮を十分行いながら、内容を取り纏めたものではあるが、いかんせんIHE-Jのガイドラインとしては認められておらず、大部分がスコープ外である。

しかし、本事業としては、この拡張が必ずや標準化や相互運用性の役に立つと考え、本事業から、IHE-Jの臨床企画委員会（XDS-WG）に、本実装の状況を報告し、汎用性の高い技術として提案するものである。
（提案内容については、第Ⅳ編を参照のこと。）

明確な標準化を待たずに、この様な仕組みを実装する事への是非は存在すると思うが、本技術の実用化は、放射線部門のみならず、電子カルテにおける検査結果の集約的閲覧環境の構築と言う機能要件の一部として、広く利用可能と考えている。

５．３．２　本実証における新規トランザクションについて

今回、Order Placerへのメッセージ連携としてはDICOM側にGP-PPSを採用し、DICOM/HL7-Gatewayを間に挟むことで、HL7側にORU/ACKメッセージの連携を可能とすることで行われている。

本来画像到着に関するDICOM GP-PPSでの情報は、Order Fillerを介して返信することで、HL7に変換しOrder Placer側まで情報連携することが望ましい。

Order PlacerとHL7メッセージで情報連携できるアクタはADTアクタを除くとOrder Fillerに限定されることがその理由である。

今回は、Order Filler本体への実装を見送ったため、画像受信完了及び読影完了通知は、Order Fillerの望まれる機能を切り出して実装した、（仮想Order Filler となる）DICOM/HL7-Gatewayを介して行われている。

ただし、仮想Order FillerであるDICOM/HL7-GatewayとOrder Placer間のメッセージそのものについては、新規にHL7を拡張することなく、既存のORU/ACKで代用している。

ところが、ORU/ACKメッセージは、その構造上DICOMオブジェクトを特定するような情報が格納できない。

本事業ではこのORU/ACKメッセージを埼玉医科大学・富士通・コニカミノルタエムジー、日立メディコの四者で、十分な協議を行うことで、仕様的に拡張した。

結果的に、画像受信完了や読影完了通知が、電子カルテのデータベースに格納できる事となったが、本来の用途ではないため、今後に課題を残した。

ここで重要なのが拡張ORU/ACKメッセージが仮想Order FillerであるDICOM/HL7-Gatewayを１つでやり取りしている点である。１ポートで複数の情報をやり取りする以上、メッセージを区別する情報については、イベントタイプを新たに定義する必要がある。今回はORU/ACKメッセージR01イベントにて行っており、さらに区別するためにOBR-4の検査項目ID（本来のORU/ACKではJJ1017-16Pが格納される）に識別子「1000000000000000」を画像受信通知、識別子「0000000000000000」を読影完了通知とすることによって電子カルテデータベースの一意性を確保している。

本事業ではコニカミノルタエムジー、日立メディコの２社が関連ベンダとして電子カルテと前述の連携を行うこととなるため、識別子自体も上記の２つで済むが、院内に複数のオブジェクトを配信する機能（サーバやレポーティングシステム）が混在する環境化では、本機能のみの実装では不十分と考えられた。

５．３．３　本実証の考察

医療機関における臨床の要望として、検査結果の集約的閲覧環境の構築がある。臨床医は治療対象の患者様について、必要な時すぐに全ての情報（過去歴や主訴・検査結果や画像）を把握可能なシステムを欲している。

本来、医療機関内におけるこれらオブジェクトの配信は、電子カルテシステムが集約して行うか、各部門において専門のシステムが担当し、必要に応じて、結果を提供するかのどちらかが多い。

前者による構築の場合、必ずしも部門内の現場が欲しているような、専門性の高い部門システムが構築できない可能性が存在すると共に、電子カルテという全体の大きな検討課題の中に部門の要望が埋もれてしまいがちである。

後者による構築の場合、現場の望む、痒いところに手が届くような実装が実現可能であるが、部門システム毎に電子カルテとのインターフェースを構築したり連携仕様を策定したりする必要があり、「容易な情報連携の構築」とはいかないのが現状である。

WADOによるオブジェクトの連携は、その丁度中間的ソリューションを提供すると考えている。特に、オブジェクトの参照機能のみを提供すればよい場合に有効性が高く、電子カルテベンダに実装の負荷をかけることなく、枠組みとしては部門システムの拡張で連携技術は完了する。（ただし、電子カルテ側にデータベースを用意したり、URL連携の基となる実装を施す必要が、場合により存在することは明記しなくてはならい。）

５．３．４　連携するオブジェクトの形式について

技術的な面からもう少し、詳述する。

本事業ではOrder Placerから要求のあった、画像オブジェクト表示やレポートオブジェクト表示について、汎用的な技術であるMIMEタイプをText/HTMLとした、URL連携を行っている。本来WADOではapplication/dicomやapplication/pdfなどをはじめとする多くの形式がサポート可能である。しかし、Order Placer側ではapplication/dicomのような画像オブジェクトを表示できる機能を実装したがらない。Order Placerの使命として、連携が必要なオブジェクトは、放射線部門だけではなく、病院内の多くのオブジェクト（MFERに代表される波形データや、病理画像、検体検査結果など）全てと柔軟に連携しなくてはならない。これら連携において、全ての形式をサポートすることが、Order Placerの開発・実装において、必ずしも良い結果をもたらさないからである。

そこで本実証事業ではもっとも汎用的な技術としてTEXT/html形式にてWebブラウザを用いた表示のみを採用し、広く相互運用可能な条件で実証を行った。

なお、電子カルテシステムからの画像表示について、現状多いスタイルとして、専門ベンダのアプリケーションを独自にベンダ間の責任の範囲で組み込むことが一般的である。

画像表示のアプリケーションはJAVAやMicrosoftに特化したオブジェクトなどアプリケーションに固有の部分があり、十分なテストを経ない限りマルチベンダ環境下では、これを採用できない。またアプリケーションの組み込みについて画像のような巨大なオブジェクトを表示する場合は院内のインフラやクライアントの性能など十分に考慮する必要がある。

本事業で採用したTEXT/html形式のオブジェクトならば、汎用のWeb技術のみが存在すれば、システムに負荷をかけるというリスクを回避しながら、オブジェクトの参照が可能と考えた。

５．３．５　本事業におけるWADOの実装

XDS統合プロファイルは、IHEで施設間の連携を円滑に行う目的で普及が進められている、ITインフラストラクチャーの重要な概念である。

本事業では前述したように、まず医療機関「内」で、電子カルテから要求されるオブジェクトについて、同様のモデルとして捉えることにより、XDS統合プロファイルの考え方を、国内の施設内連携に利用可能と推察した。

ただし、医療機関内での実装で完結する場合、XDS統合プロファイルの実装で定義されているebXMLなど、医療に馴染みのない部分を新規に構築するのではなく、既存の電子カルテ内のデータベースに担当させ、連携の概念や枠組みのみを利用することで、容易な構築モデルとした。

本実装における具体的特徴としては、Document Repositoryを電子カルテ内に直接実装し、Imaging Document sourceやReport Repositoryに画像配信用のDICOM/Web変換機能を実装し、サーバとして配置することが重要であった。

具体的には、XDS統合プロファイルで規定された、各アクタについて、現在稼働中の病院情報システム部品で代替可能か検討し、ebXMLを用いずに実装するため、同連携部分をサブコンポーネント内に納めきれる（具体的には、電子カルテ内に完結する）仕組みを選択した。

オブジェクトの連携には、XDS-i統合プロファイルで規定された、WADO（Web Access to DICOM Persistent Objects）を用いることで、汎用性が高く軽快な動作が期待され、将来的な施設間連携技術にも応用可能な実装とした。

特に、当施設の電子カルテはWeb型と呼ばれるタイプであり、電子カルテサーバと電子カルテクライアント間は、専用線を用いたWeb技術で連携されている。電子カルテ側には、Webブラウザが用意され、各種情報が表示可能な環境を提供しており、WADO技術との親和性は非常に高いと予測したことも、本技術採用の一因である。

なお、画像に関する連携については、配信サーバ側が検査単位のURL連携時に、画像リストを提供する仕組みを実装した。

このことにより、検査内に収容されている多くの画像の中から、目的の画像を探しやすい環境の提供が可能と考えられた。

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

電子カルテにおいて、円滑で豊富な各種情報オブジェクトの参照機能は、臨床診断時における情報の量・質に直結するため、非常に重要な実装である。中でも、放射線領域で必須となる、画像とレポートの連携手法が標準化されれば、現在各施設においてバラバラな同部分の実装状況から、それぞれに発生している接続改造など、リソースの浪費が抑制され、相互運用可能なシステムの構築へ大きく前進するものと期待される。

さらに本技術は、放射線以外の領域で発生した同様のオブジェクトに対して、電子カルテ上で参照するための手段を共通の枠組みで提供可能で、特に各部門システムとの連携において、技術仕様の共通化など、幅広い横展開が大いに期待される。

また、XDSの枠組みでは、ドメイン毎に情報を交換可能な仕組みが提案されており、病・診連携や病・病連携等、地域規模での相互運用性に期待が集まっており、ebXMLを利用した、社会的IT基盤との方向性一致とあわせ、今後の発展が見込める領域である

« 前へ | 目次 | 次へ »