English Site

第二回の実装検証委員会は、平成18年2月27日（稼動検査前日）に埼玉医科大学において行われた。

稼動検査項目が正しく実装されているか、第一回の問題点が解決されているか等の視察後、再度忌憚の無き意見を自由発言で賜った。
（なお、発言の順番と収載順は、異なる場合がある。収載順は、氏名のアイウエオ順である。また、各委員の発言時間に、委員以外が発言した場合は、発言者を明記して、区別しているので注意されたし。文中の敬称は略させて頂きました。）

（１）安藤　　裕委員

 臨床面における実装は特に問題ない。WADOの技術に興味がある。今後どの様に使われていくか、WADOの枠組みで何が出来るか。
 困った過程や対応したかったが困難だったなど、もっと具体的な側面を見せないとユーザにはWADOといっても興味がわかない。ユーザがWADOでやろうと言っても距離がある。（埼玉医科大学）
 ARI統合プロファイルの一部をWADOで実装しても良いのではないかと考えている。また、Report ReaderでもWADOが使えるのではないかと思う。この様な、提案をしていくことが大切である。
 我々もReport Readerの機能として、電子カルテ上に実装するならば、十分利用可能だと考えている。特に電子カルテでは、インスタンスが確定するので、URL連携で十分である。ただし、放射線部門内については、大量のレポートを扱う必要上、検索や絞り込みなどの機能がなければ、そのままでは利用出来ないと考えている。（埼玉医科大学）
 参照表示サーバにおけるフォーマットの設計概念はどの様なものか。

（埼玉医科大学注：WADOのフォーマットについて実装したコニカミノルタエムジー株式会社、野村氏から回答させて頂くこととなりました。）

 PACSは、受信した画像をDICOMフォーマットで格納している。参照サーバには、PACSから選ばれた画像が転送される設計である。この場合、参照サーバにはどの様なフォーマットで格納されるのか。
 オリジナルをJPEGとして保管する。また、サムネイル用にJPEG2000フォーマットも併用される。配信サーバ上のデータは、非可逆圧縮したDICOMフォーマットになることが想定されている。（コニカミノルタエムジー）
 使用しているJPEGフォーマットは、ベースラインではなくExtendフォーマットで行っているので、画像のWW/WLを変更することは可能か？
 はい、可能です。（コニカミノルタエムジー）
 WW/WLを指定して、電子カルテから、再度呼び出すことは可能か。
 ユースケースとして、臨床側がWW/WLを変えないということを前提に設計しているため、WW/WLをあらかじめ合わせたデータを配信するという構想である。この部分は、IHE-Jと言うより、施設の運用となる。（埼玉医科大学）
 配信側のディスク容量が無駄にならないか。
 古いデータから消えてしまう設計としているので、残存期間との兼ね合いとなる。基本的に問題としていない。（埼玉医科大学）
 本事業で先ほど連携していた画像のフォーマットは何か？
 本事業では、JPEGフォーマットのみを提供している。（コニカミノルタエムジー）
 なぜ、DICOMとしないのか。
 電子カルテベンダにDICOMをサポートする、表示用の汎用アプリケーションを開発させることは、本質ではないと考えた。よって、今回は、JPEGのみが単純に連携出来ればよいとの要求仕様である。（埼玉医科大学）

（埼玉医科大学注：実証事業における要求仕様以外の実装については、不明なため、日立メディコの鈴木氏から、回答させて頂くこととなりました。）

 レポーティングシステムが今実装している方法は、非DICOMのデータベースに管理されたDICOM-SRフォーマットがあって、外部とDICOMにて連携する場合は、DICOM-SRのフォーマットを用いるという方式と、データベース自体がDICOM-SRのフォーマットを持っていて、WADOでの連携時にHTMLフォーマットに変換して連携する方式が考えられるが、どちらか。
 前者である。この選択には、実装のし易さが関係している。（日立メディコ）
 DICOMが定義しているSRの神髄は、階層化された構造化されたレポートからHTMLを変換して出力可能なことだと思うが、かなり負荷になるのか。

 選定という問題がある。連携としてどの情報を利用するかによって、画面の見せ方やフォーマットを考えなくてはならない。それを考えると、自分のDICOMフォーマットをそのまま出した方が良い。DICOMオブジェクトは受けられるが、複雑なレポートが来たらHTML化できない。受け取れるが利用出来ないという意味となる。他からオブジェクトで呼ぶというのは、今回やっていない。（日立メディコ）
 エビデンスを入れるような項目は無いのか。外部から取得したDICOM-SRを解釈して変換して出せるか。
 レポートのユーザインタフェースについては、今回の目的ではいらないだろうということで、特に表示していない。SINRというのは、技師がはき出したエビデンスを先生が見ることが前提と考えている。（日立メディコ）

（２）石垣　武男委員

 連携としてはうまく動いていた。
 埼玉医大が工夫したところとIHE-Jを指定しただけで可能であった部分を、正確に報告して欲しい。

（３）江本　　豊委員

 実証事業と言うことでちゃんと使える部分まで持ってきた成果は大きいと思う。
 ただその中で、実装してIHE-Jとして入れているのはこの部分ですよ。という提示と、実装するために工夫したところはこの部分ですよという提示を分けたうえで解りやすく公開してもらえれば、見学に来て、埼玉医科大学でIHE-Jを指定することで出来た部分と、サイト（埼玉医科大学側）で検討して指定した部分が判ることになる。できればそのようにして頂きたい。
 実際に導入したい施設が見学に来た時、それが有効であると感じた。かなり苦労しているところもあるなと。これを広くIHE-Jを導入したい人に広報することが、大切だと考えられる。

（４）小野木雄三委員

 WADOは確かにいいかと思いますが、要はどの様な情報にアクセスしたいのか、呼び出し方法を定めれば、それだけで本当にいいのかということですが、DICOMにするとか、これからどういう場面でどの様な情報の呼び出しに使えるかという観点からも検討願えればと思います。
 現実にもうIHE-Jへの対応が出来ているパッケージが、数多く出てきているので、それで出来ていない部分をカバーするための実装を行おうとすると、新しいものを入れていきたい・作りたいと表明する人たちが活躍する場面ももうしばらくはあると思うが、あっという間にそれはなくなってくると思う。
 それは、標準化によるものか、競合するものが広がるのか？（江本委員）
 それは、標準化であろう。むしろ、臨床工学（臨床の要望）をもう少し整理して頂いて、今はカルテだけの検討ですが、データマイニング等の技術に応用出来ないかなど、広く検討して欲しい。
 データ蓄積のデータベース等は、画像には全く応用出来ていない。URLのみで画像が出せるなら、非常に有用と考えられる。（江本委員）
 確かに、何のために電子化を行っているかを考えないといけないだろう。データ連携のための実装を、行っているわけではないことを忘れずに進めたい。（埼玉医科大学）

（５）細羽　　実委員

 WADOを使いながら好きなフォーマットを実装出来ればさらによい。実際には、もっと多くのフォーマットをサポート出来るのでは？
 WADOはMIME/Typeで連携フォーマットがきまる。帰りの部分がMIME/Typeとなる。実際は申し合わせが先なので、いきなり知らないものと繋ぐことはない。今回は富士通さんと申し合わせでこれを連携させると言うことで実装している。タイプが何でも出来ないといけないと言うことはない。（コニカミノルタエムジー）
 XDSはどの様な要求にも応えられるわけではない。これしかとれないと宣言する。ネゴシエーションありきである。
 XDSは院内なら連携するフォーマットが決まっているから問題ないが、広くは枠組み内（ドメイン内）で、どの連携を行うか調整する。→やはり、事前調整が必要。（埼玉医科大学）
 PDIを用いて外部の施設で画像を撮影し、持ち帰って登録できるような統合プロファイルの応用は、大変面白いと思う。患者データの確認方法を統合プロファイルとして提案されたら良いのではないか。Portable Media Importerに患者オーダが飛んで来ているところが興味深い。
 ITインフラストラクチャーと合わせることで、更に良くなるのではないか。統合する時に、患者情報を間違わない仕組みを考えるべきである。具体的には、名前を合わせる等の工夫が必要である。
 PID統合プロファイルを臨床採用する上で、運用上の問題点が存在することが、判明している。それは、（1）ウイルス対策と、（2）属性を更新する時に、別人のORMメッセージと間違わないような工夫を必要としている点である。（埼玉医科大学）
 患者属性のチェックを、持参したもので行うなどの対応が必要と考えられる。患者IDのすりあわせは、ユースケース上無理であろう。（埼玉医科大学）
 もう一つ、異なるソリューションを行ってはどうか。将来的には、CD-R本体に画像診断の報告書を入れるとか、診療情報提供書を入れる等が考えられる。

（６）森村　晋哉委員

 レポートワークフローに関して、アクタを立ち上げ直すのは、煩雑だとかんじていたが、今回は修正されていた。
 前回、GSPS付きのシナリオであったが、今回はやらないのか。
 稼動試験の項目として表記されていないので、時間の関係もあり、今回は割愛したが、画像とGSPSがPDIにて連携可能な環境を構築している。（埼玉医科大学）
 レポートの部分として、TEXT/HTML連携を実装しているが、ニュ−メリックなレポートも配信可能か。SINRを変換する事が可能な実装はしたのか。もしそれが可能なら超音波やエビデンス・ドキュメントの連携が可能なHTMLとなり、汎用性が上がると思われる。
 DICOM-SR形式のレポートとして、拡張部分が何処まで出来ているか。また、レポートから変換可能なフォーマットは、テキストだけか。
 超音波のレポートとしてどの程度利用可能か。

（埼玉医科大学注：実証事業における要求仕様以上の実装については、不明なため、日立メディコの鈴木氏から、回答させて頂くこととなりました。）

 配信可能なフォーマット（変換可能な）はテキストだけか。
 変換して出すためのフォーマットは、現在TEXT/HTMLのみである。レポートは、レポジトリはDICOM-SR環境で管理。ただし、内部処理として、データベースは独自の実装となっており、WADOを呼び出すための実装は、独自DBから起こすことになっている。その部分はDICOMではない。（日立メディコ）
 他のオブジェクト付きのレポートが送られてきたら、受けられないのか。（細羽委員）
 DICOM-SR形式として、受けることは可能であるが、その情報を画面に出したり、運用することはできない。（日立メディコ）
 CPI統合プロファイルの実装について、WADO環境下でも可能か。
 WADOの環境を利用する、.NET（埼玉医科大学注：コニカミノルタエムジー社のI-PACSシステムに使用される基本技術）上でのGSPS適用は問題ない。ただ、GSDFのキャリブレーションが出来ない。電子カルテ用の汎用モニタではその環境がない。CPIが役に立つのは、1M以上の診断モニタが撒かれる環境が整ってからかも知れない。GSPS適用のニーズはかすかに見えるが、GSPS保存のワークフローが見えてこない。（埼玉医科大学）

（７）埼玉医科大学から（今後について）

 PDI統合プロファイルは、臨床での病診連携ユースケースが確定している。しかるべき時期には本系に移行し、臨床稼動を開始する。
 JJ1017を用いたSWF統合プロファイルにおける、モダリティ連携は、モダリティが元々本系にしか無いため、初めから本系に実装した。
 レポートは従来の枠組みに戻す。ユースケースが3と7のみの対応であり、イレギュラーなケースや柔軟なレポートワークフローに対応するのは、まだ無理があると考えているからである。今後、RWF統合プロファイルの検討が完了した時に、再度当施設のワークフローとの適合を検討し、可能ならば移行について考えるというスタイルである。
 WADOについては、臨床的要望の高い「画像を選ぶ仕組み」を導入し、軽快で、汎用性の高い連携が可能な点など、いいところだけを部分的に採用し臨床応用するつもりである。
 本事業全体から考えて、特に顕著なのは、何か新しい実装を行うにしても、過去に構築した情報連携による、太い屋台骨が既に出来ていて、追加実装等の連携が行いやすい点が、今回の拡張で非常に役に立った。この傾向は、本事業に限らず、何をするにしても何でもしやすいと考えている。特にORM等の情報が、電子カルテ側から既に来ているため、はぐれそうな情報まで、統合しやすい。（埼玉医科大学）

« 前へ | 目次 | 次へ »