Integrating the Healthcare Enterprise
IHE 放射線：
ユーザハンドブック
2005 年版
2005 年 6 月 20 日
Copyright Ⓒ 2005: ACC/HIMSS/RSNA
IHE 放射線ユーザハンドブック
管理者向けの要約
医療連携のための情報統合化プロジェクト (IHE)は、American College of Cardiology (ACC)、
Healthcare Information and Management Systems Society (HIMSS)、Radiological Society of
North America (RSNA)、を含む医療提供者と医療機器ベンダが、患者ケアを支えるために、情
報システムが交信する方法を改善するための構想です。IHE は統合プロファイルを定義し、そ
の統合プロイファイルは、確立したデータ規格を用いてシステムを統合し、システム間の相互
運用を効果的に行い、ワークフローを能率よく働かせることを目標としています。IHE は電子
カルテ時代に求められている統合レベルの高度化を達成することを可能にします。
統合プロファイルの概要
各 IHE 統合プロファイルでは、システム統合のための臨床上の要求事項と、それに対応する
ソリューションについて説明しています。IHE では、医用画像と通信（DICOM）およびヘル
スレベル 7（HL7）などの規格を基盤として、各アクタが実施しなければならないトランザク
ションを注意深く詳細に規定して、IHE アクタと呼ばれる機能上のコンポーネントを定義して
います。
IHE 統合プロファイルの取得方法
購入またはアップグレードしようとしている情報システム（医用画像保管通信システム（PACS）
、放射
線部門システム（RIS）
、撮影装置やワークステーションなど）に必要な IHE 機能を指定します。RFP
には、どの IHE アクタと統合プロファイルが必要かを記載しています。
統合プロファイルにかかるコスト
統合プロファイルによってはコストが全くかからない場合もあります―統合プロファイルが
製品の機能に組み込まれているからです。また、ベンダが、新しいシステムに IHE 統合プロ
ファイルを追加コストを加えて一括パッケージとする場合や、既存のシステムへのアップグレ
ードとして提供する場合もあります。大抵の場合 IHE 統合プロファイルはシステムの全コス
トの中でほんの小さな部分しか占めないほうがよいでしょう。
統合プロファイル実装の投資対効果
統合プロファイルは、医療行為を効率よく行うのに必要な統合情報システムの配置を能率的に管理す
ることを可能にします。逆に、機関ごとにインターフェースを作成するという方法は費用がかかる上
に、既存のシステムを変更しない限り、こうした個別のインターフェースのメンテナンスも必要です。
IHE を通した統合により、初期費用が削減され、機能性が向上するだけでなく、今後の製品取得も容
易になります。統合プロファイルは、さまざまな標準規格に基づいた情報システム統合の方法を明確
に定義しています。
その他の IHE のメリット
IHE によって医療機関は先端情報技術を利用でき、医療の質と効率を向上させることが可能と
なります。IHE を通じて医療情報の統合を進めることで、患者の安全性も向上します。さらに
データ紛失や検査結果の不一致などの問題解消にかける時間が減ることで、職員は効率よく時
間を利用できるようになります。医療機関は包括的な患者情報に基づき医療上の決定を行るよ
うになります。
では何をすべきか？
放射線部門やその他のIHE統合プロファイルを読み、各医療機関の目的達成のためのIHE導入
方法を検討します。本書（IHE放射線ユーザハンドブック）を読み、IHE適合製品のRFP作成
方法やシステム導入方法を理解します。上記資料およびその他の資料はインターネット
（www.ihe.net）で閲覧可能です。
2005 年 6 月 20 日
i
IHE 放射線ユーザハンドブック
執筆貢献者
編集者：Kevin O’Donnell
著者：
Ellie Avraham, 大規模 PACS 計画
Frederick Barton, 大規模 PACS 計画
Christoph Dickmann, PACS 据付け
Sanjay Jain,RIS 計画
Tory Legget, RIS 計画
Cindy Levy, システム動作確認
Cor Loef, モダリティ据付け、統合方法
Paul Nagy, RFPs（提案要求書）,2009/02/03 システム動作確認
Kevin O’Donnell, モダリティ計画、附属書
John Pagannini, 計量評価関係附属書
Tony Palmer, ＲIS 据付け
Paul Seifert, PACS 据付け
Niki Wirsz, 小規模 PACS 計画
2005 年 6 月 20 日
ii
IHE 放射線ユーザハンドブック
このハンドブックの使い方
医療機関で IHE 実装の経験をもつ医療分野専門家から情報提供を受けて、IHE 放射線企画技
術委員会により編集され、この IHE 放射線システム配備のためのハンドブックは、IHE 機能
をもつシステムを取得し実装して行く方法やその理由を述べています。
IHE は、医療システムを統合するという複雑で入り組んだ手間のかかる作業を、より簡単に、より
早く、より信頼性高くものにするように設計されました。このハンドブックは、IHE をどのように
利用したら、既存のシステムの選択、規定、購入および展開する方法を改善できるかを説明してい
ます。各章には、次のような典型的なシナリオが収められています：新しいモダリティの購入と展
開、医用画像保管通信システム(PACS)の購入と展開、放射線部門システム（RIS）のアップグレー
ド。各々のシナリオで概説している考え方は、IHE で定義されているトランザクションを用いたシ
ステムの統合が係わるシステム取得や展開プロジェクトすべてにも適用できます。
各々のシナリオには、新システムの選択と購入に携わる方々や新システムの導入および構成の
担当者への助言も含まれます。一連の附属書には、各シナリオに適用される助言や情報が記載
されていますが、また IHE トランザクションを通して接続されるシステムならばどんな場合
でも適用されます。
各章／シナリオには、以下のセクションがあります：
セクション X.1.1 および X.1.2：各プロファイルが提供するメリットに目標やニーズをマッピ
ングして IHE 統合プロファイルを選択する。
セクション X.1.3：望むプロファイルを得られるように RFP を書き込む（幾つかの推奨プロフ
ァイルのためのサンプル文章を含む）。
セクション X.1.4 および X.1.5：適切な製品を特定し評価する。
セクション X.2.1：IHE プロファイルのメリットを最大に引き出せるようなワークフローの変更。
セクション X.2.2：IHE 機能が適切に作動することを確認するための据付テスト。
セクション X.2.3：IHE 適合システムの導入、設定時に検討すべき問題点。
セクション X.2.4：既存システムの「取扱いに関する」問題があったとしても、メリットを最
大限生かすために問題点を特定し対処する。
本書は、標準規格に基づく効率よい情報交換が可能な放射線システムを展開し、病院での重要
業務におけるニーズに応えるため、IHE の構想で開発されたツールの利用法に関する指針を提
供します。病院での利用の効率性や適合性を決定するその他の多くの要素については考慮しま
せん。したがって、IHE が提供するツールは、IHE システムの選択、購入、展開、グレード
アップに必要なリソースとして欠かせないものではあるが、リソース全体の一部を占めるに過
ぎないことに留意してください。
注：本書はIHE放射線ユーザハンドブックの第一版です。将来版は内容を拡張し強化する予定
です。最新版は常にwww.ihe.netで入手可能です。
本ハンドブックは医療環境のニーズに応えることを目的としています。コメントや提案を歓迎
しています。電子メールでihe@rsna.orgへ送信頂くか、オンラインでhttp://forum.rsna.orgへ
お寄せ下さい。
2005 年 6 月 20 日
iii
IHE 放射線ユーザハンドブック
目次
管理者向けの要約 ............................................................................................................................ i
執筆貢献者 ...................................................................................................................................... ii
このハンドブックの使い方 ............................................................................................................ iii
目次 ................................................................................................................................................ 1
用語集 ............................................................................................................................................. 3
1.
シナリオ：モダリティの購入................................................................................................... 5
1.1.
1.1.1.
組織目標と統合プロファイル ..................................................................................... 9
1.1.2.
IHE 統合プロファイルとアクタを選択する ............................................................... 9
1.1.3.
あなたの RFP（要求仕様書）に統合要求事項を盛り込む........................................ 10
1.1.4.
適切な製品を選択する .............................................................................................. 10
1.1.5.
ベンダからの統合宣言書を理解する ......................................................................... 10
1.2.
2.
購入計画と購入プロセス ................................................................................................... 5
システムの全体構成と実装プロセス ............................................................................... 10
1.2.1.
あなたのワークフローの変更を検討する .................................................................. 11
1.2.2.
システムの作動を確認する ....................................................................................... 14
1.2.3.
導入問題を検討する .................................................................................................. 15
1.2.4.
“遺産”システム問題の摘出と対応 ......................................................................... 19
シナリオ：RIS のアップグレード ......................................................................................... 19
2.1 購入計画と購入プロセス .................................................................................................. 19
2.1.1.
組織目標の達成 ......................................................................................................... 21
2.1.2.
IHE 統合プロファイルとアクタを選択する ............................................................. 22
2.1.3.
あなたの RFP に統合要求事項を盛り込む ................................................................ 22
2.1.4.
適切な製品を選択する .............................................................................................. 22
2.1.5 ベンダからの統合宣言書を理解する .......................................................................... 22
2.2.
3.
システムの全体構成と実装プロセス ............................................................................... 22
2.2.1.
あなたのワークフローの変更を検討する .................................................................. 23
2.2.2.
システムの作動を確認する ....................................................................................... 23
2.2.3.
導入問題を検討する .................................................................................................. 27
2.2.4.
“遺産”システム問題の摘出と対応 ......................................................................... 28
シナリオ：統合度の高い PACS の据付け .............................................................................. 31
3.1.
購入計画と購入プロセス ................................................................................................. 31
3.1.1.
組織目標の達成 ......................................................................................................... 31
3.1.2.
IHE 統合プロファイルとアクタを選択する ............................................................. 36
3.1.3.
あなたの RFP に統合要求事項を盛り込む ................................................................ 37
3.1.4.
適切な製品を選択する .............................................................................................. 38
3.1.5.
ベンダからの統合宣言書を理解する ......................................................................... 38
3.2.
システムの全体構成と実装プロセス ............................................................................... 38
3.2.1.
あなたのワークフローの変更を検討する .................................................................. 38
3.2.2.
システムの作動を確認する ....................................................................................... 39
2005 年 6 月 20 日
1
IHE 放射線ユーザハンドブック
3.2.3.
導入問題を検討する .................................................................................................. 41
3.2.4.
“遺産”システム問題の摘出と対応 ......................................................................... 41
附属書 A 統合プロファイルの統合戦略の策定 ........................................................................... 48
A.1 現存する遺産システムを含む IT 環境における統合の進め方 .......................................... 49
附属書 B IHE 統合プロファイルを理解する ............................................................................. 51
B.1 統合プロファイルの要旨とチュートリアル ..................................................................... 51
B.2 ユーザの成功事例 ............................................................................................................ 51
B.3
IHE テクニカルフレームワークを理解する .................................................................... 51
附属書 C 統合の機能仕様を RFI/RFP に盛り込む ..................................................................... 53
附属書 D 適切な製品の選択 ....................................................................................................... 56
D.1
IHE コネクタソンの結果 ................................................................................................. 56
D.2
IHE 統合宣言書 ............................................................................................................... 56
附属書 E 統合宣言書の理解 ....................................................................................................... 57
附属書 F
DICOM 適合性宣言の受理と理解 ............................................................................... 58
附属書 G HL7 インターフェース仕様の受理と理解 .................................................................. 59
附属書 H 受入テストの実施 ....................................................................................................... 60
附属書 I 性能の測定 ................................................................................................................... 62
I.1 何を測定するか ................................................................................................................. 62
I.2 サンプルの測定結果 .......................................................................................................... 63
2005 年 6 月 20 日
2
IHE 放射線ユーザハンドブック
用語集
アクタ[IHE]：ある情報または業務を担うシステムやアプリケーション―例えば、オーダ発行
アクタ。アクタ間の情報通信のために特定 IHE トランザクションの組合せが指定されている。
ベンダの製品には一つまたは複数のアクタが含まれることもある。
患者登録管理 (ADT) メッセージ[HL7]：患者統計情報と患者来訪情報の新規・更新を伝達する。通
常、情報は患者管理システムに入力され、そこから看護部門や補助部門や経理財務部門へ、データ
自動定期的更新の形かレコード検索問い合わせへの対応という形で転送される。1
ブローカー：特定の仕様に準拠していないシステムとその他のシステムを接続することで、既存装
置の取扱いに関する問題に対処する機器またはアプリケーション。ブローカーは、システムとの通
信を仲介し、それぞれのシステムが解読可能な仕様に変換する。
コネクタソン [IHE]：IHE に参加するベンダが一堂に会し、IHE アクタの実装が為されている
かどうかをテストするイベントで、年に 1 回行われている。
医 療 用 デ ジ タ ル 画 像 と そ の 通 信 の た め の 標 準 規 格 （ DICOM ）： Digital Imaging and
Communication in Medicine の略で、医用画像機器間のデジタル情報通信の標準規格。
DICOM サービス：サービスクラスを参照。
部門〔IHE〕：IHE 内で特定の臨床分野に対処する作業グループで、放射線、循環器、臨床検
査、IT インフラの各部門がある。部門ごとにテクニカルフレームワーク（TF）が発行されて
いる。
一般オーダメッセージ (ORM) [HL7]：このメッセージの機能はオーダについての情報の発信
を開始させることである。このメッセージには新オーダの発行、既存オーダの削除、活動継続
中止、待機、その他が含まれる。ORMメッセージは発行者、実施者、または関心のある第三
者などによって発信される。 2
ヘルスレベル 7(HL7)：診療や医療の管理、提供、評価を支える情報の交換、管理、統合のた
めの標準規格。
医療連携のための情報統合化プロジェクト（IHE）：医療機関と産業界による医療情報システ
ムの連携に向けた構想。
統合プロファイル[IHE]：特定分野の医療連携に必要な標準規格の実装方法の詳細な解説。各
プロファイルには、ユースケース、診療情報および関連するワークフローの定義とそれを実行
するためのアクタのセットが示される。この統合プロファイルに関連して、要求事項書（RFP）
および製品説明において使いやすい形式で詳細に統合方法を定めた仕様書である IHE テクニ
カルフレームワークがある。
統合宣言書［IHE］：それぞれ製品の特定バージョンが対応する IHE 統合プロファイル、アク
タ、オプションを説明するために、ベンダが作成し、公開する文書。
インターフェースエンジン：ブローカーを参照
紛失データ：削除または紛失したデータ（多くの場合、統計または追跡情報のエラーや不一致
により索引が不正に登録されているため）
1
2
HL7 2.3.1 版より引用した定義
HL7 2.3.1 版より引用した定義
2005 年 6 月 20 日
3
IHE 放射線ユーザハンドブック
プロファイル[IHE]：統合プロファイルを参照。
登録システム：通常ワークフローでの患者登録用システム。通常は患者統計情報のオーナ／ソ
ース。
サービスクラス［DICOM］：画像保存や印刷など、DICOM で定められ、サービスを提供また
は利用する機器によって実行される機能。
サービスクラス提供者（SCP）［DICOM］：DICOM サービスを提供するシステムまたはアプ
リケーション（多くの場合、「サーバ」とみなされる）
サービスクラス利用者（SCU）［DICOM］：DICOM サービスを利用するシステムまたはアプ
リケーション（多くの場合、「クライアント」とみなされる）
補足［IHE］：テクニカルフレームワーク（TF）に新規に提案された機能。一般的には、パブ
リックコメント、レビュー、トライアル版、試験を経て TF に統合される。
テクニカルフレームワーク（TF）［IHE］：TF には、統合プロファイルが規定され、対処する
問題点およびユースケース、関連アクタやトランザクションが定義されている。それぞれのト
ランザクションの実装仕様を詳細に記載されている（主にベンダのための手引きとして使用さ
れる）。
トランザクション[IHE]：アクタ間の情報交換。TF には、それぞれのトランザクションについて、
情報交換のための標準規格（HL7、DICOM、W3C など）の適用方法が記載されている。
業務リスト：予定されている画像撮影など作業項目のリスト。業務リストは一般的に電子的に
回収され、その中には作業に関する詳細（患者氏名、ID 番号、受付番号、関連入力データ）
が含まれる。スケジュールや機器の指定については、含まれることも、含まれないこともある。
略語
AE Title = Application-Entity Title（アプリケーションエンティティタイトル）
CPI = Consistent Presentation of Images（画像表示の一貫性確保）
DCS = DICOM Conformance Statement（DICOM 適合性宣言）
GSPS = Grayscale Presentation State（グレースケール表示状態）
HIS = Hospital Information System（病院情報システム）
MPPS = Modality Performed Procedure Step（モダリティ実施処理手順）
MWL = Modality Worklist（モダリティワークリスト）
PACS = picture archiving and communication system（画像保管通信システム）
PGP = Presentation of Grouped Procedures（複数検査手続きの一括撮影と表示）
PIR = Patient Information Reconciliation（患者情報の整合性確保）
PPS = Performed Procedure Step（進抄管理）
RFI = request for information（（技術）情報要求書）
RFP = request for proposals（提案要求書）
RIS = radiology information system（放射線（部門）情報システム）
SWF = Scheduled Workflow（通常運用のワークフロー）
2005 年 6 月 20 日
4
IHE 放射線ユーザハンドブック
1.
シナリオ：モダリティの購入
新しいモダリティを一般的な病院や診療所で購入し実装する際には、既にその医療機関で稼動
しているシステム（放射線情報システム[RIS]、画像保管通信システム[PACS]、ワークステー
ション）や機能（医療デジタル画像通信[DICOM]、モダリティワークリスト[MWL]、ソフト
‐コピーレビュー）に応じて IHE 統合機能をもつモダリティを実装することは、様々なメリ
ットを生み出します。
1.1.
購入計画と購入プロセス
本セクションでは、購入責任者に向けて、モダリティシステムの要求事項を決める場合に考慮
すべき組織の目標、その目標に向けて取り組む IHE 統合プロファイルを選択していく方法、
提案要求書（RFP)の中に明確に IHE 要求事項を説明する方法、ベンダ応答を解釈していく方
法を列挙します。
1.1.1
組織目標と統合プロファイル
組織の目標を明確に把握することは、装置を取得するために要求事項を定義していくのに重要なこと
です。各 IHE 統合プロファイルは組織目標の特定の組合せに応じられるように設計されています。新
しいモダリティシステムを取得する際に医療機関がもつ目標とその目標をサポートする際に各関連統
合プロファイルが貢献できることを下記に示します。
エラーの削減と患者ケアの改善
モダリティ上での通常運用のワークフロー（SWF）：
¾
MWLのRISから患者情報と検査情報をダウンロードすることによって、モダリティ
コンソールでの手入力によるエラーを防止。
¾
RISからワークリストのモダリティに現在の正確な情報をダウンロードすることによ
ってデータの陳腐化を防止。
¾
患者アレルギーや妊娠状態による合併症予防、―モダリティはそれらの詳細をワーク
リストから得て、オペレータへ表示される。
¾
画像および完了状態の送信を電子的に行い、手作業での手順の数を減らすことによっ
て医療の遅延を回避。
¾
下記脚注のようにスループット部門での作業のやり方によって試験データの消失ま
たは「破損」 3 を防止。
¾
診療履歴の紛失や不適切な履歴を予防―モダリティはRISから詳細な患者統計情報と処置経過
記録をダウンロードして検査結果を保存して、正確な位置と引き出しが可能になる。
モダリティ上での画像表示の一貫性確保(CPI)：
¾
通常でない撮影用の患者の向きを規定するために、モダリティのコンソール上に表示
状態を添付することで、患者の向きについての混乱を防ぐ。
モダリティ上での複数検査手続きの一括撮影と表示（PGP)：
¾
複数検査手続きを一括撮影にグループ化することによって、複数の撮影による患者の
不快感を和らげる。
3
「破損」した観察結果は、患者診療記録、オーダ、画像の間で、主要な統計情報と追跡情報の間の不一致が
生じた際に発生する。
2005 年 6 月 20 日
5
IHE 放射線ユーザハンドブック
モダリティ上でのキー画像への注釈(KIN)：
¾
画像撮影取得中の患者の状態や動きなどの重要な観察を、放射線技師が「デジタル貼
付けメモ」を使って放射線科医に対して記録できる。
モサリティ上でのエビデンス文書：
¾
関連測定などの、新規の臨床上の詳細情報を放射線科医に提供できる。
¾
胎児体長、血管狭窄や駆出率のようなモダリティ計測値を人間にも機械にも認識可能
な形式の画像で電子的に保存することによって、測定値の消失を防止。
モダリティ上で (SWF の) 支援プロトコルセッティングオプション：
¾
ワークリストエントリで提供された手続きコードに基づきプロトコルの初期設定を
調整した、不整合なまたは不正確なプロトコルの使用を削減。
モダリティ上での (SWF の) 進捗管理(PPS)の例外管理オプション：
¾
ワークリストのエントリを誤って選択することに起因する、誤った患者検査の削減―モダ
リティはRISおよびPACSに電子的に警告信号を送信する。
スループットでの改善
モダリティ上での通常運用のワークフロー(SWF)：
¾
ワークリストを使い患者統計情報や検査結果詳細をダウンロードすることによって、
データ手入力時間を節約。
¾
紛失した検査結果の探索や再入力での時間の浪費を防止―モダリティは患者統計情
報をダウンロードし、検査結果を誤った綴りの患者名でファイルしてしまうことを防
ぎ、不測の削除を防ぐためPACSに画像の受信を電子的に確認する。
¾
PACSへの画像転送の確認を人的に行なうために浪費される時間を節約―モダリティ
はPACSに画像の受信を自動的に確認する。
¾
読影／レポートプロセスでの遅延を削減―モダリティはRISに対して進行中の検査と完了
した検査を明確に報告し、初見と最終読影をより早く実施できるようにする。
¾
紙によるオーダでの読み間違いから生じる、誤検査を防止―モダリティはRISのワー
クリストからオーダのワークリストをダウンロードする。
¾
救急治療や姓名不詳者の検査による統計情報をマニュアルで修正することにより浪
費する時間を節約―PACSはRISからの患者統計情報提供に基づきモダリティへ検査
結果を自動的にアップデートする。
モダリティ上での(SWF の)支援プロトコル設定オプション：
¾
プロトコルセットアップ時間の削減―モダリティはワークリストエントリで提供され
た手続きコードに基づき初期プロトコルパラメータを設定する。
モダリティ上での（SWF の）PPS 例外マネージメントオプション：
¾
流れた検査の再予約をしやすくする―モダリティはRISに詳しい理由情報を提供す
る（装置の故障、患者の体調、患者の死亡など）。
モダリティ上での画像表示の一貫性確保(CPI)：
¾
放射線科医の画像準備に費やす時間の削除―放射線技師が画像を準備し表示状態を
保存する。
2005 年 6 月 20 日
6
IHE 放射線ユーザハンドブック
モダリティ上での複数検査手続きの一括撮影と表示(PPG)：
¾
手続きを一括撮影にグループ化することによって、一人の患者の複数検査オーダに対
する撮影時間を短縮。
¾
適切なウィンドウ処理を行い関係する画像部分を直接的に表示する状態を実現することによっ
て、放射線科医が比較検討する画像の間で解剖学的な部位をマッチングさせるのに費やす時間を
短縮。
モダリティ上でのエビデンス文書：
¾
口述書取り、転記、読み合わせの時間を短縮―モダリティはレポーティングシステム
へ測定値をデジタルに送り込む。
課金プロセスの改善：
モダリティ上での通常運用のワークフロー：
¾
失われた収入の回収、RIS上には入力されていない実施された追加の手続きの代金―
モダリティは実際に行なった手続きをRISに計上アップデートする。
¾
支払者の支払い拒否の防止、オーダと合致しない実施報告手続きという理由で―モダ
リティは実際に行なわれた手続きを報告し、オーダと異なる際は旗を立てて注意を促
すのでうまく折り合いを付けられる。
¾
“ペーパーワーク”に費やされる時間の防止、モダリティによって既にキャンセルされた
手続きをモダリティがそのキャンセル理由もつけてRISへ報告することにより。
モダリティ上に料金の通知表示：
¾
各手続きに対してフィルムや他の消耗品を正確に表示請求―モダリティはこれら詳
細をRISに報告する。
モダリティ上に複数検査手続きの一括撮影と表示(PGP)：
¾
失われた収入の回収、複数検査がモダリティでグループ化して一括撮影された場合―
モダリティは各々の手続きの受付番号を個々に保存してあり報告する。
モダリティ上の進捗管理(PPS)例外管理オプション(SWF 上)：
¾
不完全な検査に対しての料金計算で時間を費やすのを減少―モダリティは詳細な“不
完全”コードをRISへ提供する。
患者照射量の削減
モダリティ上での通常運用のワークフロー(SWF)：
¾
検査データの紛失を避けることによって、紛失検査を繰り返すことによる照射量の増加を
防ぐ。
¾
ターンアラウンドタイムを改善することによって、「時間がかかる」検査を繰り返す
ことによる照射量の増加を防ぐ。
モダリティ上に複数検査の手続きの一括撮影(PGP)：
¾
一回のコンビネーションスキャンを行なうことによって、一人の患者への複数オーダ
による照射量の削減。
モダリティ上で(SWF の)支援プロトコル設定オプション：
¾
誤って実施された検査を繰り返すことによる照射量の増加を防ぐ―モダリティは、紙
のオーダを受けて手動でプロトコルを設定するかわりに、ワークリストエントリで提
供された手続きコードに従って初期プロトコルパラメータを設定する。
2005 年 6 月 20 日
7
IHE 放射線ユーザハンドブック
小児科患者に成人のプロトコルを用いることによる照射量の増加を防止―モダリティは、ワー
クリストエントリで提供された手続きコードに従って初期プロトコルパラメータを設定する。
運用コストの削減
モダリティ上で通常運用のワークフロー(SWF)、画像表示の一貫性確保(CPI)および複数
検査手続きの一括撮影と表示(PGP)：
¾
前述のスループットでの効率化と改善により、人員増加を防止。
モダリティ上で可搬用画像データ交換(PDI)：
¾
外科手術用、他の医療機関への照会、内科医への照会のための不要なフィルムの削減
―モダリティはそれら利用者に送信される可搬用画像データ交換搭載のCDを生成す
る。
画像品質の改善
モダリティ上の画像表示の一貫性確保(CPI)：
¾
放射線技師がモダリティ上で適切なディスプレイ設定を選択し、PACSに表示状態を
保存することから、有効でないディスプレイ設定を削減。
¾
モダリティディスプレイステーションを適切に校正させることによって有効でない
ディスプレイ設定を削減。
モダリティ上でキー画像への注釈(KIN)：
¾
患者の動きまたは造影剤の漏れなどの画像撮影上の問題点を報告―放射線技師は放
射線科医師向けにモダリティ上にデジタル「メモノート」を貼り付けられる。
¾
お粗末な撮影技術などの画像取得上の問題を注意喚起―放射線科医は同じツールを
使って放射線技師と通信できる。
展開運用のコスト／時間の削減
モダリティ上にすべての IHE プロファイル
¾
カスタムメードインターフェース仕様にかかる時間と支出を防ぐ―IHE‐TFは多くのベ
ンダにサポートされ試験された強力なインターフェースの詳細仕様を提供する。
¾
カスタムメードインターフェースの実装時の時間と支出を防ぐ―多くのIHE統合プ
ロファイルが既にたくさんのベンダ製品にサポートされている。
¾
インターフェース準拠のテストの時間と支出を削減―多くの実装のバリエーション
がIHEコネクタソンで試験されたシステムで洗練されてきている。
¾
インターシステムテストの時間と支出を削減―複数のシステムの組合せが、すでに、
IHEコネクタソンで、同時に直接テストされている。
¾
複数のカスタムインターフェースの代りに単一のインターフェース(IHE)をメンテナンスするこ
とによって、カスタムインターフェースのメンテナンスの時間と支出を削減。
常に単一の装置の購入によってすべての組織目標に対応できるとは限らない。IHE 統合プロファイルのメ
リットを完全に達成するには、そのモダリティと相互運用するシステムもまたプロファイルに定義された
ような役割を果たすことが必要となる。相互運用するシステムがプロファイルに述べられた機能をいくつ
かもってはいるがすべてではないというような環境で、撮影装置などの単一のアクタ上で統合プロファイ
ルを実装することによっても、しばしば、統合プロファイルのもつメリットが部分的には達成される可能
性がある。附属書 A に、長期的な購入計画での段階的な要求事項と個別購入計画について総括
的な議論を記載しています。
2005 年 6 月 20 日
8
IHE 放射線ユーザハンドブック
各医療機関の目的に向けた進展状況を知り、投資回収率を測定するためには、明確に定義され
た効率化指標が必要となります―附属書 I を参照。
1.1.2.
IHE 統合プロファイルとアクタを選択する
購入しようとするシステムの統合要求事項を具体的に定めていくことは、どの IHE 統合プロ
ファイルを選択し、どの IHE アクタがサポートされているか選択するという単純なことです。
幾つかのプロファイルは、あなたが選択しようと決定するかもしれない追加機能を提供するオ
プションを持っています。モダリティの購入に関係する統合プロファイルおよび各プロファイ
ルが持つ機能を以下に述べます。
通常運用のワークフロー(Scheduled Workflow(SWF))が画像収集プロセスでのIHE統合の最
も基本的で不可欠なものです。この統合プロファイルは代表的な画像との出会い遭遇において、
患者ケアを能率よく進めるためのシームレスな情報の流れを確立します。確立の方法は、登録
からオーダ発行、スケジューリング、画像取得、保管等を経由して画像表示まで患者情報を一
貫して保持するようなトランザクションを規定することによって行なわれます。あなたがこの
プロファイルからスタートされることを強くお勧めします。
画像表示の一貫性確保(Consistent Presentation of Images)は放射線技師がモダリティ上で初期の
表示設定を行ないます。放射線科医が読影の際にそれを行なうように求めるのではありません。
複数検査手続きの一括撮影と表示(Presentation of Grouped Procedure)はモダリティが報告
や課金の流れの鎖を混乱させることなしにグループ手続き（たとえば胸部－腹部－骨盤）を可
能にしています。
可搬式画像データ交換(Portable Data for Imaging)はモダリティ上でDICOM準拠の画像CDs
を作り出すことができます。
エビデンス文書(Evidence Document)は画像測定が（例えばejection fraction、胎児身長）モダ
リティを用いて実施されPACS上に保管されます。
アシステッドプロトコルセッティングオプション(in the SWF Profile)はワークリストエント
リに基づきモダリティ上で初期プロトコルを調整可能にしています。
例外管理オプション(in the SWF)は、何故検査が中断されたか、点検修理が必要だとかについ
てモダリティからRISへ詳細なフィードバックを可能にしています。
撮影装置アクタ(Acquisition Modality Actor)はモダリティシステムが果たしている最重要な役割で
す。モダリティが実行できる他のIHEアクタとしては：印刷コンポーザー(Print Composer)：プリ
ントリクエストをDICOMプリンタへ送る、メディアクリエーター(Media Creator)：画像CDsを作
る、画像表示(Image Display)：PACSから画像を検索表示する、エビデンスクリエータ(Evidence
Creator)：計測値をPACSに保存する、があります。
各プロファイルやアクタの提供するメリットは前節で概説しました。更に詳しい情報は附属書B を参照願い
ます。
1.1.3.
あなたの RFP（要求仕様書）に統合要求事項を盛り込む
あなたのＲＦＰの中に IHE の機能サポートを求めることはとても簡単で、システムにどの IHE 統合
プロファイル（およびオプション）をサポートして欲しいか、および各プロファイルの中でどの IHE
アクタの役割を果たすべきかを述べるだけでよいのです。
以下に全仕様を備えた撮影装置のプロファイルとアクタを指定するサンプルステートメントを示します。
：
¾
モダリティシステムは、IHE 予約済み通常運用のワークフロー統合プロファイルに
準拠し、撮影装置および画像表示装置のアクタを実装すること。
¾
モダリティシステムは、IHE 通常運用のワークフローの中でアシステッドプロトコルセッティ
ングオプションおよび例外管理オプションを満たし、撮影装置アクタを実装すること
2005 年 6 月 20 日
9
IHE 放射線ユーザハンドブック
¾
モダリティシステムは、IHE 画像表示の一貫性確保統合プロファイルに準拠し、撮
影装置およびプリント生成アクタを実装すること。
¾
モダリティシステムは、IHE 複数検査手続きの一括撮影と表示統合プロファイルに
準拠し、撮影装置アクタを実装すること。
¾
モダリティシステムは、IHE 可搬用画像データ交換統合プロファイルに準拠し、メ
ディアクリエータアクタを実装すること。
¾
モダリティシステムは、IHE エビデンス文書統合プロファイルに準拠し、撮影装置
アクタを実装すること。
RFP プロセスの更に詳細な議論は、附属書 C を参照願います。
1.1.4.
適切な製品を選択する
あなたは可能性のあるベンダの広いグループに直接あなたの RFP を送ることを選ぶことも出
来ますが、どのベンダが関係する IHE 統合機能を充足しているかを公開された情報源に照会
することも出来ます。そのような情報源については、附属書 D を参照願います。
1.1.5.
ベンダからの統合宣言書を理解する
ベンダはあなたの RFP に応じて IHE 統合宣言書資料を提出します。多くの製品の IHE 統合
宣言書は、以下からも利用可能です。
www.ihe.net/Resources/ihe_integration_statements.cfm.
統合ステートメントは、特定ベンダの特定製品がどの IHE プロファイル、アクタ、オプショ
ンをサポートしているかの直接的な宣言です。統合宣言の内容については附属書 E を参照願い
ます。
1.2
システムの全体構成と実装プロセス
以下のセクションは実装チーム向けに意図されたものです。IHE 機能を持つモダリティシステ
ムを実装展開する際の重要な臨床上および IT 上の諸々の考慮を述べています。IHE プロファ
イルを充足していないシステムにモダリティを接続する際のいわゆる“遺産”問題にどのよう
に対応するかについても触れています。
1.2.1.
あなたのワークフローの変更を検討する
IHE プロファイルは、流れるような臨床ワークフローの中にデジタル画像情報システムを実装
するように設計されています。例えば、モダリティでは紛失したフィルムフォルダーの捜索と
か、PACS 上の患者フォルダーのミスマッチの解消とかの為に患者情報を入力しようとするニ
ーズを拒否し受け付けません。画像は直ちに表示可能となります。そのような変更のメリット
をすべて享受するには、幾つかのタスクは正しい方法で実行されなければなりません。
1.2.1.1
通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)
SWF および PIR プロファイルは、患者デモグラフィック情報、オーダおよび手続き情報が正確で
一貫性があることを保障しています。また画像はタイムリーに読影可能にします。モダリティオペ
レータは、MWL を用いて RIS に対して患者デモグラフィック情報やスケジュールされた手続き情
報を問合わせて入手します。患者の氏名変更はモダリティでは実行禁止です。モダリティが予期し
ない追加変更を加えられない限り、RIS が最も重要な情報源であり氏名のアップデートなどの管理
を行なうところです。最もタイムリーで正確な患者情報を確保するために、患者やオーダ詳細が変
更されたというケースにも備えられるように新しい検査を始める前にワークリストに問い合わせを
かけるべきです。モダリティオペレータは検査ごとに患者が正しく選ばれているか検証しなければ
なりません。
2005 年 6 月 20 日
10
IHE 放射線ユーザハンドブック
予約されていないケースでは（例えば救急患者）
、患者氏名や ID 番号が分からないことがあります。
それら情報が手続きを開始するには必要なので、事前に取り決めてある一時的な仮の患者氏名と ID
番号のリストの中からモダリティで選択して決める必要があります。そのように予約されていない
場合には、画像オーダのキー識別人（key identifier）である AN は空欄とし、正しい患者氏名、登
録番号が判明した時に RIS や PACS が画像情報に正しい値を入れ首尾一貫させます。
1.2.1.2.
画像表示の一貫性保持
CPI プロファイルは、どんなモニタ機器やプリンタ装置が使用されても、画像の表示はその医
療機関中で一貫性が保たれることを保障します。放射線技師はコントラストや輝度の設定、フ
リップ、ズーム、シャッター、回転や注記のような画像調整機能を用いて適切な画面表示を（お
そらく数種類の）作り出します。例えば PACS ワークステーションで最後に見た画像の画面が
求められる際に放射線科医がどの設定を用いるか直ぐに分かるように、充分に理解された区別
しやすい説明文言が使われねばなりません。
放射線科医は、画像に加えてそれら表示状態オブジェクトの存在とその意味を充分に意識して
いなければなりません。医師はその表示状態を将来の参考にするために、画像を自身で修飾し
た表示状態を保存しておくことを望むかもしれません。
IT 関係者は、使用されるすべてのモニタおよびフィルムプリンタの一貫性保持のため
Grayscale Display Function Standard(DICOM PS3.14)に準拠してモニタやプリンタを定期
的に較正しなければなりません。
1.2.2.
システムの作動を確認する
以下のセクションは、モダリティがそれぞれ実装された統合プロファイルに従って作動してい
ることを確認する方法のガイダンスです。各セクションは、モダリティに関するプロファイル
を一つずつテストしていく項目を示します。しばしば、データとトランザクションを確認する
には此処に述べる以外の別の方法もあります。附属書 H を参照願います。
1.2.2.1.
通常運用のワークフロー(SWF)
モダリティについては、患者デモグラフィック情報やオーダや他の手続き情報が MWL を経由
してモダリティに届き、モダリティが作り出す画像に保持されていることが大切です。その極
めて重要な情報がモダリティ上でレビュー出来るか照合確認すること。検査完了時に PACS 上
にその検査関係の情報が正確に保管されているか確認し、更に RIS ワークリストともマッチす
ることも確認すること。以下は SWF 機能を持つ新しいモダリティ上で実施する必要があるハ
イレベルのテストの例です。
1)
病院情報システム（HIS）や RIS 経由である手続きを計画し、ワークリスト機能(MWL*)
を 用いてモダリティ上で MWL 情報を調べます。
*この記号は、www.ihe.net/Technical_Framework/index.cfm. 上にあるIHE TFの中に説明されて
いますが、トランザクションコードを示しています。
シナリオの確認：モダリティ上の患者デモグラフィック情報および手続き情報はRIS経由でスケジ
ュールされてきた情報とマッチするか照合確認すること。RISでスケジュールされた手続き情報を
モダリティ上のワークリストと比較すれば、これを行なえます。MWL上で得られる具体的な情報
（例えば、患者氏名、患者ID、AN、モダリティ、要請手続きID、プロトコル名、プロトコルコー
ド）については、IHE TF Vol. 2 のTable 4.5-3 を参照願います。
2)
モダリティ上で予約手続きを開始し、手続き実行中は RIS 上の手続き状態／情報の更新を
観察すること（モダリティ実施処理手順（MPPS）進行中）
。
2005 年 6 月 20 日
11
IHE 放射線ユーザハンドブック
シナリオの確認：モダリティ上で実行されている手続きに従ってRIS（またはPACS）上
の手続き状態がアップデートされていることを確認すること。注意：多くのモダリティで
は中間的手続き状態という状態表示を持たないことがあります。実行中の状態になるとア
ップデートされる情報の具体的な例はIHE TF Vol.2 の附属書Aを参照願います。モダリテ
ィは手続きをどのように実行するかについてのユースケースはIHE TF Vol.2 Section4.6
を参照すること。
3)
モダリティ上で予約手続きを完了させ、RIS 上の手続き状態／情報が（完了）となること
を観察すること（モダリティ実施処理手順（MPPS）完了）。また、予約無しの手続きを
実行してみましょう。その場合、患者デモグラフィック情報や手続き情報が入力（バーコ
ードからか手入力か）されなければならず、予約済み手続きに新しい手続きを追加し、放
射線科医が生成画像を観察した後手続きが完了する前にモダリティ上でその手続きを棄
却することになるのですが。
シナリオの確認：モダリティ上で手続きが実行中になると、RIS(またはPACS)上の手続き
状態がそれに応じてアップデートされることを確認すること。実行中の状態になるとアッ
プデートされる情報の具体的な例はIHE TF Vol.2 の附属書Aを参照のこと。テストされる
シナリオに基づいて特に注意するべきパラメータの幾つかは、AN、要求手続きID、予約
手続き対実行済み手続きの比較です。
4)
モダリティからの画像を画像保管システムへ保管する（自動保管でも手動保管でもどちら
でも）。（モダリティ画像保管完了）
シナリオ確認：モダリティ上に生成された画像がPACSシステムに保管されたことを確認
すること。
5)
画像保管システムが画像の所有を宣言する前に、モダリティから画像を削除することを試
みること。（保存委託）
シナリオの確認：画像がPACSシステム経由で永久保管されたものではなかったので、モ
ダリティ上の画像は削除できなかったことを確認すること。
6)
画像補完システムが画像の所有を宣言した後に、モダリティから画像を削除することを試
みること。（保存委託）
シナリオの確認：画像がPACSシステム経由で永久保管されたので、モダリティ上の画像
は削除できたことを確認すること。
それらの分野の各々については、適切なデータセットを用いて詳細なテストセットが作成され
る必要があります。例えば、モダリティが RIS から MWL を検索する際には、次の項目の様
なタイプのことが考慮されなければなりません。
1)
どんなタイプの MWL 問合せモダリティは実行できるのか？
関連するフィールドを求めるテストを作成すること。（例えば、このモダリティに今日予
約されている手続きのすべてをとか）。
2)
どんな情報をこのモダリティは表示できるのか、そしてどんな情報がその結果としての画
像セットに保存されるか？
ＭＷＬ情報をすべて調べてモダリティ上に表示できるものはどれかを決めるテストを作
成すること。返され表示された MWL フィールド（患者氏名、患者 ID,AN,その他）の各々
をレビューする能力を確認すること。ＭＷＬから生成され結果として DICOM 画像に用い
られた情報をすべて調べるテストを作成すること。
2005 年 6 月 20 日
12
IHE 放射線ユーザハンドブック
1.2.2.2.
アシステッドプロトコルセッティングオプション(SWF の中で)
幾つかのモダリティは検査手続き計画(Procedure Plan)をサポートする能力を持っています。
その検査手続き計画とは、RIS から MWL 経由でモダリティにもたらされ手続き完了と共に
RIS へ持ち帰られるプロトコルシーケンスコードに基づいているのですが。プロトコルシーケ
ンスは手続き中のすべてのステップをドライブするために用いられます。例えば、MRI に対し
てのプロトコルシーケンスは“T-1 axial-weighted fat sat sequence of the brain”のごとくで
しょう。そのプロトコルシーケンスとは、数値を与えられ各モダリティは適切なマシンプロト
コルを実行することによってその数値に対応して機能構成されます。
このオプションをサポート出来るような医療機関では、サポート出来るモダリティでテストす
るべきです。
1)
プロトコルコードを用いて RIS 経由で手続きを予約し、モダリティ上で MWL 機能経由
での情報を調べます。
シナリオの確認：モダリティ上のプロトコルコードがRIS経由で予約されたものとマッチ
することを確認します。MWLのプロトコルシーケンスコードに関する特定の情報はIHE
TF Vol. 2 のTable 4.5-3 を参照のこと。モダリティはプロトコルコードを用いて実行され
る手続きをコントロールしていることを確認すること。アシステッドプロトコルオプショ
ンについて更に詳しくはセクション 4.6.4.1.2.4.2 を参照願います。
2)
RIS によって指定されたプロトコルコードを用いて予約した手続きを実行します。
シナリオ確認：モダリティはプロトコルコードを用いて実行される手続きをコントロール
していることを確認すること。アシステッドプロトコルオプションについて更に詳しくは
セクション 4.6.4.1.2.4.2 を参照願います。
3)
代りに、プロトコルコードを変えて予約した手続きを実行してみます。
シナリオ確認：モダリティで実行された手続きによってRISがアップデートされたことを
確認すること。アシステッドプロトコルオプションについて更に詳しくはセクション
4.6.4.1.2.4.2 を参照すること。
詳細なテストセットはデータセット付きで計画すること。特定のモダリティをテストするのに
用いられる手続きの代表的なセットを使用するべきです。
1.2.2.3.
PPS 例外管理オプショ(SWF の中で)
幾つかのモダリティは、開始された手続きが途中で棄却される必要が生じる際に備えて、適切
な理由付けのコードを準備しておく機能が備わっています。このオプションを可能に出来る医
療機関では、この機能はモダリティ上でテストする必要があります。この要求事項については
セクション 4.6.4.1.2.4.2 を参照すること。この機能のテストは、SWF とモダリティのテスト
に追加テストを加えることで行なえます。
1)
RIS 経由で要求手続きを予約しモダリティ上で MWL 機能を用いて情報を調べ確認します。
2)
予約手続きを実行します。多くの画像を取得し、PACS へ送り込みます。
3)
手続きを棄却し、継続中止の理由コードを入力します。
4)
PPS が、PACS へ送られた取得画像を参照し、中止する理由コード付きで生成されたこと
を確認します。
シナリオの確認：RIS(PACS)上の手続き状態がモダリティで実行中の手続きに基づきアッ
プデートされたことを確認すること。例外管理コードについて更に詳しくは、IHE TF Vol.
2 のTable 4.7-1 を参照願います。
2005 年 6 月 20 日
13
IHE 放射線ユーザハンドブック
詳細テストセットはデータセット付きで作成すること。特定のモダリティをテストするには代
表的な手続きセットを用いるべきです。
1.2.2.4.
画像表示の一貫性確保(CPI)
CPI を使うことにより画像表示のレビュー能率と正確さが改善されます。CPI に関する表示状態を
生成するために、モダリティが重要な役割を果たします。以下は、CPI 機能をもつ新しいモダリテ
ィシステムのテストに必要と思われるハイレベルテストのリストの一例です。
1) CPI に関連して使用されるすべてのワークステーションおよびプリンタを較正します（ベ
ンダの資料参照）。
2) ウィンドウ付け／レベル化、拡大、回転、その他などを加えられた画像をモダリティ上に
生成し（直接に画像取得プロセス経由でもまたは取得画像のポストプロセッシングによっ
てでも）、PACS に保管します。(モダリティ表示状態情報の保存)
3) PACS から画像を検索し他のワークステーション上に表示します（画像検索取得）。
シナリオの確認：表示された画像は元の後処理された画像と同一なことを確認します。保
管 され る画像 の属 性の全 リス トにつ いて は DICOM 2003 PS 3.4:GSPS [Grayscale
Presentation State]を参照願います。
4) 処理された画像をモダリティからプリンタへ印刷します（表示 LUT 付き印刷要求）。
シナリオの確認：画像は元の後処理された画像と同一なことを確認します。印刷の属性の全リ
ストについてはDICOM 2003 PS 3.4:Presentation LUT SOP Classを参照願います。
各々の分野で、詳細テストセットを適切なデータセット付きで作成する必要があります。それらの
データには、処理可能な代表的な画像と適用する画像操作／変換のリストを（モダリティは発生さ
せる GSPS の中に適切な属性を設定しているのかを確認するために）含むべきです。
1.2.3.
導入問題を検討する
IHE を以ってしても、据付けは“plug and play”(配線接続したらそれで完了という単純な作
業)ではない―システムは自身で構成の組み上げをしてくれる訳ではない。モダリティに対して
は、下記の作業の実行が必要です。
1,2,3,1.
通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)
1)
あなたのモダリティの DICOM MWL 用に、AE タイトル、IP アドレス、ポートをまとめ
ること。この情報が RIS ベンダと共有される必要があり、その結果 RIS はあなたの MWL
を提供するように構成されます。
2)
あなたのモダリティのモダリティ実施処理手順(MPPS)用に、AE タイトル、IP アドレス、
ポートをまとめること。この情報が PACS ベンダと共有される必要があり（もし MPPS
マネジャを構成しているなら）、その結果 PACS ベンダは MPPS メッセージをあなたのモ
ダリティから RIS へ転送出来ます。さもなければ、もし RIS が MPPS マネジャとして作
動しているならば、MPPS メッセージを受信し PACS へ転送し、そして RIS はあなたの
モダリティの MPPS 構成情報を知る必要が出てくるでしょう。
3)
あなたのモダリティの DICOM 保存と保存委託用に、AE タイトル、IP アドレス、ポート
をまとめること。この情報が PACS ベンダと共有される必要があり、その結果 PACS はあ
なたに保存サービスを提供するように構成されます。
4)
あなたのモダリティの DICOM プリントサービス用に、AE タイトル、IP アドレス、ポー
トをまとめること。
2005 年 6 月 20 日
14
IHE 放射線ユーザハンドブック
この情報がプリンタベンダと共有される必要があり、その結果プリンタはあなたにフィル
ム上への印刷サービスを提供するように構成されます。加えて、プリント要求生成におい
ては、プリンタ属性をその特定のプリンタをサポートするように（媒体のタイプ、濃度の
最大最小、フィルム方向、フィルムサイズ ID、倍率タイプ、トリム、構成情報および極
性）構成すること。
相当の時間が異なるシステム間で種々のコードを生成し同期を採っていくのに費やされます。
コードはあなたのシステム中の様々な部分に使われるために―プロトコルコードのように単
純なものから、手続きコードのようにより大きなデータッセットに至るまで―取り決めていく
必要があります。例によって、コードは手作業で同期を保つ必要があり、もし同期が外れたら、
コードの値を意識することも無いので、受け取り手はデータを受けられないことになります。
1.2.3.2.
画像表示の一貫性確保(CPI)
モニタやプリンタの Grayscale Display Function Standard (DICOM PS 3.14)に従った定期的較正が
求められます。生成された表示状態について名前の付け方の取り決めが必要になるでしょう。
1.2.4.
“遺産”システム問題の摘出と対応
IHE 統合プロファイルは、すべての関係するシステムがそれらの統合プロファイルをサポート
することを前提として作られています。もし幾つかのシステムがあなたの選択したプロファイ
ルをサポートしていないか、プロファイルが基礎としている標準規格がサポートしている場合
には、なお幾つかのメリットは達成可能です。もしあなたのシステムに機能欠落があるなら、
短期間ではその欠陥を避けて回り道をする方法と、むしろそのシステムを置き換えるかまたは
アップグレードするかを考えればよいのです。
1.2.4.1.
モダリティを非 IHE PACS に接続する
モダリティと PACS 間の相互運用性は、HIS または RIS 経由で新しい情報または情報のアッ
プデートを受け取った場合に患者デモグラフィック情報、オーダや手続き情報が保存されアッ
プデートされることを可能にします。画像が出来るだけ早く利用可能になるように画像状態の
情報が提供されます。非－IHE PACS の能力に基づき、モダリティのある部分かすべての機能
が利用可能です。以下がモダリティを非 IHE PACS とどの様に統合していくか決める際に検
討するべきガイドラインです。
あなたの PACS ベンダからあなたの医療機関に据え付けられている現在のリリースされた製
品の DICOM 適合性宣言を要求すること。
1.2.4.1.1 通常運用のワークフロー(SWF)
SWF プロファイルにおいて、モダリティは PACS に対して、特定の属性を持つとか特定の方
法で（TF 参照のこと）メッセージに応答するとか幾つかの DICOM サービスを、サポートし
ていることを求めています。重要な DICOM サービスは以下の通りです：
¾
SCP として DICOM 保管
¾
SCP として DICOM 保存委託
¾
SCP として DICOMWPPS
¾
SCP として DICOM 問合せ／検索
もしあなたの PACS がそれらのサービスすべてを持っているならば、次に DIICOM 画像（そして他
の DICOM オブジェクトなら何でも）に備わっていて、モダリティがその上で作動する重要な
DICOM 属性を確認することです。取得ワークフローのすべてにおいて情報の一貫性を確保するた
めに、IHE で決定したキーとなる重要な属性は以下の如くです：
¾
患者氏名(0010,0010)
¾
患者 ID(0010,0020)
¾
検査インスタンスユニーク識別子(0020,000D)
2005 年 6 月 20 日
15
IHE 放射線ユーザハンドブック
¾
登録番号(0008,0050)
¾
依頼済み手続き(0040,1001)
¾
予約済み処理手順(0040,0009)
キー属性の完全なマッピングについては、
放射線TF, Vol. 2, 附属書A を参照のこと。
もしあなたのPACS
がそれらキー属性のどれかに作動しないならば、あなたのベンダはそれら属性を適切にサポートするオ
プションまたはアップグレードを提供するかもしれません。
PACS 上で MPPS をサポートすることは、自動的な手続き状態トラッキングおよび課金を可能にして、
“取得ループを完結させる”ので大いに役に立ちます。MPPS サービスが欠如する部分もあるのでワー
クフローは妨げられるが、このサービスの欠如によってはシステム間のデータ一貫性は損なわれません。
もしあなたの PACS が DICOM MPPS を持たないならば、検査状態をモダリティ（または RIS）へお
よびモダリティ（または RIS）から受信することが出来なくなります。この場合、
“取得ループを完結さ
せる”という点ではワークフロー問題を減少させますが、手続き状態のトラッキングおよび早く正確な
課金は次のどちらかの方法で行なうことは出来ます：(a)あなたの PACS は“頼みの綱モード”を持ち、
諸々の自己発見的な方法で検査状態を推定することが出来ます（その方法とは保存とか保存委託を使う
ことに依るかまたは他のイベントやモダリティや RIS からのトリガーを使います）
；(b)PACS 上の RIS
クライアントを使って取得タスクの状態を見つけてワーク状況を追跡します。
PACS 上での DICOM 保存委託をサポートすることは、一旦 PACS が“委託”を受け入れたならモダリ
ティから画像を自動削除することが可能です。もしあなたの PACS が DICOM 保存委託の機能を持たな
いならば、PACS が受け取ってその画像データの所有権を取ったことを確認することが出来ません。こ
の問題を減少させるには：(a)画像をモダリティシステムから削除する前に各検査のすべての PACS 上に
受けられて永久、長期保存“委託”を実行したことを手作業で確認する；(b)モダリティ上のすべての画
像のコピーをレポートが作成し保存されたことを確認するまで削除しないで保持しておきます。
もしあなたの PACS が DICOM 保存機能をサポートしていないならば、
IHE 統合は本当に実行不可能で
す、何故ならば DICOM 保存はぎりぎりの最低限なのです。あなたの PACS のアップグレードか買替え
を検討すること。
1.2.4.1.2.
画像表示の一貫性確保(CPI)
CPI プロファイルにおいては、モダリティは PACS に対して、特定の属性を用いてとか、特定
の方法で（TF 参照のこと）メッセージに応答するとかで、幾つかの DICOM サービスをサポ
ートしていることを求めています。重要な DICOM サービスは以下の通りです：
¾
SCP として DICOM 保管(GSPSs のために)
¾
SCP として DICOM 問合せ／取得(GSPSs のために)
¾
SCP として DICOM 保存委託
もしあなたの PACS がそれらのサービスをサポートしていないならば、あなたのベンダはオプ
ションかアップグレードでそれら機能を提供しなければなりません。
CPI 統合プロファイルの基礎の一つが DICOM GSPS オブジェクトの生成、保存および仕様で
あり、それは関係する画像を“前回見た通りに”表示しプリントするために必要なすべてのグ
レースケール処理操作やすべての空間的グラフィックな変換機能を伝えています。もしあなた
の PACS が GSPS オブジェクトの受信も処理も出来ないならば、画像を PACS ワークステー
ション上に“前回見た通りに”表示することが出来ず、画像をフィルム上に“前回見た通りに”
プリントすることも出来ません。この問題を減少させるため、(a)あなたの PACS は GSPS オ
ブジェクトを保存し問合せ／検索を掛けられなければなりません。表示用の CPI をサポートし
プリント生成アクタとして働くサードパーティのワークステーションをあなたの PACS に追
加することを考慮してください。(b)モダリティはプリント生成アクタとして CPI をサポート
するオプションを持つことが出来るかもしれません、それは画像プリントを一貫して表示する
2005 年 6 月 20 日
16
IHE 放射線ユーザハンドブック
CPI 機能付きのプリントサーバーとなります。(c)モダリティが最低限保障機能の画像に対する
グラフィックオーバレイ発生と技師が行なうグレースケール設定による画像コピー生成に頼
ります。しかし、この方法は PACS へ送付する画像の数を大幅に増やし、それら画像の将来の
処理を妨げます。
DICOM 保存委託をサポートしない PACS に関しての問題と可能な回り道についての議論は、
前記の SWF における保存委託のセクションを参照願います。
1.2.4.2.
モダリティを非‐IHE RIS へ接続する
あなたの RIS ベンダからあなたの病院に現在据え付けられているシステムの DICOM 適合性
宣言を要求してください。
1.2.4.2.1
通常運用のワークフロー(SWF)
SWF プロファイルにおいては、モダリティは RIS に対して、特定の属性を用いてとか、特定
の方法で（TF 参照のこと）メッセージに応答するとかで、幾つかの DICOM サービスをサポ
ートしていることを求めています。重要な DICOM サービスは以下の通りです：
¾
SCP として DICOM MWL および
¾
SCP として DICOM MPPS
RIS は、患者情報やオーダ情報をモダリティへ伝えるてめに DICOM MWL を使用するべきで
す。ワークリスト問合せおよび値の返却にどんな種類の属性をサポートしているか適合性宣言
を調べること、特に DICOM 規格で求められているものに加えて IHE がサポートを求めてい
る追加の属性を調べることです。
¾
依頼済み手続き ID(0040,1001) マッチングキーとして、
¾
登録番号(0008,0050)マッチングキーとして
¾
コード意味(0080,0104)予約済み手続きコードシーケンス(0040,0008)に対してのリ
ターンキーとして
¾
依頼済み手続きコードシーケンス(0032,1064)
もしそれらの属性がサポートされていなければ、あなたのワークフローは影響を受けるでしょ
う、何故ならばモダリティオペレータは求められているワークリストを効率よく探すことが出
来ないからでしょう。
RIS 上で DICOM MWL 能力が欠如している場合には、患者情報や検査情報をモダリティ上に
得るための回り道の方法には(a)バーコードを用いる（少なくとも不可欠の識別番号にアクセス
する代替方法）、(b)RIS ターミナルかハードコピー上で読み上げてモダリティで手入力する。
モダリティが求めている重要な情報には基本的な患者デモグラフィック情報、RIS の割り当て
る AN、およびもし可能ならば RIS の割り当てる検査インスタンスユニーク識別子（院内でデ
ータの一貫性を確保するために）です。
取得ワークフローのループを閉じるために、モダリティは関係するシステムに向けて DICOM
MPSS を発信し、取得状態（撮影進行中、完了、中断）を追跡し、一回取得グループケースの
発生の注意を喚起し、実行したワークについての追加データを課金用に入力します。これは医
療機関がかなり後の局面で導入を決められる追加仕様であるので、登録システムの供給者と交
渉を行なえることです。このサービスの必要性は、病院が課金プロセスを全体のワークフロー
の中に統合／自動化しようとするかまたは統合されていない課金手続きとして継続するかの
意思決定に依存します。
IHE は、モダリティに MPPS メッセージを RIS または PACS に送信することを求めています。
もしあなたの RIS が DICOM MPPS をサポートする能力を欠いている場合には、検査状態の
アップデートを受信できません。取得ワークフローのループを閉じることを可能にするという
観点からこの問題を減少させるには、手続き状態を追跡し早い正確な課金を行い、
2005 年 6 月 20 日
17
IHE 放射線ユーザハンドブック
MPPS メッセージが仲介装置へ送られ、それから更に HL7 ベースのアップデートメッセージ
が RIS に送られ、次いで MPPS は PACS まで転送されます。検査のアップデートを手入力す
るために RIS ターミナルはモダリティコンソールの付近で利用できるとよい。
2005 年 6 月 20 日
18
IHE 放射線ユーザハンドブック
2.
シナリオ：RIS のアップグレード
放射線検査部門は、現存する RIS のアップグレード／更新を計画しています。部門は放射線検査手
続き量が増加しており、しかしすべてが収入として実現している訳ではありません。オーダを締め
る際の問題があるし、時には検査が報告および結果配送のプロセスで紛失してしまいます。
病院は患者デモグラフィック管理およびオーダ管理の現存する資源を持っています。部門はモ
ダリティから生じる検査結果をすべて保管する PACS を持っています。多くの DICOM 機能を
持つモダリティが存在し、RIS のアップグレードが完了すれば新しいモダリティも幾つか導入
する予定です。
RIS の第一の機能はオーダ処理、手続きの予約、報告作成および放射線部門で実行され読影さ
れた手続き料金の把握です。RIS は診断報告書のコピーを院内報告保管所に送ります。
2.1.
購入計画と購入プロセス
購入意志決定の権限を持つ管理者向けに、このセクションは、RIS システムの要求事項を決める際
に考慮すべき組織の目標をリストアップし、それら目標に応じて IHE 統合プロファイルの選び方、
IHE 要求仕様の明確な記述方法およびベンダの応答を理解する方法を列記します。
2.1.1.
組織目標の達成
明確に組織の目標を特定することは、いかなる装置の取得においても重要な最初のステップです。
各々の IHE 統合プロファイルは、特定の組織目標の組合せに応じられるように設計されています。
下記が、新しい RIS を取得しようとする際に医療機関が抱く組織目標および各々の関係する統合プ
ロファイルが組織目標をサポートする際に果たす貢献を示すリストです。
過誤を減少させ患者へのケアを高める
RIS 上の通常運用のワークフロー(SWF)
¾
データの紛失の減少、RISは患者デモグラフィック情報をHISまたは登録システムか
ら受け取りそれをPACSやモダリティに伝えるので、識別データに一貫性が欠ける場
合がありそれに起因して発生。
¾
手入力によるデータの誤りの減少、RISは患者デモグラフィック情報とそのアップデ
ートを登録システムから、放射線検査オーダ情報をオーダエントリシステムから電子
的に受け取るため。
¾
手入力によるデータの誤りの減少 、RISは患者情報とオーダ情報をモダリティに
MWLを用いて伝えるため。
¾
誤った検査や取り消された検査手続きの実行を防止、RISはモダリティに届く最新の
検査手続きおよび予定の変更を含んで最新のワークリストを生成するため。
¾
アレルギーおよび妊娠状態などに起因する合併症の防止、RISは患者のアレルギーや
妊娠状態についての詳細をMWLに持っているため。
¾
患者の待ち時間を最小化、RISは次の処理量の改善セクションに示すように検査プロ
セスの能率を改善するため。
2005 年 6 月 20 日
19
IHE 放射線ユーザハンドブック
RIS 上での患者情報の整合性確保(PIR)
¾
患者の誤認および不正確な患者情報を防止、RISは登録システムからアップデート情
報（エントリエラー発見による、John Does識別、結婚後の氏名への記録の移動）を
受け取り、PACSや報告書管理(Report Manager)のような他の統合システムへアップ
デートを送るため。
処理量の改善
RIS 上での通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)：
¾
患者デモグラフィック情報の手入力によるスタッフの時間の浪費を防止、RISは登録
システムから情報を電子的に受け取りそれをモダリティに届けるため。
¾
紙のオーダ紙の到着待ちまたは捜索によるスタッフの時間の浪費を防止、RISは検査
オーダをオーダ発行システムから電子的に受け取りモダリティへ届けるため。
¾
過誤の発見修正を（よく調整された方法で行い）スタッフの時間の浪費を防止、RIS
はHIS,RIS,PACSおよびモダリティの間の多くの修正を自動的に行なうため。
¾
予約無しオーダの手作業での整合化によるスタッフ時間の浪費の防止、RISはモダリ
ティから予約無しの画像取得の報告を受けると、自動的にオーダの穴埋めをしてオー
ダ発行システムへ通報するため。
収入の増加／課金の改善
RIS 上の通常運用のワークフロー(SWF)および患者情報の一貫性確保(PIR)：
¾
発行オーダ通りに実行した検査に対する収入の喪失の防止、RISはワークリスト経由
でモダリティに最新の詳細を提供するので、発行後にキャンセルや内容変更される場
合にも適切に対応できるため。
¾
請求の遅れを防止、RISはモダリティからPPSメッセージとして手続き完了情報をタ
イムリーに受け取るため。
¾
不正確な請求を減少、RISはモダリティでキャンセルされたまたは変更された手続き
の正確な詳細情報を受け取るため。
¾
RIS 上での IHE 会計処理(Charge Posting)
¾
請求遅延の防止、RISはすべてのシステムからイベント発生の時点で請求できるイベ
ントを把握し、課金を速やかに正確に行いその結果を課金請求システムに利用可能に
するため。
RIS 上の IHE 複数検査手続きの一括撮影と表示(PGP)：
¾
グループ化一括撮影により未締め切りのオーダの減少：RISはモダリティから一回の
スキャン撮影とグループ化されたオーダの各々の登録番号に対しての撮影との両方
の完了メッセージを受け取るため。
2005 年 6 月 20 日
20
IHE 放射線ユーザハンドブック
運用コストの減少
RIS 上の通常運用のワークフロー(SWF)、患者情報の一貫性確保(PIR)、会計処理および
複数検査の一括撮影と表示(PGP)：
¾
余分の人員増を防止、上記のように効率化と処理量の増加、課金プロセスの改善により。
運用展開の際のコストと時間を減少
RIS 上の全 IHE 統合プロファイル：
¾
インターフェースのカスタム仕様決定にかかる時間とコストの削除、IHE TFは多く
のベンダにサポートされテストされた強力なインターフェース用の詳細な仕様を準
備しているため。
¾
カスタムインタフェース実装の時間とコストの防止、多くのIHE統合プロファイルは
多くのベンダ製品によってサポートされているため。
¾
インターフェース整合性テストの時間とコストを減少させる、多くの実装の派生型が
IHEコネクタソンでシステムテストされ問題点を解決済みであるため。
¾
インターシステムテストの時間とコストを減少させる、多くのシステム間組合せが
IHEコネクタソンで既に直接的に同時にテスト済みであるため。
¾
カスタムインターフェースのメンテナンスの時間とコストを減少させる、
複数のカスタムインター
フェースの代わりに単に一個のインターフェースをメンテナンスするだけであるため。
常に単一の装置の購入によってすべての組織目標に対応できるとは限らない。IHE 統合プロフ
ァイルのメリットをフルに達成するにはその RIS を取り巻き交信し合うシステムもまたプロ
ファイルに定義されたような役割を果たしてくれることが求められています。しばしば、RIS
のような単一のアクタの上で統合プロファイルが実装されていて、そのアクタが置かれている
環境は、アクタと交信し合うシステムがプロファイルに述べられた機能をいくつか持ってはい
るがすべてではないという場合には、統合プロファイルの持つメリットは部分的には達成され
ます。附属書 A で、要求事項をシーケンシャルに考慮し、個々の購入を長期計画の一環として
計画することを総合的に討議しています。
組織の目標に向かっての進歩の後を追い投資利益率を求めていくには、良く定義された一組の
活動状況を定量的に計測する方法が求められます。―附属書 I を参照願います。
2.1.2. IHE 統合プロファイルとアクタを選択する
購入しようとするシステムの統合要求事項を具体的に定めていくことは、どの IHE 統合プロ
ファイルを選択しどの IHE アクタがサポートされているか選択するという単純なことです。
幾つかのプロファイルは、あなたが選択しようと決めるかもしれない追加機能を提供するオプ
ションを持っています。RIS の購入に関係する統合プロファイルおよび各プロファイルが持つ
機能を以下に述べます。
通常運用のワークフロー (SWF)および患者情報の一貫性確保(PIR)が RIS を院内の他のシス
テムと統合する際の最も基本的で不可欠なものです。この二つの統合プロファイルが、典型的
な画像情報の流れおよびある例外ケースにおいて、患者ケアを能率よく進めるためのシームレ
スな情報の流れを確立します。確立の方法は、登録からオーダ発行、スケジューリング、画像
取得、保管等を経由して画像表示まで患者情報を一貫して保持するようなトランザクションを
規定することによって行なわれます。あなたはこの二つのプロファイルからスタートされるこ
とを強くお勧めします。
会計処理、は部門システムから正確に請求可能なイベント情報を収集し、それを迅速かつ集中
的に請求課金システムに利用可能にします。
複数検査手続きの一括撮影と表示(Presentation of Grouped Procedure)は、モダリティが画像
を取得する際に複数の手続きオーダを一括グループ化して行なう場合に、能率よいワークフロ
ーと正確なオーダトラッキングを可能にしています。
2005 年 6 月 20 日
21
IHE 放射線ユーザハンドブック
アシステッドプロトコルセッティングオプション(in the SWF Profile)はワークリストエント
リに基づき、モダリティ上で初期プロトコルを調整可能にしています。
例外管理オプション(in the SWF)は、何故検査が中断されたか、点検修理が必要だとかについ
てモダリティからRISへ詳細なフィードバックを可能にしています。
DSS／オーダ実施アクタ(DSS/Order Filler Actor)は、RISシステムが実行する最も重要な役割
です。RISが実行できる他のIHEアクタを追加するならば、診断報告書の永久保管を行なう報
告書保管(Report Repository)、診断報告書を生成しオプション的に報告作業ステップとしてワ
ークリストエントリ情報も取り出せる報告書作成(Report Creator)、および報告書を問合せ閲
覧する報告閲覧(Report Reader)があります。
各プロファイルやアクタの提供するメリットは前節で概説した。プロファイルについて更に詳
しい情報は附属書 B を参照願います。
2.1.3.あなたの RFP に統合要求事項を盛り込む
あなたのＲＦＰの中に IHE の機能サポートを求めるのはとても簡単で、システムにどの IHE 統合
プロファイル（およびオプション）をシステムにサポートして欲しいか、および各プロファイルの
中でどの IHE アクタの役割をシステムは果たすべきかを述べるだけでよいのです。
以下に全仕様を備えた RIS の統合プロファイルとアクタを指定するサンプルステートメントを示し
ます。
：
¾
RIS は DSS／オーダ実行アクタとして SWF プロファイルおよび PIR 統合プロファ
イルをサポートすること。
¾
RIS は DSS／オーダ実行アクタとして SWF の中でアシステッドプロトコルセッティ
ングオプションおよび例外管理オプションをサポートすること。
¾
RIS は、DSS／オーダ実行アクタとして IHE 会計処理プロファイルをサポートすること。
RFP プロセスの更に詳細な議論は、附属書 C を参照願います。
2.1.4.
適切な製品を選択する
あなたは可能性のあるベンダの広いグループに直接あなたの RFP を送ることを選ぶことも出
来ますが、どのベンダが関係する IHE 統合機能を充足しているかを公開された情報源に照会
することも出来ます。そのような情報源については、附属書 D を参照願います。
2.1.5.
ベンダからの統合宣言書を理解する
ベンダはあなたの RFP に応じて IHE 統合宣言書資料を提出するでしょう。多くの製品の IHE
統合宣言書は、以下からも利用可能です。
www.ihe.net/Resources/ihe_integration_statements.cfm.
統合ステートメントは、特定のベンダの特定製品がどの IHE プロファイル、アクタ、オプシ
ョンをサポートしているかの直接的な宣言です。統合宣言の内容については附属書 E を参照願
います。
2.2.
システムの全体構成と実装プロセス
以下のセクションは実装チームを意図して作られました。IHE 機能を持つ RIS を実装展開す
る際の重要な臨床上および IT 上の諸々の考慮すべき点を述べています。IHE プロファイルを
充足していないシステムに RIS を接続する際のいわゆる“遺産”問題にどのように対応するか
についても触れています。
2005 年 6 月 20 日
22
IHE 放射線ユーザハンドブック
2.2.1.
あなたのワークフローの変更を検討する
IHE プロファイルは流れるような臨床ワークフローの中にデジタル画像情報システムを実装
するように設計されています。例えば、紛失したフィルムフォルダーの捜索とか PACS 上の患
者フォルダーのミスマッチの解消とかの為に、モダリティで患者情報を入力しようとするニー
ズを拒否し受け付けません。画像は直ちに表示可能となる。そのような変更のメリットをすべ
て享受するには、幾つかのタスクが正しい方法で実行されなければなりません。
通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)
SWF プロファイルは、患者デモグラフィック情報、オーダおよび手続き情報は正確で院内中
に一貫性があることを保証しています―担当責任を持つシステムが、その情報をメンテナンス
し適切に関係先すべてに配布することが出来るように、その情報は一貫して同じシステム
(HIS,RIS,その他)から入力されなければなりません。臨床系および IT 系のスタッフは、ある
情報要素のオーナーが誰であるかはっきり知っていなければならないでしょう。オーナーが情
報を配布し、受信する側が情報を追跡利用します。典型的には、
¾
HIS が患者の同定権を保有します。救急のケースでも、HIS が患者を追跡し整合をと
ることを求められそして RIS をアップデートします。患者は HIS の中でのみ登録さ
れるべきなのです。IHE ワークフローが必要に応じて HIS 以下のシステムをすべて
アップデ－トします。もし患者が RIS で登録されたなら HIS をアップデートする IHE
ワークフローは無いのです。
¾
RIS は、他のスケジュール情報の中では登録番号(AN)、Study Instance Unique Identifier
を所有します。モダリティではもし分からなければ AN を入力してはなりません。
患者識別番号の所有権の一環として、臨床や IT スタッフは情報の相互関係について更に理解
を深める必要があるでしょう。例えば、IHE は複数検査手続きの関係する AN もサポートして
います。そのようなタイプの関係をセットアップ出来ることは、現在のワークフローの効率の
悪さを解決してくれるかもしれません。
2.2.2.
システムの作動を確認する
以下のセクションは、RIS が実装されたそれぞれの統合プロファイルに従って作動しているこ
とを確認する方法のガイダンスです。各セクションは RIS の関係するプロファイルを一つずつ
テストして行く項目を示します。しばしば、データとトランザクションを確認するには此処に
述べる以外の別の方法もあるということには留意してください。テストを進める戦略の入門と
して、附属書 H を参照願います。
2.2.2.1.
通常運用のワークフロー(SWF)
モダリティについては、HIS から送られる患者デモグラフィック情報やオーダ情報が正確に
RIS に保管されていることが重要です。この情報は、他の患者デモグラフィック情報やオーダ
情報の追加と手続き情報を併せて、正確にモダリティおよび PACS に転送されなければなりま
せん。その結果、手続きが適切に実行され報告書が届けられます。同様に、モダリティや PACS
から RIS へ返された状態情報は，極めて重要であり、完了した手続きや画像のような利用可能
になった情報についての状態表示を医療機関内に送出します。
RIS インターフェースの操作を確認するには、プロセスの幾つかのポイントでチェックする必要が
あります。HIS で作り出され RIS にスケジューリング用に送られた特定の患者の手続き情報をチェ
ックすること。HIS および RIS で作り出されモダリティへ送られた特定の患者の手続きを実行する
情報をチェックすること。モダリティからの状態およびアップデート情報をチェックすること。最
後に、PACS 上での画像情報の利用可能状況をチェックすることです。
2005 年 6 月 20 日
23
IHE 放射線ユーザハンドブック
以下は SWF 機能を持つ新しい RIS 上で実施する必要があると思われるハイレベルのテストの
例です。いくつかは，ことによるとすべてが、特定の医療機関にとって関係が深いかもしれま
せん。それらテストシナリオは IHE TF Vol. 1 Section 4.4 に載っているユースケースに基づい
ています。各々のシナリオに併せて、テストシナリオが準備されたメカニズム（仕組みと理由）
の説明もしています。多くの場合、データやトランザクションを確認するにはいくつかの方法
があることに留意することです。
患者登録およびオーダ実行は色々な方法で行なえます。以下のようにです：
1)
HIS 上で患者を登録しオーダを発行します。RIS 経由で実施します。（患者登録、オーダ
発行管理、オーダ実施管理）
シナリオ確認：患者登録作業で入力した重要な患者デモグラフィック情報、encounter
information (PV－1),その他、がRIS上に正確に出るか確認すること。HL7 のメッセージ
(例えば、患者氏名、ID、住所、クラス、掛かりつけ臨床医、アレルギータイプ)としてHIS
が送付する特定の情報についてはIHE TF Vol.2 Section 4.1.4. を参照すること。それから、
あなたの（撮影）操作用に入力した重要なオーダ情報がRIS上に正しく現れるのを確認数
すること。オーダが実施されRIS上に予約されたことを確認数すること。HL7 のメッセー
ジ(例えば、オーダ番号、オーダ日付／時間、universal service ID、オーダ発行者)として
HISが送付する特定の情報についてはIHE TF Vol.2 Section 4.2.4.を参照することなどで
す。
2)
患者を HIS 上で登録し、RIS 経由でオーダ（患者登録、オーダ発行管理、オーダ実施管
理）を発行します。
シナリオの確認：患者登録作業で入力した重要な患者デモグラフィック情報、encounter
information (PV－1),その他、がPatient Management User Interface経由でRIS上に正確
に出るか確認すること。HL7 のメッセージ(例えば、患者氏名、ID、住所、クラス、掛か
りつけ臨床医、アレルギータイプ)としてHISが送付する特定の情報についてはIHE TF
Vol.2 Section 4.1.4.を参照願います。次いで、あなたの（撮影）操作用にRISで入力した
重要なオーダ情報がHIS上に正しく現れるのをPatient Management User Interface経由
で確認すること。オーダが実施されRIS上に予約されたことを確認数すること。HL7 のメ
ッセージ(例えば、オーダ番号、オーダ日付／時間、universal service ID、オーダ発行者)
としてHISが送付する特定の情報についてはIHE TF Vol.2 Section 4.2.4.を参照願います。
3)
HIS 上で患者を登録します。
オーダを発行する前に、
HIS 経由で患者情報をアップデートします。
シナリオの確認：Patient Management User Interface経由でRIS上に反映された重要な患者
デモグラフィック情報、encounter information (PV－1)、その他がアップデートされたデー
タだけから構成されていることを確認すること。HL7 のメッセージ(例えば、患者氏名、ID、
住所、クラス、掛かりつけ臨床医、アレルギータイプ）としてHISが送付する特定の情報に
ついてはIHE TF Vol.2 Section 4.1.4.を参照願います。
4)
HIS または RIS で生成されたオーダに基づき手続きが RIS で予約されます。
（手続き予約済み）
シナリオの確認：登録された患者の手続き情報はPACSへ送られていることを確認するこ
と。PACSのScheduled Procedure User Interfaceを用いて,予約された患者のオーダ情報
を確認数すること。（代りに、引き続く別の予約手続きが存在して、それにより手続きの
完了を報告する適当な情報が発生して、それにより確認される。次の手続きには前の画像
の検索および報告が含まれます）HL7 のメッセージ(例えば、患者氏名、ID、universal
service ID)としてRISが送付する特定の情報についてはIHE TF Vol.2 Section 4.4.4.1.2 を
参照願います。
5)
ある場合には、手続き実行前にオーダが変更されることもあります。この場合、RIS 上で
（検査手続きの更新）
手続き情報のアップデートが行われなければなりません。
シナリオの確認：PACSのScheduled Procedure User Interfaceを用いて，予約された患者のオー
2005 年 6 月 20 日
24
IHE 放射線ユーザハンドブック
ダ情報を観察し、登録された患者の手続き情報は PACS で変更されたことを確認すること。PACS
のScheduled Procedure User Interfaceを用いて，
予約された患者のオーダ情報を確認数すること。
（代りに、引き続く別の予約手続きが存在して、それにより手続きの完了を報告する適当な情報が
発生して、それにより確認される。次の手続きには前の画像の検索および報告が含まれる。
）HL7
のメッセージ(例えば、手続き取り消し、手続き変更、手続き中断)として RIS が送付する特定の情
報については IHE TF Vol.2 Section 4.1.3.1.2 を参照願います。
手続きはモダリティに対して予約されます。手続きを実行するシステムは、予約手続き情
報を RIS から取り寄せたりアップデートを RIS へ送ったりするために、RIS と交信する
必要があります。すべてのシステムは、要求されたオーダおよび手続きの情報がすべて送
信されたことを確認する必要があります。
6)
モダリティは RIS 上の予約手続きリストを取り寄せます。
（モダリティワークリスト送付済み）
シナリオ確認：PACSのScheduled Procedure User Interfaceを用いて,予約された患者の
オーダ情報を観察し、登録された患者デモグラフィック情報および予約された手続きのオ
ーダや手続き情報は、正しくワークステーション上に表示されることをMWLを観察する
ことにより確認すること。PACSのScheduled Procedure User Interfaceを用いて,予約さ
れた患者のオーダ情報を確認数すること。
（代りに、引き続く別の予約手続きが存在して、
それにより手続きの完了を報告する適当な情報が発生して、それにより確認されます。次
の手続きには前の画像の検索および報告が含まれます）DICOM（例えば、患者氏名、ID,
要求された手続き、AN）メッセージとしてRISが送付する特定の情報についてはIHE TF
Vol.2 Table 4.5-3 を参照願います。
7)
モダリティが手続きを実行すると状態更新がRIS に伝えられます。
（MPPS 進行中、MPPS 完了）
シナリオの確認：RIS上の手続きがモダリティ上で実施されたこととマッチすることを確
認すること。以下がoutcomeのリストである。手続き中断の場合のモダリティから送られ
る特定の情報についてはIHE TF Vol.2 Table 4.7-1 を参照し、Assisted Protocol Option
についてはSection4.6.4.1.2.4 を参照願います。
Outcomes：モダリティ／ワークステーションが単一の予約手続きを実行、モダリティ／
ワークステーションが手続きを棄却、モダリティ／ワークステーションが予約手続き 2 個
をグループ化実行（Modality Group case Option がサポートされている場合）、モダリテ
ィが予約と異なる手続きを実行、モダリティが予約無しの手続きを実行（下記の PIR セ
クション参照）、モダリティがプロトコルコード付きで予約手続き実施（Assisted Protocol
Option がサポートさせる場合）。
8)
報告用に（例えば CAD ワークステーション）追加して画像を生成したワークステーショ
ンは、RIS にその実施した手続きについて通知することを求められます。(クリエータ処理
手続き進行中、クリエータ処理手続き完了)
シナリオの確認：RISに伝えられた手続きが実際に実施されたものとマッチしているかエ
ビデンス生成により確認すること。下記がそのoutcomesのリストです。
RIS は、手続き取得フェーズにある間は、PACS も含めて院内の他のコンポーネントに状
態アップデート情報を送ります。
9)
RIS は、手続き状態を維持するのみならずその手続きに関係する画像の状態についても維
持します。PACS レポーティングシステムは、手続きの状態のみならず手続きに関した画
像の利用可能な状態にも基づいて報告フェーズを予約します。（利用可能画像）
シナリオ確認：モダリティにおける取得最中の手続きの状態および手続きが報告準備完了とな
るまでの間の手続きの状態を確認すること。画像がPACS上に利用可能になると、これを反映
して手続きについてのRIS状態がアップデートされたことを確認することです。
これらの分野で、詳細なテストセットが適切なデータセット付きで開発される必要があり
ます。RIS は放射線検査部門の中心にあり、従ってこのセットはかなり広範なものとなる
でしょう。それらのデータには下記を含む必要があります：
2005 年 6 月 20 日
25
IHE 放射線ユーザハンドブック
1)
HIS から RIS へ送られる HL7 レコードの開発。(a)それらのレコードは、患者デモグラ
フィック情報および患者オーダ情報等の項目を生成させるために、HIS から RIS へ送ら
れるすべての HL7 メッセージを含むべきです。これには、例えば、患者登録(ADT)メッ
セージ A01(患者受入れ)、A04(患者登録)、A05(予備受入れ)、および一般オーダメッセー
ジ(ORMs)等を含みます。テストされる個々のトランザクションについては IHE TF を参
照願います。(b)それらのレコードには、モダリティへ(MWLs 経由で)伝えられたり PACS
システムへ(DICOM 画像経由で)伝えられたりするすべてのフィールド情報を含むべきで
す。患者デモグラフィック／オーダ情報は、患者氏名、ID、性別、要求手続 ID、AN、お
よび実行された手続き ID を含みます。
2)
RIS から HIS へ送られる HL7 レコードの開発。
（それらはテストの一部として生成され
たデータです。）(a)それらのレコードは、患者デモグラフィック情報および患者オーダ情
報等の項目を生成させるために、RIS から HIS へ送られるすべての HL7 メッセージを含
むべきです。これには、例えば、患者登録(ADT)メッセージ A01(患者受入れ)、A04(患者
登録)、A05(予備受入れ)、および一般オーダメッセージ(ORMs)等を含みます。テストさ
れる個々のトランザクションについては IHE TF を参照願います。(b)それらのレコードに
は、モダリティへ(MWLs 経由で)伝えられたり PACS システムへ(DICOM 画像経由で)伝
えられたりするすべてのフィールド情報を含むべきです。患者デモグラフィック／オーダ
情報は、患者氏名、ID、性別、要求手続 ID、予約ロケーション、モダリティ、予約プロ
トコルコードおよび予約オウロトコル説明を含みます。パラメータの全リストについては、
IHE TF Vol 2 Table 4.5-3 を参照願います。
3)
放射線検査部門の中で使われるべきコードや RIS 上へマッピングの開発。
HL7 から DICOM へのマッピングはシステムセットアップの一部としても生起する必要
があるかもしれません。これは MWLs のようなものにも必要です。もし Assisted Protocol
Code Option が SWF 内でサポートされているなら、プロトコルコードは開発され、RIS
とモダリティの両方のセットアップにも用いられるでしょう。
患者情報の整合性確保(PIR)
RIS の重要な機能は、患者のデモグラフィック情報やオーダ情報が院内で常に最新の情報に保
たれるのを確保することです。患者が通院するとアップデートが必要になります。この情報は
放射線査部門システム全体に適切に広め伝えられる必要があります。以下が SWF の一部とし
て必要となる PIR に関するハイレベルのテストです。
1)
手続き予約の前に患者情報のアップデートを（患者情報更新）
シナリオの確認：患者管理ユーザインターフェースを経由してRIS上に反映されている患
者デモグラフィック、エンカウンター情報(PV‐1)、その他はアップデートされた患者デ
ータだけから成り立っていることを確認してください。HL7 のメッセージ(例えば、患者
氏名、ID、住所、クラス、掛かりつけ臨床医、アレルギータイプ）としてHISが送付する
特定の情報についてはIHE TF Vol.2 Section 4.1.4 を参照願います。
2) 手続き予約の後の患者情報アップデート（患者情報更新）
シナリオ確認：前項と同じです。加えて変更がPACSにも反映していることを確認願います。
3)
画像取得の間の患者 ID の整合性確保（患者情報更新）
シナリオ確認：前項と同じです。変更がPACSにも反映されていることを確認をしてくだ
さい。それから、手続きで生成した画像は表示されたり報告された際に新しい患者デモグ
ラフィック情報を反映していることを確認してください。
4)
手続き予約の前にオーダの置き換えを（検査手続きの更新）
シナリオの確認：登録された患者に対しての手続き情報がRIS上でアップデートされたことを確認
願います。RIS上のオーダ管理ユーザインターフェースを使って予約した患者のオーダ情報を観察
してください。HL7 のメッセージ(例えば、患者氏名、ID、universal service ID)としてRISが送付
2005 年 6 月 20 日
26
IHE 放射線ユーザハンドブック
する特定の情報についてはIHE TF Vol.2 Section 4.4.4.1.2 を参照願います。
5)
手続き予約後のオーダ付け替え（検査手続きの更新）
シナリオの確認：事後に登録された患者に関することは、未登録であった患者であったことの
を確認してください。これは、登録された患者についてRIS上で変更されたことを確認する必
要があるためです。RIS上のユーザインターフェースを使用して予約された患者のオーダ情報
を観察してください。HL7 のメッセージ(例えば、患者氏名、ID、universal service ID)として
HISが送付する特定の情報については、IHE TF Vol. 2 Section 4.2.4 を参照願います。それか
ら、登録された患者の手続き情報は、PACSで変更されたことを確認願います。PACSの
Scheduled Procedure User Interfaceを用いて,予約された患者のオーダ情報を観察願います。
HL7 のメッセージ(例えば、手続き取り消し、手続き変更、手続き中断)としてRISが送付する
特定の情報についてはIHE TF Vol. 2 Section 4.13.1.2 を参照願います。
6)
次のシナリオは、まだ同定されていない患者の登録とオーダ実施に関するものです：(a)まだ
同定されていない患者が HIS で登録され HIS でオーダ発行されました。オーダを実施し手続
きを RIS 経由で予約します。
（患者登録、オーダ発行管理、オーダ実施管理、）。(b)まだ同定
されていない患者が HIS で登録され RIS でオーダ発行されました。
（患者管理、オーダ発行
管理、オーダ実施管理）。(c)まだ同定されていない患者が HIS で登録されたがオーダ発行前
にモダリティで検査完了しました。
（患者登録）(d)HIS で患者登録される前にまたはオーダが
発行される前にモダリティで手続きを実施しました。
シナリオの確認：患者情報がHIS上でアップデートされた後、患者のデモグラフィック情報がRIS
上でアップデートされたことを確認願います。未同定の患者とアップデートされた患者とは同一
であるはずです。HL7 のメッセージ(A40 患者Merge)としてHISが送付する特定の情報について
はIHE TF Vol. 2 Section 4.12.4.4 を参照願います。このプロファイルについてのテストデータの
開発は、HL7 のメッセージタイプの追加がある点を除けば、同じです。
2.2.3.
導入問題を検討する
IHE を以ってしても、据付けは“plug and play”(配線接続したらそれで完了という単純な作業)
ではありません―システムはそれ自身で構成組上げをしてくれる訳ではありません。RIS に対
しては、下記の作業の実行が必要でしょう。
2.2.3.1.
通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)
¾
あなたの DICOM MWL 用に、AE タイトル、IP アドレス、ポートをまとめること。
この情報がすべてのモダリティベンダと共有される必要があり、その結果モダリティ
はあなたの RIS の MWL に問合せを個々に出せる様に構成されます。
¾
あなたの RIS の DICOM MMPS 用に、AE タイトル、IP アドレス、ポートをまとめる
こと。この情報が PACS ベンダと共有される必要があり（もし MPPS マネージャを構成
しているなら）
、その結果 PACS ベンダは MPPS メッセージをモダリティからあなたの
RIS へ転送出来ます。さもなければ、もし RIS が MPPS マネジャとして作動している
ならば、MPPS メッセージを受信し PACS へ転送し、そしてすべてのモダリティはあな
たの RIS の MPPS 構成情報を知る必要が出てくるでしょう。
¾
あなたの HL7 インターフェース用に IP アドレス、あなたの ADT 用のポートおよび
オーダインターフェースをまとめること。同じであることも同じでないこともありま
す。この情報があなたの HIS と共有される必要があり、その結果 HIS ベンダは何処
へ HL7 メッセージを送るか知ることが出来ます。IP アドレスおよび HIS または臨
床情報システムへのポートの位置をはっきり決めること。その結果、手続きアップデ
ートメッセージがあなたの RIS から送られます。最後に HL7 手続きメッセージにつ
いてですが、あなたの RIS がオーダおよび患者デモグラフィック情報をあなたの
PACS へ送れるようにするために、あなたは IP アドレスおよび HL7 オーダのための
ポートを PACS ベンダから入手しておく必要があるでしょう。
相当の時間が、種々のコードを生成し異なるシステム間でコードの同期を採って行くために費やさ
2005 年 6 月 20 日
27
IHE 放射線ユーザハンドブック
れます。コードはあなたのシステム中の様々な部分に使われるためのコードを―性別コードのよう
に単純なものからプロバイダコードのようにより大きなデータッセットに至るまで―取り決めてい
く必要があります。それらコードは手作業で同期を保つ必要があり、もし同期が外れたならば、コ
ードの値を意識することも無いので、受け取り手はデータを受けられないことになります。
2.2.4.
“遺産”システム問題の摘出と対応
IHE 統合プロファイルは、すべての関係するシステムがそれらの統合プロファイルをサポート
することを前提として作られています。もし幾つかのシステムがあなたの選択したプロファイ
ルをサポートしていないか、プロファイルが基礎としている標準規格がサポートしている場合
には、なお幾つかのメリットは達成可能です。もしあなたのシステムに機能欠落があるなら、
短期間はその欠陥を避けて次善策を取る方法と、むしろそのシステムの置き換えまたはアップ
グレードを計画するかを検討することです。
2.2.4.1.
RIS を非 IHE PACS に接続する
RIS と PACS 間の相互運用性は、HIS または RIS 経由で新しい情報または情報のアップデー
トを受け取った場合に患者デモグラフィック情報、オーダや手続き情報が保存（PIR の場合ア
ップデート）されることを可能にします。画像が出来るだけ早く利用可能になるように画像状
態の情報が提供されます。非－IHE PACS の機能に基づき、それらの機能のある部分かすべて
が利用可能となります。以下が、RIS を非 IHE PACS とどの様に統合していくか決める際に
検討すべきガイドラインです。
あなたの PACS ベンダから現在の DICOM 適合性宣言と HL7“インターフェース仕様”を要
求することです。附属書 F 及び G を参照願います。
2.2.4.1.1
通常運用のワークフロー(SWF)
SWF プロファイルにおいて、RIS は PACS に対して、特定の属性を持つか特定の方法で（TF 参照
のこと）メッセージに応答したりして、幾つかの DICOM および HL7 サービスをサポートしている
ことを求めています。重要な DICOM および HL7 サービスは、SCP として DICOM MPPS、SCP
として DICOM 検索／取得、SCP として DICOM インスタンス利用可能通知、および HL7 ORMs
です。
あなたの PACS は、モダリティから DICOM MPPS 状態アップデートを受信する能力を持つべきで
す。これらアップデートは取得の開始および完了についての状態および診断や検査の状態の情報
（Study Instance Unique Identifier および AN）
も含んでいます。
あなたの PACS に DICOM MPPS
機能が欠如している場合には、あなたの新しい RIS は PPS マネジャとしてセットアップされるべき
で、その結果あなたの RIS が状態アップデートの受信が可能になります。
検査が予約された時、あなたの PACS は RIS から HL7“手続き予約済み”メッセージを受け
取ります(Radiology TF Vol.2.4.4 参照)。このメッセージには患者デモグラフィック情報、予約
手続きスッテップ、RIS 生成の AN および Study Instance Unique Identifier が含まれます。
これが PACS に受信する画像を正しい患者情報、および検査、と関係付け、関連する以前の画
像をプリフェッチします。HL7”手続き予約済み“メッセージを受信する能力を持たないと、
モダリティがオーダとマッチしない画像を保存する時に、PACS オペレータは手作業で患者デ
モグラフィック情報や検査特有の情報（例えば AN）を入力し整合性を与えることを求められ
ます。それから、PACS は現在の画像を受信始めると同時に関連する以前の画像のプリフェッ
チを始めます、HL7 メッセージを受信した時にではありません。HL7 メッセージを受信して
そのオーダを PACS がサポートするメッセージに変換する機能を持つ仲介／インターフェー
スエンジンを使用することも出来ます。これらの次善策は明らかに時間がかかり、非標準の度
合いにもよりますが、実装するために高価につくでしょう。
2.2.4.1.2.
患者情報の整合性確保(PIR)
PIR プロファイルでは、RIS は PACS に特定の属性を使用したりメッセージへの応答の方法を
指定したり(TF 参照)して幾つかの HL7 サービスをサポートすることを求めます。重要
2005 年 6 月 20 日
28
IHE 放射線ユーザハンドブック
な HL7 サービスは、HL7 更新 ORMs および HL7 患者更新メッセージ(ADTs)です。あなたの
PACS は、患者デモグラフィックまたは手続き情報が変更される時か、二人の患者が一人に合
併されるような時に、RIS から HL7“患者更新“メッセージ(Radiology TF Vol. 2.4.12 参照)
および”手続き／オーダ更新“メッセージ(Radiology TF Vol. 2.4.13 参照)を受信できなければ
なりません。PACS は RIS から受信する HL7 患者デモグラフィックおよび手続き／オーダ更
新メッセージを受け取ると、PACS オブジェクトに中の患者およびエンカウンタデータをアッ
プデートし最新のデータに保ちます。この機能は同定されていない患者（精神的外傷傷害：ト
ラウマ）や誤って同定された患者の場合に特に重要です。
PACS が適切な HL7 ADT および／または ORMs を受け取る能力を持たない場合は、PACS の
患者データとエンカウンタデータの情報整合性を保つ能力に制限が生じます。この場合、モダ
リティがオーダとマッチしない画像を保存する時に、PACS オペレータは手作業で患者デモグ
ラフィック情報や検査特有の情報（例えば AN）を入力し整合性を与えることを求められます。
HL7 メッセージを受信してそのオーダを PACS がサポートするメッセージに変換する機能を
持つ仲介／インターフェースエンジンを使用することも出来ます。
2.2.4.2. RIS を非 IHE モダリティに接続する
RIS とモダリティとの間の相互運用性は、HIS および／または RIS 経由で患者デモグラフィック情
報、オーダや手続き情報がモダリティへ伝えられることを可能にします。画像が出来るだけ早く利
用可能になるように、モダリティで手続き状態の情報が提供されます。非－IHE モダリティの能力
に基づき、それらの機能のある部分かすべてが利用可能となるでしょう。以下が、RIS を非 IHE モ
ダリティとどの様に統合していくか決める際に検討すべきガイドラインです。
あなたのモダリティベンダからあなたの医療機関に据え付けられている製品の各々について、
現在の DICOM 適合性宣言を要求することです。附属書 F を参照願います。
2.2.4.2.1 通常運用のワークフロー(SWF)
SWF プロファイルにおいて、RIS はモダリティに対して、特定の属性を用いたりそして特定
の方法で（TF 参照のこと）メッセージに応答したりして、幾つかの DICOM サービスをサポ
ートしていることを求めています。重要な DICOM サービスは、SCU として DICOM MWL、
SCU として DICOM MPPS です。モダリティは RIS から患者情報やオーダ情報を検索するの
に DICOM MWL を使用すべきです。IHE は属性を拡張しモダリティ上で表示されます。以下
の IHE 拡張の属性がモダリティ上のワークリストで表示されていることを確認してくださ
い：予約手続きステップ開始日／時、予約手続きステップ説明、手続き説明、手続き ID、AN、
紹介掛かり付け医氏名、および患者氏名、ID、誕生日付、性。
モダリティは DICON MPPS を RIS システムへ発信して取得状態（進行中、完了）を追跡し、取得ルー
プを閉じワーク実施完了の追加信号を出し料金請求プロセスへと進めさせます。この機能はより後の段
階でモダリティと登録システム両方のベンダと交渉して実装することも出来ます。もしあなたのモダリ
ティが DICOM サービスの一つまたは両方をサポートし損なっているならば、RIS を非‐DICOM モダ
リティに接続することについての次のセクションを参照願います。
2.2.4.3.
RIS を非‐DICOM モダリティに接続する
あなたのモダリティが DICOM MWL および／または DICOM MPPS をサポートしないので、ベン
ダから要求できる標準準拠の適合性宣言は存在しません。あなたのモダリティベンダに患者情報お
よび検査情報を問合せ／受信するベンダ固有のメカニズムの説明を求めることです。取得装置に
DICOM MWL 機能が無いと、患者情報および検査情報を問合せ／受信する可能な次善策は：バーコ
ードを利用する（少なくとも不可欠な識別用データにアクセスする代替法）
、
（半）ベンダ固有のイ
ンターフェースから DICOM へのモダリティゲートウエーを利用する（追加のコストおよび／また
はメンテナンスの負担増加）
、及び RIS ターミナルで読み取ったかハードコピー上のデータをモダリ
ティで手入力する、などです。
2005 年 6 月 20 日
29
IHE 放射線ユーザハンドブック
モダリティが持つべき重要な情報は、基本的な患者デモグラフィック情報、RIS-指定の AN、
そしてもし可能なら、RIS-指定の Study Instance Unique Identifier（病院内でデータ一貫性
を確保するために）です。取得装置に DICOM MPPS 機能が欠如しているなら、検査状態を報
告する可能性のある次善策は：(a)モダリティに代って MPPS を送信する“仲介”システムま
たは PACS オプション、その様なシステムはしばしばモダリティに Worklist Function を提供
します。(b) PACS は“頼みの綱モード”を持ち検査状態を推定することを可能にします（そ
の方法とはモダリティや RIS からの Storage や Storage Commitment または他のイベントや
トリガーに基づいて）、(c)モダリティ上で RIS ターミナルを各モダリティ近くに置き手作業で
検査状態アップデートを手入力します、などでしょう。
2.2.4.4.
RIS を非 IHE HIS に接続する
RIS と HIS の間の相互運用性は、患者デモグラフィック情報やオーダ情報が RIS や院内の他
の放射線部門に受け渡されることを可能にします。画像が出来るだけ早く利用可能になるよう
に、画像状態の情報が提供されます。非 IHE HIS の能力に基づいて、それらの機能のある部
分か、すべてが利用可能となるでしょう。以下が RIS を非 IHE HIS に統合して行くか決める
際 に 検 討 す べ き ガ イ ド ラ イ ン で す 。 あ な た の HIS ベ ン ダ か ら 現 在 の HL7 “ interface
specification”を要求すること―附属書 F および G を参照願います。
2.2.4.4.1
通常運用のワークフロー(SWF)及び患者情報の整合性確保(PIR)
SWF プロファイルにおいて、RIS は HIS に対して、特定の属性を持つとか特定の方法で（TF 参照
のこと）メッセージに応答するとか幾つかの HL7 メッセージタイプを、サポートしていることを求
めています。重要な HL7 メッセージタイプは、(a)HL7 患者登録メッセージ、および(b)HL7 手続き
‐オーダメッセージ、であり、それぞれ求められるものは以下の通りです。(a)についてはミニマム
として（あなたの施設の機能にも依るが）ADT メッセージ中の(ⅰ)A01,入院患者の訪問の登録、
(ⅱ)A04,外来患者の訪問の登録、A08,患者情報のアップデート、および(ⅲ),A40,患者の統合、およ
び(b)については(ⅰ)新しい ORM,(ⅱ)ORM 取り消し、などです。
この HL7 メッセージのミニマムセットがあれば、患者デモグラフィックおよび訪問情報を HIS から
RIS へ伝える基本的機能を提供することが出来ます。それらは又患者デモグラフィックの如何なるア
ップデートでも、二人の患者を統合して一人とする作業でもこなせます。必要な IHE 定義の HL7 メ
ッセージの完全なリストは、Radiology TF Vol. 2 4.1‐4.4 および 4.12 を参照願います。
手続き‐オーダメッセージが HIS にオーダを生成し ORMs を RIS に予約用として送ることを
可能にしています。この基本的な HL7 機能のサポート無しには、患者および／または検査の
ID 管理が院内で一貫性を保つことは不可能です。例えば、もし HIS が HL7 メッセージ経由
で患者アップデートや統合を RIS に伝えられなければ、RIS は患者アップデートまたは患者統
合の操作を直接に行なう機能を持たざるを得ません。
典型的には、HIS と RIS の間でお互いの間のメッセージ変換を司るインターフェースエンジ
ンが存在します。このエンジンは RIS と HIS の間で共有して使われる HL7 メッセージの小修
正にも対応し、または、もし HIS が HL7 をサポートしないならば、インターフェースエンジ
ンはその機関だけに通用する固有のメッセージを HL7 メッセージに変換したり、その逆を行
なったりすることも可能です。IHＥはまた、HIS にオーダアップデートを受信するために双
方向性のインターフェースをサポートすることを求めています。双方向性のインターフェース
無しには、つぎのような問題点が発生してくるでしょう：(a)オーダがもし RIS で入力された
ら HIS で再入力されなければなりません。(b) HIS は患者や検査について最新の情報を持てな
くなります。
(c)オーダがRISで発行される際に、HL7メッセージハンドシェーキング(General Order
Response Manager)が起り、RIS が HIS からオーダ番号を取って来ることを可能にしています。
HIS が HL7 をサポートしないなら、ベンダにインターフェース仕様を提出するように求めることで
す。
これを RIS ベンダまたはインターフェース分析家に渡し機関専有のデータを HL7 へ送信／から
受信する際の処理方法を決定させることです。附属書Ｇを参照願います。
2005 年 6 月 20 日
30
IHE 放射線ユーザハンドブック
3.
シナリオ：統合度の高い PACS の据付け
放射線検査部門は、新しい大規模な統合 PACS を導入したいと考えています。検査規模の増大、
幾つかの部門での検査数の増加、HIS および電子式オーダエントリシステムとの統合の改善が
重要な論点です。新しい PACS は病院のすべての部門に対して画像のデジタル保管、診療活動
やレポーティングのデジタル化を目標として利用されます。
多くのモダリティは検査結果を PACS へ保管します。DICOM 機能を部分的にしか、または全
く持たないかなり古い遺産のモダリティがいくつかあり、これに対する次善策が求められます。
読影はワークステーション上でソフト-コピーレビューされます。ワークステーションには限ら
れた数のフィルムプリンタしか接続されず、フィルムプリントは外科用、照会用、教育用です。
報告はまだ書き取りおよび筆写で行なわれていますが、電子式レポーティングシステムへのア
ップグレードを計画しています。
PACS はソフトコピーとハードコピーの両方で読影の画像源となります。長期保管は最終的に
はフィルムからデジタルに移行するでしょう。放射線検査部門は、地域の他の医療機関への読
影サービスもまた実施しています―セカンドオピニオンを求めて、または特化専門医の診断を
求めて、他の医療機関から当院 PACS へ送られて来る撮影画像の読解をです。診断結果（画像
と報告書）は照会元へ電子的に、フィルムで、またはＣＤで送付されます。
3.1.
購入計画と購入プロセス
購入意志決定の権限を持つ管理者向けに、このセクションは RIS システムの要求事項を決める際に
考慮すべき組織の目標をリストアップし、
それら目標に応じて IHE 統合プロファイルの選び方、
IHE
要求事項の明確な記述方法およびベンダの応答を理解する方法を列記しています。
3.1.1.
組織目標の達成
臨床現場にIHEの取り組みを実行展開するメリットは20以上の医療センターにより報告されていま
す。それらIHEサクセスストーリーの詳細は次のサイトで入手できま
す。www.ihe.net/resources/success_stories/index.html.
明確に組織の目標を特定することはいかなる装置の取得においても重要な最初のステップで
す。各々の IHE 統合プロファイルは特定の組織目標の組合せに応じるように設計されていま
す。下記が、新しい PACS を取得しようとする際に医療機関が抱く組織目標および各々の関係
する統合プロファイルが組織目標をサポートする際に果たす貢献を示す理論的なリストです。
エラーを減少させ患者へのケアを高める
PACS 上の通常運用のワークフロー(SWF)
¾
患者の識別ミスの防止、PACSはRISからのORMs（患者デモグラフィックやオーダ
詳細を含んでいます）を監視しモダリティから受信する相当する画像をチェックする
ため。
¾
不正確な診断の防止（画像の紛失による）、PACSはMPPSおよび保存委託(Storage
Commitment)を用いてモダリティと一緒にPACSへ送付された画像検査のリストを
確認するため。
¾
画像利用可能となるまでの時間遅れの減少、PACSはRISからの画像利用可能問合せ
に応答するため。
¾
Instance Availability Notification Option(in SWF) on the PACS：
2005 年 6 月 20 日
31
IHE 放射線ユーザハンドブック
¾
レポーティングの遅れを減少する、画像データが利用可能になるとPACSはレポート
システムや他の関係のあるシステムへ通知を送るため。
¾
読影ミスの防止（全画像が揃う前に放射線科医が初期読影を開始）、PACSは全撮影が
利用可能になって始めてレビューシステムへ通知するため。
PACS 上で患者情報の一貫性確保(PIR)：
¾
患者のデモグラフィック情報のエラーを減少させる、PACSはRISメッセージを患者
情報へのアップデート付きでモニタしているため（John Does識別問題、登録エラー
の修正、患者レコードの統合）。
¾
手続きの細部のエラーを減少させる、PACSはRISメッセージを手続き検査情報のアップ
デート付きでモニタしているため（予定変更とか手続き内容の変更による）
。
¾
誤診断を防止する（他人へファイリングされデータが紛失し）
、PACSは患者およびオー
ダ情報の初期値とアップデートを追跡して保存し迅速にPACS内で同期を採る。
¾
トラウマケアでの遅れを防止、PACSはデータを通常通りに取り扱うが、一旦患者が同定
されると画像、レポート、その他の医療レコードと突き合され整合がとられます。
PACS 上の可搬用画像データ交換(PDI)：
¾
他の医療機関からのデータの紛失を防止、PACSはCD上のデータセットをインポート
し患者のレコードと統合できるため。
¾
患者識別子のミスマッチを防止(他の機関からのCDからインポートされたデータの)、
PACSはインポート時にこの値をローカルな値に整合させるため。
¾
患者の心の平安を高める、PACSは患者の個人的なヘルス情報のCDコピーにストレー
トにアクセス出来るため。
PACS 上の画像表示一貫性の確保(CPI)：
¾
誤診の減少（画像の低コントラストによる）：PACSは表示をGrayscale Standard
Display Function curveに応じて較正されているため。
¾
、
誤診の減少（ウィンドウ、フリップ、シャッター等の誤った設定による低質表示の画像）
PACSは画像表示の適切な視認設定を保管されているGSPSで行なうため。
¾
読影をミスリードしやすい画像の差を防止（臨床医と撮影技師の画像の差による）
、PACS
が画像表示状態を決めるので、両方の表示システムが同じ方法で表示されるため。
PACS 上の複数ソースオプション（放射線科検査情報へのアクセスの）：
¾
不完全な画像レコードの減少、他の情報保管庫（循環器系PACS、長期保管庫、その他）
から臨床的に関係のある追加データへも統合化されたアクセスが出来るため。
PACS 上のキーイメージノート(KIN)：
¾
臨床的に重要な画像を発見する難しさを防止。PACSは照会医、外科医、その他の方
からの患者デモグラフィックな問合せ、アクセス、表示などに対してキーとなる重要
な画像上にフラッグを立てたり注記したり出来ます。
2005 年 6 月 20 日
32
IHE 放射線ユーザハンドブック
PACS 上のエビデンス文書：
¾
臨床データの不完全さの防止、PACSは臨床上の測定値、CADの結果または超音波検
査も組み込んだレポート等を含むエビデンス文書を保管し提供するため。
PACS 上の画像・数値を含む報告書(SINR)：
¾
臨床データの不完全さの防止、PACSは臨床テキスト、測定値、画像などを統合する
診断報告書を保管し提供するため。
処理量の増加
PACS 上の通常運用のワークフロー(SWF)：
¾
以前の画像の待ち時間の減少、PACSはRISからの予約情報をモニタし検査が予約さ
れた時点で以前の情報の検索を開始する、画像取得後に開始するのではありません。
¾
、PACSはモダリ
検査結果の紛失の防止（PACSへ送信済みと勘違いしモダリティで削除）
ティに画像の所有権を取ったことを保存委託メッセージで明確に確認するため。
¾
撮影技師の確認時間の節約、PACSは保存委託サービスを利用することで保管成功を
伝え、撮影技師側が人間作業で受領確認する時間を節約できます。
¾
初期読影の遅延の減少、PACSは取得の進行中をモニタし完了をメッセージで返すの
で、撮影技師は現在の状態を常に把握出来るため。
PACS 上の Instance Availability Notification Option(SWF 中で)：
¾
後処理遅れの防止―PACSは画像が後処理作業待ちの状態になるや否や後処理マネジ
ャに通知を出すため。
¾
報告遅れの減少、PACSは画像が利用可能になると報告マネジャに通報します。
PACS 上で患者情報の整合性確保(PIR)：
¾
患者デモグラフィックの手動による再入力の防止―PACSはRISから患者デモグラフ
ィックおよび予約手続き情報のアップデート付き情報を受け取るため。
¾
手作業での整合性確保の作業を減少(PACS中の不正確な患者および手続き情報の)、
PACSは変更の多くを受信した情報に応じて自動的に修正するため。
PACS 上の複数ソースオプション(放射線情報へのアクセスにおいて)、
¾
複数システムへの手作業検索の防止(関連する患者データを求めて放射線科PACS、循
環器科PACS、院内長期保管庫)―PACSは複数システムからのDICOMデータの総合
的な閲覧を可能にするため。
PACS 上の画像表示一貫性の確保(CPI)：
¾
放射線科医のディスプレイ設定の調節時間の減少―PACSはモダリティでされた表示
の状態設定をそのまま使うため。
¾
放射線科医のモニタ設定に時間の減少―表示装置をDICOM Grayscale Standard
Display Function curveに較正してあるため。
2005 年 6 月 20 日
33
IHE 放射線ユーザハンドブック
PACS 上の複数検査手続きの一括撮影と表示(PGP)：
¾
放射線科医の関連画像捜索の時間浪費の防止（グループ一括取得の中から該当画像を
探し出す）―PACSは技師により予め選択された関連画像を表示するため。
¾
放射線科医のディスプレイ設定の調節時間の減少（グループ一括撮影でＣＴの異なっ
た部分（頭部、胸部）毎に設定を調節）―PACSはモダリティで各部分に対して行な
われた最適設定を用いて表示するため。
¾
放射線科医の画像セットを手作業で分割する時間を削除―PACSは適切にラベル付けされた表
示状態（バーチャルスプリット）によって各オーダ毎の画像へアクセスできるため。
PACS上でのエビデンス文書：
¾
放射線科医の複数ワークステーションアクセス時間の減少―PACSはPACS診断ワー
クステーション上でCAD結果、モダリティ測定、および超音波構造化報告書などの非
画像データも表示可能であるため。
PACS 上で可搬用画像データ交換(PDI)：
¾
他の機関からの以前のフィルムをスキャンする時間の防止―PACSはCD上で画像の
インポートや検査のまとめをサポートするため。
PACS 上のキーイメージノート(KIN)：
¾
外科医の重要画像捜索時間の防止―PACSはキーイメージノートを使って直ちに直接
に放射線科医が立てたフラッグの付いた画像へアクセス出来るため。
データへのアクセスの改善
PACS 上の可搬用画像データ交換(PDI)：
¾
他の機関のデータへのアクセスの改善―からの以前のフィルムをスキャンする時間
の防止―PACSは他の医療機関のCDから患者や診断の情報をインポートし、うまく折
り合いをつけて活用させることが出来ます。
¾
臨床データコンシューマのアクセスの改善（照会開業医、セカンドオピニオン放射線
科医、神経外科医、整形外科医、他の病院診療所、紹介者等）―PACSは、信頼でき
る高速ネットワーク接続がない場合は、CDで患者や診断情報をエクスポートするこ
とが出来ます。
¾
患者情報の可搬性の改善（HIPPA問題、医療保険の相互運用性と説明責任に関する法
律、米国連邦法）―PACSは患者の画像歴をCDに収め標準的な配布を行ないます。
PACS 上の Web Option(PDI 上)：
¾
単純なウエッブブラウザーからのアクセスの改善（患者、照会開業医、その他）―PACS
はDICOM画像のウェッブ可視版(JPEG,HTML)および報告書を同じCD上に一緒に
収められます。
PACS 上の放射線情報へのアクセス(ARI)：
¾
病院周囲からのアクセスの改善―PACSは表示ワークステーション上でDICOM画像
やデータの問合せ／検索をサポートしています。
2005 年 6 月 20 日
34
IHE 放射線ユーザハンドブック
PAC 上の複数ソースオプション(ARI)：
¾
複数のPACSからのデータへのアクセスを改善―ワークステーションは物理的に別個
のシステム（超音波ミニPACS、循環器PACS、および放射線PACS）への問合せ結果
やアクセスデータを統合します。
PACS 上のキーイメージノート(KIN)：
¾
最重要画像へのアクセスの改善―PACSは、問合せ可能なフラッグを立てる仕組みを
使って、キー画像を大きな検査画像セットから即座に分離して取り出します。
画像品質の維持／改善
PACS 上の画像表示の一貫性確保(CPI)
¾
一貫性の無い画像表示の防止―PACSは、モニタ上に表示したりフィルム上に印刷し
たりする際に、一貫して同じウインドウレベル、コントラスト、フリップ、ズーム、
ユーザ注記、等を使用し表示状態を同一に保ちます。
¾
不正確で一貫性の無い画像表示の防止 ―PACSの表示装置はDICOM Grayscale
Standard Display Functionを用いて標準に較正されています。
運用コストの低減
PACS 上のワークフロー(SWF)、画像表示の一貫性確保(CPI)、および複数検査の一括撮
影と表示(PGP)：
¾
人員増加の防止、上述の効率化と処理量増加によります。
PACS 上の可搬用画像データ交換(PDI)：
¾
他の機関への照会、紹介してきた開業医、または外科等への不必要なフィルムを減少
させる、何故ならばモダリティは可搬用画像データ交換の CD を生成しそれらユーザ
へ送付するため。
PACS 上の通常運用のワークフロー(SWF)：
¾
大幅にフィルム印刷、管理、保管のコストを削減、PACSのディスプレイ装置は画像
をフィルム用でなくソフトコピーレビュー用の画像を表示します。
患者被爆線量の減少
PACS 上の通常運用のワークフロー(SWF)
¾
取得の繰り返しを防止（検査結果の紛失による）、検査結果の紛失防止策は処理量の
セクションに記載済みです。
PACS 上の画像表示の一貫性確保(CPI)：
¾
取得の繰り返しを防止 （コンシューマの受信する劣悪な画質による）、PACSは
DICOM較正と保管されている表示状態を用い、すべてのコンシューマに同じ高画表
示を提供するため。
PACS 上の複数検査手続きの一括撮影と表示(PGP)：
¾
複数回のスキャンおよびセットアップを防止、PACSは関連する複数画像のサブセッ
トにアクセスする表示状態を用いてモダリティに一回のスキャンでグループ化した
取得を行なえるため。
2005 年 6 月 20 日
35
IHE 放射線ユーザハンドブック
運用展開するコスト／時間の減少
PACS 上の全 IHE プロファイル：
¾
カスタムインターフェース仕様に掛かる時間とコストの防止―IHE TFは多くのベンダに
サポートされテストされた強力なインターフェースの詳細な仕様を提供しています。
¾
カスタムインターフェース実装に掛かる時間とコストの防止―多くのIHE統合プロ
ファイルは既に多くのベンダによってサポートされています。
¾
インターフェース規格適合性テストの時間とコストの減少―たくさんの実装派生品
がIHEコネクタソンでシステムテストされ問題点を綺麗に解決しています。
¾
システム間テストの時間とコストの減少―システム間の組合せの色々な例が既に
IHEコネクタソンで一緒に直接接続テストされています。
¾
カスタムインターフェースメンテナンスの時間とコストの減少、複数のカスタムインタ
ーフェースではなく単一のIHEインターフェースのみのメンテナンスで済みます。
常に単一の装置の購入によってすべての組織目標に対応できるとは限りません。IHE 統合プロファ
イルのメリットをフルに達成するには、その PACS を取り巻き交信し合うシステムもまたプロファ
イルに定義されたような役割を果たしてくれることが求められています。しばしば、PACS のよう
な単一のアクタ上で統合プロファイルが実装されていて、そのアクタが置かれている環境は、アク
タと交信し合うシステムがプロファイルに述べられた機能をいくつか持ってはいるがすべてではな
いという場合には、統合プロファイルの持つメリットは部分的には達成されます。附属書 A で、要
求事項をシーケンシャルに考慮し個々の購入を長期計画の一環として計画することを総合的に討議
しています。組織の目標に向かっての進歩の後を追い投資利益率を求めていくには、良く定義され
た一組の活動状況を定量的に計測する方法が求められます。―附属書 I を参照願います。
3.1.2. IHE 統合プロファイルとアクタを選択する
購入しようとするシステムの統合要求事項を具体的に定めていくことは、どの IHE 統合プロ
ファイルとアクタがサポートされて欲しいか選択することを含みます。幾つかのプロファイル
は、あなたがまた選択しようとするかもしれない追加機能を提供するオプションを持っていま
す。PACS の購入に関係する統合プロファイルおよび各プロファイル PACS で果たす機能を以
下に述べます。
通常運用のワークフロー(Scheduled Workflow(SWF))および患者情報の一貫性確保(PIR)がPACSシス
テムを統合する際の最も基本的で不可欠なものです。この二つの統合プロファイルが、典型的な画像
情報の流れおよびある例外ケースにおいて患者ケアを能率よく進めるためのシームレスな情報の流れ
を確立します。確立の方法は、登録からオーダ発行、スケジューリング、画像取得、保管等を経由し
て画像表示まで、患者情報を一貫して保持するようなトランザクションを規定することによって行な
われます。大きな医療機関は、この二つのプロファイルからスタートし具体的なニーズと優先度に基
づいて追加するIHE統合プロファイルを補っていきます。
IHE画像表示の一貫性確保プロファイルは、画像品質、その一貫性、および読影診断プロセス
に於ける重要性から、同様に強く推薦されます。
¾
IHE放射線部門情報へのアクセスプロファイル、画像やレポートを他科（例えば整形
外科、脳神経外科）へ利用可能にします。
¾
IHE複数検査手続きの一括撮影表示プロファイル、グループ化して撮影表示を一括処
理を能率よく行ないます。
¾
IHE可搬用画像データ交換プロファイル、画像データを可搬型媒体CDに書込みまた
はCDからインポートします。
¾
IHE Radiology Option (in the Audit Trail and Node Authentication Profile)、セキ
ュリティ及びプライバシー関連の監査証跡(Audit Trail)を生成します。
2005 年 6 月 20 日
36
IHE 放射線ユーザハンドブック
¾
IHEキー画像への注釈プロファイル、種々の目的のため画像に関連する注釈テキスト
（短文）を付箋付けして保管、アクセス、表示することが出来ます。
¾
IHEエビデンス文書プロファイル、計測値やCAD結果をPACS上に保管し表示します。
¾
IHE核医学画像プロファイル、核医学画像および結果スクリーンを適切な臨床表示さ
せたり保管させたりします。
¾
IHE画像・数値を含む報告書プロファイル、DICOM規格に基づく報告書を保管し、
管理します。
画像データ管理／保存アクタが PACS システムによって果たされている重要な役割です。ほと
んどの PACS も又、画像データ表示アクタおよび PPS 転送アクタの役割を果たしています。
PACS が果たしている他のアクタの役割を追加するなら：
¾
エビデンス生成アクタ、再処理された画像、計測値追加、CAD結果等のデータ生成。
¾
メディア生成アクタ、画像データをCDに書き込む。
¾
メディアインポートアクタ、CD上の画像データをPACSへインポートする。
¾
（画像を
プリントデータ生成アクタ、プリントリクエストをDICOMプリンタに送る。
“非デジタル”ユーザへ配布するため）
¾
レポート生成アクタ、画像や他のエビデンスの解釈を含む内容の報告書を生成エクス
ポートする。
¾
レポート管理アクタ、診断報告書や報告プロセスの管理を行なう。
¾
レポート保存、診断報告書を保存し配布する。
¾
レポート表示アクタ、診断報告書を検索・表示する。
¾
セキュアノ－ドアクタ、監査記録へアクセスするデータを生成する。
¾
監査記録アクタ、監査記録及びアクセス記録のアーカイブ。
各プロファイルおよびアクタにより発揮されるメリットについては以前のセクションで概説
されています。更に詳しい情報は、附属書 B を参照願います。
3.1.3.
あなたの RFP に統合要求事項を盛り込む。
あなたのＲＦＰの中に IHE の機能サポートを求めるのはとても簡単で、システムにどの IHE 統合
プロファイル（およびオプション）をシステムにサポートして欲しいか、および各プロファイルの
中でどの IHE アクタの役割をシステムは果たすべきかを述べるだけでよいのです。
以下に全仕様を備えた PACS のプロファイルとアクタを指定するサンプルステートメントを
示します。：
¾
PACS は以下の IHE 統合プロファイルの中で画像データ管理／画像データ保存アク
タをサポートすること：通常運用のワークフロー、患者情報整合性の確保、画像表示
の一貫性確保、複数検査手続きの一括撮影と表示、放射線科情報へのアクセス、キー
イメージノート、エビデンス文書、核医学画像、および Radiology Option of Audit
Trail and Node Authentication。
¾
PACS は以下の IHE 統合プロファイルの中でエビデンス生成／アクタおよび画像デ
ータ表示アクタをサポートすること：通常運用のワークフロー、画像表示の一貫性確
保、放射線科情報へのアクセス、キーイメージノート、エビデンス文書、核医学画像。
2005 年 6 月 20 日
37
IHE 放射線ユーザハンドブック
¾
PACS は IHE 可搬用画像データ交換統合プロファイルの中で可搬用画像データ書込
み、可搬用画像データ読み込み、プリント生成、画像データ表示、およびレポート表
示の諸アクタをサポートすること。
¾
PACS は IHE 画像・数値を含む報告書統合プロファイルの中でレポート管理、レポ
ート保存、レポート表示、およびレポート生成の諸アクタをサポートすること。
RFP プロセスの更に詳細な議論は、附属書 C を参照願います。
3.1.4.
適切な製品を選択する
あなたは可能性のあるベンダの広いグループに直接あなたの RFP を送ることを選ぶことも出
来ますが、どのベンダが関係する IHE 統合機能を充足しているかを公開された情報源に照会
することも出来ます。そのような情報源については、附属書 D を参照願います。
3.1.5.
ベンダからの統合宣言書を理解する
ベンダはあなたの RFP に応じて IHE 統合宣言書資料を提出するでしょう。多くの製品の IHE
統合宣言書は、以下からも利用可能でです。
www.ihe.net/Resources/ihe_integration_statements.cfm.
統合ステートメントは、特定ベンダの特定の製品がどの IHE プロファイル、アクタ、オプシ
ョンをサポートしているかの直接的な宣言です。統合宣言の内容については附属書 E を参照願
います。
3.2.
システムの全体構成と実装プロセス
以下のセクションは実装チームを意図して作られました。IHE 機能を持つ PACS を実装展開
する際の重要な臨床上および IT 上の諸々の考慮すべき点を述べます。IHE プロファイルを充
足していないシステムに RIS を接続する際のいわゆる“遺産”問題にどのように対応するかに
ついても触れています。
3.2.1.
あなたのワークフローの変更を検討する
IHE プロファイルは流れるような臨床ワークフローの中にデジタル画像情報システムを実装
するように設計されています。例えば、紛失したフィルムフォルダーの捜索とか PACS 上の患
者フォルダーのミスマッチの解消とかのために、モダリティで患者情報を入力しようとするニ
ーズを拒否し受け付けません。画像は直ちに表示可能となります。そのような変更のメリット
をすべて享受するには、幾つかのタスクは正しい方法で実行されなければなりません。
3.2.1.1.
通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)
SWF および PIR プロファイルは、患者デモグラフィック情報、オーダおよび手続き情報は正
確で院内中に一貫性があることを保証するために用いられます。更に、内部システム状態アッ
プデートは、臨床データへのアクセスをよりタイムリーな方法で行なってくれます。HIS およ
び RIS のシステムアップデートが PACS に広く伝播するので、放射線科医は安心して患者デ
モグラフィック情報やオーダ・手続き情報を信頼して使えます。放射線科医は特定の検査につ
いて現在の画像状態の情報も提供されることも追加しておきます。
3.2.1.2.
画像表示の一貫性確保(CPI)
CPI プロファイルは、どんなモニタ機器やプリンタ装置が使用されても、画像の表示はその医
療機関中で一貫性が保たれることを保障しています。PACS 上で、放射線科医は画像だけでな
く画像の表示状態オブジェクトの存在とその意味を良く知っていなければなりません。表示状
態については、放射線科医がどの設定を用いるか直ぐに分かるように（例えば PACS ワークス
テーションで最後に見た画像画面が求められる際に）、充分に理解された区別しやすい説明文
言が使われなければなりません。
2005 年 6 月 20 日
38
IHE 放射線ユーザハンドブック
同様に、放射線科医も何か新しい表示状態を作ろうとする際には、それらの充分に理解された
区別しやすい説明文言が使わなければなりません。
IT 関係者は、使用されるすべてのモニタおよびフィルムプリンタの画像表示の一貫性保持のた
め、Grayscale Display Function Standard(DICOM PS3.14)に準拠してモニタやプリンタを定
期的に較正するでしょう
3.2.2.
システムの作動を確認する
以下のセクションは、PACS が実装されたそれぞれの統合プロファイルに従って作動している
ことを確認する方法のガイダンスです。各セクションは PACS 関係するプロファイルを一つず
つテストして行く項目を示します。しばしば、データとトランザクションを確認するにはここ
に述べる以外の別の方法もあるということには留意してください。テストを進める戦略の入門
として、附属書 H を参照願います。
3.2.2.1.
通常運用のワークフロー(SWF)
PACS にとっては、実行された手続きとそれに続くワークステーションのレンダリングで得ら
れる DICOM 画像や関連する DICOM オブジェクトが永久保管されるが重要です。更に、ワー
クステーションが後処理やレポート作成のフェーズにある間に利用可能な情報に問い合わせ
や検索をかけられることが極めて大切です。以下は、SWF 機能確認用に新しい PACS 上で実
施する必要があると思われるハイレベルのテストの例です。
1)
各々の関係するモダリティに対して、モダリティ上の予約に従って予約された手続きを、
画像の利用可能状況を確認しながら(MPPS complete、Image Availability)、実行完了さ
せること。また、(a)モダリティ上で予約されていない手続きを、そのモダリティ上で患者
デモグラフィック情報および手続き情報を入力して（バーコードからでも手入力でも）、
実行すること。(b)ある予約済み手続きを放射線科医が得られた画像をレビューした後、新
しい手続きを予約手続きに追加してください。そして(c)その手続きが完了する前にモダリ
ティじょうで手続きを棄却してください。
2)
モダアリティからの画像を PACS システムに保存してください（自動保存でも手動保存で
も）。（Modality Image Stored）
シナリオの確認：モダリティ上に生成された画像がPACSシステム上に保存されたことを
確認します。それから、RIS(またはPACS)上の手続き状態がモダリティ上で進行する手続
きに基づいてアップデートされてきたことを確認します。利用可能な画像の数が取得され
た画像の数と一致することを確認します。
3)
PACS が画像の所有権を主張する(Storage Commitment)前に、モダリティから画像を削
除することを試みます。
シナリオの確認：画像がPACSシステム経由で永久保存されたものでなかったため、モダ
リティ上の画像は削除出来ないことを確認します。
4)
PACS が画像所有を宣言した後(Storage Commitment)、モダリティから画像を削除する
ことを試みます。
シナリオの確認：画像がPACSシステム経由で永久保存されたため、モダリティ上の画像
は削除出来たことを確認します。
5)
医療機関内のモダリティタイプの各々について、画像を PACS から表示させます。(Query
Images, Retrieve Image)
シナリオの確認：画像がPACSから検索され適切に表示されることを確認します。それか
ら、RIS上の患者デモグラフィック、オーダ、手続き情報が表示画像のそれと一致するこ
とを確認します。
6)
画像の後処理を行い PACS に保存します。(Creator Images Stored)
2005 年 6 月 20 日
39
IHE 放射線ユーザハンドブック
7)
シナリオの確認：画像がPACSから検索され適切に表示されることを確認します。
これらの分野で、詳細なテストセットが適切なデータセット付きで開発される必要があります。
それらのデータセットには、モダリティから PACS へ送られるべき画像と各モダリティに生成
された予約手続きの準備を含める必要があります。その目的は、モダリティから生成された
DICM 画像が、重要な患者デモグラフィックおよび手続き情報と後処理用にワークステーショ
ン上で生成された画像情報のすべてを含んでいることを確認できるためです。
3.2.2.2. 患者情報の整合性確保(PIR)
もし患者デモグラフィック情報に変更が起るなら、適切なレポートが確実になされるように患者デ
モグラフィック情報のアップデートが行われることが極めて重要です。更に、検査属性がレポーテ
ィングとそれに続くレポート視読の効率を確保するために、維持される必要があります。
1)
画像取得中の患者 ID 情報の整合性をとります。(Patient Update)
2)
シナリオの確認：手続きで生成された画像が、表示されたり引き続きレポートされる際に、
新しい患者デモグラフィック情報を反映していることを確認します。
3)
以下のシナリオは、まだ同定されていない患者の登録とオーダ実施に関してです。
(a) 同定されていない患者が HIS で登録、HIS でオーダ発行。オーダ実施、RIS 経由手続き予
約。(Patient registration, Placer Order Management, Filler Order Management)
(b) 同定されていない患者が HIS で登録、RIS でオーダ発行。 (Patient registration,
Placer Order Management, Filler Order Management)
(c) 同定されていない患者が HIS で登録、しかしオーダ発行前にモダリティにて検査完
了。(Patient registration)
(d) HIS での患者登録前またはオーダ発行前に、検査実施。
シナリオの確認：患者デモグラフィック情報がアップデートされた後、PACSから検索された
画像を表示することにより実際の患者デモグラフィック情報と合致するか確認します。
これらの分野で、詳細なテストセットが適切なデータセット付きで開発される必要があります。
それらのデータセットには、HIS と RIS の間で送られるべき HL7 レコードの開発を含む必要
があります。それらのデータセットには、患者デモグラフィック情報とエンカウンター情報を
アップデートするためのすべての HL7 メッセージ(HIS から RIS へ送られる、またはその逆も)
を含む必要があります。テストされる特定のトランザクションについては IHE TF を参照願い
ます。
3.2.2.3.
画像表示の一貫性確保(CPI)
CPI を用いれば効率と正確さが改善されるでしょう。PACS は CPI に関連した表示状態を維持
するのに重要な役割を果たします。以下は、新しい PACS CPI 上で実施する必要があると思わ
れるハイレベルのテストの例です。
1)
CPI に関連して、使用されるすべてのワークステーションとプリンタを較正すること。
（ベ
ンダ資料を参照すること）。
2)
ワークステーション上でウィンドウ／レベル付け・拡大・回転等の後処理をされた画像を
生成させ、PACS に保存すること。(Creator Presentation State Stored)
3)
PACS からその処理した画像を検索し、他のワークステーション上に表示させる。
(Retrieve Images)
シナリオの確認：表示された画像がオリジナルの後処理された画像と同一であることを確
認 す る こ と 。 保 存 可 能 な デ ィ ス プ レ イ 属 性 の 全 体 リ ス ト は DICOM 2003 PS 3.4
Presentation LUT SOP Classを参照願います。
4)
PACS から処理された画像をプリントすること。(Print Request with Presentation
2005 年 6 月 20 日
40
IHE 放射線ユーザハンドブック
Look-Up Table)
シナリオの確認：フィルム画像がオリジナルの後処理された画像と同一であることを確認
すること。プリント属性の全体リストはDICOM 2003 PS 3.4 Presentation LUT SOP
Classを参照願います。
これらの分野で、詳細なテストセットが適切なデータセット付きで開発される必要があります。
それらのデータセットには、処理用の代表的な画像を含む必要があります。
3.2.3.
導入問題を検討する
IHE を以ってしても、据付けは“plug and play”(配線接続したらそれで完了という単純な作
業)ではありません―システムは自身で構成組み上げをしてくれる訳ではありません。PACS に
たいしては、以下が考慮されるべきシステム構成と据付上の問題点のリストです。
3.2.3.1.
通常運用のワークフロー(SWF)および患者情報の整合性確保(PIR)
1)
AE タイトル、統合プロファイルアドレス、モダリティの DICOM MMPS（もし構成され
た MPPS マネジャであるなら）用のポートと共に PACS を構成することです。その結果、
PACS は MPPS メッセージをモダリティから RIS へ転送出来ます。さもなければ、もし
RIS が MPPS マネジャとして作動しているならば、MPPS メッセージを受信し PACS へ
転送するでしょう。
2)
AE タイトル、統合プロファイルアドレス、DICOM Storage Service を持つすべてのモダ
リティおよびワークステーションの DICOM MMPS（もし構成された MPPS マネジャで
あるなら）用のポートと共に PACS を構成することです
3)
AE タイトル、統合プロファイルアドレス、PACS の DICOM Print Services 用のポート
と共に PACS を構成すること。プリンタがフィルム上へのプリントサービスを提供出来る
ように、この情報はあなたのプリンタベンダと共有される必要があります。更に、あなた
の print composer の中で特定のプリンタ用にプリンタ属性（例を次に記す）をサポート
するように構成することです。（媒体タイプ、最小及び最大濃度、フィルムオリエンテー
ション、フィルムサイズ ID、拡大タイプ、トリム、構成情報、および極性）
相当の時間が、種々のコードを生成し異なるシステム間でコードの同期を採っていくために費やさ
れます。コードはあなたのシステム中の様々な部分に使われるために取り決められる必要がありま
す―性別コードのように単純なものからプロバイダコードのようにより大きなデータッセットに至
るまで。それらコードは手作業で同期を保つ必要があり、もし同期が外れたなら、コードの値を意
識することも無いので、受け取り手はデータを受けられないことになります
PIR の場合、一時的な ID を割り当てて使わせることが必要になるかもしれない。例えば、
“issuer of patient ID”であり、これは DICOM 及び HL7 患者 ID の間の一貫性を確保する
ために用いられます。
3.2.3.2.
画像表示の一貫性保持(CPI)
Grayscale Display Function Standard(DICOM PS3.14)に準拠してモニタやプリンタの定期
的な較正を行なうことが求められます。生成される表示状態について名前の付け方の取り決め
が必要になるでしょう。
3.2.4.
“遺産”システム問題の摘出と対応
IHE 統合プロファイルは、すべての関係するシステムはそれらの統合プロファイルをサポート
することを前提として作られています。もし幾つかのシステムがあなたの選択したプロファイ
ルをサポートしていないがプロファイルが基礎としている標準規格はサポートしている場合
には、なお幾つかのメリットは達成可能です。もしあなたのシステムに機能欠落があるなら、
短期間はその欠陥を避けて回り道をする次善策といつそのシステムを置き換えるかまたはア
ップグレードするかを考えればよいのです。
2005 年 6 月 20 日
41
IHE 放射線ユーザハンドブック
3.2.4.1.
PACS を非 IHE モダリティに接続する
モダリティと PACS 間の相互運用性は、HIS または RIS 経由で新しい情報または情報のアップデー
トを受け取った場合に、患者デモグラフィック情報、オーダや手続き情報が保存（PIR の場合アッ
プデート）されることを可能にします。画像が出来るだけ早く利用可能になるように画像状態の情
報が提供されます。非－IHE PACS の能力に基づき、それらの機能のある部分かすべてが利用可能
となるでしょう。以下が PACS を非 IHE モダリティとどの様に統合していくか決める際に検討す
べきガイドラインです。
あなたのモダリティベンダからあなたの医療機関に据え付けられている製品の各々について、
現在の DICOM 適合性宣言を要求することです。附属書 F を参照願います。
3.2.4.1.1
通常運用のワークフロー(SWF)
SWF プロファイルにおいて、PACS はモダリティに対して、特定の属性を用いてそして特定
の方法で（TF 参照のこと）メッセージに応答することによって、幾つかの DICOM サービス
をサポートしていることを求めています。重要な DICOM サービスは、SCU として DICOM
Storage、SCU として DICOM MPPS、SCU として DICOMMWL、及び SCU として DICOM
Storage Commitment です。
もしあなたのモダリティがそれらのサービスすべてを持っているならば、重要な DICOM 属性
が DIICOM 画像（そして他の DICOM オブジェクトなら何でも）の中に備わっていることを
確認することです。取得ワークフローのすべてにおいて情報の一貫性を確保するために、IHE
で決定したキーとなる重要な属性は以下の如くです（キー属性の完全なマッピングについては、
Radiology TF, Vol. 2, Appendix A を参照願います）。
¾
患者氏名(0010,0010)
¾
患者 ID(0010,0020)
¾
登録番号(0008,0050)
¾
予約済み手続き(0040,1001)
¾
予約済み処理手順(0040,0009)
もし一つ以上のあなたの現在のモダリティシステムに、上記にリストアップしたサービスのどれ
かが欠けているなら、あなたのベンダはそれら属性を提供するオプションまたはアップグレード
を行なうかもしれません。モダリティ上で MPPS をサポートすることは、自動的な手続き状態
トラッキングおよび課金を可能にして、
“取得ループを完結させる”ので大いに役に立ちます。
MPPS サービスが欠如する部分もあるのでワークフローは妨げられますが、このサービスの欠
如によってはシステム間のデータ一貫性は損なわれない。
もしあなたの PACS が DICOM MPPS
を持たないならば、検査状態を PACS（または RIS）へ報告することが出来なくなります。この
場合、
“取得ループを完結させる”という点でワークフロー問題を減少させること、手続き状態
のトラッキング、および早く正確な課金は、次のどちらかの方法で行なうことは出来ます：(a)
モダリティに代って MPPS を送信する“仲介”システムまたは PACS オプションが利用できる
かもしれません。その様なシステムはしばしばモダリティに Worklist Function を提供します。
(b)あなたの PACS は“頼みの綱モード”を持ち検査状態を推定することを可能にします（その
方法とはモダリティや RIS からの Storage や Storage Commitment または他のイベントやトリ
ガーに依ります）
。(c)モダリティ上で RIS クライアントを使って―例えば取得タスクを手作業で
“サインオフ”させ―ワーク状況を追跡します。
PACS 上 で の DICOM Storage Commitment を サ ポ ー ト す る こ と は 、 一 旦 PACS が
“commitment”を受け入れたなら、モダリティから画像を自動削除することが可能です。も
しあなたの PACS が DICOM Storage Commitment の機能を持たないならば、PACS が受け
取ってその画像データの所有権を取ったことを確認することが出来ません。この問題を減少さ
せるには、画像をモダリティシステムから削除する前に、各検査のすべての画像が PACS 上に
2005 年 6 月 20 日
42
IHE 放射線ユーザハンドブック
受信され永久、長期保存に“committed”したことを手作業で確認します。モダリティ上のす
べての画像コピーをレポートが作成され保存されたことを確認するまで削除しないで保持し
ておくことです。
もしあなたのモダリティが DICOM MWLs を取り出すことが出来ないならば、
RIS で予約された正確な
患者、オーダおよび手続き情報を自動的に受信することは不可能でしょう。このやりとりは IHE ではモ
ダリティと RIS の間で起ると定義されていますが、モダリティと PACS の間の統合の品質に大きな意義
を持っています。これがまき起こす問題を軽減させるために、(a)モダリティの代わりに MWLs を問合
せ引き出せる“仲介”システムまたは PACS オプションが利用可能です。(b)あなたの PACS は、モダリ
ティから受信する画像を、RIS から受信する最も正確な患者および手続き情報を使ってアップデートす
るオプションを持つことが出来まする。もしあなたの PACS が PIR をサポートし患者および検査情報を
RIS から受信しているならば、確実に可能でしょう。
もしあなたのモダリティが DICOM Storage をサポートしないならば、あなたは一時的にその
機能を提供するインターフェースボックスを利用したいと思うでしょう。しかし、DICOM
Storage こそは本当に何も飾らないむき出しのミニマムです。時代遅れのシステムであること
を見逃してしまっている議論です。非‐DICOM モダリティをどう統合していくかの戦略につ
いては、以下を参照願います。
3.2.4.1.2
画像表示の一貫性確保(CPI)
IHE CPI プロファイルにおいては、PACS はモダリティに対して、特定の属性を用いてとか特
定の方法で（TF 参照のこと）メッセージに応答するとかで、幾つかの DICOM サービスをサ
ポートしていることを求めています。重要な DICOM サービスは：
¾
SCU として DICOM Storage (GSPS のために)
もしあなたの PACS がそれらのサービスをサポートしていないならば、あなたのベンダはオプショ
ンかアップグレードでそれら機能を提供しなければなりません。
CPI 統合プロファイルを創設した理由の一つが DICOM GSPS オブジェクトの生成、保存および使用
であり、それは関係する画像を“前回見た通りに”表示しプリントするのに必要なすべてのグレース
ケール処理操作やすべての空間的グラフィックな変換機能を伝えています。もしあなたのモダリティ
が GSPS オブジェクトの受信も処理も出来ないならば、画像をモダリティコンソール上に“前回見た
通りに”表示出来ず、画像をフィルム上に“前回見た通りに”プリントすることも出来ません。
これがまき起こす問題を減少させるため、PACS または PACS ワークステーションのユーザは、
PACS ワークステーションで行なわれるグレースケール処理操作および空間的グラフィックな変換
を反映するために GSPS オブジェクトを生成し保存することが出来るかもしれないし、問合せ／検
索を掛けられなければなりません。
（このことは、もし PACS または PACS ワークステ－ションが
Evidence Creator として CPI プロファイルをサポートしていると主張しているなら、誠に正しい。
）
このことは次のことを求めているようでもあります、求められている表示パラメータ（例えば、ウ
ィンドウの巾・レベル、回転、および画像フラッグ）は PACS または品質保証ワークステーション
で手動／手続き的なメカニズム（手書きの注記または電話コールのような）によって、ユーザ
に”communicated”されています。
3.2.4.2
PACS を Non-DICOM モダリティへ接続する
PACS を non-IHE モダリティに接続するセクションで述べたように、DICOM を用いてモダリティで
発生した画像を PACS に保存することは、すべての IHE 可能な PACS システムは画像を DICOM 経
由で受信すると期待されているから、最も基本的なレベルでの統合においても、実施しなければなら
ない必要事項です。医療機関には未だ遺産の non-DICOM モダリティが存在していることは認めなけ
ればならない現実です。あなたの一つ以上のモダリティが DICOM Storage をサポートしてない状況
に対応していくには、その様な時代遅れになったモダリティが置き換えられるまでは、次のアプロー
チのどれかを行ってこの境遇を正して行きます。
1) モダリティベンダがモダリティに DICOM Storage 機能を付け加えるソフトウエアオプションを
持っているかもしれません。加えて、モダリティベンダから DICOM MWLs, Storage
2005 年 6 月 20 日
43
IHE 放射線ユーザハンドブック
Commitment, and/or MPPS(MPPS)を可能にするアップグレード／オプションが利用可能にな
るかもしれません。
2） 多くの私有フォーマットを DICOM に転換しそれを PACS に保存する“仲介装置”または
PACS オプションが存在します。その仲介装置はまた、モダリティに代って MWLs およ
び Storage Commitment を請求し、および／または MPPS を供給します。
3) ある場合は、遺産モダリティはデジタル画像を提供する能力さえ持たないことがあります。
この場合には、大元のビデオ画像をキャプチャしデジタル DICOM データに変換し PACS
に転送／保存する装置も存在します。
3.2.4.3.
PACS を Non-IHE RIS に接続する
PACS と RIS 間の相互運用性は、HIS または RIS 経由で新しい情報あるいは情報のアップデ
ートを受け取った場合に、患者デモグラフィック情報、オーダや手続き情報が保存されアップ
デート（PIR の場合）されることを可能にします。画像が出来るだけ早く利用可能になるよう
に、画像状態の情報が提供されます。Non-IHE RIS の能力に基づいて、それらの機能のある
部分かすべてが利用可能となるでしょう。以下が PACS を non-RIS とどの様に統合して行く
か決める際に検討するべきガイドラインです。
あなたの RIS ベンダからあなたの医療機関に据え付けられている製品の各々について現在の
DICOM 適合性宣言および HL7”interface specification”を要求することです。附属書 F および
G を参照願います。
この展開シナリオは、
PACS を別の分離した RIS と統合することを想定していることに留意して下さい。
結合された PACS-RIS 製品は PACS と RIS の間の通信を内部的に取り扱っていますが、他の PACS シ
ステムとのいかなる通信も改めて徹底したインターフェースのレビューが必要になります。
3.2.4.3.1
通常運用のワークフロー(SWF)及び患者情報の整合性確保(PIR)
SWF プロファイルにおいて、PACS は RIS に対して、特定の属性を使用するとか特定の方法で（TF
参照のこと）メッセージに応答するとか幾つかの DICOM および HL7 サービスを、サポートしてい
ることを求めています。重要な DICOM および HL7 サービスは以下の通りです：
¾
SCU として DICOM MPPS
¾
SCP として DICOM Instance Availability Notification(保存委託)
¾
SCU として DICOM Query/Retrieve, HL7 ORMs
¾
HL7 ADT message
もしあなたの RIS がそれらのサービスすべてを持っているならば、RIS が DIICOM MPPS メ
ッセージの中に備わっている重要な DICOM 属性を受け付けられるか確認することです。取得
ワークフローのすべてにおいて情報の一貫性を確保するために、IHE で決定したキーとなる重
要な属性は以下の如くです：
¾
患者氏名(0010,0010)
¾
患者 ID(0010,0020)
¾
登録番号(Accession Number)(0008,0050)
¾
依頼済み手続き(0040,1001)
¾
予約済み処理手順(0040,0009)
¾
PPS ID(0040,0253)
キー属性の完全なマッピングについては放射線検査部門 TF, Vol. 2, 附属書 A を参照願います。
更に、RIS が、HL7 ORMs の中の以下に述べるキー患者、オーダ、手続き等の同定用の属性
を提供できるか確認することです。
¾
患者氏名(patient demographics-5)
¾
患者 ID-2
2005 年 6 月 20 日
44
IHE 放射線ユーザハンドブック
¾
患者デモグラフィック情報(patient demographics-3)
¾
オーダ実施番号(Filler order number(ORC-3))
キー属性の完全なマッピングについては、放射線検査部門 TF, Vol. 2, 附属書 B を参照願います。
RIS とモダリティ（または PACS）の間で MPPS をサポートすることは、自動的な手続き状態トラッ
キングおよび課金を可能にして、
“取得ループを完結させる”ので大いに役に立ちます。もしあなたの
RIS がDICOM MPPS をサポートしないならば、
モダリティから検査状態アップデートを受けられず、
それを PACS へ転送することもできません。この場合、
“取得ループを完結させる”という点に関して
のワークフロー問題の減少、手続き状態のトラッキング、および早く正確な課金は、次のどちらかの
方法で達成は出来ます：(a)モダリティに代って HL7 経由で RIS へ MPPS-等価な情報を送ることが出
来ます“仲介”システムまたは PACS オプションが利用可能かもしれません。(b)モダリティ上（また
は近く）の RIS クライアントを使ってワーク状況を追跡します―例えば手作業により RIS 上で直接に
取得タスクを“signing off”することによってです。
あなたの RIS 上で DICOM MPP 機能が欠如する場合、あなたの新しい PACS は PPS Manager
としてセットアップされるべきであり、その結果あなたの PACS はそれらの状態アップデート
を受信できます。
RIS はしばしば部門内のワークフロー管理で重要な役割を果たします。RIS については、ある手続き
の画像がすべて利用可能になって初めて、後続のワークフロースッテプ、例えばレポーティングまた
は追加の画像後処理等、が開始できるということを意識しておくことは大切です。この意識を広める
ために、RIS の中では DICOM Instance Availability Notification Service または DICOM Query
Service がサポートされていることが役に立ちます。
もしRIS がSCU としてのDICOM Query もSCP
としての DICOM Instance Availability Notification もサポートしないならば、RIS はある手続きから
の画像すべてが利用可能になった時期を自動的に決める方法が無いことになります。この問題を減少
させるために、PACS クライアントを使って全画像が利用可能になったかの問合せを行なうことがで
き、RIS に代ってこの DICOM 問合せをするインターフェースメカニズムが存在し、インターフェー
スコンバータが DICOM Instance Availability Notification メッセージを受信し、ルーティングし、
処理してくれ、その結果 automated availability notification が可能になります（DICOM メッセージ
を RIS が理解でき処理できるメッセージに変換）
。
PACS は、RIS から受け取る HL7 オーダ （手続き予約済み）メッセージを用いて、関連する以前の
画像をプリフェッチすることにより画像レビューのワークフローを流れるように整えます。もし RIS
が HL7 ORMs を送信しないなら、PACS のプリフェッチング能力は限定されたものになってしまい
ます。
この問題を低減させるため、
RIS から送られる私的専用の患者またはエンカウンター情報を HL7
準拠の ADT メッセージに変換する機能を持つ仲介／インターフェースエンジンを使用することも出
来ます。または RIS ベンダが、HL7 ADT メッセージの伝送も含めて HL7 能力を追加するソフトウエ
アオプションまたはアップデートを提供するかもしれません。
PACS は、RIS から受信する HL7 ADT メッセージを用いて、PACS の DICOM オブジェクト中の
患者及びエンカウンター情報を最新のものに保ちます。この機能は未同定の（トラウマ）患者およ
び誤認の患者に正確に対処するのに特別に重要な意味を持ちます。もし RIS が HL7 ADT メッセー
ジを送信しないと、PACS の持つ患者とエンカウンター情報の一貫性を維持する能力が限定されて
しまいます。この問題を低減させるために、RIS から送られる私的専用のオーダ／手続きメッセー
ジを HL7 準拠の ORM に変換する機能を持つ仲介／インターフェースエンジンを使用することも出
来ます。または RIS ベンダが、HL7 ORMs の伝送も含み HL7 能力を追加するソフトウエアオプシ
ョンまたはアップデートを提供するかもしれません。
3.2.4.4.
PACS を非 IHE ワークステーションに接続する
ワークステーションと PACS 間の相互運用性は、PACS 上に保存されている画像や他のオブジ
ェクトの視認および取扱い操作を可能にします。ワークステーションンはモダリティでオリジ
ナルに取得された画像から導出派生された画像を生成し、それらを PACS に保存することが出
来ます。ワークステーションは又、様々な視認用パラメータや実行された画像操作の情報を
PACS に保存することも出来ます。画像が出来るだけ早く利用可能になるように画
2005 年 6 月 20 日
45
IHE 放射線ユーザハンドブック
像状態の情報が提供されます。非－IHE ワークステーションの能力に基づき、それらの機能
のある部分かすべてが利用可能となるのです。以下が PACS を非 IHE ワークステーションと
どの様に統合していくか決める際に検討するべきガイドラインです。
あなたのモダリティベンダからあなたの医療機関に据え付けられている製品の各々について
現在の DICOM 適合性宣言を要求することです。附属書 F を参照願います。
3.2.4.4.1
通常運用のワークフロー(SWF)
SWF プロファイルにおいて、PACS はワークステーションに対して、特定の属性を使用する
とか特定の方法で（TF 参照のこと）メッセージに応答するとかして、幾つかの DICOM サー
ビスをサポートしていることを期待しています。重要な DICOM サービスは以下の通りです：
¾
SCU として DICOM Query/Retrieve
¾
SCU として DICOM Storage（ワークステーションが派生画像を生成する能力がある場合)
¾
SCU として DICOM Storage Commitment（ワークステーションが派生画像を生成
する能力がある場合）
SWF プロファイルの中のワークステーションは、画像の表示及び予約されてはいなかったかもしれ
ない後処理を行なうために PACS から画像を問合せて検索することを期待されています。もしあな
たのワークステーションが DICOM Query/Retrieve をサポートしていないならば、PACS 上の保存
画像を表示し後処理を行なうことはより困難になるでしょう。この場合、画像を同定してワークス
テーションに取り寄せ視認・後処理を行なうには、別の方法を見つける必要があります。これは次
の方法で可能です。(a)ワークステーションはそこへ送られてきた画像を受信することは出来るでし
ょう。統合ワークステーションを用いて画像を同定確認します。それをあなたの遺産ワークステー
ションへ送り、そこで視認・後処理を行ないます。(b)あなたの PACS はあなたのワークステーショ
ンが読める媒体を使って（例えば、PACS はワークステーションが読める DICOM フォーマットの
CD を生成出来る）
、画像をワークステーションへ転送できます。(c)あなたのワークステーションベ
ンダが、DICOM Query/Retrieve 機能を実行できるソフトウエアアップグレードまたはオプション
を提供するかもしれません。
画像を後処理し派生画像を生成するワークステーションは、それら画像を DICOM Storage
Commitment サービスを用いて SWF プリファイルの一部として PACS 上に保存し PACS に画像の
所有権を取ることを求めることを期待されています。ワークステーションが DICOM SC を持ってい
ないならば、PACS が受信してその画像データの所有権を引き受けたことを確認する方法がありま
せん。この問題を低減するために：手作業で、検査ごとにすべての画像が PACS 上に受信されて、
ワークステーション上から削除される前に永久長期保存の”committed”を受けていることを確認し
ます。画像がアーカイブ保存されるまでは、ワークステーション上のすべての派生画像は保管して
おきます。
もしあなたのワークステーションが DICOM 保存機能をサポートしていないならば、派生画像に対
して DICOM Storage を行なう機能を持つ仲介／インターフェースエンジンの一時的な使用を考え
ることも出来ます。しかしながら、あなたのワークステーションが後処理を実行し派生画像を生成
するような使い方をするなら、DICOM 保存はぎりぎりの最低限なのです。時代遅れのシステムで
あるという議論を見逃してしまっています。
3.2.4.4.2
画像表示の一貫性確保(CPI)
IHE CPI プロファイルにおいて、PACS はワークステーションに対して、特定の属性を使用するとか
特定の方法で（TF 参照のこと）メッセージに応答するとかして、幾つかの DICOM サービスをサポ
ートしていることを期待しています。重要な DICOM サービスは、SCU として DICOM
Query/Retrieve(画像以外に、具体的には GSPS オブジェクトの query and retrieval)、および SCU と
して DICOM Storage（ワークステーションが表示画像の視認状態を保存する必要があるなら、具体的
には GSPS オブジェクト）です。
2005 年 6 月 20 日
46
IHE 放射線ユーザハンドブック
CPI 統合プロファイルを創設した理由の一つが、DICOM GSPS オブジェクトの生成、保存お
よび使用であり、そのオブジェクトは関係する画像を“前回見た通りに”表示しプリントする
ために必要なすべてのグレースケール処理操作やすべての空間的グラフィックな変換機能を
伝えています。CPI プロファイルのワークステーションは、関連する画像をレンダリングし表
示する際にどんな GSPS オブジェクトでも適用出来るべきです。ワークステーションが画像を
表示する際に GSPS を適用できないなら、視認する画像の一貫性確保は現実的な方法では不可
能です。
もしあなたの遺産ワークステーションが画像を表示する際に GSPS オブジェクトを適用でき
るが DICOM Query/Retrieve をサポートしていないならば、画像を“前回見た通りに”表示
することはより困難になるでしょう。この場合、画像を表示する間画像を同定して GSPS オブ
ジェクトをワークステーションに取り寄せ使用するには、別の方法を見つける必要があります。
これは次の方法で可能です。(a)ワークステーションはそこへ送られてきた DICOM GSPS オブ
ジェクトを受信するのは出来るでしょう。統合 PACS ワークステーションを用いて関係する画
像の GSPS オブジェクトを同定確認します。それをあなたの遺産ワークステーションへ送り、
そこで視認・後処理を行ないます。(b)あなたの PACS はあなたのワークステーションが読め
る媒体を使って（例えば、PACS はワークステーションが読める DICOM フォーマットの CD
を生成出来る）、GSPS オブジェクトをワークステーションへ転送できます。(c)あなたのワー
クステーションベンダが、DICOM Query/Retrieve 機能を実行できるソフトウエアアップグレ
ードまたはオプションを提供するかもしれません。
2005 年 6 月 20 日
47
IHE 放射線ユーザハンドブック
附属書A
統合プロファイルの統合戦略の策定
統合を始めるに際しては、設備を1台だけ購入すればそれで終わるわけではありません。統合
には部門や施設のシステムがすべて関与し、業務と情報の全体的な流れに効率的に知的に寄与
します。重要なのは、全体的な部門や施設の戦略を統合するために開発することです。完成し
た統合が、どんな姿になりどのように作動するかに関して構想を描き、その目的地に到達する
には現状から出発してどんなステップを踏んで行くかを考えてください。そう考えれば、現在
購入を計画しているものが、壮大な構想の中で役割を果たすには、どのような統合のインター
フェースと能力をサポートすべきかが決まります。
情報技術は効率的なワークフロープロセスの重大な構成要素です。そのようなプロセスを実装
するには、新規設備の購入か既存設備の改良が通常必要になります。IHEは、購買規格の統合
部分を書くために有用な語彙を提供します。
まれには、ある医療施設全体にすべて新しい設備を設置するという機会があります。これらの
状況では、完全に統合されたシステムを実装することが比較的簡単です。しかしながら通常は、
部分的に統合された情報システムが完結しているか、ほとんど完結した状態で既に存在してい
るので、実際は段階的に開発し統合する戦略のほうが、管理と資金調達が容易になります。
いずれの場合でも、立案方法は同じです。統合運用上のワークフロープロセスに注目してくだ
さい。基本的なプロセスフローの理解から出発し、次に、「支流」および特別な場合を含めま
す。次に、それらのプロセスに関与するシステムとトランザクションを識別します。プロセス
に関与し既に施設内にあるシステムの各々について、必要なトランザクションを実装するため
に製品を改良できるかどうかを決めます。既存の製品の改良または購入する新製品に関して、
必要なIHEトランザクションを実装するための要求事項を購買仕様書に含めてください。
必要なトランザクションを指定するために2つの方法、つまり難しい方法と易しい方法があり
ます。難しい方法は、IHEテクニカルフレームワーク(TF)に定義されたトランザクションの
各々を理解し、プロジェクトの現段階の目的を満たすためにどの特定トランザクションが要求
されるかを決定し、購入製品または改良がそれらのトランザクションを実装するよう購買仕様
書で要求することです。易しい方法は、IHE統合プロファイル並びにこれらの統合プロファイ
ルの中で指定された詳細なユースケースおよび解決策を系統的に使用することです。それによ
って円滑な発展的な道をたどり高い相互運用性が実現できます。
設備をすべて同時に購入しない限り、1回の購入ですべての目標を達成することはできません。
大抵は直ちに得られる利益は増分的であり、他の構成部分が今後追加され統合されるにつれて、
統合の効果が順次に結実するでしょう。放射線科(それは増分的な利益が可能であることを実証
する)における段階的な統合戦略の例として、下記を考慮してください:
最初に想定する放射線科の状況では、いくつかのモダリティがプリンタに接続されており、放
射線科にはワークフローを管理する放射線情報システム(RIS)がないとします。IHEをこの状
況で導入すれば、IHEを実現するための構想、青写真および戦略が得られます。
1番目の単純かつ実際的なステップは、少数の後処理ワークステーションを導入し、例えば、
収集した画像の品質保証を行なうことです。IHEにはこのステップに利用できるプロファイル、
つまり画像表示の一貫性確保(CPI)プロファイルがあります。それは画像をワークステーショ
ンから見てもフィルム上で見ても同じように知覚できることを保証します。
2番目のステップは、RISを導入し、モダリティをRISにDICOMモダリティワークリスト
(MWL)によって接続することです。IHEにはこのステップに利用できるプロファイル、つまり
予約済みワークフロー(SWF)プロファイルがあります。
2005 年 6 月 20 日
48
IHE 放射線ユーザハンドブック
それは患者IDおよび患者人口統計データの自動的伝送という利益すべてをもたらし、さらに放
射線情報システムの振舞いおよびモダリティが次の段階に向けて何を準備せねばならないか
正確に明示します。次の段階とは放射線科がPACSの導入を準備することです。
その後、3番目のステップはPACSの導入になるでしょう。この段階でIHE TFの真価が発揮さ
れ、次のような適切な統合プロファイルが用いられます。つまり本格的なSWF、患者情報の整
合性確保(PIR)、複数検査手続の一括撮影と表示、および放射線科情報へのアクセスです。こ
れらのIHEプロファイルから期待できるメリットに関しては、このハンドブックの該当するセ
クションを参照してください。
PACSの導入後に暫くしてから、放射線科は次の段階の準備ができるでしょう。つまりワーク
フローの中に、追加の生産性を向上するオブジェクト、例えば測定やコンピュータ支援診断を
生成し使用するタスクを導入すること、およびキー画像への注釈によって重要な画像にフラグ
を立てることです。IHEでは次のような統合プロファイルがこの段階で利用できます。つまり
後処理ワークフロー、キー画像への注釈およびエビデンス文書です。これらのIHEプロファイ
ルから期待できるメリットに関しては、このハンドブックの該当するセクションを参照してく
ださい。
放射線科での患者の撮影手続きのループを閉じるために、報告と料金請求を扱う必要がありま
す。ワークフローは拡張され、報告のタスクおよび手続き料金請求の準備を含めることになり
ます。このためにIHEでは次のような統合プロファイルが利用できます。つまり報告書ワーク
フロー、画像・数値を含む報告書および会計処理です。
要するに、IHEアプローチで施設統合することにより、病院の統合コストの低減が期待できる
かもしれません。そのコストは病院のIT予算総額の20%～25%に相当します。その結果、さら
に多くの資金が医療固有の投資に利用できます。コストの低減は、IHE仕様書に従って製品に
標準プロトコルを使用することにより可能です。これらの製品は定期的な相互接続性セッショ
ン(コネクタソン)で試験されます。そこには、ほとんどの医療関係ベンダが参加します。製品
価格の低減も期待できることがあります。開放的かつ成熟した規格に基づいた製品の市場力学
が働くからです。
IHEは、病院内および病院間の既存ITシステムを統合するために、証明済みで実用的なロード
マップを提供します。ロードマップは、新しい臨床部門、例えば循環器、臨床検査、患者の統
合的診療記録管理のためのインフラストラクチャー、地域健康情報ネットワーク中の臨床経路
などを扱います。
ユーザ志向かつ反復志向の標準化プロセスは、IHE仕様書が現実世界の統合問題に取り組むこ
とを保証します。IHEロードマップは1年ごとの反復に分割されています。そこでは、それぞ
れの反復により自給自足の統合解決策が提供されます。
IHE適合製品が多数のベンダから提供されることは確実です。IHEを支持する医療ITベンダが
ますます増えているからです。その結果、病院は、多種多様な利用可能な製品から選択し、最
良のIHEシステムを構築することができて、単一のベンダに頼ることがなくなります。異なる
ベンダからのIHE製品の間で、相互運用はますます改善されます。なぜなら詳細なメッセージ
記述があり、多数のベンダが参加する試験セッション(コネクタソン)でIHE実装が確認され、
製品の特定のIHE能力を記述する統合宣言書(IS)が出版されているからです。
この戦略が実際に成功することは多くのIHE成功事例によって示されています。それは
www.ihe.net/Resources/user_success_stories.cfmに掲載されています。この統合の道を歩む
のはあなたが最初ではありません。多くの仲間が既に道を開いてきました。この道に沿って自
分なりのベースラインを設定し、目標に向けた進捗状況を測定できます(附属書Iの測定の説明
を参照)。
A.1
現存する既存システムを含むIT環境における統合の進め方
IHEのシステム間の相互運用は、システムが、正確に定義されたインターフェースをデータ交
換に使用することを意味します。さらに、交換されるデータを構成する方法、またはそのよう
な交換で受け取られたデータを処理する方法に関する本質的なシステムの動きが、しばしば定
義されます。これにより設置または配置の手間が削減され、定義された質で本質的なデータを
通信できます。
2005 年 6 月 20 日
49
IHE 放射線ユーザハンドブック
そのような統合メカニズムに従わない既存システムでは、既存のインターフェースを特別に適
応させれば、データ交換を確立するのをサポートするかもしれません。その方法はそれほど包
括的ではないが、経過処置としては十分な方法になる可能性があります。したがって、ここで
共通の既存システム統合アプローチが記述されます。それは、IHE対応機械に非IHE対応設備
を接続する実行可能なステップとなり、あなたの施設の統合ニーズを満たすことができるかも
しれません。
上記の「非IHE」統合シナリオでは、通信システムは少なくとも最も重要な規格に基づいたイ
ンターフェース、主としてDICOM、HL7 v2.xインターフェースを提供します。これにより統
合の手間が省けるはずです。なぜなら融通性を制約して、定義されたメッセージを適応させる
必要があるからです。
「非DICOM」、非HL7の統合シナリオは主として通信システム間の所有者固有のインターフ
ェースに基づきます。そのため統合の手間が複雑になるかもしれません。これらの場合、イン
ターフェース適応が有効に働くかもしれません。
インターフェース適応または転換は、退屈ですが試みる価値のある努力です。関連のインター
フェース、例えばデータ構造、内容意味、および配置オプションまたはコミュニケーションの
準備をするシステムの各サイドの変わりやすさをチェックしてください。もしメッセージタイ
プ、構造または内容が、送信システムと受信システムとの間で一致しないと(例えばメッセージ
バージョンが異なり、データの組立てが異なり、使用されるコードが異なると)、受信システム
は送られたメッセージを受理できないか、または理解できません。メッセージ転換メカニズム
はこの通信および統合問題を解決します。関与するシステムの目的、範囲、およびあなたの組
織または設備によって、適応インターフェースに対するアプローチが異なります:
1)
インターフェースの個々のマッピング(「マニュアルインターフェース」)：この適応は、
この特定の場合に対し、2つの通信システムだけのために行われます。そのような非再使
用可能な解決法が推奨されるのは、限定的な組織範囲をもつ特定使用法の周辺システム―
例えば研究用データ収集を実現することだけです。
2)
一部のシステムタイプ(「仲介装置」、「インターフェース変換器」)のための特定の適応
メカニズム：このような総合システムは特定のシステムタイプ間(例えばHIS-RIS間、
RIS-PACS間)に存在し、メッセージの一部のセットを翻訳し、またしばしば相当な前配置
メッセージを翻訳します。それらにより、特定シナリオのための既存システム統合が、ほ
とんどは診療科レベルで容易になります―例えばRIS-PACS変換器は、RISのHL7データ
をDICOM MWLサービス部門に翻訳し、データをモダリティに提供します。そのような
メカニズムは、特定の撮影目的のため、またはあなたの撮影部門でやや専用的なメッセー
ジ転換を実行する必要がある場合に適切になります。
3)
一般的、多目的、高生産性メッセージ適応システム(「インターフェースエンジン」)：こ
のようなシステムは、高度に構成可能なメッセージ変換メカニズムをもち、しばしば異な
るメッセージ分配機能と結合します―例えばルーティング、放送です。それは多くのシス
テムタイプを接続でき、施設での中央サービスとして通常提示されます。例えば、RISは
検査値をインターフェースエンジン経由で既存検査室システムから得るかもしれません。
もしあなたの施設がそのような中央インターフェースエンジンを運営しているならば、そ
れをあなたの撮影統合シナリオのために使用でき、あなたの撮影部門に別のインターフェ
ースソフトウェアをインストールする代わりになるかもしれません。
もし上記のインターフェース適応のコスト対利益比率に満足できないならば、通信システムの片
方または両方に新しいソフトウェアバージョンをインストールすれば、当面の統合問題を解決で
き、また恐らく他のシステムとの追加の統合問題も解決できるかもしれません。
2005 年 6 月 20 日
50
IHE 放射線ユーザハンドブック
附属書B
IHE統合プロファイルを理解する
統合プロファイルを理解するための追加の情報源はいくつかありますが、それらは興味をもつ
深さによって異なります。
B.1
統合プロファイルの要旨とチュートリアル
IHEとそのプロファイルに関する要約とチュートリアルを提供する紹介文書が、www.ihe.net
にあります。
統合プロファイル文書は、プロファイルの各々について基礎的な記述と図解を提供します
(www.ihe.net/pdf/iheyr3_integration_Profiles.pdf)。
SCAR 2003ワークショップからの「IHEがオファーするもの」というプレゼンテーションは、
基本プロファイルの簡潔な図解概観を提供します(www.ihe.net/presentation
/ihe_scar_2003.html)。
最初の7つの放射線科プロファイルの本文の概要は、radiographics.rsnajnls.org/cgi
/content/full/21/5/1343で提供されます。
2004年のIHEワークショップからのプレゼンテーションは、各プロファイルの詳細なプレゼン
テーションを提供します(www.ihe.net/participation/workshop/workshop_2004 /index.html)。
結局、各プロファイルの詳細に関してはIHE TFのボリューム1に記述されており、各プロファ
イルに対して１つづつ章を設け、解決された問題、解決に関与するアクタ、および相互作用す
るためアクタが使用するトランザクションを概説しています。特に、セクション2.1では現在
のプロファイルの概観を、セクション2.2では現在のアクタを説明し、表2.2-1では各アクタが
どのプロファイルに関与するか示し、第3章以降は各プロファイルを詳述しています。さらに
深く調べたい場合は、IHE TF文書を調べてください。IHE TFの読み方については下記セクシ
ョンを参照ください。
B.2
ユーザの成功事例
もう１つの関連情報源は、ユーザ成功事例集であり、www.ihe.net/resources
/success_stories/index.htmlにあります。これらの事例研究は、IHEプロファイルを開発した
施設によって提出されたものです。各文書は簡潔に1ページにまとめられており、その施設の
経験、開発したプロファイルおよび関係する特定の製品に関して記載されています。
B.3
IHEテクニカルフレームワークを理解する
完全なIHE TFは、www.ihe.net/Technical_Framework/index.cfmからダウンロードできます。
各々のIHE部門が個別のTFを公表していますが、それらは完全に互換性をもち相互運用が可能
です。実際、部門では、しばしば他の部門からのトランザクションとプロファイルが利用され
ますし、製品はしばしば複数の部門からのプロファイルを実装しています。公表されたTFは、
放射線検査、ITインフラストラクチャー、臨床検査室および循環器の部門を対象としており、
他の部門のものもまもなく追加されると思われます。
新しいプロファイルが試験的実施のために公表される場合はウェブサイトに補遺文書として
記載されます。一旦プロファイルが試験され、最終文書として十分安定し正確であると判断さ
れたならば、プロファイル補遺文書は、関連のTF文書が次回リリースされるときに合併されま
す。TFの内容分類はどの部門のTFでもほとんど同じです。TFのボリューム1では、各統合プ
ロファイルに対し1つづつ章を設けて、プロファイルがどのような問題を解決するよう意図さ
れるか説明し、次に、アクタ(解決で果たされる種々の役割)およびトランザクション(アクタが
どのように通信し振舞うよう要求されるか)の点から、解決策を概説します。TFのボリューム2
は、各トランザクションがどのように行われるか詳細に規定します。このボリュームでは、関
連する規格の使用について非常に詳しく記述しています。それは本質的にはベンダ技術者のた
めの実装指針ですが、医療施設の技術スタッフがIHEの運用を詳細に理解したい場合も有用で
す。一部の部門の場合、トランザクションが多数あるので、ボリューム3が追加のトランザク
ションを含むために付け加えられます。TFのボリューム4は、要望に応じて、各国の特別のニ
ーズを満たすのに必要な仕様変更を含んでいます。
2005 年 6 月 20 日
51
IHE 放射線ユーザハンドブック
これらは国内拡張仕様と呼ばれます。IHEの目標は世界的に共通のニーズに役立つことである
ので、ボリューム4は概して簡潔な文書です。
2005 年 6 月 20 日
52
IHE 放射線ユーザハンドブック
附属書C
統合の機能仕様をRFI/RFPに盛り込む
統合プロファイルは、医療機器の購入者とベンダとの間の正確で迅速なコミュニケーションを
提供します。購入者は、特定のプロファイルのための要求事項を含めることができますので、
IHEはその要求事項に適合するとベンダが主張するため何を行なう必要があるか数百ページ
の文書を提供しています。IHEプロファイルを参照すれば、主張は簡潔で正確にわかります。
要求事項を表現するためIHE統合プロファイルを使用する場合、IHE放射線TFを参照し、
RFI/RFPにwww.ihe.net/Technical_Framework/index.cfmへのリンクを含めたいと思うかも
しれません。IHEを使用すると単純化されるので、TFの詳細はベンダに任され、ベンダが製品
の中で実装します。あなたは、RFI/RFPの前に、またはそれに対応して、適用可能な製品のた
めにベンダがIHE統合宣言書を提供するよう特に要求したいと思うかもしれません。
RFI対RFP
RFIは、ベンダの技術は何か、その技術があなたの問題をどのように解決するかを記述するよ
うベンダに依頼します。RFPは、あなたが行なう計画の提案であり、プロジェクト予定表、予
算、ニーズの宣言を含んでいます。この附属書はRFIを記述します。このRFIをRFPにするた
め予定表および予算をRFIに追加します。
統合の点でベンダをランク付けする方法論
統合は、競合システムを評価しランク付けするとき鍵になります。統合の各分野について買い
手は自分らの「LIMits」が何か決定する必要があるでしょう。「LIMits」とはLike to haves(希
望するもの), Intend to haves(計画するもの), Must to haves(必須のもの)です。各々のIHE統
合プロファイルが、どのような統合問題を解決できるか識別してください。そしてあなたの施
設で実装に成功するため、この統合がどのくらい重要か施設内部で格付けしてください。希望
するもの、計画するもの、必須のものをそれぞれ1点、3点、5点と採点します。
この採点を施設内部で行ってから、統合特徴のこの優先順位をベンダに知らせるかどうか決定
してください。統合プロファイルの各々について、統合によって遂行する計画を簡潔に説明し、
ベンダがその問題をどのように解決できるか尋ねてください。ベンダの答えを統合の仕方に応
じて次のように採点してください。
統合が不可能な場合: 0点、
ベンダ固有の方法論を使用する場合：1点、
DICOM/HL7を使用するが、IHE仕様書には従わない場合：3点、
IHEを使用するが、あなたの選択肢ではない場合：4点
IHE方法論を完全に使用する場合：5点
統合特徴の評価は、PACSの場合下記の例のようになります：
統合
プロファイル
問題
施設内部で
の格付け
ベンダの能
力
ランク
*
予約済み
ワークフロー
(SWF)
オーダを予約および収集プロセスに統合するこ
と。モダリティおよび手続き状態情報のMWLを
RISおよび／またはPACSに返送すること
5
4
20
患者情報の整
合性確保(PIR)
患者個人情報の変更に対しRIS、PACSおよび
HISデータベースを自動的に同期させること。
5
3
15
患者同期
アプリケーショ
ン
合計点
患者情況情報を多数の「知っている」アプリケ
ーションに対しユーザのコンピュータ上で同じ
患者に同期するよう共有すること
3
0
0
35
各プロファイルについて、施設内格付けの点数とベンダの能力の点数を掛け算して積を求める。
各プロファイルの積を合計する。あなたのニーズに合わせてベンダがどのくらい統合できるか、
合計点により客観的に判定できる。
2005 年 6 月 20 日
53
IHE 放射線ユーザハンドブック
ベンダRFI採点表の例
下記は採点表の例です。それは、IHE放射線部門からの利用できるプロファイルを必ずしもす
べて含んでいるとは限らりませんが、IHE ITインフラストラクチャー部門から少数のものを含
んでいます。関心のあるプロファイルを反映するために自分自身のスコアカードを作成するこ
とわお勧めします。
統合
問題
施設内部で ベンダの能力 ランク
プロファイル
の格付け
*
予約済み
オーダを予約および収集プロセスに統合する
ワークフロー こと。モダリティおよび手続き状態情報の
(SWF)
MWLをRISおよび／またはPACSに返送する
こと
患者情報の整 患者個人情報の変更に対しRIS、PACSおよび
合性確保(PIR) HISデータベースを自動的に同期させること。
画像表示の一 ウィンドウ／レベル情報、シャタリング、ズーム、
貫性確保(CPI) フリップおよび注釈を保存すること。これは放射線
科医の業務の成果品であり、画像に添付して紹介医
師に届けて通知する必要があります。
複数検査手続 複数のオーダを単一の検査にリンクし、その部分集
の一括撮影と 合をエンドユーザに知的にデリバーし、会計のため
表示
の正確なオーダ詳細追跡を維持すること。
患者同期アプ 患者情況情報を多数の「知っている」アプリケ
リケーション ーションに対しユーザのコンピュータ上で同
じ患者に同期するよう共有すること
キー画像への 大きなデータセット中の主要画像に印(フラグ)
注釈
を付けてテキストを添付し紹介内科医と外科
医に通知すること；さらに教育とQCの目的の
ためにも使用される。
施設内ユーザ この施設および他の施設アプリケーションの
認証
ための「単一のサインオン」パスワードを共有
すること。ユーザが多くのパスワードを覚える
必要がないので、これは便利でありサポートコ
ストを低減します。
可搬用撮影デ 他の場所でも容易に判読できるCDを作成する
ータ交換
こと―データの利用可能性を向上しサポート
コストを低減します。
患者ID相互参 あるシステムが、異なる部門のシステムと通信しな
照
ければならない場合、中央のID相互参照システムを
使用し、多数のマスター患者インデックス部門にま
たがるようにすること。
監査証跡と機 HIPAA適合のための監査証跡を作成し、通信先
器認証
の他のシステムを機器認証してセキュリティ
を確保すること。
RFPの言語
「必須のもの」や恐らく「計画するもの」に対しては、用語「しなければならない(shall)」を
RFPの中で次の例のように使用してください：
「PACSシステムは、SWF統合プロファイルおよびPIRプロファイルを画像マネジャ／画像ア
ーカイブアクタとしてサポートしなければなりません。」
「PACSシステムは、SWF統合プロファイルをエビデンス生成アクタおよび画像表示アクタと
してサポートしなければなりません。」
「PACSシステムは、画像統合プロファイル用のIHEポータブルデータを可搬用画像データ書
込みアクタとしてサポートしなければなりません。」
2005 年 6 月 20 日
54
IHE 放射線ユーザハンドブック
「PACSシステムは、IHE予約済みワークフローのインスタンス有効性通知選択肢を画像マネ
ジャ／画像アーカイブアクタとしてサポートしなければなりません。」
「希望するもの」や特に新規の統合プロファイルについては、ベンダは用語「しなければなら
ない」でまだ応じることができないかもしれません。なぜなら現在その機能性のある製品がな
いからです。契約交渉で約束した構成要素を将来の計画表の中にどのように含めるか決めてく
ださい。契約に含まれない機能性の納入をベンダに期待することは、非現実的です。
2005 年 6 月 20 日
55
IHE 放射線ユーザハンドブック
附属書D
適切な製品の選択
色々な方法で、IHEに関係するベンダと製品を見つけることができます。
D.1
IHEコネクタソンの結果
IHEコネクタソンの結果は、どのベンダがどの統合プロファイルを開発し試験に成功している
か示します。IHEコネクタソンは毎年行われベンダは自発的に参加します。これにより、ベン
ダは自社製品のIHE統合能力を、他の多くのベンダの製品と一緒に構造化され管理された環境
内で試験することができます。その結果により、あるプロファイルに、あるアクタを実装する
にはどのベンダが優れているか実証できます。
その結果には、特定の製品またはバージョンは列記されません。ベンダは自社製品のIHEサポ
ート能力を主張するためコネクタソンに参加する必要はありません。コネクタソンはベンダま
たは製品を認証するものではありません。言い換えれば、公表された結果は有用なリトマス試
験です。コネクタソンでプロファイルを試験して成功したベンダが、製品はそのプロファイル
を実装していると直接主張すれば、その主張は説得力があります。特定製品の特定バージョン
がIHEに適合しているとの直接主張に関しては、ベンダの公表するIHE統合宣言書を参照して
ください。これについては次のセクションで述べます。
IHEコネクタソンは毎年、北米、欧州およびアジアで開催されます。コネクタソンの結果は、
www.ihe.net/およびwww.ihe-europe.org/con_resultから入手できます。結果を示すレイアウ
トでは、各ベンダが列で示され、そのベンダがコネクタソンで成功したアクタとプロファイル
がドットで示されます。成功したかどうかは、コネクタソンプロジェクト管理スタッフが判断
します。スタッフはスポンサー組織(例えばHIMSS、RSNA、ACC)の雇用する独立技術者です。
ベンダが成功と判断されるには、自社製品を少なくとも他の3社の製品とともに試験して成功
する必要があります。
D.2
IHE統合宣言書
IHE統合宣言書は、特定の製品が特定のIHE統合プロファイルをサポートしていることをベンダが宣
言したものです。多くのベンダがウェブサイトに製品統合宣言書を掲載しています。それらのサイト
は単一の索引ページ、www.ihe.net/Resources/ihe_integration_statements.cfmにリンクしています。
自社の統合宣言書へのリンクをこのページに掲載したいベンダは、このページに記載の指示に従い申
込書を提出してください。
統合宣言書はベンダによる消費者への主張です。ベンダは、統合宣言書の公表にコネクタソン
で問題のシステムを試験するよう要求されることはありません。統合宣言書の内容の解釈につ
いての詳細に関しては、附属書Eを参照してください。
2005 年 6 月 20 日
56
IHE 放射線ユーザハンドブック
附属書E
統合宣言書の理解
IHE統合宣言書は簡潔な文書であり(１ページの場合が多い)、どのIHE統合プロファイルが製
品によりサポートされるか、どのIHEアクタ役割をシステムがプロファイルの中で果たすか述
べたものです。ベンダは、自社のウェブサイトに統合宣言書を公表するか、またはRFPに応じ
てそれらを提供します。ここに例があります：
IHE統合宣言書
ベンダ
Integrated Medical
Systems社
製品名
Mega CT
バージョン
V3.2
日付
2002年10月17日
この製品は、下記のIHE統合プロファイル、アクタおよび選択肢をサポートするためIHE TFの
中で要求されるトランザクションをすべて実装しています：
実装された
統合プロファイル
実装されたアクタ
実装された選択肢
予約済みワークフロー
撮影装置
患者に基づいたワークリスト問い合わ
せ、支援収集プロトコル設定
可搬用画像データ交換
画像データ書込み
選択肢は定義されませんでした。
ベンダのIHE情報のウェブアドレス: www.integratedmedicalsystems.com/ihe
実装の規格適合性宣言へのリンク
HL7
なし
DICOM
www.integratedmedicalsystems.com/dicom/MegaCT-DCS.pdf
一般的なIHE情報へのリンク
北米では：
欧州では：
日本では：
www.ihe.net
www.ihe-europe.org
www.jira-net.or.jp/ihe-j
統合宣言書は、IHE放射線TF、ボリューム1、附属書Dに詳述してあります。
宣言書の最初の部分は、宣言書がベンダIntegrated Medical Systems社製Mega CTシステム、
バージョン3.2に当てはまることを示します。宣言書は2002年10月17日に公表されました。
宣言書の中央の部分は、このCTシステムは、IHE予約済みワークフロープロファイルを撮影
装置アクタとしてサポートし、予約済みワークフロー中の2つの選択肢(つまり患者に基づいた
ワークリスト問い合わせ、支援収集プロトコル設定)をサポートすることを示します。さらに、
IHE可搬用画像データ交換プロファイルを画像データ書込みアクタとしてサポートします。
2005 年 6 月 20 日
57
IHE 放射線ユーザハンドブック
附属書F
DICOM適合性宣言の受理と理解
ベンダは、一般にDICOM適合性宣言(DCS)を各製品に対し顧客の依頼に応じて提供します。
しばしば、これらの文書は、ベンダのウェブサイトにありダウンロードできます。そうでなけ
れば、販売員に技術部からDCSを入手するよう依頼してください。DCSは、ベンダ製品の
DICOM能力を詳述しています。
DICOMはベンダに多くの詳細事項を任せており、多くのものがオプションなので、ベンダは
自社製品に何ができるかDCSの中で詳述しなければなりません。DICOMは、DCSに何を書く
べきか、その書式はどうするかについて最近更新しました。詳細はDICOM規格の第2部を参照。
それはdicom.nema.orgで入手できます。
DCSには次の説明があります：
どのサービスをベンダが実装したか：例えばDICOM保存かまたはDICOM MWL管理か。
サービスのサポートを実装したのは、サービスのクライアント(SCU)としてか、サーバー(SCP)
としてかまたは恐らくその両方としてか。
どんなオブジェクトがキーサービスのためにサポートされているか(例えばCTオブジェクトの
保存、造影されたMRオブジェクトまたは循環器検査手続の報告書)。
しばしば、キーの詳細、例えば製品がサポートするのはSCUかまたはSCPのような特定のサー
ビスどうかなどを見つけるには、タイトルページまたは目次を見ればわかります。しばしば、
語句「SOP Class Unique Identifier」を探すと、その製品にサポートされた特定のオブジェク
トについて質問の答えがわかります。
IHE統合宣言書はDCSによって扱われる問題のうちのいくつかに対し単純なアプローチを提
供しますが、統合宣言書はDCSの代わりにはなりません。さらに、非IHEシステムをもつ既存
システムの統合を扱うときDCSは特に有用になります。DCS文書の内容の詳細な分析は、この
附属書の範囲外です。
2005 年 6 月 20 日
58
IHE 放射線ユーザハンドブック
附属書G
HL7インターフェース仕様の受理と理解
ベンダがHL7に適合すると主張したとしても、その主張は、DCSと異なり流通が広くなく書式
が厳密ではありません。しかしベンダにHL7「インターフェース仕様書」を提供するよう依頼
することはしばしば可能です。この文書には、ベンダのシステムが作成し受理するメッセージ
のタイプ、それらのメッセージ中のフィールド、メッセージがいつ送られ予期されるか、フィ
ールドがどのように満たされるかが詳述されています。しばしば、HL7に基づいたシステムは
非常に融通性があり、それらのHL7インターフェース振舞いをあなたのニーズに適応させるこ
とができます。ニーズの複雑さによっては、これらの種類のインタフェー経験者を雇い、HL7
インターフェースを評価し、カスタマイズしてもらいたいと思うかもしれません。
ベンダがあなたにそれらのインターフェースに何を期待するかについての詳細を提供するよ
う依頼した場合、IHE TFを指摘して、システムがどのプロファイルおよびアクタ役割を果た
すことを期待するかをベンダに伝えてください。そうすれば、システムの完全利用はできない
としても、少なくとも機能性の一部に対し詳細な仕様を提供できます。
2005 年 6 月 20 日
59
IHE 放射線ユーザハンドブック
附属書H
受入テストの実施
施設は、実装プロセスの一部として受入試験を含めることが強く推奨されます。これには受入
計画を開発する必要があります。受入計画には、受入試験の実施、合格か不合格を決める仕様、
予定などが含まれます。典型的には、計画に含む受入試験は、ベンダと顧客が合意したもので
す。一旦統合されるシステムが識別されたならば、受入試験を開発することができます。受入
試験は、物理的なシステムをすべてインストールしネットワークに適切に接続した後に行なう
ことをお勧めします。システムの一部を使用して受入試験を行なうことは可能かもしれません
が、その場合、追加の分析と試験設定が必要になるかもしれません。
受入計画を開発するには技術スタッフ(コンサルタントまたは内部の開発要員)が必要です。こ
のハンドブックが扱うのは相互運用特徴の受入試験だけであり、個々のシステムで提供される
他の特徴はすべて含まれないことに注意してください。さらに受入試験で注目するのは機能性
であり、速度のような性能の問題ではありません。
一旦設置に関与するIHEプロファイル、アクタおよびトランザクションがすべて識別されたな
らば、関係する各システムについて受入試験のリストを書くことができます。IHE TFのボリ
ューム1を使用して、トランザクション試験の高水準のリストを作成します。それには適切な
プロファイルの各々に対しアクタ／トランザクションの表を見直します。IHE TFのボリュー
ム2および3(および国内拡張仕様がある場合はボリューム4)を使用して、(さらにあなたのプロ
ジェクト仕様、HL7仕様書およびDCSも使用して)、受入試験データセットの詳細および試験
実施後の予想結果を作成します。
一旦試験仕様書をすべて集めたならば、試験計画を作成します。試験計画は次のコンポーネン
トを含んでいることをお勧めします：
試験を行なうためにどのシステムが要求されますか。
実行されるべき試験のリストは何ですか。
試験を行なうためにどのデータが要求されますか。
試験のオペレーションはどのように検証されますか(例えば、どの試験ツールが必要ですか。)
各試験についてどんな結果が予想されますか。
各コンポーネントが重要であり、その作成に時間をかけることをお勧めします。
試験システムの組：試験システムの組は、相互に連結するシステムをすべて含む必要がありま
す。ある場合には、実際の環境が試験によって影響されないよう別個の試験環境を設定する必
要があります。他の場合には、実際の環境を使用できますが、システムを試験するために使用
するタイミングとデータは慎重に考える必要があります。
試験の開発：試験戦略は、どのシステムを統合するかにより異なります。同様に、結果の確認
は、展開するシステムの能力および施設自体のワークフローにより異なります。注意すること
は、もし非IHEシステムが施設に関係すると、予想結果がどうなるか決めるために追加の評価
が必要になることです。なぜなら完全なIHE環境の中で起る結果から逸脱するかもしれないか
らです。
いくつかの試験の詳細が、このハンドブック中の各章／シナリオの受入試験セクションに列記
してあります。さらに、TFのボリューム1の文書化されたプロファイルの多くは、ユースケー
スを含んでいます。それはIHEで取り組むバリエーションの詳細を含んでいるので、あなたの
試験にそれを含めることができます―例えば予定外の収集、単純なシングルステップ収集、追
加収集および「グループケース」収集などです。
試験データ：特定の試験データは、試験されるユースケース、施設の運営に関係するデータに
よって異なります。データは現実のケースを代表することが望ましく、患者人口統計、
2005 年 6 月 20 日
60
IHE 放射線ユーザハンドブック
オーダおよび手続的な情報の完全なセットを含むことが望ましいです。場合によっては、代表
的な「共同使用結果」、例えばDICOM画像および報告書が必要かもしれません。特定のデー
タフィールドをもった数社のメーカーからの多くのモダリティシステムが、相互運用特徴を完
全に試験するために要求されるかもしれません。
ある施設を実装するのにIHEユースケースがすべて関係するとは限りません。例えば、施設に
よっては、要求された手続きにつき手続きステップは１つしかないように手続きを常に構築す
るかもしれません。この場合、多数の予約済み手続きステップを扱うIHE機能性は関係があり
ません。
試験ツール：結果を検証するには、ツールと複数システムを使用する必要があるかもしれませ
ん。例えばHL7ツール、DICOMツール、結果画像を表示するモダリティの使用、またはDICOM
画像内の情報が検索されたMWL情報をすべて含むことを検証するPACSシステムの使用など
です。下記は結果の妥当性確認をするための種々のツールです：
HL7パーザ：HL7メッセージのフィールドを解析し、人間が判読しやすい方法でコンポーネン
トを示します。
DICOMバリデータ：DICOM画像ヘッダーの内容がDICOM規格に適合するかどうかチェック
します(フリーウェアwww.dclunie.com/を参照)
DICOMスニッファー：TCP/IPネットワーク上のトラフィックを観察し、DICOMに関連のト
ラフィックを識別し、読影のためDICOMコミュニケーションのコンテンツを組立てて保存す
る方法を提供します(フリーウェアwww.dclunie.com/を参照)
MESAツール：IHE試験プロセスの一部として、HIMSSとRSNAは、ソフトウェアツールの開
発をセントルイスにあるワシントン大学のthe Electronic Radiology Laboratory at the
Mallinckrodt Institute of Radiologyに委託しました。そのツールによって、コミュニケーショ
ンパートナー、試験データおよび試験計画が提供され、ベンダがIHE TFを実装するときベー
スライン試験を行なうことを可能にします。これらの試験は範囲が限られていますが、試験計
画の開発には役立ちます(www.erl.wustl.edu/mesa/index.htmlを参照)。
場合によっては、さまざまなシステムの動きを検証するには多数のツールセットを使用するほ
うが有利かもしれません。ベンダが自社のシステムを試験するツールを提供することもありま
す。注意すべきことは、IHEは特定のベンダツールを推奨していないということです。
2005 年 6 月 20 日
61
IHE 放射線ユーザハンドブック
附属書I
性能の測定基準
適切な性能測定をすることは、有効に管理し改善しようとするすべてのプロセスにとって非常
に重要です。放射線のワークフローや他のプロセスも例外ではありません。適切な測定を選択
し、測定値を集め、フィードバックに対応すると、事情のわかった管理と急場しのぎの介入と
の差がつきます。何を測定するか考えるだけでも、現在の優先事項と目標と理想の姿を見直す
ことができます。
適切な測定基準を念入りに選択し、測定し、追跡することは、言うは易く行なうは難しです。
IHE賛成論の一つは、紙から電子的なワークフローに切り替えることが容易になり、多くの適
切な値が自動的に集まるので、手作業で測定値を集めるより実際的であるということです。手
作業は本来の仕事から気をそらさせます(Heisenbergの原則が働きます)。
統合プロジェクトを考慮する時に、測定基準を集め始めます。変更を計画する時、測定基準は
特に有用です。良い測定基準は、現在の慣行のベースライン測定を確立し、改良の余地を指摘
し、プロセスおよび技術の変更案による影響を評価し、変更と平衡への回帰に起因する初期の
混乱を追跡し、プロセスそして最終的にはプロジェクト成功への影響を確認／是正します。
さらに、測定基準は医療産業全般に役立ちます。測定基準が圧力となって、看護が改善されコ
ストが減りそれらの目標に向けて新技術を効果的に適用するからです。測定基準を集める施設
は、結果を共有するように強く推奨されています。RSNAは、IHEを実装する前と実装した後
との比較研究が公表されることに特に関心をもっています。
I.1
何を測定するか
何を測定し最適化するべきであるか決めることは、重要な仕事です。システムとその関係者は
選んだ目標を最適化するため順応し、時には予定外の戦略を使用して不適当な犠牲を払うこと
があります。臨床的メリットをすべて代表的な測定値に換算できるとは限りませんが、換算で
きるメリットは多いので、測定基準は目標を確立し目標への進捗状況を測定する有効な方法で
す。考慮するべき値には、先ず出発点として下記の値があります。あなたの優先事項とプロセ
スを反映する測定基準を選択してください。学術的な情報については、セクションで後述する
情報源を参照してください。
放射線科の運営上の測定基準：1つの専門分野の1年当たりの患者人数、1台の設備の1日当たり
の患者人数、1年当たりの手続き件数、1つの手続き当たりのステップ数、1年当たりのフィル
ム媒体のコスト、1年当たりのフィルム現像処理と処分のコスト、1年当たりのカルテフィルム
の保存取扱コスト、報告書のターンアラウンド時間、1年当たりの反復検査、1年当たりの「整
合性確保イベント」の件数、「整合性確保イベント」1件当たりに費やした時間、手作業によ
る患者情報入力の誤り率
患者経験測定基準：着いてから帰るまでの患者「ターンアラウンド」時間および放射線科の患
者待ち時間
プロジェクト実装測定基準：システムとインターフェースを指定する時間、統合を試験する時
間、カスタムインターフェースに費やした時間／金銭
測定基準の一つのアプローチは、プロセスにおける重要な節目／進行管理点で、各試験のため
にタイムスタンプを記録することです。
入院患者検査：オーダを書く、検査の予約 (オプション)、前回のフィルムの利用 (オプション)、
手続きプロトコルの選択 (オプション)、患者同意を得る(オプション)、搬送手配、患者が放射
線科に到着、患者が処置室に入る、走査の開始、走査の終了、患者が処置室から出て病室に帰
る
2005 年 6 月 20 日
62
IHE 放射線ユーザハンドブック
外来患者の検査：検査の予約 (オプション)、患者の到着、オーダを書く、前回のフィルムの利
用 (オプション)、手続きプロトコルの選択 (オプション)、患者同意を得る(オプション)、患者
が処置室に入る、走査の開始、走査の終了、患者が処置室から出て帰宅する
画像の取扱い：検査をPACSに転送、現在と検査を前回の検査と比較、現在の検査を読影、現
在の検査をアクティブファイルに置く、現在の検査を保存、検査終了
報告：予備レポート呼び出し、報告書の書取り、報告書の転写、報告書の編集、報告書に署名、
報告書の配布、報告書の保管
レインバースメント：患者情報の収集
タイムスタンプのデータで、時間に関連する多くの測定基準は計算できます。特定の節目をど
こに決めるかは施設のワークフローによって異なります。タイムスタンプの順序も恐らく施設
によって、また検査によって変わります。ある程度の融通性が必要でしょう。
他の多くの情報源およびアイディアが放射線科での測定基準の使用に関して存在しています。
考慮するべき情報源は、次の学会、論文、出版物です。
RSNAとその出版物RadiologyおよびRadioGraphics；SCAR(Society for Computer
Applications in Radiology)とその出版物Journal of Digital Imaging；AHRA(American
Healthcare Radiology Administrators)とその出版物Radiology Management；RBMA
(Radiology Business Managers Association)と放射線科生産性測定に関する出版物；
ECR(European Congress of Radiology)とその出版物European Radiology；MIR
(Management in Radiology)
別の情報源はあなたの同僚です：同僚の目標について、また何を測定しているか尋ねてくださ
い。「最高級」の病院を見つけるためには、HIMSS Davies Award of Excellence in healthcare
ITの毎年の受賞者を参考にしてください。
I.2
サンプルの測定結果
このセクションは、いくつかの施設が有用と考えていた測定と記録した値を論じます。これは
利用できる情報のうちの手っ取り早いサンプルです。更に詳しい情報は上記の情報源からでき
ます。多くの施設が注目しているのは、報告書が利用できるまでの所要時間であり、これが放
射線科の顧客に最重要の性能測定基準であるとしています。所要時間の開始時刻は研究が異な
ると異なります。例えば検査をオーダした時刻、患者が検査のため到着した時刻、画像が読影
できる時刻などです。あなたが選んだ測定基準を明確に定義することは、それを他の施設が参
考にして比較し使用できるために重要です。
結合*入院患者および外来患者報告書ターンアラウンド時間†パーセンタイル―病院
ターンアラウンド
時間
パーセント
一般的な放射線検査
6時間以下
7-12 時間
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
コンピュータ断層撮影
6時間以下
7-12 時間
2005 年 6 月 20 日
回答者の数
30%
21%
8%
27%
3%
6%
6%
71
51
18
64
6
15
13
27%
22%
63
52
ターンアラウンド
時間
核医学
6時間以下
7-12 時間
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
特殊手技
6時間以下
7-12 時間
63
パーセント
回答者の数
25%
24%
9%
27%
2%
6%
6%
55
54
19
60
4
14
15
27%
19%
54
37
IHE 放射線ユーザハンドブック
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
磁気共鳴
6時間以下
7-12 時間
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
超音波
6時間以下
10%
25%
4%
6%
7%
23
60
9
14
16
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
すべての放射線検査
6時間以下
7-12 時間
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
6%
29%
4%
7%
10%
11
57
8
13
20
21%
17%
8%
33%
5%
5%
11%
37
31
15
60
10
10
21
25%
22%
9%
26%
3%
7%
7%
81
72
30
83
11
23
24
29%
69
* 結合したデータは、回答者によって提供され
ました。
7-12 時間
22%
54
†各検査分野で±2 SD範囲の外側のデータは
除外されました。
13-18 時間
19-24 時間
25-30 時間
31-36 時間
36時間超
9%
26%
4%
5%
5%
22
63
9
13
12
上の表は次の出典から許可を得て転載しました。Table 9 of the American Healthcare
Radiology Administrators (AHRA), Hanwell LL, Conway JM. "Radiology Report
Turnaround Time." American Healthcare Radiology Administrators, AHRA Survey (1995).
ベッド数が450強のある病院での調査では、報告書ターンアラウンド時間(オーダから最終報告
書までの所要時間)は平均26時間でした。それで18時間以下にするという目標を立てました。
RDI Marketing Service社がRISのある施設とRISのない施設の性能を比較した結果です：
1か月当たりの手続きの件数
RISありは5,760件
RISなしは1,690件
報告書ターンアラウンド時間
24時間
30時間
トランスクリプションのターンア
ラウンド
11時間
14時間
磁気共鳴(MR)画像施設の処理能力調査によれば、182箇所の施設(MR画像システムは197台あ
り)が処理した患者は2,045,954人でした。つまり1年当たり走査した患者は平均3,010人±188
人(標準偏差)で (最小の施設は626人、最多の施設は6,000人)でした。
(www.invivoresearch.com/arti_clin_seda.html)。
“Reinventing the Radiology Report, 2: Time to Adapt”by Bruce Reiner, MD and Eliot
Siegel MDによれば、「最近の調査では、CT検査の平均報告書ターンアラウンド時間は、
2005 年 6 月 20 日
64
IHE 放射線ユーザハンドブック
中間報告だけでも3.7日、最終報告は5.5日の間である。これらの数字を見ると、従来の報告は
非能率的で遅いので紹介臨床医は不満を感じている。」 4
ある施設のプロジェクトの成功例では、放射線検査の予約から報告書提供までの測定基準のタ
ーンアラウンド時間が平均10日から2日に短縮したという。
(www.cisco.com/en/US/strategy/healthcare/hospitals_sentara.html).
ある施設では、撮影予約スロットをすべて30分に変え、オペレーションの時間を拡大すること
により、画像診断の生産性、ボリューム、収入が増加しました。昼休みや休憩時間も走査でき
るので、予約できるCT走査の件数は1か月当たり140件増加しました。全体として、外来患者
が予約できる件数は約75%増加し、年間総収益見込みは150万ドル増加しました。
(www.ahraonline.org/AHRAArticles/AHRAArticles.dll/Show?ID=414)
多くの施設でこれらのターンアラウンド時間の改善を文書化しています。ある施設では、検査
から読影まで(従来の8～24時間かかっていたのが短縮され)平均約20分となりました。また読
影からトランスクリプション(それはPACSまたはHISで直ちに読める)まで1～2日かかってい
たのが短縮され2時間になりました(デジタル書取りシステムに電話して読んだあと直ちに利
用できる)。5 他にも色々な報告書がターンアラウンド時間の短縮について同様に印象的な報告
をしています。
Mehta A、Dreyer K、Boland G, et al. Does PACS improve report turnaround time? Journal of Digital
Imaging 2000;13:105-107
5 Mattern CW、King BF Jr.、Hangiandreou NJ et al. Electronic imaging impact on image and report
turnaround times. Mayo Medical Center, Rochester, MN 55905.
4
2005 年 6 月 20 日
65

地域包括ケア情報連携研修会実施要領

nordicBrainExの仕様書

愛とフランス

PACS, 遠隔医療・CAD

可搬媒体の取り扱いの現状と問題点

PACS 環境において自動作成されたサブトラクションイメージの画質評価

電子カルテ化のその後 - JASTRO 日本放射線腫瘍学会

MityForOne MityForOne

「可搬型医用画像」 およびその運用指針(2015年6月JAMI, IHE勉強会)

垰本勝司 - 大西脳神経外科病院