サービス指向アーキテクチャで医療システムの性能を改善する

医療におけるSOA

医療分野における技術とその導入の急速な増加は、医療の組織においてその組織内で作業するために必要なものばかりでなく、外部からアクセスされるシステムに対して、相互運用性のないシステムを積み上げてしまうという結果を引き起こしています。その統合の負担は、通常はシステムを利用するユーザーへ襲いかかり、一つの作業を完了するために複数の異なるシステムへのアクセスを強要させられます。しかしながら、サービス指向アーキテクチャ（SOA）の利用により、重要な情報の配信を改善し、グループを通したデータの共有を、コスト、セキュリティ、配信のリスクの点で実用的なものとすることができます。

今日の医療組織では、増大するシステムのポートフォリオを管理することが求められています。システムの習得、統合、保守にかかる費用は増大する一方で、ユーザーのシステムに対する要求も増しています。組織は、収益循環やビジネス機能の管理をサポートするだけでなく、発展している臨床への要求も解決しなければなりません。加えて、地域的なケアデリバリをサポートするために、他の組織との相互運用性を強化する必要性も増大しています。サービス指向アーキテクチャは、医療組織を通したシステムリソースの再利用と共有をサポートするためのシステム設計と管理原則を提供します。SOAでは、既存システムのリエンジニアリングを求めているのではありません。SOAにより、ソリューションの一部として利用されるサービスのライブラリを構築するために、既存のプロセスを新しい機能と結合することができます。ビジネスプロセスにあわせた共有サービスを使用することで、分離したシステム間のデータ同期の必要性を低減し、相互運用性を強化します。机の上、部門、そして医療組織を超えてソリューションを構築するので、サービスは、その場所に依らず利用することができるでしょう。

医療情報技術におけるSOA利用の紹介

各部門やケアデリバリをサポートするために、組織の全体を通して単一のシステムに依存している医療組織では、通常は、既にシステムリソースを共有、再利用するためのソリューションを持っています。より一般的には、組織が一つあるいはそれ以上の企業システムに依存し、追加のシステムで部門に特化したニーズをサポートし、自身のシステムでの事例を利用して、複雑なネットワークのデータインターフェースの利用と相互運用をおこないます。大きなシステムポートフォリオを持つ組織では、より容易にSOAのメリットを得ることができるでしょう。SOAの環境により、システムの資産を組織を通してアクセスさせ、現時点で孤立しているシステムの機能を共有する機会を与えることができます。例えば、SOAによりシステムを追加することなく、十分に力を発揮していない処理要求を満足させるための支援が可能で、処理とデータ管理を統一する機会を得ることができます。これは、既存システムがサービスとしてパッケージ化、共有化され、その価値が高まる可能性を秘めているということを意味しています。図１では、医療システムの機能と関連するアプリケーションの例を表しています。この図には、機能やシステムの完全なリストを含んでいませんが、一般的な医療システム環境におけるシステム機能の冗長性を示しています。

図１ - 医療システムと機能

SOA は、自己完結していてその境界がはっきりしている独立した作業単位として、サービスを定義します。作業単位は全体のプロセスであるかもしれないし、ある処理をサポートする機能であるかもしれないし、ビジネスプロセスの一部かもしれません。サービスがシステムのソリューションとして統合され、「発掘される」につれて、SOAによってサービスは直接ビジネスプロセスをサポートします。再利用と標準化のためにSOAを適用する際の最も大きな機会は、システム、部門、組織にわたって利用される機能によって提供されます。システム機能がシステムを通して冗長であるならば、それに対応するビジネスプロセスはおそらく関連していて、サービスとしてプロセスの共有の必要性を示唆しているかもしれません。図１の中で、冗長している多くのものがそれにあたります。

• 患者を登録する
• 患者を収容、退院、移転する
• 病状と診断を文書化する
• 請求書の記録と文書化をする
• 臨床記録を作成する
  

それぞれのシステム機能は、サービスの再利用の機会をより増やすようなタスクに分類することができるかもしれません。例えば、「患者を登録する」の機能は、「患者の記録を検索、参照する」、「患者の記録を作成、更新する」、「保険が適格であるかを確認する」、「文書の履歴」(新規もしくは更新)、に分けることができるかもしれないし、登録プロセスの間に他のビジネスアクティビティが完了できるかもしれません。この粒度によって、他のサービスやアプリケーションが、「患者を登録する」機能の一部を利用することができます。「患者の記録を検索、参照する」のタスクは、組織の大部分で利用されるかもしれません。その一方で、「患者の記録を作成、更新する」のタスクは、権限を持ったフロントデスクのスタッフのみで利用されるかもしれません。場合によっては、別のシステムによって提供された機能が現在あるプロセスで利用されている機能よりも優れているかもしれません。例えば、他のシステムで利用している「保険が適格であるかを確認する」機能が、「患者を登録する」機能で行われている対応するシステムの機能よりも優れているかもしれません。SOAは、機能を標準化し、システムとプロセスにわたって利用することを可能にするような環境を提供します。

図２では、「患者を登録する」サービスの機能の概念図を表しています。

図2 - 「患者を登録する」システムの機能

SOAが医療業界でより一層採用されるにつれて、特定のサービスと同様にサービスのコレクションが、医療組織のサービス調達組織の機能として採用され、利用されることになるでしょう(第2章に記載されています)。サービスを提供するシステムの位置が透過的であるので、時間をかけて手に入れたこれらのサービスが、組織の外で利用されるかもしれません。例えば、診断関連グループ(DRG)やその他の似たような管理された医療語彙のコード化サービスは、統合のために組織のソリューションとして利用可能であるかもしれません。そのサービスが、外にある仲介システムに配置されたり、様々な医療組織で利用されるかもしれません。SOAによって可能となる更なる強みとして、単一のDRGコードセットがサービスを利用する医療組織全体に対してだけでなく、組織全体に対して、簡単に最新の状態にすることができるということです。図3では、医療におけるサービス分類の例を示しています。

図3 - 医療におけるサービス分類の例

 SOAで医療データの統合を解決する

ほとんどの医療組織では、看護師は患者のケアをするために複数のシステムやデバイスを利用します。看護師は、デモグラフや入院情報をチェックするために患者の管理アプリケーションを利用し、前の臨床記録や現在の病状を参照するために一つ若しくはそれ以上の電子機器による医療記録(EMR)を利用し、正確な請求書を作成するために料金収集アプリケーションを利用し、依頼された指令のためにいくつかの補助的なシステムを利用します。もし、看護師に患者の担当医師へのコンタクトや他の組織の臨床記録の参照をサポートしているシステムへのアクセスがなければ、電話やFAXによってこれらの作業を完了させる必要があるでしょう。これらのシステムや機能をサポートするアクティビティは、全体的なケアデリバリシステムを達成するよう求められています。しかしながら、この例では、看護師は自身の作業をサポートするために、システム統合していない様々なシステムを利用します。つまり、看護師が相互運用性を提供しているのです。

伝統的に、医療組織はいくつかの組織の中の100以上のシステムを通じたデータの同期によって、相互運用性を支援しています。患者の情報は、これらのシステムのほぼ全てで管理されています。システムデータベースはデータインターフェースを用いて同期し、比較的クリティカルでないシステムのためにデータ入力を繰り返します。まず最初に、システム間のデータインターフェースは、ポイントトゥーポイントで、それぞれのシステムが持つ独自のメッセージフォーマットです。システムの数が増加したので、Health Level 7(HL7)のような標準インターフェースフォーマットや中央データインターフェースエンジンが、より大きな医療組織によって採用されました。加えて、インターネットベースの通信により、組織が保険庁のような外部の組織とのデータ交換ができるようになりました。図4は、一般的な医療データ統合アーキテクチャを表しています。この環境では、様々なタイプのサーバー、旧来のポイントトゥーポイントインターフェース、データインターフェースエンジンによって処理される多くのインターフェースがあります。

図4 - 一般的なレガシーの医療データ統合アーキテクチャ

データがシステムやシステムデータベースの中で、そして組織の外で同期化されていますが、このデータインターフェースアプローチは、データの相互運用性に欠けています。プロセス間のデータ処理と通信には、複数のシステムや冗長な処理があります。全体的なワークフローをサポートするために、ユーザーは処理を完了するために必要な複数のアプリケーション間での切り替えが必要となります。システムでは、冗長なデータのクリアも必要となります。SOAでは、図5で示すように、サービスは既存のシステム機能を使って開発されます。

図5 - 医療におけるSOA統合アーキテクチャ

SOAでシステム処理はまとめられ、サービスのセットとして表されます。各々のサービスは、標準インターフェースによって組織全体で利用できるようになります。同じ情報をメンテナンスしたり、アクセスする部門全てが同じサービスを利用し、システムのそれぞれのサービス通信が関連しています。ユーザーはワークフローを完了するためにシステムを切り替える必要がなく、データはプロセスやシステムのサポートによって自動で同期化されます。ユーザーワークフローに足並みをそろえた統合化されたサービスは、医療組織のプロセスと人々の間で本当の相互運用性を可能にします。医療保険の携行と責任に関する法律(HIPAA)のコンプライアンスをサポートするために、組織では保険庁との標準のデータ通信を強化しています。加えて、他の医療組織との統合により、臨床のワークフローや医療情報ネットワーク(HIN)への参加をサポートすることがしばしば求められます。組織は、完全なプロセスの相互運用性を提供するために、外部サービスをSOAソリューションとして統合するかもしれません。例えば、患者が組織内で登録されるとき、サービスは、ケアに関する全組織に対して患者を登録するために、HINによって提供される外部のサービスを利用するかもしれません。患者の登録情報が同期化されるだけでなく、このような外部通信がユーザーにほとんど影響を与えない関連ワークフローにあり、組織のシステム境界の外側での相互運用性を形成します。

SOAは、システムが進化する際の次のステップです。組織の内外でアジャイルさや効果的な再利用がよりよくおこなわれている間は、それは以前のアーキテクチャアプローチに基づきます。SOAは、本当の相互運用性を提供します。ほとんどの医療組織では、冗長した処理やデータを持った、大きなシステムポートフォリオがあります。SOAでは、システム機能が組織全体でよりフォーカスされ、利用されるサービスとして選択され、パッケージ化されます。組織では自身の労力を、複雑なデータインターフェース戦略の維持から、医療プロセスとより密接に関係している相互運用性をサポートするサービス指向アプリケーションの作成にシフトすることができます。この章の残りを通して、SOAを通しての本当の医療データのインターオペラビリティが、どのようにして医療での産業変化をもたらすことができるのかというテーマについて探求します。

医療情報ネットワーク(HINs)におけるSOA

データ統合と相互運用性は、医療の中で最重要な要件です。お金と人命が犠牲となる医療ミスは、ほとんどの場合、ケアの間際に正しい形で利用できる正常な情報の不足によるものです。

世界中で、この問題を解決することは、多くの行政と関連する医療機関にとって最重要点です。医療情報ネットワーク(HINs)は、データ統合問題が解決される手法です。HINは、保険庁(支払者)だけでなく、行政、病院、専門研究室、薬局の間の協調です。そしてそれは、医療システムによる重要な医療情報を正確かつ素早く交換するために、共有された情報経路、データリポジトリ、アプリケーションインターフェースを構築するためのデータ交換のネットワークを提供するためのものです。

HINsは、以下の主な利用モデルをサポートするためにあります。

• 患者の病歴、アレルギー、永続的な医療の問題、現在の医薬、対処中の処置といった、重要な情報を取得するために、ある介添え人と別の人の間での患者の電子医療記録をやりとりする
•  プライマリないしはセカンダリケアプロバイダの紹介をやりとりする、あるいはこれらの紹介で訪問したところの医療結果だけでなく研究所の結果をやりとりする
• 処方や薬が患者の保険でサポートされているかどうかを素早く知るための、処方に対する電子的な事前承認
•  診療のキャッシュフローサイクルの正確さとスピードを増すための、電子的な申し立てのファイリングと報酬
• 処方薬の利用を電子的に指令、監視するための手法
• 法で定められたバイオサーベイランス活動(インフルエンザやその他の病気)に対する、重要な医療情報の統合データリポジトリ
•  患者と医療のステークホルダーのポータルが、適切なデータにアクセスするための手法
  

図6では、SOAベースのHINのアーキテクチャを示した図です。

図6 - HINのアクター

継続可能なHINをつくる

HINを実行するための主要課題は、維持可能な財政モデルをつくることです。それは、そのネットワークを導入するためのコストやリスクが、医療団体にとって耐えれるものであり、継続して存在するネットワークを維持するためのオペレーションコストを正当化するための、繰り返し発生する価値の源泉が存在することです。政府(地方、地域、国家)がより大きな価値を求めて資金提供をしている団体でさえも、コスト、価値、持続可能性におけるこれらの課題が、今なお考察材料となっています。

.医療データの統合においてレガシーなメカニズムを使用することは、単純に、長い期間に渡ってHINを遂行し持続する上で経済的な面で実行可能ではありません。もし、どんなときでも新しい病院、薬局、政府関連機関にHINがもたらされるのならば、新しいポイントトゥーポイント/ブローカーのインターフェースが開発され、以下のようなアーキテクチャやコストの問題が発生します。それは、図7で表されています。

図7 - ポイントトゥーポイント/ブローカーの統合アーキテクチャ

統合におけるポイントトゥーポイント/ブローカーの手法でおきることは、HINに加わっている数に比べて、システムインターフェースの数が指数関数的に増えることです。カナダのHealth Infoways1による調査では、統合のためのアプローチが、コストや持続可能性の観点からいかに不毛であるかをはっきりと示しています。

• 一つの統合のコスト: 簡単なもの = 32,000カナダドル、中間 = 20,081カナダドル、複雑なもの = CAD 190,000カナダドル
• カナダに38,783のシステム
• 統合のタイプの数: 簡単なもの = 4,527、中間 = CAD 95,000、複雑なもの = 14,175
• この結果、15億のシステムインターフェースポイントをもたらす
• 推定コストは、約CAD1840億カナダドル

このカナダの例は、ポイントトゥーポイントの統合アーキテクチャを使用する規模のHINを構築することが、コストの点から無理があるということをはっきりと示しています。これを書いたときには、アメリカでは、HINに対してそれぞれ約200万～500万USドルを費やしている多くの州や地方の行政によって、 234地域のHINｓが構築されています。これらのHINsのための最初のスタートアップコストの70パーセント以上は、情報ネットワーク上に最初の病院や保険会社をもたらすためのシステム統合です。長期にわたって彼らの経費を支えるためのHINsにとっては、こういった経済状況が変わる必要があります。

HINにSOAを適用するためのガイドライン

HIN統合アーキテクチャのためにSOAを使うと、統合のコストを大きく下げることができ、医療の団体への持続可能な価値の源泉が確立されます。これを達成するために、HINのサービスアーキテクチャは、以下のようである必要があります。

• ネットワークのデータ相互運用性をつくるために、インターフェースポイントの数を簡素化して減らす
• アーキテクチャ、インフラストラクチャ、ソフトウェア、結合ユニットのような関連するビジネスサービスに対処する
• 共有したHINネットワークの中だけでなく、病院、研究所、薬局、保険企業の中で配置可能にする
• 現状を含み医療データ表現の標準を発展している、レガシーシステムのサポート
• コスト、複雑性、実用性、順応性の観点で、小規模から大規模な医療組織までスケーラブルである
  

HIN に適用されるSOAテクニックが提供する最初のキーとなるメリットは、データインターオペラビリティ問題を単純化することです。HL7のような医療のデータ標準に対する業界標準がある一方で、それらの標準に関する基本的な問題はソフトウェアにおける様々な解釈となります。したがって、HINのための一番最初の目的は、ソフトウェア解釈、ひいてはネットワーク上の医療データの表現と解釈の実行を標準化しなければならないことです。このようにする際に最も費用効果がよい方法は、医療データを表すコアビジネスサービスの標準化されたセットを経由することです。

図8 が示すように、データ表現（「標準的なデータ表現」）の標準化された実行を管理するためにSOAサービスを実行することで、1桁分のシステムインターフェースポイントの数を減らします。HINに参加している各々と、ネットワーク中の各々の参加者のためのシステムインターフェースを作成・維持する必要のあるHINデータセンターの代わりに、全ての参加者に必要なことは、それらのシステム表現をサービスによって一つの特定したものへと変換することです。それは、(例えば、患者、プロバイダー、オーダー、照会などで)変換されている特定データに対する標準形式を定義します。

図8 - SOA統合アーキテクチャ

このSOA(システム統合の標準ベースのアーキテクチャ)は、65パーセント以上の統合の数とコストを減らします。SOAのコアビジネスサービスが管理する標準的なデータ表現により、次のものが確立します。

• 固有のエンドポイントアプリケーション全てから独立した構成
• 実現されている情報アーキテクチャと技術インフラの独立(分離)
• 一貫した実行を保証するためのメッセージ定義を明確にする
• ビジネスプロセスを推進するデータの可視性
• 個々のビジネストランザクションに対する固有のアプリケーション定義を明確にする

標準的なデータ表現の上に構築されたサービスを利用することで、HINネットワークがデータの標準化されたソフトウェア解釈に頼るようになるので、ネットワークがネットワーク全ての参加者による共有インスタンスとシステム機能の消費をサポートすることができます。これにより、HINが、プロバイダーレジストリ、医学語彙変換、マスターパーソンのインデックスといった共有サービスを提供することができます。そして、医療団体全てに代わって、ロケーターサービスを記録することができます。サービスなしで表現されるそれらは、HINに参加しているそれぞれの組織のデータセンターに配置され、複製される必要があります。図9では、このアーキテクチャと共有サービスの例を示しています。

図9 - 想定されるHINサービスのポートフォリオ

3章と4章で記述されているエンタープライズサービスバスの技術を利用することで、HINのデータセンターと医療情報ネットワークに参加している組織のそれぞれが、それぞれの他のサービスをパブリッシュしたり、利用したりすることができ、ネットワーク参加者の間で新しいビジネストランザクションやインタラクションを素早くサポートするための統合されたワークフローを確立することができます。加えて、サービスバスアーキテクチャのサービスコンテナ構成は、病院、研究所、薬局、保険団体にある既存の配置されている臨床や管理のシステムが、このアーキテクチャに加わって、XMLWebサービスによって「前面に」現れるようになります。これにより、付加的かつ反復的な方法でSOAのメリットを実現することができます。その結果、既存の技術投資を活用することができるのです。図10 は、サービスバスアーキテクチャの図です。

図10 - サービスバスアーキテクチャ

これらの例で見られるように、SOA技術を使用することで、どんな規模でもHINを実行するコストを大幅に下げることができます。さらに、SOAは患者に関する簡単なポータルと統合されたデータレコードのデータベースのホスティングを超えて、継続的な価値の源泉を提供するソフトウェアサービスとしての機能を医療団体に提供します。

SOAによる電子医療記録の拡張

これまでのところで、わたしたちはSOA技術を使用することで医療情報システムの統合を改善し、コストを大幅に削減することを可能とする手法について数多く論じてきました。しかし、世界的には、自動化され、電子化された医療臨床情報の量の平均は少ないです。

世界中の多くの医療組織は、患者の診療記録の収集、配布、妥当性確認を目的とした電子医療記録(EMR)システムを計画、あるいは設置しています。そのような技術は、30年間商用での利用が続いていますが、日々作業する臨床医によるEMR採用の世界的な平均は、20パーセント未満です。図11では、この低い採用率の理由をまとめ、SOAがどのようにしてEMR採用を増加する手助けとなりうるのかについて説明しています。

図11 - 電子医療記録(EMR)システム採用への障壁

SOA技術を利用することで、図11に記載されている多くの問題を、直接解決することができます。

初めに、多くの電子医療記録システムは、部門から医療の専門にわたる企業レベルのアプリケーションとなるように設計されています。この広いスコープによる一つの共通な作用として、多くのタブ、データフィールド、ボタン、その他のユーザーインターフェース要素を持つ画面であり、それは、手元の作業を完了するためにほんのわずかの機能しか必要でない作業に対して、トレーニングや使用を複雑なものとします。SOAベースのEMRでは、ユーザーインターフェースの多くのフォームを迅速にサポートすることができます。何故なら、コアとなるデータやビジネスロジック機能が、画面に対して疎結合となっているからです。それ故、ISVの開発者、または潜在的に十分なエンジニアの才能を持つIT開発者が、部門の専門的なユーザーインターフェースを提供することができます。そして、EMRエンジンのコアプロセスやデータ検証を重複させることなく、作業の役割を提供することができます。

次に、SOAベースのEMRは、データとビジネスルールに対する一連の組み立て可能なソフトウェアサービスとして構成されているので、ワークフローをすぐにカスタマイズすることができます。それは、個々の組織や部門のニーズを、個々の部門が「最善の」開発をすることなくサポートするためのものです。というのも、ベンダーが特定の部門のワークフローをよりよいものとなるように支援しているので、個々の部門は異なるベンダーによる似たようなアプリケーションスタックを持っているからです。それは、一度ならず、しばしば同じコア技術に対する支払いによる組織のコストを節約するだけでなく、共通サービスのインフラがSOAベースのEMRで繰り返し再利用されるので、コストをまとめて持ちこたえる上での大幅な削減の余地もあります。

.最後に、先に説明したように、SOAアーキテクチャは EMRシステムまたは病院のプロセスの全機能が、外だしされ、共有データセンターでホストされ、ユーティリティとして利用することができます。例では、制御された医学語彙変換、マスターパーソンのインデックスサービス、患者の記録のロケーターサービス、保険照合、クレーム処理、照会管理といった、SOAを動力源としたHINにより提供されうる機能を含んでいます。この主要メリットは、機能を実行して維持するためのコストです。大抵の場合、外だしによって得られたソフトウェア機能、ホストされた実用モデル(ユーティリティコンピューティングとかアプリケーションサービスプロバイダと呼ばれることもあります) は、トータルコストの大幅な低下のために行われます。これは、サービス、データセンターインフラストラクチャ、ソフトウェアライセンス、エンジニアリングのコストがEMRが内部のデータセンターにホストされている場合に、それぞれの顧客が繰り返し負担しているというよりは、それが多くの顧客に広がっているという事実によります。SOAの手法や技術を利用するとき、医療IT組織は、外だししたものと平行して、直接、内部にホストされたシステムや技術を統合することができます。図7.12は、このアーキテクチャを説明しています。

図12 - ホストされ外だししたアプリケーションの統合アーキテクチャ

SOAにおける医療システムのパフォーマンス改善について、さらなる情報を知りたければ、Intel出版から発行された、Girish Juneja、Blake Dournaee、Joe Natoli、Steve Birkel氏による書籍「Service Oriented Architecture Demystified(source)」を参照してください。

著者について

Girish Juneja は、IntelでSOA製品のディレクターをしており、エンジニアリングや技術戦略の技術業界で15年以上の経験を持ちます。

Blake Dournaee は、現在、IntelのSOA製品におけるプロダクトマネージャです。Blakeは、処女作としてXMLセキュリティを書き、定評のある著者でもあります。

Joe Natoli は、デジタルヘルスグループのプラットフォームアーキテクトです。Joeは、設立メンバーで、SOA戦略のアーキテクトです。さらにIntelのITプログラムをプランニングしています。

Steve Birkel は、Intelの情報技術における技術チーフアーキテクトです。技術インフラ戦略やエンタープライズ統合の発展をリードしています。

Copyright © 2008 Intel Corporation. All rights reserved.本稿は、Girish Juneja, Blake Dournaee, Joe Natoli, and Steve Birkelによる書籍「Service Oriented Architecture Demystified」に書かれている内容をベースにしています。この本に関してより詳細が知りたければ、Intel出版のWebサイトを見てください。http://www.intel.com/intelpress/sum_soa.htm