GMSIH, HPRIM and JAHIS
Integrating the Healthcare Enterprise

10

臨床検査
テクニカルフレームワーク
第1部(LTF-1)
統合プロファイル
20
1.0 版 –トライアル・インプリメンテーション用
November 24, 2003

Copyright © 2003: GMSIH, HPRIM, IHE-J, JAHISIHE 臨床検査テクニカルフレームワーク、第１部

目次
序章................................................................................................................................................................2
1.1. IHE の概要 ............................................................................................................................................2
1.2. 臨床検査テクニカルフレームワーク（Laboratory Technical Framework）の概要 ...............................2
1.3. 対象読者................................................................................................................................................3
1.4. 実在のアーキテクチャとの関係............................................................................................................3
1.5. 表記規約................................................................................................................................................3
1.6. コメント....................................................................................................................................................3
1.7. 著作権について.....................................................................................................................................4
1.8. IHE テクニカルフレームワークの開発とメンテナンス・プロセス.........................................................4
2. 統合プロファイル ...........................................................................................................................................4
2.1. 適用範囲................................................................................................................................................4
2.2. ラボラトリの専門性................................................................................................................................5
2.3. 統合プロファイルの概要 .......................................................................................................................6
2.4. 臨床検査テクニカルフレームワークのアクター ...................................................................................6
3. 臨床検査スケジュール済みワークフロー.....................................................................................................7
3.1. ユースケース .........................................................................................................................................7
3.1.1.
登録済み検体を使用する外部依頼のオーダー ..........................................................................7
3.1.2.
未登録または検査部門が採取した検体を使用する外部依頼のオーダー ................................8
3.1.3.
第三者により登録された検体または検査部門が採取した検体を使用する実施者オーダー....8
3.2. ラボラトリの専門性/ユースケース ........................................................................................................93.3. アクター/トランザクション.....................................................................................................................10
3.4. データモデル........................................................................................................................................123.5. プロセスフロー .....................................................................................................................................143.5.1.
最初の 2 ユースケースを示す臨床検査スケジュール済みワークフロー： 依頼者オーダーリング
14
3.5.2.
3 番目のユースケースを示す臨床検査スケジュール済みワークフロー： 実施者オーダーリン
グ
15
3.5.3.
患者更新のフロー .......................................................................................................................16
3.5.3.1.
依頼作成前の患者情報の更新 ..........................................................................................16
3.5.3.2.
依頼作成後の患者情報の更新 ..........................................................................................17
3.5.3.3.
依頼完了後の患者情報の更新 ..........................................................................................18
3.5.4.
依頼/結果の更新、状況の変化、キャンセルおよび例外の管理...............................................19
4. 用語解説......................................................................................................................................................19
5. 懸案事項......................................................................................................................................................20
5.1. 将来のサイクル(cycles、年度)のための覚え.....................................................................................20
1.
30

40

50

60

1.0 版 –トライアル・インプリメンテーション用 03/11/24

1

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

70

1.

序章

1.1.

IHE の概要

インテグレーティングヘルスケアエンタープライズ（IHE, Integrating the Healthcare Enterprise）は、現代の医療機関を支える情報システムの統合を促進するための取り組みである。 その基本的な目標は、患者の治療において、診断に必要な全ての情報が、医療関係者に対し、正確かつ有効であることである。 IHE 活動は統合を促進するためのプロセスおよび討議の場である。 具体的な臨床的目標を達成するため、確立されたメッセージ規格を実装するための技術的枠組み(framework)を定義する。 この枠組みを実施するための厳格なテストプロセスを含み、教育セッションを開催し、この枠組みの利点を提示し業界およびユーザーによる導入を奨励するために医療専門家の主要ミーティングにて公開する。
IHE 活動に使われているアプローチは新しい統合標準を定義することではなく、必要に応じて、構成の選択
肢を明確にしながら、統合された形のなかで既存の標準の使用をサポートすることである。 既存の標準の明確化あるいは拡張が必要な場合は、IHE は関連する標準化団体に意見を照会する。
1.2.

80

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

IHE の 2003-2004 年度(cycle)は臨床検査機関、その情報システム、自動化システムおよび装置に対して、活動を拡大する。 本書「臨床検査テクニカルフレームワーク」はこの拡大により展開する新しいプロファイル、ア
クターおよびトランザクションについて明示する。 また、この新規分野を網羅するための従来規格の適切なメッセージを選択し、その実装を明確にする。
臨床検査テクニカルフレームワークを以下 2 つの部に編成する。
第 1 部は、機能要素、アプリケーションの役割のような IHE アクターを定義し、かつそのトランザクションを示しながら、この分野の上位概念を説明する。 専門的な臨床ニーズにより高度に適合する統合プロファイル(integration profile)と呼ばれる機能図に纏める。
第 2 部は各トランザクションとそのメッセージの詳細な技術仕様を説明する。
本書は公開レビュー期間に正誤表の確認と修正を通じて定期的に見直され、毎年更新される。 現バージョン（Rev. 1.0 for Trial Implementation）は 2003 年 11 月に規定および実施された IHE トランザクションに特定する。 本書の最新バージョンはインターネットwww.gmsih.fr およびwww.rsna.org から入手可能である。

90

本書は以下の標準化団体の助力で作成された。
GMSIH (
Groupementpourl
aMode
r
ni
s
a
t
i
onduSy
s
t
è
med’
I
nf
or
ma
t
i
onHos
pi
t
a
l
i
e
r
)
HL7 とその系統機関
H.PR.I.M (Association « Harmoniser et Promouvoir les Informatiques Médicales »)IHE-J (IHE Japan)
JAHIS（保険医療福祉情報システム工業会）
RSNA（北米放射線医学学会）
SFI
L(
Soc
i
é
t
éFr
a
nç
a
i
s
ed’
I
nf
or
ma
t
ique de Laboratoire)

1.0 版 –トライアル・インプリメンテーション用 03/11/24

2

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

100

主要貢献者を以下に示す：

1.3.

対象読者

本書が意図する対象読者を以下に示す：

 IHE 活動に関係するベンダーの技術担当者
 医療機関の IT 部門
 標準の開発に関係する専門家 医療情報システムの統合の技術面に関心のある者
110
1.4.

120

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

IHE のアクターとトランザクションは、実際の医療情報システム環境を抽象化したものである。 いくつかのトラ
ンザクションは従来、特定の製品カテゴリ（例：HIS（病院情報システム）、電子患者記録、臨床情報システム、
LIS（臨床検査システム）、LAS（臨床検査自動化システム）、分析機、ロボット搬送システム、他の分析前後処理装置など）により実行されていたが、IHE 臨床検査テクニカルフレームワークでは意図的に、上述した製品
カテゴリと、機能またはアクターを関連付けないようにしている。 IHE 臨床検査テクニカルフレームワークは、
アクターごとに、情報システムの統合化に関連する機能のみを定義する。 したがって、アクターの IHE 定義を、実装する製品の完全なる定義と捉えてはならないし、フレームワーク（枠組み）自体を医療情報システムのアーキテクチャを包括的に記述していると考えるべきでもない。
1.5.

表記規約

IHE 臨床検査テクニカルフレームワークは、IHE ラジオロジ・テクニカルフレームワーク（IHE radiology
Technical Framework） 改訂 5.5 版に規定されている規約を変更無く引用する。 その文書の第 1 部の 1.6 項（表記規約）を参照のこと。
1.6.
130

コメント

JAHIS（保険医療福祉情報システム工業会）、GMSIH、HIMSS および RSNA（北米放射線医学学会）はこの文書と IHE 活動についての意見を歓迎する。 意見の送付先は以下のとおり：
Karima BOURQUARD
374, rue de Vaugirard
1.0 版 –トライアル・インプリメンテーション用 03/11/24

3

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

75015 PARIS
E メール：karima.bourquard@gmsih.fr
なお、下記の IHE Laboratory international mailing list に送信しても可。
ihe-intl-lab@listes.univ-rennes1.fr
国内では、下記の URL の「コメント募集」にて意見を募集している。
URL http://www.jira-net.or.jp/ihe-j/index.html
140
1.7.

著作権についてIHE は Health Level Seven, Inc.により、HL7 標準からの表の複製を許可されている。 本書の HL7 表は、Health Level Seven, Inc.が有する著作権で保護されているため、無断複写、転載を禁じる。
IHE は本書の一部分、あるいは全体の複写にあたり、Health Level Seven 社およびその系統機関に許可を与
える。
1.8.

IHE テクニカルフレームワークの開発とメンテナンス・プロセス

150
IHE 臨床検査テクニカルフレームワークは IHE Laboratory 技術委員会により継続的に拡張され、見直しされる。 フレームワークの開発およびメンテナンスのプロセスは、2003 年に刊行したラジオロジ・テクニカルフレー
ムワーク 5.5 版の 1.10 項「IHE テクニカル・フレームワークの開発とメンテナンス・プロセス」に明記された原則に従う。
2.

統合プロファイル

2.1.

適用範囲

臨床検査テクニカルフレームワークは、保健医療機関の検査部門についての統合化を説明する。
160

基本的に、検査部門は臨床担当部署あるいは医師から患者に関する検査実行の依頼を受ける。 検査は通常、患者から採取した検体で行われる。 施設によっては、検査部門が検体を採取する必要がある依頼を受けることもあれば、分析される検体が添付されている依頼を受けることもある。 後者の場合、検体は依頼の前/後に届く。
メッセージングのやりとりのために、検体容器の識別は必須。 しかし、ラベル発行工程の具体的な詳細は、このフレームワークの適用範囲外である。
ワークフローは、依頼を受入、変更または却下する検査部門の能力と、オーダー依頼者に対する適切な通知を包括する。

170

検査では、血糖グルコースのような簡単な定量測定から、骨髄生検のような複雑な病理学診断レポートまで、多様な種類の検査結果がでる。 結果のいくつかは、血清タンパク電気泳動のように、画像やグラフを伴う。
結果は依頼した臨床担当部署へ、またコピーは他の医師や部署へ送付され、電子的医療記録に保存されることもある。
検査結果には、依頼され出力されたものと、依頼されずに出力されたものがある。
検査結果はさまざまな検証ステップを経て進行する。
未検証結果(non-validated result)は、分析装置から出力されたが、人がまだ検証していない状態のものである。
技術的に検証された結果(technically validated result)は、他の基準とともに精度管理結果を考慮に入れて的確な分析手順から得られた結果であると臨床検査技師により保証されたものである。

180

臨床的に検証された結果(clinically validated result)は、臨床検査の専門家より容認、解釈されたものである。 臨床的な検証（巻末の用語解説を参照）は結果解釈を含む。 臨床検査の専門家は生物学的な経過、有効な臨床治療情報を鑑み、全ての依頼の整合性を考慮する。 臨床検査の専門家はこのステップを、通例または簡単な事例を確認するルールや推論を適用したエキスパートシステムを使って行うか
1.0 版 –トライアル・インプリメンテーション用 03/11/24

4

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部もしれない。
検査部門は通常、臨床的な検証をした後にのみ結果送信をする。 緊急時のような条件下や、医療担当部署との合意の下においては、結果が技術的に検証され次第送信されるかもしれない。 この場合は、臨床的な検証を行った後、結果の妥当性が承認される。
コードセットと複数のアクターによって共有されている関連ルールのやりとりは、この統合プロファイルの適用範囲を超えている。 しかし、必要ならアクターは共通のコードセットを使用すると仮定する。
ラボラトリの専門性

2.2.
190

全てのラボラトリの専門的な検査業務が現在のフレームワークで網羅されているとは限らない： 2003-2004 年度(cycle)は患者そのものではなく、患者から採取した検体について検査を行う専門領域のワークフローを網羅する。
下表は、HL7 v2.5 の表 0074“臨床診断部門 ID(Diagnostic Service Section ID)”からの抜粋であるが、IHE
臨床検査テクニカルフレームワークの 2003-2004 年度で取り組む検査部門の専門的な検査業務を示す。 他の専門性については今後の IHE 活動にて追加予定。

値
BG
BLB
CUS
CTH
CP
CT
CH
HM
ICU
IMM
LAB
MB
MCB
MYC
NMS

表 2.2-1: 専門的なな検査業務の網羅的でないリスト
内容
臨床検査 TF 2003 –2004 による対応
Blood Gases○
血液ガス
Blood Bank
血液バンク
Cardiac Ultrasound
心臓超音波
Cardiac Catheterization
心臓カテーテル
Cytopathology
細胞病理学
CAT ScanCAT スキャン
Chemistry○
生化学
Hematology○
血液学
Bedside ICU Monitoring
ベッドサイド集中治療室モニタリング
Immunology○
免疫学
Laboratory1○
検査部門
Microbiology○
微生物学、細菌学
Mycobacteriology○
結核菌学
Mycology○
菌類学
Nuclear Medicine Scan
核医学スキャン

1

この表の“LAB”（検査部門）は複数の専門分野をもつラボラトリを表す。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

5

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

NRS
OSL
PF
SR
TX
VUS
VR

Nursing Service Measures
看護業務方法Outside Lab
外部検査機関Pulmonary Function
肺機能Serology
血清学
Toxicology
毒物学
Vascular Ultrasound
血管超音波
Virology
ウイルス学

○
○

○

200
2.3.

統合プロファイルの概要

以下 4 つの統合プロファイルが検討されている。
臨床検査スケジュール済みワークフロー(Laboratory Scheduled Workflow)： 特定の入院患者または外来患者のために検査部門が行う検査。
臨床検査・患者情報の整合性確保(Laboratory Patient Information Reconciliation)： 誤認/匿名患者のための検査。 後に患者記録と照合される。
ポイントオブケア(Point of Care Testing)： ラボラトリの監督下において、患者のベッドサイドで医療スタッフが実施する検査。
医療機関間の検査(Inter-Enterprise Testing)： 外部検査機関による検査。
210
最初の 3 つの統合プロファイルは保健医療機関内に含まれる。 最後の 1 つは外部ラボラトリを関与させるワークフローで、別の保健医療機関のスタンドアローンか一部かにあたる。
2003-2004 年度 臨床検査テクニカルフレームワークは、最初のプロファイルである「臨床検査スケジュール
済みワークフロー」を開発する。 他の 3 つについては、次回の 2004-2005 年度(cycle)に実施する予定。
2.4.

220

臨床検査テクニカルフレームワークのアクター

患者管理（ADT）： 入院、退院および転院。 システムは患者数や対処した情報の追加および/または更新し、この情報をオーダー依頼者、オーダー実施者、オーダーリザルトトラッカへ送信する責任を負う。このアクター
はラジオロジ・テクニカルフレームワーク(Radiology Technical Framework)および IT インフラストラクチャ・テク
ニカルフレームワーク(IT Infrastructure Technical Framework)でも提起されている。
オーダー依頼者(Order Placer)： さまざまな臨床ラボラトリに検査依頼をする病院あるいは医療施設におけるシステムで、的確なラボへ依頼を配信し、依頼の状態の変化に的確に対応する。 あるケースでは、オーダ
ー依頼者が検体採取および登録に責任を負う。 したがって、オーダー依頼者とオーダー実施者間のトランザクションは、検体に関連する情報を取り扱う。

230

オーダー実施者(Order Filler)： ラボラトリにて使用されるシステム。 オーダー依頼者から検査依頼を受信し、関連する検体を採取、管理し、依頼の受入/却下、検査オーダー（work orders）を割り当てし、それらをオートメーションマネージャーへ送信し、オートメーションマネージャーから結果を受け取り、臨床的な検証を行い、依頼の状態の変化に適切に対応し、その結果をオーダーリザルトトラッカへと送信する。 いくつかのケースでは、オーダー実施者自体が検査依頼を生成することもある。（例：オーダー依頼者に接続していない担当部
署から検査部門が文書による依頼を受けた場合、あるいは、外部の医師から施設宛てに文書による依頼を受けた場合。） 場合によっては、オーダー実施者が検体採取および登録の責任を負う。
オートメーションマネージャ(Automation Manager)： ラボラトリでの自動化、またはその一部を管理するシス
1.0 版 –トライアル・インプリメンテーション用 03/11/24

6

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

テムかコンポーネントのこと。 自動化には、自動化/ロボット搬送システム、分析装置、および分析前/後処理装置（自動遠心分離機、分注機、開栓機、閉栓機、分類装置、検体収納、検索システムなど）の統合あるいは
インターフェースを含む。 このアクターはオーダー実施者から検査オーダー（work orders）を受ける。 依頼された検査を適切な機器で処理し、技術的に検証された結果をオーダー実施者へ返信する。 このアクターは、
たとえ、例えば分析工程が単体分析装置で処理できるような小さな要素だとしても考慮する必要がある。 複数のオートメーションマネージャーが 1 つのオーダー実施者に関係することもできる。
240

オーダーリザルトトラッカ(Order Result Tracker): 検査結果、画像、臨床実験レポート、放射線学レポート、
外科活動レポートなど、患者の各種検査結果を保存する病院/医療施設におけるシステムで、オーダー実施者が通知する全ての状態変化の結果を登録する。 このアクターは単独では検査結果を保存せず、依頼された検査結果を保存する。 検査結果は必ず依頼に脈絡がある内容や、その依頼に関連する全ての情報と一緒に保存される。
（このアクターは臨床検査テクニカルフレームワークに限ったものではない： “Retrieve Information for Display Integration
Pr
of
i
l
e
”
で定義されているアクター“
I
nf
or
ma
t
i
onSource”の役割も演じる(ラジオロジの“IT Infrastructure Technical Framework”
を参照)。 また、”
Ra
di
ol
og
yTe
c
hni
c
a
lFr
a
me
wor
k
”
で定義されているアクター“
Ent
e
r
pr
i
s
eRe
por
tRe
p
os
i
t
or
y
”
の役割も演じる。）

3.

臨床検査スケジュール済みワークフロー

250「臨床検査スケジュール済みワークフロー」統合プロファイルは、保健医療機関全体にわたり、臨床検査と結果データの持続性と統合性を確立する。 依頼と患者情報の一貫性の維持するため、検体の適合性の管理するため、および検証の多様なステップにおいての結果を送信するためのトランザクションを含む。 これらトラ
ンザクションのいくつかは、IHE ラジオロジ・テクニカルフレームワークに定義済である。 当該プロファイルはラボラトリ内での、分析前、分析および分析後の工程の自動化を可能にする。

260

3.1.
ユースケース以下に示す 3 つのユースケースでは、オーダー依頼者、オーダー実施者、オーダーリザルトトラッカのアクターが、最新の患者情報を ADT（入院/退院/転院）アクターによりもたらされると仮定している。 アクターやトラ
ンザクションを全体的に概要するには、図 3.3-1 を参照のこと。
3.1.1.

登録済み検体を使用する外部依頼のオーダー

本シナリオの初期部分： 当該ユースケースに限定

270

280

医療部門の医師は、患者のための臨床検査（またはバッテリ）を指示する。 依頼は全ての関連情報とともにオーダー依頼者に登録される。 （オーダー依頼者の辞書に記載の）ラボラトリが定めたルールを使い、オーダー依頼者は、（容器タイプ、防腐剤/抗凝固、容量、時間および患者状況などの）収集データや搬送状態とともに、検査実行にどのような検体が必要なのかを判断する。 オーダー依頼者は、一意的な検体 ID を記載
した検体識別ラベル（通常バーコード）、依頼者オーダーID、患者識別（PID、名前、来院番号など）を供与し、該当検体に関連して依頼するバッテリを決めることもある。 医療部門のスタッフは検体を採取し、各容器上に適切なラベルが貼付されているかを確認後、オーダー依頼者がオーダー実施者へオーダーを送信している検査部門へ検体を送付する。 物質の流れ（検体）と電気通信の流れ（オーダー）の一連の順序は必ずしも一致させる必要はない。 それは医療機関に依る。 検査部門のスタッフはオーダー実施者のアプリケーションを使用して依頼者オーダーを開き、全ての必要な検体が有効で、依頼と一致しているかを確認する。 必要であれば、オーダーを却下したり、修正しながら依頼を受け入れる。 その後、オーダー実施者により依頼が作成、スケジュールされて、オーダー依頼者に通知される。 検体が破損または紛失した場合は、オーダー実施
者はオーダー依頼者に新しい検体を要求し、依頼されていたバッテリ（検査項目）は、差し替え用の検体が届
くまで保留とする。
当該ユースケースにおいては、医療機関はその施設におけて全検体に対して一意的な ID を確保する検体識別する仕組みを使用しなければならない。 オーダー依頼者とオーダー実施者のアクターは、臨床検査機
関やオートメーションマネージャーと適合する検体 ID の構造に同意しなければならない。 例えば、臨床検査の自動化システムは、検体 ID 番号の長さ、または読み取り可能なバーコードラベルのフォーマットにより機能が限定される。 検体 ID はその検体の存続期間につき、必ず一意的にすべきである。
本シナリオの中間部分： 3 つのユースケースで共有
1.0 版 –トライアル・インプリメンテーション用 03/11/24

7

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

290

オーダー実施者は、オーダーを 1 つか 1 つ以上のオートメーションマネージャーへ送信される検査オーダー（Work Orders）に分割する。 検査部門の技術スタッフはオートメーションマネージャーと全ての必要な機器（分注機、ロボットシステム、分析機．．．）を使用して、種々の検査オーダーを実行する。 検体の分割（分注）は、子検体容器を識別するために（オーダー実施者またはオートメーションマネージャーが印刷した)追加ラベルを必要とするかもしれない。 技術スタッフは検査結果の技術的な検証を行い、オートメーションマネージ
ャーはその結果をオーダー実施者へ返信する。 臨床検査の専門家はオーダー実施者のアプリケーションを使い、臨床的に結果を検証する。
本シナリオの最終部分： 3 つのユースケースで共有（医療機関によるが）さまざまなステップにおいて、オーダー実施者はオーダーリザルトトラッカへ結果を送信する。 さらに、依頼/結果についての全てのステータス変化をオーダー依頼者、オーダーリザルトトラッカの両方に通知し、依頼および結果はそれぞれで最終状態になる。この最終状態は“完了”、“キャンセル”または“無効”のいずれかにあたる（結果が出ても、後に無効となることがある）。
3.1.2.

未登録または検査部門が採取した検体を使用する外部依頼のオーダー

本シナリオの初期部分： 当該ユースケースに限定
300

医療部門の医師は患者の臨床検査を指示する。依頼は全ての関連情報とともにオーダー依頼者のアプリケーションに登録される。オーダー依頼者は検体を識別していない。検体の登録と採取について以下 3 種類のサブ・ユースケースが考察される。
1. 処置部門は患者 ID と依頼者オーダーID に限定した識別でラベル貼付された検体を採取、提供する。
検体はその後、処理を行う検査部門のスタッフにより、オーダー実施者やバーコードされた検体 ID のラベ
ルで、再識別される。
2. 検査部門は検体採取および識別の責任を負う。 この業務は検査部門の専門スタッフが行う。2
3. 処置部門は、（オーダー依頼者から受信した情報をもとに）オーダー実施者が作成した必要検体およびラベルのリストを使って検体を採取し、（例えば病棟のリモート印刷を介して）処置部門のスタッフへ送る。3310

上記 3 種類のサブケースでは、オーダー実施者は検体をラベルにより最終的に識別する。 ラベルに記載すべき内容を以下に示す。

 一意的な検体 ID（通常、自動化のためバーコードされている）
状況に応じ、以下を記載する。

 実施者オーダー ID 患者識別（ID）
 責務ある識別（処置部門あるいは医師、データモデルの図 3.4-1 を参照）

 依頼されたバッテリ
 オーダー依頼者 ID その他
当該ユースケースの中間および最終部分は 3.1.1 のユースケースと同様。
320
3.1.3.

第三者により登録された検体または検査部門が採取した検体を使用する実施者オーダー

本シナリオの初期部分： 当該ユースケースに限定：
2

北欧および米国にて頻見されるケース。
カナダやフランスのいくつかの医療機関で見られるケース。 処置部門スタッフは、オーダー実施者の要求の下、検体採取および識別を行う。
3

1.0 版 –トライアル・インプリメンテーション用 03/11/24

8

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

以下 2 種類のサブ・ユースケースが考察される。
1. ラボラトリ・スタッフはオーダー依頼者のアプリケーションにアクセスできない処置部門から書面による依頼を受ける。
2. 一連の依頼を処理中に、ラボラトリは新規依頼を既存の依頼群に追加する。 その新規依頼はその依頼
群の既存検体の 1 つとして扱われる。

330

上記 2 種類のサブケース両方とも、作成された依頼は実施者オーダー番号を持つ。 オーダー実施者のアプ
リケーションは、オーダー依頼者のアプリケーションにこの実施者オーダーを通知する。 オーダー依頼者のアプリケーションは依頼者オーダーを作成し、オーダー実施者へ依頼者オーダー番号を返信する。
新規検体は、適切なラベル（バーコードされた検体 ID、実施者オーダーID、患者識別）と共にオーダー実施
者により登録される。
当該ユースケースの中間および最終部分は 3.1.1 のユースケースと同様。 3 種類のユースケースのステップ
を下図に重複して示す。
初期部分

最終部分

中間部分

ケース 3.1.1
登録済み検体を使用する外部依頼
のオーダー

340

ケース 3.1.2
未登録または検査部門が採取した検体を使用する外部依頼のオーダ

350

オーダー実施者はオートメーションマネージャと通信し、検査を行う（3.1.1 を参照）

オーダー実施者は結果をオーダリ
ザルトトラッカと、状況をオーダー
依頼者と通信する。
（3.1.1 を参照）

ケース 3.1.3
第三者により登録された検体または検査部門が採取した検体を使用する実施者オーダ

図 3.1-1 重複して表した３ユースケース
360
ラボラトリの専門性/ユースケース

3.2.

下表はこの臨床検査スケジュール済みワークフロー・統合プロファイル(Laboratory Scheduled Workflow
Integration Profile)が網羅する 12 の専門分野を、異なるユースケースへの適用性と共にリストアップしたもの。
表 3.2-1： サポートされた専門分野とワークフロー・ユースケースのリスト
値

専門分野

登録済み検体を使用する外部依頼のオーダ

未登録または検査部門が採取した検体を使用する外部依頼のオーダ

実施者オーダー

BG

Blood Gases
血液ガス
Chemistry
生化学
Hematology

○

○

○

○

○

○

○

○

○

CH
HM

1.0 版 –トライアル・インプリメンテーション用 03/11/24

9

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

IMM
LAB
MB
MCB
MYC
SR
TX
VR

3.3.
370

血液学
Immunology
免疫学
Laboratory
検査部門、ラボラトリ
Microbiology
微生物学、細菌学
Mycobacteriology
結核菌学
Mycology
菌類学
Serology
血清学
Toxicology
毒物学
Virology
ウイルス学

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

アクター/トランザクション

図 3.3-1 に、臨床検査スケジュール済みワークフローおよびトランザクション相互に関与するアクターを示す。
アクターADT の“患者登録[RAD-1]”と“患者更新[RAD-12]”で開始されるトランザクションは、ラジオロジのス
ケジュール設定済みワークフロー(Radiology Scheduled Workflow)で既に明記されている（ラジオロジ・テクニ
カルフレームワーク(Radiology Technical Framework）の第 1 部を参照）。 この 2 つのトランザクションを修正なく、そのまま使用する。
臨床検査スケジュール済みワークフローは LAB-1 から LAB-5 と番号付けされた 5 つの新しいトランザクショ
ンを導入する。

380
図 3.3-1： 臨床検査スケジュール済みワークフローの図
本書では、オートメーションマネージャーと分析装置や他の装置間のトランザクションを規定していない。 こ
れらのトランザクションは、将来のバージョンにて言及する。 現バージョンのオートメーションマネージャーは分析工程に使われる全ての自動化装置をグループ化するアクターである。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

10

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

臨床検査スケジュール済みワークフローで導入される新規トランザクションに関する注：390

LAB-1: 依頼者オーダー管理（Filler Order Management）： 依頼のライフサイクル管理のため、オーダー依頼者とオーダー実施者間で必要な全てのメッセージを含むトランザクション。 これら２つのアクター間における依頼の一貫したビジョン（内容や状況）を保つことを主要目的とする。
LAB-2: 実施者オーダー管理（Filler Order Management）： 新規の実施者オーダーを通知するため、およびそれを反映した依頼者オーダーを作成するために、オーダー実施者とオーダー依頼者間で必要な全てのメッセージを含むトランザクション。 それぞれの実施者オーダーが依頼者オーダーと相当すること、さらに実施者オーダー番号と依頼者オーダー番号を持つことを主要目的とする。
LAB-3: オーダー結果管理（Order Results Management）： オーダー実施者からオーダーリザルトトラッカ
へ検査結果や依頼状況の変更をするトランザクション（例： 訂正、キャンセル）。

400

LAB-4: 検査オーダー管理（Work Order Management）： 実施者オーダーの検査項目部分を含む検査オーダー（work order）を行うため、オーダー実施者とオートメーションマネージャー間で必要な全てのメッセー
ジを含むトランザクション。 オートメーションマネージャーへの作業割り当てや、このアクターが全ての患者や依頼の更新を知らされるよう保たれることを主要目的とする。 このトランザクションはプッシュ型(pushmechanism)に基づいており、問い合わせ型(query mechanism)では使用されない。
LAB-5: 検査結果管理（Test Result Management）： オートメーションマネージャーからオーダー実施者へ
技術的に検証された検査結果を伝えるトランザクション。
表 3.3-1： 臨床検査スケジュール済みワークフロー ― アクターおよびトランザクション
アクター
トランザクション
選択性
参照文書
ADT
Patient registration [RAD-1]
R
Radiology TF vol 2, sect 4.12
患者管理
患者登録 [RAD-1]
Patient update [RAD-12]
R
Radiology TF vol 2, sect 4.12
患者更新 [RAD-12]
Order Placer
Patient registration [RAD-1]
R
Radiology TF vol 2, sect 4.12
オ ー ダ ー 依 頼 患者登録 [RAD-1]
Patient update [RAD-12]
R
Radiology TF vol 2, sect 4.12
者
患者更新 [RAD-12]
Placer Order management [LAB-1] R
Laboratory TF vol 2, sect 4
依頼者オーダー管理[LAB-1]
Filler Order management [LAB-2] R
Laboratory TF vol 2, sect 5
実施者オーダー管理[LAB-2]
Order Filler
Patient registration [RAD-1]
R
Radiology TF vol 2, sect 4.12
オ ー ダ ー 実 施 患者登録 [RAD-1]
Patient update [RAD-12]
R
Radiology TF vol 2, sect 4.12
者
患者更新 [RAD-12]
Placer Order management [LAB-1] R
Laboratory TF vol 2, sect 4
依頼者オーダー管理[LAB-1]
Filler Order management [LAB-2] R
Laboratory TF vol 2, sect 5
実施者オーダー管理[LAB-2]
Order result management [LAB-3] R
Laboratory TF vol 2, sect 6
オーダー結果管理 [LAB-3]
Work order management [LAB-4] R*
Laboratory TF vol 2, sect 7
実施オーダー管理 [LAB-4]
Test result management [LAB-5]
R*
Laboratory TF vol 2, sect 8
検査結果管理 [LAB-5]
Automation
Work order management [LAB-4] R
Laboratory TF vol 2, sect 7
Manager
実施オーダー管理 [LAB-4]
オ ー ト メー シ ョ Test result management [LAB-5]
R
Laboratory TF vol 2, sect 8
ンマネージャー 検査結果管理 [LAB-5]

1.0 版 –トライアル・インプリメンテーション用 03/11/24

11

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

Order Result
Tracker
オーダーリザ
ルトトラッカ

410

Patient registration [RAD-1]
患者登録 [RAD-1]
Patient update [RAD-12]
患者更新 [RAD-12]
Order result management [LAB-3]
オーダー結果管理 [LAB-3]

R

Radiology TF vol 2, sect 4.12

R

Radiology TF vol 2, sect 4.12

R

Laboratory TF vol 2, sect 6

R*: LIS（臨床検査システム）がオーダー実施者とオートメーションマネージャーの両方のアクターの機能をサポートしている場合、トランザクション LAB-4 と LAB-5 は関連性が無い。 これらのトランザクションは、検査部門に別のオートメーションマネージャーがあるとき、オーダー実施者によりサポートされねばならない。
3.4.

データモデル

本項に記載のデータモデルは、アクター間のトランザクションで伝達される情報に関連する。 特定のシステム/アクターの内部データベースモデルをいかなる方法でも制約することはない。いわゆる通信モデルである。
さらに、この通信モデルは HL7 v3 RIM、または派生する Laboratory DMIM のどちらとも競合しない。 当該モデルの目標は、システム内にアクターやトランザクションを実装するためにシステムベンダーをサポートすること、また、IT 部門が医療施設内でこのデータモデルを参考にすることである。
データモデルは以下の定義(assertions)に基づく。


この統合プロファイルで、医療部門の医学的な責務の下、現在の来院状態やロケーションで、その患者
420が入院患者なのか、外来患者なのかが ADT （患者管理）アクターにより特定される。


患者の来院中の診療、看護、受入などのさまざまな責務が定義される。 ロケーションは建物、階、部屋、ベッドなどに特定される受入の責務の一部である。 患者のロケーションは、正確な結果の伝達や検体採取のためだけでなく、疫学的根拠のためにも重要。 例えば、細菌学のラボラトリでは院内感染などの発見、追跡のためにこういった情報を必要とする。 機関によっては、これらの責務は医師、治療室、あるいはその両方が責任を負う。


依頼者オーダーは、物質（空気、水、外科装置、食品、薬剤、など）、あるいは生存被験者（患者）を対象に、医師によって指示され、処置部門によって依頼される。 後者のケースは、依頼は現在の患者の来院やロケーションに関係する。

430



依頼者オーダーは医療施設における一意的なグローバルキー、依頼者オーダー番号を持つ。

依頼者オーダーは、設定前にキャンセル、あるいはラボラトリ・スタッフが却下しない限り、相応する 1 つの実施者オーダーに転移する。


同様に、実施者オーダーは、ただ 1 つの依頼者オーダーと関連する。

依頼は、医療施設における 2 つの一意的なグローバルキー、つまり実施者オーダー 番号および依頼者
オーダー番号で特定される。


当該 2003 –2004 IHE サイクル(cycle、年度)では、実施者オーダーは 1 箇所の臨床ラボラトリが扱うと見なす。

“検査オーダー（work order）”は実施者オーダーの一部で、オーダー実施者のアクターからオートメー
440

ションマネージャーのアクターへ送信される。 1 つの実施者オーダーは、０または 1 つ以上の検査オーダーになるかもしれない。 あるケースでは、検査オーダーは実施者オーダーと同一であるが、他のケースにおいては、検査オーダーは単体分析機へ送られる検査だけかもしれない。


依頼は 1 つ以上の検査から成るバッテリで構成される。 例： 血球数、血清電解質、タンパク電気泳動、
血清グルコース値、血清カリウム値。 バッテリはまた、他の（より小さな）バッテリで構成することもできる。


個別の検査では、1 つ以上のバッテリの一部を構成することができる。 例えば、生化学においては、血清カリウム値は“3 イオン血清電解質”バッテリの一部で、同様に“血清電解質一式”バッテリの一部でもある。 血液学では血小板数は、血小板数検査のみのバッテリを構成し、同様に、追加検査に含まれる“血1.0 版 –トライアル・インプリメンテーション用 03/11/24

12

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

球数一式”バッテリの一部を構成する。


生化学、血液学、免疫学、ウイルス学では、依頼された検査（an ordered test）はほとんどの場合、1 検査
450（one single observation）のみを作成する。 通常、検体に関する測定や計算の検査からは 1 結果のみが生じる。 しかし、さまざまな検査（several observations）を生じる依頼された検査の例（examples ofordered test）がある。 これらの例は検体についての何かを“検出”あるいは“特定”する。 微生物学の例として“バクテリア検出”の検査では、“ブドウ球菌アウレウス”や“大腸菌”の 2 つを検出する。 同様に、血液学の検査“異常白血球の特定”では、“赤芽球”や“白血球の形態異常”の 2 つを検出する。 このことから、データモデルでは検査（test）は 0～n 個の検査（observations）と関連する。


試験する内容により、さまざまな方法で検査はもたらされる。 用手法や、自動分析機での処理を介して、あるいは、他の検査結果を使い演算論理装置を通じての計算を介して、また結果の定性的な解釈や、技術者あるいは臨床検査の専門家作成のテキスト評価を介してなどがある。


自動分析機での検査の場合、許容範囲の検査を得るために分析機に数回通過させることが必要なことがある。 例えば、検体希釈後の 2 回目の通過は、1 回目の通過が検査の分析範囲外の結果だったとき、必要とされる。
460


技術的な検証の主要目的は、規定された手順で、満足の行く精度管理をしながら、同一検査の前回値から許容できる偏差のような他の検証基準に適合しながら、検査結果が得られているかを確かめることである。


依頼されたバッテリには通常、患者から採取した 1 検体が必要。 いくつかの検査、例えば、糖負荷試験
は特定の間隔をおいて採取された数個の検体が必要。 クレアチニン・クリアランス（糸球体のろ過値）は尿と血清の両方とも採取する必要がある。 患者から直接採取された検体のことを“親検体”と呼ぶ。


医療機関、あるいは関心がある専門分野によって、遠心分離または希釈のような前処理を含む準備ステップを経て、検査は“親検体”か、親検体から採取した 1 個以上の“子検体”について測定される。



臨床的な検証は全ての実施者オーダーまたは依頼のグループに概ね適用するプロセスで、解釈を円滑470にするために患者に有効な臨床的な情報と、必要とされる可能なフォローアップのアクションと一緒に、結果に生物学的な一貫性があるかを考慮する。 あるケースでは、例えば血液ガスのような重要な結果
が、より早い有効性が得られるように、あるいは短時間で得られるようにするために、結果の一部だけで行われる。 複数の専門分野を持つラボラトリでは、1 つの専門分野につき 1 人の臨床検査の専門家が担当し、それぞれが専門知識に特有のバッテリを検討する。 最終的に実施者オーダーは数人の臨床検査の専門家により検証される。


バッテリは分析工程中の中間検査から作成されることがある。 細菌学の例では、“グラム陰性菌”が発見された場合には、抗生物質に対する感受性の検査を行う。

480

上記の定義(assertions)により、臨床検査スケジュール済みワークフローのデータモデルは下図のように簡略化した UML（Unified Modeling Language）クラス図によって表現できる。 尚、クラス属性は下図では示されていない。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

13

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

図 3.4-1： 臨床検査スケジュール済みワークフローのデータモデル
3.5.

プロセスフロー

プロセスフローを、以下のような UML シーケンス図で表す。（上から下へ時間の経過を示す）

490

これらの図はフローの大まかな流れを示す。 各トランザクションは、最初に起こったイベントから 1 本の矢印で示されるが、トランザクションを構成するさまざまなメッセージの詳細はない。 例えば、トランザクション[LAB-1]
は依頼を設定することから始まるが、このトランザクションのメッセージの流れは依頼が完了、キャンセルあるいは無効になるまで続行される。 個別にメッセージは表示されず、各トランザクションの詳細なメッセージの流れは第 2 部に示す。
3.5.1.

最初の 2 ユースケースを示す臨床検査スケジュール済みワークフロー： 依頼者オーダーリング

図 3.5-1 はユースケース 3.1.1 および 3.1.2 の基本的なプロセスフローを表す。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

14

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

図 3.5-1: 依頼者オーダーリングのプロセスフロー

500

3.5.2.

3 番目のユースケースを示す臨床検査スケジュール済みワークフロー： 実施者オーダーリング

1.0 版 –トライアル・インプリメンテーション用 03/11/24

15

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

図 3.5-2: 実施者オーダーリングのプロセスフロー
510

注： この一般的なユースケースでは、まず依頼はオーダー実施者側で実施者オーダー番号が付いて作成される。 その後、オーダー依頼者で依頼者オーダー番号が付与される。 このステップを経ると、トランザクショ
ン LAB-2 は、「オーダー依頼者、オーダー実施者の両方ともが依頼を認識する。」という役割を終える。 次のステップでラボラトリは依頼を割り振り、トランザクション LAB-1 の初期メッセージを用いて、オーダー依頼者へ“ステータス変更”を通知する。 この特別なケースでは、トランザクション LAB-1 はオーダー実施者からオーダー依頼者へ送信されたメッセージで開始するため、図中の矢印“LAB-1”はオーダー依頼者方向に向いている。 トランザクション LAB-1 は“依頼者オーダー管理”に専念し、“依頼者オーダーリング”プロセスフローと同様に、両方からのメッセージに関与しながら依頼のプロセス終了まで続行される。
3.5.3.

患者更新のフロー520
当該ケースは分析プロセスのさまざまな局面において、患者情報の更新をシステムに取り入れる状況を網羅する。 前のフロー図でインパクトがある部分のみを下図に示す。 前に記載したワークフロー図に従い、全ての順次ステップが進められる。
3.5.3.1.

依頼作成前の患者情報の更新

当該ケースは依頼者オーダーリングと実施者オーダーリングに等しく影響を与える。 依頼者オーダーリングの例（最初の 2 ユースケースに相当する部分）のみを下図に表す。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

16

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

530

図 3.5-3: 依頼者オーダーリング前の患者情報の更新
3.5.3.2.

依頼作成後の患者情報の更新

当該ケースは依頼者オーダーリングと実施者オーダーリングに等しく影響を与える。 依頼者オーダーリングの例（最初の 2 ユースケースに相当する部分）のみを下図に表す。 フロー最初の部分にあたる患者登録およびトランザクション[RAD-1]は下図に表示されていない。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

17

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

540
図 3.5-4: 依頼者オーダーリング後の患者情報の更新
注：
図のように、アクター：オーダー依頼者、オーダー実施者、およびオーダーリザルトトラッカは、最新の患者情報が ADT から直接供与される。

550

オートメーションマネージャーはトランザクション LAB-4 のメッセージを使って、オーダー実施者からの患者の最新情報を受信する。 オーダー実施者は、もし該当患者に関連する検査オーダー（work orders）をオートメーションマネージャーと通信していなければ、患者の最新情報を受信し次第オートメーションマネージャーへ
このメッセージを伝えなければならない。
新規患者情報の照合は、オーダー依頼者、オーダーリザルトトラッカ、オーダー実施者により行われる。 照合は、該当患者に関する検査オーダー（work orders）が完了していない間はオートメーションマネージャーでも行われる。
3.5.3.3.

560

依頼完了後の患者情報の更新

当該ケースは依頼者オーダーリングと実施者オーダーリングに等しく影響を与える。 依頼者オーダーリングの例（最初の 2 ユースケースに相当する部分）のみを下図に表す。 フロー最初の部分にあたる患者登録およびトランザクション[RAD-1]は下図に表示されていない。

1.0 版 –トライアル・インプリメンテーション用 03/11/24

18

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

図 3.5-5: オーダー完了後の患者情報の更新
注：
図のように、アクター：オーダー依頼者、オーダー実施者、およびオーダーリザルトトラッカは、直前の最新の患者情報が ADT から直接供与される。

570

オートメーションマネージャーが依頼と患者に関する作業を終了した場合は、患者の最新情報を通知する必要がない。 該当患者に関する新規の検査オーダー（work order）が行われるときのみ、新しい患者情報を受信する。
3.5.4.

依頼/結果の更新、状況の変化、キャンセルおよび例外の管理

依頼/結果の更新フローは、この第 1 部に記載されたトランザクション・レベルのような上位概念では明白にしていない。 （トランザクション[2]で患者情報を更新するように）依頼/結果の更新に特化した特別なトランザク
ションはない。 反対に、依頼/結果を更新するイベントはトランザクション[LAB-1]から[LAB-5]に載っている。
これらの依頼/結果更新（および依頼キャンセル）のフローはメッセージレベルで表示されるため、各トランザク
ションの詳述は第 2 部にて言及する。

580

目標は不変である： アクター内の依頼/結果に関わるあらゆる更新、キャンセル、あるいは状況変化が、依頼と関連する他のアクターへ更新内容を伝えるための全ての適正なメッセージを引き起こす。 そのため、依頼/
結果の一貫性は、相互に影響し合う全てのアクター間で保たれる。
同様の理由で、検体に関する例外管理（例： 不一致性、容器の紛失/損傷）、あるいは指示に関する例外管理（検査部門に棄却されたバッテリ）については、トランザクションレベルでは出現しない（特定のトランザクショ
ンはない）ので、各トランザクションの詳述は第 2 部で言及する。
4.

用語解説

バッテリ(Battery)： ラボへ依頼された単一名称で識別される 1 個以上のラボ検査。 例えば、≪血清電解質≫
1.0 版 –トライアル・インプリメンテーション用 03/11/24

19

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS

IHE 臨床検査テクニカルフレームワーク、第１部

はナトリウム、カリウム、塩化物および重炭酸イオンの検査を通常構成するバッテリで、血清検体に関して臨床ラボへ依頼をする。カリウムは個別で依頼されるため、チームバッテリ(term battery)とも表現される。
590

臨床検査の専門家(Clinical expert)： 臨床的な検証と、依頼またはその一部分をレポートする総合的な責任を担う人。 HL7 では“結果原論の解説者(Result principal interpreter)”と呼んでいるが、いくつかの国々では“病理学者(pathologist)”、他の国々では“生物学者(biologist)”と呼んでいる。
臨床的な検証(Clinical validation)： 臨床検査の専門家が、依頼についてラボから得た結果（検査）を容認
および解釈する過程。 生物学の歴史や、患者のために臨床検査の専門家が認識する臨床的および治療情報とともに、全ての依頼内容を勘案しながら、結果解釈を行う。 いくつかの国々では、これを“生物学的な検証”と呼ぶ。 最も単純で定例なケースを解釈するためのルールや推論に基づく知見を備えたエキスパートシ
ステムにより、このステップを実行する。 この検証のステップは、最初に依頼を指示する医師が行う診断や治療と区別するため、いかなる場合でもラボの責任下におく。

600

実施者オーダー(Filler order)： オーダー依頼者のアクターから受ける依頼者オーダーに代わり、オーダー実施者のアクターにより作成された依頼。 “実施者オーダーリング”のユースケースで既に述べたように、実施者オーダーはオーダー実施者のアクターから直接作成される。
依頼者オーダー(Placer oeder)： オーダー依頼者のアクターが作成、処理をする依頼。
技術的な検証(Technical validation)： ラボ技術者が、自らの管理下で、手動/自動化のテクニックのどちらかを使って得た単一または一連の検査を容認する過程。技術的な検証とは、規定するラボの手順で、満足のいく精度管理および他の技術的な検証基準に則り、結果/検査を確保することである。
来院(Visit)： 入院および外来患者両方に適用し、医療施設内の一意的な来院番号(visit number)で識別する。さらに、病院滞在中に患者のために行った全ての行為についての管理記録をする。フランスにおいては、“National Extension for IHE France”と題されたラジオロジ・テクニカルフレームワーク(Radiology Technical
Framework)の第 4 部を参照のこと。

610

検査オーダー（Work order）： 実施者オーダーから抽出したバッテリや検査項目の一部で、実施のためオーダー実施者のアクターからオートメーションマネージャーのアクターへ送られる。
5.

懸案事項

5.1.

将来のサイクル(cycles、年度)のための覚え オートメーションマネージャーに制御された分析セクションに検体がいつ到達したのか、オーダー実施者が知るためのトランザクション（例：ステータスモニタ）を、将来のシナリオに追加される予定。 現行サイク
ルでは、検体のラボラトリ到着は依頼状況に自動的に基づいている。

 オートメーションマネージャーはオーダー実施者に検査結果を通知するが、下記に挙げたケースでは、
620

オーダー実施者はオートメーションマネージャーに検査結果を照会する。 このトランザクションは今後シナリオに追加される予定。
1. 通信にエラーが発生して、オーダー実施者が検査結果の受信に失敗した場合は、あとで受信に失敗した検査結果を再送する必要がある。
2. オーダー実施者が全ての検査結果が受信可能なときは、それに対する準備が整った場合のみ。

 当該文書は、オートメーションマネージャーと分析装置/他の装置間でのトランザクションを定義していな
いことに留意。 これらのトランザクションは将来における IHE 年次サイクルで定義する予定。

 オートメーションマネージャーは、分析機器と通信する別のオートメーションマネージャーと通信するケースがある。 この内容も将来のサイクルの対象にするだろう。
630

1.0 版 –トライアル・インプリメンテーション用 03/11/24

20

Copyright © 2003: GMSIH, HPRIM , IHE-J,

JAHIS