鈴鹿中央総合病院では，2007年に大規模なシステム更新，新規システムの導入を控えており，現在，IHE-Jの実装も視野に入れてシステムの選定を行っています。
ところで，IHE-JではDICOMやHL7の使い方を示すガイドラインが示されており，医療業務のワークフローを定義したものが“統合プロファイル”であるということは理解しているのですが，具体的に，電子カルテのオーダ種のうち，どの程度までをカバーしているのかがわかりません。

現在定義されている統合プロファイルは，主に放射線領域と検体領域で，循環器領域や内視鏡領域，病理などにも，どんどん拡張しています。

HL7で標準化するとは言っても，会計などではアメリカと方式が違うために，対応できない部分がありますね。その場合，日本のベンダーが独自解釈して製品を開発しているのでしょうか。

そのとおりです。これまではシングルベンダーでシステム構築を行う医療機関も多く，そのベンダーの仕様に合わせれば，何も問題はありませんでした。しかし，今後はマルチベンダーによるシステム構築が増えてくると思いますので，そうなったときには，IHE-Jなどが示したHL7やDICOMについてのガイドラインに則って，各ベンダーがシステム開発を行うという流れになってくると思います。標準化が進むことで，医療機関にとってはコストの低減にもつながります。

確かに，各医療機関がシングルベンダーで独自にシステム構築をするよりも，マルチベンダーで必要なシステムが選択でき，値段も安く，運用もスムーズであれば，そのメリットはとても大きいと思います。

システム構築の際に必要な費用には，システムの費用と人件費があります。パッケージであればシステム構築の費用は抑えられますが，システムエンジニア（SE）の人件費は予想以上に高額です。人件費は，テストも含めて，SEが現場でどの程度の時間をかけるかで決まりますが，各医療機関の独自の部分が多ければ多いほど，当然時間がかかります。言い換えれば，時間の短縮が大幅なコストダウンにつながるのです。
岡崎市民病院では，システムの導入に必要な費用のうち，約6割が人件費でしたが，IHE-Jガイドラインを採用したことで，その人件費を大幅に抑えることができました。なぜなら，IHE-Jガイドラインを採用したシステムでは，すでに“コネクタソン”という接続試験が終わっているため，その分，確認作業にかかる時間が短縮できるからです。もちろん，IHE-Jがすべての業務に対応しているわけではないので，確認作業もゼロにはなりませんが，必ず時間は短縮されます。

毎年行われているコネクタソンでつながったシステム同士は，実際に必ずつながるということなのでしょうか。

コネクタソンではアクタ同士をつないでいますので，そのアクタが採用されている製品同士はIHE-Jでつなぐことが可能です。IHE-Jでは，3システム以上と接続できれば合格を表す「○」，接続評価が一部不足しているものは「△」といった星取り表を用意していますので，それが参考になると思います。

毎年4月に開催されているJRCでは“CyberRad”という，IHE-Jを採用したシステム同士をつなぐデモツアーを行っています。それに参加していただけば，IHE-Jでシステムをつなぐということが，よくわかっていただけると思います。

ただ，コストについては，2006年11月の医療情報学会で行われたセッションの中で，標準化をしようとすると，逆にシステムの値段が高くなってしまうということが話題になっていました。

残念ながら，現状では確かにそのとおりです。IHE-Jに則った製品がこれまでなかったために，新規開発になってしまう部分が多いからです。ただ，これは過渡期の現象です。以前は，例えばCTにDICOMを採用しようとすると，必ずその分の費用が発生していました。が，いまでは頼まなくても付いてくる。IHE-JもDICOMと同じような流れをたどっていくと思います。

統合プロファイルはいまいくつありますか。

数え方の違いで，50以下という人もいれば，60以上という人もいます。放射線部門から進んでいきましたので，カバーしている部分も放射線部門が一番多いです。現在は，電子カルテの部分が進んできていますし，逆に，看護については議論が進んでいないというように，温度差があります。

私は，システム構築に必要なのでHL7やDICOMなどの標準規格については勉強しているつもりです。IHEができるまでは，確かに標準規格の解釈はベンダー任せでしたね。

そうです。そして，その使い方を統合プロファイルによって示したのがIHEです。つまり，IHEという新しい規格ができたわけではなく，使い方を示しているだけなのですが，資料には複雑なことが書いてある（笑）。

IHEでは，医療機関の標準的な運用をある程度想定した上で，統合プロファイルを定義していると思うのですが，その順番には幅があるのでしょうか。

通信の方法は，順序や表示方法にかかわらず，どれも同じです。統合プロファイルに示されているのは，患者情報を送るときに使うのはHL7の何々です，ということだけです。例えば，“患者さんの情報を送る”というのはSWFやPIRの中に示されていますが，“どのタイミングで患者さんの情報をどの部門システムに送るか”までは決まっていません。ですからその情報を，ボタンを押したときに送信するか，何もせずに自動で送るか，部門側が取りに来るか，各施設が自由に選択できます。また，“SWFの要素となるアクタをすべて実装しないとIHEを実装したことにはならない”という考え方は，よくある誤解の1つです。必要なものを必要なだけ実装すればよいのです。
例えば，岡崎市民病院では，全部門システムで自動的に患者情報の整合性を確保したいと考えて，PIRやLIR（検体検査における患者情報の整合性確保の統合プロファイル）を8部門（電子カルテ，放射線，検体検査，生理，調剤，透析，眼科，給食）すべてに実装しました。それは，当院にとって必要だろうと判断したからです。また，IHE-Jには，処方の部分についてはHL7のガイドラインが示されていないのですが，ほかのシステムと同じガイドラインに則ったHL7を実装しています。

つまり，統合プロファイルは，HL7やDICOMといった標準規格を応用する際のガイドだということでしょうか。

そうです。このトランザクションは，この通信に使えばやり取りできます，というガイドです。
当院を例に挙げると，電子カルテシステムを作った日立製作所は，“医事システムで患者情報が登録されたら，それを部門システムに送る”という仕組みを1つ作り，それを8部門に適応しました。もちろん，かかった費用は1つ分だけです。つまり，日立製作所ではもうこの仕組みは持っていますので，次の施設が同じ仕組みを採用するときには，工数が減ることになります。

各メーカーのシステムがすべて標準化され，それをそのまま導入できるようになれば，とても便利ですね。

鈴鹿中央総合病院では，まず，オーダリングシステムから電子カルテに替えます。そのほか，検体検査システム，物流システム，輸血管理システムはスタンドアローンタイプなので，ネットワークに接続していきます。新規導入では，RIS，看護支援システム，病理部門システムがあります。ですから，必然的にマルチベンダーになります。
そこで，IHE-Jガイドラインに則っていろいろな部門システムを連携させるのと，単にHL7やDICOMなどの標準規格を採用する場合とでは，何が違うのでしょうか。

システムを構築する際には，まず，オーダリングなどの上位システムがあって，その下にたくさんの部門システムがあります。その際，上位のシステムが決めた通信の方法にすべてのベンダーが合わせる場合と，部門ベンダーにすでに仕様書があって，その仕様に上位システムのベンダーが合わせる場合とが考えられます。後者の場合，上位のベンダーはA社仕様，B社仕様の仕組みを作って，それぞれをつないでいきます。放射線部門で言えば，RISとモダリティはそういうつなぎ方になるのですが，HISと各部門システムの場合は，できればHISに合わせて一本化したいという希望をベンダーに出し，IHE-Jを選択するということになってくると思います。

私たちは通常，システムの運用をベースに考えます。現在の運用を，医療安全等も考えてどう効率良くしていくか，そのために必要な機能は何かを考えるわけです。予算面から考えて，導入するシステムは当然パッケージベースになりますが，どれだけカスタマイズを少なくできるのかということも考えながら仕様書を作りました。しかし，その後どうすればIHE-Jを採用できるのか，ということがわかりません。

先ほどは通信，連携についてですが，いまのお話は，機能や運用ということですね。そうなると，それはIHE-Jを実装するかどうかとは，ちょっと違う部分になります。IHE-Jが定義しているのは，あくまでも情報をどう連携させるかということです。IHE-Jでは，上位システムから部門システムへと情報を正しく送ります，ということを約束しているだけなんです。

では，当院が今度導入するシステムをIHE-Jで接続するとしたら，具体的にはどうなるでしょうか。

検体検査と放射線領域は問題なく接続できます。病理についても，オーダと患者連携については可能です。統合プロファイルのSWFとLSWFを使えば，これらの大半は連携できます。ただし，これはあくまでもHISから各部門へという流れです。逆の流れは現在のIHE-Jでは難しいですが，実現させる方向で検討が始まっています。

他院の患者さんの検査依頼を受けると患者情報が発生します。これまでは，例えば病理検査の場合，システムはスタンドアローンタイプで，しかも紙でオーダを出していましたので，検査の際にその患者さんのIDを作るということは行っていませんでしたし，それでも運用上の問題はありませんでした。ですが，電子カルテを導入するとなると，検査依頼の患者さんでも当院のIDが必要になります。ただ，患者さんが持ってくる外部の情報は，他院の患者IDになっていますので，どうやって整合性を保てばいいかと考えているのですが。

IHE-Jには，患者情報の整合性を保つための統合プロファイルがすでに用意されています。他院から来る画像や，そのほかの検査結果には他院のIDが付いてますから，そのままでは電子的に見ることはできません。それを解決するための仕組みは，独自で作るとなるととてもやっかいです。

放射線科では，撮影部位がイレギュラーになることがあります。例えば，手を撮影する場合に左右が逆だったり，情報の読み違いによって，まったく違う部位がオーダされるといったケースです。その場合は，電話で医師に確認し，オーダを変更してもらうのですが，RIS側で変えたデータをHISに反映させることは可能でしょうか。

そのトランザクションはIHEにはありますが，IHE-Jにはありません。そもそも，日本のベンダー自体が，そういう製品開発を行っていないので，岡崎市民病院でも，埼玉医科大学でも実現できていないです。

IHE-J委員会では，下から上への情報の流れをIHE-Jで実現するための検討をすでに始めていますので，いま上位システムから部門システムへの流れを標準化しておけば，次のリプレイスで追加することは容易です。

IHE-Jでは，トランザクションが記載されている表があるんですが，今回適用した部分に丸をつけておけば，次に何を採用すればいいのかということが，一目でわかります。そして，この表のすべてに丸が付いた時点で，院内の情報システムすべての標準化が完了した，ということになります。これは，システムや担当者の世代交代という長期的な視点から見てもメリットがありますし，短期で考えた場合も，今回はこれを実装した，次はこれ，というように，計画的に標準化が進められます。

大切なのは，各医療機関ごとにワークフローをもう一度見直すことです。イレギュラーな運用があったときの対応は病院独自の流れになることもあるので，IHE-Jになじまない場合はIHE-Jを選択しないということもあるでしょう。そういった部分については，各医療機関が方針を決めていく必要があります。

つまりIHE-Jの“いいとこ取り”をすればいいのですね。

IHE-Jの実装にあたっては，統合プロファイルについて勉強する必要があると思いますが，どの程度の知識が必要でしょうか。

すべて勉強してからシステムの構築を考えるのでは，それだけで何年もかかってしまいます。すでに情報の流れが線として出来上がっているのであれば，その中にIHE-Jで該当するものがあれば使おうと思ってもらえればいいわけです。

IHE-Jガイドラインに含まれているかどうかはわからないけれども，ここはHL7にしよう，これはDICOMにしよう，という考え方ならできると思います。

それはあくまで，HL7やDICOMを知っていることが前提です。知らない人は対応できないので，そのためにIHE-Jでガイドラインを示しているわけです。また，もしHL7を知っていたとしても，すべてをわかっているわけではないなら，ほかにもこういうものがありますよ，ということがIHE-Jには示されています。IHE-Jでは，HL7の通常の記述と違って，運用を考慮した記述になっていますので，それもユーザーにとっては1つのメリットです。

各部門の担当者にも，IHEについてある程度知っておいてもらう必要がありますね。

もちろん，そのとおりです。IHE-J委員会が出している資料の中に，「SWFは“通常運用のワークフロー”」，「PIRは“患者情報の整合性確保”」などと書かれている図がありますが，まずは，その統合プロファイルで何ができるかという項目をつかんでおけば十分です。そして，これとこれにIHE-Jが取り入れられるということと，どのベンダーに声をかければよいのかというのをコネクタソンの表で確認し，話し合いをするときにアクタを見ればいいと思います。

ベンダーには，どのように臨んでいけばいいのでしょうか。

もうすでに，岡崎市民病院や埼玉医科大学などでIHE-Jによるシステム構築を経験しているベンダーがありますので，そのようなベンダーに「情報連携はIHE-Jで」と言ってみるのが簡単な方法ではあります。ただ，それ以外のベンダーであっても，要求仕様書に「情報連携はIHE-Jで」と書けば，対応できる企業は増えてきていると思います。

候補はベンダーに示してもらい，そのときに改めて統合プロファイルやアクタを見ます。そして，結果として，ユーザーとベンダーがIHE-Jという共通の認識のもとにシステム構築を進めることが可能になります。

それなら，あまり詳しく知らなくても大丈夫ですね。最初は資料は読み込まずに，項目だけ知っておく。その上で，要求仕様書に「IHE-J」と書く。これがIHE-Jの実装を実現するための，第一歩ということですね。