GMSIH, SFIL, IHE-J, JAHIS and RSNA

Integrating the Healthcare Enterprise

10

臨床検査
テクニカルフレームワーク
Volume １（LAB TF-1）
統合プロファイル
Revision 2.0 - トライアル実装用
2007年8月16日

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

20

30

40

50

60

目次
1

はじめに .......................................................................................................................................................7
1.1
IHE の概要 ...........................................................................................................................................7
1.2
臨床検査テクニカルフレームワークの概要 ......................................................................................... 7
1.2.1
本書の作成 .....................................................................................................................................7
1.2.2
臨床検査テクニカルフレームワークの構成 .................................................................................. 7
1.3
対象読者 ................................................................................................................................................8
1.4
標準との関係 ........................................................................................................................................8
1.5
現実のアーキテクチャとの関係 ........................................................................................................... 9
1.6
表記規則 ................................................................................................................................................91.6.1
IHE アクタおよびトランザクションの図表 ................................................................................. 9
1.6.2
プロセスフロー図 ........................................................................................................................ 10
1.6.3
テクニカルフレームワークの相互参照 ......................................................................................... 10
1.7
本年行われる変更の範囲 .................................................................................................................... 10
1.7.1
補遺および CP の統合 ................................................................................................................. 11
1.7.2
患者基本情報および受信データについての ITI-TF への依存 .................................................... 11
1.8
コメント ..............................................................................................................................................12
1.9
著作権 .................................................................................................................................................12
1.10 IHE テクニカルフレームワークの開発および保守のプロセス ......................................................... 12
1.11
用語集..............................................................................................................................................12
2 臨床検査テクニカルフレームワークの範囲 .............................................................................................. 182.1
臨床検査 ..............................................................................................................................................18
2.2
臨床検査部門が監督するポイントオブケア検査................................................................................ 19
2.3
臨床検査レポートの共有 .................................................................................................................... 19
2.4
今後のデータ交換のための共通コードセット共有 ............................................................................ 192.5
臨床検査の専門分野 ...........................................................................................................................20
3 臨床検査統合プロファイル ........................................................................................................................20
3.1
医療機関のワークフロー統合プロファイル ....................................................................................... 20
3.2
医療コミュニティのコンテンツ統合プロファイル ............................................................................ 22
3.3
統合プロファイル間の依存関係 ......................................................................................................... 23
3.4
統合プロファイルの概要 .................................................................................................................... 25
3.4.1
Laboratory Testing Workflow（LTW） .................................................................................... 25
3.4.2
Laboratory Device Automation（LDA） .................................................................................. 25
3.4.3
Laboratory Point Of Care Testing（LPOCT）......................................................................... 25
3.4.4
Laboratory Code Set Distribution（LCSD） ........................................................................... 25
3.4.5
Laboratory Specimen Barcode Labeling（LBL）.................................................................... 25
3.4.6
Laboratory Scheduled Workflow（LSWF） – 非推奨 ............................................................ 25
3.4.7
Laboratory Information Reconciliation（LIR） – 非推奨...................................................... 25
3.4.8
Sharing Laboratory Reports（XD-LAB） ................................................................................ 26
3.5
製品実装 ..............................................................................................................................................26
3.5.1
一般ガイドライン ........................................................................................................................ 26
3.5.2
LAB-TF における HL7 規格の使用 ............................................................................................ 26
3.5.3
LAB-TF におけるワークユニット間の関係................................................................................ 27
3.5.3.1
オーダグループあるいは Laboratory Request ................................................................... 272
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

70

80

90

100

3.5.3.2
オーダ ...................................................................................................................................27
3.5.3.3
検査オーダ（Work Order） ................................................................................................ 28
3.5.3.4
検査オーダ手順 （WOS） .................................................................................................. 28
3.5.3.5
ワークフロープロファイルのアクタによるワークユニットの使用 .................................... 28
3.5.3.6
XD-LAB プロファイルのコンテンツモジュールにおけるワークユニットの配置 ............. 29
4 Laboratory Testing Workflow（LTW） - 臨床試験ワークフロー.......................................................... 30
4.1
範囲 .....................................................................................................................................................30
4.2
ユースケース ......................................................................................................................................30
4.2.1
登録済み検体を使用するオーダ ................................................................................................... 30
4.2.2. 外部登録機関が登録した検体を使用するオーダ ........................................................................... 31
4.2.3
臨床検査部門により作成される実施者オーダ ............................................................................ 32
4.3
アクタとトランザクション ................................................................................................................ 32
4.4
LTW 統合プロファイルのオプショﾝ .................................................................................................. 33
4.5
プロセスフロー ...................................................................................................................................33
4.5.1
最初の 2 つのユースケースの LTW: 発行者（Placer）がオーダする .......................................... 34
4.5.2
3 番目のユースケースの LTW: 実施者（Filler）がオーダする：............................................. 35
4.5.3
患者更新フロー ............................................................................................................................36
4.5.4
オーダと結果の更新とキャンセル .............................................................................................. 38
4.5.5
オーダ入力前に実施される検査 .................................................................................................... 38
5 Laboratory Device Automation （LDA） - 検査自動化システム ......................................................... 39
5.1
範囲 .....................................................................................................................................................39
5.2
ユースケース ......................................................................................................................................40
5.2.1
検体到着前に WOS が LD にダウンロードされるケース .......................................................... 41
5.2.2
LD への検体到着時に WOS をクエリするケース ...................................................................... 42
5.2.3
LD へ WOS を手入力するケース ................................................................................................ 42
5.2.4
Analyzer による再検査 ............................................................................................................... 43
5.2.4.1
初回の検査直後に Analyzer で決定される再検査 ............................................................... 43
5.2.4.2
Automation Manager による技術的検証中に決定される再検査 ....................................... 44
5.2.4.3
Order Filler による臨床的検証中に決定される再検査 ....................................................... 45
5.2.5
患者検体 WOS のユースケースのサマリ .................................................................................... 45
5.2.6
分析装置により実施される精度管理 ............................................................................................. 46
5.2.6.1
Automation Manager によりダウンロードされた精度管理 .............................................. 46
5.2.6.2
Automation Manager に予約され、Analyzer にクエリされる精度管理........................... 46
5.2.6.3
Automation Manager にアップロードされる非要求型の精度管理結果 ............................ 46
5.3
臨床検査部門におけるシステムの相互接続 ....................................................................................... 47
5.4
アクタとトランザクション ................................................................................................................ 48
5.5
LDA 統合プロファイルのオプション ................................................................................................ 49
5.6
プロセスフロー ...................................................................................................................................50
5.6.1
ダウンロードモードで動作するすべての LD による検体の正常プロセス ................................ 50
5.6.2
ダウンロードモードで動作するすべての LD による WOS 更新 ............................................... 51
5.6.3
AWOS の手入力および SWOS ダウンロードによる正常プロセス ............................................ 52
5.6.4
クエリモードで動作するすべての LD による検体の正常プロセス ........................................... 53
5.6.5
許容範囲を逸脱する結果による、Analyzer での自動再検査..................................................... 54
5.6.6
技術的検証の間、Automation Manager にリクエストされた再検査 ....................................... 55
5.6.7
検査オーダ到着前に実施される緊急検査 ................................................................................... 56
3
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

110

120

130

140

150

5.6.8
Automation Manager によりダウンロードされた精度管理...................................................... 57
5.6.9
Automation Manager に予約され、Analyzer にクエリされる精度管理 .................................. 57
6 Laboratory Point Of Care Testing （LPOCT） – 臨床ポイントオブケア検査 .................................... 58
6.1
LPOCT のサマリ ................................................................................................................................58
6.2
LPOCT の範囲....................................................................................................................................58
6.3
LPOCT の範囲外 ................................................................................................................................59
6.4
ユースケース ......................................................................................................................................59
6.4.1
既存オーダ、患者 ID、ID チェックとマッチする検査結果....................................................... 59
6.4.2
オーダされていない検査結果 - 患者 ID 確認 ............................................................................ 60
6.4.3
一時的に接続される POCRG、臨床検査部門による監督 -オーダ作成 ...................................... 61
6.4.4
ポイントオブケア検査結果の手入力-オーダ作成 ....................................................................... 62
6.4.5
POCRG による精度管理検査 ...................................................................................................... 62
6.5
アクタとトランザクション ................................................................................................................ 63
6.6
LPOCT 統合プロファイルのオプション............................................................................................ 64
6.7
プロセスフロー ...................................................................................................................................65
6.7.1
既存のオーダと照合される検査結果- 患者 ID 確認 ................................................................... 65
6.7.2
患者 ID 確認を伴うオーダされていない検査結果 ...................................................................... 65
6.7.3
一時的に接続される POCRG – オーダされていない検査結果.................................................. 66
6.7.4
オーダされていないポイントオブケア検査結果の手入力 .......................................................... 66
6.7.5
POCRG による精度管理検査 ...................................................................................................... 67
7 Laboratory Specimen Barcode Labeling（LBL）－検体バーコードラベリング ................................... 68
7.1
範囲 .....................................................................................................................................................68
7.2
ユースケース ......................................................................................................................................68
7.2.1
Order Placer とグループ化される LIP（リクエストモード） .................................................. 68
7.2.2
Order Filler とグループ化される LIP（リクエストモード） ................................................... 69
7.2.3
Order Placer とグループ化され、Order Filler に情報を伝えられる LIP（リクエストモード）
69
7.2.4
Order Placer とグループ化される LIP（クエリモード） ......................................................... 69
7.2.5
Order Filler とグループ化される LIP（クエリモード） .......................................................... 70
7.3
アクタとトランザクション ................................................................................................................ 70
7.4
LBL 統合プロファイルのオプション ................................................................................................. 71
7.5
プロセスフロー ...................................................................................................................................72
7.5.1
ユースケース 7.2.1:Order Placer とグループ化される LIP（リクエストモード） .................. 72
7.5.2
ユースケース 7.2.2: Order Filler とグループ化される LIP（リクエストモード） .................. 72
7.5.3
ユースケース 7.2.3: LIP が Order Placer とグループ化され、Order Filler が情報を伝える（リクエストモード） ..........................................................................................................................................73
7.5.4
ユースケース 7.2.4: Order Placer とグループ化される LIP（クエリモード） ........................ 73
7.5.5
ユースケース 7.2.5: Order Filler とグループ化される LIP（クエリモード）.......................... 74
8 Laboratory Code Set Distribution （LCSD） - 検査コードセット配信 .............................................. 75
8.1
範囲 .....................................................................................................................................................75
8.2
アクタとトランザクション ................................................................................................................ 75
8.3
Laboratory Code Set Distribution 統合プロファイルのオプション ................................................ 76
8.4
プロセスフロー ...................................................................................................................................76
9 Sharing Laboratory Reports（XD-LAB）............................................................................................... 77
9.1
範囲 .....................................................................................................................................................774
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

160

170

180

190

9.2
ユースケース ......................................................................................................................................77
9.2.1
病院の医師がアフィニティドメインの患者記録をフィード ...................................................... 77
9.2.2
民間の臨床検査機関がアフィニティドメインの患者記録をフィード........................................ 78
9.2.3
外来の医師がアフィニティドメインで臨床検査レポートを共有 ............................................... 78
9.2.4 民間臨床検査機関あるいは病院の臨床検査部門がレポートを組織的に共有 ................................. 78
9.2.4 民間臨床検査機関あるいは病院の臨床検査部門がレポートを組織的に共有 ................................. 79
9.2.5
退院時に作成･共有される累積レポート ..................................................................................... 79
9.3
国家プロジェクトとのリンク ............................................................................................................. 79
9.3.1
イタリア ......................................................................................................................................80
9.3.2
米国 ..............................................................................................................................................80
9.3.3
フランス ......................................................................................................................................80
9.3.4
日本 ..............................................................................................................................................80
9.4
ワークフローメッセージングとのリンク........................................................................................... 81
9.4.1
IHE Laboratory Scheduled WorkFlow とのリンク .................................................................. 81
9.5
XD*-LAB 統合プロファイルのアクタとトランザクション............................................................... 81
9.5.1
アクタとトランザクションの関係 .............................................................................................. 81
9.6
XD*-LAB 統合プロファイルのオプション ........................................................................................ 82
9.6.1
文書表示オプション .................................................................................................................... 82
9.6.2
文書インポートオプション ......................................................................................................... 82
9.6.3
節のインポートオプション ......................................................................................................... 83
9.6.4
個別データのインポートオプション........................................................................................... 83
9.7
XD-LAB の他の統合プロファイルへの依存関係 .............................................................................. 83
9.8
XDS、XDM、XDR のコンテンツ結合 .............................................................................................. 83
10
Laboratory Scheduled Workflow（LSWF）－臨床検査予約済ワークフロー..................................... 85
10.1
ユースケース ...................................................................................................................................85
10.1.1 ID のある検体へ外部発行されたオーダ ..................................................................................... 85
10.1.2 ID のない検体あるいは臨床検査部門に採取される検体のオーダ ............................................. 86
10.1.3
外部機関あるいは臨床検査部門により識別される検体の実施者オーダ ................................ 87
10.2
アクタとトランザクション ............................................................................................................. 88
10.3
Laboratory Scheduled Workflow 統合プロファイルのオプション ............................................... 90
10.4
プロセスフロー ...............................................................................................................................92
10.4.1
最初の 2 つのユースケースに関するワークフロー: 発行者（Placer）がオーダする ......... 92
10.4.2 3 番目のユースケース:実施者オーダリング ............................................................................ 93
10.4.3
患者更新のフロー .................................................................................................................... 94
10.4.3.1 オーダ作成前の患者情報更新 ................................................................................................ 94
10.4.3.2 オーダ作成後の患者情報更新 ................................................................................................ 95
10.4.3.3 オーダ遂行後の患者情報更新 .............................................................................................. 96
10.4.4
オーダ/結果の更新、ステータス変更、キャンセル、例外 ..................................................... 97
11
Laboratory Information Reconciliation（LIR）－検査情報整合性確保 .............................................. 98
11.1
ユースケース ...................................................................................................................................98
11.1.1 ADT（入院・退院・転送）システムで登録される ID のない患者 ............................................ 98
11.1.1.1 Order Placer 側がオーダする検査 ...................................................................................... 98
11.1.1.2 Order Filler 側がオーダする検査 ......................................................................................... 99
11.1.2 ADT システムで登録されない患者 ............................................................................................. 99
11.1.2.1 Order Placer 側がオーダする検査 ...................................................................................... 99
5
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

200

11.1.2.2 Order Filler サイドでオーダされる検査 ............................................................................. 99
11.1.3 オーダ作成前に臨床検査装置で実施される検査 ...................................................................... 100
11.1.3.1 分析装置から開始...............................................................................................................101
11.1.3.2 Automation Manager から開始 ........................................................................................101
11.1.3.3 本シナリオの最終部分 .......................................................................................................101
付録 A: アクタの説明 .....................................................................................................................................103
付録 B: トランザクションの説明 ...................................................................................................................1066
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

1
210

220

はじめに

1.1 IHEの概要
インテグレーティングヘルスケアエンタープライズ（IHE：Integrating the Healthcare Enterprise）は、現在の医療機関を支える情報システムの統合を促進するためのイニシアチブである。その基本的な目的は、患者を治療するために医療従事者が治療方針を決定するために必要なすべての情報を正しく利用できるようにすることである。IHEイニシアチブは統合作業を促進するための手段であり討議の場である。IHEでは特定の臨床的目標をするメッセージ交換規約を実装するためのテクニカルフレームワークを定義している。 また、IHEには、このフレームワークを実装した上での厳密なテストプロセスも含まれている。さらにIHEでは、このフレームワークの利点を立証し、業界やユーザがIHEを導入するよう促進するために、医療関係者の会議で教育セッション、展示会を開催している。
IHEのアプローチでは、新しい標準を定義するのではなく、HL7、ASTM、DICOM、ISO、IETF、OASIS、
CLSIなどの既存の標準を、それぞれが適切な分野で統合して使用し、必要に応じて構成の選択肢を定義する。IHEでは、既存の標準で明確化しなければならないときや拡張が必要な場合には、該当する標準化団体に推奨事項を提示することにしている。

1.2 臨床検査テクニカルフレームワークの概要
1.2.1 本書の作成
230

本書、臨床検査テクニカルフレームワーク（LAB-TF）では、医療施設の臨床検査部門以外の部門やさらに幅広い医療提供者のコミュニティ（ここでは今後、医療コミュニティと呼ぶ）とともに、臨床検査部門の統合という目標を達成するために、既存の標準を特定な形で実装する定義を行う。
本書は毎年更新され、公開レビュー期間に正誤表の確認と修正を通じて定期的に見直される。現バージョン（Rev. 2.0 for Trial Implementation）では、2007年7月時点の定義と実装に基づくIHEトランザクションを記述する。文書の最新バージョンは以下のインターネットリンクにより、常時入手できる。

www.ihe.net/TechnicalFramework, www.ihe-europe.fr,www.gmsih.fr/IHE
本書は以下の標準化団体の助力で作成された。
240

GMSIH（Groupement pour la Modernisation du Système d’Information Hospitalier）
JAHIS（保健医療福祉情報システム工業会）
IHE-J（日本IHE協会）
SFIL（Société Française d’Informatique de Laboratoire）
HL7およびHL7加盟団体
RSNA（北米放射線医学学会Radiological Society of North America）

1.2.2 臨床検査テクニカルフレームワークの構成

7
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

250

260

IHE臨床検査テクニカルフレームワークでは、IHEアクタという医療施設あるいは医療コミュニティの機能
構成要素のサブセットを設定する。そして、アクタ間の相互作用を標準に基づくトランザクションを組み合わせて定義する。このトランザクションの内容は、順次詳細に説明され、以下の5巻（Volume）にまとめられる。

•

本書、臨床検査験テクニカルフレームワーク Volume 1（LAB TF-1）では、IHE 機能が俯瞰的観点から示され、統合プロファイルという機能単位にまとめたトランザクションが臨床検査に独特な統合要件を対処する方法を示す。

•

Volume 2 では、メッセージに基づく各トランザクションおよびメッセージについて、詳細な技術的説
明が行われる。

•

Volume 3（LAB TF-3）では、文書に基づく各トランザクション、その恒久的（persistent）なコンテンツと制限についての詳細な技術的説明が提供される。

•

Volume 4（LAB TF-4）では、この臨床検査テクニカルフレームワークの全プロファイルで使用できる
LOINC（Logical Observations Identifiers, Names and Codes）のサブセットが提供される。

•

Volume 5（LAB TF-5）は、この臨床検査テクニカルフレームワークに則って、国レベルの統合を実行する場合のフレームワークを提供する。

1.3 対象読者
本書の想定される対象読者は次のとおりである。
270

280

•

IHE イニシアチブに参加するベンダの技術スタッフ•

医療施設、医療コミュニティの IT 責任者•

標準作成に関係する専門家•

医療情報システムの統合の技術的側面に関心をもつ人

1.4

標準との関係

IHEテクニカルフレームワークでは、医療機関での相互作用という観点のみから分散医療環境の機能コンポーネント（IHEアクタと呼ばれる）を特定する。現開発レベルでは、HL7、IEFT、ISO、CLSI、OASIS、W
２Cの各標準に基づいてトランザクションのシークエンスを定義している。IHEイニシアチブの範囲が拡大すると共に、他の標準に基づくトランザクションも必要に応じて組み込まれる可能性がある。
状況によってIHEは、これらの標準が特定のオプションをサポートすることを推奨しているが、これらの標準と矛盾する技術的な選択を推奨することはない。IHEの方針としては、既存の標準に問題や拡張があった
場合には、各標準開発団体に、それぞれの適合性あるいは各標準開発戦略内での解決を依頼することとしている。
したがって、IHEは実装の枠組みであり、標準そのものではない。IHEを標準として参照することは適切ではない。製品の適合性宣言は、従来どおり対応する標準に直接言及する必要がある。さらに、IHE統合機能を実装したベンダは、IHE統合宣言書を使用して、IHEテクニカルフレームワークの仕様に製品が準拠して
8
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

290

いることを記述しなければならない。IHE統合宣言書の目的は、対象製品のユーザに、その製品が対応するよう設計されているIHE機能を伝えることである。IHE統合宣言書を発行するベンダは、その内容に関する全責任を負わなければならない。IHEのアクタと統合プロファイルの概念を理解しているユーザは、実装している他の製品のIHE統合宣言書を比較することで、製品間の統合レベルを判断することができる。

1.5 現実のアーキテクチャとの関係

300

IHEのアクタとトランザクションは、現実のヘルスケア情報システム環境を抽象化したものである。従来、各トランザクションは特定の製品カテゴリ毎（病院情報システム（HIS）、電子カルテ（EPR）、診療管理システム（CIS）、ラボ情報システム（LIS）、ラボ自動システム（LAS）、分析器、ロボチック移送シス
テムやその他の検査前後の処理装置など）が実行するが、IHE臨床検査テクニカルフレームワークでは、あ
えてそのような機能やアクタを上記の製品カテゴリと関連させることを避けている。各アクタについて、
IHEテクニカルフレームワークでは、統合する情報システムと関連のある機能だけが定義されている。したがって、IHEにおけるアクタの定義を、アクタを実装する製品の完全な定義と考えてはならず、また、フレームワーク自体を、医療情報システムのアーキテクチャを包括的に記述するものと見なしてはならない。

1.6 表記規則
本文書では、以下の表記規則を使用して、フレームワークの概念を表し、IHEテクニカルフレームワークの基になる標準の適用方法を指定する
310

1.6.1 IHEアクタおよびトランザクションの図表
各統合プロファイルは、トランザクションを通して相互作用する一連のアクタによってサポートされる、現実の機能を表したものである。アクタとは、情報システムまたは情報システムのコンポーネントであり、医療業務活動に必要な情報カテゴリを生成、管理し、それに基づいて稼動するものである。トランザクシ
ョンとは、標準に基づくメッセージを通して必要な情報をやり取りするアクタ間の相互作用である。

320

以下のセクションのアクタとトランザクションの図表では、特定のプロファイルにおいて各アクタがサポ
ートしなければならないトランザクションが示される。図表で示されるトランザクションは、LAB TF-2で定義されるとおり、名称とトランザクション番号の両者により識別される。
図ではトランザクション番号が、特定のテクニカルフレームワークのドメインを接頭にしたカッコつきの番号で示される。

330

あるプロファイルが正しく有用に機能するために、前提となるプロファイルに依存する場合がある。例えば、Sharing Laboratory Reports（XD-LAB）コンテントプロファイルは、XDS、XDMおよびXDRという3つの文書共有プロファイルの1つに依存する。これらの依存関係を知るには、表3-1でプロファイルを探し、どのプロファイルが前提として示されているか確認する。アクタは、プロファイル内の必須トランザクシ
ョンに加え、前提となるプロファイルで要件とされているトランザクションをすべて実装しなければならない。

9
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

1.6.2 プロセスフロー図
以下の統合プロファイルの解説には、関連するアクタ間のトランザクションのシーケンスとして、プロフ
ァイルが機能する流れを示すプロセスフロー図を掲載する。

340

これらの図は概要が理解できるように示されており、医療機関あるいは医療界のワークフローの中でトラ
ンザクションを見ることができる。IHEによって詳しく定義されていない特定のトランザクションと動作は、これらの図ではイタリック体で示されており、それに関連するIHEトランザクションが医療情報システムのより広いスキームのどこに組み込まれるのかという背景情報が追加される。
これらの図は、唯一可能なシナリオを示すものではない。これ以外のアクタのグループ化が可能な場合が多く、他のプロファイルからのトランザクションが発生することもある。
場合によっては、トランザクションの順番もフレキシブルである。その場合は通常、他のバリエーションが存在することを指摘する注が記載される。トランザクションは、そのトランザクションにより取り扱われる主な情報の流れに沿って矢印で示されるため、矢印は必ずしも発動源を示すわけではない。

350

1.6.3

テクニカルフレームワークの相互参照

同一テクニカルフレームワーク文書内の節を参照する場合は、節番号自体を使用する。他のVolume、または他のドメインのテクニカルフレームワークを参照する場合は、以下のフォーマットが使用される。
<ドメイン記号> TF-<Volume番号>:<節番号>
ここで、<ドメイン記号>は、IHEドメインを示す短い記号である（ITI = ITインフラ、PCC = 患者ケア、
LAB=臨床検査）。

360<Volume番号>は、そのテクニカルフレームワーク内の該当するVolumeである（1、2、3など）。
<節番号>は、該当する節の番号である。
例えば、ITI TF-1:3.1は、IHE ITインフラのVolume 1の節3.1を示す。テクニカルフレームワークのトランザ
クション番号を参照する場合は、以下の形式が使用される。
[<ドメイン記号>-<トランザクション番号>]370<トランザクション番号>は、指定されたドメイン内のトランザクション番号である。例えば、[LAB-1]は、IHE臨床検査テクニカルフレームワークのトランザクション1を示し、[ITI-30]はITインフラテクニカルフレームワークのトランザクション30を示す。

1.7 本年行われる変更の範囲
IHEテクニカルフレームワークは、新しいプロファイル、修正および新しいトランザクションを反映するた

10
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

めに、毎年更新される。

1.7.1 補遺およびCPの統合
380

390

本臨床検査テクニカルフレームワークの[Rev.2.0]は、以前は個別の補遺で説明された多くの統合プロファ
イルを統合することで、V1.2 LAB-TFを拡張する。また、IHE臨床検査委員会で承認されたCP（変更の提案）を考慮して、マイナーチェンジも提示する。これは、2008年のコネクタソン試験と展示プロセスの基礎となる。
この、LAB-TF revision 2.0に統合された補遺は以下のとおり。
Laboratory Device Automation（LDA）2005年9月に補遺として発行
Laboratory Point Of Care Testing（LPOCT）2005年9月に補遺として発行。
Laboratory Code Set Distribution（LCSD）2005年9月に補遺として発行
Sharing Laboratory Reports（XD-LAB）2006年9月に補遺として発行
Laboratory Specimen Barcode Labeling（LBL）2007年3月26日から4月26日までのパブリックコメント期
間が終了し、このLAB-TF revision 2.0で直接発行された。

1.7.2 患者基本情報および受信データについてのITI-TFへの依存
さらに、このLAB-TFのrev. 2.0では、患者基本情報および診察データを提供するトランザクションのITイン
フラドメインへの外部化も考慮している。これらのトランザクションは、ITインフラテクニカルフレーム
ワーク内に構築された、Patient Administration Management（PAM）およびPatient Demographics Query（PDQ）両プロファイルの一部である。

400

LAB-TFの以前の改訂（revision）との、後方互換性を保持するため、臨床検査委員会により以下の決定がなされた。

- 既存の Laboratory Scheduled Workflow（LSWF）統合プロファイルは、RAD-TFから受け継がれた患者データトランザクションRAD-1およびRAD-12、またADTアクタとともに、そのまま維持される。
LSWFプロファイルは、後方互換性のためだけに維持され、LAB-1、LAB-2、LAB-3、LAB-4、LAB5、RAD-1およびRAD12トランザクションを使用する。

- 既存の Laboratory Inforamtion Reconciliation（LIR） は、後方互換性のためのみに、分冊の補遺で、そのまま維持される。
410- 新しい統合プロファイルLaboratory Testing Workflow（LTW）は、LSWRおよびLIRプロファイルを組み合わせたものであるが、ADTアクタと、RAD-1およびRAD-12トランザクションは除外され、その代わりITI-TFのPAMおよびPDQプロファイルのアクタとグループ化している。

- 新しいプロファイルLTWでは、Order Placer および Order Result Trackerという2つのアクタをグループ化するオプション機能も追加される（CP38のリクエストによる）。電子患者記録（EPR）が、臨床検査部門にオーダを発行し、かつオーダ遂行の結果をトラッキングするという2つの役割を果たすのをより良くより頻繁にサポートすることが目的である。

11
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

420

1.8 コメント
JAHIS、GMSIH、SFIL、IHE-J、RSNA は、本文書およびIHEイニシアチブに関するコメントを歓迎する。
コメントは、IHE臨床検査委員会の共同委員長までお送りいただきたい。
François Macary

Nobuyuki Chiba

francois.macary@agfa.com

chiban@alice.aandt.co.jp

1.9 著作権430

Health Level Seven, Inc.は、IHEに対して、HL7規格の表の複製を許可している。本書に掲載されているHL7の表は、Health Level Seven, Inc.が著作権を保有しており、無断複写・複製・転載は禁じられている。
IHEはHealth Level Seven Inc.とその加盟団体に対し、本書の一部あるいは全体の複製を許可する。
Clinical and Laboratory Standards Institute（CLSI）はIHEに対し、POCT1-A規格の表および図の複製を許可している。本書のPOCT1-Aの表および図は、CLSIが著作権を保有し、無断複写･複製･転載は禁じられている。
IHEはCLSIに対し、本書の一部あるいは全体の複製を許可する。

440

1.10 IHEテクニカルフレームワークの開発および保守のプロセス
IHE臨床検査テクニカルフレームワークは、IHE臨床検査技術委員会により、継続的に拡張および保守が行われる。フレームワークの開発および保守のプロセスは、ベンダとユーザがIHE統合機能を有するシステム
を指定、開発、購入する際に信頼して使用できるよう、仕様を安定させるため多くの原則に従っている。

450

その第1の原則は、テクニカルフレームワークにいかなる拡張、明確化、修正を行なう場合も、フレームワ
ークの以前のバージョンとの後方互換性が維持されなければならないことである。これは、以前のバージョンで定義されたIHEアクタおよび統合プロファイルが実装されたシステムとの相互運用性を維持するためである。

1.11 用語集
この用語集では、本臨床検査テクニカルフレームワークで使用する頭字語、略語、特別用語を紹介する。
分注機（Aliquoter）

1つの親検体を、1つあるいは複数の子検体に分割する自動装置。LDA 統合プロファイルで、
Pre/Post-processor として動作する。

AM

Automation Manager: LAB-TF の LSWF, LIR, LTW および LDA各統合プロファイルに関連するアクタ。

Analyzer

LDA統合プロファイルのアクタで、検体の計測あるいは判定を行う装置がその役割を果た

12
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

す。
ATNA

ITI-TFの、Audit Trail & Node Authentication統合プロファイル

AWOS

Analytical Work Order Step（分析作業オーダ手順）。 LDA統合プロファイルで、Analyzerにより実施される。

バッテリ（Battery）

臨床検査部門へオーダすることが可能な１つあるいは複数の臨床検査のセットで、1つの名称
およびコードにより識別される。同意語は｢パネル｣。

CDA

Clinical Document Architecture。 医療文書を電子的に表示するためのHL7規格。

遠心分離機（Centrifuge）

遠心分離により、血液を血清成分と血球成分に分割する自動装置。LDA統合プロファイルではPre／Post-processorにあたる。

CIS

Clinical Information System（臨床情報システム）

臨床検査の専門家（Clinical expert）“Medical expert”、”Bio-medical scientist”、”Results principal interpreter”ともいう。オーダあるいはオーダグループの臨床的承認とレポートの総合的な責任を担う人。HL7ではResult principal
interpreterと呼ぶ。

臨床的承認（Clinical validation）“Medical validation”ともいう。臨床検査専門家がオーダやオーダグループの結果を承認し解釈するプロセス。患者についての生物学的経過や臨床的／治療情報とともに結果を解釈する。
臨床検査専門家はこの手順を自らの責任の下に専門システムを使用して実施することもある。専門システムはナレッジルールを使用し生物医学者の論法をエミュレートするものであ
る。

CLSI

The Clinical and Laboratory Standards Institute

Code set

コードセットとは、データの要素をコード化するために使用される、任意のコードのセットである。例えば、用語、医療概念、診断コード、手技コードなどの表である。国際的なコー
ドセットの例としては、LOINCTM（Logical Observation Identifier Names and Codes） がある。

コンベア（Conveyor）

検体を他の装置に搬送する自動装置。LDA統合プロファイルでは、Pre/Post-processorにあたる。

CTConsistent Time: ITI-TF の統合プロファイル。

Decapper

検体容器の栓を取り外す自動装置。LDA統合プロファイルにおいて、Pre/Post-processorになる。

DML

Device Message Layer。POCT1-A規格で定義。

EHR

Electronic Health Record

外部精度管理（External Quality

検査済みのコントロール検体に実施する検査で、目標値は明らかにされない。施設の技能管理が目的。外部精度管理の検体は、外部の機関により提供される。外部の機関は、複数の医13
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

Control）

療施設から得られた結果を管理・比較する。技能検査とも呼ばれる。

実施者オーダ番号（Filler Order Number）

臨床検査部門側のOrder Fillerアクタがオーダに割り当てた固有の参照番号である。

HIS

Hospital Information System（病院情報システム）

HL7

Health Level Seven: 医療情報交換の領域における国際標準開発組織。

IHE

Integrating the Healthcare Enterprise（医療施設の統合）

内部精度管理（Internal Quality
Control）

検査済みのコントロール検体を使用して分析装置で実施する検査。通常は目標値がわかっている。装置の正確性のチェックが目的。

ITI-TF

ITインフラテクニカルフレームワーク

Label Broker

LBL統合プロファイルのアクタで、ラベル情報を受信し、ラベルを適切な作業に配送する。
またこのプロセスのステータスを通知してもよい。

Label Information Provider

LBL 統合プロファイルのアクタで、ラベリングの指示と情報を Label Broker に送信する。

Labeler

バーコードラベルを検体容器に貼る自動装置。

Laboratory Request「オーダグループ」の同意語（下記参照）.

LAB-TF

Laboratory Technical Framework（臨床検査テクニカルフレームワーク）

LAS

Laboratory Automation System（臨床検査自動化システム）

LB

Label Broker。LAB-TF、LBL統合プロファイルのアクタ。

LBL

LAB-TFのLaboratory Specimen Barcode Labeling統合プロファイル。

LCSD

LAB-TFのLaboratory Code Set Distribution統合プロファイル。

LD

Laboratory Device。 LDAプロファイルのアクタ。LDはAnalyzerかPre/Post-processorのいずれか
である。

LDA

Laboratory Device Automation統合プロファイル。

LIP

Label Information Provider。LAB-TFリリース1のLBL統合プロファイルのアクタ。リリース2では後方互換性のためのみに保持された。

LIR

LAB-TFのLaboratory Information Reconciliation統合プロファイル。

14
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

LIS

Laboratory Information System（臨床検査情報システム）

LPOCT

LAB-TF の、Laboratory Point Of Care Testing 統合プロファイル。

LSWF

LAB-TFリリース1のLaboratory Scheduled Workflow統合プロファイル。リリース2では後方互換性のためのみに保持された。

LTW

Laboratory Testing Workflow 統合プロファイル。以前のプロファイルLSWF およびLIRを置換するために、LAB-TFリリース2で作成された。

マスターファイル
（Master File）

1つあるいは複数のアプリケーションシステムにより使用される、共通参照ファイル。コードセットはマスターファイルと見なすことができる。

MLLP

HL7 Minimal Lower Layerプロトコル。

検査結果（Observation）

他の測定値や派生地から論理的／代数的に派生した単一の測定変数値あるいは単一の測定値。

OF

Order Filler。LAB-TFのLSWF、LIR、LPOCT、LTWの各統合プロファイルのアクタ。

OP

Order Placer。LAB-TFのLSWF 、LIR、LTWの各統合プロファイルのアクタ。

オーダ（Order）

病棟／医師から臨床検査部門へオーダされ、患者から採取された1つあるいは複数の検体で実施されるバッテリあるいは検査。

Order Filler

アクタはLISで、臨床検査部門側でオーダを管理する。

オーダグループ（Order Group）

Laboratory Requestとも呼ばれる。ある患者について、病棟／医師から、1つあるいは複数の臨床検査部門へ一緒に出されるオーダのセットで、この患者から採取された1つあるいは複数の検体に対し実施されるもの。

Order Placer

HISあるいはCISがアクタ。オーダを生成、発行、管理することが目的。

Order Result Tracker

臨床検査部門が出した結果をトラッキングするアクタ。

ORI

Oservation Reporting Interface。POCT1-A from CLSIの標準POCT1-Aが定義する。

ORT

Order Result Tracker。LAB-TFのLSWF,、LIR、LPOCT、LTWの各統合プロファイルのアクタ。

PAM

ITI-TFのPatient Administration & Movements統合プロファイル

PCC-TF

患者ケア（Patient Care Coordination）テクニカルフレームワーク。

PDQ

TI-TFのPatient Demographics Query統合プロファイル。

15
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

PHR

P ersonal Health Record

発行者グループ番号（Placer Group Number）

病棟サイドのOrder Placerアクタがオーダグループに割り当てた固有の参照番号。

発行者オーダ番号（Placer Order Number）

病棟サイドのOrder Placerアクタによりオーダに割り当てた固有の参照番号。

POCDM

LPOCT統合プロファイルのPoint Of Care Data Managerアクタ。

POCT1-A

CLSIが作成したポイントオブケア検査をサポートする相互運用性規格。

POCRG

LPOCT統合プロファイルのPoint Of Care Result Generatorアクタ。

Pre/Post-processor

LDA統合プロファイルのアクタで、検体に複数の手順を実施する装置（SWOS）。

QC

LDA統合プロファイルのAnalyzerおよびLPOCT統合プロファイルのPoint Of Care Result
Generatorが実施する精度管理。

Recapper

検体容器に栓を戻す自動装置。LDA統合プロファイルではPre／Post-processorになる。

Sorter

処理の種類に応じて検体を分類する自動装置。LDA統合プロファイルではPre／Post-processorに
なる。

SWOS

Specimen Work Order Step。LDA統合プロファイルではPre/Post-processorにより実施されるWOS（検査オーダ手順）。

技術的検証（Technical Validation）

臨床検査技師が、一般に自らの管理下で手動あるいは自動技術により作成した単一の検査結果あるいは検査結果のセットを承認するプロセス。技術的検証は、検査結果が定義された臨
床検査の手続きに適合して得られたこと、そして精度管理などの技術的検証の基準を満たしていることを保証する。

Test

臨床検査部門あるいはポイントオブケアで実施する業務で、手動または分析装置で装置、機器、システムの支援を得て、1件あるいは複数の検査結果を得ようとするもの。検査結果は、
in-vitroの検体の量の測定、検体の所見、他の検査結果やデータを使用した計算、あるいは他の手段により得ることができる。

検査オーダ（Work
Order）

バッテリの検査、あるいは検査。Order FillerアクタからAutomation Managerアクタにリクエストされる。

検査オーダ手順（Work Order Step）

Order FillerアクタからAutomation Managerアクタにリクエストされる、バッテリあるいは検査。

XD-LABLAB-TFのSharing Laboratory Reports統合プロファイル。

XDM

ITI-TFのCross Enterprise Document Media Interchange統合プロファイル。

16
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

XDR

ITI-TFのCross Enterprise Document Reliable Interchange統合プロファイル。

XDS

ITI-TF の Cross Enterprise Document Sharing 統合プロファイル。

17
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2

臨床検査テクニカルフレームワークの範囲

2.1 臨床検査
460

臨床検査テクニカルフレームワークでは、医療機関のワークフロー内でin vitro検体の診断検査を完全に統合するために、臨床検査部門、病棟、医療機関の他のチームが参加する一連のワークフロー統合プロファ
イルを提供する。
さらに、臨床検査テクニカルフレームワークにより、医療機関内および独立の臨床検査組織が、（地区、地域あるいは国レベルの）広い医療コミュニティ内部で結果レポートを共有することを可能とするコンテ
ンツ統合プロファイルが提供される。

470

臨床検査部門は臨床部門あるいは医師から検査オーダを受ける。検査は患者から採取した検体で行われる。検体の採取は施設によって、臨床検査部門のスタッフ、病棟のスタッフ、検体採取室のスタ
ッフあるいは外部機関が行ってもよい。

検体容器の識別は重要である。検体IDは通常、検体容器に貼り付けられたバーコードラベルに表示する。
検体のラベリングのプロセスを、2つ以上の情報システム間（例えば、病院情報システム、臨床検査情報システム）のデータ交換に依存する組織では、LAB-TFがこのプロセスを、専用のLaboratory Specimen Barcode
Labling統合プロファイルによりサポートする。他の組織では、このLBLプロファイルを必要とすることな
く、検体IDが管理される。

480

臨床検査部門は、オーダ発行部門に対して適切な通知をともなってオーダを承認、変更、却下することができる。
検査結果は、血糖グルコースのような単純な測定値、骨髄生検のように記述の多いもの、HIV血清陰性のよ
うな単純にコード化されたもの、血清蛋白電気泳動のように画像やグラフを伴うものなどさまざまである。
結果は検査をオーダした病棟／医師へ送信される。またコピーが他の医師や部署へ送付/電子記録に保存さ
れる。

490

検査結果は、オーダされた検査とオーダされていない検査（リフレックステスト）両方に対し発行される場合がある。
検査結果はさまざまな検証手順で得られる。
未検証結果（non-validated result）は、分析装置から得られたが、人がまだ検証していない状態のものである。
技術的検証結果（technically validated result）は、制御された装置で得られ、他の基準や精度管理結果を考慮に入れて、適正な分析手順を通して得られた結果であると臨床検査技師が承認されたものである。

18
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

臨床的検証結果（clinically validated 3 result） 医学的検証済み結果（medically validated result）ともいい、臨床検査専門家（国によって、医学専門家、生物医学者、病理学者ともいう）が入手できる患者の臨床・治療情報とともに生物学的経過とオーダグループ全体との整合性を考察したうえで承認し解釈したもの。臨床検査専門家はこのステップを、簡単なケースを自動的に検証するルールや論法を適用した専門システムを使って行ってもよい。

500

臨床検査部門は通常、臨床的検証を行った後に結果を送信する。緊急時や病棟によっては常時の処置として、技術的検証結果が送信される可能性もある。この場合は、臨床的検証を行った後、結果が確認される
か訂正される。

2.2 臨床検査部門が監督するポイントオブケア検査
510

状況によっては、臨床検査はポイントオブケアの器具を使用したり、病棟のスタッフがベッドサイドで、あるいは患者自身が簡単に実施できることもある。このような検体が分析前の準備を必要としないような
一般的な検査の場合、病棟のスタッフ（あるいは患者）は結果へ直接アクセスすることが認められている。
結果は即時ケア提供者の臨床的判断のために使用される。
臨床検査テクニカルフレームワークではこのような状況を、医療施設の臨床検査部門がこのポイントオブケア検査のプロセスを監督する条件で扱う。複数の病棟のポイントオブケア分析装置は恒久的あるいは定期的に、集中Point Of Care Data Managerに接続される。この集中システムが患者検体および精度管理検体に対するポイントオブケア検査と結果を収集し、ポイントオブケア検査プロセスの監督が可能にし、結果を監督を行う臨床検査部門システムに送信する。

520

臨床検査とポイントオブケア検査の核心的な相違:
ワークフローがポイントオブケアの検査結果セットを作成する分析検査から始まる場合、そして重大な分
析前後処理がない場合、このワークフローの分析部分は、Laboratory Point Of Care Testing統合プロファイル
内で取り扱われる。
他のすべてのケースでは、分析前後および分析ワークフローは、Laboratory Device Automation統合プロファ
イルが扱う。このLDAプロファイルでは、1つのオーダが開始するワークフローをサポートする。このオーダが、Order Placerレベルで発行されか。Order Fillerレベルで発行されたか、また分析装置がどこに設置されているか（ポイントオブケアか臨床検査部門か）は関わらない。

530

2.3 臨床検査レポートの共有
臨床検査テクニカルフレームワークが提供するコンテンツ統合プロファイルであるXD-LABにより、医療コミュニティで使用する文書共有リソース内で（医療施設内外の）臨床検査組織が結果レポートを電子文書として共有することが可能となる。

2.4 今後のデータ交換のための共通コードセット共有
3

これらのタームの正確な定義については、本 Volume の用語集を参照。
19

Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

540

複数のアクタが共有するコードセットの交換とそれに関連するルールは、Laboratory Code Set Distribution（LCSD）という専用の統合プロファイルが取り扱う。臨床検査テクニカルフレームワークでは、臨床検査用にLOINCコード化の使用を推奨している。またVolume 4ではこのコード化のサブセットを提案している。あるいは、SNOMEDなど他の国内あるいは国際的なコード化スキームをこのLAB-TF統合プロファイルに使用することも可能である。

2.5 臨床検査の専門分野

550

このLAB-TFは、微生物学、血液銀行検査（例：ABOグループ）などin-vitro検体検査を実施するほとんどの専門分野をカバーする。
解剖病理学はLAB-TFから除外する。この分野には専用テクニカルフレームワークとして病理学テクニカル
フレームワークを使用する。
血液銀行（血液製剤採取、保存、配送、管理）により実施される、輸血ワークフローもLAB-TFには含まな
い。

3
560

570

臨床検査統合プロファイル

IHE統合プロファイルは、医療施設の統合ニーズおよび情報システムの統合機能について、正確な用語で議論するために、医療専門家とベンダが使用できる共通言語を提供する。統合プロファイルでは、固有の医療ニーズに対応するため設計された標準の実装についての定義を行う。IHE臨床検査テクニカルフレームワ
ークの詳細な定義を参照することで、ユーザは自らが必要とするIHE機能を、ベンダは提供するIHE機能を正確に述べることができる。

統合プロファイルは、IHEアクタ、トランザクションとその内容により定義される。アクタ（LAB TF-1：
付録Aにまとめる）は、情報システムまたは情報システムのコンポーネントであり、医療面／作業面に関連する情報を生成、管理、操作する。トランザクション（LAB TF-1:付録Bにまとめられる）は、標準に基づいたメッセージを通して必要な情報をやり取りするアクタ間の相互作用である。

3.1 医療機関のワークフロー統合プロファイル
次の表に、臨床検査テクニカルフレームワークの各ワークフロー統合プロファイルと各プロファイルの相
互依存関係、およびITインフラテクニカルフレームワークの各統合プロファイルへの依存関係を示す。

20
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

セキュリティ
管理

患者情報診察管理

オーダ発行結果をケアで使用（病棟）

検体採取（ポイントオ
ブケア、病
室、ラボ）

ラボ
オーダ予約
と実行

自動化

Laboratory Testing Workflow (LTW)
臨床検査のオーダと実行、結果の配信、例外管理（誤認患者、オーダぬけなど）
Laboratory Code Set Distribution (LCSD)
他のワークフロープロファイルに参加しているアプリケーション
間のテストコードのマスターファイル共有
Laboratory Point Of Care Testing (LPOCT)
ポイントオブケアのin-vitro検体検査を臨床検査部門の全体的監視の下に実施。
Laboratory Specimen Barcode Labeling (LBL)
自動化した検体識別化処理
Laboratory
DeviceAutomation
(LDA)
分析処理と
前後処理の
自動化

Laboratory Scheduled Workflow (LSWF)
検査のオーダ、予約、実施、結果の配信
後方互換性のみの目的で保持Laboratory Information Reconciliation (LIR)
通常処理に対する例外を扱う（患者誤認、オーダ抜けなど）
後方互換性のみの目的で保持

図3-1: LAB-TF のワークフロー統合プロファイル

580

後方互換性のために保持された2つの統合プロファイル、LSWFおよびLIR（ライトグレーのボックス）を除き、LAB-TF統合プロファイル（白のボックス）では、ITI-TF統合プロファイルのPAMあるいはPDQを最新の患者基本情報および診察データを取得するために使用する。
LDAプロファイルはラボ内の自動装置を対象とする。
LTW、LPOCT、LBL、LCSDは、臨床検査部門、病棟、検体採取室（医療施設の専用室、病棟の一部、臨床検査部門の一部のいずれも可）の間で、十分に使用できる。

21
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

3.2 医療コミュニティのコンテンツ統合プロファイル

590

コンテンツ統合プロファイルでは、文書共有統合プロファイルのトランザクションで使用される、構造化されたコンテンツが定義される。各トランザクションは、2つのコンポーネント、つまり伝達される情報の主要部分であるペイロードと、そのペイロードについて記述するメタデータ、を有すると考えられる。コ
ンテンツをトランザクションへバインディング（結びつける）することにより、このペイロードがどのよ
うにトランザクションのメタデータに影響するが特定される。その後、コンテンツプロファイル内のコン
テンツモジュールがペイロードを定義する。コンテンツモジュールはトランザクションに中立である。つ
まりコンテンツモジュールが記述することは、それが使用されるトランザクションに依存しない。一方、コンテンツの結びつきにより、ペイロードがいかにトランザクションメタデータに影響するかが特定される。
以下の一覧表は、臨床検査テクニカルフレームワークの唯一のコンテンツ統合プロファイルと同プロファ
イルのITインフラテクニカルフレームワークの各統合プロファイルへの依存関係を示す。

Sharing Laboratory Reports (XD-LAB)
文書共有リソースに対し検査結果を電子文書として発行

図3-2: LAB-TFのコンテンツ統合プロファイル

22
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

600

臨床検査テクニカルフレームワークは、単一のコンテンツ統合プロファイルであるSharing Laboratory
Reports（XD-LAB）を提供する。これにより、文書共有リソースとともに、臨床検査結果レポートを共有することが可能になる。このプロファイルでは、臨床検査レポートのコンテンツは電子文書であると定義する。共有のオペレーション自体は、ITI-TF： XDS、XDMあるいはXDRのうち、任意の文書共有プロファ
イルのトランザクションが行う。

3.3 統合プロファイル間の依存関係

610

ある統合プロファイルを実装することが、別の統合プロファイルで定義される機能を達成するための前提である場合、IHE統合プロファイル間の依存関係が存在する。
LAB-TF統合プロファイルの依存関係を次の表に示す。LAB-TFのリリース2で非推奨とされたプロファイル
については、グレーの背景付きで表される
表3-1: 統合プロファイルの依存関係
依存対象

依存タイプ

目的

Laboratory
Testing Workflow(LTW)

統合プロファイル

ITI-TFのPAMあるいはPDQ

LTWの各アクタ、Order Placer、Order FillerおよびOrderResults Tracker は、以下のアクタの組み合わせのうち、少なくとも1つとグループ化されなければならない。
PA の Patient Demographics Supplier と Patient Encounter
Supplier。
PAM の Patient Demographics Consumer と Patient Encounter
Supplier。
PAM の Patient Demographics Consumer と Patient Encounter
Consumer。
PDQのPatient Demographics Consumer。

各アクタ、Order Placer、Order
FillerおよびOrder Results Trackerには、最新の患者データが、アクタが必要とする場合すぐに、提供されなければならない。提供された
データは、医療機関で使用可能なものである

Laboratory
Testing Workflow(LTW)

ITI-TFの Audit
Trail and Node
Authentication(ATNA)

Order Placer、Order Filler および Order Results Tracker
は、ANTA Secured Node アクタとグループ化されなければならない。

エクスポートされた PHIの監査証
跡、ノード認証および伝送の暗号化を管理するために必要。

Laboratory
Testing Workflow(LTW)

ITI-TF のConsistent
Time
(CT)

Order Placer、Order Filler および Order Results Tracker
は、ANTA Secured Node アクタとグループ化されなければならない。

複数の相反する更新を管理し、解決するために必要。

Laboratory Device
Automation(LDA)

LTW, LSWF

LDA プロファイルでAutomation Managerアクタを実装するシステムは、LTWおよびLSWF (1) プロファイルのAutomation Managerも実装しなければならない。

Automation Manager アクタが、LTW プロファイルで受信した検査オーダをLDAプロファイルで処理するためにステップオーダに分割する。

Laboratory Point Of
Care Testing(LPOCT)LTW

LPOCT プロファイルでOrder Filler アクタを実装するシス
テムは、LTWプロファイルのOrder Fillerアクタも実装しなければならない。

Order Filler が、ポイントオブケア
検査オーダを、他のオーダと同じ
レポジトリで保存し、両カテゴリからの結果をレポートする。

Laboratory Point Of
Care Testing(LPOCT)

ITI-TF のPAM
あるいは PDQ

LPOCT プロファイルの POCDM アクタは、以下のアクタの組み合わせのうち、少なくとも1つとグループ化されなければならない:
PAM の Patient Demographics Supplier と Patient Encounter
Supplier。
PAM の Patient Demographics Consumer と Patient Encounter
Supplier。
PAM の Patient Demographics Consumer と Patient Encounter
Consumer。
PDQ のPatient Demographics Consume

POCDMアクタが、ポイントオブケア検査の時に、患者IDをコントロールし、かつ当該の検査を実施
するスタッフが、正確に患者を確認することを可能にする責任を持つ。

23
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

統合プロファイル

依存対象

Laboratory Code Set
Distribution (LCSD)

なし

Laboratory Specimen
Barcode Labeling
(LBL)

LTW

Laboratory
Scheduled
Workflow（LSWF）

依存タイプ

目的

LBLプロファイルのLabel Information Providerアクタは、
LTWプロファイルの Order Filler あるいは Order Placer のいずれかとグループ化されなければならない。

LBLプロファイルのLIPアクタ
が、LTWプロファイルに送られたオーダあるいはオーダグループから検体のラベリングの指示を得る。

なし

Laboratory
Information
Reconciliation(LIR)

Laboratory
Scheduled
WorkflowおよびLaboratory
DeviceAutomation

このプロファイルは、LSWFとLDAプロファイルのアクタに適用されるユースケースと制約条件のセットである。

SharingLaboratory
Reports(XD-LAB)ITI-TFのCrossEnterprise
Document
Sharing(XDS)

XD*-LAB Contentプロファイルの実装者はXDSアフィニティドメイン内で臨床検査レポートを共有できるよう、XDS
プロファイルを実装することができる。XDSプロファイル
を文書交換のために使用される場合、Content Creatorは
XDS Document Sourceアクタとグループ化しなければならず、またContent Consumerは、XDS Document Consumer ア
クタとグループ化しなければならない。

XDSアフィニティドメイン内における臨床検査レポートの共有と他の種類の文書（画像、ECGなど）の共有とを共存させる。

SharingLaboratory
Reports(XD-LAB)ITI-TFのCrossEnterprise
Document
Sharing(XDS)

XD*-LAB Content プロファイルの実装者は、メディアを使用して臨床検査レポートを共有するために、XDM プロ
ファイルを実装することができる。XDM プロファイルを文書交換のために使用する場合、Content Creator は XDM
Portable Media Creator アクタとグループ化しなければならず、また Content Consumer は、XDM Portable Media
Consumer アクタとグループ化しなければならない。

メディアに記録された臨床検査レポートの共有と他の種類の文書（画像、ECGなど）の共有とを共存させる。

Sharing Laboratory
Reports (XD-LAB)

ITI-TFのCrossEnterprise
Document
Sharing(XDS)

XD*-LAB Content プロファイルの実装者は、信頼性の高い
Point-to-Point ネットワークメッセージを使用して臨床検査
レポートを共有するために、XDR プロファイルを実装することができる。XDR プロファイルを文書交換のために使用する場合、Content Creator は XDR
Document アクタとグループ化しなければならず、またContent Consumer は、XDR Document Recipient アクタとグ
ループ化しなければならない。

信頼性の高いPoint-to-Pointメッセージを通じた臨床検査レポートの共有と、他の種類の文書（画像、ECG など）の共有とを共存させる

Sharing Laboratory
Reports (XD-LAB)

ITI-TFのAudit
Trail and Node
Authentication(ATNA)

Content Creator と Content Consumer は、ANTA Secured
Node アクタとグループ化しなければならない。

エクスポートしたPHIの監査証
跡、ノード認証および伝送の暗号化を管理するため。

Sharing Laboratory
Reports (XD-LAB)

ITI-TFのConsistent Time(CT)

Content CreatorとContent Consumerは、CT Time Clientアクタとグループ化しなければならない。

複数の更新間の矛盾を管理し解決するため。

注(1)：Automation Managerアクタについては、LTW新規プロファイルと非推奨とされたLSWFプロファイルとの間で機能的な相違はない。

24
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

3.4 統合プロファイルの概要
620

3.4.1 Laboratory Testing Workflow（LTW）
LTWプロファイルでは、IDのある患者とIDがないまたは誤認された患者に対するIDのあるオーダとIDのな
いオーダに対し、医療施設内の臨床検査部門で実施した検査に関するワークフローを扱う。このプロファ
イルは後方互換性のみのためにLAB-TFリリース2に残された以前の2つのプロファイルであるLSWFおよび
LIRを置換する。

3.4.2 Laboratory Device Automation（LDA）

630

LDAプロファイルでは、Automation Managerと、検査プロセスに関連する臨床検査装置（分析前処理装置、分析装置、分析後処理装置）セットとの間のワークフローを扱う。

3.4.3 Laboratory Point Of Care Testing（LPOCT）
LPOCTプロファイルでは、医療機関の臨床検査部門の監督の下にポイントオブケアあるいは患者のベッドサイドで病棟のスタッフにより実施される臨床検査に関連するワークフローを扱う。

3.4.4 Laboratory Code Set Distribution（LCSD）

640

LCSDプロファイルでは、臨床検査部門のドメイン内（バッテリ、検査、検査結果コード）にコードセットを有するアプリケーションが、コードセットを他のアプリケーションと共有する方法を扱う。これは、ア
プリケーション間のデータ交換に対するサポートを強化することを目的とする。

3.4.5 Laboratory Specimen Barcode Labeling（LBL）
LBLプロファイルでは、1人の患者を対象とする既存のオーダあるいはオーダグループのための検体採取容器の自動ラベリングと配送のプロセスを扱う。

3.4.6 Laboratory Scheduled Workflow（LSWF） – 非推奨
650

LSWFプロファイルは、LAB-TFリリース2において、後方互換性のためのみに保持される。正確に識別された患者を対象とする既存オーダを遂行するため、臨床検査部門が実施する検査に関連する予約済みワー
クフローを扱う。

3.4.7 Laboratory Information Reconciliation（LIR） – 非推奨
LIRプロファイルは、LAB-TFリリース2においてのみ、後方互換性のためのみに保持される。患者が識別できない、あるいは誤認する、オーダが使用できない、などの例外的な状況下で、臨床検査部門が実施する検査に関連するワークフローを扱う。

25
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

660

3.4.8 Sharing Laboratory Reports（XD-LAB）
XD-LABプロファイルでは、ITI-TFで定義される文書共有プロファイルの1つを使用し、臨床検査レポート
を医療環境とケア提供者からなるコミュニティで共有される電子コンテンツとして定義する。

3.5 製品実装
3.5.1 一般ガイドライン
670

680

開発者には、製品にIHEアクタとトランザクションを実装する際にいくつかのオプションがある。決定には3つのクラスのオプションがある。

•

システムのクラスでは、組込むアクタを選択する。（1 つのシステムに対して複数のアクタが許可される。）•

各アクタに関しては、アクタが参加する統合プロファイルを選択する。

•

各アクタとプロファイルに対して、実装するオプションを選択する。

サポートされるプロファイルに対して、要件とされる全トランザクションが実装されなければならない。
（トランザクションの説明については、LAB-TF-2を参照。）
実装者は、その製品に組み込まれているIHEアクタ、IHE統合プロファイルとオプションを明記する宣言書を提供しなければならない。ITI-TF-1の付録Cに宣言書の推奨形式を示す。
一般に、製品には、任意の1つのアクタまたはアクタの組み合せを実装することができる。2つ以上のアクタがグループ化される場合は、それらの機能のサポートに必要な情報の流れが、アクタ間の内部通信により十分可能であることが前提である。このような内部通信の厳密なメカニズムは、IHEテクニカルフレーム
ワークの範囲外である。

690

複数のアクタが単一製品への実装でグループ化される場合は、サポートされる各アクタが開始または終了
する全トランザクションをサポートする必要がある（つまり、IHEトランザクションは外部製品インターフ
ェイスで提供する必要がある）。

3.5.2 LAB-TFにおけるHL7規格の使用
臨床検査テクニカルフレームワークでは、ほとんどのトランザクションとコンテンツモジュールでHL7相互運用規格を直接使用する。LPOCT統合プロファイルのみにCLSIのPOCT1-A規格に基づくトランザクショ
ンがある、POCT1-A規格もHL7規格を使用している

26
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

V2.5

Laboratory Device Automation (LDA)
Laboratory Point of Care Testing (LPOCT)
Laboratory Code Sets Distribution (LCSD)
Laboratory Barcode Labeling (LBL) 2007

CDA
R2

710

Sharing Laboratory Reports (XD-LAB)

コンテンツ

V3

検査コードのサブセット
LOINC

Laboratory Testing Workflow (LTW) 2007

ワークフロー700

図3-3: LAB-TFプロファイルで使用するHL7のバージョン

3.5.3 LAB-TFにおけるワークユニット間の関係
3.5.3.1 オーダグループあるいはLaboratory Request

720

オーダグループは一連のオーダであり、医師／病棟が1人の患者のためにまとめてオーダした複数のバッテリ／検査である。これらのバッテリ／検査は、1つまたは複数の臨床検査部門がその患者からの採取検体に実施される。オーダグループの同意語は「Laboratory Request」である。
オーダグループは必要に応じて、臨床検査各部門がオーダグループの中のサブセットを自らの専門と能力に応じて分担することができる。
オーダグループが存在する場合、Order Placer（OP）、Order Filler（OF）、Order Result Tracker（ORT）、
Automation Manager（AM）の各アクタ間のメッセージでは、「発行者グループ番号（Placer Group
Number）」（Order Placerアクタが割り当てる固有ID）で表示される。これらのアクタはすべて、このオーダグループあるいはその一部を処理するとき、この固有IDを記憶し、相互に送信するすべてのメッセージ
内に示すなければならない。

730

ある臨床検査レポートがオーダグループあるいはその一部の実行として作成されるときに文書共有リソー
ス内で共有する場合は、そのヘッダに発行者グループ番号が記される。これ作業はこのレポートを共有するContent Creatorアクタが担当する。このレポートを読むContent Consumerアクタは、このレポートに関連する発行者グループ番号の表示／統合を担当する。

3.5.3.2 オーダ
オーダとは、ある患者を対象に医師／病棟がオーダし、臨床検査部門が発行するバッテリあるいは検査である。このバッテリあるいは検査は、1つの臨床検査部門がその患者の採取検体に実施される。
740

バッテリあるいは検査が、医師がオーダするのではなく、臨床検査部門が発行する場合、リフレックスオ

27
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイルーダという。
LTWプロファイルの定義にあるように、オーダは臨床検査部門で予約されて実施される場合と予約なしに実施される場合がある。
また、LPOCTプロファイルにあるように、オーダはポイントオブケアでも実施される。

750

すべてのケースにおいて、病棟側のOrder Placerアクタにより、オーダに「発行者オーダ番号（Placer Order
Number）」という固有IDが割り当てられる。
Order Fillerアクタは、オーダを認識するとすぐ、「実施者オーダ番号（Filler Order Number）」という臨床検査部門の固有IDが割り当てられる。
オーダは、０または1つのオーダグループに属する。言い換えると、オーダはスタンドアロンオーダであるが1つのオーダグループに属す。

3.5.3.3 検査オーダ（Work Order）
760

検査オーダはLTWプロファイルで、1つあるいは複数の検体についてOrder FillerアクタからAutomation
Managerアクタに対し要求される1件のバッテリまたは検査である。Order Fillerであるアプリケーションが固有の検査オーダ番号を割り当てる。検査オーダは、０または1つのオーダグループに属する。

3.5.3.4 検査オーダ手順 （WOS）
検査オーダ手順は、検査オーダの構成要素で、Automation Manager（AM）が操作するLaboratory Device（LD）が1つの検体に対し実施するもので、Automation Managerアプリケーションにより、固有のWOS番号が割り当てられる。WOSは、０または1つの検査オーダに属する。

770

3.5.3.5 ワークフロープロファイルのアクタによるワークユニットの使用
以下の図では、どのアクタにより各ワークユニットが割り当てられているか、アクタ間のメッセージ内での各ワークユニットの範囲、そしてこのワークユニットのIDを伝達するHL7 V2.5フィールドが示される。

28
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

ワークフロー
アクタ

ワークユニット780

凡例：
OP が割り当て
OF が割り当て
790

AM が割り当て

図 3-4: ワークフロープロファイルのアクタが使用するワークユニット
注: Laboratory Code Set Distribution プロファイルはワークユニットを扱わないため、この図にはない。

3.5.3.6 XD-LABプロファイルのコンテンツモジュールにおけるワークユニットの配置
800

1つのCDAr2文書としての臨床検査レポートには、検査のユニットが2つだけ含まれる。これは以下の表に示すコンテンツモジュール内に配置される。
表3-2: XD-LAB 統合プロファイルのコンテンツモジュールにおけるワークユニット
CDA臨床検査レポート内の要素（所在Xパス）コンテンツ

ClinicalDocument/inFulfillmentOf/order/id

レポートがオーダグループを実行している場合の発行者グループ番号。レポートが単一のオーダを実行している場合の発行者オーダ番号。

ClinicalDocument/component/structuredBody/..
../section/entry/act/entryRelationship/../organizer@classCode=”BATTERY”/id

バッテリに割り当てられたオーダ実行者番号29
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

4

Laboratory Testing Workflow（LTW） - 臨床試験ワークフロー

4.1 範囲810

LTW統合プロファイルにより、医療施設内で、臨床検査および検査結果データの継続性および完全性が確立される。登録済みの患者と、未登録、あるいは誤認された患者を対象とする登録済みオーダと未登録オーダの両者に対し、医療施設の臨床検査部門が実施する検査のワークフローを扱う。
このプロファイルは、後方互換性のためのみに、LAB-TFリリース2で保持される、2つの過去のプロファイ
ル、LSWFおよびLIRを置換するものである。
このプロファイルに関連するトランザクションのセットは、オーダと患者情報の一貫性を維持し、検体の採取と受容をトラッキングし、そして臨床検査結果を多くの検証ステップへ送るためのものである

820

4.2 ユースケース
以下に示す3つのユースケースでは、Order Placer、Order Filler、Order Result Trackerの各アクタに、最新の患者基本情報および診察データが提供されることが前提となる。これは、各アクタを、ITI-TFのPAMあるいはPQDプロファイルの適切なアクタとグループ化することにより達成される。

4.2.1 登録済み検体を使用するオーダ
本シナリオの初期部分：当該ユースケースに限定

830

病棟の医師は、ある患者について、臨床検査（またはバッテリ）をリクエストする。オーダグルー
プ（あるいは単一のオーダ）が必要な関連情報とともに、Order Placerアプリケーションに入力される。
Order Placerは、検査実行にどのような検体が必要なのかを、採取条件（容器のタイプ、防腐剤/抗凝固、容量、時間および患者ステータス）や搬送条件とともに、判断する。
Order Placerは、固有の検体IDを記載した検体IDラベル（通常バーコード）および他の関連情報（患者名、診察IDなど）を供与する。病棟のスタッフは検体を採取し、容器に適切なラベルを貼付することで各検体を識別する。このユースケースでは、全検体に対して、施設全体の固有IDを確実に使用する、検体IDスキームが前提となる。検体IDのフォーマットと長さは、臨床検査組織および自動操作の制約条件に従わなくてはならない。

840

Order Placerが｢新規オーダ｣メッセージをOrder Fillerに送信すると、オーダグループ（あるいは単一のオーダ）が関連情報と一緒に送られる。
オーダが受信されると、Order Fillerアプリケーションにより、各オーダのコンテンツが検証され、受諾される場合、実施者オーダ番号が割り当てられ、Order Placerアプリケーションに返信される受領メッセージで、その番号が通知される。何らかの理由で、臨床検査部門がバッテリあるいは検査を受諾できない場合、相当するオーダは却下され、そのことがOrder Placerに通知される。

30
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

850

関連するオーダがOrder Fillerアプリケーションに受諾される前後に、臨床検査部門へ検体が送付される。物の流れ（検体／容器）とメッセージの流れの順序は医療機関によって異なる。
臨床検査部門のスタッフは、Order Fillerアプリケーションを使用して、各オーダを相当する検体とともに確認する。検体が利用可能で、かつ有効であれば、オーダが開始され、そのことがOrder
Placerアプリケーションに通知される。検体が無効または破損している場合（例えば、溶血血清d）、検体は却下され、それに依存するオーダは開始されない。
本シナリオの中間部分：3つのユースケースで共通

860

Order Fillerにより、オーダグループ（あるいは単一のオーダ）が1つあるいは複数の検査オーダに分割され、Automation Managerへ送信される。臨床検査部門の技術スタッフは、Automation
Managerとすべての正確な機器（分注機、ロボットシステム、分析機など）を使用して、種々の検査
オーダを遂行する。検体の分割（分注）により、子検体容器を識別するための（Order FillerまたはAutomation Managerが印刷する）追加ラベルが必要となる可能性がある。技術的な検証の後、結果がAutomation ManagerからOrder Fillerに送信される。
本シナリオの最終部分：3つのユースケースで共有

870（医療機関によるが）様々なステップで、Order FillerからOrder Result Trackerへ結果が送信され、また各オーダのすべてのステータス変化および関連する結果が、Order Placer、Order Result Tracker両者に通知される。

4.2.2. 外部登録機関が登録した検体を使用するオーダ
本シナリオの初期部分：

当該ユースケースに限定

病棟の医師が、ある患者の臨床検査（あるいはバッテリ）をリクエストする。オーダグループ（あるいは単一のオーダ）が、すべての関連情報とともに、Order Placerアプリケーションに入力される。
Order Placerは検体を識別しない。検体の識別と採取について、3種類のサブユースケースが考慮さ
れる。
880

1.
病棟で、患者ID、および発行者グループ番号あるいは発行者オーダ番号に限定したIDがラベル貼付された検体を、採取、提供する。「検体」はその後、Order Filler アプリケーションにより再識別され、そして処理のため、臨床検査部門のスタッフが、バーコードの検体IDを貼付する。

2.

臨床検査部門が検体採取および識別の責任を負う。

3.

必要な検体は、LBL統合プロファイルを使用することで、決定および識別される。

このユースケースの中間および最終部分は、4.2.1のユースケースと同様である。

31
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

4.2.3 臨床検査部門により作成される実施者オーダ
890

本シナリオの初期部分：

当該ユースケースに限定

2種類のサブユースケースが考慮される。
1.
臨床検査部門のスタッフが、Order Placerアプリケーションにアクセスできない病棟から、書面によるオーダを受領する。
2.
オーダグループの処理中に、臨床検査部門が当該のオーダグループに、新規のバッテリあるいは検査を追加することを決定。その新規オーダは、グループの既存検体の1つで実施される。

900

いずれのサブユースケースでも、作成されたオーダは実施者オーダ番号を持つ。Order Filler アプリケーシ
ョンにより、番号がOrder Placer アプリケーションに通知される。そこではOrder Placer アプリケーション
が、発行者オーダ番号を実施者オーダ番号に割り当て、かつOrder Fillerに返信する。
このユースケースの中間および最終部分は、4.2.1のユースケースと同様である

4.3 アクタとトランザクション
図4-1では、Laboratory Testing Workflow統合プロファイルに直接関連するアクタ、そしてアクタ間のトランザクションを示している。他の関連するプロファイルに参加しているため、間接的に関連している他のアクタはここでは示されていない。

910

図4-1: Laboratory Testing Workflowアクタ図表
32
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

表4-1では、Laboratory Testing Workflow 統合プロファイルに直接関連する各アクタのトランザクション、
そしてアクタ間のトランザクションが示されている。Laboratory Point Of Care TestingあるいはLaboratory
Specimen Barcode Labelingに参加しているため、間接的に関連している他のアクタは必ずしも示されていな
い。
表4-1: Laboratory Testing Workflow – アクタとトランザクション
アクタ

トランザクション

Order Placer
Order Filler

Automation Manager
Order Result Tracker

920

必須（R）/オプショナル（O）

Vol.2 内の節

Placer Order management [LAB-1]

R

LAB TF-2: 4

Filler Order Management[LAB-2]

R

LAB TF-2: 5

Placer Order management [LAB-1]

R

LAB TF-2: 4

Filler Order Management[LAB-2]

R

LAB TF-2: 5Order Results management [LAB-3]

R

LAB TF-2: 6

Work Order Management [LAB-4]

R

LAB TF-2: 7

Test Results Management [LAB-5]

R

LAB TF-2: 8

Work Order Management [LAB-4]

R

LAB TF-2: 7

Test Results Management [LAB-5]

R

LAB TF-2: 8

Order Results management [LAB-3]

R

LAB TF-2: 6

4.4 LTW統合プロファイルのオプショﾝ
この統合プロファイルのために選択可能なオプションを対応するアクタと表4-2に示す。
表4-2:
アクタ

オプション

Order Placerなし

Order Filler

なし

Order Result Tracker

なし

Automation Manager

なし

Vol.と節

4.5 プロセスフロー
930

プロセスフローが、以下のようなUMLシーケンス図で表される。（上から下へ時間の経過を示す）
下記の図の、ブルーのメッセージの流れ（Order FillerからOrder Placerへ通知されるオーダステータスの変更）は、Order PlacerとOrder Results Trackerのアプリケーションが異なる場合のみ発生する。
Order PlacerとOrder Results Trackerが同一のアプリケーションにグループ化されている場合は常に、ス
テータス変更および可能性のある新規の結果を伝達するLAB-3メッセージが、オーダの新規ステータスを当
該のアプリケーションに十分に伝える。この場合、LAB-1の｢オーダのステータス変更｣メッセージは重複する。
33
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

940

したがって、グループ化されたOrder Placer／Order Results Trackerとの交換の際、Order Fillerはトランザクシ
ョンLAB-1によってこのような（以下のすべての図においてブルーで印がつけられている）余分なメッセージを送信してはならない。

4.5.1 最初の2つのユースケースのLTW: 発行者（Placer）がオーダする
Image DisplayはImage Archiveに対し、スタディ、シリーズ、画像のインスタンスを呼び出すために、クエリする。

最初結果未確認

最終結果確認

図4-2: 発行者からのオーダのプロセスフロー
950

34
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

4.5.2 3番目のユースケースのLTW: 実施者（Filler）がオーダする：

最初結果未確認

最終結果確認

図4-3: 実施者からのオーダのプロセスフロー
注：

このユースケースでは、まずオーダがOrder Fillerサイドで、実施者オーダ番号付きで作成される。次いで、Order
Placerにより発行者オーダ番号が付与される。このステップを経ると、トランザクションLAB-2は、Order Placer、
Order Fillerの両者がオーダを認識する、という任務を実施する。このオーダに関するプロセスフローの残りの部分では、Order FillerとOrder Placerの間で、LAB-1のみが使用される

35
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

960

970

980

4.5.3 患者更新フロー
ここでは、分析プロセスのさまざまな段階で、患者情報の更新がシステムに取り入れられる状況を扱う。
3.3節の表3-1「統合プロファイルの依存関係」に示されたように、3つのアクタ、Order Placer、Order Filler
およびOrder Results Trackerは、ITI TFのPAM／PDQプロファイルの適切なアクタとグループ化される。このグループ化により、これら3つのアクタに、最新の患者基本情報および診察データが、いつでも確実に提供される。
これら3つのアクタは自らの患者データを、組み合わされたPAMあるいはPDQアクタが更新を通知されるとすぐに、自動的にかつ遅滞なく更新する。したがって、臨床検査部門のスタッフおよび病棟のスタッフが当該の患者に関連するオーダを検査している際、あるいはそのオーダの結果を調べている際、新しい患者データが利用できる。
逆にAutomation Managerアクタは、検査オーダのコンテクスト内でのみ、患者基本情報および診察データを受信する。
この患者データの一部（例えば、患者名の更新、患者IDの変更）が変更された場合、Order Fillerには常に、トランザクションLAB-4を使用して、当該の患者に関する処理中の全検査オーダについて、この更新をAutomation Managerに転送する責任がある。
当該の患者について、現在処理中の検査オーダが存在しない場合は、Automation Managerへ患者の更新が伝達されることはない。
したがって、臨床検査部門のスタッフにとっては、Automation Managerアプリケーションの検査オーダ内で、新たな患者データが利用できる。
図4-4では、このプロセスで発生する患者データの更新に関して、あるオーダのプロセスフローが示される。
｢患者データ更新｣とは、広義に理解されるべきものである。その中には、患者基本情報の更新（PAMプロ
ファイルのトリガイベント、A31あるいはA08）、患者IDの変更（PAMのA47）、2つの患者記録の統合（PAMのA40）、2つの患者記録のリンク付け（PAMのA24）、患者クラスの変更（PAMのA06およびA07）、転送（A02）あるいはそのキャンセル（A12）、患者アカウントの変更（A44）そしてその他のトリガイベントなどがありえる。

36
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

図4-4: ｢オーダ処理中の患者データ更新｣
990

Order FillerがAutomation Managerへ転送すべきイベントは少なくとも以下のものを含む。

•

患者情報の更新（A31 あるいは A08）•

患者の転送（A02）•

転送のキャンセル（A12）•

入院患者を外来患者に変更（A07）•

外来患者を入院患者に変更（A06）•

患者 ID の変更（A47）•

患者アカウントの移動（A44）•

患者の統合（A40）1000
これらがLAB-4の「検査オーダ更新」メッセージに、メッセージの患者関連のセグメントに入力された適切な新情報とともに反映される。検査オーダ番号は主要な情報であり、Automation Managerに使用され、正しい検査オーダにある患者の更新へ適用される

37
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

4.5.4 オーダと結果の更新とキャンセル

1010

オーダや検査オーダ、またアクタ内の結果の一部に対する更新、取消、ステータス変更は、関係する他のアクタにそのことを伝える適切なメッセージがトリガしなくてはならない。これらのメッセージは、トラ
ンザクションLAB-1、 LAB-3、LAB-4およびLAB-5でサポートされ、LAB TF-2で考察される。

4.5.5 オーダ入力前に実施される検査1020

状況によっては（夜間、臨床検査部門に出勤している技術者が実施する緊急の検査、臨床検査情報システム（LIS）アプリケーションが一時的に臨床情報システム（CIS）アプリケーションから切断されている、など）、検査はそのオーダがLISに送られる前に、Automation Managerとその分析装置で実施されることがある。結果は電話により、病棟のスタッフに伝えられる。
このような状況で、オーダがOrder Placerアプリケーションに最終的に入力され、かつLISアプリケーションに送られる場合、オーダと、予期される検査プロセスにより作成された既存の結果との整合性が確保されなければならない。整合性の確保は、予期される結果が使用される最新のシステムで行われるものとする。
• 臨 床検査 装置に よっ て得 られた 結果が Automation Manager のみに 伝え られた 場合、 Automation
Manager が、その結果を今後の検査オーダにリンクさせるユーザインターフェイスあるいは自動メカ
ニズムを提供しなければならない。LDA 統合プロファイルの 5.6.7 節を参照のこと。

•

Automation Manager から Order Filler へ、トランザクション LAB-5 を使用し、かつ検査オーダ番号なし
で、予期される検査結果がアップロードされた場合、Order Filler が、当該の未確定の結果を、のちにOrder Placer アプリケーションから受信するオーダへリンクさせる、ユーザインターフェイスおよび/あるいは自動メカニズムを提供しなければならない。

38
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5
1030

1040

Laboratory Device Automation （LDA） - 検査自動化システム

5.1 範囲IDA統合プロファイルでは、臨床検査機関の自動化された技術部門のための、ワークフローをサポートする。
LDA統合プロファイルでは、Automation Managerアプリケーション（例えば、LAS=臨床検査自動化システ
ム、あるいはLIS=臨床検査情報システム）と自動化されたLaboratory Devices（LD）のセットとの間のワー
クフローを扱う。これは、検査オーダを処理し、関連する検体で検査を実施し、そして結果を検索するためのものである。この処理には、検体の分析前処理（ソート、遠心分離、分注、搬送、開栓）、分析処理
自体（オーダされた検査を検体で実施）、そして分析後処理（閉栓、搬送、再検査、希釈、保存、検索）が含まれる。
LDAプロファイルでは、臨床検査部門のスタッフが操作するAutomation ManagerとLaboratory Devices（LD）との間のワークフローを厳密に示す。病棟のスタッフが操作する装置については、別のプロファイ
ルLPOCTでサポートするため、LDAの範囲外である。
Automation ManagerがOrder Fillerからの検査オーダを受信し、それを1つあるいは複数の検査ステップオー
ダ（WOS）のシーケンスに分割し、各ステップはアクタ（Pre/Post-processor、Analyzer）を実装する自動装置が担当する。

1050

WOSが単一の検体上で実施される。
LDAプロファイルでは、検体到着前にダウンロードされたステップオーダ、装置で検体が認識された後、クエリにより得られたステップオーダ。自動装置に手入力されたステップオーダなど様々な状況に対応する。
検体のロボット搬送を除き、電気的･機械的なインターフェイスを通じた自動装置の取り扱いについては示さない。ステップオーダ関連の情報、ステップオーダのステータスおよび得られた結果についてのみ述べ
る。

1060

検査オーダから発行されたWOSのシーケンスのうち、Analyzerに検査の実施を指示する特別なWOSは、分析ステップオーダ（AWOS）と呼ばれる。検体で実施されるシーケンスの他のWOSで検査結果を出さない
ものは検体処理ステップオーダ（SWOS）と呼ばれる。
AWOSを行うトランザクションは特定の検体に対する検査を実施するよう分析装置に指示を出すが、検査の方法については言及しない。分析装置の電気的･機械的な取り扱いについては、このプロファイルの範囲外である
検体に対するWOSが配信される前後に、検体が分析装置上に到着する可能性がある。いずれのケースでも、ステップが実施されるためには、装置が検体とWOS（指示）の両方を受領していなければならない。

1070

LDAプロファイルでは、Analyzerでの精度管理検体検査、およびAnalyzerからAutomation Managerへの精度
管理結果のアップロードについても示される。Analyzerは、患者検体AWOSと精度管理検体AWOSの両者を遂行することが可能である。Laboratory Testing Workflow プロファイルは、Automation ManagerからOrder39
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

Fillerへの精度管理結果のアップロードをサポートする。したがって、両プロファイルの組み合わせにより、
臨床検査情報システム上で、すべてのAnalyzerの精度管理結果を集中化させることが可能となる。
一部の状況では、（IDあるいは所在による）検体の認識あるいはWOSのコンテンツをLDユーザインターフ
ェイスに手入力することも可能である

1080

最初のIDは、Order Placer、Order FillerあるいはLabel Information Providerの、いずれかのアクタにより提供される。SWOSにより、分注機に子検体を準備するよう指示が出された場合、作成された各子検体に新しいバーコードラベルでコード化された新規IDが必要となる。これらのIDおよびラベルは、Automation
Manager、分注機あるいは外部機関が提供してもよい。ラベル発行のプロセスに関する手順の詳細について
はLDAプロファイルの範囲外であり、バーコードラベルが、この検体のWOSを実施するすべてのLDにより読み取り可能であること（例えばバーコードのフォーマットと長さ、ラベルのフォーマットなど）を推奨するのみである。
LDAプロファイルでは、LDはAutomation Managerへの検体到着の通知に関連して、WOSを受諾あるいは却下する能力があり、AnalyzerはAWOSのコンテンツを変更する能力を有する。これは、例えば、元の検査で得られた結果により、新規の検査を自動的に追加することなどである。

1090

検査結果のトラッキングとは、各アクタ（Analyzer、Automation Manager）が未加工の検査結果を精緻化、変換、あるいは解釈する前に保存する能力を意味している。この安全対策的保存の手順については、LDA
プロファイルでは扱わない。

5.2 ユースケース

1100

本節で定義する患者の検体検査についてのユースケースはすべて、Order FillerからAutomation Managerに送信される検査オーダで開始する。Automation Managerは、この検査オーダを、ステップオーダのシークエンスに分割し、そして臨床検査部門の自動手順に従い、LD（分注機、ロボットコンベア、分析装置など）での各ステップの予約を行う。
各WOSには、それを実施する対象装置により必要とされるすべての情報（検体容器の識別、検体情報、ターゲットID、実施すべき操作、予定時刻など）が含まれる。
分析ステップオーダ（AWOS）にはまた、実施すべき臨床検査のリスト、患者ID、入院・臨床情報、オーダ情報などが含まれている。検体情報には、ID、位置、検体のタイプ、容量、採取した日時、採取者のID、検体の分析前のステータス（例えば、「遠心分離済み」、「開栓済み」など）、を含むことが可能である。

1110

単一の検査（例えば、HbA1c）、あるいは一定の検査（血液培養、血算など）を実施するAnalyzerに関しては、AWOSは実施すべき検査を述べる必要はない。
基本的に、1つのステップオーダは単一の検体に関連づける。検体（親検体あるいは子検体）は通常、検体容器に貼付されたバーコードラベルに印刷された固有IDにより識別される。
臨床検査部門の技術スタッフは、Automation Managerを使用し、必要なすべてのLDを操作し、様々なWOSを監督する。技術スタッフは、Automation Managerで結果の技術的検証を実施し、そして当該の結果は40
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

Automation ManagerがOrder Fillerに返信する。

1120

検体が破損あるいは紛失した場合、Automation Managerは代替の検体が到着するまで検査オーダを延期ある
いはキャンセルする。本節では、精度管理検査の2つのユースケースも示す。

5.2.1 検体到着前にWOSがLDにダウンロードされるケース
本シナリオの初期部分：

a)

1130

Automation Managerが予約済みWOSをLDへ送信する。一部のLDにおいては、多くのWOSを単一の検査リストにグループ化することが可能である。この検査リストは、LDへ送信される単一のメッセージ内へダウンロードされる。しかしその場合でも、検査リストのWOSの各部分は、単一の検体と関連付けられる。

b) LDにより、（バーコードIDのスキャニング、容器内の位置の識別、手入力で）検体が認識され、LDのメモリから関連するWOSが選択される。

c)

オプションとして、その後、LDからAutomation Managerに｢検体到着｣の通知を送信してもよい。

本シナリオの最終部分：r） LDが当該の検体についてのWOSを実施する。
s） 実施されている検査のステータスについて、LDがAutomation Managerに通知を行う。AnalyzerのAWOSについては、この通知メッセージに実施された臨床検査の結果とステータスを含める。
1140

例外処理：
検体が認識される時刻までに、WOSがダウンロードされていない場合はいくつかのイベントを発生させることができるが、イベントはLD自体の機能およびオペレータの動作により異なる。LDがこの検体をスキップするか、検査プロセスを延期して未着のWOSがダウンロードされるのを待つか、LDからAutomation Managerに、当該の検体IDをクエリするか（第2のユースケース）、あるいはオペレータがWOSを手入力するか（第3のユースケース）、などである。

1150

WOSが最初にダウンロードされてから、LDにより検体が認識される間に、親オーダおよび検査オ
ーダのコンテンツが変更（一部検査の削除、他の検査の追加、ターゲットIDを他のIDへの変更）される可能性や、キャンセルされる可能性すら存在する。このようなイベントにより、Automation
Manager上のWOSが、キャンセルされたり、変更されたりする結果となる。そのため、Automation
Managerはこの変更あるいはキャンセルを伝えるメッセージをLDへ送信しなければならない。

41
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.2.2 LDへの検体到着時にWOSをクエリするケース
本シナリオの初期部分：

a)
1160

Automation ManagerがWOSの予約を行うが、それをLDに送信しない。

b) Automation Managerが検査オーダの更新あるいはキャンセルを受信する場合、Automation Managerは関連するWOSが適切に更新あるいはキャンセルし、必要な場合新規のWOSを作成する。

c)

LDは（バーコードのスキャニング、あるいは手入力で）検体を認識し、検体IDをAutomation
Managerへクエリする。

d) Automation Managerは実施すべきWOSを返信する。
本シナリオの最終部分：ユースケース5.2.1と同様
例外処理：

1170

このユースケースでは、LDが検体のステップを実施する準備が整っている場合、Automation Manager
はジャストインタイムで実施すべきステップについて送信する。そのため、｢WOSを更新｣および｢WOSをキャンセル｣のメッセージは必要ない。
Order FillerがAutomation Managerに検査オーダを送信する前に、またWOSがAutomation Managerに存在する以前に、検体がLDに送られる可能性がある。そのような場合、ステップc）のクエリは不成功に終わる。ステップd）で送信される回答は、｢検体は認識されていない、その検体について中断中の
WOSはない｣となる。そして、LDはこの検体をスキップし、後に新たにクエリが試みられるか、（とくに緊急のオーダの場合）オペレータがWOSをLDへ手入力する（第3のユースケース）。

1180

5.2.3 LDへWOSを手入力するケースa)

Automation ManagerがWOSの予約を実施、WOSはLDに必要とされるすべての関連情報とともに1枚の紙にプリントされる。

b) 臨床検査部門の技術スタッフは、その紙からWOSをLDに手入力する。
c) 検体認識に際し、LDが関連するWOSをピックアップ。
d) オプションとして、その後LDからAutomation Managerに、｢検体到着｣の通知を送信してもよい。
本シナリオの最終部分： ユースケース5.2.1と同様

1190

例外処理：
検体が認識される時刻までにWOSが入力されていない場合には、いくつかのイベントを発生させることができる。LDがこの検体をスキップするか、あるいは検査プロセスを延期して、オペレー
タがWOSを手入力するのを待つか、LDにより、デフォルトのWOSが実施されるかである。LDがAnalyzerである場合は、デフォルトのAWOSは、緊急検査のパネルの可能性があり、迅速に実施か
42
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

つ報告することができる。
WOSがAutomation Managerによりプリントされてから、それがLDで遂行される間に、親オーダおよび検査オーダのコンテンツが変更（一部検査の削除、他の検査の追加、ターゲットIDの他のIDへの変更）される可能性があり、あるいはキャンセルされる可能性すら存在する。このようなイベント
により、Automation Manager上のWOSが、キャンセルされたり、変更されたりする結果となる。こ
うした変更は、（Automation Managerのユーザインターフェイス上で、あるいは新たに修正された
WOSシートをプリントすることにより）オペレータに伝えられなければならない。オペレータは
続いて、LDのWOSを手入力で修正する。

1200

5.2.4 Analyzerによる再検査
1つのAWOSには、Analyzerによる通常1回の分析検査が必要である。一部の状況では、この初回の検査から得られた結果が、2回目の検査あるいは｢再検査｣によりコントロールされる必要がある。
1210

再検査の必要性は、以下の時点で決定することができる。
-

LDによる初回の検査が実施された直後、結果がAutomation Managerにアップロードされる前。

- Automation Managerアプリケーションによる、初回の検査結果を伴う検査オーダの技術的検証の間。
-

その後、Order Fillerアプリケーションによる、初回の検査結果を伴うオーダの臨床的検証の間。

したがって、3つのユースケースが考慮される。

5.2.4.1 初回の検査直後にAnalyzerで決定される再検査
1220

再検査の実施が、最初の検査後に自動的にあるいは手動で決定される。理由として以下が考えられる。
-

試薬の不足、ノズル詰まり、キャリブレーションの失敗など、Analyzerの問題により、検査結果が得られなかった。

-.検査結果が範囲を逸脱している。この場合、検体の自動希釈を伴う再検査が引き起こされる。

この再検査は、結果がAutomation Manager にアップロードされる前に行なわれる。最初の検査結果は存在しないか、あるいは不適切なものである。

1230

Automation Managerは、このAWOSのステータス変更（最初の検査は失敗、2回目の検査が予約済み）を通知される必要があるが、これはLDのオペレーションをトラッキングし、試薬の消費量を記録できるようにするためである。
前述の3つのシナリオに共通する最終部分が、以下のサブケースで示される。

本シナリオの最終部分:
a) LD（Analyzer）が当該の検体に対し、オーダされたステップを実施（初回の検査）。

b) 得られた結果を考慮し、2回目の検査が予約される。AWOSのステータスの変更（初回の検査失敗、
43
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2回目の検査が予約済み）が、AnalyzerからAutomation Managerに通知される。

c)
1240

適切な調整（希釈、試薬の補充、ノズルの洗浄、キャリブレーションなど）が行われた後に、Analyzerが2回目の検査を実施。

d) 2回目の検査結果とステータスが、AnalyzerからAutomation Managerに通知される。
5.2.4.2 Automation Managerによる技術的検証中に決定される再検査
初回の検査の結果について技術的検証が行われている間、正常値の範囲、患者の以前の検査結果および他の臨床情報、あるいはデータ変動（drifting）、検出された精度管理範囲よりの逸脱、などの技術的情報を比較して、コントロール（再検査）が決定される。この決定は、技術スタッフあるいはAutomation Manager
アプリケーションにより自動的に行われる。

1250

前述の3つのシナリオに共通する最終部分が、以下のサブケースで示される本シナリオの最終部分：r） Analyzerが当該の検体に対し、オーダされたステップを実施（初回の検査）。
s） このAWOSについての初回の検査結果とステータスが、AnalyzerがAutomation Managerに通知する。
t） Automation Managerは結果の技術的検証を実施し、結果、同一検体の同一検査項目が、新たに要求する。この新たな検査として、同一の分析装置あるいは（初回の検査で得られた結果を確認するために）別の分析装置での新たな検査が要求される可能性がある。

1260

再検査では、2回目の検査に選択されたAnalyzerの検査モードに対し、適切なシナリオがピックアップされる。
再検査のために選択されたAnalyzerがダウンロードモードで動作している場合は（少なくとも再検査用に）、
同一の検体および同一の検査項目について、新規のAWOSが、Automation ManagerからAnalyzerに送信される。これにより、新たに5.2.1のシナリオ（ステップa）が開始される。
Analyzerがクエリモードで動作している場合は、Automation Managerは新規のAWOSを予約し、そしてAnalyzerからのクエリを待つ。これにより、新たに5.2.2のシナリオ（ステップa）が開始される。

1270

Analyzerが手入力のみサポートしている場合は、Automation Managerにより予約済み再検査がプリントアウ
トされる。これにより、新たに5.2.3のシナリオ（ステップa）が開始される。
さらに、再検査により、選択されたAnalyzer以外に、LDにゆだねられる新規のSWOSが作成される可能性がある。以下は、その例の一部である。

-

新しい容器を使用して、分注機（Pre-Analyzer LD）が作成する必要のある新たな子検体に対し、再検査が予約される-

再検査で、検体を別のAnalyzerへ搬送する必要が生じる。これは、Post-Analyzerロボットコン

44
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

ベアと関連する。
1280

5.2.4.3 Order Fillerによる臨床的検証中に決定される再検査
オーダグループ全体の結果についての臨床的検証の間、正常値の範囲、患者の以前の検査結果および他の臨床情報、あるいはデータ変動（drifting）、検出された精度管理範囲よりの逸脱、などの技術的情報とともに、結果全体の臨床的一貫性を考慮して、コントロール（再検査）が決定される。この決定は、臨床検査部門の専門家により、あるいは専門家を支援する自動エキスパートシステムにより行われる。

1290

この状況では、前述の3つのシナリオの最終部分は正常に終了する。臨床的検証の後、Order Fillerにより同一患者、同一検体について新規の検査オーダが作成され、Automation Managerに、Analyzerのうち１つで、改めて予約を行うようリクエストがある。この新規の検査オーダにより、同時にオーダされた追加の検査が伝えられる可能性がある。それにより、新たな子検体が必要になるかもしれない。この種の再検査は、
前述の3つのシナリオによりサポートされ、説明される。

5.2.5 患者検体WOSのユースケースのサマリ
初期部分：
予約

中間部分：
前処理、分析

最終部分：
後処理

図5-1:患者検体WOSのLDAユースケース

45
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.2.6 分析装置により実施される精度管理
以下のユースケースでは、交換される全メッセージ内で、検体が「QC検体」の役割を果たす。
1300

5.2.6.1 Automation Managerによりダウンロードされた精度管理
a)

b)
c)
d)
1310

e)

Automation Managerにより、ある精度管理検体の検査セットに対し、Analyzerが実施する新規の精度管
理AWOSが（自動的に、あるいは技術者によりインタラクティブに）予約される。AWOSが（検体/容器IDあるいは特定の位置、および実施すべき検査が記されて）分析装置にダウンロードされる。
分析装置が（バーコードIDのスキャニングあるいは位置により）検体を認識し、関連するAWOSを検出し、検査を実施。
当該のAWOSについて得られた結果が、分析装置からAutomation Managerに送信される
Automation Managerは、自らの評価ルールをこれらの精度管理結果に適用し（結果が受諾される、あるいはコントロール範囲外となる、あるいは偏差傾向についての警告が出される）、そして結果を自らの精度管理データベースに保存する。
条件によっては、トランザクションLAB-5および精度管理検査のリフレックスオーダを使用して、精度管理結果をAutomation ManagerからOrder Fillerに転送してもよい。

5.2.6.2 Automation Managerに予約され、Analyzerにクエリされる精度管理
a)

1320

b)
c)
d)

e)

1330

ある精度管理検体の検査セットについて、Analyzerが実施する新規の精度管理AWOSが（自動的に、あるいは技術者によりインタラクティブに）、Automation Managerにより予約される。AWOSが（検体/容器ID、および実施すべき検査を記して）、分析装置に対し準備される。
分析装置が（バーコードIDのスキャニングにより）検体を認識、Automation Managerに検体/容器IDがクエリされる。Automation Managerにより、この「精度管理検体」に対する適切なAWOSが返信される。
分析装置により検査が実施され、当該のAWOSについて得られた結果がAutomation Managerに送信される。
Automation Managerは、自らの評価ルールをこれらの精度管理結果に適用し（結果が受諾される、あるいはコントロール範囲外となる、あるいは偏差傾向についての警告が出される）、そして結果を自らの精度管理データベースに保存する。
条件によっては、トランザクションLAB-5および精度管理検査のリフレックスオーダを使用して、精度管理結果をAutomation ManagerからOrder Fillerに転送してもよい。

5.2.6.3 Automation Managerにアップロードされる非要求型の精度管理結果
a)
b)
c)

d)

分析装置により、（位置により、および/あるいは必要な情報を手入力することで）検体が認識され、この検体について、あらかじめ設定された検査、あるいは手入力の検査が実施される。
リフレックスAWOSについて、分析装置からAutomation Managerに、結果が送信される。
Automation Managerは、自らの評価ルールをこれら非要求型の精度管理結果に適用し（結果が受諾される、あるいはコントロール範囲外となる、あるいは偏差傾向についての警告が出される）、そして結果を自らの精度管理データベースに保存する。
条件によっては、トランザクションLAB-5および精度管理検査のリフレックスオーダを使用して、精度管理結果をAutomation ManagerからOrder Fillerに転送してもよい。

46
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

1340

5.3 臨床検査部門におけるシステムの相互接続
前述のとおり、臨床検査部門では、オーダを遂行するためにOrder Filler（OF）アプリケーションが使用される。OFは、1つ以上のAutomation Manager（AM）の助力を得るか、あるいは得ないで、技術的オートメ
ーションを取り扱う。Automation Managerはそれぞれ、1つあるいは複数のLaboratory Devices（LD）を管理する。IHEアクタをサポートする臨床検査情報システム（LIS）、臨床検査自動化システム（LAS）、装置（Dev）は、様々な方法で相互接続されることが可能である。

1 レベルの LAS

2 レベルの LAS とシングルパス

2 レベルの LAS とマルチパス

図5-2: 臨床検査部門におけるシステムの相互接続

1350

システムに適切なアクタが実装されれば、これらの相互接続のアーキテクチャは、それぞれ有効である。
つまり以下のようになる。

0 または 1 レベルのLAS

2 レベルの LAS とシングルパス

2 レベルの LAS とマルチパス

図5-3：システムの相互接続をサポートするアクタのグループ化

47
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

多重経路検査オーダの管理については、Order Fillerアプリケーション内部の問題である。管理ルールについては、IHEでは説明されない

5.4 アクタとトランザクション

図5-4.Laboratory Device Automation アクタの図表

1360

表5-1は、LDAプロファイルに関連するそれぞれのアクタのトランザクションをまとめたものである。この統合プロファイルをサポートしていると言うためには、「R」で示される、アクタにより、必要条件とされるトランザクションが実行されなければならない。「O」で示されるトランザクションはオプションであり、以下の節5.5で説明されるプロファイルのオプションを定義する。
表5-1. LDA統合プロファイル - アクタとトランザクション
アクタ
Automation Manager

Analyzer

Pre/Post-processor

トランザクション

必須（R）/オプショナル（O）

Vol.2 内の節LAB-21 : WOS Download

R

LAB TF-2: 9

LAB-22 : WOS QueryR

LAB TF-2: 10

LAB-23 : AWOS Status Change

R

LAB TF-2: 11

LAB-26 : SWOS Status Change

O

LAB TF-2: 12

LAB-21 : WOS Download

O

LAB TF-2: 9

LAB-22 : WOS QueryO

LAB TF-2: 10

LAB-23 : AWOS Status Change

R

LAB TF-2: 11

LAB-21 : WOS Download

O

LAB TF-2: 9

LAB-22 : WOS QueryO

LAB TF-2: 10

LAB-26 : SWOS Status Change

R

LAB TF-2: 12

48
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.5 LDA統合プロファイルのオプション
この統合プロファイルのために選択可能なオプションを対応するアクタとともに表5-2に示す。
1370

表5-2 Laboratory Device Automation – アクタとオプション
アクタ
Automation Manager
Analyzer (1)オプション

Vol.と節Pre/Post-processorの管理
クエリモード WOS

ダウンロードモード WOS
Pre/Post-Processor(2)クエリモード WOS
ダウンロードモード WOS

Pre／Post-processorの管理：ある製品には、Analyzersに対するAWOS のみを管理する、Automation
Managerを実装することが可能であり、それゆえ、製品はトランザクションLAB-21、LAB-22、およびLAB23のみサポートする。ある製品が、Pre/Post-processorの管理オプションをサポートする場合は、その製品はまた、SWOSの管理および、Pre/Post-processorsとのトランザクションLAB-26のサポートを行わなければ
ならない。

1380

クエリモードWOS: このオプションを実装するAnalyzerは、トランザクションLAB-22をサポートしなければならない。
ダウンロードモードWOS：このオプションを実装するAnalyzerは、トランザクションLAB-21をサポートしなければならない。
クエリモードWOS：このオプションを実装するPre/Post-processorは、トランザクションLAB-22をサポートしなければならない。
ダウンロードモードWOS：このオプションを実装するPre/Post-processorは、トランザクションLAB-21をサ
ポートしなければならない。

1390

注1：

トランザクションLAB-21あるいはトランザクションLAB-22のいずれもサポートしないAnalyzerを実装する製品についても、LDA統合プロファイル適合であると言うことは可能である。それは、トランザクションLAB-23を使用して、結果をレポートすることのみが可能な、単一方向（one way）のAnalyzerである。

注2：

LAB-26. LDA統合プロファイル適合であると言うためには、Pre/Post-processorアクタを実装している製品は、必須のトランザクションLAB-26とともに、2つのトランザクションLAB-21およびLAB-22のうち、少なくとも1つをサポートしなければならない。

49
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

1400

5.6 プロセスフロー
これらのUMLシーケンス図表においては、プロセスフローの高度な観点が示される。各トランザクション
はトリガイベントとともに、1本の矢印で表されるが、トランザクションを構成する様々なメッセージの詳
細については示されない。各トランザクションのメッセージの流れと、個別のメッセージの説明については、Volume 2に示される。

5.6.1 ダウンロードモードで動作するすべてのLDによる検体の正常プロセス
このプロセスフローは、ユースケース5.2.1に基づく。

図5-5 ダウンロードモードでの正常プロセス1410
この図表では、1つの分析前装置、1つの分析装置、および1つの分析後装置を使用する状況が示される。

50
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.2 ダウンロードモードで動作するすべてのLDによるWOS更新
ユースケース5.2.1に基づくこのプロセスフローでは、自らのWOSの更新を引き起こす検査オーダの更新について示す。

図5-6 ダウンロードモードでのWOS更新

1420

Automation Managerは検査オーダの更新を受信すると、この更新を、この更新と関連のあるLDでステップ
オーダを完了していないものに対してのみ転送する。
節4.5.3で説明したとおり、検査オーダの更新は、患者情報の更新をダウンロードするために使用することが可能である。当該のWOSが完了していない場合、LDがWOSに含まれる患者情報の正確さと関係しており、かつ患者情報の更新を保存することが可能な場合、この患者情報更新のダウンロードは関連するWOS
内にあるLDに対して行われる

51
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.3 AWOSの手入力およびSWOSダウンロードによる正常プロセス
1430

このプロセスフローは、SWOSについてはユースケース5.2.1に、AWOSについてはユースケース5.2.3に基づく。Pre／Post-processor はダウンロードモードで動作しており、一方、Analyzer は、結果をレポートするためのトランザクションLAB-23のみサポートする、単一方向（one-way）のインターフェイスを有している。
図5-7 AWOS手入力による正常プロセス52
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.4 クエリモードで動作するすべてのLDによる検体の正常プロセス
このプロセスフローは、すべてのLDがクエリモードで動作している、ユースケース5.2.2に基づく

1440

図5-8 クエリモードでの正常プロセス

53
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.5 許容範囲を逸脱する結果による、Analyzerでの自動再検査
このプロセスフローは、サブユースケース5.2.4.1に基づく

図 5-9 初回の検査直後に決定された、Analyzerでの再検査

54
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.6 技術的検証の間、Automation Managerにリクエストされた再検査
1450

このプロセスフローは、サブユースケース5.2.4.2に基づく。

図5-10 技術的検証中、Automation Managerにより決定された再検査
2回目の検査のリクエストにより、Analyzer上の同一の検体に対して、新規のAWOSが作成される。この例
では、同様にPre/Post-processor に対して新規のSWOS が作成され、それに対して、2回目の検査のために検体の準備を行うようリクエストされる（分注、希釈、検索、分析装置への搬送など）

55
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.7 検査オーダ到着前に実施される緊急検査
1460

このプロセスフローは、セクション4.5.5で説明されたとおり、LTW統合プロファイルのOrder Fillerアクタとの組み合わせで、ユースケース5.2.3と関連付けられるユースケース5.2.2に基づく

図5-11 検査オーダ到着前に実施･使用される手入力の緊急AWOS

56
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

5.6.8 Automation Managerによりダウンロードされた精度管理
以下の図は、ユースケース5.2.6.1を示す。

図5-12 ダウンロードされた精度管理検査

5.6.9 Automation Managerに予約され、Analyzerにクエリされる精度管理
1470

以下の図は、ユースケース5.2.6.2を示す。

図5-13 クエリされた精度管理検査57
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6

Laboratory Point Of Care Testing （LPOCT） – 臨床ポイントオブケア検査

6.1 LPOCTのサマリ

1480

1490

1500

1510

状況によっては、臨床検査はポイントオブケア装置により、病棟のスタッフによりベッドサイドで、あるいは患者自身により簡単に実施されることがある。これらの組織では、病棟のスタッフに、検体の分析前の準備を必要としない、一般的な検査へ、直接アクセスすることを認めている。結果は即座に臨床的判断（clinical decision）に使用される。
病棟のポイントオブケア分析装置により、｢永続的｣あるいは一時的な接続を使用し、中央のPoint Of Care
Data Managerに、検査結果が送信される。
このプロファイルでは、医療施設の臨床検査部門による監督の下、ポイントオブケア検査が行われる組織について説明される。この監督には、POCTの結果の臨床的検証、精度管理（QC）サーベイランス、試薬の補充、病棟のスタッフに対し行われる、適切な検査の実践についての教育、が含まれる。
このプロファイルでは、ポイントオブケア検査が、ポイントオブケア分析装置を使用する病棟の医療スタッフの責任で行われ、このプロセスにいかなる臨床検査部門も関連しない組織も、サポートされることが可能である。こうした組織は、検査部門主導でない組織（non-laboratory led organizations）として示される（このプロファイルのサブセットが、これらの組織に適用されるであろう）。
臨床検査部門主導のニーズを満たすためには、ポイントオブケアで行われた患者の結果が、POCDMから
POCTプロセスを監督する臨床検査部門のOrder Filler アプリケーションに、転送されることが可能でなければならない。
このLPOCT プロファイルによりカバーされるワークフローは、選択された組織の種類、およびポイントケ
ア装置により使用される接続のタイプ（永続的あるいは一時的）に依存する。
LPOCT プロファイルでは、Laboratory Tesitng Workflowプロファイルで定義されるOrder Fillerアクタが使用され、新たに2つのアクタ、Point Of Care Result Generator（POCRG）および Point Of Care Data Manager（POCDM）が導入される。

6.2 LPOCTの範囲•

医療施設内の、あるいは医療施設管理下にある在宅医療におけるポイントオブケア検査。

•

ポイントオブケアを実施することができる臨床検査の全ての部門。

•

患者自身に対してではなく、検体に対して行われる検査。

•

重要な分析前のプロセス不要で短時間で実施される検査。

•

患者のベッドサイド、あるいはポイントオブケアで病棟のスタッフにより実施される検査。

•

ポイントオブケア装置により生成された検査結果、またはシステムへ手入力された検査結果、あるいはシステムにより計算された検査結果。

•

中央の Point Of Care Data Manager に永続的／一時的に接続されるポイントオブケア装置。

•

ポイントオブケア検査プロセス全般の監督。この監督には、精度管理サーベイランス、試薬管理、オペレータの証明および Point Of Care Data Manager への結果の集中化を含むことが可能である。

•

このプロファイルではこの監督を臨床検査部門の責任とすることが可能となっている。これには、全ての患者の結果を臨床検査情報システム（LIS）へアップロードすることが含まれる。
58

Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6.3 LPOCTの範囲外

1520

•

中央の Point Of Care Data Manager によるポイントオブケア装置のリモートコントロール（リモートコ
マンド）は、このプロファイルの範囲外である。

•

オペレータの識別のプロセスは、このプロファイルの範囲外である。

•

POCDM から臨床検査情報システム（LIS）への精度管理結果のアップロードについては、このプ
ロファイルの範囲外である。

•

POCT の検査結果のセットが Order Filler へ到着する際、これらの結果はすでにポイントオブケアのケ
ア提供者により使用されており、かつ POCDM により技術的に検証されていることが前提となる。これら 2 つの特質により、LPOCT プロファイルでは、検査結果の修正あるいはキャンセルは取り扱わない。

•

POCT の検査結果が病棟のスタッフあるいは医師により一度使用されると、このプロファイルでは以前のポイントオブケア検査結果のキャンセルあるいは修正は取り扱わない。ポイントオブケア装置による検体の 2 回目の検査では、新規の検査結果のセットが作成される。この 2 回目の検査･分析が実施されるのは、初回の結果が POCDM により却下されており、それゆえに Order Filler へ結果が送信されていないからである。

1530

6.4 ユースケース
以下の5つのユースケースは、このプロファイルのサマリにおいて言及した様々な組織および状況に対応する。

6.4.1 既存オーダ、患者ID、IDチェックとマッチする検査結果

1540

1550

このユースケースには、リアルタイムでの患者IDの確認が含まれる。これには、ポイントオブケア検査装置（POCRG）とPoint Of Care Data Manager（POCRG）との間が、永続的に接続されている必要がある。
当該のシナリオでは、検査に先立ち、Order Placerアプリケーションでポイントオブケア検査のオーダが作成される状況がカバーされる。しかし、オーダの番号は、POCRGに入力されることもなければ、あるいはPOCDMとOrder Fillerのいずれに送信されることもない。Order Fillerは、自らのデータベース内で既存のオーダを照合しなければならない
注1： オーダ番号がポイントオブケア装置に入力され、それがPOCDMに、次いでOrder Fillerへ転送されるユースケースは、
IHE LAB TFでは、Laboratory Testing Workflow 統合プロファイル、およびLaboratory Device Automation 統合プ
ロファイルによりサポートされる、予約済み臨床検査の正常のユースケースとみなされる。このユースケースのポイン
トオブケア装置は、離れた場所にあったとしても、臨床検査部門の分析装置であるとみなされる。このVolumeの節2.2を参照のこと。

本シナリオのパート1
医師が、ある患者に対するポイントオブケアをオーダする。このオーダはOrder Placer アプリケーションに入力され、発行者オーダ番号が割り当てられる。Laboratory Testing Workflowプロファイルの一部として、新規のポイントオブケアのオーダが、Order PlacerからOrder Fillerへ送信され、Order Fillerはオーダに実施者
オーダ番号を割り当て、ポイントオブケアの検査結果を待つ。

59
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

1560

本シナリオのパート2
このオーダを遂行するため、オペレータ（医師、看護師、患者）は患者から検体を採取し、それをポイン
トオブケア装置にセットする。オペレータは自身のID、患者/受診IDおよび検査に関連する全ての情報を提供し、操作を開始する。さらに、オペレータは、実施すべき検査のためのオーダがすでに存在するという、指標も入力する
本シナリオのパート3提供された情報を確認するため、また患者の氏名を入手するため、この情報がPOCRGからPOCDMに通知される。ポイントオブケア装置に返信されたこの患者の氏名が、オペレータが正しい患者／受診IDを入力したことを確認できるように、表示される。患者がPOCDMに認識されていない場合、あるいは他にエラーが発生した場合、オペレータは施設のポリシーに従う。例えば、オペレータは装置の患者IDをロックする。

1570

1580

1590

本シナリオのパート4
ポイントオブケア装置により検体の検査が実施され、結果が作成され、それがユーザに表示される。
「照合すべき既存のオーダあり」という指標を含む、検査結果のセットが、関連データとともにPOCRGからPOCDMに送信される。
POCDMは、自らのルール（正常値あるいは上下限値=scale limits、精度管理検査結果と結果を比較）と対照して受信した検査結果を確認し、結果を受諾し、保存し、そしてPOCRGに（結果を受諾したと）受領通知を送る。POCRGでは、POCDMから受信した知らせが表示される。POCDMにより、間違ったあるいは疑念のある結果が検出された場合は、結果が却下され、POCRGに対し受領拒否の通知が返信される。
本シナリオのパート5: – オーダ照合
検査結果のセットを受諾してから、POCDMはそれを、「照合すべき既存のオーダあり」という指標を伴い、Order Fillerへ転送する。
Order Fillerは、同一検査を含む、同一のオーダ提供者によりほぼ同時期に出された、同一の患者についてのポイントオブケア検査オーダを照合し、自身のデータベースで既存のオーダを検索する。Order Fillerにより、受信した検査結果のセットが、このオーダに保存される。Order Fillerが、データベースのいかなる
既存のオーダとも照合できない場合は、ユースケース5.5.2の通り、新規のオーダが作成される。
実施者オーダ番号を受領メッセージに入れて送信することで、検査結果のセットがOrder FillerからPOCDMに知らされる。
Laboratory Testing Workflowプロファイルの一部として、Order FillerからOrder Placerへ、POCTオーダの結果が到着したこと（オーダのステータス変更）が通知される。
本シナリオのパート6: 臨床的検証
後に、結果の臨床的検証が実施される。Laboratory Testing Workflowプロファイルでは、これにより当該の結果のOrder Result Trackerへの送信がトリガされ、｢オーダ完了｣の通知がOrder Placerに送信される。

6.4.2 オーダされていない検査結果 - 患者ID確認

1600

このユースケースには、リアルタイムでの患者IDの確認が含まれる。これには、ポイントオブケア検査装置（POCRG）とPoint Of Care Data Manager（POCDM）との間が、永続的に接続されている必要がある。検査はオーダが作成される前に実施される。オーダはPOCT検査結果が受信されると、自動的に臨床検査情報システム（LIS）により作成される。

60
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

本シナリオのパート1
オペレータ（医師、看護師）により、POCRGアクタが実装されているポイントオブケア装置に患者検体がセットされる。オペレータは自身のID、患者IDおよび検査に関連する全ての情報を提供し、操作を開始する。
本シナリオのパート2
ユースケース6.4.1のパート3と同様。

1610

1620

1630

本シナリオのパート3
ポイントオブケア装置により検体の検査が実施され、結果が作成され、それがユーザに表示される。検査
結果のセットが、関連データとともにPOCRGからPOCDMに送信される。POCDMは、自らのルール（正常値、上下限値=scale limits、精度検査結果と比較）と対照して受信した検査結果を確認し、結果を受諾し、保存し、そしてPOCRGに受領通知を送る。POCRGでは、POCDMから受信した受領通知が表示される。
POCDMにより、間違ったあるいは疑念のある結果が検出された場合は、結果が却下され、POCRGに対し受領拒否の知らせが返信される。
本シナリオのパート4: 臨床検査部門による監督 – オーダ作成
POCT検査結果のセットを受諾してから、POCDM はそれを、ポイントオブケア検査のプロセスを監督する、
臨床検査部門のOrder Fillerへ転送する。Order Fillerにより、受信した結果が、ただちに作成された新規の実
施者オーダに保存される。割り当てられた実施者オーダ番号を受領メッセージに入れて送信することで、検査結果のセットがOrder FillerからPOCDMに知らされる。
また、Laboratory Testing Workflowプロファイルにも関連しているので、Order FillerはOrder Placerから、トランザクションLAB-2を使用して、発行者オーダ番号を取得する。このトランザクションの間、Order
Placer アプリケーションにより、このポイントオブケア検査結果のセットのために、発行者オーダが作成され、割り当てられた発行者オーダ番号が返信される。認識されない患者の場合は、Order Fillerアプリケーションが整合性確保を担当する。
本シナリオのパート5: 臨床的検証
ユースケース6.4.1.のパート6と同様

6.4.3 一時的に接続されるPOCRG、臨床検査部門による監督 -オーダ作成
これは、シナリオ6.4.2の変形で、医療施設のネットワークに一時的に接続されるPOCT装置に適合する。このような設定では、検査はリアルタイムでの患者IDの確認を行うことなく、オフラインで実施される。
本シナリオのパート1
ユースケース6.4.2のパート1と同様。

1640

本シナリオのパート2
POCRGにより、検体の検査が実施され、その結果は、作成され、自らのルール（正常値など）と対照して承認され、表示され、そしてメモリに保存される。
本シナリオのパート3

The POCRG displays the acknowledgment received from the POCDM. 後に、POCDMとの接続が確立された際に（例えば、ポイントオブケア装置がドッキングステーションにプラグオンされた時）、POCRGに
61
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

より、メモリに蓄積されたPOCT検査結果がすべて送信される。
POCDMにより、検査結果のセットが受信され、患者IDを含む情報が確認され、保存され、そして受領通知がPOCRGに送られる。
POCRGにより、POCDMから受信した受領通知が表示される
1650

本シナリオのパート4および5
シナリオ6.4.2と同様。

6.4.4 ポイントオブケア検査結果の手入力-オーダ作成
一部のポイントオブケア検査結果（例えば、一般尿検査）は、人が読み取り手入力される。このシナリオ
は、このようなPOCT検査結果が、POCDMアクタを実装しているシステムに直接、手入力される時にふさわしい。このケースにおいては、POCDMアクタとグループ化された、中央のPOCTシステムが、ポイント
オブケア検査結果の手入力専用のPOCRGアクタをサポートする。
1660

本シナリオのパート1
看護師が、（POCDMとグループ化される）POCRGで自らを識別し、患者IDを入力する。（POCDMとグループ化される）POCRGにより、患者IDが確認され、オペレータが患者IDを確認できるように、患者のすべてのIDおよび受診情報が表示される。
オペレータが、POCRGに検査結果を入力する。POCDMが、検査結果のセットを自らの設定ルールに対照してコントロールし、それを却下するか、あるいは受諾し、そして受諾の場合は保存する。
本シナリオのパート2および3
シナリオ6.4.2および6.4.3のパート4および5と同様。

1670

本シナリオのパート1
オペレータは、IDをPOCRGに入力しログインして、精度管理検体IDを入力（あるいはスキャニング）して、操作を開始する。
オペレータは、検体のタイプ、試薬ロット番号、実施すべき検査などの、必要な追加情報を入力する。

1680

6.4.5 POCRGによる精度管理検査

本シナリオのパート2
POCRGにより、精度管理検体の検査が実施され、結果が作成される。
POCRGが永続的な接続を有している場合、あるいはPOCDMとの次の接続が確立された場合、精度管理検査結果のセットが、POCRGからPOCDMへ送信される。
POCDMにより検査結果のセットが受信され、自らの設定ルールと対照して確認が行われ、保存され、そして受領通知がPOCRGへ送られる。
精度管理検査結果の確認が失敗に終わると、POCDMおよびPOCRGは、単に「QC失敗」と表示して結果を秘密にし、オペレータが正確な処置を実施し、精度管理検査を再開するまで、今後この装置が患者検体の処理を行うことを阻止してもよい。

62
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6.5 アクタとトランザクション

患者検体テス
トの開始点

結果セット

結果セット了承

図6-1 Laboratory Point Of Care Testingアクタの図表

1690

表6-1は、LPOCT プロファイルに直接関連するそれぞれのアクタのトランザクションをまとめたものである。この統合プロファイルをサポートしていると言うためには、「R」で示される、アクタにより、必要条件とされるトランザクションが実行されなければならない。「O」で示されるトランザクションはオプションである。この統合プロファイルで定義され、アクタがサポートすることを選択できるオプションの全リ
ストは、以下のセクション6.6に示す。

表6-1. LPOCT統合プロファイル – アクタとトランザクション
アクタ

トランザクション

必須（R）/オプショナル（O）

Vol.2 内の節

Order Filler

Transaction LAB-32

R

LAB TF-2: 15

Point of Care Manager

Transaction LAB-30

O（注 3２を参照）

LAB TF-2: 13

Transaction LAB-31

R

LAB TF-2: 14

Transaction LAB-32

R

LAB TF-2: 15

Transaction LAB-30

O（注 3２を参照）

LAB TF-2: 13

Transaction LAB-31

R

LAB TF-2: 14

Order Result Tracker

注3： トランザクションLAB-30が、｢患者ID確認｣オプションをサポートするPOCRGおよびPOCDMに対して必要とされる。セクション5.7を参照。

1700

63
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6.6 LPOCT統合プロファイルのオプション
この統合プロファイルのために選択可能なオプションを対応するアクタとともに表6-2に示す。必要に応じ、オプション間の依存関係を注に示す。
表6-2 Laboratory Point Of Care Testing – アクタとオプション
アクタ
Order Filler

1710

オプション

Vol.と節オプション定義なし

Point of Care Data Manager

患者 ID チェック

Point of Care Result Generator

患者 ID チェック

患者IDチェック：このオプションでは、POCRGアクタを実装するポイントオブケア装置と、POCDMアクタを実装する中央のPoint Of Care Data Managerとの間の、｢永続的な｣リンクを必要とする。この状況では、正しい患者/受信
IDがポイントオブケア装置に確実に入力（あるいはスキャン）されるために、患者検体の検査を実施する
前に、POCRGおよびPOCDMが患者ID確認にLAB-30を使用する。

64
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6.7 プロセスフロー
Laboratory Testing Workflowプロファイルに関連するアクタはグレーのボックスで示す。
1720

6.7.1 既存のオーダと照合される検査結果- 患者ID確認

図6-2: ユースケース6.4.1のプロセスフロー

6.7.2 患者ID確認をともなうオーダされていない検査結果

図6-3: ユースケース6.4.2のプロセスフロー

65
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6.7.3 一時的に接続されるPOCRG – オーダされていない検査結果

図6-4: ユースケース6.4.3のプロセスフロー

6.7.4 オーダされていないポイントオブケア検査結果の手入力

1730

図6-5: ユースケース6.4.4のプロセスフロー

66
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

6.7.5 POCRGによる精度管理検査

図 6-6: ユースケース6.4.5のプロセスフロー

67
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

7

Laboratory Specimen Barcode Labeling（LBL）－検体バーコードラベリング

7.1 範囲
1740

LBL統合プロファイルがサポートするワークフローは以下のとおりである。臨床検査部門の検査オーダに関連する検体採取のために、バーコードラベルであらかじめ識別された検体容器を搬送する。このロボット
システムは、他のシステム（病院情報システム=HIS、診療管理システム=CIS、ラボ情報システム=LIS）から患者、検査オーダ、検体データを受信し、必要な各検体および容器にラベルを発行する。ラベルには、検体IDのバーコードが記されており、そして他の情報もラベルに印刷されている可能性がある。
2つの新規のアクタ、Label Information Provider（LIP）およびLabel Broker（LB）が、このワークフロ
ーのサポートを行う。

1750

Label Brokerはラベル情報を受信し、ラベルを適切なオペレーションに搬送する。またLabel Brokerは、
このプロセスのステータスを通知することが可能である。Label Information Providerは通常、Laboratory Testing Workflow統合プロファイルのOrder Fillerおよび Order Placerとグループ化される。
Label Brokerは、ラベリングの指示を受動的に通知されることが可能である。あるいは、この指示を得る
ため、Label BrokerがLabel Information Providerにクエリを行うことが可能である。
このプロファイルでは、臨床検査部門ドメインの範囲で、検体容器のラベリングのみを取り扱う。他のドメイン内の、ラベリングのワークフローについては取り扱わない。

7.2 ユースケース
1760

このプロファイルでは、5つのユースケースを取り扱う。各ユースケースは、どのシステムが、ある特定の検査オーダに必要な検体および容器を算定する、ビジネスルールを実装しているかに依存する。

7.2.1 Order Placerとグループ化されるLIP（リクエストモード）
Label Information Providerは、Order Placerとグループ化され、ラベル情報を作成し、情報をLabel
Brokerに送信する。
d） Order Placerは検査オーダを作成し、このオーダに必要な容器および関連するバーコードラベルについて、計算する。
e） Order PlacerはOrder Fillerに対してオーダを出し、それをOrder Fillerが受諾する。
1770f） 予定の時刻に、Label Information ProviderはLabel Brokerに、ラベリングの指示を送信する。
g） Label Brokerが、バーコードラベル付きの容器を支給する。
h） そして、ラベルが貼り付けられた容器は検体採取に使用され、次いで検査のために臨床検査部門に送付される。

68
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

7.2.2 Order Fillerとグループ化されるLIP（リクエストモード）

1780

Label Information Providerは、Order Fillerとグループ化され、ラベル情報を作成し、情報をLabel
Brokerに送信する。
e） Order PlacerサイドあるいはOrder Fillerサイドで、検査オーダが作成される。
f） いずれのケースでも、Order Fillerがオーダを受領し、そして予定時刻に、オーダを予約し、このオーダに必要な容器および関連するバーコードラベルについて計算する。そして、Order FillerはLabel
Brokerに、ラベリングの指示を出す。
g） Label Brokerが、バーコードラベル付きの容器を支給する。
h） そして、ラベルが貼り付けられた容器は検体採取に使用され、次いで検査のために臨床検査部門に送付される。

1790

7.2.3 Order Placerとグループ化され、Order Fillerに情報を伝えられるLIP（リクエストモード）
Order Fillerがラベル情報を作成する。ラベル情報をLabel Brokerに送信するために、Label Information
ProviderはOrder Placerとグループ化される。
a） 検査オーダが、Order PlacerサイドあるいはOrder Fillerサイドで作成される。
b） Order Fillerがこのオーダが受諾し、また検体情報を作成し、Order Placerに確認メッセージを返信する。この確認メッセージで、検体情報が伝えられる。
c） 予定の時刻に、Order Placerとグループ化されたLabel Information Providerは、Label Brokerにラベリ
ングの指示を送信する。
d） Label Brokerが、バーコードラベル付きの容器を支給する。

1800e） そして、ラベルが貼り付けられた容器は検体採取に使用され、次いで検査のために臨床検査部門に送付される。

7.2.4 Order Placerとグループ化されるLIP（クエリモード）
Label Brokerが、Order Placerとグループ化されるLabel Information Providerからのラベル情報を、自らリクエストする。
a） 検査オーダが、Order PlacerサイドあるいはOrder Fillerサイドで作成される。
1810b） 患者が検体採取の場所に到着する。患者IDがLabel Brokerに入力（あるいはスキャン）される。これにより、当該の患者から採取される検体へのラベリングの指示を得るため、Label Broker からLabel Information Providerへのクエリが引き起こされる。
c） Order Placerとグループ化されたLabel Information Providerが、返信でラベリングの指示を出す。
d） Label Brokerが、バーコードラベル付きの容器を支給する。
e） そして、ラベルが貼り付けられた容器は検体採取に使用され、次いで検査のために臨床検査部門に
69
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル送付される。

7.2.5 Order Fillerとグループ化されるLIP（クエリモード）
1820

Label Brokerが、Order Fillerとグループ化されるLabel Information Providerからのラベル情報を、自らリクエストする。
a） 検査オーダが、Order PlacerサイドあるいはOrder Fillerサイドで作成される。
b） いずれのケースでも、Order Fillerがオーダを受領し、そして予定時刻に、オーダを予約し、このオーダに必要な容器および関連するバーコードラベルについて計算する。
c） 患者が検体採取の場所に到着する。患者IDがLabel Brokerに入力される。これにより、当該の患者から採取される検体へのラベリングの指示を得るため、Label BrokerからLabel Information Provider
へのクエリが引き起こされる。
d） Order Placerとグループ化されたLabel Information Providerが、返信でラベリングの指示を出す。
e） Label Brokerが、バーコードラベル付きの容器を支給する。

1830f） それから、ラベルが貼り付けられた容器は検体採取に使用され、次いで検査のために臨床検査部門に送付される。

7.3 アクタとトランザクション

図7-1: Laboratory Barcode Labelingアクタの図

70
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

表7-1. LBL統合プロファイル – アクタとトランザクション
アクタ

トランザクション

Label Information Provider
Label Broker

注1：

1840

必須（R）/オプショナル（O）

Vol.2 内の節Transaction LAB-61

R

LAB TF-2: 16

Transaction LAB-62

R

LAB TF-2: 17

Transaction LAB-61

R

LAB TF-2: 16

Transaction LAB-62

O（注 1）LAB TF-2: 17

Label Information Providerは、リクエストモードおよびクエリモードの、両者をサポートしなければならない。Label Brokerについては、リクエストモードは必須であるが、クエリモードはオプショナルである。トランザクションLAB-62にサポートされるクエリモードについては、ユースケース4および5に相当する

7.4 LBL統合プロファイルのオプション
表7-2 Laboratory Barcode Labeling – アクタとオプション
アクタ
Label Broker

オプション

Volと節

ラベリング指示のためのクエリ

ラベリング指示のためのクエリ:
クエリモードで動作しているLabel Brokerは、ユースケース4および5のワークフローをサポートするために、
トランザクションLAB-62を使用する。
1850

71
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

7.5 プロセスフロー
Laboratory Testing Workflow統合プロファイルのアクタはグレーのボックスで示す。

7.5.1 ユースケース7.2.1:Order Placerとグループ化されるLIP（リクエストモード）

時間内

図7-2: Order Placerとグループ化されるLIP（リクエストモード）

7.5.2 ユースケース7.2.2: Order Fillerとグループ化されるLIP（リクエストモード）

時間内

図7-3: Order Fillerとグループ化されるLIP（リクエストモード）
1860
72
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

7.5.3 ユースケース7.2.3: LIPがOrder Placerとグループ化され、Order Fillerが情報を伝える（リクエストモード）

時間内

図7-4: LIPがOrder Placerとグループ化され、Order Fillerが情報を伝える（リクエストモード）

7.5.4 ユースケース7.2.4: Order Placerとグループ化されるLIP（クエリモード）

患者が
検体採
取室に
到着

図7-5: Order Placerとグループ化されるLIP（クエリモード）

73
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

7.5.5 ユースケース7.2.5: Order Fillerとグループ化されるLIP（クエリモード）

患者が
検体採取室
へ到着

図7-6: Order Fillerとグループ化されるLIP（クエリモード）
1870

74
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

8

Laboratory Code Set Distribution （LCSD） - 検査コードセット配信

8.1 範囲
共通コードセットは、臨床検査部門のワークフロー環境で、複数のアプリケーションシステムにより、一般的に使用される。これら共通コードは、当該の場所に存在する様々なアプリケーション間で、同期化される必要がある。多くの実装では、1つのアプリケーションシステムがコードセットの作者（所有者）となる。コードセットを管理する責任については、異なるシステム間に分散することも可能である。
1880

このプロファイルでは、コードセット（バッテリ、検査および検査結果コード）の所有者に対して、コードセットを他のアプリケーションに送信する方法を提供する。

8.2 アクタとトランザクション
図8-1に、LCSD統合プロファイルに直接関連するアクタ、そしてアクタ間のトランザクションを示す。他の関連するプロファイルに参加しているため、間接的に関連している他のアクタはここでは示されない。

図8-1: Laboratory Code Set Distributionアクタの図

1890

表8-1は、LCSDプロファイルに直接関連するそれぞれのアクタのトランザクションをまとめたものである。
この統合プロファイルをサポートすると宣言するためには、「R」で示される、アクタは必須とされるトラ
ンザクションを実行しなければならない.
表8-1: Laboratory Code Set Distribution統合プロファイル – アクタとトランザクション
アクタ

トランザクション

必須（R）/オプショナル（O）

Vol.2 内の節

Code Set Master

Laboratory Code Set ManagementR

LAB TF-2: 18

Code Set Consumer

Laboratory Code Set ManagementR

LAB TF-2: 18

75
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

8.3 Laboratory Code Set Distribution統合プロファイルのオプション
LCSD プロファイルは、オプショナルのトランザクションの定義は行わない.

1900

8.4 プロセスフロー
Code Set Masterは、臨床検査部門のコードセット（バッテリ、検査および検査結果）を管理する。3つのユースケースがある。

1910

ユースケース1：コードセット全体が、加入者システムに送信される。これらのシステムでは、現在のコードセットを新規のコードセットに置き換えなければならない。コードを受信したシステムは、コードセッ
トから除去されたコードを、その後使用してはならない。除去されたコードは削除するべきではないが、後方互換性のために、無効であることを示すフラグをつけるべきである。新規に追加されたコードは、トランザクションで伝えられた発効日時から使用可能である。
ユースケース2：Code Set Masterが、単一のバッテリ、単一の検査、あるいは単一の検査結果を、追加、除去、あるいは変更する。コードセット全体が加入者システムに送信されるのではなく、変更点が記述されている部分のみが送信される。
ユースケース3：認識されていないコードを受信すると、受信者からCode Set Masterに対して、当該のコードに関する詳細全体についてクエリが行われる。
IHE 臨床検査テクニカルフレームワークでは、現在ユースケース1のみサポートしている。他のユースケー
スは、このプロファイルの今後のバージョンに追加される可能性がある。

1920

図8-2:Laboratory Code Set Distributionプロファイルの基本プロセスフロー76
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

9

Sharing Laboratory Reports（XD-LAB）

9.1 範囲このコンテンツ統合プロファイルは、文書共有リソースへ発行される電子的文書としての臨床検査レポー
トを取り扱う。例としては、ITI-TFで定義される文書共有プロファイルのうち1つを使用して、医療界で共有される、Electronic Health Record（EHR）あるいは Personal Health Record（PHR）などがある。
1930

このような電子的文書は、ある患者に対する1つあるいは複数の検査オーダを遂行する際に、臨床検査部門が作成する、公開可能な（releasable）結果のセットを含む。レポートは、人間にとって判読可能なフォー
マットで共有される。さらに、この電子的な臨床検査部門のレポートは、機械により判読可能なフォーマットで、検査結果を含まなければならない。これは、利用者（consumer）のデータベース内で検査結果を統合するためである。
取り扱い範囲は、解剖病理学をのぞく、すべての臨床検査分野である。
この統合プロファイルで定義される臨床検査レポートに対する人的な部分は、米国のCLIAおよびフランスのGBEAを含む、多くの国の臨床検査規則と互換性を有する。
このプロファイルで説明される機械により判読可能なフォーマットによる検査結果のセットを含む臨床検
査レポートは、適切にコンテンツが匿名化された、かつ患者IDが偽名化された、過去の結果の共有を目的として、使用することも可能である。これは共有の分散型臨床検査レポジトリを作成するためである。

1940

9.2 ユースケース
9.2.1 病院の医師がアフィニティドメインの患者記録をフィード

1950

病院に滞在中、患者 John Smith には数回の臨床検査オーダが行われた。退院の際、病院の医師は、臨床検査レポートを含む、様々な設備により作成された最重要レポートを選択する。そして多くの医療施設および1次ケア提供者により共有される（例えばXDSアフィニティドメインのような）医療情報交換システムに、
これらのレポートを個別に配信する。したがって後に、新規のケアが行われる際には、John Smithのケア提供者（例えば、彼のホームドクター）は、（例えばXDSアフィニティドメインのような）医療情報交換シ
ステムを通じて、彼の過去の臨床検査レポートにアクセスすることができる。
この例では、電子的な臨床検査レポートが、Order Result Tracker の役割を果たすシステムにより作成され、退院サマリを準備している医療スタッフのリクエストに応じて、外部の医療情報交換システムに送信され
る。
病院

ケア提供者

退院時

77
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

9.2.2 民間の臨床検査機関がアフィニティドメインの患者記録をフィード

1960

泌尿器感染症の疑いのある患者、Jane Smithが、ホームドクターから、CBC、尿の顕微鏡検査および培養のオーダとともに、市街地にある民間の臨床検査機関に送られる。Jane Smithは、尿検体を持って最寄りの臨
床検査機関へ入る。面会した採血専門医は彼女から静脈血検体を採取した後、彼女は臨床検査機関を出る。
この臨床検査機関では、（血液学および微生物学の）リクエストに応じた全検査が一緒にレポートされる。
2日後、臨床検査機関はJaneのホームドクターに書面でレポートを提出し（このユースケースの範囲外）、
同時に国レベルのElectronic Health Record（EHR）に、このレポートを電子的フォーマットで送信し、JaneSmithの記録をフィードする。
独立検査室

すべてのケア施設またはPHR

9.2.3 外来の医師がアフィニティドメインで臨床検査レポートを共有

1970

泌尿器感染症の疑いのある患者Jane Smithが、彼女の尿検体を採取し、それを尿の顕微鏡検査および培養のオーダとともに委託臨床検査機関へ送付した、ホームドクターの診察を受ける。臨床検査機関は、ホームドクターに検査結果を返信し（このユースケースの範囲外）、医師は結果をレビューし、Jane Smithに彼女の治療について通知する。Jane Smithのリクエストを受けた医師は、電子的フォーマットにより、Janeの個
人医療記録内でこの臨床検査レポートを共有する。

開業医
すべてのケア施設

78
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

9.2.4 民間臨床検査機関あるいは病院の臨床検査部門がレポートを組織的に共有
コミュニティあるいは病院の臨床検査部門が、レポートを（ある程度自動化して）組織的に地域の医療ネットワークと共有する。トリガイベントは、公表可能な臨床検査レポートを配布する決定であり、この時点でコピーが地域医療ネットワークのレポジトリへ送信される。
検査室

1980

すべてのケア施設またはPHR

9.2.5 退院時に作成･共有される累積レポート
ある患者の退院時に、病院の医師が、当該医療施設の1つあるいは複数の臨床検査部門が作成した、最重要な臨床検査結果を選択し、累積レポートを作成する。これは、多くの医療施設および1次ケア提供者が共有する医療情報交換システムに送信される。この累積レポートでは、1つあるいは複数のオーダグループに関連する検査結果が集められる。これは、例えば患者のホームドクターなど、Electronic Health Record（HER）にアクセスできる者すべてが使用できる。

病院

ケア提供者

注1：

退院サマリについてのコンテンツ統合プロファイルは、Patient Care Coordinationドメインにより構築される。このユースケースおよびユースケースにより伝えられる臨床検査の累積レポートは、Patient Care Coordination退院サマリが使用されない場面で使用することが意図されている。このユースケースは、多分野の完全な退院サマリを置き換えるものではない。
また臨床検査の累積レポートの本文の構成は、PCC退院サマリの臨床検査結果の節としても使用される候補ともなっている。

注2：

退院時以外に、臨床検査の累積レポートを作成することも可能である（例えば、多部門チームの会議あるいは患者の紹介
の際）

1990

9.3 国家プロジェクトとのリンク
79
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

9.3.1 イタリア
2000

イタリアは、臨床検査レポートを構築するためにCDA R2の実験を行った初の国家であった。2005年以来、TeleMed ESCAPE プロジェクトの実験が、ヴェネト地方で行われた。

9.3.2 米国

2010

米国では、American Health Information Community（AHIC）およびOffice of National Coordinator（ONC）が、大きな進歩である3つのユースケースから、「許可された機関がケアに必要な臨床検査結果に、患者中心主
義でアクセスするための、標準化され、幅広く使用できるセキュアなソリューションを展開すること｣を確認した。これは、｢ケア提供者による過去の臨床検査結果の検索｣を含むことで、さらに洗練される。このIHEのユースケースでは、臨床検査レポートがCDA文書内に含まれており、「XDS文書共有」がオンデマ
ンドで、レポジトリからレポートのクエリおよび検索を行うことが可能であるため、過去の臨床検査デー
タへのアクセスが確実になる。
このユースケースの一部では、米国ではEHR to Lab Information Communication Specification（ELINCS）との一致が必要であり、これには、結果をコード化するボキャブラリ（LOINCあるいはSNOMEDのサブセット）が含まれる。ELINCSでは、オーダリング提供者に返信する、かつ提供者のコントロール下にある、結果の伝達のみに焦点を当てている。ELINCSおよびIHEノースアメリカでは、彼らの取り組み（effort）を臨
床検査領域に加えることについて審議中である。

2020

2030

9.3.3 フランス
ユースケース、9.2.1、9.2.2、9.2.4および9.2.5では、国の個人記録であるDMP（Dossier Medical Personnel）
で、臨床検査レポートを共有するニーズをカバーしている。この患者個人記録は、文書志向（document
oriented）であり、中央の文書レポジトリおよびレジストリを使用することで、インフラの共有について
IHE XDSプロファイルに依存している。個人記録の固有のキーは、患者電子医療カードである「Carte
Vitale」を使用して認証される、本人の国の医療ID（NIS = Numero Identifiant de Sante）に基づく。患者は自らの記録と医療提供者からの記録へアクセスを管理する。医療提供者は専門電子カード（CPS）のX509証
明証を通じて身分を証明する。また患者はこのアクセス管理を、正式に宣言したホームドクター（medicin
traitant）に委任することができる。患者の記録に保存されている臨床検査レポートを含む医療文書には、文書を認証する医療提供者がX509証明証を使用して、デジタル署名を行う。
このプロファイルによる他の要件としては、癌のケースに焦点を当てる多分野のコラボレーションミーテ
ィングで、臨床検査レポートを共有することであり、National Institute of Cancer（INCA）が目指すもう1つの国家プロジェクトであるDCC（Dossier Communicant en Cancerologie）の要件とされている。

9.3.4 日本

2040

日本は、臨床検査レポートを直接共有するためのユースケースは有していない。代わりに日本は、現在同国で標準化されている、CDA R2に基づく「患者紹介文書（Patient Referral Document）」の「臨床検査結果
セクション｣として、このプロファイルで定義する臨床検査レポートの本文の構成内容を使用する可能性がある。

80
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

9.4 ワークフローメッセージングとのリンク
9.4.1 IHE Laboratory Scheduled WorkFlowとのリンク

2050

2060

以上のすべてのユースケースでは、一般的にオーダあるいはオーダグループが遂行された後、臨床検査レ
ポートの文書が作成され、そして文書共有リソースに配布される。それは通常、最終レポートである。しかし場合によっては、仮のレポートを共有することも可能である。すべてのケースで、臨床検査レポートの文書は、Laboratory Scheduled Workflowの臨床検査結果メッセージにより伝えられることはない。
以上のすべてのユースケースでは、臨床検査レポートの文書が、公表可能な結果のセットを使用して作成される。これは、仮のレポートあるいは最終レポートのいずれかである。このレポートの、追加の更新がサポートされなければならない（例えば、置換、非推奨など）。ユースケース9.2.2および9.2.4では、レポートは臨床検査スケジュール済みワークフローの間に、Order Fillerの役割を果たすラボ情報システム（LIS）により作成される。Content Creatorアクタは、Order Fillerアクタと組み合わされる。
ユースケース9.2.1および9.2.5では、レポートは臨床検査スケジュール済みワークフローの間に、OrderResult Trackerの役割を果たすアプリケーションにより作成される。Content Creatorアクタは、Order Result
Trackerアクタと組み合わされる。

9.5 XD*-LAB統合プロファイルのアクタとトランザクション
このセクションでは、他の2つのIHEテクニカルフレームワークを参照する。

•

IT インフラテクニカルフレームワーク•

患者ケア（PCC）テクニカルフレームワーク

どちらも以下のサイトで閲覧可能である。http://www.ihe.net/Technical_Framework/.

9.5.1 アクタとトランザクションの関係
2070

2080

このプロファイルには、2つのアクタが存在する。Content CreatorおよびContent Consumerである。
Content Creator
Content Creatorアクタは、コンテンツの作成およびContent Consumerへの送信を担当する。
Content Consumer Content Consumerアクタは、Content Creatorアクタが作成したコンテンツの、閲覧、インポート、あるいは他の処理に責任を担当する。
Content（すなわち、臨床検査レポート）は、Content Creatorにより作成され、そしてContent Consumerにより利用される。あるアクタから別のアクタへのコンテンツの共有あるいは送信は、以下で説明するIHEプロ
ファイルの適切な使用により取り扱われ、そしてこのプロファイルの範囲外である。Document Sourceある
いはPortable Media Creatorが、Content Creatorアクタを具体化することが可能である。Document Consumer、Document RecipientあるいはPortable Media Importerが、Content Consumerアクタを具体化することが可能である。
あるアクタから別のアクタへ臨床検査レポートあるいは更新を、共有または送信することは、XDS、XDMおよびXDRの各統合プロファイルとの適切なコンテンツ結合を使用することで取り扱われ、臨床検査テク
ニカルフレームワークのVolume 3で説明を行う。

81
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

コンテンツ

コンテンツ
共有

コンテンツ

図5.1-1 XD*-LABのアクタ

9.6 XD*-LAB統合プロファイルのオプション
2090

この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表5.2-1にまとめられている。必要に応じ、オプション間の依存関係が注に示されている。これらのオプションは下の表にまとめられており、かつ、表の右側の列に示されているとおり、Volume 3の節2.1に詳細が記されている。
表9-1 アクタとオプション
アクタ

オプション

Vol.と節
LAB
TF-3:
2.1.1
Contents Consumer
LAB TF-3: 2.1.2
LAB TF-3: 2.1.3
LAB TF-3: 2.1.4
注1： アクタは少なくともこれらのオプションのうち1つをサポートしなければならない。

表示オプション(1)
文書インポートオプション(1)節インポートオプション(1)
個別データインポートオプション(1)9.6.1 文書表示オプション

2100

本オプションでは、Contents Consumerが臨床検査レポートのアクセス、表示、管理するときの処理要件を定義する。レポートのコンテンツがContent Consumerアクタにより表示される場合、臨床検査レポートのContent Creatorアクタは、レポートの一貫性のある表示を保証するスタイルシートへのアクセスを提供しなければならない（PCC TF-2:5.4.1.1.2.1を参照）。
アクタは、このスタイルシートが存在する場合、これを使用して文書を表示することができなければならない。

9.6.2 文書インポートオプション
このオプションでは、Content Consumersが、アクセスを提供し、そして臨床検査レポート全体をインポー
トし、またそれを患者記録の一部として管理するための処理要件を定義する。

82
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2110

9.6.3 節のインポートオプション
このオプションでは、Content Consumersが、アクセスを提供し、そして臨床検査レポートの選択された節をインポートし、それを患者記録の一部として管理するための処理要件を定義する。

9.6.4 個別データのインポートオプション
このオプションでは、Content Consumersがアクセスを提供し、臨床検査レポートがら選択した部分の個別
データをインポートし、それを患者記録の一部として管理するための処理要件を定義する。
2120

9.7 XD-LAB の他の統合プロファイルへの依存関係

2130

ある統合プロファイルの実装が、別の統合プロファイルで定義された機能を達成するための前提条件である場合、IHE統合プロファイル間の依存関係が存在する。表5.3-1で、これらの依存関係を定義する。一部の依存関係では、あるプロファイルをサポートしているアクタが、別の統合プロファイルをサポートしている1つあるいは複数のアクタと、グループ化される必要がある。例えば、Sharing Laboratory Report（XDLAB）では、別々の参加アクタが、Cross-Enterprise Document Sharing（XDS）統合プロファイルをサポート
し、またそれらのアクタがAudit Trail and Node Authentication（ANTA）統合プロファイルの Secured Node
アクタとグループ化される必要がある。依存関係が存在するのは、患者のプライバシーの保護が不可欠の環境で適切に機能できるように、XD-LAB および XDS の各アクタが、患者ID情報交換を適切に監査する、
セキュアなコミュニケーションチャンネルをサポートしなければならないためである。
XD-LAB統合プロファイルの依存関係については、このVolumeの3.1節の表3-1に詳細が示される。

9.8 XDS、XDM、XDRのコンテンツ結合

2140

2150

医療界の情報共有のニーズに資する、調整されたインフラを有する医師のオフィスおよび病院で、臨床検査レポートの共有が行われることが期待される。いくつかのメカニズムが、IHEプロファイルによりサポートされる。
• レジストリ/レポジトリに基づくインフラが、IHE Cross-Enterprise Document Sharing（XDS）と、
Patient Identification（PIX と PDQ）および Notification of Availability of Documents（NAV）など、他のIHE 統合プロファイルで定義される。

•

メディアに基づくインフラが、IHE Cross-Enterprise Document Media Interchange（XDM）プロファイ
ルで定義される。

•

信頼性の高いメッセージングに基づくインフラが、IHE Cross-Enterprise Document Reliable Interchange（XDR）プロファイルで定義される。

•

これらのインフラすべてが、Consistent Time（CT）統合プロファイルおよび Audit Trail and Node
Authentication（ANTA）統合プロファイルの使用を通じて、セキュリティとプライバシーをサポートする。

これらのプロファイルのさらなる詳細については、IHE ITインフラテクニカルフレームワークを参照のこと。
83
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

このようなインフラが、このプロファイルで説明されるユースケースにより前提とされている。コンテン
ツの結合は、IHEのトランザクションで使用されるペイロードが、それらのトランザクションで送受信されるコンテンツに含まれるデータ要素に、どのように関連し、かつ/あるいは制約されるか、を説明する。
Sharing Laboratory Reportsプロファイルでは、1つの結合を適用するが、これはContent Creator が、IHE ITI
XDS、XDM あるいはXDR統合プロファイルとグループ化される場合に使用される。
コンテンツと結合については、IHE臨床検査テクニカルフレームワークのVolume. 3で詳細する。

84
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2160

10 Laboratory Scheduled Workflow（LSWF）－臨床検査予約済ワークフロー
LAB-TFの、revision 2 により、このプロファイルは非推奨とされ、後方互換性のためのみ保持される。
新規の実装では、このプロファイルに代わってLTWプロファイルをサポートしなければならない。

2170

Laboratory Scheduled Workflow 統合プロファイルでは、医療施設を通じた、臨床検査と検査結果のデータの継続性および完全性が確立される。これには、オーダと患者情報の一貫性を維持し、検体の妥当性を管理し、結果を様々な検証のステップへ送付するという一連のトランザクションが含まれる。これらのトラン
ザクションの一部は、IHE放射線科テクニカルフレームワークがすでに定義している。このプロファイルでは、臨床検査部門内の、分析前、分析および分析後の各プロセスの自動化が可能となる。

10.1 ユースケース
以下の3つのユースケースにおいては、ADT（Admission-Discharge-Transfer）アクタがOrder Placer、Order
FillerおよびOrder Result Trackerアクタを最新の患者情報とともに提供することが前提となる。アクタとトラ
ンザクションの全体的な概観については、図10.2-1を参照のこと。

10.1.1 IDのある検体へ外部発行されたオーダ
2180

2190

2200

本シナリオの初期部分、当該ユースケースにのみ適用：
医療部門の医師が、ある患者に対する臨床検査（或いはバッテリ）を指示する。すべての患者情報とともに、オーダがOrder Placer に入力される。臨床検査部門が確立した（Order Placerの辞書にある）規則を用いて、Order Placerが、検査を実施するために、採取（容器のタイプ、防腐剤／抗凝固、容量、時刻および患者のステータス）および搬送の条件とともに、どの検体が必要か判断する。Order Placerにより、検体IDラベルも提供されるが、これには固有検体ID（通常はバーコード）、発行者オーダID、患者ID（PID、氏名、受診番号）が含まれることが可能で、そしてこの検体に関連する、オーダされたバッテリを識別することも可能である。医療部門のスタッフは、検体を採取し、容器にラベルを貼り付けて各検体を識別し、Order
PlacerがOrder Fillerへオーダを送信したとおり臨床検査部門へ検体を送付する。物の流れ（検体）と、通信の流れ（オーダ）のシークエンスは、必ずしも同期する必要はない。それは医療施設による。臨床検査部
門のスタッフは、Order Fillerアプリケーションを使用して発行者オーダを開き、必要な検体すべてが使用可能で、かつオーダに適合しているかを確認する。そして必要に応じて、オーダを却下するか、修正つきで承認する。次いで、Order Fillerによりオーダが作成および予約され、そのことが、Order Placerに伝えられる。検体が破損しているか、あるいは紛失された場合、Order FillerがOrder Placer に新しい検体をリクエストする。リクエストされた検査のバッテリは、差し替え用の検体が到着するまで予約は行われない。
このユースケースにおいては、施設では、全検体を施設全体で固有に識別することを保証する、検体IDメカニズムが使用されなければならない。Order Placer アクタおよびOrder Filler アクタにより、臨床検査組
織およびAutomation Managers と互換性のある検体IDの構造について、合意がなされなければならない。たとえば、臨床検査部門の自動システムは、読み取ることが可能な検体ID番号の長さ、あるいはバーコード
ラベルのフォーマットに関して、機能に限界があるかもしれない。検体IDは、当該検体が存在する期間、最初から最後まで固有なものでなければならない。

85
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

本シナリオの中間部分、3つのユースケースで共有：
Order FillerはオーダをAutomation Managerへ送信する1つあるいは複数の検査オーダに分割する。
臨床検査部門の技術スタッフは、Automation Managerとすべての必要な機器（分注機、ロボットシ
ステム、分析機など）を使用して、種々の検査オーダを遂行する。検体の分割（分注）により、子検体
容器を識別するための（Order FillerまたはAutomation Managerにより印刷される）追加ラベルが必要となるかもしれない。技術スタッフにより作成された結果の技術的検証が行われ、そして
Automation Managerから、結果がOrder Fillerに返信される。臨床部門の専門家は、Order Filler アプ
リケーションを使用して、結果の臨床的検証を実施する。

2210

本シナリオの最終部分、3つのユースケースで共有：（医療機関によって異なるが）さまざまな段階において、Order FillerからOrder Result Tracker に結果が送信され、またオーダあるいは結果に関するすべてのステータス変更が、Order PlacerおよびOrder Result
Tracker両者に通知される。オーダおよび結果は、それぞれ最終ステータスを有する。最終ステータスは、｢完了｣、｢キャンセル｣、あるいは｢無効｣（すなわち、結果が発表されるが、後の段階で無効であると示される）のいずれかである。

2220

10.1.2 IDのない検体あるいは臨床検査部門に採取される検体のオーダ
本シナリオの初期部分、当該ユースケースにのみ適用：
臨床医が、ある患者に対する臨床検査を指示する。すべての患者情報とともに、オーダがOrder Placerアプ
リケーションに入力される。Order Placerには対応する検体がない。検体の識別および採取のために、3つのサブユースケースが考慮される。
3.

2230

4.
5.

臨床部門が、検体を採取し、かつ供給する。検体には、患者IDおよび発行者オーダIDに限定したIDが貼り付けられる。検体は続いてOrder Fillerにより再識別され、臨床検査部門のスタッフにより、処理のため、バーコード検体IDが貼り付けられる。
臨床検査部門が、検体の採取および識別に責任を持つ。この業務は、臨床検査部門の専門スタッフにより実施される 4。
臨床部門が、必要な検体およびラベルのリストを使用して、検体採取を行う。このリストは、（Order
Placerから受診した情報に基づき）Order Fillerが成され、臨床部門のスタッフに（たとえば、病棟にあるリモートプリンタなどで 5）配布したものである。

3つのサブケースすべてにおいて、検体は最終的にはOrder Fillerがラベルで識別する。ラベルには、以下の内容が含まれなければならない。
固有検体ID（通常、自動操作のためにバーコードを使用）

2240

オプションとして、以下のものを含むことが可能である。

4
5

このケースは、ヨーロッパ北部および米国によくある。
このユースケースは、カナダあるいはフランスの一部組織に見られる。医療部門のスタッフが Order Filler の要件に従がって、検体の採取および識別を実施する。
86

Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2250

実施者オーダID
患者ID
責任者のID （医療部門あるいは医師、データモデルErreur! Source du renvoi introuvable を参照）
オーダされたバッテリ
Order Placer IDなど
このユースケースの中間および最終部分は、ユースケース10.1.1と同じである。

10.1.3 外部機関あるいは臨床検査部門により識別される検体の実施者オーダ
本シナリオの初期部分、当該ユースケースにのみ適用：
2つのサブユースケースが考えられる。

2260

6. 臨床検査部門のスタッフが、Order Placer アプリケーションにアクセスできない医療部門から、書面によるオーダを受領する。
7.

オーダのグループの処理中に、臨床検査部門は当該グループに、新規オーダを追加することを決定。その新規オーダは、グループの既存検体の1つに対し実施される

いずれのサブケースにおいても、作成されたオーダは、実施者オーダ番号を持つ。Order Filler アプリケー
ションにより、実施者オーダがOrder Placer アプリケーションに通知される。そこでは、Order Placer アプ
リケーションにより、発行者オーダが作成され、発行者オーダ番号が Order Fillerに返信される。

2270

新規の検体（ある場合）は、Order Fillerが、適切なラベルで（バーコード検体ID、実施者オーダID、患者
ID）識別する。
このユースケースの中間および最終部分は、ユースケース10.1.1と同じである。以下の図で、3つのユースケースで重複するステップが示される。

87
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

初期部分

中間部分

最終部分

OF が AM と通信し、テストが実行される（cf 3.1.1）

OF が結果を
ORT に、ステータス
を OP に通信（cf 3.1.1）

ユースケース 3.1.1
登録検体に外部が発行したオーダ

ユースケース 3.1.2
未登録検体またはラボが採取する予定の検体に外部が発行した
オーダ

ユースケース 3.1.3
第三者登録またはラボが採取した検体に対する実施者オーダ

図10.1-1 3つのユースケースが重複している部分

10.2 アクタとトランザクション
2280

図10.2-1に、Laboratory Scheduled Workflow 関連するアクタ、そしてアクタ間のトランザクションを示す。
アクタADTにより開始されるトランザクション、”Patient registration [RAD-1]”および“Patient update [RAD12]” については、Radiology Scheduled Workflow において、すでに定義されている（放射線テクニカルフ
レームワークのVolume 1を参照）。これらの2つのトランザクションは、いかなる変更もなしに、ここで採用される。
LSWでは、[LAB-1]から[LAB-5]までの番号が振られた、5つの新規トランザクションが導入される。

88
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

図10.2-1： 臨床検査予約済みワークフロー図
2290
現在の文書では、Automation Manager と、分析機器あるいは他の装置との間のトランザクションについては定義されない。これらのトランザクションについては、この文書の将来のバージョンにおいて定義される予定である。現在のバージョンにおいては、Automation Managerは、分析プロセスに使用される自動装置
すべてをグループ化するアクタである。
以下にLaboratory Scheduled Workflowにより導入される新規トランザクションについての注を示す。

2300

LAB-1: Placer Order Management
このトランザクションには、オーダのライフサイクル管理のために、Order PlacerとOrder Filler との間で必要な全メッセージが含まれる。この主要な目的は、2つのアクタ間における、オーダの（目的コンテンツおよびステータス）を一貫してを維持することにある。
LAB-2: Filler Order Management
このトランザクションには、新規の実施者オーダを通知し、またそれを反映する発行者オーダを作成する
ために、Order Filler とOrder Placer との間で必要な全メッセージが含まれる。この主要な目的は、各実施
者オーダが1つの発行者オーダにより代表され、そしてそれぞれが、実施者オーダ番号と発行者オーダ番号を有することを、保証することにある。

2310

LAB-3: Order Result Management
このトランザクションにより、Order Filler から Order Result Tracker へ、検査結果およびオーダステータ
スの変更（すなわち、修正、キャンセル）が伝えられる。
LAB-4: Work Order Management
このトランザクションには、実施者オーダの検査のサブセットを含む検査オーダを実行するために、Order
Filler とAutomation Managerとの間で必要な全メッセージが含まれる。このトランザクションの主要な目的
89
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

は、検査をAutomation Manager へ配信し、またAutomation Managerに対して、患者およびオーダの更新を伝え続けることにある。
このトランザクションは、プッシュメカニズムに基づいており、クエリメカニズムは決して使用されない。
2320

LAB-5: Test Result Management
このトランザクションにより、Automation Manager からOrder Filler へ、技術的に検証された検査結果が伝えられる。
表10.2-1 Laboratory Scheduled Workflow アクタとトランザクション
アクタ

ADT
Order Placer

Order Filler

Automation Manager
Order Result Tracker

2330

トランザクション

必須（R）／
オプショナル（O）

Patient registration [RAD-1]
Patient update [RAD-12]
Patient registration [RAD-1]
Patient update [RAD-12]
Placer Order ｍanagement [LAB-1]
Filler Order Management [LAB-2]
Patient registration [RAD-1]
Patient update [RAD-12]
Placer Order management [LAB-1]
Filler Order Management [LAB-2]
Order result management [LAB-3]
Work order management [LAB-4]
Test result management [LAB-5]
Work order management [LAB-4]
Test result management [LAB-5]
Patient registration [RAD-1]
Patient update [RAD-12]
Order result management [LAB-3]

R
R
R
R
R
R
R
R
R
R
R*
R*
R
R
R
R
R
R

Vol2 の節
放射線科TF vol 2、4.12節
放射線科 TF vol 2、4.12 節
放射線科 TF vol 2、4.12 節
放射線科 TF vol 2、4.12 節臨床検査 TF vol 2、4 節臨床検査 TF vol 2、5 節
放射線科 TF vol 2、4.12 節
放射線科 TF vol 2、4.12 節臨床検査 TF vol 2、4 節臨床検査 TF vol 2、5 節臨床検査 TF vol 2、6 節臨床検査 TF vol 2、7 節臨床検査 TF vol 2、8 節臨床検査 TF vol 2、7 節臨床検査 TF vol 2、8 節
放射線科 TF vol 2、4.12 節
放射線科 TF vol 2、4.12 節臨床検査 TF vol 2、6 節

R*: 臨床情報システム（LIS）により、Order Filler アクタおよび Automation Manager アクタ、両者の機能がサポートされる場合は、トランザクション LAB-4 と LAB-5 は無関係である。しかし、これらのトラン
ザクションは、臨床検査部門に別のAutomation Manager が存在する場合、Order Filler によりサポートされなければならない。

10.3 Laboratory Scheduled Workflow 統合プロファイルのオプション
この統合プロファイルのために選択可能なオプションを対応するアクタとあわせ表3.4-1にまとめる。必要に応じ、オプション間の依存関係を注に示す。
表10.4-1

Laboratory Scheduled Workflow – アクタとオプション

アクタ

オプション

Vol＆節

なし

ADT
90
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

Order Placerなし

Order Filler

なし

Order Result Tracker

なし

Automation Manager

なし

2340

91
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

10.4 プロセスフロー
プロセスフローを、以下のUMLシーケンス図で示す。時間の流れは上から下の方向で示す。。

2350

これらの図においては、プロセスフローの高度な観点が示される。各トランザクションはトリガイベント
とともに、1本の矢印で現されるが、トランザクションを構成する様々なメッセージの詳細については示されない。たとえば、トランザクション[LAB-1]は、オーダの依頼とともに開始されるが、このトランザクシ
ョンのメッセージの流れは、オーダが完了、キャンセルあるいは無効となるまで続けられる。個別のメッ
セージについては表示されない。各トランザクションの詳細なメッセージの流れについては、Volume 2に示される。

10.4.1 最初の2つのユースケースに関するワークフロー: 発行者（Placer）がオーダする
図10.4-1は、ユースケース10.1.1および10.1.2の基本的なプロセスフローを示す。

図10.4-1 発行者オーダリングのプロセスフロー92
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2360

10.4.2 3番目のユースケース: 実施者オーダリング

図10.4-2 Filler Ordering （実施者オーダ）のプロセスフロー
注：

2370

この一般的なユースケースでは、まずオーダがOrder Fillerサイドで、実施者オーダ番号付きで作成される。そして次に、Order Placerにより発行者オーダ番号が付与される。このステップを経ると、トランザクション LAB-2
は、Order Placer、Order Fillerの両者がオーダを認識する、という任務を遂行する。次のステップでは、臨床検査部
門がオーダをスケジューリングし、そしてトランザクションLAB-1の最初のメッセージを通じて、この｢ステータス変更｣をOrder Placer に通知する。この特定のケースでは、トランザクションLAB-1が、Order Filler から Order Placer に対してメッセージが送信されることで開始される。それゆえ、図の”LAB-1”の矢は、Order Placer に向けられている。それでも、トランザクションLAB-1は、Placer Order Management 専用であり、それはオーダのプロセス終了まで、ちょうど「発行者オーダリング」プロセスフローにあるように、両者からのメッセージに関連しながら、続けられる。

93
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

10.4.3 患者更新のフロー
以下のケースでは、分析プロセスの様々なステップで、患者情報の更新がシステムに導入される状況がカバーされる。前述のフロー図のうち、影響のある部分のみが下で表示される。前述のワークフロー図に従って、次々に起きるステップすべてが進行する。

10.4.3.1 オーダ作成前の患者情報更新
2380

このケースでは、発行者オーダリングおよび実施者オーダリングに、等しく影響が与えられる。発行者オーダリングの例のみが（最初の2つのユースケースに相当して）、ここでは示される。

図10.4-3 発行者オーダリング前の患者更新

94
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

10.4.3.2 オーダ作成後の患者情報更新
このケースには、発行者オーダリングおよび実施者オーダリングが同様にかかわっている。ここでは（最初の2つのユースケースに対応して）、発行者オーダリングの例のみを示す。フローの最初の部分（患者登録およびトランザクション[RAD-1]）は、この図で示さない。

2390

図10.4-4： 発行者オーダにつづく患者更新注：上記の通り、Order Placer、Order FillerおよびOrder Result Tracker各アクタは、最新の患者情報とともに、ADTにより直接提供される。
Automation Managerは、トランザクションLAB-4のメッセージを使用して、Order Fillerからの患者の更新
情報を受信する。Order Fillerは患者の更新情報を受信すると、この患者に関連する検査オーダがAutomation Managerに対して伝えられている場合は、このメッセージをAutomation Managerに対して発行
する。

2400

新しい患者情報の整合性確保については、Order Placer、Order Result Tracker、Order Fillerが実行する。整合性確保は、当該の患者に関連する検査オーダが完了していない場合、Automation Managerでも行われる。

95
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

10.4.3.3 オーダ遂行後の患者情報更新
このケースには、発行者オーダリングおよび実施者オーダリングが同様にかかわっている。ここでは（最初の2つのユースケースに対応して）、発行者オーダリングの例のみを示す。フローの最初の部分（患者登録およびトランザクション[RAD-1]）は、この図で示さない。

図10.4-5オーダ遂行後の患者情報更新
注：2410

上記の通り、Order Placer、Order Filler および Order Result Tracker の各アクタは、最新の患者情報とともに、ADTにより直接提供される。
Automation Managerがこのオーダと患者についての検査を完了している場合は、患者の更新について知らされる必要はない。この患者に関連する新規の検査オーダが実施されている場合のみ、Automation
Managerは新たな患者情報を受信する。

96
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

10.4.4 オーダ／結果の更新、ステータス変更、キャンセル、例外

2420

オーダあるいは結果の更新フローは、たとえば、このVolumeで表されるトランザクションレベルなどの、高度な観点では明らかにはできない。オーダ／結果の更新専用の、特別なトランザクションは存在しない（患者更新のために、トランザクション[2]が存在するのとは異なる）。反対に、オーダ／結果更新のイベ
ントは、既存の最も包括的なトランザクションである[LAB-1]から[LAB-5]によって行われる。これらのオーダ／結果更新（およびオーダのキャンセル）イベントは、メッセージレベルで現れる。したがって、本件についてはVolume 2で、各トランザクションについての詳細な説明とともに考察する。
目的は不変である。アクタ内で、オーダあるいは結果に関わるあらゆる更新、キャンセル、ステータスの変更がある場合、このオーダと関連する他のアクタへこの更新を伝えるための、すべて適切なメッセージを発行しなくてはならない。この目的は、当該のオーダ／結果と相互作用するすべてのアクタ間のオーダ／結果の一貫性を維持するためである。

2430

同様の理由で、検体（すなわち、不適切、容器の紛失あるいは破損）あるいは指示（臨床検査部門により却下されたバッテリ）に関する例外の管理についても、トランザクションレベルでは起こらない（特別なトランザクションは存在しない）。したがって、その件についてはVolume 2で、各トランザクションについての詳細な説明とともに考察する。

97
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

11 Laboratory Information Reconciliation（LIR）－検査情報整合性確保

2440

LAB-TFのrevision 2では、このプロファイルは非推奨とされ、後方互換性のためのみ保持される。新規の実装では、このプロファイルに代わって、Laboratory Device Automationプロファイルとの組み合わせでLaboratory Testing Workflowプロファイルをサポートしなければならない。
LIRプロファイルは、LAB-TFの補遺として発行され、LAB-TFに統合される前に非推奨とされた。LIRプロ
ファイルでは基本的に、以下に示されるいくつかの追加のユースケースを提供する。

11.1 ユースケース
11.1.1 ADT（入院・退院・転送）システムで登録されるIDのない患者

2450

このユースケースでは、医療センターで誤認された、あるいは識別されない患者に関する、非常に一般的なケースへの、シンプルだが具体的なソリューションを追求する。このユースケースは、3.5.3（Laboratory
Scheduled Workflowを参照）のごく普通の拡張のため、以下のサブケースではもっとも重要なケースのみ説明する。
患者情報はオーダの重要な部分なので、このユースケースは、発行者オーダあるいは実施者オーダのいず
れかに関連する、2つの異なるシナリオに影響を与えることができる。
-Order Placerがオーダした臨床検査-Order Fillerでオーダした臨床検査

2460

11.1.1.1 Order Placer側がオーダする検査
本シナリオの初期部分
a）オペレータ（受付のスタッフ）が未登録患者あるいは誤認された患者をADTに登録する。
b）この情報が、Order Placer、Order Filler、Order Result Trackerへ送信される。
本シナリオの中間部分
c）オペレータ（病棟スタッフ）が、オーダをOrder Placerに入力する。
d）オーダが、Order Fillerに、そして結果として他の受信者、すなわちAutomation Managerに、そして必要な場合はLaboratory Devicesに転送される。

2470

本シナリオの最終部分e）オペレータ（受付のスタッフ）が、ADTで患者データを更新する。このプロセスの間、患者情報に関して以下のような場合がある。
…氏名、住所あるいは既知であるが誤っている他のデータの訂正が必要な場合。
⇒患者更新…以前に認識されていた患者として識別される場合。
⇒ソース患者IDおよびターゲット患者IDを統合する、あるいはリンク付ける。
f）この情報が、Order Placer、Order FillerおよびOrder Result Trackerに送信される。検体検査試験が終了していない場合、あるいは最終結果がまだ戻されていない場合、Order FillerはAutomation Managerに、当該患者の新たな詳細を送信しなければならない（LAB-4）。
98
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイルg）受信者は、更新/統合のリクエストを実行するか、あるいは単に記録を統合する必要がある。
2480

注1：

患者がOrder Fillerにより更新あるいは統合される場合、Automation Manager内部のルールに従い、Laboratory
Devicesに当該患者の新たな詳細が転送される。

11.1.1.2 Order Filler側がオーダする検査
このシナリオの初期部分および最終部分は、前述のユースケースと同様である。中間部分のみが独自に展開される。
本シナリオの中間部分
c） オペレータ（病棟スタッフ）が、オーダをOrder Fillerに入力する。
2490d） オーダがOrder Placerに送信され、Order Placerは発行者オーダ番号を返信する。またAutomation
Managerは、オーダ作成について知らされる。
注2：

患者がOrder Fillerにより更新あるいは統合される場合、Automation Manager内部のルールに従い、Laboratory
Devicesに当該患者の新たな詳細が転送される。

11.1.2 ADTシステムで登録されない患者
このユースケースでは、病棟のスタッフあるいはオーダエントリシステムのユーザが緊急分析を実施するために臨床検査リクエストを作成する必要があるが、患者がまだ登録されていない状況に対処する。この場合、当該患者のIDあるいは詳細のいずれも使用できないので、オーダは入力できない。
2500

11.1.2.1 Order Placer側がオーダする検査2510

異なる施設間、複数のドメイン間、あるいは別々の医療部門内で、情報共有のために患者参照情報（ID、
氏名、生年月日）を使用する必要がある場合、IHE LAB委員会では、ADTが作成する患者記録が常に存在することを前提としている。したがって、Order Placerは臨床検査のみに使用されるアクタではなく、複数のドメインで共有されるアクタであるため、Order Placerのオペレータが新規のローカル患者を登録することはできない。
このアプローチは、ADTが認識していない患者のIDあるいは詳細が、医療施設のシステム間に拡散するリ
スクを避けるものである。
この制限に則して作業を行うために、病棟のスタッフあるいは臨床検査部門のスタッフは、ADTアプリケーションを使用して患者記録を作成し、それからその記録を新規の臨床検査オーダ追加の際に使用できるようにしなければならない場合がある。

11.1.2.2 Order Fillerサイドでオーダされる検査

2520

このユースケースには、新規のローカル患者記録を作成することへの制限はない。このローカルIDは臨床検査に使用されるアクタ限定のものだからである。
施設の患者登録が、任意の時点でADTアクタから届くことがある。しかし、このことがワークフローへ及ぼす影響はない。なぜなら、結果がOrder Fillerに保存される際、あるいは臨床的検証の段階で、新規患者の詳細は、臨床検査部門のIDとの整合性が確保されるからである。
このケースでは、患者の詳細と実施者オーダとの整合性は、臨床検査部門内で確保される。
本シナリオの初期部分a） 未登録の患者の検体を検査しなければならない。

99
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイルb） 当該の患者がOrder Fillerで、ローカルIDを付与して登録される。
本シナリオの中間部分
c） オペレータ（臨床検査部門のスタッフ）が、検査オーダをOrder Fillerへ入力する。
d） 検査オーダが、Automation Managerへ送信される。
e） Automation Managerは、検査オーダを複数のステップオーダに分割しLaboratory Devicesすなわち
AnalyzersおよびPre／Post Processorsに送信する。
f） Analyzerが検査結果を返信する。
g） 結果がOrder Fillerへ返信される。
2530
本シナリオの最終部分h） 正確な患者の詳細が届いた後、臨床検査部門のスタッフ、あるいはエキスパートシステム（例えばラボ情報システム=LISなど）が、実施者オーダを正確な患者情報と照合する。このステップは、臨床的検証（ステップi）より前、あるいはそれと同時に行うことが可能である。
i） 臨床的検証が実施される。
j） 実施者オーダが、Filler Order Managementトランザクションを使用して、Order Placerへ送信される（LAB-2）。
k） 実施者オーダとその結果が、Order Result Trackerへ送信される（LAB-3）。
2540 注1：

2550

LAB-2（ステップj）およびLAB-3（ステップk）トランザクションは、臨床的検証の前に行なうことが可能であるが、患者とオーダが照合される前に行なうことはできない。このユースケースでは、非常に厳密な前提条件が設定される。それは、患者がADTにより登録され、そして臨床検査IDが正確に施設ID（ADT患者ID）と照合されない限り、Order PlacerあるいはOrder Result
Trackerに対するいかなるトランザクションも実施されない、というものである。

注2：

ローカルIDポリシーは、それに対して単独の責任を有する、臨床検査部門内で定義される。患者IDは、様々なステータスを有することが可能である。例えば、｢臨床検査部門で識別された（ローカル）｣、｢施設で識別された（有効）｣などのステータス、あるいは臨床検査部門の割当機関が決定するいかなるステータスも可能である。

注3：

臨床検査部門に識別された患者が、施設に識別された患者と（手入力であるいは自動的に）照合される場合、その際照合された患者についての以前の結果あるいはオーダを送信するかどうかは、臨床検査部門の決定に左右される。

注4：

ローカルなあるいは施設の、患者の整合性確保は、最終結果が作成された後に実施することが強く推奨される。この推奨では、新規の患者IDを、臨床検査部門の技術的アクタ（すなわち、Automation Manager、Laboratory Devices）に伝達する必要性は含んでおらず、また照合プロセスが不成功に終わった場合、LAB-4トランザクションを繰り返すことを回避している。

11.1.3 オーダ作成前に臨床検査装置で実施される検査
特に急を要する検体検査の典型的ケースである。臨床検査部門のシステムがアクティブな状態ではない場
合に、検査のリクエストが行われることが可能である。そのため、プロセスはLaboratory Devicesから、あるいは可能であればAutomation Managerから開始するべきである

100
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2560

11.1.3.1 分析装置から開始
本シナリオの初期部分
a） スキャンされた、あるいは手入力された検体IDとともに、検体が分析装置に設置される。
b） 技術者が検査を選択する。
本シナリオの中間部分
c） 分析装置は結果を処理し、Automation Managerに送信する。
d） Automation Managerは結果を、｢結果は検査オーダと照合されない｣とフラグ付けし、保存する。

2570

本シナリオの最終部分：下記の、節11.1.3.3参照。

11.1.3.2 Automation Managerから開始
本シナリオの初期部分a） 検査オーダが手入力で作成され、Automation Managerにより、｢非要求型の検査オーダ｣としてフラグ付けされる。
b） 検体がLaboratory Deviceに設置され、LDはWOSを要求するクエリを行うか（LAB-22）、あるいはAutomation ManagerがWOSをダウンロードするのを待つ（LAB-21）。

2580

本シナリオの中間部分
c） 分析装置は結果を処理し、Automation Managerに送信する。
d） Automation Managerは、手入力で作成された検査オーダ内で、結果を保存する。
本シナリオの最終部分: 下記の、節11.1.3.3参照。
注1：｢フラグ付け｣というタームは、特別な本物のフラグが、こうした検査オーダに対し作成されなければならないことを、必ずしも意味しない。むしろ、システムの規則により、ただ単に発行者オーダ番号をつけない、ということも可能である。最終的な目標は、この非要求型の検査オーダを、簡単に識別することにある。

11.1.3.3 本シナリオの最終部分
2590

2600

一度、Automation ManagerがLaboratory Devicesから結果を受信すると、最後の業務は技術的検証を実施し、それを臨床的検証のためにOrder Fillerに送信することである。これらの最終ステップは、通常のワークフ
ローに基づき、2つの異なる方法で実施することが可能である。1番目のアプローチでは、Automation
Managerを、Order Fillerからの事前の検査オーダがなければトランザクションを開始できない、受動的なアクタと見なす。2番目のアプローチでは、Automation Managerを、検査オーダが届いていなくても、Order
Fillerに実施者オーダを作成させることができる、能動的なアクタと見なす。
オプション：
1） Automation Managerが検査オーダを待つe） Order Fillerが、実施者オーダを予約し、Automation Managerに適切な検査オーダを作成する。
f） Automation Managerは、検査オーダを受信し、それをフラグ付けされて保存されている結果あるいは検査オーダと照合する。
g） Automation ManagerはOrder Fillerに、オーダ結果を送信する。Order FillerはLaboratory Scheduled
Workflow内のように、正常な方法で動作し、Order PlacerおよびOrder Result Trackerへ情報を伝達する。
注1： 実施者オーダが作成される方法（Order Placerにより、あるいは内部でOrder Fillerにより）は問題ではない。
いずれのケースでも、Order Fillerは取り扱うべき新規の検査オーダを有する。

101
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2610

2620

2） Automation Managerは、Order Fillerが発行した検査オーダへの参照情報がない結果を提出する。
e） Automation Managerは、シナリオの初期部分に基づく技術的検証を実施する。
非要求型の検査オーダが通常通り、技術的に検証される。
（｢結果は検査オーダと照合されない｣とフラグ付けされ）保存されている結果に適合す
る、新規の検査オーダが作成される。この検査オーダは検証され、そしてまた｢非要求型の検査オーダ｣としてフラグ付けされる。
f） Automation ManagerはOrder Fillerにオーダ結果を送信し、Order Fillerは結果がアクタ間で流通できるように、実施者オーダを作成する。この時点より、手続きはLaboratory Scheduled
Workflowプロファイルによる説明に倣って進行する。
注1：

このアプローチの帰結として、Automation ManagerからOrder FillerへのOULメッセージでは、OBR-2およびORC-2フィールドは伝達されない。

注2：

実施者オーダのうち1つが、受信した結果と照合できるか明らかにするために、既存の実施者オーダの予備確認をすること
が、Order Fillerにとっての良い実践となる。この実践により、不必要な実施者オーダの作成を回避することが可能になる。

注3：

患者情報が欠如しているために技術的検証が実施されない場合でも、Automation Managerは結果を提出する。これは、Order Fillerが技術的検証および臨床的検証を実施するためである。このケースでは、OULメッセージのPIDセグメントは空
である。

102
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

付録A: アクタの説明

2630

ADT： Admission Discharge and Transfer（入院･退院および転送）。患者基本情報および診察情報の追加および/あるいは更新、またこの情報の、Order Placer、Order Filler、Order Result Trackerへの配信に責任を持つシステム。このアクタは、放射線科テクニカルフレームワークより受け継がれたもので、非推奨のプロフ
ァイル、Laboratory Scheduled WorkflowおよびLaboratory Information Reconciliationのみに登場する。
Analyze： 自動化された機器であり、この機器を管理するAutomation Managerからのリクエストに応じ、生物検体の検査を実施する。Automation ManagerからAnalyzersに送信される、検体検査についての各リクエス
トは、分析ステップオーダ（AWOS）と呼ばれる。当該の機器は、作成された検査結果、および関連する
条件あるいはイベントを、Automation Managerに返信する。さらにAnalyzerは、自らをサーベイランスするために、精度管理検査を実施することも可能であり、そしてその精度管理検査結果を、Automation Managerに送信する。このアクタは、Laboratory Device Automationプロファイルに関連する。

2640

2650

2660

Automation Manager： 臨床検査部門の自動装置あるいはその一部を管理する、システムあるいはコンポーネント。自動装置には、自動あるいはロボット化された搬送システム、分析機器、そして自動遠心分離機、分注機、開栓装置、閉栓装置、ソータ、検体保存検索システムなどの分析前、分析後プロセス装置の、
統合あるいはインターフェイス化が含まれる。このアクタは、Order Fillerからの検査オーダを受信し、オーダされた検査の適切な装置での処理を管理し、技術的に検証された結果をOrder Fillerに返信する。このアクタは、単一の分析機器を管理するときのように、たとえ分析プロセスのわずかな部分を管理する場合
でも、重要視されなければならない。複数のAutomation Managersを、1つのOrder Fillerに関連付けることが可能である。このアクタは、Laboratory Testing WorkflowおよびLaboratory Device Automationプロファイルに関連し、同様に非推奨のプロファイル、Laboratory Scheduled WorkflowおよびLaboratory Information
Reconciliationにも関連する。
Code Set Master： 1つあるいは複数のコードセットを所有する（コードセットの保守に責任を持つ）シス
テム。このシステムは、可能性としては、ラボ情報システム（LIS）、診療管理システム（CIS）、病院情報システム（HIS）、ラボ自動システム（LAS）あるいは施設の共通レポジトリのいずれかである。コード
セットは、定期的に（例えば毎週）、あるいはコードセットが変更される度に、送信されることが可能である。コードセットには、バッテリ、検査および検査結果のコードを含むことが可能である。このアクタは、Laboratory Code Set Distributionプロファイルに関連する。
Code Set Consumer： Code Set Master(s）からコードセットを受信し、Code Set Master(s）が保守したコー
ドセットが反映されるよう、内部の表を更新するシステム。このアクタは、Laboratory Code Set Distribution
プロファイルに関連する。
Content Consumer： Content Creatorアクタが作成したコンテンツの、閲覧、インポート、あるいは他の処理に責任を持つアプリケーション。このアクタは、臨床検査レポートを利用するために、Sharing
Laboratory Reports（XD-LAB）プロファイルに関連する。
Content Creator： コンテンツの作成および、Content Consumerへの送信に責任を持つアプリケーション。
このアクタは、共有を目的とした臨床検査レポート発行のために、Sharing Laboratory Reports（XD-LAB）
プロファイルに関連する。

103
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2670

Label Broker： ある患者へのオーダあるいはオーダグループに関する検体採取に必要な、容器の搬送および識別を行うロボットシステム。このシステムは、Label Information Providerと呼ばれる他のシステムから、指示を受信する。このアクタは、Laboratory Specimen Barcode Labelingプロファイルに関連する。
Label Information Provider： オーダあるいはオーダグループに関する検体のラベリングの指示を保有し、その指示をLabel Brokerに伝える情報システム。このアクタは、Laboratory Specimen Barcode Labelingプロフ
ァイルに関連する。

2680

2690

2700

2710

Order Filler： 臨床検査部門により使用されるシステムで、Order Placerアクタから検査オーダを受信し、関連する検体を採取あるいはコントロールし、オーダを受諾あるいは却下し、検査オーダを予約し、そして検査オーダを1つあるいは複数のAutomation Managersに送信し、各Automation Managerから結果を受信し、臨床的検証を実施し、オーダの状態の変更すべてを適切に管理し、そして結果をOrder Result Tracker(s）に送信する。
場合によっては、Order Fillerが検査オーダ自体を作成する（例えば、臨床検査部門が書面によるオーダを、Order Placerに接続されていない部門から、または組織外の医師から受領した場合、あるいは臨床検査部門が作成した反射オーダなど）。また、場合によってはOrder Fillerが検体の採取および識別に責任を持つ。
Order Fillerは、機関内の複数のOrder Placerから検査オーダを受信することが可能であり、また複数のOrderResult Trackerにオーダ結果を送信することが可能である。ポイントオブケア検査をサポートしている組織
では、このアクタはLaboratory Point Of Care Testingプロファイルとも関連付けられるが、これはプロセスを監督する指定された臨床検査部門に、ポイントオブケア検査結果をアップロードするためである。このア
クタは、Laboratory Testing WorkflowおよびLaboratory Point Of Care Testingプロファイルに関連し、同様に、非推奨のプロファイルLaboratory Scheduled WorkflowおよびLaboratory Information Reconciliationにも関連する。
Laboratory Point Of Care Testing統合プロファイルではこのアクタが、ポイントオブケア検査結果のセットをPOCDMから受信し、これを照合された、あるいは当該の検査のために作成されたオーダ内で保存する。これらのPOCTオーダはまた、臨床的検証へ提出され、そして精度保証と責任性のためのみに保管される。というのは、すでに医療スタッフが当該のオーダを、治療の決定のために使用しているからである。臨床的検証のプロセスにより、Laboratory Scheduled WorkflowプロファイルのトランザクションLAB-3を使用する、Order Result Trackerへの結果の送信が引き起こされる。POCTオーダは、Laboratory Testing Workflowプロフ
ァイルのトランザクションLAB-1あるいはLAB-2を通じて、Order Placerサイドのオーダと関連づけられる。
Order Placer： 様々な臨床検査機関のために、検査オーダおよびオーダグループを作成するシステムで、各オーダを適当な臨床検査機関に送付し、そしてすべての状態の変化を適切に管理する。場合によっては、Order Placerは検体の識別に責任を持つ。それゆえに、Order PlacerとOrder Fillerとの間のトランザクション
では、検体関連の情報が伝達されることもある。1つの医療機関に、複数のOrder Placerが存在することが可能である。ポイントオブケア検査をサポートしている組織では、このアクタはOrder Fillerからのリクエス
トに応じて、ポイントオブケア検査オーダについても、検査前あるいは検査後に識別する。このアクタは、新規のプロファイルLaboratory Testing Workflowに関連し、同様に、非推奨のプロファイルLaboratory
Scheduled WorkflowおよびLaboratory Information Reconciliationにも関連する。
Order Result Tracker： 医療機関の患者について得られた臨床検査結果を保存するシステムで、Order Filler
から通知された結果をすべての状態の変更について登録する。このアクタは、オーダあるいはオーダグル
ープのコンテクストで、検査結果を保存する。このアクタは、新規のプロファイルLaboratory Testing
Workflowに関連し、同様に、非推奨のプロファイルLaboratory Scheduled WorkflowおよびLaboratory
Information Reconciliationにも関連する。
104
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

2720

Point Of Care Data Manager（POCDM）： POCRGのセットを管理し、またその結果を集中化するシステ
ム。POCDMは、POCRGからのいかなる通信にも、迅速に反応する。POCDMはPOCRGからのポイントオ
ブケア検査結果を受信し、検査結果をそのコンテクスト内でコントロールし、保存し、そしてOrder Filler
へ転送する。
POCDMは結果の技術的なレビュー（技術的検証）をサポートしている。
POCDMは、POCRGのセットの活動をコントロールする機能を提供する。
POCDMは、各POCRGの精度管理結果を保存し、すべてのPOCRGに対する精度管理を監督する。
POCDMは、自身のアプリケーションおよび関連するPOCRGsのセットを、許可されたスタッフが設定するのを認める。
Point Of Care Results Generator （POCRG）： 自動計測、手入力あるいは計算により結果を作成するシス
テム。関連する患者あるいは精度管理検体ID、検査を実施するオペレータ、オーダリング提供者および医療部門とともに、結果を識別する。POCRGは、この情報をPOCDMに送信する。
さらにPOCRGは、その内部プロセスコントロール情報を、POCDMに送信することが可能である。

2730

Pre/Post-Processor: この自動装置は、これを管理しているAutomation Managerのリクエストに応じ、生物検体に対して一部の基本的なステップを実施する。Automation ManagerからPre/Post-Processorに送信される、ある検体に1ステップを実施するための各リクエストは、検体処理ステップオーダ（SWOS）と呼ばれる。
当該の機器はAutomation Managerに、オペレーションのステータスを返信する。Pre/Post-Processorの例としては、ソータ、分注機、開栓装置、閉栓装置、検体コンベア、検体保存システム、がある。このアクタは、Laboratory Device Automationプロファイルに関連する。

105
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

付録B: トランザクションの説明
2740 [LAB-1] Placer Order Management： このトランザクションは、（独立の、あるいはオーダグループ
内の）オーダのライフサイクルを管理するために、Order PlacerとOrder Fillerの両アクタ間で必要な全メッセージを提供する。この主要な目標は、上記の2つのアクタ間で、オーダ（コンテンツおよびステータス）の一貫性ある目的を維持することにある。
[LAB-2] Filler Order Management： このトランザクションは、Order Fillerアプリケーションが臨床
検査部門サイドで作成したオーダに新規の発行者オーダ番号を割り当てるため、Order FillerとOrder Placerとの間で必要なメッセージを提供する。

[LAB-3] Order Results Management： このトランザクションは、Order FillerからOrder Result Trackerに、オーダの結果、および結果のステータス変更、修正、キャンセルを伝える。
2750[LAB-4] Work Order Management： このトランザクションは、Order FillerとAutomation Managerの両アクタ間で、後者による検査オーダを実行するために必要なメッセージを提供する。このトランザクションが目指すのは、検査をAutomation Managerに送付し、そして当該の検査オーダに関連する患者情報の更新すべてを、Automation Managerに常に伝達することである。

[LAB-5] Test Results Management： このトランザクションは、Automation ManagerからOrder Fillerに、
検査オーダについて得られた技術的に検証された検査結果、および結果のステータス変更、修正、キャンセルを伝える。
[LAB-21] WOS Download： このトランザクションには、”push method”に従い、Automation ManagerからAnalyzerあるいはPre/Post-processorにステップオーダ（WOS）をダウンロードするために使用される、メッセージが含まれる。これには、「新規のWOS」、「WOSの更新」、「WOSのキャンセル」
および関連する受領通知が含まれている。このトランザクションは、ダウンロードモードで動作
2760
する、AnalyzersおよびPre/Post-Processorとともに使用される。
[LAB-22] WOS Query： このトランザクションには、１つあるいは複数の検体（あるいは位置）IDについてAutomation Managerにクエリを行うために、AnalyzerあるいはPre/Post-Processorが使用するメッセージ、および各検体専用に1つあるいは複数のWOSを伝達する、Automation Managerからの返信メッセージが含まれる。このトランザクションは、WOSをリクエストするために、”pull method”を実装する。
[LAB-23] AWOS Status Change： このトランザクションには、分析ステップオーダ（AWOS）のステータス（｢検体到着｣、｢初回の検査失敗｣、｢2回目の検査開始｣、「AWOS完了｣など）をレポートするために、またAWOSが完了した際に検査結果を送信するために、Analyzerが使用するメッセージが含まれる。また、Automation Managerからの、関連する受領通知も含まれる。
2770 [LAB-26] SWOS Status Change： このトランザクションには、検体検査ステップオーダ（SWOS）の全ステータスの変更、また関連する受領通知をレポートするために、Pre/Post-Processorが使用するメッセージが含まれる。ステータスの変更には、｢検体到着｣、「SWOS完了｣、「SWOS失敗」などが含まれる。
[LAB-30] Initiates point of care testing for a patient specimen： このトランザクションは、永続的に接続されているPoint Of Care Results Generatorで使用される。Point Of Care Results GeneratorはPoint Of Care Data Managerにメッセージを送信するが、それには、自身のID、医療部門ID、オーダリング提供者ID、オペレータID、患者/受診ID（あるいは精度管理ID）、その他開始される検査の関連情報が含まれる。Point Of Care Data Managerはオペレータを識別し、（精度管理の場合以外）
患者IDを確認し、次いでPoint Of Care Results Generatorに回答を返信する。回答がポジティブなら2780ば（精度管理の場合以外）患者IDが伝達され、ネガティブならば却下した理由が伝達される。
[LAB-31] POCT observations produced： Point Of Care Results GeneratorはPoint Of Care Data Managerに、検査結果のセットを送信する。Point Of Care Data Managerは、この検査結果のコンテンツを確
106
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSSIHE臨床検査テクニカルフレームワークVol. １：統合プロファイル

認し、保存し、そしてPoint Of Care Results Generatorに受領通知を行う。

[LAB-32] POCT observations accepted： Point Of Care Data ManagerはOrder Fillerに、患者情報がすべてそろった検査結果を送信する。Order Fillerは受領を通知する。この受領通知では、この検査
結果セットに属する実施者オーダ番号が伝達される。
[LAB-51] Laboratory Code Set Management： コードセット（バッテリ、検査、検査結果）の配布を管理する。
2790 [LAB-61] Label delivery request： このトランザクションには、Label Information ProviderからLabel
Brokerに送信される、ラベル配布に必要なメッセージが含まれる。メッセージには、ラベル情報、
患者情報および検体情報が含まれる。
[LAB-62] Query for label delivery instruction： このトランザクションには、Label BrokerがLabel
Information Provider に 、 患 者 ID の ク エ リ を 行 う た め に 使 用 す る メ ッ セ ー ジ 、 お よ び Label
Information Providerから返信される、ラベル情報、患者情報および検体情報を含むレスポンスメッ
セージが含まれる。

2800

107
Rev 2.0 Trail Implementation 16/08/2007

Copyright © 2007：GMSIH, SFIL, IHE-J, JAHIS, RSNA, HIMSS