Ｉ H Ｅという考え方

ＩHＥ誕生の背景

IHE とは Integrating the Healthcare Enterprise の略で医療情IHE の概念は放射線領域の医療情報システムから発祥しまし

報システムの相互接続性を推進する国際的なプロジェクトです。

た。その昔、C T、M R I などの医療機器メーカーは画像診断
機器から発生するデジタル画像情報を独自のサーバに保管し利IHE という言葉を初めて聞く方にとっては、これだけで何であ用するシステムを開発していました。当時の画像情報は開発

るかを理解することは困難なことでしょう。そもそも医療情報

メーカー独自のデータ形式であり、他社の装置やシステムで利システムとは医療を支える裏方のような存在であり、医療行為用するといった相互の互換性は存在しませんでした。

の直接的なツールではないため、医療現場で働く医療従事者にとっては関心の希薄な分野ではないでしょうか。

しかし、利用者は異なるメーカーの装置、システム間で画像情報を送受信することを望むようになります。そこで生まれた

しかし、施設の規模や場所を問わず、医療情報システムはライフラインのように医療を行う上で欠かせないシステムなのでのが、「標準規格」と呼ばれる、機器やシステムを問わずに情報の送受信を可能とするデータの規格です。

す。医療情報システムの利用経験がある方ならば、思ったように医療機器やシステムが接続できず、情報を円滑に利用できな

医用画像分野においては「DICOM」(Digital Imaging and

かったという経験をお持ちではないでしょうか。ライフライン

Communications in Medicine: ダイコムと読む ) と呼ばれるのように「使えて当たり前」とはいかないのが現状と思われま

医用画像情報の標準規格がそれにあたり、電子カルテなどの医す

図1

用文字情報の標準規格は「HL7」(Health Level Seven: エイ。

チエルセブンと読む ) がそれにあたります。この DICOM の登
IHE ではこのような問題を解決するための、ひとつの手段を提案しています。

場により、撮影・検査装置やシステムのメーカーを問わず情報の送受信が可能となりました。

理想的なシステム連携を実現できていますか？

しかし、標準規格を利用すれば必ずしも全てにおいて情報の送受信が容易に行えるかと言えばそうではありません。これは医療情報システムを利用する場面 ( ワークフロー ) が施設や運用状況によって多種多様となり、そのワークフローごとに標準規格をどのように使って情報連携を行うかというルールが明確に定まっていないためです。
人間同士の言葉のやり取りに置き換えると、日本語、英語という言語は明確になっているものの、方言が存在するために言葉が通じないのに似ています。
図11

標準規格の使い方

統合プロファイルとテクニカルフレームワーク

標準規格とは標準化によって制定された取り決めです。しかユーザーは利便性の高いワークフローを実現するために、メー

し、DICOM や HL7 に対応した医療情報システムを導入してもカーを問わないシステム連携を望みます。それを安価で容易に実格の使い方が明確でないとはどのようなことでしょうか ?

ます。このガイドラインを定める際には、事前に実際の医療現場システム間連携ができない場合もあると前述しました。標準規
例えば、DICOM 規格を大きなルールブックとします。何章にもおよぶ膨大なルールの中から “CT 画像を別システムに送る ” というルールを探し出し、システム構築の担当者間で意識合わせを行う作業はメーカー間、およびメーカーとユーザー間現するためには、標準規格の使い方のガイドラインが必要となりで一般的なワークフロー調査を行い、その上でシステム連携を実現するために必要となる標準規格の使い方を示したガイドラインを策定しているのです。

IHE では医療現場での一般的なワークフロー分析の結果であるにとっても大きな負担となることが医療情報システムを構築し業務シナリオを「統合プロファイル」と呼び、その統合プロファ

準規格の使い方を明確にするとは「DICOM というルールブッ

示したガイドラインのことを「テクニカルフレームワーク」と呼た経験を持つ方ならご理解いただけると思います。つまり、標クの○章の “CT 画像を別システムに送る ” というルールを使って下さいね」というガイド本的な役割を IHE が担うということ

イルに沿ったシステム連携を実現するための標準規格の使い方をんでいます。

Ｉ H Ｅの世界的な活動と組織なのです。CT 装置を導入している多くの医療機関に “CT 画像

を別システムに送る ” というワークフローが共通に存在するのなら、打合せ等の労力、時間や開発コストを抑えることができ、このガイド本は有効的に機能することになります。

また、標準規格を使わず、メーカー独自仕様やカスタマイズ

により接続を実現しても、導入後のバージョンアップの度に追加費用が発生する、カスタマイズがカスタマイズを呼ぶ悪循環に陥る場合もあります。このような問題はシステム導入時に限ったことではなく、システム更新時にも同様の問題が発生します。また、放射線分野に限ったことではなく様々な医療分野においても同様の課題なのです。

近年、医療の IT 化が進み、専門分野ごとの IT 化だけではな

く施設全体の IT 化という視点からのシステム連携や、他施設とのシステム連携に対するニーズが高まっています。これらを実現する場合にも標準規格を円滑に利用することが可能であれ

ば、打ち合わせやカスタマイズの省略が可能となり、導入費用の抑制や将来的な汎用性に期待を持つことが出来るのです。

IHE では、これらの標準規格の使い方が定まっていないことに起因する問題を解決するために、ガイド本にあたる “ 標準規格の使い方の「ガイドライン」” をあらかじめ提案しています。
IHE の示したガイドラインを利用することで、施設やシステ

ムごとに細かな設定やカスタマイズを行うことなく、機器やシ
ステムメーカーを問わずに連携できるシステム ( マルチベンダ

システムという ) の構築が可能となり、開発期間や開発費用の抑制が可能となります

図２

。

図２

2

図3

IHE が確立されたのは北米です。その概念は世界各国で広く受け入れられ、その活動は世界２０ヶ国以上にまで広がっています
図3。我が国では日本 IHE 協会として活動しており、放射線、

放射線治療、循環器、臨床検査、病理・臨床細胞、内視鏡、眼科、PCD (Patient Care Device)、ITI (IT Infrastructure) の 9 領 域に分かれて活動を行っています

図4。また、国際的には歯科、薬剤、 患 者 ケ ア 管 理 PCC (Patient Care Coordination)、Quality

Research and Public Health (QRPH) といった新領域に拡大し、日本においてもその歩調を合わせ、各領域の立ち上げ準備が行われています。

図4

日本で既に活動している各領域は企画部門と技術部門に分かれており、企画部門は医療施設で実務に携わる医師・コメディカルや学会等の関連団体のメンバーで委員が構成され、技術部門は

メーカーはお客様の声があって初めて製品を開発しリリースするのです。

そのため、日本 IHE 協会では IHE の考え方を広く一般の方にメーカーや医療施設の医療情報システム管理担当者で構成されてご理解いただくために、年に数回、全国各地で開催するワーク側の双方の視点から活動を行っています。日本 IHE 協会への入います。ワークショップやセミナーで用いたプレゼンテーショ

います。委員 ( 会員 ) は公募されており、ユーザー側とメーカー会については、公式 Web サイトに情報が掲載されています。

ショップや学会等でのセミナーなどを通じて普及活動を行ってン資料は日本 IHE 協会公式 Web サイトで公開しています。

ＩＨＥの活動：ＩＨＥサイクル

Ｉ H Ｅの 利 用 方 法
医療情報システムの導入や更新を予定している施設は、利用しIHE では医療現場での統合プロファイル ( 業務シナリオ ) の分

たい IHE の統合プロファイル ( 業務シナリオ ) を選択し、仕様書

析、テクニカルフレームワークの策定、コネクタソン、IHE のイルを実現するためのテクニカルフレームワークをシステム構築

ナリオ ) の導入、というサイクルで活動を行っており、この一に統合プロファイルを記載します。メーカーはその統合プロファの際に使用します。

全ての統合プロファイルが施設の要望に当てはまるかと言えば普及活動、実装製品の医療現場での統合プロファイル ( 業務シ連のサイクルをＩ H Ｅサイクルと呼んでいます

図6。

このサイクルによって、一度製品としてリリースされた後も、そうではないため、利用者は必要であると考える統合プロファイ

統合プロファイルやテクニカルフレームワークが医療現場の利用することが可能となっています。

る仕組みとなっています。

ルのみを選択し、部分的に IHE のテクニカルフレームワークを

ワークフローのニーズに合っているかどうかを検証し、改良す

ＩＨＥ対応製品の接続試験 : コネクタソン

図6

コネクタソン会場の様子

図5

一般的にシステムや医療機器を施設に導入した際には、実際にＩＨＥの用語：アクタとトランザクション

データの送受信を確認する接続テストを行います。これと同様にIHE のテクニカルフレームワークを実装したシステムや機器もデータ送受信の接続テストを行う必要があります。

しかし、対象となるシステムや機器は多数のメーカーに及ぶため、メーカーごとに個別に行うことは不可能です。そこで IHE
では年に一度、テクニカルフレームワークを実装したシステムや機器を一同に集め、数日間にわたる接続試験を行っています
図5。この長時間に渡る接続テストを「コネクト」と「マラソン」を合わせた造語で「コネクタソン」と呼んでいます。このコネク

タソンの結果は一覧表となっており、日本 IHE 協会公式 Web サ
イトから入手できます。

Ｉ H Ｅの普及活動
IHE の概念は理論的には的を射ているはずですが、それを実際

IHE 用語集：http://www.ihe-j.org/words/
本パンフレットを読み進めるにあたって、「アクタ」、「トランザクション」という言葉が登場します。テクニカルフレームワー

クは「アクタ」と「トランザクション」で表現されているからです。
「アクタ」とは演劇でいうところの登場人物のことであり、医療情報システムにおける「アクタ」とは例えば CT などの撮影装置や、装置で撮影した画像を保管するサーバや、画像表示端
末のディスプレイのことです。「トランザクション」とはこの「アクタ」の間でやり取りされる情報のことです。

日本 IHE 協会 公式 Web サイト
http://www.ihe-j.orgに広く一般的に医療情報システムに実装するためには、これを利用するユーザーからの多数のニーズが必要となります。つまり、

3

放射線領域の統合プロファイル

放射線領域の統合プロファイル ( 業務シナリオ ) 一覧

IHE 放射線部門のテクニカルフレーム
ワークは 1999 年から開発が行われ、画像情報を扱う DICOM 規格と、テキスト情報を扱う HL7 規格を活用し、ICT 技術の進歩に合わせて年々進化をし続けています。既存のプロファイルの改修に加え、特に近年では、被ばく放射線量の管理や、地域広域での画像レポート情報連携など、情報をより広く活用するためのプロファ

イルの開発が進んでおります 図 7 。
放射線領域では、22 のプロファイルが存在し、院内外に及ぶ広範の業務について、IT 化をカバーしております。以下で代表的な統合プロファイルについて簡単に説明しましょう。

予約済ワークフロー（SWF, SWF.b）
統合プロファイル SWF は、画像診断
部門で一般的に行われているワークフ
ローを実現するシステム連携をサポートしています。医療情報システムへの患者情報登録から、オーダ発行、スケジュー
ル作成、検査実施、画像収集、保存、表示、
レポート作成の間で患者情報を維持するためのトランザクションを指定した基礎

図7

予約済みワークフロー (SWF：Scheduled Workflow)となるプロファイルです 図 8 。
2013 年に日本提案により HL7 V2.5.1を採用した SWF.b が新たに定義されました。
＜関係システム [ アクタ名 ] ＞●患者情報登録システム [ADT]●病院情報システム : HIS（オーダエントリ）[OP]●放射線情報システム : RIS [OF]●撮影装置モダリティ [Aq.Modality]●画像管理保管システム : PACS [IM/IA]

図8

可搬媒体による画像データ交換（PDI）
統合プロファイル PDI は、CD-R 等のメディアに記録された画像および診断レ
ポートのインポート、表示、または印刷を確実に実行できるようにすることを目

可搬媒体による画像データ交換 (PDI：Portable Data for Imaging)

的としています 図 9 。このプロファイル
では、メディアで診断および治療に関する情報を配布するためのアクタとトラン
ザクションを指定しています。関係するシステムは可搬媒体への書き込み、読み込みを行うために次のようになります。
図9＜関係システム [ アクタ名 ] ＞●可搬用画像書き込みシステム [PMC]●可搬用画像読み込みシステム [PMI]●モダリティ [Aq.Modality]●画像管理保管システム : PACS [IM/IA]

4

なお、
日本 IHE 協会では PDI 互換チェックツール ( レベル 3) を開発し販売しています。詳しくは次の URL をご確認ください。

PDI 互換チェックツール ( レベル 3)
http://www.ihe-j.org/pdi-tools/被ばく線量管理（REM）
統合プロファイル REM は放射線撮影中に患者さんが受ける被ばく線量を管理するための機能を定義しています。
モ ダ リ テ ィ の 中 で も 放 射 線 を 使 っ た 検 査 を 行 う CT、
Projection X-ray が対象になります。モダリティから被ば
く線量情報を DICOM SR オブジェクトとして発生させ、PACS にて保管し、被ばく線量情報を活用するシステムから、その情報を検索、取得、匿名化、各種処理、表示しよ

被ばく線量管理（REM）

うというものです 図 10 。最終的には線量レジストリにて院
内、地域、広域の情報を統合的に管理することも視野に含まれています。
＜関係システム [ アクタ名 ] ＞●撮影装置モダリティ [Aq.Modality]●画像管理保管システム : PACS [IM/IA]●線量情報利用システム [Dose Consumer]●線量情報報告システム [Dose Reporter]●線量情報登録システム [Dose Register]

図 10

統合画像情報相互交換（XDS.b-I）

統合画像情報相互交換（XDS.b-I）
統合プロファイル XDS.b-I は ITI 領域の XDS.b を拡張し、
DICOM 情報（画像、エビデンス文書、Presentation Stateを含む）並びに画像診断レポートを対象にしたものです。共有したい情報は発生の際に、予め文書レジストリ（台帳）と文書リポジトリ（保管場所管理簿）に必要情報が記録管理されます。一方、画像やレポートが必要なシステムは文書
レジストリに存在確認し、文書リポジトリに格納場所を問合せ、その格納場所から実情報を取得します。画像情報の場合、Web ベース（WADO）での取得になります 図 11 。
＜関係システム [ アクタ名 ] ＞● XDS.b 文書利用システム [Document Consumer]● XDS.b 文書台帳システム [Document Registry]● XDS.b 文書管理簿システム [Document Repository]●画像文書利用システム [Imaging Document Consumer]●画像文書保管システム [Imaging Document Source]

図 11＜放射線領域のその他のプロファイル＞
統合プロファイル

略語

放射線科情報へのアクセス

ARI

他の部門から放射線科の情報（画像、読影レポート等）にアクセスするための手順を規定した統合プロファイル

解説

監査証跡とノード認証

ATN A

ノード（実装されている装置）間の相互認証を行い安全性を維持する。個人情報に関わる監査証跡を残す。

会計処理

C HG

部門システムのスケジュール管理（オーダ受け）システムと医事会計器（Charge Processor) の間で情報を交換する。

画像表示の一貫性確保

CPI

モノクロ画像の表現と表現状態情報（アノテーション、シャッター、回転、表示領域、拡大）の一貫性維持

エビデンス文書

ＥＤ

ワークステーション、撮影装置で作成される測定結果などの非画像情報、例えば診断の根拠となる情報を生成、保存する機能

フュージョン画像

FU S

複数の機器から画像を収集し、レジストレーション、ブレンドによって融合された画像の表示を行う。

メディアインポートの整合性確保

IR WF

他施設から持ち込まれた可搬媒体 (CD、フィルム等 ) 内のデータを自施設のシステムに取り込み、保存。

キー画像ノート

KIN

乳房画像

MAMMO

画像情報にメモ情報で添付し、重要な画像のみを抽出して表示する。
マンモグラフィー画像について、効果的・効率的な診断のための画像表示とハードコピー機能を定義。

核医学画像

NM

投与された放射性物質 ( R I) の体内での分布やこれをトレーサとして測定した代謝量、血流量を表す画像

複数検査手続きの一括撮影と表示

PGP

複数検査手続きを一括撮影し、表示の際には手続き単位にできる仕組みを実現した統合プロファイル

後処理ワークフロー

PWF

検査画像に対する各種の画像処理などの後処理のワークフロー。CT 画像データなどの３次元画像処理などが想定されている。

報告書ワークフロー

RWF

報告書にまつわる業務の流れを 13 のユースケースに基づき記述している統合プロファイル。他の統合プロファイルと連携・整合を保つよう工夫されている。

画像・数値を含む報告書

S IN RDICOM SR 規格に基づく報告書作成のための統合プロファイル。報告書は正式の診断報告書に入力することができる
ので、情報の再入力が避けられる。

教育・臨床トライアル用データ出力

TC E

臨床データから匿名化を行い教育用・臨床トライアル用のファイル出力を行う。

X DS - I

医療施設間で画像データを共有する仕組みを提供。インデックスをレジストリで保存、リポジトリで画像本体を保管し画像データソースの所在管理を行う。

施設間画像データ共有

5循環器領域の医療情報の特徴
循環器領域の最大の特徴は、恒常的に収縮と拡張を繰り返す心臓という臓器を扱う点です。そのため、心血管撮影、心臓超音波検査などの動画像を用いた診察が必須であること、心臓の電気的興奮を計測する心電図波形、EPS 波形、心収縮時の経時的な圧波形などの波形データを多用する特徴があります 図 12 。動画像

データは放射線領域の静止画像データと同様に DICOM による標準化が進んでいるため、IHE を利用しやすい環境下にあります。一方波形データは、現在までのところ、波形データの標準化の国際的普及は遅れており、PDF、SVG などの画像

図 12

データ（紙の心電図を画面に表示したよ

うな画像データ）として取り扱われています。そのため、比較表示が煩雑であるという問題とともに、元来波形データであるにも拘らず保存時に画像データとして扱われるために、波形そのものの解析ができないという本末転倒した不便さが生じています。また、これら画像検査や

図 13

心電図検査の施行時に、運動負荷あるいは薬物負荷が頻繁に行われることは循環器領域の大きな特徴です 図 13 。

上述の特殊性に鑑み、われわれは以下の 6 項目についてワークフローの作成に着手しています。将来的には、日本で検討が開始された波形情報、血管内画像診断などについても、国際的に用いられる

プロファイルとして完成することを目標
としています。

心臓カテーテル検査（CATH）
心臓カテーテル検査で発生する画像は動画像であり、静止画像データを取り扱う放射線領域のワークフローに類似しており、SWF、PIR、ITI/CT の 3 つの統

図 14

合プロファイルを循環器領域でも採用し、統合プロファイル CATH として提示しています。また、循環器領域では意識不明の氏名不詳患者に対する心臓カテーテル検査と治療を施行する場合があり、通常のワークフローである SWF に加えて、事後に患者氏名等が判明した場合の患者情報修正ワークフローである PIR を最初から加えて、統合プロファイル CATH としています。SWF、PIR、ITI/CT の各項についての詳細は放射線領域の項をご参照
ください。

6

波形情報（ECG）
心電図のワークフローでは 2 つのワー
クフローについて規定しています。
● 1 PDF、SVG を利用した基本的な表示

PDF、SVG 自体は世界で広く利用されている画像データ形式であり、各社機器から発生したこれらの形式の心電図画像
を１つのサーバで保管し、検査ごとの履歴として管理しています 図 14 。利用者は
WEB ブラウザで履歴一覧画面を表示し、必要な心電図履歴を選択することで画像形式での心電図波形を閲覧することが可能となります。
● 2 MFER（日本版標準規格）を利用した多様な表示

日 本 版 IHE で あ る IHE-J で は 既 にISO/TS11073-92001 として国際規格である MFER を採用しています。波形デー
タの標準規格を採用することによるメ
リットは、画像データではなく波形デー
タとしての保管が可能となるため、経時比較表示が可能となり、心電図波形解析

ツールなどの利用が可能となります 図 15
。MFER は今後、日本発の世界標準規格として期待されています。

心エコー のワークフロー（E CHO）
心エコーのワークフローは経胸壁心エ

コー、経食道心エコー、ストレスエコーを対象にしています。血管内超音波検査（IVUS）や心臓内心エコー（ICE）などは含まれていません。心エコーの統合プロ

ファイルは既存のプロファイルと共通した点が多く、SWF、PIR の 2 つのプロファ

イルをまとめて統合プロファイル ECHOとしています。SWF、PIR については放射線領域の項をご参照頂ください。

図 15

ストレス（ S T R E S S ）循環器領域の診断法の大きな特徴として、Treadmill 運動負荷検査、Ergometer
運動負荷検査、アデノシンなどの薬剤負荷 心 筋 SPECT 検 査、 ド ブ タ ミ ン 負 荷

心臓超音波検査、ジピリダモールなどの薬 剤負荷 MRI 検 査 な ど の 負荷検査が挙げられます。ドブタミン負荷心臓超音波検査は前述の “ 心エコーのワークフロー（ECHO）” に含まれるものの、運動負荷、
薬剤負荷ともにこれまでのところプロト
コールの多様性などから統合プロファイ
ル・ワークフローが確立されていませんでした。そこで、IHE-J 循環器委員会ではこれらワークフローの作成に着手しており、今後プロファイルを公表することを目的としています。

血 管 内 画 像 診 断 （IVI）
図 16

循環器領域では動脈硬化性プラークの組 織 性 状 評 価 に 血 管 内 超 音 波（IVUS）、
血 管 内 視 鏡、 光 干 渉 断 層 法（OCT） な

ど新しいイメージング法が登場しています。これら診断法は、心臓カテーテル検査のワークフローと類似していますが、カテーテル検査時に診断の必要性が決定される場合が多いためワークフローの標準化が難しく、データ量の多い動画像保存が要求されるという課題もありました。
しかし最近では、施設のインフラ整備が進むと共に DICOM 化が急速に広がってきております。現在、IHE-J 循環器委員
会では、米国と協議し心臓カテーテル検査のモダリティオプションとして制定しました (2013 年 5 月現在、Trial Implementation
Version)。

情 報 抽 出 とデータハンドリング● 2 データハンドリング

循環器領域では多施設共同研究や学会● 1 計測結果管理（ED-CARD）

主導の全国調査など、大規模な研究や調造影画像では画像情報のみならず、画像やヨーロッパでは国が主導するナショナ

循環器領域では心エコー画像や心血管解析を行った結果得られた数値情報が診

断、治療指針の決定に大きく寄与しているという特徴があります。そこでその解析結果をレポートシステムやデータベー

スシステムへ電子データ（テキストデー
タ）として送信することを可能とする統合プロファイルの開発を検討しています。
これにより解析結果の手作業による転記の手間を省くことが可能となります
図 16。

査が盛んに行われています。また、北米

ルデータベースが構築され、登録が義務付けられている国があります。日本においては、日本循環器学会等と各種工業会と連携し、波形，心エコー，心カテにおける各種計測値情報の標準的な要素定義と格納方式を定める活動を実施中です。
地域連携を意識し施設内外の情報伝達をスムーズにさせるだけでなく，レジスト
リデータベースへの登録を視野に入れた
プロファイル化を目指しています。

7

P C D (Patient Care Device) 領域の概要
PCD(Patient Care Device) 領 域 で のIHE 活動は、北米では 2005 年より開始
され、2006 年からテクニカルフレーム
ワークの検討が始まっています。日本に於いては、2009 年から PCD ドメイン設
立の準備を始め、2010 年度は、正式なコネクタソンの実施の前段階として「プレ」コネクタソンを実施しました。また、第 30 回医療情報学連合大会（浜松市にて開催）では、他のドメインとともに企画
展 示 を 行 い ま し た。2011 年 度 に は、
PCD ドメインとして正式にコネクタソンを 実 施 し、DEC プ ロ フ ァ イ ル で 3 社、ACM プロファイルで 4 社の参加があり、以降毎年コネクタソンを実施しています。
今後は DEC、ACM の拡張、他のプロファ
イルでのコネクタソン実施の検討を進めます。PCD ドメインで扱う領域は広く、装置間接続性の向上、データ形式の標準化、患者のアラーム管理・伝達、機器の管理、治療やケアに関する輸液等の指示の正確さ、埋め込み機器の管理等にまで及びます 図 17 。
これらをサイト別に見ると手術室のシ
ステム、救急のシステム、ICU/CCU におけるシステム、病棟システム等が該当します。さらに他のドメインとも合わせて病院内全てがカバーできることとなります。これらを通して患者の安全管理を充実 さ せ る こ と も 考 慮 し ま す。 さ ら に、PCD は救急車やクリニック（診療所）レベルから家庭と言う範囲までカバーする
PHD（Personal Health Device）と言う
概念とも整合を取れるよう考えています。
PCD ドメインでは各装置どうしの相互
接 続 に 関 す る DEC（Device Enterprise
Communication） と い う プ ロ フ ァ イ ル
が 基 本 と な り ま す。 さ ら に ア ラ ー ト 管
理 と し て ACM（Alert Communication
Management）、 輸 液 ポ ン プ 管 理 に
関 す る PIV（Point of care Infusion
Veriﬁcation） 等 が 主 た る 統 合 プ ロ フ ァイルとなります。その他、装置間で扱うパラメータや単位・有効桁等を調整する
RTM（Rosetta Terminology Mapping）、
埋め込み機器の管理 IDCO（Implantable
Device Cardiac Observation）、 波 形
データの管理のための WCM（Waveform
Content Module） や 装 置 の 管 理 MEM（Medical Equipment Management） 等があります。

図 17

図 18

8

図 18

各 装 置 からのデータ収集（ D E C ）統 合 プ ロ フ ァ イ ル DEC（Device
Enterprise Communication） は、 各 装
置からのデータ収集をするプロファイル

です 図 19 。このプロファイルは、PCD
ドメインの他のプロファイルの基本となるプロファイルで、アラートマネジメント（ACM）や、輸液管理（PIV）のプロファ
イルも、装置からのデータの収集はこの
DEC プロファイルを使用します。
DEC プロファイルは、装置からデータ
を 出 力 す る DOR（Device Observation
Reporter） と い う ア ク タ と デ ー タ を
受 信 す る DOC（Device Observation
Consumer）というアクタが基本となります。

アラートマネジメント（ A C M ）図 19

統 合 プ ロ フ ァ イ ル ACM（Alert
Communication Management） は、 患者及び装置に関するアラート（アラーム＋アドバイザリ）管理のプロファイルです 図 20 。
アラートデータの送受信は DEC プロ
ファイルでのトランザクションを利用し、
ア ラ ー ト の 出 力 AR（Alert Reporter）と言うアクタとなり、そのデータを AM（Alert Manager）で管理し、AC（Alert
Communicator）でメディカルスタッフに伝達します。
ACM プロファイルで特徴的なのは、ア
ラートの管理と言っても患者アラートだ
けを管理するのではなく、患者に使用される装置のアラートも管理します。

図 20

輸液ポンプの管理（PIV）
統合プロファイル PIV（Point of care
Infusion Veriﬁcation）も、輸液ポンプからの流量等のデータ収集は DEC プロファ
イルでのトランザクションを利用します

図 21 。これらのデータをもとに患者への投薬指示や輸液指示が行われますが、正しい患者に正しい投与量を正しいルートで投与することを第一義的に考えます。
投薬や輸液指示を人的なミスを防ぐことを 目 的 と し て、IOP（Infusion Order
Programmer） か ら、IOC（Infusion
Order Consumer）へ設定を伝達するトランザクションとなります。輸液ポンプ
等への実際の投与設定と開始は、その設定値を確認したメディカルスタッフが行
います。

図 21

9

I T Infrastructure ( ITI ) 領 域 とは臨床分野のワークフローで各臨床分野と直接関連の低い機能を実現するためのプロファイルを集めたものです。例えば、セキュリティ基盤、患者 ID の参照などです。また、他の分野に拡張が可能な基本的な機能を提供しています。例えば、施設間での医療情報連携・
地域連携の基盤や治験データ収集などのためのフォー
ムデータの入力や検索の仕組みなどです。 図 22 に ITIの統合プロファイルを示します。このように非常に幅広い分野に利用可能な機能を提供しています。

セキュリティ基盤
正しいユーザかどうかは､ PWP( 職員の登録簿 )､ ユ

図 22

ーザ認証については､ XUA､ アクタ間での相手認証は､ ATNA( 監査証跡とノード認証 )､ 誰がアクセスしたかの監査証跡は､ ATNA､ 改ざんはないかなどデータ完全性には､ CT( 時刻の整合 )､ 及び ATNA､ あるいは､ DSG( デジタル署名 ) が用いられ､ データ秘匿 ( 暗号化 ) については､ ATNA などの統合プロファイルを利用することができます。

医療情報連携基盤
例として医療機関Ａ､ Ｂ､ Ｃ､ Ｄがあり､ 患者はＡ医療機関で救急の治療を受けた後､ ＡとＢ医療機関に入院､ Ｃ医療機関で長期療養を行い､ 近隣の診療所Ｄで診療を受ける場合について説明します。診療所Ｄの医師は､ 患者から過去の治療経緯を聞くだけではなく､医療機関Ａ､ Ｂ､ Ｃから必要な医療情報 ( 退院サマリ

図 23などのドキュメント ) を参照します 図 23 ｡ そこで、合意を形成したコミュニティ (IHE では「アフィニティド

メイン」と呼びます ) の内部に情報の所在管理センタ( レジストリ ) を設置し､ 実際の情報は提供する各医療機関が保管サーバ ( リポジトリ ) に保存しておきます。
診療所 D の医師は、情報利用者 ( コンシューマ ) として、所在管理センタに患者の医療情報の所在の問合せを行い、その情報が保管されている保管サーバから情報を引き出すことができます。

XDS 統合プロファイルは､ 所在管理台帳 ( レジストリ )､ 提供共有情報の保管 ( リポジトリ）、情報提供者( ソース ) と情報利用者 ( コンシューマ ) という４つのアクタで情報共有する基盤を構築しています｡ その他に、Point-to-Point の通信で相手に安全にドキュメン
トを提供する方法 (XDR) や可搬媒体によってドキュメ
ントを届ける仕組み (XDM) もあります。

また、画像情報については、放射線分野の機能として XDS に類似した XDS-I.b という機能があり、画像情報の場合は、画像情報提供者 ( ソース ) に直接情報を取りに行きます。

合意を形成したコミュニティの内部での情報共有は、

XDS という枠組みで共有されますが、コミュニティ間の情報共有も IHE では提供されています。コミュニティ

10

図 24

を跨いだ情報共有の仕組み（XCA）は、 図 24 に示します。XCA では、検索をしたい患者について予め各コミュニティ内の統一患者 ID が分かっていることが前提になります。あるコミュニティから他のコミュニティへ医療情報の所在を問い合わせて、見つかったものについて共有情報の読み出しを行う機能（XCA）が可能となっています。問合せや読み出しを依頼するのが開始ゲートウェイ、各コミュニティがその問合せに応答するのが応答
ゲートウェイです。

また、放射線領域に分類されますが、XDS で文書情報でなく画像情報を対象としたものが XDS-I であるように、XCA の画像対応が XCA-I です。

患者情報参照基盤
図 25に､ 患者 ID の相互参照方法を示しています｡ 患者 ID は､ 各医療機関の 患 者 ID の 提 供 元 ( 患 者 ID ソ ー ス )によって中央にある患者 ID 相互参照マネージャに登録され管理されています｡
マネージャは､ 各医療機関からの患者
ID を相互にマッピングします｡ 各医療機関の患者 ID 利用者 ( コンシューマ )はマネージャに問い合わせ､ 自病院の患者 ID から医療連携するコミュニティ
全体の ID を知ることができます｡ この

図 25

プロファイルは､ 患者 ID 相互参照 ･ 統
合プロファイル (PIX) と呼ばれていま＜ ITI 分野における統合プロファイル一覧＞

す｡ また､ 患者名､ 生年月日などの基用 途

本情報から､ 患者 ID を知ることのできる 統 合 プ ロ フ ァ イ ル (PDQ) が あ り ま

データ管理

す。

ニティ間で行うように拡張した機能もSecurity

検討されており、複数のアフィニティ

名

称

説

明

SVS

Sharing Value Set

RID

Retrieve Information EUA と PIX と共同して CDA, PDF, JPEG などの患者情
for Display
報を検索して表示する機能。

EUA

PIX は、コミュニティ内の患者 ID の紐付けですが、この機能を複数のコミュ

略 称Enterprise User
Authentication

複数の医療機関で統一された術語セットを管理する機能。

HL7 CCOW を用いて施設内での利用者認証方法。シング
ルサインオンを実現。

PSA

Patient Synchronized HL7 CCOW を用いてアプリケーション間で患者 ID など
Applicationsを連携する機能。

CT

Consistent Time

一秒以内の誤差で時刻同期する機能。

ATN A

Audit Trail and Node 監査証跡のためにログを一元的に管理する機能と通信相手
Authenticationの端末を相互に認証し、安全な通信路を確立する機能。

PIX

Patient Identifier Cross- 病院間で同一の患者を統一された患者 ID(Master Patientreferencing
Index (MPI)) で管理する機能。

PIXV3

Patient Identifier Crossreferencing HL7 V3

PDQ

患者の基本情報（氏名、電話番号、生年月日、性別、母親の名前、出Patient
Demographics Query 産順番など）を問い合わせる機能。オプションで来院情報も扱う。

プロファイルを「地域医療連携におけ

PDQV3

Patient Demographics
Query HL7 V3る情報連携基盤技術仕様 Ver 1.1」とXDS

Cross-Enterprise 施設間で患者ドキュメント（退院サマリや検査結果など）
Document Sharing をオンラインで共有する機能。 ebXML と SOAP を使用する。

XDR

Cross-Enterprise
Document Reliable
Interchange

施設間で患者ドキュメント（退院サマリや検査結果など）をオンラインで安全に提供する機能。

XDM

Cross-Enterprise
Document MediaInterchange

施設間で患者ドキュメント（退院サマリや検査結果など）を媒体で提供する機能。

I T I プロファイル一覧

XCA

Cross-Community
Access

複数のアフィニティドメイン（コミュニティ）間で患者ドキュメント（退院サマリや検査結果など）を共有する機能。

右の表に 2014 年 10 月現在の ITI 分

XCPD

Cross-Community
Patient Discovery

複数のアフィニティドメイン（コミュニティ）間で特定の患者を捜して、紐付けする機能。

BPPC

Basic Patient
Privacy Consents

XDS アフィニティドメイン内で患者の複数のプライバ
シーポリシーに関する同意を記録し提供する機能。

PWP

Personnel White
Pages

医療機関内で職員の連絡方法や ID などを管理する機能。

XUA

Cross Enterprise
User Assertion

施設間でユーザ、アプリケーションやシステムを認証する機能。

患者管理

PA M

Patient Administration
Management

患者基本情報（氏名、性別、住所、入院／外来、病室情報など）を登録したり、適時更新したりする機能。

データ管理

R FD

Retrieve Form for
Data Capture

外部システムにデータを登録するために必要な情報を電子
カルテなどから取り出して、外部へデータを提供する機能。

MPQ

Multi-Patient
Queries

XDS レジストリに問合せをする場合に、地域の基準に基づいた集合問合せを利用可能とする機能。例えば、施設の認定、臨床試験データの収集や疫学調査など。

ドメイン（コミュニティ）間で特定の患者を捜して、紐付けする機能（XCPD）が提案されています。
日本 IHE 協会では、上記の医療情報連携基盤と患者情報参照基盤で説明した地域医療連携に使用する複数の統合

してまとめて、医療情報標準化推進協
議 会（HELICS） へ HELICS 指 針 と し連携て申請中です。

野の 22 統合プロファイルの一覧を示します（このうち XCPD のみまだ確定していませんが、重要なので掲載しました）。このようにたくさんの種類があSecurity

り、更に新しいものが提案されています。用途をデータ管理、Security、連携、患者管理などに大きく分類しています。

連携

XDS-SD

PIX を HL7 のバージョン３に対応させたもの。

PDQ を HL7 のバージョン３に対応させたもの。

Scanned Documents 書類やフィルムからスキャンされたドキュメントに患者 ID、患者情
Integration Profile
報やメタデータなどを付加して、XDS で利用できるようにする機能。

11

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

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

臨床検査分野の IHE 活動は 2002 年より開始され、日本でも同年 IHE-J 臨床検

査ワーキンググループを発足させ、国際会議に参加し提案、検討を重ねてきました。現在までに作成した統合プロファイ

ル に つ い て 示 し ま す 図 26 。 こ の う ち

LDA、LBL 統合プロファイルについては日本が中心となってまとめたものです。

院 内 検 査 ワークフロー LT W
臨床検査部門が通常行う入院・外来患者に対する検体検査業務を扱うプロファ

図 26

イルで、臨床検査部門の基本的なワークフローです。

＜関係システム [ アクタ名 ] ＞

院内検査ワークフロー LTW と検査自動化システム LDA●診療管理システム（CIS）、
病院情報システム（HIS、オーダリング）[OP]●臨床検査情報システム（LIS）、
臨床検査自動化システム（LAS）[OF]●診療管理システム（CIS）、
病院情報システム（HIS）[ORT]

臨床検査部門は、医師あるいは臨床部

門から検査オーダを受け、検査は患者から採取した検体で行われます。 図 27 において、OP から、OF に対し、トランザクショ

ン LAB-1（依頼者オーダ管理）により、検査オーダを送信します。OP は、固有の

図 27

検体 ID を記載した検体 ID ラベル（通常バーコード）および他の関連情報（患者名、診察 ID など）を供与します。臨床部門のスタッフは検体を採取し、容器に適切な検体 ID ラベルを貼付することで各検体を識別します（一般的にバーコードである

ことが多い、付加情報として患者名、診療 科 な ど が 記 載 さ れ ま す ）。 検 体 ID の

臨床現場即時検査 LPOCT

分析実行プロセスにおける、AM と分臨床検査部門の監督下で、手術室やベッ

析前／後処理装置などの分析機器間のドサイドのような臨床現場で行われる＜関係システム [ アクタ名 ] ＞

場即時検査）のワークフローです 図 28 。

ワークフローです 図 27 。

POCT（Point of Care Testing ／臨床現フォーマットと長さは、臨床検査の組織●臨床検査情報システム（LIS）、
臨床検査自動化システム（LAS）[AM]●分析機器 [LD]

監督する内容には、POCT の結果の臨床

わなくてはなりません。

AM が OF からの検査オーダを受信し、れる、適切な検査の実践についての教育

内およびシステムや機器の制約条件に従
検査オーダが受信されると、OF により

それを 1 つあるいは複数の検査ステップ

り当てられ、トランザクション LAB-2（実ケンスに分割し、各ステップは LD を実受諾される場合、実施者オーダ番号が割

オーダ（Work Order Step、WOS）のシー

的検証、精度管理（QC）サーベイランス、試薬の補充、病棟のスタッフに対し行わが含まれます。

＜関係システム [ アクタ名 ] ＞

WOS が単一の検体上で実施されます。

●臨床検査情報システム（LIS）、
臨床検査自動化システム（LAS）[OF]●オートメーションマネージャ（OCT 機器から集中してデータを集める）[POCDM]● POCT 機器 [POCRG]

いては、OF から ORT に、トランザクショのスタッフが操作する AM と LD との間

LPOCT 統合プロファイルでサポートされます。

スタッフが操作する装置については、別

タ は、POCRG と POCDM。POCDM をため、LDA の範囲外です。

POCRG からの結果を収集し、結果の管施者オーダ管理）により、OP に送信されます。検査結果は、オーダされた検査とオーダされていない検査両方に対して発行される場合があります。検査結果につン LAB-3（オーダ結果管理）により送信

12

検査自動化システム LDA

装する自動装置（自動分析装置や検体前／後処理の装置が該当する）が担当し、LDA プロファイルでは、臨床検査部門のワークフローを示しています。病棟のするワークフローでサポートされるアクのプロファイル LPOCT でサポートするが患者検体および精度管理検体に対する理を行う OF に送信します。

採取管準備 LBL

臨床現場即 時 検 査 LP O CT

検体検査依頼に基づき採取容器にバー

コードラベルを貼る「採血管準備装置」
に関するワークフローです 図 2 9 。

LBL 統合プロファイルがサポートする

ワークフローでサポートされるアクタは、
LIP および LB です。LB はラベル情報を受信し、ラベルを出力します。LIP は通常、LTW 統合プロファイルの OF および OPとグループ化されます。

＜関係システム [ アクタ名 ] ＞●診療管理システム（CIS）、
病院情報システム（HIS、オーダリング）、
臨床検査情報システム（LIS）、
臨床検査自動化システム（LAS）[LIP]●ラベル発行機 [LB]

LB は、ラベル発行指示を受動的に通知

図 28

採取管準備 L B L

されることが可能です。あるいは、この指示を得るため、LB が LIP にクエリを行うことが可能です。

検 査 コ ー ド の 更 新 LC S D
LTW の複数の異なるアクタあるいはシステム間において、共通の検査コードを使用するための検査コード更新ワーク
フ ロ ー で す（LCSD：Laboratory Code図 29

Set Distribution）。

検体検査結果報告書の共有 XD-LAB

検体検査分 野 の I HE -J が 使 ⽤ す る 標 準

他施設へ伝達するための電子的文書の共有リソースへ発行される臨床検査

レポートを取り扱う統合プロファイルです。例としては、ITI テクニカルフレーム

ワークで定義される文書共有プロファイ

ルが使用された、医療機関で共有される、Electronic Health Record（EHR） あ る

い は Personal Health Record（PHR）などがあります。ある患者に対する検査

結果を含み人間にとって判読可能であり、データベース内で検査結果を統合するため、コンピュータにより判読可能なフォー
マットでなければなりません。

検体検査分野の IHE が使用する標準

図 30(1) データ交換メッセージ

検体検査のデータ交換メッセージは、

HL7 Ver2.5 を使用しています 図 30 。ただし XD-LAB だけは HL7 Ver3.0 を使用
しています。なお、HL7 Ver2.5 をベースに、IHE との整合性に配慮して策定された、「JAHIS 臨床検査データ交換規約」

が参考になります。
(2) 検査項目コード
検査項目コードについて、IHE-J では

JLAC10（臨床検査項目分類コード）を採用しています。

なお最新のテクニカルフレームワークは次の URL からダウンロードできます。
IHE Laboratory Technical Framework
http://www.ihe.net/
Technical_Framework/index.cfm

13また、ワークフロー関係の統合プロファイ ル に 関 し て は HL7 Ver.2.5 を 参 照 標

準としていますが、日本語の資料として
HL7Ver.2.5 準拠の JAHIS 臨床検査デー
タ交換規約最新版を参照してください。
JAHIS 臨床検査データ交換規約

http://www.jahis.jp/jahis_hyojyun/seiteizumi_hyojyun/

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

ルを適用する」と書けば済みます。

IHE 導入により期待される効果の一つ

病理・臨床細胞領域との統合

ダリングシステム）、LIS（臨床検査シス

は 2 つのドメインスコープに多くの類似として、HIS（電子カルテシステムやオーテム）どちらか一方のシステム更新の際に、システムメーカーの選択肢が増えるとともに、円滑に移行可能であることが挙げられます。また要求仕様書を作成する場合も、一般的な検体検査のワークフ
ローについては「IHE の LTW プロファイ

臨床検査、病理・臨床細胞のドメイン性を確認し、互いの資産を再利用しようという共通の思いにより、2016 年 1 月より、病理検査医学（PaLM：Pathology

and Laboratory Medicin）として合併し活動を開始しました。

病理・臨床細胞領域の統合プロファイ ル
病 理・ 臨 床 細 胞 領 域 の IHE 活 動 は、
2005 年 9 月からは米国、欧州、日本が協力して推進しています。病理学統合プロファイルでは、他分野と同様に、標準的なワークフロー（WF）を設定しており、医療情報システムへの患者情報登録から、オーダ発行、検査実施、各種病理画像収集と保存、レポート作成と保存、それら結果の端末への表示、の一連の業務フローを実行するためのアクタとトランザクションを指定しています 図 3 1 。 現在まで、病理部門システム（APIS）と病院情報シス
テム（HIS）などの関連システムが容易に接続できるようにするガイドラインとして、 病 理 学 テ ク ニ カ ル フ レ ー ム ワ ー ク（ P T F W ： P a t h o l o g y Te c h n i c a l
Framework） が 作 成 さ れ て お り、 日 本
IHE 協会のホームページから入手できます。
＜関係業務 [ アクタ名 ] ＞

図 31●組織診 [SP : Surgical Pathology]●細胞診 [CP： Cytopathology]●剖検 [CA： Clinical Autopsy]●研究 [RP： Research Pathology（Tissue Micro Array の一部 ) ]今後の展開
病理部門における HL7 V2.5 準拠のデー
タ交換規約 (JAHIS 病理・臨床細胞データ交換規約 ) と、画像格納のための DICOM 規格(JAHIS 病理・臨床細胞 DICOM 画像規約 )の標準化資料は既に完成しており、JAHISのホームページから入手できます。本資料を元に、病理部門システムの実装とコネクタソンへの参加が期待されています。
本規約は、DICOM WG-26 で検討が完了したスライド上の標本全体をデジタル画像化する装置（バーチャルスライド）の効率的なファイル方法、及び手術材料・生検材料の病理標

本の構造情報 図 3 2 について記載しています。

14

図32

バーチャルスライドの画像は数ギガバイ
トにも及ぶ巨大な記憶容量を必要とするため、その保存、検索、表示には工夫が求められています。1 枚のバーチャルスライド画
像を 1 辺が 1 千〜 4 千画素のタイル画像に分割して保存する方法が提案されています。
その際には観察に必要と想定される様々な倍率の画像も予めタイル画像に分割してピラミッド状に用意することで、効率よい検索や表示を実現しようとする方法です。バーチャルスライド画像の DICOM 標準化により、ユーザーは自分の要求に最も適したス
キャナ・画像サーバ・ビューワを選択することが可能となります。また病理領域画像のデジタル化・標準化の進展により、放射線画像、内視鏡画像、病理画像等を平行表示が可能となります。これにより、放射線医、
病理医、内視鏡医、などの画像診断において新たな利用方法の広がりが期待されています。

放射線治療領域の統合プロファイル

放射線治療実施時ワークフロー (TDW)

放射線治療 スケジューリングワークフロー (ESI)

放射線治療領域の IHE 活動は 2004 年
よ り 北 米 で 開 始 さ れ ま し た。 日 本 で は2006 年より活動を始めました。放射線治療領域では、現在 3 つの統合プロファイ
ルが公開されています。また、1 つの統合
プロファイルが公開へ向けた文書化作業を行っています。
放射線治療計画のためのワークフロー
としては「放射線治療計画ワークフロー（BRTO）」と「放射線治療のためのマルチ
モダリティイメージの登録（MMRO）」があり、放射線治療実施のためのワークフ
ローとしては「放射線治 療実施時ワーク
フロー（TDW）」があります。「放射線治療スケジューリングワークフロー（ESI）」
は放射線治療依頼と放射線治療の照射スケ
ジューリングのためのワークフローです。
各々のプロファイルのワークフローを簡単に説明します。

TDW 統合プロファイルは、放射線治療での日々の照射を実施するときのワークフローです。放射線治療情報システムは日々の照射に関するワークリストの管理を行います。ユー
ザーは放射線治療装置を操作し、放射線治療の照射を実施します。まず、放射線治療情報システムで作成された放射線治療の照射ワー
クリストを放射線治療装置が取得します。また、取得したワークリストに関連して放射線治療情報をアーカイブから取得します。次に、ユーザーはワークリストに従って患者のセッ
トアップと放射線治療の実施を行います

ESI 統合プロファイルは、文書化作業中のプロファイルです。放射線治療に関する治療依頼の発行、照射スケジュールの作成および、照射実施情報の情報連携を行うためのワーク
フローです。病院情報システムは放射線治療
依頼を発行し、放射線治療情報システムでは照射スケジュールの作成と照射実施の通知を行います。放射線治療では、治療依頼が発行された時点で放射線治療の詳細が決定していません。詳細内容が決定した段階で放射線治療情報システムが照射スケジュールを作成し病院情報システムに通知を行います。また、照射の実施が終了すると病院情報システムへ実施完了情報の通知を行います 図 35 。
このプロファイルは日本からの提案で文書化が進められています。このワークフローにより病院情報システムと放射線治療情報シス
テムでの情報連携が推進できると期待されています。
＜関係システム [ アクタ名 ] ＞

放射線治療計画ワークフロー (BRTO)
放射線治療計画ワークフロー（BRTO）
は、放射線治療計画を立案する時のワーク
フローです。このプロファイルでは、放射線治療計画装置を機能によって 4 つのアク
タとしています。輪郭情報を作成する放射線治療計画装置、照射計画を作成する放射線治療計画装置および、線量分布を計算す
る放射線治療計画装置で放射線治療計画情報を作成し、線量分布表示装置にて放射線治療の照射情報と線量分布の表示を行います。アーカイブは放射線治療計画情報の保存機能を 持っている必要があります。各
放射線治療計画アクタと線量分布表示装置
アクタは、必要とする治療計画情報をアーカイブから取得します。また、各アクタで作成したデータは他のアクタが利用できる
ようアーカイブへ保存を行います。このワークフローを適用することで、放射線治療計画をマルチベンダシステムで行うこと

図 34 。照射が完了すると放射線治療装置は放射線治療情報システムへ照射が完了した通知を行います。このワークフローを適用する
ことで、放射線治療領域でも照射実施時のワー
クリスト管理が可能となります。

＜関係システム [ アクタ名 ] ＞●アーカイブ［Archive］●放射線治療情報システム [TMS]●放射線治療装置および操作コンソール［TDD］●病院情報システム（オーダリング）［HIS］●放射線治療情報システム［TMS］

図 33が可能となります 図 33 。

＜関係システム [ アクタ名 ] ＞

図 34●輪郭情報を作成する放射線治療計画装置［Contourer］●治療計画を作成する放射線治療計画装置［Geometric Planner］●線量分布を計算する放射線治療計画装置［Dosimetric Planner］●線量分布表示装置［Dose Displayer］●アーカイブ［Archive］
図 35

15

内 視 鏡 領 域 の 統 合 プロファイル
内 視 鏡 領 域 の IHE は、 経 済 産 業 省 の「医療情報システムにおける相互運用性の実証事業」のもと、2006 年 9 月に公開された「IHE 消化器内視鏡テクニカルフ

レーム Year1: 2005-2006（上部消化管）
Volume I 統合プロファイル」に始まりました。
月

そ の 後 の 検 討 を 経 て、2010 年 7に「IHE Endoscopy TechnicalF r a m e w o r k Ye a r 4 : 2 0 0 9 - 2 0 1 0（Upper/Lower Gastrointestinal Tract）
TrialImplementation Version」を発表しました。この新しいテクニカルフレーム

ワークに基づき、同年 10 月にはコネクタ
ソンの実施に至っています。

内視鏡消化管プロファイルである EWF

図 36

は、放射線の SWF が基になっていますが、内視鏡検査独自のワークフローに対応するために異なる点もあります。

まず、内視鏡の検査はリアルタイム画

像にて診断が行われ、内視鏡の写真撮影を終えても検査終了となりません。その所見・診断結果を検査レポートとしてまとめた時点で検査終了となります。そのため EWF ではレポート作成システムをフロー中に入れて、検査レポート作成が終了したことを内視鏡検査システム（EIS）に知らせるフローを持たせるとともに、画像取得のフローは別のプロファイル(EIA) としました。

IHE 勉強会の様子
発行人

発行所

一般社団法人日本 IHE 協会

一般社団法人日本 IHE 協会※無断転載禁止

今後の展開としては、現在未定義である、画像取得のプロファイル（EIA）のす。この点に関しては、HIS から病理部

IHE 国際にて正式に内視鏡ドメインが誕

レポート作成システムから HIS に向けて、ワークをもとに、日本発の国際ガイドラ

ダが発生するのも内視鏡独自のフローで検討があります。また、2010 年 4 月に、門へのオーダを出すことができるように、生しました。現在のテクニカルフレーム

検査レポートを送るフローを持たせましインを作成することも今後の課題です。

た 図 36 。

消化器内視鏡のテクニカルフレーム

ワークは、下記の URL から入手できます。
http://www.ihe-j.org/tf/＜関係システム [ アクタ名 ] ＞●病院情報システム（オーダリング）[HIS]●内視鏡検査システム [EIS]●レポート作成システム [REPORT]

endoscopy02/index.html

コネクタソン審査員席
普及推進委員会〒 113-0033 東京都文京区本郷 3-40-11
柏屋ビル南館 4 階

16

また、内視鏡検査中に生検を行うことがありますが、この場合に病理検査のオー

コネクタソン会場より

日本 IHE 協会公式 Web サイト：http://www.ihe-j.org/
用語集 URL：http://www.ihe-j.org/words/
問合せフォーム URL：http://www.ihe-j.org/contact/
2016 年 3 月発行