医療連携における課題の解決 : 医療サービスバスの選択

インターシステムズ意思決定ガイド
医療連携における課題の解決 :
医療サービスバスの選択
医療連携における課題の解決 :
医療サービスバスの選択
概要
医療における ESB 技術の初期の導入で分かったことは、ほと
んどの製品はこの分野に特有のすべてのビジネスニーズには
医療においては、情報の利用しやすさが、医療上の意思決定
対処していないという事です。最も重要なことは、ESB が可能に
結果や、あるいは包括払い制度推進の成功に影響を与える可
するのは接続性であり、相互運用性ではないということでした。
能性があります。適切な場所とタイミングで適切な情報を確実
ESB は、異なるシステム間の通信を可能にしますが、データモ
に利用できるように、医療機関は、通常は HL7® インターフェイ
デル、データのコード化、コンテンツの標準、用語の違いや、検
スエンジン（パッケージソフトウェア）を使用して、臨床アプリ
査結果、臨床の記述などの構造化/非構造化データの活用のと
ケーション間でデータを共有してきました。しかし、医療 IT に対
いった根本的問題を解消することはできませんでした。
する需要は急速に変化しており、そのような単純なエンジンでは
こうした機能の欠如により、高コストで非効率な対処療法的な使
対応しきれなくなっています。
用を強いることになりがちです。接続を増やしたい、情報をより
 データ共有と相互運用性のための新しい標準とプロトコルが
有効利用したい、イノベーションのペースを速めたいというニー
出現し、進化し続けている。
 データ (画像、ゲノムデータ、および最新の診断、治療法、モ
ズに、長い間、CIO、CMIO、および IT 部門は対応できませんで
した。
ニタリング機器からの出力など) の量、種類、そして生成速度
は、増え続けている。
 ビジネスモデルは、診療ごとの支払いから価値に応じた支
医療向けに設計された ESB の選択
払いへと進化しており、患者医療保険プランを含むケアチー
医療向け ESB である「医療サービスバス」の登場により、状況
ム間で、これまで以上に充実した医療連携に対する需要が
は一変しました。医療サービスバスは、ESB 技術が自然に進
生み出されている。
化したものであり、非医療 ESB で見られる高度な SOA 機能に、
これらの需要に対応する内製ソフトウェア開発への負担を減ら
すために、多くの医療機関はエンタープライズサービスバス
(ESB) 製品とそれによるサービス指向アーキテクチャ (SOA) 導
入に目を向けています。特に注目しているのは次の能力です。
医療における相互運用性標準のサポート、SOA 自身が生来的
に持つ高性能データ管理機能、さらに HL7 インターフェイスエ
ンジンの使いやすさと、迅速な統合機能を組み合わせられたも
のです。
 各組織のデータを簡単に取得したり使用したりできるように
する。
 既存のアプリケーションと医師のワークフローに情報を提供
して、よりよい医療連携を行う。
SOA : 医療機関は、成功するために、SOA に対して実践的に
アプローチする必要があります。つまり、必須の SOA 機能に、
医療固有の相互運用性、機能、および標準と組み合わせた、実
績のある医療サービスバスを使用することです。
 医療における通信と相互運用性に関する作業負担を ESB
ベンダーに負わせることで、関連する標準の急速な変化に対
以降に、より連携されコスト効率が高く、医療に対する需要を満
応する。
たす優れた医療サービスバスを選択するためのガイドラインを
ESB と SOA は、特定の業界での適用に限られるものではあり
ません。ただし、これらの技術が、電子商取引とオンライン小売
のニーズに対処するために開発されたことに留意する必要があ
ります。つまり、医療環境に特有の課題を念頭に置いて開発さ
れたものではないということです。
示します。ガイドラインは、標準と相互運用性、データ、管理のし
やすさ、モバイルおよび複合アプリケーションの開発、ならびに
ビジネスモデルの変更の 5 つのカテゴリで構成されています。
標準と相互運用性
認定
進化する標準
医療では、認定された相互運用性にも特別な役割があります。
ほとんどの非医療 ESB 製品は、比較的単純な電子商取引など
記録) を集約して共有することは、医療に特有の課題です。他
の Web スタイルのアプリケーションをサポートするように設計さ
の業界には、医療情報交換と同じような問題はありません。医
れています。これらは、従来の総合医療ネットワーク (IDN) や病
療上のセキュリティ、プライバシー、そして同意 (コンセント) に関
院環境とは違って、動作しているアプリケーションの数が非常に
する懸念を配慮しながら、これをうまく行うには、厳格で堅牢な
少ないこと、さらに、それらのアプリケーションが広範な Web
医療相互運用性標準を導入する必要があります。医療相互運
サービスを提供していることを想定しており、標準による医療
用性を求める医療機関には、次の 2 つが必要です。
複数のアプリケーション間で複雑なデータ記録 (特に複合患者
データ共有はほとんど、またはまったくサポートされていません。
なぜなら、この概念は通常、医療以外にはほとんど意味がない
からです。医療サービスバスは、HL7v2 と HL7v3 のほかに、
以下の標準をサポートする必要があります。
 FHIR®、CDA®、CCD®、IHE プロファイル、NwHIN Direct、
 選択した製品が必要な相互運用性を提供できることを保証
する IHE USA および ICSA ラボによる複数の最新の認定
 複数の IHE プロファイルとドメインに対するきめ細かく実績の
あるサポート、および長年にわたる取り組み
DICOM、X12
 米国以外の国では、ITK (英国)、NEHTA (オーストラリア)、お
IHE : IHE（Integrating the Healthcare Enterprise）は、医療に
よび DMP (フランス) の標準およびプロトコルのサポートも重
おけるコンピュータシステムの情報共有方法の改善に重点を置
要
く推進組織です。これは、完全でそして複合的な医療情報交換
の業界標準です。IHE International は、この相互運用性標準を
非医療 ESB 製品を医療環境で使用する場合、これらのメッ
絶えず改善しており、製品が最新の IHE 認定を取得することは
セージング標準 (およびその特異性) の理解と十分なサポート
相互運用性を保証する上で不可欠です。IHE 認定は、1 回の
がないことは、重大な欠点になります。非医療 ESB は、たとえ
「コネクタソン」イベント (相互運用性のもう 1 つの重要なテスト)
ば、受信側システムから要求される形式で情報を生成するなど、
で示した接続性よりも価値が高く、現在の実世界での製品の相
一般的な医療情報交換の課題を解決できない可能性が高いで
互運用性を、より反映しています。
す。一方、医療サービスバスは、供給側システムの形式でデー
タを受け取り、提供側システムに配信するために必要な形式
(HL7 や CDA/CCD など) に変換することができます。
FHIR : インターシステムズを始めとするますます多くの組織が、
新しい FHIR (Fast Health- care Interoperability Resources)
標準を採用しています。FHIR が、完全に規定されると、IHE (医
療連携のための情報統合化) による標準など、他の標準を補完
します。これは、完全な医療情報文書の相互運用性と交換を実
現するために不可欠です。近い将来、FHIR は、モバイルアプリ
ケーションでのきめの細かい医療情報交換で、おそらく大きな
役割を果たすようになるでしょう。
医療連携における課題の解決 :医療サービスバスの選択
インターシステムズ意思決定ガイド
データ
信頼性
拡張性
情報システムをどれほど強化しても、システム停止を引き起こ
す制御不能な脅威は常に存在します。人の生命が危険に晒さ
医療組織が成長し、接続される医療機器が増加し、在宅医療の
れる環境では、堅牢で信頼できる技術基盤が不可欠です。シス
データソースが統合されるようになり、さらに、新しい診断テスト
テムのダウンタイムとデータの破損は容認できません。
によって複雑なデータが大量に生成され、これらがすべて電子
医療記録 (EHR) システムに接続されるようになると、統合され
たシステムのメッセージングトラフィックと、それらをサポートする
情報量は大幅に増加します。医療サービスバスは、大規模に
拡張可能である必要があります。つまり、レガシーアプリケー
医療サービスバスの信頼性とは、パフォーマンスが実証されて
いること、メッセージ配信が保証されていること、およびハード
ウェア障害からデータ損失なしで自動回復することによりダウン
タイムを最小化できることを意味します。
ションだけでなく、新しいビッグデータ、ソーシャル、モバイル、
実証されたパフォーマンス
およびクラウドコンピューティングのニーズにも対応できることが
医療サービスバスのようなミッションクリティカルなインフラスト
求められます。
ラクチャ技術は、複雑な IT 環境から単純な IT 環境まで広い範
さまざまなデータ型 (構造化、非構造化、画像、文書、メッセー
囲で使用できることが実証されている必要があります。さらに、
ジ) をサポートし、一貫した管理しやすい環境で、臨床データ、
管理データ、ゲノムデータ、および患者入力データを結合できる
プラットフォームが必要です。それは、1 日あたり数百万件の
必要以上に複雑になることなく動作する必要があります。複雑
になると、管理しにくくなり、統合されたシステムが不安定になっ
て、組織は常に「消火活動」モードになってしまう可能性があり
HL7 メッセージ配信の保証、複雑な数メガバイトの X12 文書と
ます。
CCD 文書の処理、ゲノム変異体ファイルの取り込み、分析プ
保証されたメッセージ配信
ラットフォームへの API による接続を確実に行う機能が提供で
重要な医療データは、診療現場で、まさに必要とされるタイミン
きていなければなりません。
グで、常に利用できることが必要です。選択した医療サービス
単純にメッセージを渡すだけのサービスバスを完全な医療情報
バスに、すべてのメッセージとプロセス状態を格納する高性能な
交換のための重要なサービスをサポートするサービスバスに
大規模組織に適合するデータベースシステムが備わっていれ
拡張する場合は、次に挙げるような、強力なデータ管理機能と
ば、データ損失とメッセージ配信の遅延を避けることができます。
性能が極めて重要です。
ダウンタイムの最小化
 マスター患者インデックス
ハードウェア障害、停電、または他の有害なイベントが発生した
 患者の同意 (コンセント)
 複数の医療提供者、場所、および受診歴を横断し、包括的な
場合、医療サービスバスは、医療組織のサービスレベル目標
および遅延許容範囲に適合するよう、回復の選択肢の提供が
必要です。
医療記録の集約
 分析
管理のしやすさ
ソリューションの開発は単発の作業ですが、その管理は長期に
わたって必要です。したがって、管理のしやすさは重要な選択
要因になります。接続・連携された医療ソリューションは管理が
困難です。なぜなら、このソリューションはまったく異なるアプリ
ケーションコンポーネントを接続し、多くの場合、それらは複数
のハードウェアプラットフォーム、オペレーティングシステム、技
術フレームワークに渡っているためです。医療サービスバスに
は、(オンプレミスとクラウドベースの) ハイブリッド環境で同じよ
うに使うことができる管理機能が必要です。
医療サービスバスには、このようなソリューションのすべてのコ
ンポーネントを表示、モニタリング、および管理する一貫した一
元管理ポータルの提供が必要です。
システムの問題に対する自動アラート
ESB に関する問題の多くは、開発およびテストの期間中には見
ビジネスプロセスオーケストレーションと
人のワークフロー
つからず、運用が始まってから発見されるものです。努力と最
ビジネスプロセスは、患者の入院手続きといった目的を完結す
善の措置を施したにも拘らず、アプリケーションは継続的に使用
るために実行する一連の作業です。オーケストレーションとは、
不能となり、ソフトウェアのアップグレードが全員に周知されるこ
技術よりもプロセスに重点を置いた設計活動です。
となく実行され、ネットワークとデータにエラーが発生します。故
に、医療サービスバスには、堅牢で柔軟なイベントモニタリング
とアラートを備え、問題発生時に主要関係者に通知する機能が
必須です。また、こうした問題を速やかに診断して修正する、簡
このような観点で、医療サービスバスは、アナリストや開発者が
システム間の論理的な相互作用に重点を置きながら、ルールと
ワークフローを含むプロセスと情報フローのダイアグラムを作成
することができるグラフィカルツールを提供する必要があります。
単で強力なメカニズムも必要です。
ESB は同期した要求と応答に重きをおいて処理するのが普通
求められる機能には次のものがあります。
 システム状況を一目で確認できるダッシュボード
 重要なイベントの検出時の電子メール、電話、または他の方
法による自動アラート機能。イベントは、発生したこと (たとえ
ば、メッセージキューがその日時における制限値を超えた)
ですが、ほとんどの医療機関は非同期に機能しています。中に
は長期にわたって行われるプロセスを伴うこともあります。医療
サービスバスは、イベントドリブン、非同期、および長期間に及
ぶビジネスプロセスもサポートしており、医療機関でサービス
バスを有効利用するために不可欠です。
の場合もあれば、発生しなかったこと (たとえば、所定期間内
最も効率が良く機能的にも強力な複合アプリケーションには、次
に救急部門からメッセージを受信しなかった) である場合もあ
の機能を持つ医療サービスバスが必要です。
ります。アラートを確認したオペレータが、速やかに問題を理
解し、素早く診断して修正方法を提供できる必要があります。
 （外部データベースや分析ソフトウェアにデータを再投入する
 プロセスと情報フローをダイアグラム化する機能豊富なグラ
フィカルエディタ
 ビジネスプロセスダイアグラムに基づく自動コード生成
必要なく）システムを通過するメッセージを集約し、分析およ
びレポートする機能
 人のワークフローを含む長期間におよぶビジネスプロセスの
サポート
 システム稼働中に個々のインターフェイスを停止、開始、そし
てアップグレードする機能
 ユーザーの意思決定を自動的にビジネスプロセスに組み込
みながら、ユーザー間でのタスク配分と移動を行うワークフ
 システムを通過するあらゆるメッセージをトレースし、一連の
ローエンジン
プロセス中の各ステップの各ステージでの変換結果、および
関連するエラーを見ることができる機能
サービスとしてのアプリケーション : ボストンに拠点を置くパート
ナーズヘルスケアは、米国の大手統合医療システムプロバイ
ダであり、インターシステムズの HealthShare を使用して、200
個以上のエンタープライズアプリケーションを、彼らが提供する
ネットワーク全体でソフトウェアサービスとして利用できるように
しています。これらのサービスは、パートナーズのイベント通知
フレームワークを基盤に提供され、パートナーズのネットワーク
を通して、医師に、有用なアラートやその他のサービスを提供し
ています。
医療連携における課題の解決 :医療サービスバスの選択
インターシステムズ意思決定ガイド
モバイルアプリケーションと
複合アプリケーションの開発
基盤となるサービス、アプリケーション、およびデータソースが
医療機関が個別開発ソフトウェアからパッケージソリューション
ションを作成できることが必要です。医療サービスバスは、「ど
に移行すると、マネージドケアへの効果的な移行や、タスク固
こでも動作」という約束の下、統合された呼び出しを、API また
有のモバイルアプリケーションの作成といったイノベーションが
は Web サービス経由でエンタープライズアプリケーションに配
困難になります。医療機関は、ソフトウェアベンダーの製品スケ
信する必要があります。エンタープライズアプリケーションは、
ジュールとロードマップに縛られる可能性があります。医療サー
モバイルアプリケーションの動作に必要なデータを保持してい
ビスバスを採用する目的の 1 つは、ローカルなイノベーションを
ます。新しい医療機器の登場によって、医療のイノベーションは
実現すると同時に、パッケージソリューションによる規模の経済
加速します。したがって、医療サービスバスは、経済的で予測
を担保することです。医療サービスバスは、購入したアプリケー
可能な方法で、それらの機器をデータ収集アプリケーション
ションの動作や軽量なモバイルアプリの作成を拡張する手段と
(EHR システムなど) に接続できることが必要です。
サイトあるいはクラウドに展開されているかどうかに関係なく、
開発環境ではモバイルアプリケーションや他の複合アプリケー
して、SOA および重要な医療相互運用性標準をサポートするこ
とが必要です。特に FHIR のサポートは、医療の展望を改革す
るソーシャル、モバイル、そしてクラウドコンピューティングへの
シフトをサポートするために、タスク固有のデータを抽出および
提供するために重要です。
医療サービスバスによって内部と外部のリソースの統合がされ
統合された技術 : ベンダーが合併や買収を通して寄せ集めた
ESB/SOA プラットフォームの採用は慎重に行って下さい。その
様なサービスバスの統合は、エンタープライズの接続よりも労
力が必要となるでしょう。あくまでも統合されたプラットフォーム
を推奨します。
た後でも、ユーザーが期待する機能と提供される機能にギャッ
プがあることはよくあります。開発者や開発ツールを追加したり、
プロジェクトを遅延させたりせずに、短期間で簡単に、この
ギャップを埋めるビジネスロジック (複合アプリケーション) を作
成する機能は不可欠です。次のような強力な開発機能を持つ
医療サービスバス製品が必要です。
 サービスの作成、ビジネスプロセスオーケストレーション、ビ
ビジネスモデルの変更
戦略的相互運用性への道
診療報酬モデルは診療ごとの支払いから価値に応じた支払い
ジネスルールの作成、データ変換、ワークフロー、イベント処
へと進化しており、医療 IT はその進化をサポートするようにシフ
理、ダッシュボード作成の各機能を備えた、単一の一貫した
トしています。それと並行して、医療 IT は単純な HL7 インター
グラフィカル開発環境
フェイスエンジンから戦略的相互運用性プラットフォームへと進
化しています。価値に応じた支払いは、保険会社、医師、および
 ルールベースのメッセージルーティング
患者のインセンティブを、医療の連携を深め、品質を高め、コス
 既存のバックエンドサービスが必要なすべてのビジネスロ
ト効率を高めるという目標に合致しています。戦略的相互運用
ジックまたはデータを提供できない場合に、プロジェクトを完
性は、医療コミュニティ全体 (プロバイダ、保険会社、および患
了することができ、さらにモバイルアプリを作成するための
者) の包括的な医療記録を、適切なタイミング、有効な方法で集
迅速な開発機能
約し共有することにより、価値に応じた支払いをサポートします。
 サービスラッピング — Web サービスを提供しないアプリケー
ションに基づいてサービスを提供する機能
 コーディングすることなく、サービスの公開と利用ができる
価値に応じた支払い
1
: 業界全体の医療費支払いの改革を主
導しているメディケアメディケイドサービスセンター (CMS) は、
2016 年までに、新しい支払いモデルを通じてメディケアの支払
いの 30% を品質または価値に結び付けることを計画していま
す。2018 年までに、年間 5,000 億ドルを超える CMS の支払額
の 50% が、この価値に応じた支払いモデルを通じて行われる
ようになります。
戦略的相互運用性を実現するには、機能拡張が可能で、使用
HealthShare Health Connect
するコンポーネントを事前に統合する必要のない、統合された
サービス指向フレームワークが含まれる医療サービスバスを選
択する必要があります。考慮すべき拡張機能には、医療データ
の集約と正規化による包括的医療記録の作成のほか、マス
ター患者インデックス、ワークフロー、同意、用語、臨床ポータル、
分析、および患者関与の各機能が挙げられます。
HealthShare Health Connect は、インターシステムズが提供す
る医療サービスバスであり、グローバルな医療情報プロトコル
とメッセージング形式に基づく統合機能を提供します。Health
Connect は、大容量トランザクションのサポート、傑出したプロ
セス管理、および医療という「常時稼働中」のビジネスに必要な
継続的モニタリングを提供します。Health Connect の機能の一
医療サービスバスは、価値に応じた支払いを実現する上で、中
部を次に示します。
核的な役割を果たすと同時に、管理しやすく、システムの問題を
管理者に自ら通知する役割も果たす必要があります。また、ビ
ジネスの俊敏性を増すために新しい変化するビジネスプロセス
を迅速にモデル化およびサポートする機能も提供する必要があ
 認定済標準対応の統合機能
 ビジネスプロセスとワークフロー管理
 データ変換
ります。
 イベントの検出とモニタリング
 拡張性とセキュリティ
最後の質問
 視覚的な診断と監査
HealthShare ファミリーの追加モジュールは、製品の機能を拡
サポートおよびベンダーの利用しやすさ
医療の主要アプリケーションでは、ベンダーサポートが重要で
張して、お客様の増大する要件に対応します。次のモジュール
があります。
す。複数のアプリケーションと Web サービスを統合する統合ソ
 HealthShare Information Exchange : 広範な相互運用性
リューションでは、さらにその重要性が増します。ベンダーのカ
と安全な医療情報交換のために必要な機能と技術がすべて
スタマサポート担当者の知識と熱心さのレベルについて、その
統合されています。
統合ソフトウェアの他のユーザーに尋ねてみると良いでしょう。
 医療について理解し、あなたの状況に詳しいエンジニアに、
一年中いつでも電話ですぐに連絡できますか。
 ベンダーはあなたと同じタイムゾーンの地域にサポート専門
家を配置していますか。
 製品はベンダーの宣伝どおりに動作していますか。
 ベンダーは、その顧客が製品を稼働する前、稼働開始時、お
 HealthShare Patient index : 医療組織内や医療情報ネッ
トワーク全体で、患者 ID の唯一の信頼できる情報源。
 HealthShare Personal Community : 患者が積極的に参
加するコミュニティを構築するための包括的で拡張可能なソ
リューション。
 Health Insight : 高度な医療分析のためのデータを提供しま
す。
よび稼働した後に立ち会っていましたか。
 カスタマサービスは期待以上でしたか。
お問い合わせ窓口
医療サービスバスとサービス指向 IT インフラストラクチャへの
移行のご相談およびインターシステムズがお手伝いできる内容
については、次の窓口までお問い合わせください。
 jpcontact@InterSystems.com
 インターシステムズジャパン Tel: 03-5321-6200(代)
医療連携における課題の解決 :医療サービスバスの選択
インターシステムズ意思決定ガイド
1
『Setting Value-Based Payment Goals — HHS Efforts to Improve U.S. Health Care』、Sylvia M. Burwell 著、2015 年 1 月 26 日、NEJM.org.
インターシステムズジャパン株式会社
〒160-0023
東京都新宿区西新宿 6-10-1
日土地西新宿ビル 15F
Tel: 03-5321-6200 (代)
Fax: 03-5321-6209
InterSystems.com/jp/
InterSystems HealthShare は、米国インターシステムズ社およびその子会社の登録商標です。
その他の製品は、該当各社の商標または登録商標です。 Copyright © 2015 InterSystems Corporation. All rights reserved. 8xx-15

Download Report