最新 IHE 入門 2022 刊行にあたって
日本 IHE 協会 副理事長
三浦公嗣

2019年から世界に広がったCOVID-19によって、市民生活は大きな影響を受けています。三密を避けるなどの日常生活上の制約のみならず、職場での仕事の進め方についても、例えば在宅勤務やリモート会議など、今まであまり見かけなかった手法が導入されるなど、感染拡大当初はともかくとして私達は次第に新しい環境に慣れつつあります。
もちろん医療現場への影響も例外ではありません。院内感染がクラスターに拡大し通常の診療活動ができなくなった医療機関は言うに及ばず、自らそのことを選択したか否かを問わずすべての医療機関がCOVID-19感染者に対応することを前提として診療を行うことを余儀なくされています。
感染制御という観点からは、人と人との接触をできるだけ避けることやスタンダード・プリコーションの実施が徹底されることとなり、患者や医療関係者とのコミュニケーションには今まで以上に細心の注意を払う必要が生じるとともに、次第にオンライン診療をはじめとして、今までとは違ったモードでの医療提供も珍しくなくなってきました。ここに医療情報システムの新たな展開が期待される新分野が拓かれつつあると言っても過言ではないかもしれません。
また、医療分野の研究開発に目を転じてみると、例えば新薬の開発では従来の無作為二重盲検というような多額の費用が必要となる方法に加えて、日常診療で得られた医療情報をReal World Dataとして利用するという新しい方法論も提案され、実際にその実現に向けて国を挙げての対応を進めつつあります。医療情報がその患者自身の診療に生かされるだけではなく、社会全体での医療の発展に寄与する時代が着実に近づきつつあるというのが現在の医学・医療の姿です。その場合、例えば電子カルテに入力されたデータを利用するとしても、データの信頼性等についての確認が必要になり、単に情報を伝送したり共有するだけではすまないことは明らかです。今後は一段と高い品質の医療情報が求められることになり、そのための体制が必要になってきます。つまり、データ
そのものにより高い価値が置かれるようになればなるほど、そのインフラにはより高い精度が求められることになってくると言えましょう。
一方で、通奏低音のようにわが国で鳴り響くのは人手不足を指摘する声であり、医療・介護分野も大変な人手不足に直面しています。もちろん患者への直接
4

的なケアにあたる人材の確保は急務でありますが、上述のように医療情報の高度利用を進めていくためには、高度化を担う人材の確保も不可欠です。このため必要な人材を養成するとともに、貴重な存在である専門家がその専門分野に傾注できる環境を形成していくことも重要です。
これからの医療の発展を考えれば、単に医療情報の活用が求められだけでなく、その品質を担保することを通じて利用できるデータの総量を高めていくことがますます肝要になってきています。日本IHE協会は医療情報の品質向上の一端を担う組織として、本書を通じて最新の状況を読者の皆様に提供し、その活動を支援してまいります。

5

執筆者一覧
■ 編集
日本 IHE 協会 普及推進委員会

■ 編集者
安藤 裕

日本 IHE 協会 代表理事

（埼玉メディカルセンター）

細羽 実

日本 IHE 協会 副理事長

（京都医療科学大学）

関 昌佳

日本 IHE 協会 理事■ 執筆者 （アイウエオ順）
阿部 聡

日本 IHE 協会 net-PDI 委員会（アレイ株式会社）

安藤 裕

日本 IHE 協会 代表理事

石井 尚実

日本 IHE 協会 臨床検査委員会 委員長（株式会社日立ハイテク）

越後 洋一

日本 IHE 協会 循環器技術委員会 委員長（日本光電工業株式会社）

大関 毅

日本 IHE 協会 循環器委員会

大森 真一

日本 IHE 協会 内視鏡技術委員会 委員長（埼玉メディカルセンター）（オリンパスメディカルシステムズ株式会社）
奥田 保男

日本 IHE 協会 普及推進委員会 委員長

喜多 紘一

日本 IHE 協会 ITI 委員会 （保健医療福祉情報安全管理適合性評価協会）

木村 雅彦

日本 IHE 協会 ITI 委員会（日本アイ・ビー・エム株式会社）

木村 通男

日本 IHE 協会 副理事長

（浜松医科大学医療情報部）

小山 武彦

日本 IHE 協会 PCD 委員会 委員長（日本光電工業株式会社）

近藤 恵美

日本 IHE 協会 病理・臨床細胞委員会（シスメックス CNA 株式会社）

塩川 康成

日本 IHE 協会 理事

篠崎 和美

日本 IHE 協会 眼科企画委員会 委員長

鈴木 昭俊

日本 IHE 協会 病理・臨床細胞委員会 委員長

関 昌佳

日本 IHE 協会 理事

細羽 実

日本 IHE 協会 副理事長

（京都医療科学大学）

本田 憲業

日本 IHE 協会 副理事長

（埼玉石心会病院）

三浦 公嗣

日本 IHE 協会 副理事長

（藤田医科大学）

宮川 力

日本 IHE 協会 ITI 技術委員会

6（量子科学技術研究開発機構）（東京女子医科大学）（株式会社ニコン）（株式会社ファインデックス）

１ はじめに『医療情報システムは、どうして複雑で、かつ高価なのでしょうか?』
病院で医療情報システムに携わっていると、このような疑問を考えることが多くないでしょうか？同じような医療情報システムであっても、各病院で微妙に違っており、病院の数だけいろいろの医療情報システムが存在しているのが現状です。各病院で別々の医療情報システムを使わざるを得ないのは、各々の病院のワークフ
ロー（業務の流れ）が標準化されていないのが原因といえます。このような状況では、医療情報システムを納入するメーカは、それぞれの病院に合わせて医療情報シ
ステムや機器を手直しする必要が生じます。この手直しが莫大なコストや手間のかかる最大の理由です。
本書は、このような医療情報システムの複雑かつ高コストな現状を踏まえたうえ
で、医療情報システムや情報機器の導入や更新のときに是非読んで頂きたい本です。医療情報システムの構築に関心があり、また、医療情報システムを利用している方に、情報システムの無駄な投資を予防できる解説書です。
前述の通り医療情報システムの複雑性や高コスト性の原因は、医療情報システムが標準化されていない点です。このような場合に、ぜひIHEのワークフローを参照
して標準的なワークフローの導入を検討して下さい。標準的なワークフローに準拠
したシステムや機器ならば安価に導入することができます。
IHEとは、Integrating the Healthcare Enterpriseの略です。その日本語訳は、「健康や医療を管理する病院など医療機関を統合すること」となります。もう少し説明すると、IHEは健康増進や疾病治療の分野を対象とし、病院内だけでな
く、地域の医療施設においてこれらの医療施設内・外で情報を連携して、効率的に業務を行うことを推進します。IHEの目標は、3つあり、一つは、標準的な業務ワー
クフローの提案をすることです。2つ目はそのワークフローを実現するための技術的なガイドラインを作成すること、最後3つ目はIHEに準拠した機器の接続テストを行い、その結果を公表することになります。
（安藤 裕）

１．１

IHE の成果物

IHEの目的は、医療機器やシステム間でスムーズに情報をやり取りすることです。医療機器やシステムを利用する場面は、色々あると思いますが、多くの病院
13で共通しておこると予想される場面を分析して、共通の利用場面を作成します。
この共通の利用場面において、どの機器やシステム間で、どのようなタイミング
で、どのような情報をやり取りするかをIHEは技術的ガイドラインを決め、文書化しておきます。このIHEが文書化したものが成果物です。標準的な業務ワーク
フローを決めたものが、統合プロファイル（Integration Profile）と呼ばれます。統合プロファイルには、業務ワークフローだけでなく、情報のやり取りをどのような規格を用いて行うかが記載されます。一般には、広く用いられている標準規格を用いて定義します。このようにして分野別に該当する統合プロファイルをまとめたものが、技術定義書（Technical Framework）となります。IHEは、
国際的な活動のため、この技術定義書は英語で書かれています。そのため、日本の病院関係者の方にとっては、利用しづらいかも知れません。日本IHE協会のホームページには、和訳もありますので是非参照してください。IHEの技術定義書の説明は2.2.2節「テクニカルフレームワーク」に、統合プロファイルの説明は
2.2.3節「統合プロファイル」に記載されています。
（安藤 裕）

１．２ IHE と仕様書
医療機関において情報システムを利用するユーザーの方は、システムを新たに導入する場合や更新する場合に、IHEのアウトプットである統合プロファイル
や技術定義書を参照して、導入のための仕様書を簡単に書くことができます。シ
ステムや機器の導入のときに、仕様書に「IHEの○○統合プロファイルに準拠すること」という文言を記載すれば、簡単にIHEを利用することができます。この参照した統合プロファイルは、業務フローや標準規格の使い方を定義しています
ので、それらの詳細を記載する必要はありません。
その際、IHEの統合プロファイルにはどのようなものがあるかを理解しないと、仕様書には書けません。技術定義書の読み方は、2.3節「テクニカルフレーム
ワークの読み方」をご覧下さい。簡単に概要を理解するには統合プロファイルのUse case（ユースケース）のパートを読むことをお勧めします。ユースケースの説明は2.3.3節「ユースケース」にあります。分野別の統合プロファイルは4章「各ドメインの概要」に、放射線分野から始まり、いろいろな分野の統合プロファ
イルが説明されています。特に統合プロファイルのユースケースを読むことにより、そのプロファイルの大まかな機能が理解できると思います。
繰り返しになりますが、是非システムの導入のときには、仕様書に「○○統合
プロファイルに準拠すること」を記載するのをお忘れなく。
（安藤 裕）
14

１．３ 相互運用性を活用し業務の効率化を図る
システムや情報機器がたくさんあると、それぞれの端末で同じ事を入力する必要があるかも知れません。このような業務の効率化を妨げるような端末は、是非改善することが望まれます。IHEはシステムや機器の「相互運用性」を向上させることを目的としています。「相互運用性」とは、システムや機器の間で情報のやりとりをして、情報を共通利用することです。たとえば、医師が電子カルテに入力した現病歴や主訴を看護師が再利用したり、画像検査を行うときに診療放射線技師が参照したり、読影する医師が再利用したり出来ることを意味します。多くの病院では、他の医療機関からの紙に書かれた紹介状を見ながら、概要を再入力しているかと思われます。相互運用性が確保されれば、紹介状から自動的に文章を再利用することが可能となります。このような入力をする場面は、
ごくありふれたことだと思います。しかし、IHEのような相互運用性を向上させる方法が導入されれば、一度入力したものは、再入力しないで利用が可能になります。
（安藤 裕）

15

２ IHE 入門
２．１ IHE 概要
２．１．１ 目的・理念
IHEとはIntegrating the Healthcare Enterprise の略で医療情報シ
ステムの相互接続性を推進する国際的なプロジェクトです。IHEという言葉を初めて聞く方は、これだけで何であるかを理解することは困難なことでしょう。そもそも医療情報システムとは医療を支える裏方のような存在であり、医療現場で働く医療従事者にとっては関心の希薄な分野ではないでしょうか。しかし、施設の規模や場所を問わず、医療情報システムは電気、水道、ガスのようなライフ
ラインのように医療を行う上で欠かせないシステムなのです。医療情報システムの利用経験がある方ならば、思ったように医療機器やシステムが接続できず、情報を円滑に利用できなかったという経験をお持ちではないでしょうか。ライフラ
インのように「使えて当たり前」とはいかないのが現状と思われます。IHEではこのような問題を解決するための、ひとつの手段を提案しています（奥田 保男）

２．１．２ 生まれた背景・成立ち
IHEの概念は放射線領域の医療情報システムから生まれました。その昔、CT、MRIなどの医療機器メーカは画像診断機器から発生するデジタル画像情報を独自のサーバに保管し利用するシステムを開発していました。当時の画像情報は開発メーカ独自のデータ形式であり、他社の装置やシステムで利用するといった相互の接続性や互換性は存在しませんでした。
しかし、利用者は異なるメーカの装置、システム間で画像情報を送受信することを望むようになります。そこで生まれたのが、「標準規格」と呼ばれる、機器やシステムを問わずに情報の送受信を可能とするデータの規格です。医用画像分野においてはDICOM（Digital Imaging and Communications in
Medicine：ダイコムと読む）と呼ばれる医用画像情報の標準規格がそれにあたり、電子カルテなどの医用文字情報の標準規格はHL7（Health Level
Seven：エイチエルセブンと読む）がそれにあたります。このDICOMの登場により、撮影・検査装置やシステムのメーカを問わず情報の送受信が可能となりました。しかし、標準規格を利用すれば必ずしも全てにおいて情報の送受信が容易
16に行えるかと言えばそうではありません。これは医療情報システムを利用する場
面（ワークフロー）が施設や運用状況によって多種多様であり、そのワークフロー
ごとに標準規格をどのように使って情報連携を行うかというルールが明確に定
まっていないためです。人間同士の言葉のやり取りに置き換えると、日本語、英語という言語は明確になっているものの、それぞれに方言が存在するため一概に日本語といっても意味が通じない場合があるのに似ています。
DICOM規格やHL7規格が病院内で使用されていますが、IHEの業務シナリ
オはそれらをどのように使用するかを解説しています（図２．２．１）。IHEの対象
範囲は、病院あるいは病院間などにおける情報共有や情報交換を含めた業務全
般となります。ここで注意してほしいのは、IHEにより医療機関のすべての業務を実現することは困難であることです。IHEは、例えば電子カルテシステムのすべての機能をIHEで置き換えることは、現状では不可能です。そのため、IHEで置き換えることができる部分をIHEで実装するようにしてください。IHEで実現できない業務フローの範囲は、無理にIHEを使用する必要はありません。そのため、適材適所でIHEを使用します。

【図２．１．１：IHE概念図】
HIS：Hospital Information System病院情報システム、RIS：Radiology
Information System放射線情報システム、PACS：Picture Archiving andCommunication System画像管理システムなどでHL7やDICOM規格が使われて情報が伝達されます。IHEで実現できる部分を実装することが重要です。

（奥田 保男）

２．１．３ 歴史
IHEは1999年、北米放射線学会（RSNA）と医療情報・管理システム学会（HIMSS）が中心となってその活動を開始しました。RSNAが主体ということもあり、はじめは放射線診断領域の業務をターゲットにして第一歩を踏み出しています。2001年8月には日本でも日本医学放射線学会（JRS）、日本放射線技術
17

学会（JSRT）、医療情報学会（JAMI）といった学術団体が中心となり、さらに2つの工業会（JIRA：日本画像医療システム工業会、JAHIS：保健医療福祉情報シ
ステム工業会）と医療情報システム開発センター（MEDIS-DC）の6団体で「IHE-Jプロジェクト」がスタートして、経済産業省の補助金を受け本格的な活動が始まりました。2004年には米国心臓病学会（ACC）も加わって循環器部門の検討が始まりました。さらには大陸、地域ごとの活動として北米（アメリカ、カナダ）、アジア・オセアニア（オーストラリア、韓国、台湾、中国、シンガポール）やヨー
ロッパ（オーストリア、フィンランド、フランス、ドイツ、イタリア、イスラエル、オラン
ダ、ノルウェー、スペイン、スイス、トルコ、イギリス）にも支部ができるなど、国際的な広がりを見せています。
現在の日本では前述した6団体に加えて、日本眼科医療機器協会（JOIA）、日本眼科学会（JOS）、日本循環器学会（JCS）、日本病理学会（JSP）、日本放射線腫瘍学会（JASTRO）、日本歯科放射線学会（JSOMR）などともに100団体を超える団体会員と個人会員によって構成されています。
国際的なIHEの体勢は、図２．１．２に示すように、国際委員会の下に、地域
IHE（ヨーロッパやアメリカ、アジア/オセアニアなど）と領域別IHEに分かれて活動しています。

【図２．１．２：IHE Internationalの組織構成】（奥田 保男）

２．１．４ 検討領域（ドメイン）
IHEの検討領域とはIHEが活動する上で医療機関の業務における専門分野に近いものです。創設時のRadiology（放射線領域）に始まり、Laboratory（臨床検査）、Anatomic Pathology（病理・臨床細胞）、Endoscopy（内視鏡）、Radiation Oncology（放射線治療）、Cardiology（循環器）、Eye
18

Care（眼科）、Dental（歯科）、Pharmacy（薬局）があります。さらに総合的なインフラや医療機器、情報管理の領域として、IT Infrastructure：ITI（IT基盤）、Patient Care Device：PCD（患者ケアデバイス）、Patient Care
Coordination：PCC（患者ケア連携）、Quality、Research and Public
Health：QRPH（品質・研究・公衆衛生）が存在します。

【図２．１．３：IHEドメイン概念図】

日本では日本IHE協会の組織として放射線、放射線治療、循環器、臨床検査、内視鏡、病理・臨床細胞、眼科、ITI、PCDの9つの検討領域が活動しています。
近年の国際的な動向に合わせるために歯科、薬剤、PCC等の検討領域設立の検討を行っています（図２．１．３）。
次の図は日本IHE協会の組織図です（図２．１．４）。各ドメイン（分野）別に企画委員会と技術委員会があります。さらに、各ドメインを横断的につなぐ委員会として、普及推進委員会、RFP（Request For Proposal）委員会、国際委員会、
接続検証委員会（接続テストを担当）、CAｓC委員会、netPDI委員会、RFP委員
会があります。また、IHEに関する知識や技術を習得された方を認定するための組織として認定技術者試験委員会が発足しています。

19

【図２．１．４：IHE-J組織図】（奥田 保男）

２．１．５ IHE サイクル・活動内容
IHEでは医療現場での統合プロファイル（業務シナリオ）の分析、テクニカルフ
レームワークの策定、コネクタソン、IHEの普及活動、実装製品の医療現場へ統合プロファイル（業務シナリオ）の導入、というサイクルで活動を行っており、この一連のサイクルをIHEサイクルと呼んでいます（図２．１．５）。このサイクルによって一度製品としてリリースされた後も、統合プロファイルやテクニカルフレーム
ワークが医療現場のワークフローのニーズに合っているかどうかを検証し、改良する仕組みとなっています。

【図２．１．５：IHEサイクル】

20

IHEサイクルでは、業務シナリオを作成する段階で、ユーザーとベンダとが相互に協力し業務シナリオ（ワークフロー）を定めることが特に重要な活動です。また、コネクタソンと呼ばれる接続テストは、他の標準化活動では全く行われていません。このコネクタソンはIHEのユニークな点です。
このIHEサイクルによる活動は、意義のある重要な活動ですが、それを実際に広く一般的に医療情報システムに実装するためには、これを利用する医療機関のユーザーから多数のニーズが必要となります。つまり、医療機器、システムメ
ーカはお客様の声があって初めて製品の開発を行い、開発した製品を医療の現場に提供します。そのため、日本IHE協会ではIHEの考え方を広く一般の方にご理解いただくことを目的に、年に数回全国各地で開催するワークショップや学会等でのチュートリアル、セミナーなどを通じて普及活動を行っています。また、学会などでは同時に機器の展示を行い、IHE活動を広報しています。これらのワー
クショップやセミナーで用いたプレゼンテーション資料は日本IHE協会公式
Webサイトで公開しています。
（奥田 保男）

２．１．６ IHE のスコープ（IHE 採用でできること、別に検討が必要なこと）
2.1.4 検討領域（ドメイン）で示した通りIHEの検討領域は医療機関すべての業務を含むものではありません。IHEで対応できる範囲は、あくまでも検討領域（ドメイン）が存在する分野となります。現在、輸血部門やリハビリテーション部
門、給食栄養部門等に関する領域では、業務シナリオが想定されておらず、IHEで対応することはできません。加えて地域毎、国毎にも導入しているドメインは異なりますので注意が必要になります。さらに、日本でIHEを実装する場合は、
日本語の対応を考慮する必要性や日本独自のきめの細かい診療行為や医療安
全に加えて保健医療システムへの配慮、などを考慮して日本IHE協会ではNational Extensions（国別の拡張定義）を定めています（図２．１．６）。

21

【図２．１．６：IHEのスコープ概念図】

IHEの業務シナリオは前述したように多くの施設で共通に行われるワークフ
ローにスコープをあて、最も基本的なシナリオを想定して、各統合プロファイルが提供されています。IHEのドメイン中で最も歴史のある放射線ドメインにおいても、単純にIHEを導入すれば、すべての情報連携、運用が可能になる訳ではありません。IHEの導入が各医療機関でシステム導入時に検討すべき項目がすべて無くなる訳ではないのです。つまり、医療機関における独自の運用や、疾患別の専門医療機関の場合は別途検討すべき項目が必要になります。例えば放射線
オーダ時の制限事項を設ける、オーダ枠の設定、強調・注意アラートの表示、患者基本情報にアレルギー、副作用情報の連動、ペースメーカ、埋め込み金属の有無等の情報連携、RISの画面の見易さ等々、システム的に考慮した方がもっと便利になる、有効的になる点に関してはメーカ側との十分な検討が必要なのです。
IHEがスコープとしている領域を部分的に利用して導入作業を進めることで医療機関、メーカ双方が共通の認識を持つことが可能となり、システム導入のコ
ストや手間を大幅に削減することが可能となります。
（奥田 保男）22

２．２ IHE の用語
IHEの理解を深めるためにはIHEで使用されている用語を理解することが大変重要になります。IHEでは3文字または4文字の英略語で表現される用語が多く、初めてIHEに出会う方が取りかかりにくく感じる要因にとなっています。
しかし、最初から全ての用語を理解する必要は無く、まずはここで紹介する5つのキーワードを理解し、IHEの全体像をつかむことで、個別の詳細な略語の理解がより容易になります。

２．２．１ IHE 活動の成果（TF、IP、Actor、Transaction）
IHEは活動の成果としてテクニカルフレームワーク（Technical
Framework：TF）と呼ばれる文書の作成と、このテクニカルフレームワークに準拠しているかどうかを確認するために行われるコネクタソン（接続テスト）の実施が活動の柱となっています。テクニカルフレームワークは以下の図に示すように、放射線、臨床検査、循環器などの検討領域（ドメイン：Domain）に分かれています（図２．２．１）。ドメインは各診療部門の領域だけでなく、医療情報の基盤となるITインフラに関する領域も用意されています。

【図２．２．１：IHEの領域】

ドメインごとに独立したTFは、一つ以上の統合プロファイル（Integration
Profile：IP）から成り立っています。含まれているIPの数は、ドメインによりまちまちです。IPを実現する為に、アクタ（Actor：ある機能を示します）とトランザクション（Transaction：情報のやり取り）を用いて表現しています。次の図２．
23

２．２に示すように、ひとつのIPには、必ず2つ以上のアクタが含まれ、アクタ間の情報のやり取りがトランザクションとして規定されています。IHEを理解する上で、この統合プロファイルや統合プロファイルに含まれるアクタ、トランザクシ
ョンを理解することは重要ですが、必ずしもすべて覚える必要はありません。

【図２．２．２：IHEの用語解説：アクタとトランザクション】（細羽 実）

２．２．２ テクニカルフレームワーク
テクニカルフレームワークは、一つのドメイン（領域）に一つ定義されます。テク
ニカルフレームワークには、そのドメインのすべての統合プロファイルが記載されます。また、各統合プロファイルには、どのようなアクタとトランザクションがあるかも明記されます。統合プロファイルの実現に必要な技術文書もテクニカル
フレームワークに記載されています。ひとつのドメインの統合プロファイルがす
べて集められた文書がテクニカルフレームワークになります。
次の図は、放射線ドメインの統合プロファイル（Integration Profile：IP）の例を示しています（図２．２．３）。図の中の赤丸で囲ってあるSWFは、一番使用頻度の高いIPです。図の下部にあるのがインフラ関連であり、その上がコンテン
ツ関連、更に上部がワークフロー関連となります。

24

【図２．２．３：統合プロファイル一覧：放射線ドメイン】（細羽 実）

２．２．３ 統合プロファイル
テクニカルフレームワークに記載された統合プロファイルは、一連の業務フローを実現する見本です。統合プロファイルには、より具体的な医療情報の利用シーンが記載されています。放射線ドメインのテクニカルフレームワークに記載されている予約検査ワークフロー（Scheduled Workflow：SWF）を例に説明します。
IHEの会話の中で最も登場するのが統合プロファイルの英略語になります。この英略語の意味を理解することはとても重要です。SWFとは放射線領域の通常業務上で、日々行なっている検査予約を伴うワークフローのことになります。

25

【図２．２．４：統合プロファイル例：SWF】

上の図２．２．４に示すように患者が来院すると初診患者の場合は患者の登録をします。放射線画像検査が必要な場合は画像検査オーダを発行します。オーダ
は、画像検査装置へ転送され、患者情報が登録されます。画像検査は検査部門で実行され、撮影された画像はサーバに保管され、読影レポートが作成され依頼元の診療科へと返されます。このような一連のワークフローを表現したもの
を統合プロファイルと呼びます。テクニカルフレームワークはこの統合プロファイ
ルが複数個まとめられた文書です。
（細羽 実）

２．２．４ アクタ
統合プロファイルはアクタとトランザクションで表現されます。アクタとは、業
務フローの中でひとつの機能を実現するひとまとまりの機器と理解してください。統合プロファイルでは、患者基本情報の登録、検査オーダ発行や検査オーダの実行などの行為により情報が移動します。この行為を実現するための機能のことをアクタと呼びます。アクタは演劇で言うところの「登場人物」です。例えば
オーダの実行機能のことをOF（Order Filler：検査オーダを受け付ける機能）と表現します（図２．２．５）。

26【図２．２．５：アクタとトランザクション：SWF】

IHEではシステムの機能を表現するためにアクタという概念を使用しました。
例えば、システムの導入や更新にあたったユーザーとベンダが会話する際に、「オーダエントリーシステムでオーダを発行して、放射線部門システムでオーダを実施する。」というような表現をすることがあります。ユーザーにとってはシステ
ム単位での表現の方が理解しやすいのですが、OFの機能が電子カルテシステムにある場合や、放射線部門システムにある場合と、製品によって機能を実現するシステムが違う場合があります。ユーザーもベンダも機能単位でシステムを表現することで、実現したい統合プロファイルを理解する際に曖昧にならないようにしています。
（細羽 実）

２．２．５ トランザクション
トランザクションはアクタ間の情報連携の方法になります。アクタからアクタへ情報伝達する場合の、データフォーマットやデータ転送プロトコルなど情報伝達する場合に必要なものがすべて規定されます。トランザクションでは標準規格を用いた情報の伝達が定義されています。例えば、放射線ドメインのSWFであれば、HL7やDICOMを用います。標準規格は広く多くの製品で使用できることが必要なため曖昧な表現方法を用いている場合があります。そのため、標準規格を使用したとしても必ずしも適切に情報連携ができるとはりません。このような曖昧性をなくすために、標準規格の使い方を定義する必要があり、IHEのトラ
ンザクションではこの目的のために詳細が定められています。
（細羽 実）
27

２．３ テクニカルフレームワークの読み方
２．３．１ TF の構成
Technical Framework（TF）は医療情報システムを統合運用するためのそれぞれの装置の機能について記述しています。TFはそれぞれのドメインに唯一1つ作られます。ドメイン毎にTFには1つ以上の統合プロファイルが定義されています。TFは誰にでも無料で公開されていて、最新のものはhttps://www.ihe.net/resources/technical_frameworks/ で入手可能です。日本

IHE協会ではこれらの一部の日本語訳をhttps://www.ihe-j.org/tf/で公開しています。
TFの構成は、l Integration Profilesl Transactionsl National Extensions
l Content に関する記述
l Contents Modules
l Semantic Contentなどが記載されています。ドメインによっては省略される部分もあります。IHEが始まった当初は、トランザクションに関する規格の記述だけで内容（Content）
はありませんでしたが、今ではプロファイルによっては内容の定義が重要であることから内容（Content）も記述されるようになりました。
TFには巻末記事としてAppendixが記載されます。古いTFは基本的に以下のような構成になりますが、最近のTFでは異なっています。
l Appendix A：アクタとその定義のリスト
l Appendix B：トランザクションその定義のリスト
l Appendix C：コンテントモジュールのリスト
l Appendix D：用語リスト

放射線ドメインを例にとりますと、TFは以下のような4巻構成になっています。
l Volume 1 (RAD TF-1): Integration Profilesl Volume 1x (RAD TF-1x): Appendices to Integration
Profilesl Volume 2 (RAD TF-2): Transactionsl Volume 2x (RAD TF-2x): Appendices to Transactionsl Volume 3 (RAD TF-3): Cross-Transaction Specifications
and Content Specificationsl Volume 4 (RAD TF-4): National Extensions28

2022/03/10公開の Revision 20.0では、1巻には放射線ドメインで定義されている４９のプロファイルが記述されています。2巻と3巻ではそれぞれのプ
ロファイルで使用されるトランザクションやその内容が記述されています。4巻は国や地域での特性にあわせた拡張仕様が記述されています。この版では日本の拡張仕様も掲載されています。
IHEのTFは常に改良が加えられています。放射線ドメインでは1年ごとに新しい
プロファイルの開発を行い、その統合プロファイル（Supplement）をコネクタソンでテストを行います。ある程度参加ベンダが増えて普及するとそのプロファイル
をTFに追加します。また、既に定義されたプロファイルへの改善提案も検討され、合議によってTFの改訂が行われます。
新しく開発されたプロファイルは、Supplements for Trial
Implementationとして公開して一般から意見を求めます（publiccomments）。そして、ベンダの対応ができればコネクタソンでテストされます。十分にテストされ、仕様が確定した後にTFの文書として追加されます。
IHEでは、その他にTFに記述する内容ではないがIHEによる統合運用のために知っておくべき知識をまとめたWhite papersも公開しています。例として、放射線ドメインでは2021年までに５つのWhite paperを公開しています。その中で一番古い歴史的なドキュメントは、2004年に公開されたDepartmental
Workflowです。ここでは、放射線部門の業務について様々な例を示して解説しています。また、最新のものは、2022年3月10日に公開されたCode
Mapping in IHE Radiology Profilesです。
またIHEの導入ガイドとしてUser handbookを公開しています。IHEを使った統合運用が可能なシステムを導入する方法や現行のシステムを更新する方法などが記述されています。日本IHE協会でも、IHE導入のためのセミナーを開催した
り、解説書籍を発行したりしています。本解説書籍もその一環です。
（安藤 裕）

29

２．３．２ 統合プロファイルの概要・スコープ
統合プロファイルは、一定の範囲の業務をシステム間で情報を連携することにより実現させたものです。プロファイルは多くの医療施設の業務を分析して多くの施設で受け入れらえるものになっています。しかしながら、国や地域の特性で共通の統合プロファイルに入らない仕様については、国別拡張（National Extension）
としてTFの中で記述されます。放射線ドメインを例にすると、最も基本的な統合プ
ロファイルは、日常的に行われる検査業務の流れを実現するものでScheduled
Workflow：SWF予約検査ワークフローがあります。
統合プロファイルは、一般的に行われる業務をもとにしたシナリオが実現できる
ように、情報を連携すべき装置とその役割を決めます。役割を持った装置はアクタと呼びます。統合プロファイルでは、これらのアクタがどのタイミングでどのような情報をやり取りするかも決めています。これをトランザクションと呼びます。シナリ
オにおいてアクタの役割を明確にすることで、トランザクションの詳細が決まります。これにより、統合プロファイルを実現するための部品としての装置の仕様が明確になり、異なるベンダ（メーカ）の製品の組み合わせであってもシステムが実現可能になります。
トランザクションは、既に標準規格として確立したものが使われます。逆に言えば、標準規格のない情報伝達方法を使わねばならないようなプロファイルは作ることができません。
プロファイルは、業務の部分を定義したものですので、IHEのプロファイルをすべて使っても実際の業務がすべて網羅されるわけではありません。一方で、IHEのプロファイルは必要なもののみを導入することができます。
TFにはそれぞれのプロファイルによって実現される業務が記述され、そのプロファイルを実装するための技術的な詳細も記述されています。これにより、ユーザーである医療施設はどのような業務が実現可能か分かり、そのために必要な技術的な詳細はベンダである技術者に任せることができます。一方で、技術者は医療業務の詳細ではなく、技術的な詳細に注力して装置の開発ができます。具体的には、医療施設が新たなシステムを導入する場合に要求仕様書（RFP）にどのアクタとして機能するかを記載することでベンダは不足のない技術的要件を知ることができ、要求仕様作成にかかるコストを抑えることができます。
TFは名前のとおり「枠組み」ですので、その枠組みの中で必要に応じて様々な機能や能力を実現します。各ベンダがTFに準拠して製品に実装することになります。
これらの実装を事前にテストするのがコネクタソンと呼ばれる接続テストです。コ
ネクタソンですべての事象の確認はできませんが、基本的な情報のやり取りが決30

められており、これに沿ってテストされます。コネクタソンで複数のベンダがTFに従って実際に接続試験を行うというのがIHEの特徴です。
（安藤 裕）

２．３．３ ユースケース
統合プロファイルを理解するうえで、具体的な例が提示されています。これをユースケースと呼びます。統合プロファイルでは、業務の進行に従ってどのような装置がどのような情報を連携し、職員はどのような動きをするか網羅的に記述されています。ユースケースを提示することで、具体例で装置の動きや情報の流れが理解できます。また、統合プロファイルを設計する段階では、いろいろなユースケー
スが検討されています。これによって、様々な状況にも対応できる汎用性の高い
プロファイルが設計できるのです。
ユースケースはTFの中にも、解説の具体例として記述されています。放射線科の診断レポートを例にすると、放射線ドメインのReporting Workflow（報告書作成ワークフロー）プロファイルには11のユースケースが記述されています。診断
報告書を作成する流れとして、テンプレート（雛型）の編集によって作成する場合やディクテーション（口述筆記）によって作成する場合、2人の診断医によって読影される場合、指導医が承認する場合など実際の診断レポート作成には様々な業務の流れが想定されます。このような様々なユースケースへ対応するための例をTFの枠組みのなかで記述することで、システムが実現する詳細について、ユーザーもベンダも同じ視点で確認することができます。
（安藤 裕）

２．３．４ アクタの仕様
前述のように各ドメインのTFには複数（一つ以上）のプロファイルが記述されています。このプロファイルを実現するための機能はアクタと呼ばれ、その仕様はTFに記述されています。アクタの仕様はプロファイルごとに決められるので、IHEに対応した装置を導入する場合には、どのドメインのどのプロファイルのどのアクタであるかを明確にする必要があります。アクタはIHEのプロファイルを実現する役割の単位なので、装置が複数のアクタを実装していることもあります。ベンダは販売する装置について、IHEのどのTFのどの統合プロファイルのどのアクタを実装しているかについて記載した文書を発行します。この文書をIHE Integration
Statements（統合宣言書）と呼びます（2.5節「TIPS2：情報の探し方・製品編」
参照）。
31

IHEを導入したいドメインとプロファイルが決まっている場合、どの装置が適合しているかについては、コネクタソンのテスト結果表を参考にするとよいでしょう。
日本における毎年のテスト結果はhttps://www.ihe-j.org/connectathon/で公開
されています。
（安藤 裕）

２．３．５

アクタ・トランザクションのダイアグラム

統合プロファイルを実現するには、仕様に基づいたアクタの実装が必要です。アクタは他のアクタと情報のやり取りをして業務を遂行します。この情報のやり取り
はトランザクションとして統合プロファイルで定義されていています。どのアクタか
らどのアクタへ、どのタイミングでどの方法でどのような内容の情報を送るかが詳細に決められているのです。これを図にしたものが統合プロファイルのワークフロ
ーのダイアグラムです。
例として、以下に放射線ドメインの基本的な統合プロファイルであるSWFのダイ
アグラムを示します（図2.3.1）。四角で囲われたものがアクタです。実線はアクタ間でやり取りされるトランザクションです。

【図2.3.1：SWFのダイアグラム】

32

上の図2.3.1では、どのタイミングでどのトランザクションが行われるのかが分かりにくいので、時系列に従ってトランザクションを表したものがプロセスフロー
ダイアグラムです。
例として、以下に放射線ドメインのSWFの検査実行プロセスのプロセスフローダイ
アグラムを示します（図2.3.2）。

【図2.3.2：SWFのプロセスフローダイアグラム】（*RAD-23のトランザクションは、SWFのトランザクションではありませんが、理解しやすくするために表示してあります。）

上の図では縦の破線が各アクタを表し、横方向の矢印がトランザクションです。
縦方向が時間の流れです。トランザクション名はワークフローのダイアグラムに対応します。上から下に向かって時間が経過し、ワークフローが進行します。この図をみると、あるアクタが他のアクタからどのタイミングでこのトランザクションを受け取り、またどのようなトランザクションを他のアクタに送るのかが分かります。これにより、アクタはどのタイミングで何をすべきかが明確になります。
（安藤 裕）

33

２．３．６

参照している標準規格

前述のようにIHEのトランザクションは標準規格が用いられます。現時点で使用されている規格は下記のものがあります。今後、必要があればこれ以外の標準規格も取り入れられます。IHEではそれぞれのプロファイルのなかで規格をどのように使うべきかを定義しますが、規格そのものを定義することはありません。したがってトランザクションの詳細はそれぞれの標準規格の定義に従います。
l ASTM（American Society for Testing and Materials）
l DICOM（Digital Imaging and Communications in
Medicine）
l HL7（Health Level Seven）
l IETF（Internet Engineering Task Force）
l ISO（International Organization for Standardization）
l OASIS（Organization for the Advancement of Structured
Information Standards）
l W3C（World Wide Web Consortium）

放射線ドメインでは主としてDICOMとHL7が使われます。ドメインによっては、他のドメインのトランザクションを参照している場合があります。
（安藤 裕）

34