1
2
3
4
5
6
7
8

医療連携のための情報統合化プロジェクト

9
10
11
12
13
14
15
16
17
18
19

IHE 患者ケア装置（PCD）

20

テクニカルフレームワーク

21

ボリューム 122

改正 1.0b

23
24
25
26

最終テキスト27

2010 年 11 月 22 日

28
29

著作権所有©2010：IHE International

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

目次

1

序 ..................................................................................................................................... 4
1.1 テクニカルフレームワークの概観 ......................................................................................5
1.2 ボリューム 1 の概観............................................................................................................6
1.3 対象者..................................................................................................................................6
1.4 規格との関係 .......................................................................................................................6
1.5 現実世界のアーキテキチャとの関係...................................................................................7
1.6 規約 .....................................................................................................................................7
1.6.1 アクタおよびトランザクションの図および表..............................................................7
1.6.2 プロセスフロー図 .........................................................................................................8
1.6.3 テクニカルフレームワークの規定コンテンツ対参考コンテンツ.................................8
1.6.4 テクニカルフレームワークの相互参照.........................................................................91.6.5 トランザクション参照..................................................................................................9
1.7 IHE 患者ケア装置の本年度の見通し .................................................................................9
1.8 コメント ............................................................................................................................11
1.9 版権許可 ............................................................................................................................11
1.10 IHE テクニカルフレームワークの開発と保守プロセス ..................................................11
1.10.1 新開発－既存のテクニカルフレームワークの拡張 ....................................................13
1.10.2 既存のテクニカルフレームワークコンテンツの保守.................................................14
1.10.3 テクニカルフレームワークの使用..............................................................................15
1.10.4 製品の検証と妥当性確認の意味 .................................................................................15

2

PCD 統合プロファイル ................................................................................................. 17
2.1 統合プロファイル間の依存性............................................................................................17
2.2 統合プロファイルの概観...................................................................................................18
2.2.1 装置施設情報通信（DEC）........................................................................................192.2.1.1 患者識別に関する注記 ....................................................................................192.2.2 臨床現場輸液検証（PIV） .........................................................................................192.2.3 埋込み型装置－心臓病－検査（IDCO） ....................................................................20
2.2.4 ロゼッタ用語マッピング（RTM）.............................................................................213

アクタおよびトランザクションの概観 .......................................................................... 22
3.1 アクタの記述 .....................................................................................................................22
3.2 トランザクションの記述...................................................................................................23
3.3 製品の実装.........................................................................................................................23

4

装置施設情報通信（DEC） ........................................................................................... 25
4.1 アクタ／トランザクション ...............................................................................................25
4.1.1 患者情報－推奨トランザクション ............................................................................26
4.2 統合プロファイルオプション............................................................................................26
4.3 プロセスフロー図..............................................................................................................27
4.3.1 標準的なユースケース................................................................................................27
4.3.1.1 ケース DEC-1：患者の身元確認された DEC データを EMR／EHR へ通信.......27

2

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

4.3.1.2 ケース DEC-2：有効な周期的 DEC データを EMR／EHR へ通信 ................27
4.3.2 自動患者情報取得のためのオプショナルユースケース ........................................28
4.3.2.1 ケース DEC-ID-1：ADT に知られている患者 ID、局所的に利用可能 .........29
4.3.2.2 ケース DEC-ID-2：ADT に知られている患者 ID、局所的に利用不可 .........29
4.3.2.3 ケース DEC-ID-3：ADT に知られていない患者 ID、局所的に利用可能......29
4.3.2.4 ケース DEC-ID-4：ADT に知られていない患者 ID、局所的に利用不可......29
4.3.2.5 その他の臨床例 ...............................................................................................30
5

臨床現場の輸液検証（PIV） ......................................................................................... 31
5.1 アクタ／トランザクション ...............................................................................................31
5.2 統合プロファイルオプション............................................................................................33
5.3 統合プロファイルプロセスフロー ....................................................................................33
5.4 統合プロファイルの安全性とセキュリティ考察...............................................................34

6

埋込み型装置－心臓病－検査（IDCO）........................................................................ 35
アクタ／トランザクション ...............................................................................................35
IDCO 統合プロファイルオプション .................................................................................36
IDCO ユースケース ..........................................................................................................36
6.3.1 ユースケース IDCO-1：埋込み型心臓装置の臨床中経過観察 ..............................37
6.3.2 ユース ケース IDCO2：情報を解読するネットワークプログラマによる埋込み型心臓装置の臨床中経過観察 ......................................................................37
6.3.3 ユースケース IDCO-3：埋込み型心臓装置の遠隔経過観察..................................37
6.3.4 ユースケース IDCO-4：埋込み型心臓装置の遠隔監視 .........................................38
6.4 IDCO プロセスフロー.......................................................................................................38
6.5 IDCO 患者識別考察 ..........................................................................................................40
6.6 IDCO セキュリティ考察 ...................................................................................................41
6.1
6.2
6.3

7

ロゼッタ用語マッピング（RTM） ................................................................................ 42
7.1 問題記述 ............................................................................................................................42
7.2 アクタ/トランザクション..................................................................................................43
7.3 統合プロファイルオプション............................................................................................43
7.4 統合プロフィルプロセスフロー ........................................................................................43
7.5 主要ユースケース..............................................................................................................43

用語辞典 ................................................................................................................................... 45

3

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

1 序
医療連携のための情報統合化(IHE)は、現代の医療機関をサポートする情報システムの統合化を促進するように設計された構想である。その基本的な目的は、患者ケアにおいて医療決定のために必要とされる情報の全てが正確であり、かつヘルスケア専門家へ利用可能であることを確実にすることである。IHE 構想は、統合化の努力を奨励するためのプロセスでもありフォーラムでもある。それは、特定の臨床目標を達成するために確立されたメッセージング規格の実装のためのフレームワークを定義する。それは、このフレームワークの実装のための厳格な試験プロセスを含む。それはまたこのフレームワークの利益を実証し、かつ業界とユーザによるその採用を促進させるために、医療専門家の主な会議で教育セッションと展示会覧を組織する。
IHE 構想に採用されるアプローチは、
新しい統合化規格を定義することではなくて、
むしろ HL7、
DICOM、IETF などの既存の規格について、それらの各領域において統合化された方法で、必要な時にはコンフィギュレーション選択を定義して、それらの使用を適切にサポートすることである。既存の規格に対する明確化または拡張が必要になる時には、IHE は関連する規格諸団体に対して勧告を回付する。
この構想は、異なる医学専門領域や地理学的地域において多数のスポンサーと支援組織をもっている。北米では主要なスポンサーは、医療情報・管理システム学会（HIMSS:Healthcare
Information and Management Systems Society）と北米放射線学会（RSNA:RadiologicalSociety of North America）である。IHE カナダもまた形成されている。IHE ヨーロッパ(IHE-EUR) は 、 次 を 含 む 諸 組 織 の 大 統 合 体 に よ っ て 支 援 さ れ て い る : 欧 州 放 射 線 学 会（EAR:European Association of Radiology）と放射線医師会（ECR:European Congress ofRadiologists）、放射線・医用電子産業調整委員会（COCIR:Coordination Committee of theRadiological and Electromedical Industries ）、 ド イ ツ 放 射 線 協 会 （ DRG:Deutsche
Rontgengesellschaft）、ユーロパックス協会（EuroPACS Association）、患者情報システム改革機関（GMSIH:Groupement pour la Modernisation du Systeme d'Information Hospitalier）、
フランス放射線学会（SFR:Societe Francaise de Radiologie [www.sfr-radiologie.asso.fr]）、およびイタリア放射線医学協会（SIRM:Societa Italiana di Radiologia Medica）。日本では、IHE-Jのスポンサーは、経済産業省(METI)；厚生労働省；並びに MEDIS-DC [WWW.medis.or.jp]である；協力組織には、日本画像医療システムズ工業会(JIRA)、日本保健医療福祉情報システム
工業会(JAHIS)、日本医学放射線学会(JRS)、日本放射線技術学会(JSRT)、および日本医療情報学会(JAMI)が含まれる。医療従事者を代表する他の組織は、学問分野や地理学的な境界を横切って IHE プロセスの拡張に参加するよう招待されている。
種々の領域（患者ケア調整、IT インフラストラクチャー、心臓病学、実験室、放射線学、等）のための IHE テクニカルフレームワークは、最適の患者ケアを支援する医療情報の適切な分担を促進する統合化目標を達成するために、確立された規格の特定の実装を定義する。これらは公開見直し期間後に毎年拡張され、また正誤表の識別と修正を通じて規則的に保守されている。これらのテクニカルフレームワークの最新版は、www.ihe.net に見出される。

4

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

IHE テクニカルフレームワークは、IHE アクタと呼ばれる、ヘルスケア施設の機能的な構成要
素の下位集合を識別し、また一組の調整された規格ベースのトランザクションの観点から、それらの相互作用を規定する。それは、この多くのトランザクションを漸次より深く記述する。ボリューム 1 は、IHE 機能性の高レベルの見解を提供し、特定の臨床ニーズに対処する能力を強調
する、統合プロファイルと呼ばれる、機能ユニット中に組織化されるトランザクションを示す。
引き続く続巻は、各々の IHE トランザクションの詳細にわたる技術的な記述を提供する。
1.1 テクニカルフレームワークの概観
この文書、IHE 患者ケア装置テクニカルフレームワークボリューム 1(IHE PCD TF-1)は、患者ケア装置領域のための統合化目標を達成するために確立された規格の特定の実装を規定する。そのような統合化は、最適の患者ケアを支援する医療情報の適切な分担を促進する。IHE PCD TF
は、公開見直し期間後に毎年拡張され、またエラーの識別と修正を通じて規則的に保守される。
IHE PCD TF は、IHE アクタと呼ばれる、ヘルスケア施設の機能的な構成要素の下位集合を識別し、また一組の調整された規格ベースのトランザクションの観点から、それらの相互作用を規定する。それは、この多くのトランザクションを漸次より深く記述する。患者ケア装置テクニカ
ルフレームワーク(IHE PCD TF-1)のボリューム 1 は、IHE 機能性の高レベルの見解を提供し、特定の臨床ニーズに対処する能力を強調する統合プロファイルと呼ばれる、機能ユニット中に組織化されるトランザクションを示す。IHE PCD TF-2 は、各 PCD 特定の IHE トランザクショ
ンの詳細にわたる技術的な記述を提供する。IHE PCD TF-3 は、コンテンツに向けたプロファ
イルに関する詳細な仕様書を提供し、また特定の装置クラスからのコンテンツを含む。
IHE PCD TF は、次の領域特定の文書を含む、IHE テクニカルフレームワークの関連セットの一部である：
・IHE 心臓科テクニカルフレームワーク
・IHE IT インフラストラクチャーテクニカルフレームワーク
・IHE 放射線科テクニカルフレームワーク
・IHE 臨床検査テクニカルフレームワーク
・IHE 患者ケア装置テクニカルフレームワーク
IHE 患者ケア装置統合プロファイルは、それらの他の IHE テクニカルフレームワーク文書中に定義されるトランザクションに依存し、また参照をする。その他のフレームワークを参照する規約に関しては、このボリューム内の 1.6.4 を見ること。

5

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

1.2 ボリューム 1 の概観
セクション 1 の残部は、さらにテクニカルフレームワークの一般的な性質、目的、および機能を記述する。セクション 2 は、そのテクニカルフレームワークを構築する IHE 統合プロファイ
ルの概念を紹介する。
このボリュームのセクション 3 と続きのセクションは、各統合プロファイルについて、それが取り扱うことが意図されている臨床問題、およびそれが構成する IHE アクタとトランザクショ
ンを含めて、詳細な文書類を提供する。
その文書の本体に引き続く附属書は、統合プロファイルに関連した特定の事項の詳細な討議、および使用された用語と頭字略語の用語辞典を提供する。
1.3 対象者
この文書の意図した対象者は、次の通りである：
・ヘルスケア情報システムを統合化する技術面に興味がある臨床医
・IHE 構想に参加するベンダの技術スタッフ
・医療機関の IT、臨床技術、および医療情報部門
・規格開発に関与した専門家
1.4 規格との関係
IHE のテクニカルフレームワークは、分散しているヘルスケア環境の機能的な構成要素(IHE アクタと呼ばれる)を、ヘルスケア施設におけるそれらの相互作用の視点のみから識別する。その開発の現状レベルでは、それは HL7、IEEE、DICOM、W3C、およびその他の産業規格に基づいた組織的なトランザクションセットを定義する。IHE 構想の適用範囲が拡張するにつれて、その他の規格に基づくトランザクションも必要に応じて含まれることになる。
ある場合には、IHE は、これらの規格によってサポートされる特定のオプションヨンの選択を推奨する；しかし、IHE は、これらの規格への適合と矛盾する技術的な選択を導入することはしない。既存の規格中のエラーまたはそれらへの拡張が識別されるならば、IHE の方針は、それらの適合と規格進化戦略内での解決のためにそれらを適切な規格団体へ報告することである。
したがって、IHE は実装フレームワークであって、規格ではない。規格として IHE を参照する
ことは不適当である。製品適合は、特定の規格に直接言及して主張されなければならない。さらに、IHE 統合能力を実装したベンダは、IHE テクニカルフレームワークにおける仕様書への彼らの製品の適合性を記述するために、IHE 統合宣言書を使用しなければならない。IHE 統合宣言書の目的は、対応する製品のユーザに対して、サポートするように設計されてきた IHE 能力を均一な方式で通信することである。IHE 統合宣言書を公表するベンダは、彼らのコンテンツに関して十分な責任をとる。異なる製品からの IHE 統合宣言書を比較することによって、アクタや統合プロファイルの IHE 概念に精通しているユーザは、情報伝達が製品間でサポートできるかどうか、およびどのような範囲かを決定できる。そのような IHE 統合宣言書の書式に関しては、IHE PCD TF-2：附属書 I を参照すること。

6

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

IHE テクニカルフレームワークに従って実装された製品はまた、IHE 下にある規格の要求事項を十分に満たすことを確実にするよう IHE は実装者を奨励しているが、恐らく統合化のより低いレベルにおいてであるが、規格と適合して実装されていても IHE テクニカルフレームワークとは十分な適合状態にはない製品とも、その製品が相互に作用し合えるようにさせている。
1.5 現実世界のアーキテキチャとの関係
IHE テクニカルフレームワークに記述された IHE アクタとトランザクションは、現実世界のヘ
ルスケア情報システム環境を抽象化したもの概念である。トランザクションのいくつかは、特定の製品カテゴリ（例えば、HIS、電子式患者記録、RIS、PACS、臨床情報システム、患者ケア装置、または画像処理モダリティ）によって伝統的に実装されているが、IHE テクニカルフレームワークは、そのような製品カテゴリと機能またはアクタを関連づけることを意図的に避けている。各アクタに関して、IHE テクニカルフレームワークは、単に統合情報システムに関連した機能のみを定義する。したがって、アクタの IHE 定義は、それを実行するかもしれないあらゆる製品の完全な定義として解釈しないほうがよいし、またフレームワーク自体も、ヘルスケア
情報システムの構成を包括的に記述していると解釈しないほうがよい。
アクタとトランザクションを定義するための理由は、ヘルスケア情報システム環境の機能構成要
素間の相互作用を定義するための基礎を提供することである。単一の物的製品が多面的機能を実装する状況においては、その製品と環境中の外部機能との間のインターフェースのみが、IHE構想によって重要であると考えられている。したがって、IHE 構想は、単一の全て網羅している情報システムに基づいた統合環境か、一緒に同じ目的を達成する多重システムに基づいた統合
環境か、いずれかにメリットがあるかの優劣を決めるものではない。しかし、最も劇的に IHE
テクニカルフレームワークの可能性を明らかにするために、IHE 実証では、IHE テクニカルフ
レームワークに基づいた多重のベンダのシステムの統合化を強調している。
1.6 規約
この文書は次の規約を採用した。目的は、フレームワーク概念を表し、IHEのテクニカルフレー
ムワークの基礎となる規格をどのように適用することが望ましいか規定するためである。
1.6.1 アクタおよびトランザクションの図および表
統合プロファイルはそれぞれ、トランザクションを通じて対話する 1 組のアクタによりサポートされる現実世界の能力を表現したものである。アクタは、情報システムまたは情報システムの構成部分であって、施設での運用上の活動によって要求される情報カテゴリを生産するか、管理するか、それに作用する。トランザクションは、規格に基づいたメッセージを通じて必要な情報を通信するアクタ間の相互作用である。
以下のセクション中のアクタおよびトランザクションの図および表は、与えられたプロファイル
中でアクタがそれぞれ、どのトランザクションをサポートしなければならないかを示す。

7

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

図上に示されたトランザクションは、PCD TF-1 に定義されているように、それらの名前とトラ
ンザクション番号の両者によって識別される。トランザクション番号は、特定のテクニカルフレームワーク領域による接頭辞をもつ角括弧内の番号として、図上に示される。
ある場合には、プロファイルが適切に機能し、かつ有用なために前提条件のプロファイルに依存する。例えば、施設内ユーザ認証は時刻同期に依存する。これらの依存性を見つけるには、表2-1 の中で希望のプロファイルを探し、どのプロファイルが前提条件としてリストされているか決めることで可能である。アクタは、希望のプロファイル中のものに加えて、前提条件のプロフ
ァイル中の必要なトランザクションをすべて実装しなければならない。
1.6.2 プロセスフロー図
以下の統合プロファイルの記述は、関連のアクタ間のトランザクションのシーケンスとして、プロファイルがどのように機能するかを図示するプロセスフロー図を含む。
これらの図は、トランザクションが全体的なワークフローという状況で見られるように、「大きい図面」を提供することが意図されている。IHE によって詳細に定義されていないあるトランザクションと活動は、関連の IHE トランザクションが、ヘルスケア情報システムのより幅広い
スキーム中の何処に適合するのかについての追加状況を提供するために、これらの図中にイタリック体で示されている。
これらの図は、唯一の可能なシナリオを提供することは意図されていない。しばしば、その他のアクタグルーピングが可能であり、またその他のプロファイルからの相補的なトランザクションが散在しているかもしれない。
ある場合には、トランザクションのシーケンスが柔軟であるかもしれない。その場合には、一般に変動の可能性を指摘する注釈が存在する。
トランザクションは、そのトランザクションによって扱われる一次情報の流れに沿う方向に向いた矢印として示され、また必ずしもイニシエータではない。
1.6.3 テクニカルフレームワークの規定コンテンツ 対 参考コンテンツ
テクニカルフレームワークの大部分は、統合プロファイル、アクタ、およびトランザクションの必要とされるまたは自由選択の特性を記述する：これらは規定である。テキストのより良い理解のために、参考および規定であるテクニカルフレームワーク中に説明図（または例）もまた存在する。
IETF RFC 2119 に従って、ある言葉は、テクニカルフレームワークの特定のコンテンツが規定であるかどうかを示す：必要な（例えば、"must"(ねばならない)、"required"(要求される)、"shall"(しなければならない)）または自由選択の（例えば、"may"(かもしれない)、"recommended"(推奨される)）の何れか。参考コンテンツは、これらのキーワードを含んでいな
い。

8

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

1.6.4 テクニカルフレームワークの相互参照
同じテクニカルフレームワークボリューム内のセクションに対して、参照がなされる時には、セクション番号が単独で使用される。別のボリュームまたはもう一つの領域におけるテクニカルフ
レームワークに対して、参照がなされる時には次のフォーマットが使用される：
IHE<領域指名>TF-<ボリューム番号>:<セクション番号>、ここで：<領域指名>は、IHE 領域のための短い指名である（例えば、ITI = IT インフラストラクチャ
ー分野、RAD = 放射線分野、CARD = 心臓病分野、LAB = 実験室、PCD = 患者ケア装置）<ボリューム番号>は、所定のテクニカルフレームワーク内の適用可能なボリューム（例えば、1、2、3）であり、また<セクション番号>は適用可能なセクション番号である。
例えば：IHE ITI TF-1:3.1 は、IT インフラストラクチャーテクニカルフレームワークのボリューム 1 の（セクション 3.1）を参照する：IHE RAD TF-3:4.33 は、IHE 放射線部門テクニカル
フレームワークのボリューム 3 の 4.33 参照する。
1.6.5 トランザクション参照
トランザクションに対して参照がなされる時、次のフォーマットが使用される：<領域指名>-<トランザクション番号>、ここで：<領域指名>は、IHE 領域に関する短い指名である（例えば、ITI = IT インフラストラクチャ
ー、RAD = 放射線部門、CARD = 心臓病部門、LAB = 実験室、PCD = 患者ケア装置）<トランザクション番号>は、その領域に関するテクニカルフレームワークに規定されているような適用可能なトランザクション番号である。
トランザクションはまた、名前によって参照されてもよいが、しかしトランザクション名はその領域で、またトランザクション番号はその文書のセクション内で識別された後のみである。
1.7 IHE 患者ケア装置の本年度の見通し
IHE PCD は、サポートする試験環境、ホワイトペーパー、およびユーザガイドのようなその他の文書と同様に、各種の型の統合プロファイルを開発することに関与している。現在、全てのプ
ロファイルタイプが取り扱われてはいない；しかし、我々は次の条項を構想している：
・トランザクション統合プロファイル（メッセージ上に焦点）・コンテンツ統合プロファイル（構文論と意味論上に焦点）・装置統合プロファイル（特定の装置タイプ上に焦点）・臨床統合プロファイル（特定の臨床ワークフロー上に焦点）・および潜在的に必要に応じてその他のプロファイルタイプ
これは、最終テキスト中に公開される最初の IHE PCD テクニカルフレームワークである。それは次のプロファイルを含んでいる：

9

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

・ [DEC (Device Enterprise Communication)] 装置施設情報通信は、PCD データを施設情報システムへ通信する機構を記述するトランザクションプロファイルである。典型的な PCD
データは次を含む：周期的生理データ（心拍数、侵入性血圧、呼吸数、等）、非周期的生理データ（非侵入性血圧、患者体重、心臓出力、等）、および CLIA 放棄（または国際的権利放棄相当）臨床現場の実験室テスト（即ち、家庭血液ブドウ糖、等）。そのデータはまた、
患者 ID、ケア提供者識別、および患者ケア装置形態情報のような組織的情報を含んでもよい。
・[PIV (Point-of-care Infusion Verification)] 臨床現場輸液検証は、BCMA システムから輸液ポンプまたはポンプ管理システムへ、5-権利の有効な医薬品配達／輸液オーダ情報伝達、したがって「ループを閉じること」をサポートするトランザクションプロファイルである。

・[IDCO (Implantable Device Cardiac Observation)] 埋込み型心臓装置検査は、翻訳、通信、
および、心臓装置質疑（検査）に関連した分離性データ要素と報告付属品の加工処理のための機構を規定するトランザクションプロファイルである。

・ [RTM (Rosetta Terminology Mapping)] ロゼッタ用語マッピングは、ISO/IEEE 11073 意
味論と UCUM 測定単位を用いた標準規約表現に対して、今日の医療装置によって通信された所有権の意味論をマッピングする、一組のツール（Excel 表計算ソフトと XML ファイル）中に表現された学術用語を確立するコンテンツプロファイルである。
追加のプロファイルが開発されたか開発中であるが、しかし最終テキストへの進行に必要な要求事項をまだ満していない。これらには、次項が含まれる：・ [SPD (Subscribe to PCD Data)] PCD データへの署名は、DEC DOR から DEC DOC へ転送された情報を制限することを支援するトランザクションプロファイルである。それは、DEC プロファイルに対するオプションである。
・ [DPI (Device Point-of-care Integration)] 装置臨床現場統合は、装置または装置マネージャ／スーパバイザシステム間の「第一リンク」インターフェースを含めて、患者中心の臨床現場の周辺の装置結合性に焦点を当てたトランザクションプロファイルである。この活動には、
ホワイトペーパーの初期開発、その後の多くの提案されたプロファイル：例えば、発見と提携、データ報告、対称（双方向）通信、および外部制御などが含まれる。
・[ACM (Alarm Communication Management)] 警報通信管理は、正しいコンテンツ（例えば、証拠データ）を持つ正しい個人へ、正しい優先事項のある正しい警報を確実にするための、臨床現場の医療装置警報状況の遠隔通信を可能にするトランザクションプロファイルである。

・ [WCM (Waveform Communication Management)] 波形通信管理は、HL7 V2 検査メッセージを用いて実時間波形データの近くに通過する方法を提供するために、既存の IHE PCD
プロファイルを拡張することになるコンテンツプロファイルである。
更に、本年度の成果の一部として、技術報告書、および既存の文書への昨日強化が開発中である。
これらには次項が含まれる：・ [SA (Semantic Architecture White Paper)] 意味構成ホワイトペーパーは、患者ケア装置情報の真の意味の相互運用性を可能にするために用いられる、時々困惑させられる学術用語、
専門用語、および情報モデルの主題についての概観を提供することになる。特に[RTM]「ロゼッタ」プロファイルの開発の間に、それはまた、識別されたギャップを満たすために必要とされる新しい専門用語開発のための基本原理を敷くことになる。

10

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

・[MEM (Medical Equipment Management)] 医療機器管理は、健康 IT がどのように臨床技術／生体医学技術スタッフの活動を支援し、品質とワークフロー効率を改善するという問題を調査するホワイトペーパーである。基幹となる話題は、ユニークな装置識別、実時間位置検索、ハードウェア／ソフトウェア形態、およびパッチ管理、電池管理などを含む。
PCD は、これがトランザクションプロファイルに成長することになると予測している。

・PCD ユーザハンドブック－PCD 領域における特定の話題をインプリメンタが理解する助けになるための手段。この最初の成果は、RFP または RFI における IHE PCD プロフ
ァイルを規定する方法を管理者が示すための標的とされている。その文書は、種々のプロファイル、およびそれらを規定し実装することの利益を検討することになる。

・

プロファイル適合試験－IHE と NIST は、IHE-PCD プロファイルを横断して定義されているような、ベンダ実装を試験するために協力している。このサイクル年は、IHE-PCD V2
メッセージ検証を構文的にも意味的にも含んでいる。用語は、ISO/IEEE 11073 標準規格からの「調和したロゼッタ」用語に抑制されている。

1.8 コメント
ACCE は、この文書と IHE 構想についてのコメントを歓迎する。それらは、iheinfo@accenet.org
宛に送られるべきである。
1.9 版権許可
ヘルスレベル 7（Health Level Seven, Inc.）は、HL7 規格から表を再生するために、IHE に対して承認許可を得ている。この文書における HL7 の表は、ヘルスレベル 7 によって著作権が所有されている。版権所有。
米国電気製造業者協会（NEMA）は、DICOM 規格の部分を組み入れるために、IHE に対して承認許可を得ている。
電気電子技術者協会(IEEE)は、関連の IEEE 規格の限られたセクションを再生するために、IHEに対して承認許可を得ている。ISO/IEEE 11073 規格からのこのテクニカルフレームワークにおける著作権所有の IEEE 資料の使用は、IEEE-SA 特許使用が無料の許可指針によってカバーされている。
これらの文書から引き出された資料は、使用される場所でクレジットされている。
1.10 IHE テクニカルフレームワークの開発と保守プロセス
テクニカルフレームワークは、継続して進展しており、また他の領域特定の専門委員会と協力して、IHE 患者ケア装置専門委員会によって維持されている。フレームワークの開発と保守プロ
セスは、IHE 互換性製品を特定し、開発し、かつ取得する際に、ベンダとユーザ両者が頼るかもしれない仕様書の安定性を確実にするための多くの原則に従う。

11

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

これらの原則の第一は、テクニカルフレームワークに対するあらゆる拡張、明確化、および修正は、そこで定義された IHE アクタと統合プロファイルを実装したシステムとの相互運用性を保持するために、当フレームワーク以前の改訂版との後方両立性を保持しなければならないことである。
IHE PCD テクニカルフレームワークは、毎年次の 3 ステッププロセスに従って開発されかつ再発行される：
1.

PCD 専門委員会は、IHE 戦略的・計画委員会によって識別された新しい機能性をサポートするために、テクニカルフレームワークの現在の安定な改訂版の付録を開発し、またパブリックコメントのためにそれらを公表する。

2.

当委員会は、パブリックコメント期間に受けられた全てのコメントを取り扱い、また「試験的実装」のためのテクニカルフレームワークの更新改訂版を発表する。この改訂版は、以前のサイクルからのテクニカルフレームワークの安定した本文と新しく開発されたサプリメントの両者を含む。それは、コネクタソンのための試験的実装ソフ
トウェアを開発する際に、ベンダによって用いられるテクニカルフレームワークの改訂版である。

3.

当委員会は、テクニカルフレームワークの試験的実装改訂版に対する変更提案を、コ
ネクタソンに参加する実装者からのものを含めて、規則的に考慮する。コネクタソンの 60 日以内に受け取られた全ての変更提案の解決後に、テクニカルフレームワーク
改訂版が「最終テキスト」として発表される。

このプロセスは、以前に定義されたあらゆる統合プロファイルとそのアクタへの適合要求実装を支援するために、フレームワーク定義の後方両立性を保持する一方、拡張、明確化、および修正の必要性を取り扱うことが意図されている。
IHE テクニカルフレームワークの安定性を保持するために、二つの制御経路：新しい開発、および保守のうちの一つに従って、規則的な年間サイクル（図）に修正が生じる。

12

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

New
新開発
Development

Publish forパブリックコメン
Public Comme nt

Publish for
試験的実装
Trial Implementation

Publish
次の改訂版公刊

Publish as
最終テキスト公刊
Final Text

next version

以前の年間サイクルからの既存
Existing Technical
Framework fromテクニカルフレームワーク
previous annual cycle

Propose & Draft
提案とドラフト
New Supplement
新サプリメント

サプリメ
Supplement
PCPC
ント

Final Text
最終テキストサプリメ
Supplement
TITI
ント

Supplement

サプリメントFinal Text
最終テキストPublic Comments
パブリックコメント
considered
考察とサプリメント& Supplement updated

ChangeChange Proposal
変更提案の提示とsubmitted& 受入れ
accepted

Issues raised in
テクニカルフレームワ

変更提案
Proposal

Final Text
最終テキストpr evious version of

Change Proposal
ークの前版で提起課題
Technical Framework 変更提案の提示とsubmitted& accepted
受入れ

Change
変更提案
ProposalTechnical
テクニカルフFramework

レームワーク(next version)（次の改訂版）
Continue as required
次の年間サイクルで
in the next annual cycleの要求継続

図 1.10-1 IHE 開発プロセス
図 1.10-1 IHE 開発プロセスは、年間サイクルの間にテクニカルフレームワークを開発し保持するプロセスを示す。破線の矢印は、テキストのアセンブリ（合併）を指示する。
1.10.1 新開発－既存のテクニカルフレームワークの拡張
毎年開発される新しい機能性は、IHE 患者ケア装置計画委員会によって確認される。新しい開発のための推奨事項を提出することを望んでいる個人または組織は、PCD 計画委員会に加わり参加することが奨励される。当専門委員会は、必要な分析と設計作業を実装し、またテクニカル
フレームワークのための新しいテキストを作成する。一般に、新しい機能性は、サプリメントの形で出版される。サプリメントの目的は、次のテクニカルフレームワークへの追加の一つを作成することである：・通常、新しいアクタとトランザクションの導入を含める、新しい統合プロファイル。
・ 既存の統合プロファイルにおける新しいアクタ：これらは、テクニカルフレームワークの何処か他の所で以前に定義されたアクタか、まだ定義されていない新しいアクタの何れかである。このプロファイル中で新しいアクタの責任を特定するトランザクションが特定され定義されるが、必要または自由選択として指示されてもよい。そのプロファイルを既に実装したシステムに関する両立性問題を引き起こすことを避けるために、どんな新しい必要なトランザクションも当プロファイルにおける既存のアクタのために追加されない。
・ 既存の統合プロファイルにおける新しい選択肢：これらは、通常、プロファイルにおける既存のアクタのための自由選択のトランザクションを追加するか、または既存のトランザクシ
ョン内に自由選択の特徴を追加する。

13

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

・ 主要概念の変更：それらは、既存の統合プロファイルの性質を変えることはないが、将来はアクタ、トランザクション、またはコンテンツに対して変更か追加を意味するかもしれない。
出版プロセスは、あるフェーズで構成され、また各々の文書上で明確に指示される。
まず、テキストはパブリックコメントのために発表される（"PC"という記号で）。パブリックコ
メント期間（典型的には 30 日間）の間、テキストとコメント提出機関が IHE ウェブ上で入手可能である。この期間後に、専門委員会はコメントの見直しをすることになる。
次いで、受理されたコメントから生じる部分修正に基づいて、サプリメントの更新テキストが試
験的実装のために発表される（"TI"という記号で）。
IHE は、IHE アクタと統合プロファイルの試験的実装仕様書の実装をベンダが試験するためのプロセスを提供する。コネクタソンと呼ばれる複数対話型試験イベントに至る、IHE 試験プロ
セスは、価値あるフィードバックをベンダに提供し、また彼らの実装の適合のベースライン指示を提供する。それはまた、試験的実装仕様書の技術的アプローチの妥当性確認として役立つ。
試験的実装が新しい機能性（例えば、コネクタソンからの経験に依る）を十分に発揮したと判断され、またそのテキストが十分安定していると考えられた後に、新しいテキストが最終テキス
トとして発表されることになる（"FT"という記号で）。
最終テキストのサプリメントは、年間開発サイクル終了時に、改訂番号を更新したテクニカルフ
レームワークの新しい改訂版になるテクニカルフレームワークの最新版と合併されることにな
る。
1.10.2 既存のテクニカルフレームワークコンテンツの保守専門委員会が最大に努力したにもかかわらず、テクニカルフレームワークまたは試験的実装文書の最新改訂版は、不正確、不完全、または不明瞭であるテキストを含むかもしれない。変更提案のような事項が扱われ、また次項を扱う：
・ 訂正：実装の非相互運用性を引き起こしている技術的問題は、安定した統合プロファイルの機能性における変更を導入することなく、解決される。
・ 明確化：誤解される可能性があるか、または不明瞭であるテキストは、あらゆる技術的変更を導入することなしに、より容易に理解され明確化されるように作成される。
出版プロセスは、訂正と明確化両方に対して同じであり、また試験的実装への変更、およびテク
ニカルフレームワークの現在版への変更の両者を扱う。
提出された変更提案は、例えば、試験的実装または最終テキスト統合プロファイルに関する経験から、またはコネクタソンにおいて、ユーザ、ベンダ、または専門委員会メンバーによって取り上げられた事項から生じる。その結果の変更提案文書は、明確に次項を明言すべきである：
・変更されるように求められたテクニカルフレームワークの部分
・問題の説明・変更が必要と考えられる論理的根拠
・および、問題に対する解決策またはアプローチ

14

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

専門委員会は、受入れか不合格かの何れかである変更提案を規則的に検討する。
不合格の変更提案は、何故その変更が適切でないのかを説明する専門委員会からの論理的根拠と共に発表される。
受理された変更提案は、適切な明確化または訂正を生成するための目標を持つ更なる調査のための作業項目として、専門委員会メンバーに割り当てられる。結果のテキストは、承認される以前に、再び専門委員会によって見直されることになる。
一旦承認されると、最終テキスト変更提案は、専門委員会によって出版され、有効とみなされる。それは、年間開発サイクルの終了時に、テクニカルフレームワークの次の版の中に合併される。最終テキスト変更提案または最終テキストサプリメントへ変更提案を提出することはできない。
1.10.3 テクニカルフレームワークの使用
テクニカルフレームワークの最新版は、一次参照文書とみなされる。現在の年間サイクルからの最終のテキストサプリメントと最終テキスト変更提案は、この文書を補完する。過去の最終テキ
スト文書は、テクニカルフレームワークまたはサプリメントの試験的実装版の以前の版に、相違点についての便利な要約を提供するために保持されている。
年間の開発と保守サイクルの間に、次のような実装のためにテクニカルフレームワーク文書を使用することが推奨される：・製品実装
試験的実装テキストに基づいて実装された製品は、その後の最終テキストを見直し、またそれらの製品を必要に応じて更新することが期待される。更に、ベンダが最終テキスト変更提案を監視し、適時の様式で彼らの製品に関連するあらゆる訂正をすることが期待される。
・コネクタソン実装
コネクタソンでの試験は、試験的実装のためのあらゆる関連のサプリメントと最終テキスト
変更提案に加えて、適切な IHE 領域のためのテクニカルフレームワークの現行版に基づく。
1.10.4 製品の検証と妥当性確認の意味
IHE プロセスは、実装の相互運用性と仕様書の正確さを確実にすることに役立つように設計された追加の活動と連動している。毎年コネクタソンは、解決策提供者がその他の提供者と、典型
的には情報提供者と利用者のペアとして、IHE プロファイルの彼らの実装を試験する場所で、開催される。これらの活動は、プロファイルの実装を試験するばかりでなく、最終テキスト文書になるサプリメントの完全性と品質を試験するのに役立つ。実際、サプリメントが最終テキストになるのは、コネクタソンの間にプロファイルが厳しく吟味されてからである。

15

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

IHE 試験活動は、製品ベンダが彼らの製品をリリースするために従事しなければならない製品
検証と妥当性確認の活動へのいくつかの関係を持つ可能性がある。事実、IHE プロセスに理想的に関与することは、全体的な開発努力を減少させるという目標を持つ製品開発プロセスに利益をもたらす。
コネクタソンの間の試験活動は、解決策提供者による製品検証活動として参照されることができ、またその結果は、法規上の提案パッケージの一部として含まれることができる。しかし、彼らの内部開発方針に従って、これが適切であるのかを決定するのは、各々の組織次第である。
また、IHE プロセスがユースケースの周りに構築されているが、IHE 試験もまた製品妥当性確認の形式であると考えることもまた魅力的であるかもしれない。これは多分、IHE 試験活動の間に特定装置の意図された使用は考慮されないので適切ではない。

16

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

2 PCD 統合プロファイル
IHE 患者ケア装置統合プロファイルは、製品の統合化のための要求事項を通信する際に、ヘルスケア専門家とベンダが利用するかもしれない共通の言語を提供する。統合プロファイルは、現実世界のシナリオまたは統合システムの能力の特定のセットを記述する。統合プロファイルは、アクタの規定されたセットに適用されるが、また各アクタにとって、それらの能力を支援するために必要なトランザクションを規定する。
統合プロファイルは、IHE テクニカルフレームワークにおいて詳述された機能性の下位集合を参照するために、ユーザとベンダの両者にとって便利な方法を提供する。それらは、IHE テク
ニカルフレームワークによって定義された IHE アクタとトランザクションに関しての詳細についての難儀な言換えなしに、ユーザおよびベンダが全体的な IHE 支援を単に要求するまたは約束することよりも、より明確にできるようにする。
2.1 統合プロファイル間の依存性
統合プロファイルの実装が、別の統合プロファイル中に定義された機能性を達成するための前提条件である時に、IHE 統合プロファイルの間の依存性が存在する。表 2.1-1 患者ケア装置統合プ
ロファイル依存性は、必要とされる依存性を定義する。いくつかの依存性は、一つのプロファイ
ルを支援するアクタが、その他の統合プロファイルを支援する一つ以上のアクタによって、分類されることを要求する。
もちろん、プロファイルの異なった組合せが実装される時に発生するような、その他の有用な相互作用が存在するが、しかしそれらは以下の表には記述されていない。例えば、種々の PCD プ
ロファイルのアクタは、ユーザまたはノードの認証、監査証跡、患者 ID の相互参照、等のための IT インフラストラクチャー領域のプロファイルを実装するかもしれない。
表 2.1-1
統合プロファイル

患者ケア装置統合プロファイル依存性

以下に依存

依存性タイプ

目的

装置施設情報通信
（DEC）

時刻同期

DEC を実装する各アクタ
は、時刻クライアントアク
タで分類されなければならない

PCD データの時刻
同期スタンピングに必要。

臨床現場輸液検証
（PIV）

時刻同期

PIV を実装する各アクタは、
時刻クライアントアクタで分類されなければならない

メッセージとデー
タの時刻同期スタ
ンピングに必要

N/A

N/A

埋込み型装置－心臓病－検査（IDCO）

なし

17

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

ベンダ製品は、セクション 4 における統合プロファイル中に説明されているように、適切なア
クタ－トランザクションを実装することによって、統合プロファイルを支援する。製品は、二つ以上のアクタと二つ以上の統合プロファイルを実装してもよい。
依存するプロファイルを支援するために、アクタは依存するプロファイルにおけるトランザクシ
ョンに加えて、予め必要なプロファイルにおける全ての必要なトランザクションを実装しなければならない。ある場合には、その前提条件は、与えられた一群のプロファイルの何れか一つをアクタが選ぶことである。
アクタ（セクション 3.1 参照）は、施設における運用可能な活動に関連した情報を生成し、管理し、それに基づいて行動するような情報システムまたは情報システムの構成要素である。
トランザクション（セクション 3.2 参照）は、規格に基づくメッセージを通じて、必要とされる情報を転送するアクタ間の相互作用である。
2.2 統合プロファイルの概観
PCD-TF-1 では、各々の統合プロファイルは、次項によって定義されてもよい：
・関与された IHE アクタ
・各々の IHE アクタに必要な IHE トランザクションの特定のセット
これらの要求事項は、統合プロファイルを支援する各々のアクタに必要なトランザクションの表の形式で提示される。
多重の統合プロファイルを支援するアクタは、支援された各々の統合プロファイルの必要な全てのトランザクションを支援することが要求される。統合プロファイルが別の統合プロファイルに依存する場合、依存する統合プロファイルに必要な全てのトランザクションは、その表に含まれてきた。
IHE 統合プロファイルは、規格への適合の宣言書ではないこと、また IHE は、認証機関ではないことに注意する。ユーザは、IEEE、DICOM、および HL7 のような関連の規格への適合の宣言書をベンダが提供することを要求し続けるべきである。規格の適合は、IHE 統合プロファイ
ルを採用するベンダのための前提条件である。
また、IHE が取り扱うことができない、あらゆる成功した統合プロジェクトのための重大な必要性があることに注意する。成功裡に統合するシステムは、混乱を最小化するプロジェクト計画
をなおも必要とするし、またフェールセーフ戦略、特定のかつ相互に理解されるパフォーマンス
の期待、明確なユーザインタフェースの要求事項、明らかに識別されるシステム限界、詳細なコスト目的、保守と支援のための計画、等を記述する。
患者ケア装置(PCD)のための要求事項の最近の HIMSS サーベイにおいて、回答者達は、彼らの最高優先事項として、PCD データの施設共有を確認した。目標は、決定時間の短縮、生産性の増加、複写エラーの最小化、およびデータに関する増加した組織情報の獲得を含む。
PCD データは、次項を含む：
・周期的生理データ（心拍数、侵襲性血圧、呼吸数、等）・非周期的生理データ（非侵襲性血圧、患者体重、心臓出力、等）
・警報や警告情報18

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

・装置環境とそれらの環境を操作する能力
・CLIA 放棄（または国際的権利放棄相当）臨床現場の実験室テスト（即ち、家庭での血液ブドウ糖、等）
PCD データはまた、患者 ID、ケア提供者識別、および装置の物理的位置のような組織的データを含んでもよい。
2.2.1 装置施設情報通信（DEC）
装置施設情報通信（DEC）プロファイルは、施設への一貫した PCD データ通信の必要性を取り扱う。PCD データの施設受取りは、臨床決定サポートアプリケーション、
臨床データ保存（CDR）、
電子式医療記録アプリケーション（EMR）、および電子式健康記録（EHR）を含むが、しかしそれらに限られてはいない。
現在のプロファイルは、PCD データの施設間通信に関連したプライバシー、セキュリティ、および機密保持の問題は取り扱っていない。DEC プロファイルは、安全なネットワーク上の単一施設において実装されていると仮定されている。これらの側面は、その後数年、IHE PCD ロー
ドマップ上にある。
現在のプロファイルは、患者ケア装置の開いたループ制御か閉じたループ制御かの何れかに関連したユースケースとトランザクションは取り扱っていない。警報や警戒警報のような実時間デー
タ、波形（ECG、EEG、等）は現在取り扱っていない。
2.2.1.1

患者識別に関する注記

特に PCD データが施設へ輸出される時、患者識別は多分、あらゆる相互運用性と通信プロセスの最も不可欠なインフラストラクチャーコンポーネントである。それは、医療装置、通信、データ分析、報告、および記録保持における基幹要素である。患者ケア装置への患者識別入力の自動化は、スループットの改善、エラーの減少、安全性の向上、装置と薬の有効性、および効率の向上の可能性を持っている。患者識別信用証明書の取得のために、IHE 対応のトランザクションを使用する実装が強く推奨される。これらのトランザクションは、次項を含む：ITI-21、ITI-30、および ITI-31。バーコードまたは RFID のようなその他の機構は、また完全に有効な代替か補完である。
2.2.2 臨床現場輸液検証（PIV (Point-of-Care Infusion Verification)）
提案された統合化の目標は、電子式薬物治療管理プロセスの中に輸液システムを取り入れることである。次のような一次手順が、このプロセスを構成する：
・薬物治療オーダ・eMAR における介在物の検証オーダ
・薬物治療の準備と施行
・薬物治療の管理

19

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

薬物治療のエラーは、このプロセス中の各点で発生し得るが、この提案は、“薬物治療を管理する”ステップと関係があり、ここで臨床医によってなされるエラーの半分は、輸液に伴って生じる。これらのエラーは、通常、薬物治療管理の次の五つの「正しさ(Right)」の一つの違反に関与する：
・正しい患者・正しい薬・正しい線量・正しいルート
・正しい時間
各々の医薬を管理することまたは各々の輸液をスタートさせることに先立って、これらの正しさの見直しを確実にすることがケア提供者の責任である。
ポンプの手動プログラミングがまだ管理エラーの結果をもたらすかもしれないという理由で、このプロファイルは、自動化されたポンプのプログラミングを支援ために開発されたが、それによって、五つの「正しさ」を検証するために BCMA システムを使用する臨床医と、ポンプの実際のプログラミングとの間のループを閉じることになる。
臨床現場輸液検証プロファイルは、臨床コンピュータ支援薬物治療管理（BCMA (Bedside
Computer assisted Medication Administration)）システムから輸液ポンプへの輸液パラメータの電子式移送を支援する。この能力は、キー入力エラーを除去することによって、また「スマートポンプ」システムに積載された医薬ライブラリによって促進される自動投薬量点検の使用を増加することによって、エラーを低減することになる。薬物治療管理エラーの低減に加えて、この統合化は、またケア提供者の生産性を増加させ、また輸液データに関する一層組織的な情報を提供することになるかもしれない。
輸液ポンプから臨床情報システムへの輸液ステイタス情報の電子式移送は、IHE-PCD 装置施設
情報通信プロファイルの PCD-01（PCD データ通信）または PCD-02（PCD データ承認）トラ
ンザクションを用いて達成され得る。
このプロファイルで扱われたユースケースは、次のステップを含む（BCMA アプリケーション
によって支援されるワークフローは、必ずしも規定のオーダで発生しないかもしれないことに注意すること）:
・臨床医は、IV を管理するために BCMA を使用する・臨床医は、自己、薬物治療、患者、ポンプの特定をする・臨床医は、BCMA を用いて IV 薬物治療オーダのための輸液パラメータを確認するまたは編集する
・輸液パラメータは、ポンプへ送信される・臨床医は、直接ポンプ上の環境を確認し、また輸液を開始する
2.2.3 埋込み型装置－心臓病－検査（IDCO）
埋込み型装置－心臓病－検査統合プロファイルは、分離性データ要素の翻訳、通信、および処理のための機構を定義し、また心臓装置質疑（検査）に関連した付属品を報告する。それは、臨床審査官から医療記録システムへのメッセージを標準化することによって、診療室内と遠隔の埋込み型心臓装置の経過観察のためのユースケースを支援する。

20

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

2.2.4 ロゼッタ用語マッピング（RTM）
ロゼッタ用語マッピング（RTM）プロファイルの一次目的は、IHE PCD プロファイルに対応したシステムによって、既存の ISO/IEEE 11073-10101 学術用語の使用を調和させることである。
RTM プロファイルは、また、装置とシステム間の安全かつ相互運用可能な通信を促進するために、各数値パラメータのために許可された測定単位と列挙値を規定する。
ロゼッタ表はまた、現在 ISO/IEEE 11073-10101 専門語には存在していない、新しい専門用語を定義するために使用できる一時的な保存庫として役立つように設計されている。今までの我々の経験に基づくと、主として換気装置と換気装置環境の区域において、100 個をはるかに上回る
新しい用語が必要とされることになる。RTM はまた、IEEE 11073「個人健康装置」（PHD）構想を支援するための新しい用語を捉えるためのフレームワークとして役立つことになる。

21

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

3

アクタおよびトランザクションの概観

3.1 アクタの記述
アクタは、施設における運用可能な活動に関連した情報を生成し、管理し、それに基づいて行動する情報システムまたは情報システムの構成要素である。次項は、IHE によって定義されるアクタであり、またその他の領域のテクニカルフレームワーク文書と同様に、この文書の残りの全てにわたって参照される。
新しいアクタ
装置検査報告者－装置検査報告者（DOR (Device Observation Reporter)）アクタは、特許のフォーマットに基づくデータを含めて、PCD からのデータを受信し、また一貫した構文と意
味を提供するトランザクションへ受信されたデータをマッピングする。
装置検査利用者－装置検査報告者、装置検査フィルタ、または両者からの PCD データを受信することに責任があるアクタ。
輸液オーダプログラマ－輸液オーダプログラマ（IOP (Infusion Order Programmer)）アクタ
は、オーダを構成する情報を輸液オーダ利用者（IOC (Infusion Order Consumer)）へ送信する。IOP がオーダ情報を得る機構は、このプロファイルの範囲外である。
輸液オーダ利用者－輸液オーダ利用者（IOC (Infusion Order Consumer)）アクタは、IOP ア
クタからのオーダ情報を受信し、代わりにポンプをプログラムする。IOC が、受信された情報を持つポンプをプログラムする機構は、このプロファイルの範囲外である。
埋込み型装置心臓報告者－このアクタは、埋込み型心臓装置と通信するシステムからのデー
タを報告する。
埋込み型装置心臓利用者－このアクタは、埋込み型装置心臓報告者からのデータを受信する。
既存のアクタなし
次の表は、統合プロファイル中にどのアクタが用いられているのかを示す。
表 3.1-1

統合プロファイルアクタ

統合プロファイル

DEC

PIV

アクタ
装置検査報告者

X

装置検査利用者

X

輸液オーダ利用者

X

22

IDCO

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

統合プロファイル

DEC

PIV

IDCO

アクタ
輸液オーダプログラマX

埋込み型装置－心臓病－報告者

X

埋込み型装置－心臓病－利用者

X

3.2 トランザクションの記述
トランザクションは、規格ベースのメッセージを通じて必要な情報を転送するアクタの間の相互作用である。次項は、IHE によって定義されたトランザクションであり、この文書の残りの全てにわたって参照される。その他の領域テクニカルフレームワーク文書に規定されるこれらのト
ランザクションは、領域 ID とトランザクション番号で識別される。
PCD データ通信－装置検査報告者から施設クライアントへ PCD データを送信し、また装置検査利用者によって PCD データを受信する。
輸液オーダ通信－このトランザクションは、ケア提供者、患者、並びにプログラムされた輸液のためのポンプ識別、投薬、容量、および速度などの輸液オーダプログラマからの情報を含む。
IDC 検査通信－このトランザクションは、検査、測定、または IDCO 報告者からの報告書を含む。
次の表は、どの統合プロファイルにおいて、どのトランザクションが用いられるかを示す。
表 3.2-1

統合プロファイルのトランザクション
統合プロファイル

DEC

PIV

IDCO

トランザクション
PCD データ通信 [PCD-01][PCD-01]

X

輸液オーダ通信[PCD-03]

X

IDC 検査通信[PCD-09]

X

3.3 製品の実装
注：開発者は、製品実装における IHE アクタとトランザクションを実装する際の多くのオプシ
ョンを持っている。その決定は、次の四つのレベルのオプションをカバーする：
・

一つのシステムに関して、それがどのアクタを組み入れることになるのかを選択する。
（シ
ステムあたりの多重のアクタが許容可能である）。

・

各アクタに関して、それがどの統合プロファイルに参加することになるのかを選択する。

・ 各アクタ－プロファイルに関して、どの自由選択のトランザクションが実装されることにな
るのかを選択する。全ての必要なトランザクションは、支援されるプロファイルのために実装されなければならない。
（統合プロファイルセクションにおける統合プロファイル表を参照[KJF1]）。

23

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

・

最後に、各トランザクションに関して、どの自由選択の特徴が支援されることになるのかを選択する。
（適切な領域 TF におけるトランザクション記述を参照）。

実装者は、どの IHE アクタ、IHE 統合プロファイル、自由選択のトランザクション、および自由選択の特徴が、与えられた製品中に組み入れられるのかを記述する宣言書を提供すべきである。
そのような宣言書の推薦形式は、IHE PCD-TF2 附属書 H に定義されている。
一般に、製品実装は、あらゆる単一のアクタまたはアクタの組合せを組み入れてもよい。しかし、以下に規定される場合には、一つのアクタの実装は、一つ以上の追加アクタの実装を必要とする：
・｛この時点ではなし｝
多重のアクタが、単一の製品実装の中で分類される時、支援されるアクタの各々と共に始まるまたは終了する全てのトランザクションは、支援されなければならない（即ち、IHE トランザク
ションは、外部製品インターフェース上に提供されなければならない）。この規則に対する例外
は、上に定義された必要な分類化において、アクタ間に定義されるあらゆるトランザクションである。

24

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

4 装置施設情報通信（DEC (Device Enterprise Communication)）
装置施設情報通信統合プロファイルは、一貫した意味論を用いて、施設アプリケーションへのマ
ルチモダリティ患者ケア装置データの独立ベンダ通信をサポートする。それは、施設への通信のために、特許に関する構文論と意味論からの PCD データを単一の構文と意味表現でマッピング
することによって、これを達成する。PCD データは、一貫した施設時間で刻印された時間である。オプションは、アプリケーションに所定の特定 PCD データをろ過させるために提供されている。
4.1 アクタ／トランザクション
次の図は、このプロファイル、およびアクタ間のトランザクションに関与するアクタを図示する。

データ検査
Data Obs ervation
利用者(DOC)Cus tomer (DOC)

PCD-0 1 : Commun
ic ateーPCD-01:装置デ
Dev ic e Dat aタ通信

D evice
装置検査
Obs
erv ation
報告者(DOR)

Reporter (DOR)

Dev
ice
装置

図 4.1-1

アクタとトランザクションを持つ DEC 統合プロファイル

表 4.1-1 DEC－アクタとトランザクションは、DEC 統合プロファイルに直接関与した各アクタのためのトランザクションを記載する。この統合プロファイルの支援を要求するために、必要なトランザクション（"R"と標識）を実装しなければならない。"O"と標識されたトランザクショ
ンは、自由選択である。実装が支援を選択するかもしれない、この統合プロファイルによって定義されたオプションの完全なリストは、セクション 4.2 に記載されている。

25

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

表 4.1-1アクタ

DEC－アクタとトランザクション

トランザクション

自由選択

ボリューム 2 におけるセクション

装置検査利用者

PCD データ通信[PCD-01]

Rセクション 3.1

装置検査報告者

PCD データ通信[PCD-01]

Rセクション 3.1

このプロファイルのためのあらかじめ必要であるかもしれないその他のプロファイルに関しては、表 2.1-1 患者ケア装置統合プロファイル依存性を参照すること。
4.1.1 患者情報－推奨トランザクション
要求されていないが、IHE トランザクションは、その他のシステムからの患者情報の取得のために採用されることが推奨される。推奨されたトランザクションは、次項を含む：
患者情報問い合わせ(PDQ)－このトランザクションは、特定の患者についての特定の問い合わせに応じた患者動態情報を含む。[ITI-21]
個人情報管理－このトランザクションは、患者動態情報の変更が生じた場合、患者情報供給者(PDS)から広められる。[ITI-30]
患者情報管理－患者情報生成源は、患者情報（入院、外来、入院予約等）を登録または更新し、患者情報利用者アクタを実装する他のシステムへ情報を転送する。この情報は、特定の（通常は現在の）患者情報のための患者位置とケア提供者を含む。[ITI-31]
4.2 統合プロファイルオプション
多数のアクタは、領域または実装を横断して使用される変動に対処するために定義されたオプシ
ョンを持つ。この統合プロファイルのために選ばれるかもしれないオプションは、表 4.2-1 DEC－アクタ、および適用されるアクタに同伴するオプションの中に記載されている。これらのオプ
ションの下位集合は、このプロファイル中のアクタによる実装に必要である（それらは、その他のプロファイルにおいて真に自由選択であるかもしれないけれども）。
表 4.2-1アクタ

DEC－アクタとオプション
オプション名ボリューム 2 におけるセクション

装置検査報告者なし(MLLP 輸送を仮定）

付録 I

装置検査利用者なし(MLLP 輸送を仮定）

付録 I

26

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

4.3 プロセスフロー図
このセクションは、特定のユースケースと DEC ワークフロープロファイルのために定義された相互作用を記述する。自由選択のユースケースと同様に標準的なユースケースの両者が存在する。
4.3.1 標準的なユースケース
4.3.1.1

ケース DEC-1：患者の身元確認された DEC データを EMR／EHR へ通信

特定の患者に関連した患者ケア装置の全てからのデータは、ゲートウェイ、装置、または臨床情報システム(CIS)によって通信され、EMR/BHR へ DOR アクタを実装し、DOC アクタを実装する。諸例は、臨床モニタ、換気装置、および輸液ポンプからのデータを含む。周期的と非周期的の両データを表わす分離性パラメータは、典型的には 1 分あたり 1 回以上の間隔で通信される。
そのデータはそれぞれの患者ケア装置からのデータを横断して、時刻同期によって刻印される時間である。
主要な意図は、構造データの通信であるが、組織化されていないデータの封入のための規定が作成されている。そのアプリケーションは、患者記録における PCD データの封入のために必要とされた正式な施設患者 ID を束ねる設備類を提供する。PCD データへ正式な施設患者 ID を関連付けるためのワークフローは、現在の PCD TF の範囲外にある。
4.3.1.2

ケース DEC-2：有効な周期的 DEC データを EMR／EHR へ通信

このユースケースは、PCD データにおけるケア提供者の身元確認をすることによって、ケア提供者が有効にしたデータのみを通信することによってケース C1 上で構築する。妥当性確認を実装するワークフローは、現在の PCD TF の範囲外である。

27

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

DOC
OC

DOR

PCD データ通信
PCD-01: Communicate
PCD Data

図 4.3.1.2-1

DEC プロセスフロー（フィルタリングなし）

4.3.2 自動患者情報取得のためのオプショナルユースケース
次の例は、典型的なシステムがどのアクタをサポートすることが期待されるかを記述する。これは要求事項を定義することを意図したものではなくて、むしろ図示による例を提供するためである。
・装置検査報告者と患者動態情報を結合するゲートウェイを報告する一般目的検査。
・装置検査報告者と患者動態情報を束ねる患者ケア装置
患者の身元確認をする際に使用され得る患者動態情報データは、次項を含む：
・一部のまたは完全な患者名（患者記録かリストバンド上に印刷された名前または患者から得た名前）
・患者 ID（印刷されたバーコード、臨床チャート、RFID、スキャン、等から）・生年月日／年齢範囲
注：臨床 ID は、個人情報検証の手段として、合同委員会によって受け入れられてはいない。

28

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

患者識別結合ユースケース：ケア提供者は、患者ケア装置へ患者を接続する。患者は、リストバ
ンド上に含まれた情報の検証など、識別のためのいくつかの施設固有のプロトコルを用いて、ケ
ア提供者によって物理的に識別される。ケア提供者は、その装置または独立の装置若しくはシス
テムによって作られた、電子式識別を認可するために、物理的な患者識別からの情報を使用し、患者ケア装置から通信される全てのデータへ患者電子式 ID を結合する。その検証は、結合される装置、ゲートウェイ、または別々のシステムに存在しているアクタへのデータの直接入力に関与するかもしれない。それは、ケア提供者による患者の直接的な物理的識別、またはその他の装置かシステムと協力して、その装置によってなされた電子式識別のケア提供者による確認、に基づいているかもしれない。検証はまた、ユニークな論理的な認証が作成される時には、十分に自動化された結合を含んでいるかもしれない。最終結果は、患者ケア装置から通信されるデータが正式な施設的固有の電子患者 ID を含むことである。
4.3.2.1 ケース DEC-ID-1：ADT に知られている患者 ID、局所的に利用可能
注：以下は、患者動態情報の自動取得を支援するユースケースである。それらは、あらゆる特定の PCD プロファイルまたはトランザクション中へのマッピングはしない。
患者は、心臓監視システムの臨床モニタへ接続される（例えば、多くの臨床モニタを含む PAM
放送を経由した、連続的な ADT 供給を持つ中央ステーション）。患者は、プラスの ID 情報を提供できるかもしれないし、または提供できないかもしれない。患者の身元確認をするために用いられる動態情報は、次を含んでいる：一部のまたは完全な患者名（患者記録に印刷された名前または患者が述べた名前）；患者 MRN（これは、印刷されたバーコード、臨床チャート等から得られるかもしれない）；一部の ID エントリまたはスキャン；生年月日／年齢範囲。
（注：臨床 IDは、合同委員会規格と一致した ID として許されていない。）。ケア提供者は、ケア提供者による
プロンプトに応じて、システムコンソール上のピックリストから患者を選択する。システム情報
は、医療記録番号(MRN)、氏名、年齢、性、室／ベッドおよび入院年月日の表示を含む。中央
ステーションは、患者個人情報を装置データと結合する。
4.3.2.2 ケース DEC-ID-2: ADT に知られている患者 ID、局所的に利用不可
ADT 遅れまたはその他の状況によって、上述の患者が心臓監視システムに登記されていない場
合には、ケア提供者は、患者のピックリストを受信し、患者 ID をシステム中へ入力するために、患者登録の PDQ 問い合わせを実施できる。
4.3.2.3

ケース DEC-ID-3: ADT に知られていない患者 ID、局所的に利用可能

これは、そのシステムが代理人識別を設定していたジョン／ジェーン・ドゥ患者である。代理人
識別は、制度上の方針に従って ITI-PAM 経由によって真の患者 ID と後に連結される、何れかの方法によって決定される。
4.3.2.4

ケース DEC-ID-4：ADT に知られていない患者 ID、局所的に利用不可

システムに登記されていないが ER に存在する患者で、ケアの継続が必要とされ、識別が続いている患者のケースである。患者動態情報が未知である場合、時間と装置 MAC アドレスは、自動的に送信されることができ、そのデータ固有の識別を提供する。この最後のアプローチは、また、他の結合機構への補体として、監査証跡を作成するためにも使用できる。

29

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

4.3.2.5

その他の臨床例

DEC-ID-A：患者は輸液装置へ接続される。輸液装置は、ネットワークへ接続されるが、輸液または医薬投与管理アプリケーションによっては管理されない。ケア提供者は、患者と装置のバー
コードを走査する。ケア提供者は、正式なデータベースから ADT と装置 ID から患者 ID の表示を提供される。ケア提供者は確認する。
DEC-ID-B：患者は輸液装置へ接続される。輸液装置は、ネットワークへ接続されるが、輸液または医薬投与管理アプリケーションによっては管理されない。ID 確認するための ADT 供給は、利用できない。ケア提供者は、患者との対話によって、患者のリストバンド ID を確認する。患者 ID リストバンドが走査され（バーコード、RFID、等）、PCD に結合される。
DEC-ID-C：患者は換気装置へ接続される。換気装置は、ネットワークへ接続されるが、システ
ムによって管理されない。換気装置と患者は、RFID 標識を持っている。標識が近ければ、正式なデータベースからの患者の ADT 識別と装置の ID が結合していることを意味する。身元確認された患者のために、既存の換気装置オーダの検証が必要とされる。検証されるならば、患者
ID が PCD に結合される。

30

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

5 臨床現場の輸液検証（PIV (Point-of-Care Infusion Verification)）
臨床現場輸液検証プロファイルは、臨床コンピュータ支援薬物治療管理（BCMA）システムから汎用の輸液ポンプへの輸液パラメータの電子転送をサポートする。この能力は、キー入力エラ
ーを除去することによって、また「スマートポンプ」システムに積載された医薬ライブラリによって促進された、自動投薬量点検の使用を増加することによって、エラーを低減する。薬物治療
管理エラーの低減に加えて、この統合はまた、ケア提供者の生産性を増加させ、かつ輸液データに関しての一層組織的な情報を提供するかもしれない。
ポンプから臨床情報システムへの輸液状況情報の電子転送は、多分 IHE-PCD 装置施設情報通信
プロファイルの PCD-02（PCD データに同意）トランザクションによって、PCD-01（PCD データ通信）を用いて達成できる。
その提案された統合の目標は、電子薬物治療配信プロセス中に輸液システムを持ち込むことである。
5.1 アクタ／トランザクション
図 5.1-1 は、臨床現場輸液検証統合プロファイルに関与するアクタおよびそのアクタ間の関連のトランザクションを示す。

31

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

BCMA

輸液オーダ
プログラマ
(IOP)

PCD-03
輸液オーダの通信
輸液オーダ
利用者
(IOC)

輸液装置

図 5.1-1

臨床現場輸液検証アクタ図

表 5.1-1 は、臨床現場輸液検証プロファイルに直接関与する各アクタのためのトランザクションを記載している。この統合プロファイルの支援するために、必要なトランザクション（R と標識）が実装されなければならない。0 と標識されたトランザクションは、自由選択のアクタに関与する。この統合プロファイルによって定義されるオプションの完全なリストおよび実装がサポートすることを選択するかもしれないことはボリューム I、セクション 3.3 に記載されている。
表 5.1-1

臨床現場輸液検証統合プロファイル－アクタ及びトランザクション

アクタ

トランザクション

選択性

ボリューム 2 のセクション

輸液オーダプログラマ

輸液オーダ通信[PCD-03]

R

3.3

輸液オーダ利用者

輸液オーダ通信[PCD-03]

R

3.3

32

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

5.2 統合プロファイルオプション
この統合プロファイルのために選択されるオプションは、それらが適用されるアクタと共に、表5.2-1 に掲載されている。適用可能な場合のオプションの間の依存性は、注に規定する。
表 5.2-1

エビデンス文書－アクタとオプション

アクタ

オプション

ボリューム
2 のセクション

輸液オーダプログラマ

定義されたオプションはない--

輸液オーダ利用者定義されたオプションはない--

5.3 統合プロファイルプロセスフロー
図 5.3-1 は、このプロファイルのためのシーケンス図を示す。そのユースケースは、上のセクシ
ョン 2.2.2 に記述されている。

IOC

IOP

PCD-03: 輸液オーダ通信
Communicate
Infusion Order

図 5.3-1

臨床現場輸液検証プロファイルにおける基本的プロセスフロー

33

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

5.4 統合プロファイルの安全性およびセキュリティ考察
このプロファイルは、輸液オーダートランザクション通信を開始する前に、正確な薬物治療と輸液パラメータと同様に臨床医と患者を検証するための BCMA システムに依存する。
プロファイルは、輸液ポンプの輸液環境を提供するけれども、輸液は自動的には開始しない。臨床医は常に全ての環境を検証し、またポンプ上で直接に輸液を開始しなければならない。

34

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

6 埋込み型装置－心臓病－検査（IDCO）
心臓医は、多くのベンダからの埋込み型心臓装置を持つ患者達に従う。これらの装置は埋込み型
ペースメーカー、心臓血管細動除去器、心臓再同調治療装置、および心臓モニタ装置などに分類される。患者経過観察の一部として、埋め込まれた心臓装置の問合せが実装されている（診療室内か患者住居から遠隔的かの何れか）。これらの問合せ（応答型または非応答型）は、ベンダ独
自の機器によって実装される。埋込み装置（属性、環境、および状況）、患者（動態情報と検査）と治療（デリバリと結果）に関する情報が集められる。
ワークフロー効率を改善するために、心臓病学と電気生理学の実行は、EHR または装置診療管理システムのような中央システムにおける「キー」情報の管理を必要とする。
この要求に対応するために、埋込み型装置－心臓病－検査(IDCO)プロファイルは、問合せシス
テムから情報管理システムへの要約した装置問合せ情報の翻訳と転送に基づいた規格を定義する。
IDCO プロファイルは、心臓装置問合せ（検査）に関連した、離散したデータ要素と報告添付資料の翻訳、転送、処理、および保存のための機構を規定する。
6.1 アクタ／トランザクション
図 6.1-1 は、IDCO 統合プロファイル中に直接関与するアクタとそれらの間の関連トランザクシ
ョンを示す。その他の関連プロファイルにおけるそれらの参画によって間接的に関与するかもしれないような他のアクタは必ずしも示されていない。

Implantable
Device –埋込み型装置－Cardi ac - Reporter CommunicateIDC Observati ons
IDC
検査の通信
[PCD-09]

Impl an table Device –埋込み型装置－Car diac - Con sume r

心臓病－利用者

心臓病－報告者

図 6.1-1

IDCO アクタ図

どのように個人情報が管理されているかの詳細については、セクション 6.5 の患者識別を参照する。
表 6.1-1 は、IDCO プロファイルに直接関与する各アクタのためのトランザクションを記載する。
この統合プロファイルを支援するために、必要とされるトランザクション（R と標識）を実装しなければならない。O と標識されたトランザクションは自由選択である。この統合プロファイ
ルによって定義されるオプションの完全なリスト、および実装がサポートすることを選択するかもしれないことはボリューム I、 セクション 6.2 に記載されている。

35

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

表 6.1-1

IDCO 統合プロファイル－アクタおよびトランザクション

アクタ
埋込み型装置－心臓病－利用者
埋込み型装置－心臓病－利用者

トランザクション

選択性

ボリューム 2のセクション

IDC 検査通信 [PCD-09]

R

3.9

IDC 検査通信 [PCD-09]

R

3.9

6.2 IDCO 統合プロファイルオプション
この統合プロファイルのために選ばれるオプションは、それらが適用されるアクタと共に表
6.2-1 に記載されている。適用可能な場合のオプション間の依存性は、注に規定されている。
表 6.2-1

IDCO－アクタおよびオプション
オプション

アクタ

ボリューム 2のセクション

埋込み 型装置－心 臓病－報告者

PV1－患者訪問

3.9.4.1.2.3

OBX－要約 PDF または参考ポインタ

3.9.4.1.2.7

埋込み型装置－心臓病－利用者

PV1－患者訪問

3.9.4.1.2.3

OBX－要約 PDF または参考ポインタ

3.9.4.1.2.7

患者訪問オプション－これは求められていない検査であり、また埋込み型装置－心臓病－報告者
は、関連のオーダに気付いている状況ではないという理由で、このセグメントは自由選択である。
埋込み型装置－心臓病－報告者は、このセグメントを用いた来院として、問合せを追跡することを望むかもしれない。
要約 PDF または参考ポインタオプション－検査または追加分析は、表示可能な情報を含む要約
PDF 中に、または外部レポートへの参照ポインタとして、提供されていてもよい。
6.3 IDCO ユースケース
6.3.1 ユースケース IDCO-1：埋込み型心臓装置の臨床中経過観察
臨床状況：

36

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

アレックス・エブリマンは、予約のために、埋込み型心臓装置経過観察診療所に来院する。アレックスは、治療プロトコルに依存して、埋込み後 7-10 日間、それ以降は 3-6 ｹ月ごとに経過観察のために来院する。
心臓医のトム・エレクトロード先生および登録看護師（R.N.）のニッチ・ナイチンゲールは、埋込み型心臓装置経過観察診療所で働いている。
ニッチは心臓装置プログラマを用いて、その装置について質問する。プログラマは、装置から装置データ（例えば、環境、状況、イベント）を抽出する。ニッチは、装置データの見直しと検証をし、またプログラマから通訳システムへのデータの転送を開始する。要約を表すデータの必要な下位集合は、所有者のデータフォーマットから規約 HL7 のフォーマットへ、通訳システムによって変換される。次いで、そのデータは、HL7 メッセージを用いて、EHR または装置診療管理システムへ送信される。
この要約データは、求められていない検査メッセージとして送られる。
注：・

電気生理学の分野において、「プログラマ」は、埋込み装置との通信ができる専門化されたコンピュータを記述するための一般使用の用語である。プログラマは、埋込み装置（「尋問者」であるとして）に問い合わせる、および「をプログラムする」または心臓装置環境に対して変化させるために用いられる。

・

このユースケースにおいて、通訳システムは、プログラマからの所有者の構造データを受信すること、およびまた効果的に EMR との通信をするために必要な変換と通信プロトコ
ルを実装することができる臨床情報コンピュータシステムである。

・

心電図は、現在、HL7 規格には扱われてはいない。それらは HL7 メッセージへの PDF
添付資料として送信されることができる。

IHE 状況：ユースケースにおいて、通訳システムは、埋込み型装置－心臓病－報告者アクタと同じであり、EHR または装置診療管理システムは、埋込み型装置－心臓病－利用者アクタと同じである。
HL7
フォーマットの心臓装置メッセージは、[PCD-09]トランザクションである。
6.3.2 ユースケース IDCO2：情報を解読するネットワークプログラマによる埋込み型心臓装置の臨床中経過観察
臨床状況：
次のような変更を持つ上記の診療室内のユースケースと同じ。プログラマは EHR または装置診
療管理システムと直接通信し、通訳システムとしての役割を果たす。
IHE 状況：次のような変更を持つ上記の診療室内のユースケースと同じ。プログラマは、その役割にアクタ、埋込み型装置－心臓病－報告者を仮定する。

37

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

6.3.3 ユースケース IDCO-3：埋込み型心臓装置の遠隔経過観察
臨床の状況：
以前のユースケースの部分はまた、遠隔的に経過観察される装置を持つアレックス・エブリマンにも適用される。アレックスは、診療所外（例えばアレックスの住居）に配備された問合せ装置
へ出向き、彼の埋込み装置の状態を捉え、その情報を通訳システムへ転送する。その通訳システ
ムはそのデータを HL7 メッセージに変換し、その要約データを診療所の EHR へ送信する。
IHE 状況：上記の診療室内ユースケース 6.3.1 と同様である。埋込み型装置－心臓病－報告者アクタは、データが信用できないネットワークで送られる場合、遠隔経過観察のための通信を確保するために、
ATNA プロファイルの安全保障ノードアクタと共にグループ化されることが推奨される。
6.3.4 ユースケース IDCO-4：埋込み型心臓装置の遠隔監視
臨床の状況：
ユースケース IDCO-3 に記述された通訳システムは、サービス、例えば、装置製造業者または監視サービスとして実行されるかもしれない。このシステムは、トレンドおよび問題を早期に検出するために周期的ベースに提供されるデータを集めるかもしれないし、その他のイベント情報を提供するかもしれない。このシステムはデータ集積と分析、トレンド分析、統計的な報告書類、および EMR に送る前のデータの見直しと検証をする能力のような各種の付加価値のあるサービスを提供するかもしれない。通訳システムにおけるユーザ選択可能な環境によっては、患者の現状についての詳細情報と報告書類は、受取りシステムへ送信されるかもしれない。
IHE 状況：
上記の遠隔経過観察ユースケースと同様である。追加データの集積と翻訳は、PDF 添付資料として HL7 メッセージへ送信されることができる。
この種の付加価値のあるサービスは、その結果をインターネット上で送信することになる組織によって提要されがちになる。埋込み型装置－心臓病－報告者アクタは、データが信用できないネットワーク上で送られる場合、遠隔経過観察のための通信を確保するために、ATNA プロファ
イルの安全ノードアクタと共にグループ化されることが推奨される。
6.4 IDCO プロセスフロー

38

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

Device装置

Interrogator
尋問者

問合せ送信(1)
SendInterrogation (1)Implantable
Device
埋込み型装置– Cardiac –－心臓病－
Reporter
報告者

Implantable
Device
埋込み型装置– Cardiac –
－心臓病－
利用者
Consumer

問合せ送信(2)
SendInterrogation (2)Validate and
妥当性確認と見直し(3)
Review (3)Translate
情報翻訳(4)
Information (4)Communicate IDC
IDC
検査通信
Observations[PCD-09] (5)Receive
検査受信(6)(6)
Observation

Process
検査処理(7)
Observation (7)図 6.4-1

IDCO プロファイルにおける基本的なプロセスフロー

図 6.4-1 に関するプロセスフローのステップ
注：装置、尋問者、およびステップ 1～4、6 および 7 は参考であり、IDCO プロファイルの正式のアクタまたはトランザクションではない。
1. 問合せ送信－装置は、製造業者独自の方法で、情報を尋問者へ送信する。

39

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

2. 問合せ送信－尋問者は、製造業者独自の方法で埋込み型装置－心臓病－報告者へ情報を送信する。
3. 妥当性確認と見直し－埋込み型装置－心臓病－報告者は、情報の妥当性を確認する。これは、情報の見直しと承認をする臨床医を含む。
4. 情報翻訳－埋込み型装置－心臓病－報告者は、情報を適切な HL7 フォーマットに翻訳／マッピング／変換する。
5.

検査送信－埋込み型装置－心臓病－報告者は、[PCD-09]トランザクションを用いて検査利用者へ装置情報を送信する。

6. 検査受信－埋込み型装置－心臓病－利用者は、検査メッセージを受信する。
7. 検査処理－埋込み型装置－心臓病－利用者は更に、臨床報告書類、データベース、またはトランスコード化／再フォーマット化の結果のような派生的製品内に含まれる検査メッセージを処理する。
6.5 IDCO 患者識別考察
このプロファイルは、次の二つの患者 ID 領域：検査を提供する装置ベンダシステムおよび検査を受信する診療所を横断した ID の事前に調整した関係を仮定する。
地方の法規制によっては、各々の埋込み型心臓装置ベンダは、それが埋め込まれた患者と共に、固有の装置 ID をマッピングする、登録を保持する義務を負わされるかもしれない。あるローカ
ルでは、このマッピングは、埋込みまたはその他の組織の厳格な責任である。特定の患者識別情報は、一般にその装置に蓄えられるのではなくて、登録の際にまたはその他の手段によって利用可能になる。したがって、埋込み型装置－心臓病－報告者は、[PCD-09]トランザクションの一部として、埋込み装置のための装置関係へ、患者を表わすこの ID を送信することが必要とされるに過ぎない。規定規約によるこの ID は、産業界全体の製造業者固有 ID、固有の製造業者モ
デル番号、および固有の製造業者通し番号の連結である。
このプロファイルは、一つのアクタ、埋込み型装置－心臓病－利用者を検査メッセージの終点として規定する。埋込み型装置－心臓病－利用者は、二つの患者 ID 領域を横断した患者 ID の相
互参照を事前調整したことになる。患者の記録庫内に固有の装置 ID を保存することによって調整される。これは一般的には患者の固有の ID になるが、緊急事態における患者の位置でもあり得る。
ある場合には、埋込み型装置－心臓病－報告者は、名前、住所、等のような患者識別情報を詳述した。これらの場合には、埋込み型装置－心臓病－報告者は、[PCD-09]トランザクションの一部としてこの情報を送信できる。

40

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

6.6 IDCO セキュリティ考察
このプロファイルは、ATNA の使用を必要とはしない。施設内、VPN、等を含めて公共ネット
ワーク上のデータ転送を必要とはしないこのプロファイルには、複数の実装モデルがある。しかし、公共ネットワークが用いられる場合、ATNA は、それらのネットワーク上の安全なトラン
スポートのための一つのオプションである。埋込み型装置－心臓病－報告者アクタは、データが信用できないネットワークを横断して送信される場合、遠隔経過観察のための通信を確保するた
めに、ATNA プロファイルの安全ノードアクタと共にグループ化されることが推奨される。

41

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

7 ロゼッタ用語マッピング（RTM）
7.1 問題記述
大部分の PCD 装置は、ベンダ特有のまたは特許に関する専門用語と学術用語を使用する。結果として、情報が装置施設情報通信(DEC)のような規格ベースのトランザクションを用いて交換されるかもしれないとしても、意味の相互運用性は、コンテンツが同様に標準の学術用語へマッピ
ングされることを必要とする。このマッピングは、特定の用語からより一般的な用語へマッピン
グする場合、矛盾することも多く、意味が正確に伝わらない。
このプロファイルは、一般的には、急性ケア環境（例えば、生理的モニタ、換気装置、輸液ポン
プ、等）および標準用語へのそれらのマッピングで用いられる医療装置に適切な意味論の中核となるセットを特定する。RTM マッピングの労力は当初、数値パラメータおよびそれらの関連測
定単位と列挙値の上に焦点が当てられていた。現在は、RTM マッピングの労力は、数値パラメータと列挙値の関連単位上に焦点が当てられ、また将来は、OBR-4 とイベントコンテンツモデ
ル中に表現された検査階層の側面を含めるように拡張されそうである。
RTM 情報は均一な方式で、例えば一組のエクセル(Excel)のワークシート、および出版と配布のための一組の XML ファイルとして産業界で容易に適応できるような、読み易い機械形状で表される。これは、生産システムによる使用を促進することになるが、より重要なことは、次の目標を持って、ベンダの間の比較を促進し、彼らのシステムにおいて専門用語規格を実装することになる：
・標準専門用語から欠落している用語を特定する
・多重表現が可能ならば、正確かつ一貫した使用を確実にする・測定単位の正確かつ一貫した使用を確実にする
・列挙値の正確かつ一貫した使用を確実にする・「閉じ込め階層」の正確かつ一貫した識別を確実にする
RTM の開発の期間とその後は、標準化された医療装置用語におけるギャップが特定されることになる。これらの場合、適切な用語法に意味論を加えるための提案がなされる。RTM プロファ
イルの当面の焦点は、一般的には装置データゲートウェイと施設レベルアプリケーションの間にある DEC のようなトランザクションプロファイルにおけるコンテンツを標準化することになるが、標準化された用語はまた、文字通りにセンサから EHR へ意味の相互運用性ができるようにしながら直接的な装置通信をサポートすべきである。
RTM 情報の利用可能性はまた、正確な測定単位と特定の数値に関連した正確な列挙値の使用を強化することなど、より厳格にメッセージの妥当性を確認することができるツールの開発を促進することになる。例えば、ST セグメント偏差は、伝統的な"mm"というよりはむしろ、"μV" か"mV"で表現されることになる。これは、代わりに患者安全性に次々に役立つことになる、より大きな相互運用性、明瞭度、および正確さを促進することになる。

42

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

医療装置とシステムデータの交換に関する、ISO/IEEE 11073-10101 や UCUM のような標準
専門用語の一貫したかつ正確な使用は、実時間臨床決定支援、スマート警報、安全性インターロ
ック、臨床アルゴリズム、およびデータ採掘などの臨床研究の更なる開発を促進することになる。
この仕事はまた、イベントと警報、波形、装置環境などの重大な監視情報をサポートするために将来拡大されることができる。
7.2 アクタ／トランザクション
このコンテントプロファイルによって、新しいアクタは一つも作成されなかった。RTM の表の内容は全てではないが、プロファイル上の IHE PCD トランザクションの多くに影響することになる。
7.3 統合プロファイルオプション
このコンテントプロファイルによって定義されたオプションはない。
7.4 統合プロフィルプロセスフロー
このコンテントプロファイルのためのプロセスフローはない。
7.5 主要ユースケース
患者は家庭で監視される。潜在的に生命を脅かす心臓イベントが検出され、そしてそのイベントを確認して彼のケア提供者へ転送する遠隔監視サービスへ報告される。患者はその後、胸の痛みを訴えて ER へ収容される。12 リード線診断が取られ、その後連続的な生命徴候監視または更なる検査のための遠隔測定がなされる。ST セグメント偏差の一連の警告エピソードに従って、患者は心室エクトピの短期ランを示し、それは室心悸亢進、次いで繊維性攣縮へ急速に進展するが、始まりからずっとモニタからの警報をトリガーする。患者は ER において心変換され、CABG
外科手術が計画された。外科手術の間に、患者は 1 ダースをはるかに上回る医療装置（例えば、マルチパラメータ患者モニタ、麻酔機器、多重輸液ポンプ、バイパス機器、等）に接続され、またこれらの装置とシステムからのデータは、統合されかつ理解できる方法で自動的にチャート表示される。外科手術が成功した後、患者は ICU で監視される。患者は一週間後退院し、家庭で回復まつ。ここで、とりわけ回復を促進するために、低価格の無線インターフェースのある肺気量計を使用する。彼はまた家の内外で歩き回る間、彼の ECG を記録する無線のセンサを取り付けて、彼の携帯電話経由で遠隔監視サービスへ送信する。患者はまた、心臓リハビリ施設で経過観察され、ここで彼の ECG とブドウ糖測定値が運動前後に取られ、また全てのデータが電子的に記録された。この情報は最終的に患者の個人健康記録に保存され、また彼が受けた心臓薬物治療に関する経過観察臨床調査研究のために利用可能にされる。

43

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

この包括的であるが現実的なユースケースの最大のポイントは、患者のデータが 3 ダースをはるかに上回る数の医療装置とシステムに「接触」しており、またそれらはほぼ同じ数の異なるベンダによって設計され製造されたことである。これら全ての装置とシステムを横断して相互運用性を達成することに向けた最重要な最初のステップは、それらが分担した共通の意味論的基礎を使用することである。

44

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

用語辞典
ACC (American College of Cardiology)：米国心臓病学大学 http://www.acc.org/
ACCE (American College of Clinical Engineering)：米国臨床技術大学 http://www.accenet.org/
アクタ(Actor)：ユースケース図内の作用を実施できるユースケース図内の実体。可能な作用はメッセージの作成または利用である。
ACM(Alarm Communication Management)：警報情報伝達管理は、患者ケア装置から警報マネージャへの、および警報マネージャから警報を発する警報利用者への、臨床警報や技術的警報の通信のための IHE PCD プロファイルである。
ADT (Admit, Discharge & Transfer)：入院、退院、および転送。
警報(Alarm)：臨床警報は、起動した時に、緊急の臨床評価と可能な介入作業を必要とする条件を指示するシステムまたは装置からの指示である。
警戒警報(Alert)：臨床の警戒警報は、臨床評価と可能な注意を必要とする状態が存在するシス
テムまたは装置からの指示である。
非周期的 (Aperiodic)：心臓出力測定時などの不規則な間隔で発生する PCD データ。
正式な (Authoritative)：信頼できることを承認。
臨床 (Bedside)：一般的には急性看護環境における臨床現場。
BCMA：臨床コンピュータ支援投薬管理システム、aka バーコード投薬管理システム。
結合(Binding)：二つの関連した情報要素を結合させる処理。PCD 状況では、これは一般的には装置または装置セットと患者との連係を意味する。
生体測定の(Biometric)：ID を認識する、または請求された ID を検証するために用いられる測定可能な身体特性、または個人行動特性。
心臓装置プログラマ(Cardiac Device Programmer)：埋め込みペースメーカー、心臓細動除去器、または心臓再同調装置の動作パラメータを非侵襲的に問い合わせ、監視し、変更するために用いられる装置。
CDR (Clinical Data Repository)：臨床データ保管庫。
CIS (Clinical Information System)：臨床情報システム。
CLIA (Clinical Laboratory Improvement Amendments) ： 臨 床 実 験 室 改 善 修 正 。
http://www.cms.hhs.gov/clia/
コネクタソン（Connectathon）：IHE 試験処理－産業同業者からの対応するシステムによって、参加会社が各社の IHE 実装能力を試験する、一週間にわたる相互運用性試験イベント。
CT (Consistent Time)：時刻同期統合プロファイル。
DEC (Device Enterprise Communication)：装置施設情報通信。
DICOM (Digital Imaging and Communications in Medicine)：医療用デジタル画像とその通信のための標準規格。http://medical.nema.org/
DOB (Date of Birth)：生年月日。
DOC (Device Observation Client)：装置検査クライアント：PCD データの受取りに責任があるアクタ。

45

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

DOF：装置検査フィルタ：協定記述に基づく PCD トランザクションのフィルタリングに責任があるアクタ。
DOR(Device Observation Reporter)：装置検査報告者：レガシーと規格に基づく PCD データのIHE PCD メッセージプロファイルへのマッピングに責任があるアクタ。ISO/IEEE 11073 に基づく。
ECG (Electrocardiogram)：心電図。
EEG (Electroencephalogram)：脳波図。
EHR (Electronic Health Record)：電子式健康記録。
eMAR (Electronic Medication Administration Record)：電子式投薬管理記録。
eMPI (Enterprise Master Patient Index)：施設マスター患者インデックス。
EMR (Electronic Medical Record)：電子式医療記録。
FDA (The United States Food and Drug Administration)：米国食品医薬品局。
一般目的の輸液ポンプ：多種多様な臨床環境において静脈内に流体を注入するために用いられるポンプ。PCA（patient-controlled analgesia: 患者制御の微麻酔）、若しくはシリンジポンプなどの特定の目的のためまたは特定の環境で用いられる特製注入ポンプからは区別される。
分類化：直接的なアプリケーション・プログラム・インターフェースによってアクタ間で転送される情報が達成されるように、アクタが一つのシステムにまとめて関連づけられること。IHEに対しては範囲外である。
HIMSS (Healthcare Information and Management Systems Society)：ヘルスケア情報と管理システム協会。
HIS (Hospital Information System)：病院情報システム。
HL7 (Health Level 7)：ヘルスレベル 7。http://www.hl7.org/
IHE (Integrating the Healthcare Enterprise)：医療連携のための情報統合化プロジェクト。
http://www.ihe.net
IEEE (Institute of Electrical and Electronics Engineers) ： 米 国 電 気 ・ 電 子 通 信 学 会 。
http://www.ieee.org
IETF (Internet Engineering Task Force) ： イ ン タ ー ネ ッ ト 工 業 技 術 特 別 調 査 団 。
http://www.ietf.org/
埋込型心臓再同調治療（CRT: Cardiac Resynchronization Therapy）装置：左心室効率を改善
し、心室同調を回復させるために用いられる、表皮直下に埋め込まれた電子式装置。
埋込型細動除去器：電気的衝撃を適用することによって、心臓筋肉の繊維性攣縮の影響を弱め、正常な心拍を回復するために用いられる、表皮直下に埋め込まれた電子式装置。
埋込型ペースメーカー：心臓の特定条件で、心臓筋肉の電気的刺戟によって正常な心拍をもたらすために、表皮直下に埋め込まれた電子式装置。
相互作用図：データフローとイベントのシーケンスを描写する図。
IT (Information Technology)：情報技術。
MAC (Media Access Control)：媒体アクセス制御－ネットワーク情報伝達中に用いられる全ての装置に関連する固有の識別／通し番号。

46

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

MLLP (Minimal Lower Layer Protocol)：最小の低層プロトコル－イーサネット(Ethernet)上でHL7 メッセージを転送するために用いられ、HL7 メッセージの最初と最後を識別する区切り記
号を定義する。
MPI (Master Patient Index)：マスター患者インデックス
MRN (Medical Record Number)：医療保険記録番号（米国）または医療記録番号。
NEMA (National Electrical Manufacturers Association)：米国電気製造業者協会。
NTP (Network Time Protocol)：ネットワーク時間プロトコル。これは同期コンピュータ時計のための標準インターネットプロトコルである。ウェブサイト http://www.ntp.org は、コンピュータと同調させる方法について、入門レベルと専門家レベルにおける広範なバックグラウンド文
書類を提供する。
PAM (Patient Administration Management)：個人情報・患者情報管理、IHE-ITI 実装プロフ
ァイル。
PDQ (Patient Demographics Query)：患者情報問い合わせ、IHE-ITI 実装プロファイル。
PES (Patient Encounter Source)：患者情報源、患者についての来院情報を追加し更新しかつ保持することに責任があるシステム。それは、患者情報利用者に新しい更新情報を提供する。
PEC(Patient Encounter Consumer)：患者情報利用者、患者についての患者情報源によって提供される患者来院情報を使用するシステム。
生理的警報：患者の生理的状態（その患者に関する介護者指定の安全範囲以上または以下の心拍数など）を反映する警報。
一次警報システム：患者ケア装置はそれ自体目視と聴覚の警報指示を提供し、患者近傍において即時に見聞きすることができ、しかも患者を監視することから生じる信頼できる警報の一次指示器である。ケア提供者は、これらの一次の警報表示に基づいて即時の行動を取れる位置にいなければならないこと、また警報通信のための二次警報システムだけを専ら当てにしていてはならないことが認識されている。
PCD (Patient Care Devices)：患者ケア装置。
PIV (Pump Infusion Verification)：薬物治療管理システムから輸液装置への通信命令のためのポンプ輸液検証プロファイル。
PnP (Plug and Play)：プラグアンドプレイ。
臨床現場：臨床ケア下の患者へ密接な接近ができる物理的区域。通常は患者の枕元の周辺近傍、また隣接区域を含んでいてもよい（ブドウ糖、血液ガス）。
生理的：生命有機体の機械的、物理的、および生化学的な機能。
RFC (Request for comment)：コメントの要求。http://www.rfc-editor.org/
RFID (Radio frequency identification)：ラジオ周波数識別。
役割：使用事例におけるアクタの作用。
RSNA (Radiological Society of North America)：北米放射線協会。http://www.rsna.org/
RTM (Rosetta Terminology Management Profile)：ロゼッタ用語管理プロファイル
安全性輸液システム（スマートポンプシステム）：次のような一つ以上の「スマートな」特徴の使用を通じて、輸液に関連したエラー率を低減させるように設計された輸液装置：

47

IHE 患者ケア装置テクニカルフレームワーク、 ボリューム 1 (IHE PCD TF-1): 統合プロファイル

・ 積載医薬ライブラリにおける事前設定された限界に対して、プログラムされた投与量を点検する能力。
・RFID 標識またはバーコードから輸液パラメータを読み取る能力。

・

有線または無線のネットワーク経由で輸液パラメータを送信し受信する能力。

・

サーバーまたはゲートウェイを通じて通信する能力。

適用範囲：トランザクションの簡潔な記述。
二次警報設備：追加の位置において、追加の人々へまたはアーカイブのような追加の目的のために、「最良の努力」の警報通信を与えることが意図されたシステム、しかし患者の監視から生じる警報の信頼できる一次表示器として、一次警報システムの代わりをすることは意図されていないシステム。
SNTP (Simple Network Time Protocol)：単純なネットワーク時間プロトコル。これは、NTPの減少した正確度改訂版である。プロトコルフィールドは同じであるが、その用いられるデータ
値とアルゴリズムは、精度を大きく低減させているので、限られた容量のシステム上で実行されることができる。
同意する：特定の条件記述を満たしているメッセージのみが同意者へ送られるような依頼をする。
技術的な警報：（患者から離れた ECG リードのように）ケア提供者からの処置を必要とするかもしれないような患者の警報ケア装置自体の状態を反映する警報。
合 同 委 員 会 － 以 前 は 、 ヘ ル ス ケ ア 組 織 認 定 合 同 委 員 会 （ JCAHO: Joint Commission on
Accreditation of Healthcare Organizations）。
トリガーイベント：メッセージの受け取りまたは処理の完成などの、別の作用を発生させるイベント。
UID (Unique Identifier)：ユニークな ID。
Unbinding：装置からの患者の分離。
迷惑な：HL7 のコンテキスト内で、トリガーイベントを取り扱うアプリケーションシステムによって情報の転送が開始する時、そのトランザクションは、迷惑な更新と呼ばれる。
ユニバーサル ID：UID タイプ内での時間上の固有 ID。各々の UID は、特別に列挙された種の一つに属していなければならない。ユニバーサル ID はそのスキームの構文ルールに従わなければならない。
ユースケース：アクタの図描写とシステムの作業。
UTC (Universal Coordinated Time)：ユニバーサル連携時間。これはグリニッジ標準時間の交換である。それは国際的に認められ支持されている参照時間軸を定義する。
有効な：ケア提供者によって正確なものとしてマークされている PCD データ。
W3C (World Wide Web Consortium)：ワールドワイドウェブ連合。http://www.w3.org/

48