Comments
Description
Transcript
EHR相互運用性情報基盤：IOP-H
EHR相互運用性情報基盤：IOP-H Industrial strength InterOperability Platform for Health (IOP-H) あらまし カナダ全域への生涯健康医療電子記録（EHR：Electronic Health Record）の更なる普及 推 進 の 一 環と し て ， 富士 通 は ， EHR 相 互 運用 性 情 報 基盤 （ IOP-H ： InterOperability Platform for Health）の開発をケベック州より委託された。このシステムは，多種多様か つ地理的・組織的に分散配置されている各医療機関のアプリケーションソフト間を患者の診 療情報が高信頼・セキュア・追跡可能な形態で送受信できることを担保する，堅固かつ柔軟 性のある高性能統合プラットフォームである。そして，この情報フローに関するアクセス権 と事象発生の論理シーケンスは，規約で定められており，全カナダの医療情報システム標準 に準拠するものである。 Abstract In order to sustain the evolution toward a pan-Canadian Electronic Health Record (EHR), Fujitsu was mandated to develop the InterOperability Platform for Health (IOP-H) which can be viewed as a robust, flexible and high-performance integration platform that ensures the reliable, secure and traceable flow of patients’ clinical information between applications located in technically diversified and physically or organizationally distributed environments. This flow is controlled by rules governing the access rights and the logical sequence of events and is abiding by pan-Canadian standards for the Health sector. Pierre Coderre Fujitsu Consulting Canada Inc. 所属 現在，IOP-Hの開発に従事。 FUJITSU. 61, 4, p. 407-415 (07, 2010) 407 EHR相互運用性情報基盤：IOP-H ま え が き ある。 カナダにおけるEHRSの概要 生 涯 健 康 医 療 電 子 記 録 （ EHR ： Electronic Health Record）は長年進化を続けてきたが，EHR システム間の包括的相互運用性に欠けるため，異な Infowayは，相互運用可能なEHRSをカナダ全域 で実装することを目標にしている。 る自治体や言語の異なる広範な地理的領域で共有で Infowayは現在，九つのプログラム領域を対象に き，また安心して使えるといったまでには至ってい 投資しており，その一つが相互運用可能なEHRプ ない。EHRをカナダ全領域で導入するための取組 ログラムである。このプログラムは，認証された医 みの一環として，ケベック州政府からの委託により 療機関が，質の高い診療を支援するために重要な患 富士通は医療機関をつなぐ相互運用性サービスの核 者中心の統合医療情報をいつでもどこでも閲覧でき の 部 分 IOP-H （ InterOperability Platform for る仕組み（ソリューション）を整えることを目的と Health）を開発することになった。すでに膨大な している。患者情報はEHRを通じて医療機関間で 量の医療情報が存在し，患者が様々な医療機関を移 共有される。このセキュアかつ生涯にわたる医療記 動する現状では，今あるものを進化させつつEHR 録は，連続する診療過程のすべてにおいて，またい の導入や標準化を進めることをまず考えるべきで かなる医療機関組織やいかなる地域をもまたがり情 ある。 報共有されるように設計されている。 富 士 通 の IOP-H は ， Canada Health Infoway 医療機関間における患者医療情報データの共有に （以下，Infoway）(注)が2006年3月に発表したEHRS は，カナダ全域で使われている各地域の仕組み（ソ Blueprint第2版の中で求めているEHRソリュー リューション）すべての相互運用性がかぎとなる。 ション（EHRS）の構成要素である医療情報アクセ こうした相互運用性を確保するには，すべての関係 ス レ イ ヤ （ HIAL ： Health Information Access 者が同一の基本ルールに基づいてそれぞれの仕組み Layer）サービスに対する要件を満たしている。例 （ソリューション）を開発することが基本である。 えば，IOP-Hは，医療分野の標準であるHL7 V3 この共通ルールの確立に当たって重要な要素となる メッセージ規格に基づいて処理する。HL7のこの のが構造と規格の二つである。 バージョンでは，医療分野のメッセージ構造の定義 Infowayは，こうしたゴールに合致して各自治体 に，初めてオブジェクト指向やインターネットのコ がそれぞれの優先事項に対応できるような基本設計 ンセプトを組み込んでいる。現在の医療における 書を開発し，併せて，全カナダ共通のEHR標準の メッセージ交換のほとんどは，1対1（ピアツーピ 確立を推進・管理するため，標準検討プロセス ア）の相互運用性の解釈に多くの成果を残し普及し （Standards Collaboration Process）を立ち上げて ているHL7 V2に基づいている。そのため，IOP-H ではHL7 V3に準拠しない情報発信源との入出力の ためにV2メッセージからV3変換する拡張機能を実 装している。 きた。 InfowayのEHRS全体の最上位構造を図-1に示す。 この図は三つの主な部分に分けることができる。 上段はカテゴリ分類した患者情報のデータ保管場 富士通のIOP-Hでは，EHRSで推奨されている 所であり，各種識別子（患者，医療機関，位置情報 サービス指向アーキテクチャ（SOA）への適合性 のインデックス情報），患者別診療情報（薬剤，ア にも重点を置き，Webサービスの規格（特にセキュ レルギー，紹介時要約，退院時要約，臨床検査結 リティ関係の基準）に準拠している。 果・画像診断結果など），そして公衆衛生サーベイ IOP-Hの二つの主な目標は，これらの新しい相 互運用性標準の実装を推進すること，そして同時に， ランス情報が含まれている。 中段は，長期医療情報記録サービス（LRS： 医療機関に存在する該当医療情報への迅速なアクセ Longitudinal Record Services）と医療情報アクセ スを橋渡しするセキュアな方法を提供することで スレイヤ（HIAL）である。この二つの要素は， EHRSの全要素をつなぐ背骨として見ることができ （注） カナダ政府，州政府から融資を受け，カナダ全域での EHRSの導入を推進する非営利団体。 408 る。LRSとHIALの主要な役割は，任意の患者の長 FUJITSU. 61, 4 (07, 2010) EHR相互運用性情報基盤：IOP-H 生涯健康医療電子記録ソリューション（EHRS） 生涯健康医療電子記録情報基盤（EHRi） EHRS 検索機能 医療情報 データウェア ハウス 付属データ＆ サービス レジストリ データ＆ サービス EHRデータ＆ サービス 長期医療情報記録サービス（LRS） 医療情報アクセスレイヤ（HIAL） PoS アプリケーション PoS アプリケーション EHRビューワ Canada Health Infoway：EHRS Blueprint Infoway version 2を基に作成 図-1 EHRSの基本構造 Fig.1-Key EHRS architecture concept. 期にわたる医療情報の保存管理と参照である。 報のやり取りを，途中の段階も含めて最初から最後 そして下段は，情報が閲覧される利用機関 まで追跡可能である。HIALは二つのサービスレイ （PoS：Points of Service）を示している。EHR ヤ，共通サービスレイヤとコミュニケーションバス ビューワは，認証済みの医療従事者が，上述のデー サービスレイヤに分解することができる。 タ保管場所にある統合された情報を参照できるよう 共通サービスレイヤは，EHRiに参加する各シス にする。EHRビューワは，それぞれの医療機関や テムに共通かつ再利用可能な機能を付与するサービ 患者にとって重要な情報を共有する形態で提供する ス群である。このレイヤは，情報の統合，プライバ ことを意味している。そして，これは医療機関の診 シーとセキュリティ，システム構成，管理・監視機 療情報システムや診療記録に取って代わるものでは 能に重点を置き，これらの共通機能が該当EHRiに なく，補足情報を用いて機能補完するものである。 おけるすべてのサービスで利用できるようにする。 とは言え，ビューワ経由のそれらの情報は，別の場 コミュニケーションバスサービスレイヤは，コ 所にある医療機関または情報源からHIAL経由で送 ミュニケーション能力の確保に関連したサービス群 信されたものであり，患者の受診経緯の詳細情報と で あ る 。これ は ， 主にPoS ア プ リ ケ ー シ ョンと 同様に，別の医療機関によって実施された診断画像 EHRi間，EHRiからEHRi，そして時としてEHRi や臨床検査などの結果も含め得るのである。 内コンポーネント間（例：LRSからクライアント HIALは，抽象化レイヤとしてPoSアプリケー レジストリへ）で行われるメッセージの送受信と有 シ ョ ン と EHR 情 報 基 盤 （ EHRi ： EHR 効なコミュニケーションモードの維持に重点を置い Infostructure）を区切る働きをするゲートウェイ ている（図-2） 。 である。その構成は，サービス構成要素，サービス LRSは，患者に関する医療情報の有無と所在を 役割，情報モデル，そしてEHRデータの交換およ 整理し，それらを管理する上で中心的役割を果たす。 びEHRS間の相互運用性プロファイル手順に関する LRSの主要機能の一つは，EHRi内で追跡または維 メッセージ標準とから成る。HIALは，EHRS内の 持されている全イベントのインデックスの作成であ 一つの独立した対象物（エンティティ）であり，情 る。ここで作成されたインデックスを通じて，地域 FUJITSU. 61, 4 (07, 2010) 409 EHR相互運用性情報基盤：IOP-H 発信元 送り先 PoS （ドメイン，インデックス，そのほか） HL7 V3 Webサービス（WS）：タイプなし HIAL WS：タイプX インターオペラビリティ プロファイル HL7 V3 WS：タイプY WS：タイプX’ （オーケストレーション） WS：タイプY’ HL7 V3 WS：タイプZ’ HL7 V2.x WS：タイプZ Webサービス（WS）：タイプなし’ XSLT変換 MLLP（VPN） （正規フォーマットへ） リクエスト HL7 V2 V2 → V3 File（FTP/VPN） レスポンス V2 ← V3 リクエストマップ HL7 V3 レスポンスマップ 図-2 HIALのインタラクションモデル Fig.2-HIAL interaction model. 間共通で一貫した患者の長期の医療情報をいつでも リューションを開発することである。そして，これ 閲覧することができるようになる。 はトータルなビジネスコンセプトであり，ソフト 富士通IOP-HによるHIALの実装 IOP-Hは，多種多様かつ地理的・組織的に分散 ウェアや，ソフトウェアのカスタマイズや導入支援， 変革マネジメント支援などの専門的サービスを含ん でいる。それにより，医療の現場では，以下のよう 配置されている各医療機関のアプリケーションソフ な恩恵が得られるであろう。 ト間を患者の診療情報が高信頼・セキュア・追跡可 ・PoSアプリケーションと地域・機能・組織でグ 能な形態で送受信できることを担保する，堅固かつ ループ化されたEHRiのデータ保管場所とをつな 柔軟性のある高性能統合プラットフォームである。 ぐシームレスな相互運用性 この情報フローに関するアクセス権と事象発生の論 ・カスタマイズが容易で，短期導入が可能 理シーケンスは，規約で定められており，全カナダ ・潜在するビジネスリスクの減少 の医療情報システム標準に準拠するものである。 ・既存のハードウェア，ソフトウェア，業務手順を HIAL実装における富士通のアプローチは，それ ぞれのSOAを提供するためにわざわざ一からやり 最大限活用することによるコスト削減，そして熟 練者による短期導入 直すのではなく，各コンポーネントの疎結合を担保 ・堅ろうで実績のあるソリューション しつつ，統合と性能に焦点を合わせることであった。 ・高い移植性と相互運用性 目標は，何回かあるHIAL開発の第一回目の試行で ・高度なセキュリティと追跡可能性 はなく，医療標準，SOA，情報セキュリティにお ・プロファイルの動的設定による柔軟なソリュー いてベストプラクティスを実現できるようなサービ ション スコンポーネントを発展的に寄せ集めることである。 ・ベストプラクティス活用による運用改善 このコンセプトは，導入プロジェクトの全過程を通 ● 多層レベルのIOP-HPアーキテクチャ じてIOP-Hに発展性と順応性をもたらした。 （1） サービス IOP-Hの裏側にあるコンセプトとは，臨床医が 図-3に示すIOP-Hサービスは，この製品のコア機 進んで導入したくなるように臨床医の業務プロセス 能である。富士通は，LRSのうち3サービス（オー を常に念頭に置き，医療従事者を取り込んだソ ケストレーション，アセンブリ，EHRインデック 410 FUJITSU. 61, 4 (07, 2010) EHR相互運用性情報基盤：IOP-H ス）と，HIALのすべての共通サービスおよびすべ ていない場合，オプションとしてIOP-Hに加える てのコミュニケーションサービス（ただし，承認 ことのできる次のような臨時機能を提供している。 ディレクトリ管理を除く）の委託を受けた。これら ・認証管理ソリューション サービスの設計に当たっては，EHRSの要件および ・本ソリューションにおいて不可欠な基本的専門 EHRS Blueprintに記載された機能の要件を満たす サービスの範囲を越える，変換，統合，アセンブ ようにした。 リの各サービス （2） サブシステム ・また，変換およびアセンブリエンジンはWebサー IOP-Hには，ソリューション管理を支援するた ビスとして利用可能である。そのWebサービスは めの以下のような補助システム群がある。 PoSやそのほかのソースアプリケーション（薬剤 ・セルフサービスポータル システム，検査システムなど）といったEHRSの ・オペレーションマネジメントサポートツール ほかのコンポーネントの一部として利用できる。 セット ● 四つのポイントにおけるIOP-Hの特徴 ・インフォストラクチャ情報基盤（包括的オーケス （1） 医療分野のニーズにかなった処理性能と頑 トレーション，相互運用プロファイルとしても知 健性 られている） IOP-Hは医療分野の持つ力を立証した。開発に （3） 拡張システム（オプション） は業界標準ツールと技術を用いたが，結果としては 拡張システムは，顧客が所定の機能を持ち合わせ 医療セクタ特有のニーズにかなったビジネスソ インターオペラビリティ （相互運用性） データ キーマネジメント サービス データ サービス インターオペラビリティ （相互運用性） サービス ETL（抽出・加工・読取） サービス バックアップ複製 サービス 検索・解決 サービス ビジネス インテグレーション ドメインビジネスコンポーネント サービスカタログ サービス （レジストリ，EHRドメイン，ユーザ，コンテキスト） アセンブリ サービス データクオリティ （品質）サービス ブローカー サービス オーケストレーション サービス ノーマライゼーション （正規化）サービス マッピング サービス EHRインデックス サービス ビジネスルール サービス キューイング （待ち行列）サービス メッセージング プライバシー ID保護 サービス 匿名化 サービス 同意指示管理 サービス アイデンティティ管理 サービス セキュリティ 暗号化 サービス アクセス制御 サービス 証明管理 サービス ユーザ認証 サービス 監査証跡 サービス 総合セキュリティ サービス 電子署名 サービス 総合 監査 サービス 変換 サービス ルーティング （経路指定）サービス アプリケーション プロトコルサービス ポリシー管理 サービス 暗号化・復号 サービス エンコード・デコード サービス ネットワークプロトコル サービス 管理 サービス パーサ（構文解析） サービス シリアル化 サービス 凡例： 除外された サービス 追加された サービス 例外・エラー処理 サービス 購読 管理 継続 サービス プロトコル ログ管理 サービス アラート・通知 サービス 公開・購読 サービス コンテキスト キャッシング サービス セッション管理 サービス 設定 サービス コミュニケーション サービス群 長期医療情報 記録サービス群 一般サービス群 図-3 LRSとHIALのサービス Fig.3-LRS and HIAL services. FUJITSU. 61, 4 (07, 2010) 411 EHR相互運用性情報基盤：IOP-H リューションを生み出した。IOP-Hは，医療セク ラットフォームの保守および改良の道筋を容易にし タが必要とする高いパフォーマンスに適応できるよ ている。 う構築されている。IOP-Hは殻の中で，外部の （4） 柔軟性（フレキシビリティ） サービスから受け取ったメッセージを，ユーザ仕様 IOP-Hの柔軟性によって，利用者は既存のハー に沿って適合性を確認し，役割ベースの認証との合 ドウェア・ソフトウェア・業務プロセスを最大限再 致性を検証した後，様々な情報源からの目的応答 利用することが可能になり，また，拡張された可搬 メッセージを得るために，一連のWebサービスを起 性（ポータビリティ）と相互運用性が実現する。こ 動する。 れは，習熟曲線の短縮を意味し，ソリューションの IOP-Hはメッセージを同期・非同期のいずれの より迅速で安価な実装につながる。 モードでも処理することができる。ネイティブ形式 こういったセキュリティ標準への準拠および幅広 においてIOP-Hは，XML HL7 V3タイプのメッ い柔軟性を達成したからといって，ソリューション セージを用いるWebサービスとのインタフェースを の進歩を制限するものにはなっていない。というの とる。しかし，IOP-Hは外部アプリケーションと は，すべてのプロファイルや規則は必要に応じて更 接続するように構成されて，様々なモードでサービ 新が可能で，版数管理も適切に提供されている。 スを起動することもできる。プラットフォームのこ IOP-Hは，SOAPおよびほかのWS標準に準拠し うした柔軟性によって，IOP-Hと接続可能なアプ た形で設計されている。IOP-Hが現在ベースとし リケーションの範囲を拡大することや処理能力に関 ているマイクロソフトプラットフォームのほかに， する外部要件に合わせることが可能となる。 UNIXやJavaベースのSOAPフレームワークとシス （2） リスクを減らし応用範囲を拡大可能な，迅速 テムを組み上げることが可能であることも実証され かつ費用対効果の良い導入方法 ている。したがって，既存あるいは今後のアプリ 複雑なシステムの導入・展開にはリスクが伴い， ケーションと容易に接続可能である。さらに， ときにはそれによってビジネスが混乱することもあ ITIL （ Information Technology Infrastructure る。こうした状況は，テンプレートとフレームワー Library）のようなベストプラクティスに沿って管 クの利用によって緩和することができる。さらに， 理できるように設計されている。 臨床医の期待に応えること，それゆえに変化に対す IOP-Hは，医療分野における重大なニーズに応 る抵抗を和らげるために，このソリューションの設 えている。IOP-Hは，今まではEHRSの一環として 計には多数の専門医が積極的に参加している。ソ 使用されてきたが，それだけではなく技術的に多様 リューションに併せて提供される，ツール，テンプ で，物理的・組織的に分散しているアプリケーショ レート，技術ノウハウは，各地域の要件（コーディ ン間の医療情報の交換の際にはどのような環境で ング，メッセージ構造，既存システムに合ったイン あっても利用可能である。 タフェースなど）に合致するようソリューションを 仕立て上げることを容易にする。 （3） 適合性とセキュリティ IOP-Hの基本構造は，機能をレイヤごとに区 切っており，各ビジネスドメイン管理者（またはド メインごとのアプリケーション開発者）がHIALの IOP-Hは中心機能として，HL7 V3メッセージを 内部の仕組みを知らなくても問題がないように， 処理し，HL7 V3非準拠の発信源とのメッセージの HIALの管理者が各ビジネスドメインの特性を知ら やり取りにおいてメッセージ変換を可能とする拡張 なくてもよいようになっている。よって，これは 性も持ち合わせている。 SOAのベストプラクティスのルールに一致している。 EHRSで推奨されているSOAへの適合性を確保 IOP-Hの構造と基本技術は，柔軟で迅速なシス するために多大な配慮がされている。IOP-Hは テム導入を可能とし，その結果として，時間がかか Webサービス規格に適合しており，とくにセキュリ り危険で費用の高い実装プロジェクトを回避して ティ関係の規格（WSセキュリティ）に適合してい いる。 る。富士通のIOP-Hが確立された業界標準を信用 IOP-Hの中核となる内部の仕組みは，求められ して準拠していることは，基本的なソフトウェアプ る処理内容と性能を兼ね備えた標準準拠のメッセー 412 FUJITSU. 61, 4 (07, 2010) EHR相互運用性情報基盤：IOP-H ジ交換構造の上に構築されている。HL7 V3非準拠 IOP-Hサービス のシステムは，再利用可能な変換コンポーネントに IOP-Hのサービスは，再利用性を最大にするよ 接続され，その中で情報交換に適したメッセージ構 造に変換される。 うな構成で実装されており，また，情報の流れを最 ケベックプロジェクトで実装された特定のトラン 適化するように連続性にも配慮されている。 ザクションプロファイルが既に23個あり，それら したがって，IOP-Hでは次のようなメッセージ は患者の医療データ，検査結果，薬剤処方せん，そ 内容の検証を行う。 して放射線画像を検索や維持管理するために図-4に （1） 正しく構造化されフォーマットされたメッ 示す相互連携モデルに沿っている。トランザクショ セージのみを処理する。 ンプロファイルは，引き続き新たなものが追加され （2） ユーザ，患者とメッセージのルール準拠かつ ている。 正しい組合せのみを処理する。 （3） IOP-Hにおいて処理される間，メッセージ メッセージや規則が一度定義されれば，設定プロ セスは簡単なものである。さらに，IOP-Hは，完 データの内容は変更されないこと。 全性，信頼性，セキュリティと機密性が厳格な要件 （4） プロファイル上で定義された規則に従って， となる医療セクタ向けに開発されたものであるが， メッセージを完結まで処理する。エラーや例外 それは，利用者が技術上の非互換プラットフォーム の取扱いはプロセスに組み込まれており，結果 を使用し，一連の合意されたメッセージと規則に基 にエラーメッセージが含まれている場合でも必 づいて情報交換を行ういかなる環境においても利用 ず完結する。 可能である。 （5） メッセージ処理における全段階をログに記録 ドメイン または PoS メッセージ 1 0 HIAL 3 2 B カタログ IP IP ネットワークプロトコル IP 暗号化・復号 暗号化・復号 シリアライゼーション @ 拒否された メッセージ アプリケーションプロトコル 電子署名 アイデンティティ管理 @ 認証 セッション管理 待ち行列 Secur Santé アクセス管理 4 拒否された メッセージ 5 拒否された メッセージ 6 オーケストレーション メッセージ 分析 7 フロー フロー キャッシュ フロー フロー フロー 7 ! エラー例外 拒否された メッセージ 7 7 7 7 7 7 変換 Module de traitement Module de traitement spécifique intégré 特定実行モジュール spécifique intégré （BizTalkワークフロー含む） 検索および解決 8 @ @ 一意ID解決 @ @ @ @ @ @ 一意ID解決 一意ID解決 一意ID解決 RI ODS/ LDS FCO Gest. des journaux Audt @ @ Audit de sécurité @ @ 制御ポイントログ RU 「受信」や「送信」のメッセージログ Domaines RDSQ @ 外部コミュニケーション ! IOP-Hエラーシグナル 図-4 LRSおよびHIALサービスアーキテクチャの詳細 Fig.4-LRS and HIAL service architecture drill-down. FUJITSU. 61, 4 (07, 2010) 413 EHR相互運用性情報基盤：IOP-H する。 （2） メッセージを受信・承認する。 IOP-Hには，独自のサービス検索や解決サービ （3） ユーザを認証し，アクセス権を有効化する。 スがあり，BPELエンジンやほかのWebサービスを （4） 患者の同意を確認する。 起動できるよう設定することによって，ほかの （5） メッセージを有効にする。 IOP-H実装や類似プラットフォームとのインタ （6） 必要に応じてメッセージを変換する。 フェース接続までも可能になり，広範なネットワー （7） メ ッ セ ー ジ の EHR-IP ル ー テ ィ ン グ 仕 様 に クや多階層のアプリケーションを形成することがで 沿って，必要とされるサービスを通じてメッ きる。 セージをルーティングさせる。 IOP-Hにおいて起動されたサービスは，ビジネ （8） 必要に応じて返答を組み立てる。 スワークフローの完全性を維持するために，専門医 （9） メッセージの発信元に対して返答する。 によって定義されたプロファイル要件に沿って稼働 （10） 全段階をログする。 しなければならない。ビジネスワークフローを完全 ケベック州のIOP-H実装において，現在複数の なものにするためには，署名のような人手による介 特定相互運用性プロファイルが存在する。これらの 入を必要とするステップも含め，外部からの情報提 プロファイルはInfoway標準に基づいてはいるが， 供の要求に応えるいかなる処理も対応可能とする必 ケベック州の実情に適合するように調整されている。 要がある。 これらは現在運用可能であり，プロジェクトの今後 IOP-Hの実装 IOP-H実装プロジェクトはおおよそ下記に示す 要領で進行する。 （1） 必須ソフトウェアが，コア製品に同梱される IOP-Hのインフラストラクチャのセットアップ ガイドに沿って，インストールされ設定される。 （2） 製品のインストールや設定は，プロフェッ ショナルサービスを通じて行われる。 の展開に伴って新たなものが追加されていく。例え ば図-5の画像ドメインのためのPUTプロファイル は，つぎのステップから構成される。 ・ステップA：患者の氏名・生年月日・住所から患 者の一意識別子を見つける患者識別手法 ・ステップB：臨床医の氏名・登録番号から臨床医 の一意識別子を見つける臨床医識別手法 ・ステップC：診療所の名称・医療施設番号から診 療所の一意識別子を見つける診療所識別手法 （3） 汎用相互運用性プロファイルは，利用者の ・ステップD：画像LRSを与えられた画像スタディ 要件に対応するため事例を挙げて作成・調整さ 番号で更新し，EHRインデックスを適正な識別 れる。 子で更新 （4） EHRSの相互運用性プロファイルは，サポー EHRの完全性を確保するため，上記各ステップ トすべきトランザクションに応じて作成・調整 にもエラー処理や例外処理扱が組み込まれている。 される。その中には次の三つが含まれる。 これらはほかの行政管理地区の医療インタフェース ・WSDLをサービスにコールできるように定義 の要件に適合するよう調整することができ，こうし ・汎用プロファイルにおけるWS URLの組立て た調整はライセンス料に含まれるプロフェッショナ ・入出力メッセージのためのXSD（XML Schema ルサービスに含まれている。 Definition）を定義 発信元もしくは送り先のアプリケーションで生成 （5） システムのオペレーションをテクニカル・機 されたメッセージが，公開のInfoway標準に準拠し 能の両面において監視するよう，補助ツールや ていない場合，特定の変換や相互運用性プロファイ プロシージャが設置される。 ルを，直接HIALで，もしくは外部変換Webサービ 相互運用性プロファイルが作成されるとき，これ スを利用して定義することが可能である。この定義 らは通常，汎用の相互運用性プロファイルを雛形と は，利用者がインタフェース仕様（メッセージの送 して使用している。典型的なプロファイルは下記機 受信のWSDL，URL，XSDフォーマット）を提示 能を搭載している。 できる場合に限り相互運用性プロファイルを使用し （1） 相互認証の後にSSLセッションを起動させる。 414 て可能となる。 FUJITSU. 61, 4 (07, 2010) EHR相互運用性情報基盤：IOP-H PoS PUT 相互運用性 （インターオペラビリティ） プロファイル （オーケストレーション） LIST 相互運用性 （インターオペラビリティ） プロファイル （オーケストレーション） GET 相互運用性 （インターオペラビリティ） プロファイル （オーケストレーション） ステップ A ステップ B ステップ C ステップ D 行き先 （臨床ドメイン，インデックスなど） 図-5 相互運用性プロファイルの情報フロー記述 Fig.5-Interoperability profile information flow definition. この構造の利点は，標準の様々なレイヤを分離し， 証明された。また医療現場における実験により， 一つのレベルにおける変化がほかのレベルへの影響 IOP-Hの柔軟性と，臨床医にも医療施策の企画者 を最小限にとどめることにある。同時に，全体の情 にも使い勝手が良いことが明らかになった。プロ 報基盤は，いかなる行政管理地区の法規やプロセス ジェクトチームが直面した大きな課題は全体のパ 要件をも満たし，また，メッセージの地域差を補う フォーマンスを悪化させない次の対策が重要なこと に十分な柔軟性が保持されるように作られている。 であった。それは，外部コンポーネント接続のため む す び のWebサービス規格を使用しつつ，IOP-Hの使用 者が，すでにフレームワークによって実行されてい IOP-H に よ っ て ， Infoway が 求 め る EHRS るサービスと重複するようなサービス（例：ログ作 Blueprint要件を満たし，かつ，どの州においても 成，エラー処理）を個別に提供しないよう最適化さ 患者情報のプライバシーを保護する州法を遵守した れた相互連携モデルを確立することであった。 相互運用医療アクセスレイヤの作成は可能であると FUJITSU. 61, 4 (07, 2010) 415