白書とアナリスト・レポート
InterSystems HealthShare™ による
全国および地域での診療情報の共有
連携した医療に向けての素早い道
 |
目次
I. 全国および地域での診療情報の共有
II. HealthShare のアーキテクチャ
- HealthShare のアーキテクチャの概要
- HealthShare EPR (電子患者記録)
- HealthShare Hub
- HealthShare Edge Cache Repository
- HealthShare Gateway
III. 先進機能
IV. HealthShare システムの運用
V. まとめ
I. 全国および地域での診療情報の共有
InterSystems HealthShare の概要
世界中の医療を提供するシステムで、地域および全国の電子診療記録 (EHR) の構築にますます注目が集まっています。診療情報の共有によって重要な医療情報に容易にアクセスできるようになり、検査や処方箋の重複を排除してコストを軽減することが可能です。また最も重要な点として、質の高い医療の提供が期待できます。緊急の際にこのような情報が入手できることにより、実際に人命を救うことができます。
多くの場合、このようなソリューションは、その場限りのプロジェクトとして取り組まれています。ただし、医療システムは複雑であるため、カスタム・プログラミングに基づくそのような高性能な診療アプリケーションの開発は、実用的でも経済的でもありません。さまざまな異なる既存システムに格納されている情報を効果的に集約および共有するには、実績豊富なコンポーネントを組み込んだ製品ベースのアプローチが必要です。同時に、地域や国によってニーズが多種多様であるため、容易かつ迅速に拡張できる製品を使用して、追加機能を実現することが不可欠です。
そのような製品は、以下の要件を満たしている必要があります。
- EHR への臨床医のアクセスは、この目的専用に作成された単なる "ビューワ" や "ポータル" ではなく、要求の厳しい医療環境で使用されている実績豊富なアプリケーションに基づいている必要があります。
- 患者記録のデータベース構造は、病院、診療所、地域などの多様な環境で臨床面から実証された情報モデルを採用した、実績豊富な製品に基づいている必要があります。可能であれば、複数の国での実績があることも望まれます。こうした製品は、多様な組織の複雑なニーズをサポートし、要件の必然的な増大に伴って発生するニーズにも対応できます。
- 特にHL7 のバージョン 2 および 3 など、多様なソースにある診療情報および個人情報を迅速に統合するには、強力な統合プラットフォームが必要です。1 つの共通のフォーマットを既存のシステムがサポートする (または遠からずサポートするようになる) とは現実的に考えられないので、他のフォーマットに対するサポートを短期間で開発できることが重要です。
- コア・データベースと統合テクノロジは、短期間での開発とカスタマイズができ、大規模な拡張性をもつ必要があります。
- 標準規格ベースの強力なアプローチが必要です。
InterSystems HealthShare™ は、これらの要件を満たした革新的なソフトウェア製品です。この製品を使用すると、地域単位や国単位の複数の医療機関の間で、全EHR にまで及ぶ臨床データが集約および共有できます。また、拡張が容易で、電子処方やオーダ送受信などの追加機能を実現できます。これは、ビジネス・ルールとビジネス・プロセスの追加、複合的なアプリケーションの構築、インターシステムズのパートナが提供する付加アプリケーションを使用することによって可能となります。
HealthShare は、論理的に以下の 4 つのコンポーネントで構成されています。
- HealthShare EPRはブラウザ・ベースの高性能な電子患者記録 (EPR) で、医師が患者データにアクセスする際に使用します。
- HealthShare Edge Cache Repositoryは臨床データベースです。通常の場合、各医療機関は、医療機関が共有を望むすべての臨床データを保持した Edge Cache をもちます。
- HealthShare Gatewayは、複数の医療機関を接続するように最適化された医療統合プラットフォームです。各医療機関には、その医療機関の既存システムと Edge Cache を接続した Gateway があります。Gateway には、EPR のユーザを他の Edge Cache および Hub に接続する役割もあります。
- HealthShare Hubは、患者と医療機関の中央インデックスです。Hub は、患者を一意に識別するために使用され、その患者のデータがどの Edge Cache に保持されているかを指定します。Hub には臨床データが格納されていません。
HealthShare は、InterSystems Caché®、InterSystems Ensemble®、TrakCare™など、世界中で膨大な数の病院で使用されているインターシステムズのテクノロジを基盤にしています。
Caché は、世界中の診療医療アプリケーションの分野で広く採用されているデータベースで、米国退役軍人省や米国防総省のすべての病院、Kaiser Permanente ネットワークなどで使用されているコア・データベース・テクノロジです。『U.S. News and World Report』誌で米国の優良病院トップ 10 にランクされている病院すべてで Caché が使用されています。
Ensemble は、医療プロジェクトで広く使用されている高速インテグレーションプラットフォームです。このプラットフォームは、KLASによる調査で 2006 年の医療業界向けインタフェース・エンジン No.1に選ばれており*1 、ガートナー社の Magic Quadrant for Application Infrastructure for Composite-Application Projects, 2Q07 ( 2007年 第２四半期 コンポジットアプリケーションプロジェクトのためのアプリケーションインフラストラクチャに関するマジック・クアドラント」) レポート*2 で「リーダーズ・クアドラント」に位置づけられました。
TrakCare は、Web ベースの包括的病院情報システムで、患者を中心とした高性能な電子記録を中心に設計されています。小規模な診療所から膨大な患者を有する州全体のシステムに至るまで、世界中の病院で使用されています。TrakCare は、インターシステムズの子会社 TrakHealth の製品です。
このドキュメントでは、EPR とは、1つの医療機関で使用されている患者の電子医療記録を指します。HealthShare EPR など、患者記録へのアクセスや患者記録との対話に使用されるソフトウェア製品を指す場合もあります。EHR は、複数の医療機関で共有されている情報を統合した電子医療記録を複合的な視点から見るシステムを指します。
診療情報システムの進化
過去 30 年間、診療アプリケーションは、検査や放射線など、高性能化の進む部門別アプリケーションの開発によって全体としての進歩の道を歩んできました。近年では、システム間の対話を行い、より統合的な患者のビューを医師に提供することを目指して、主に施設単位で多大な努力が払われています。
一方、病院情報システム構築に対する最新のアプローチは全く異なり、患者の医療記録をシステムのコアとして位置付け、患者指向の傾向を持つものとなってきています。そのコアの周囲に部門別アプリケーションが構築され、医療記録内の情報へのアクセスや医療記録への情報の格納を直接行います。臨床医は、ユーザ・インタフェースに一貫性のない独立した多様な部門別アプリケーションを使用するのではなく、包括的な EPR を使用してデータにアクセスします。EPR を重視することにより、患者の医療記録を総合的な視点で見ることができ、機能の追加が可能になり、臨床医とのより洗練された (多くの場合、より高速な) 対話が実現します。言うまでもなく、このアプローチでは、品質、機能、使いやすさの面で EPR に対して高い要件が発生します。
同じように、様々な地域が診療情報の共有に対して多様なアプローチを採用しており、地域ごとに特定の機能を重視し、その機能のみを実現できるようなネットワークの設計および構築を模索しています。たとえば、ある地域では、検査機関や薬局からの情報共有から着手しようとしています。
この意味では、部門別のアプリケーションを構築するという旧来型のアプローチに似ているといえます。問題は、その基盤がシステム拡張の範囲としてどれだけ機能するか、あるいはそもそも基盤ができるのか、という点です。
どのような地域システムや全国システムであっても、患者を中心とした最新式のアプローチを採用し、フル機能の EHR に対応できる基盤テクノロジから始めることが最善のアプローチと考えられます。全面的な EHR ほど目的の高くないプロジェクトから開始するとしても、将来発生する要件を容易に満たせるように少なくとも基盤は作っておくということでも意義はあります。加えて、臨床医が最初から EPR インタフェースを使用することにより、新しい機能の導入は、大いに容易かつ自然になります。この構造の周囲には、電子処方やオーダなど、他の診療機能を追加できます。
IDN と病院グループ
総合医療ネットワーク (IDN) と病院グループでは、臨床データの集約および共有に対して、類似のニーズに直面することが増えています。これは、以下のような要因から発生するニーズです。
- これらのグループは、買収によって大規模になったという経緯が多いため、いくつものシステムが並存し、システム間の統合が進んでいません。メッセージング・システムを使用した多大な努力が払われていますが、臨床医は多くの場合、完備された医療記録にアクセスするという簡単な方法を使用できないでいます。これは、総合的な医療を提供するという目標にそぐわない事態です。
- これらの組織では、医師が高性能な EPR にアクセスできるようにし、診療情報を共有することによって、地域内の医師相互間の連携を強めることができます。
- 施設間での情報共有は、癌や HIV の患者のように、長期間にわたる治療を要する患者の追跡と治療にとって大いに助けとなります。
これらの組織の要件は、地域システムと全国システムのどちらでも、基本的には同じですが、多くの場合、いくつかの追加要件があります。たとえば、IDN はかかりつけ医院に結果を "プッシュ" したり、あるいは少なくとも医師に対して、担当患者に関する新しい情報があることを通知したいという要望があります。これらのニーズは日々進化する特性を持つことから、実績豊富な医療製品に基づく堅固な診療基盤や、複合アプリケーションによって短期間で新機能を開発できる機能を持つテクノロジの選択が重要であることは明らかです。
II. HealthShare のアーキテクチャ
HealthShare のアーキテクチャの概要
設計理念
HealthShare のアーキテクチャは、以下の要件を前提としています。
- 他の機能が用意されている場合であっても、医療記録がシステムの中心になっています。
- 医療用語はすべて標準化することが望まれますが、多くの場合、少なくとも初めのうちは実現は困難です。システムは、様々な用語を使用した複数のソースからデータを収集して表示できることが必要です。
- (患者の機密保持のための) 同意ポリシーは、国によって異なります。
- 医療機関における既存の EPR は、必要に応じて、電子的な医療記録を提供できます。ただし、より一般的には、(検査テストの実行など) トランザクションの発生時に部門別システムによって生成されるメッセージから情報を蓄積し、新しいデータベースに保持する必要があります。
- システム内の通信およびメッセージのプロトコルには標準規格ベースの高性能なものを採用します。これにより、将来他の地域システムや全国システムと接続できるようになり、今後主流となるような新しい電子医療記録システムとの相互運用もできるようになります。
- メッセージのフォーマットの標準化を図りますが、既存のシステムを統合できるように様々なレガシ・フォーマットをサポートする必要があります。多くの場合、そのようなフォーマットは、個々の部門別システムに固有のものです。
HealthShare のコンポーネント
HealthShare Hub は中央コンピュータで、すべての患者のインデックスを保持し、各患者に関する情報がどの HealthShare Gateway に存在するかを把握しています。Hub は、エンタープライズ・マスタ・ペイシェント・インデックス (EMPI) を所有するか、または既存のインデックスを使用します。ここには臨床データが格納されていません。
各HealthShare Edge Cache Repositoryは、医療機関が共有を望む情報を保持した高性能な EPR データベースです。通常、大規模な医療機関には 1 つずつあり、小規模な医療機関では複数で Edge Cache を共有する場合があります。このアプローチでは、臨床データは、収集した施設の管理下に置かれたままです。
HealthShare Gatewayは、医療機関の既存システムと Edge Cache を接続します。(検査結果など) 部門別システムからメッセージが流し込まれると、Gateway はメッセージを変換し、組織の Edge Cache に患者のデータを挿入します。さらに、臨床医が情報を要求すると、Gateway は臨床医と Hub を接続し、患者を識別してその患者のデータがどこにあるかを判別します。次に、他の Gateway および Edge Cache と通信し、患者のデータを取得して臨床医の EPR に返します。
HealthShare EPRはブラウザ・ベースの高機能な医療記録アプリケーションで、臨床医にユーザ・インタフェースを提供します。Gateway から返された患者のデータが集約され、臨床医の EPR にローカルに格納されます。次にそのデータは、臨床医が削除要求するまで、EPR で使用することができます。
HealthShare の構成
HealthShare は、様々な構成をサポートしています。通常の場合、HealthShare Hub は 1 つしかありませんが、各医療機関 (場合によっては複数の医療機関で構成されるグループ) には、独自の HealthShare Edge Cache Repository と HealthShare Gateway があります。多くの場合、Gateway および関連する Edge Cache は、医療機関の施設または複数の小規模医療機関で構成されるグループの共通施設にありますが、他の構成も可能です。別々の Edge Cacheを持つより、中央データベースの構築を好む地域もあれば、両者が混合した環境を好む地域もあります。
次のページにあるグラフィック (図 1) は、単純な構成で HealthShare を配置した様子を示しています。ここでは、2 つの医療機関と 1 つの検査機関が、お互いに臨床データを共有しています。
図 1. HealthShare のアーキテクチャ。この例では、これらの部門別システムで更新が発生すると、診療システムおよび検査システムから Edge Cache Repository にデータが流れます。参加組織で新しい患者が追加されると、Hub にある EMPI に入力され、Hub は各患者に関する情報がどの Gateway に存在するかを把握します。グループ開業医 (および他の場所) に属している医師は、HealthShare EPR を使用して、統合と整理がなされたエピソードに基づいた形で、患者の医療履歴を参照します。
HealthShare の使用方法
HealthShare の各コンポーネントの役割を理解するために、単純な例を挙げます。グループ開業医に属するある医師が、患者の臨床データを必要としています。このデータを利用する場合、基本的には、(a) 患者を特定し、その患者の診療情報が格納されている場所を判別する、(b) 様々な施設から患者の情報を入手し、臨床医のローカル EPR に入れる、(c) 患者のデータを表示し、このデータと対話する、という 3 つの手順を踏みます。多くの場合、最初の 2 つの手順は、前夜のうちに、または患者が来院したときに支援スタッフが実行します。
患者およびその患者のデータが格納されている場所を識別するには、(医療機関の Gateway を経由して) HealthShare Hub にクエリを送信します。Hub はその患者に関する情報をどの Gateway が所有しているかを指定するメッセージを返します。次に、医療機関の Gateway は、それら他の Gateway それぞれに対してメッセージを送信します。これらのメッセージは、患者のデータすべてを要求する場合もあれば、フィルタを設定して絞り込んだデータのみを要求する場合もあります。次に、これらの Gateway はそれぞれ、要求された情報を Edge Cache Repository から取得して、臨床医の Gateway に返信します。次に、臨床医の Gateway は、それらのメッセージを臨床医の HealthShare EPR (または、メッセージを読み取る機能を備えた、この医師が使用している別の EPR) に渡します。受け取った EPR は、このメッセージをローカルのデータベースに格納します。取得されたこのデータは、臨床医が記録を削除するまで (またはあらかじめ割り当てられた期間が経過するまで)、再利用できるようにローカルの EPR に保持されます。
HealthShare EPR (電子患者記録)
臨床医がこのシステムを使用するときには、必ず HealthShare EPR を使用します。このベースとなっているのは、Web ベースの高性能な EPR アプリケーションである TrakCare で、全世界の数百の病院で広範に使用されているという実績があります。一方、組織独自の医療記録システムを使用することもできます。その場合、このシステムがサポートしている標準規格およびプロトコルが、HealthShare で使用されているものと同じであり、必要に応じて、標準化されていない用語をサポートできることが条件です。
地域全体で患者の検索を実行するには、HealthShare EPR は、医療機関の Gateway を経由して、Hub およびその患者のデータが格納されている他の Gateway に接続します。次に、複数の施設や複数の臨床エピソードから受け取ったデータをまとめ、豊富な情報量を持つ包括的な、患者を中心としたビューを用意します。
EPR には、各種の情報がわかりやすく表示されます。表示される情報には、患者の個人情報、アレルギ、投薬治療、診断、検査結果 (範囲、累積、およびグラフ形式による結果)、放射線の結果 (テキストおよび画像)、家族の病歴、臨床所見、経過記録などがあります。データは、一連のタブとして臨床分類に整理されます (図 2 を参照)。タブの上にある時間表には、各エピソードとそれに関連する期間が表示されており、これを使用すると、調べる具体的なエピソードを迅速に検索できます。図 3 は、患者が現在受けている投薬記録を表示するように、医師が選択した状態です。
図 2. ある患者が複数の施設で最近受診した外来診察を表示した HealthShare EPR
図 3. この患者の投薬記録を表示した HealthShare EPR
HealthShare は、自由に構成することが可能で、実際に使用する手順や画面は、地域的な要件と複数の言語を反映するように大幅に変更できます。臨床医は、他のアプリケーションで使用できるように、EPR の詳細情報を Clinical Document Architecture (CDA) ドキュメントとしてエクスポートすることもできます。
HealthShare EPR は、自己ドキュメント式のデータ・テクノロジを利用しているため、複数のソースにある、標準化されていない用語の受信および表示に対応できます。
Web ベースのテクノロジである HealthShare EPR は、配置とサポートが極めて簡単です。必要なのは Web ブラウザだけで、クライアント側にインストールするコンポーネントはありません。
HealthShare Hub
HealthShare Hub は Ensemble をベースにしたもので、以下の 3 つの機能が用意されています。
- 識別情報管理によって、複数の医療機関に 2 つの記録があったときに、同じ患者のものか別々の患者のものかを判別
- 診療患者インデックスによって、目的の患者の情報を保有している医療機関がどこかを判別
- 管理情報 (認定されたユーザ一覧、Gateway アドレス、セキュリティとプライバシに関する情報など)
データは複数の医療機関によって収集されるため、地域システムや全国システムが機能できるようにするには、患者を一意に識別し、複数の医療機関にあるデータのうち、どれが同じ患者のものかを判別する方法が必要です。全国共通の ID 番号があれば問題は簡単になりますが、そのような仕組みが必ずあるとは限りません。
全国共通の ID 番号がないときには、通常 EMPI によって識別情報管理が用意されます。これは、IDN と病院グループですでに広範に使用されています。
すでに EMPI が導入されている医療機関の場合、HealthShare Hub はその EMPI を使用します。導入されていない医療機関の場合、HealthShare にはいくつかの代表的な識別情報管理製品をサポートする機能が用意されているため、これを使用して他の製品にも対応できます。
EMPI に格納されている情報は必要最小限のもののみです。臨床データは格納されておらず、患者の個人情報のサマリと、各医療機関がその患者を識別するために使用する識別子だけが格納されています。ある医療機関がプログラムに参加すると、患者インデックスの情報が一括でロードされます。その後、この情報はその医療機関でのデータの変更に応じて継続的に更新されます。データの変更には、患者の新規追加、既存患者データの更新、同一の患者に 2 件の患者記録が見つかったために既存の記録を 1 つにまとめる処理などがあります。
EMPI には、様々な個人データを検索できる高性能なマッチング テクノロジが用意されています。ただし、EMPI を使用するときも、一部の新規患者については、引き続き手動で確認する必要があります。
HealthShare Edge Cache Repository
ある医療機関に対して、患者の臨床データの入手を要求するとき、データのソースとしては、以下の 3 つが考えられます。
- すべての臨床データが (HealthShare Hub などにある) 中央データベースに格納されている場合は、そこから取得する。
- この医療機関の電子カルテ・システム、または医療機関のソース・システムに要求する。
- 医療機関が共有を望む臨床データをすべて保持したデータベース Edge Cache に要求する。
HealthShare はこの 3 つの方法すべてをサポートしていますが、一般的に最も実用的なのは Edge Cache によるアプローチです。中央データベースは規模が巨大になることが普通なので、一医療機関の管理能力では扱いきれなくなります。医療機関のソース・システムに要求を渡すことには、(a) 多くのソース・システムには、要求に応答できるサービス指向アーキテクチャ (SOA) がなく、代わりに、トランザクションの発生時に、検査結果などのトランザクション・データを他のシステムに渡すことしかできない、(b) 複数のソース・システムにクエリを送信する必要があるために、応答時間に関して深刻な問題が発生する可能性がある、(c) 特定のソース・システムが使用できなくなる場合がある、といった問題があります。医療機関の医療記録システムに要求を渡す方が実用的ですが、それでも同じ問題が発生する可能性は残ります。また、セキュリティ上の理由により、これは優れたアプローチではないと考える医療機関が多数存在します。主要な治療施設や小規模なグループ開業医では、システムが 1 日 24 時間稼働することすらおぼつきません。
Edge Cache を使用することには、ビジネス・インテリジェンスや SQL レポートのツールを使用してクエリができるため、利用率、公衆衛生、研究など役に立つ情報を導き出せるという、別の大きなメリットがあります。地域または国全体で用語を標準化することはできなくても、それらの用語は 1 つの Edge Cache に置かれる可能性が高いため、クエリがさらに便利になります。
HealthShare Edge Cache Repository は、HealthShare EPR で使用されているテクノロジと同じ TrakCare テクノロジと Caché オブジェクト・データベースを使用した、高性能な医療データベースです。臨床データを含むトランザクションが発生すると、ソース・システムが医療機関の Gateway にメッセージを送信します。受信した Gateway はメッセージを変換し、医療機関の Edge Cache に渡し、メッセージはそこに格納されます。
通常、Gateway ごとに独自の Edge Cache があり、大規模な医療機関ごとに独自の Gateway および関連する Edge Cache があります。小規模な医療機関 (主に治療医師や小規模なグループ開業医) は、多くの場合、Gateway および Edge Cache 用のコンピュータを 1 台共有します。各 Edge Cache には、同じ Gateway を共有している医療機関の診療情報のみが格納されます。ただし、他の構成も可能です。極端な場合、1 つの中央データベースにすべての Edge Cache を置くこともできます。
(医院の業務管理システムや病院の EPR のような) ソース・システムでは、中断があってもデータの可用性を維持する上で、Edge Cache は重要です。これがないと、データが使用できなくなる可能性があります。Edge Cache は、年中無休、1 日 24 時間稼働できるように設計されています。
HealthShare Gateway
HealthShare Gateway のベースとなっているのは Ensemble です。これは、インタフェース・エンジンとして、また複合アプリケーションを構築および実行するために、医療業界で広く使用されている高速なインテグレーションプラットフォームです。
HealthShare Gateway は、次のコンポーネント間のすべての通信を担当します。
- 診療施設と関連する Edge Cache との間
- 診療施設と Hub との間
- 2 つの診療施設の Gateway 間
各 Gateway には、以下の機能も用意されています。
- 同意管理フレームワーク (患者の同意宣言の記録、およびそれらの宣言の実行に使用)
- データ標準化サービスと用語サービス (存在していて、かつ必要な場合)
- メッセージ・プロトコルの変換
医療機関のシステムは、共有可能な情報を生成すると、Gateway にメッセージを送信します (例、検査テストが完了すると、検査結果が Gateway に送信される)。Gateway はそのメッセージを調べ、情報の性質と、キャッシュするのに適しているかどうかを判別します。適している場合は、そのメッセージを、HealthShare の標準プロトコルを使用するメッセージに変換し、Edge Cache に送信して格納します。
臨床医が、通常は HealthShare EPR を経由して、患者に関する情報を要求するときには、EPR が臨床医の Gateway にメッセージを送信し、受信した Gateway が HealthShare Hub と通信します。接続が必要な他の Gateway を Hub が特定した後、臨床医の Gateway がそれらの Gateway に接続し、その施設にある患者のデータを要求します。これらの Gateway は、関連する Edge Cache にクエリし、結果として得られたデータを XML 文書形式で元の Gateway に返します。次にこの Gateway は、他の様々な Gateway から受信した XML 文書をすべて、要求元の EPR に提供します。
HealthShare は柔軟性に富んでいるので、Gateway 同士で直接データを受け渡しできるほか、Hub を経由して Gateway のメッセージをすべて渡すこともできます。この両者を混合することが適切な場合もあります。
III. 先進機能
用語サービス
医療機関ごとに使用する用語が異なるために、情報を共有する上の障害となっていることがあります。医療機関が共通の用語に変換するか、少なくとも、相互交換用の共通標準に合意してサポートできれば理想的です。ただし、多くの場合、そのような対応は現実的ではありません。少なくとも相当の時間がかかります。
HealthShare には、共通の用語は不要です。HealthShare EPR と Edge Cache は、自己ドキュメント方式のデータ・テクノロジを採用しているため、複数のソースにある、標準化されていない用語の格納および表示ができます。
標準化されていない用語の共有を望む医療機関のため、HealthShare には、アプリケーションに依存しない代表的な用語サービスを使用できるオプションが用意されています。これらのサービスでは、SNOMED、ICD 9/10、CPT、LOINC など、いくつかの標準的な医学ボキャブラリの間で翻訳が行われ、Gateway に組み込むことができます。これらの翻訳サービスの設定は、医療機関側で行います。
機能の拡張
人間同様に、組織も成長して生き残りを図る必要があります。そして、医療地域とそこでの患者のニーズが進化するに連れて、接続された医療システムも進化できる必要があります。最初に行う接続と情報の共有は、ほんの始まりに過ぎません。重要な問題は、将来の成長と迅速な対応への基盤をシステムが提供するかどうかです。
HealthShare の接続性は Ensemble によって実現しており、Ensemble には、ビジネス・プロセスとワークフローの管理に対するサポートが用意されています。"複合アプリケーション" という新世代のアプリケーションも可能です。加えて、HealthShare には Caché も組み込まれているため、他の機能を追加しやすくなっています。
Ensemble のビジネス・プロセス
地域によって要件が異なることも珍しくありません。たとえば、ある地域では、様々なイベントが起こったときに、公衆衛生上の警告を発することを望む場合があります。さらに、そのようなイベントの性質や対応措置は、患者によって異なる場合があります。女性患者の場合は、さらに措置を講じる前に、産科システムへの問い合わせが必要となることが多いと考えられます。
これらのニーズに対応するための強力な手法は、Ensemble のビジネス・プロセスを使用して実施します。Ensemble では、組織に固有のビジネス・ルールおよびビジネス・プロセスをいくつか指定できます。これにより、それらのルールおよびプロセスが自動的に適用されます。
ビジネス・ルールとビジネス・プロセスは高レベルで定義されており、完全にカプセル化されるため、修正が容易です。したがって、HealthShare またはそのアダプタ (以下で説明します) を修正しなくても、アプリケーションまたは医療機関にある固有の差異や進化するニーズをすみやかに吸収できます。
複合アプリケーション
複合アプリケーションとは、接続されたシステムをベースにした新世代のアプリケーションです。そのようなアプリケーションは、多くの場合、自身ではデータベースをほとんど、あるいはまったく持たず、接続されたシステムのデータを利用します。複合アプリケーションは、データだけでなく、他のアプリケーションの機能 (アプリケーション・ロジック) にも頻繁にアクセスします。アクセスには、多くの場合、SOA を使用します。Ensemble には先進的な開発環境が用意されているため、機能性に富んだ複合アプリケーションを短期間で構築できます。
HealthShare EPR は複合アプリケーションの一例で、医療機関の様々な施設に、EPR では認識できない形式で格納されている診療情報を利用します。別の例としては、各医療機関で使用している様々なアプリケーションでオーダが実際にどのように処理されているのかを認識せずに、地域全体に診療オーダや電子処方を導入することも考えられます。この例では、それら様々なアプリケーションの機能にアクセスするオブジェクト指向の共通インタフェースを利用するだけで済みます。
各医療機関のアプリケーションどうしの接続が完了すれば、進化する機能に対応する上で、複合アプリケーションが強力なメカニズムとなることは容易にわかります。
接続性
このような試みを成功させるには、最小のコストと労力で既存の多くの診療アプリケーションに確実に接続する必要があります。HealthShare では、特殊な要件に対して、アダプタ、データ変換、先進的なプログラミング機能など、この目的に特に威力を発揮する Ensemble のテクノロジを使用することにより、この目的を達成します。
Ensemble のアダプタ
Ensemble のアダプタは、アプリケーションへの接続を実現し、オブジェクト・インタフェースを使用してアプリケーション固有のすべてのロジックをシステムの他のシステムから切り離す、再利用可能なソフトウェア・コンポーネントです。Ensemble は、多くのシステムのニーズを満たす、あらかじめ構築されたアダプタの大規模なライブラリを備えています。ソース・アプリケーションやターゲット・アプリケーションで標準アダプタを使用できない場合でも、カスタム・アダプタを短期間で作成できます。通常、これは、既存のアダプタを拡張 ("サブ分類") することで実現します。
ほとんどの場合、既存の診療アプリケーションへの接続には HL7 v2 の "亜種" が使用されます。HealthShare は、HL7 v2.x および v3 スキーマとその高機能な仮想ドキュメント・アーキテクチャのサポートを組み込んで用意しているため、現時点で最も高性能で高速な HL7 ベースの接続性を実現します。
ただし、すべてのアプリケーションが HL7 を使用して通信するわけではありません。そればかりか、標準的な通信方法が何もないアプリケーションもあります。保持するアダプタの数や接続可能なアプリケーションの数を重視しすぎたインテグレーションテクノロジでは、必要なたった 1 つのアプリケーションが特殊なために接続できないという事態が発生するリスクがあります。そのため、Ensemble のプログラミング機能が重要になります。このプログラミング機能により、まったく独自のアダプタの開発がサポートされます。
Ensemble のデータ変換
Ensemble のデータ変換エンジンは、必要なメッセージ・セットの変換や、その他のメッセージ正規化または修正の作業を行います。これらの作業には、メッセージのフィールドの削除や並べ替えと同程度の単純なものもあれば、アプリケーション固有のメッセージを標準形式に変換する際の複雑な処理もあります。Ensemble には、データ交換するアプリケーションからの HL7 v2 や v3 による応答を標準の CDA 形式に変換する、拡張変換クラスが組み込まれています。変換を新規に作成する場合でも、既存の変換を拡張する場合でも、変換作業をグラフィカルに指定できます。また、XML ベースの変換 "言語" を介して指定することもできます。通常から大きくかけ離れた状況では、Ensemble のプログラミング機能が必ず役に立ちます。
標準規格
相互運用においては、標準規格であることが重要です。データ交換のあらゆる側面で標準規格を採用することにより、新規および既存の医療システムだけではなく、他の地方レベルまたは全国レベルの医療情報ソリューションともインタフェースが可能になります。
HealthShare Gateway は Ensemble をベースにしたものです。Ensemble は、以下に示すように、医療データや相互運用の様々な標準規格をサポートしています。Ensemble は HL7 v2 および v3 をサポートしており、インターシステムズは HL7 標準化団体のメンバです。Ensemble はまた、ビルトインの XML パーサ、DTD および XML スキーマの双方向サポート、XPATH および XSLT を介したドキュメントのクエリと変換、SOAP を使用したメッセージの送信など、XML を強力にサポートしています。これらの機能が相まって、HealthShare は CDA など XML 文書ベースの標準規格の高度なサポートを実現しています。さらに、インターシステムズは、コンピュータ・システムによる医療情報共有の仕組みを強化するために、IHE (Integrating the Healthcare Enterprise/医療機関統合) の活動に積極的に参加しています。
他のテクノロジと接続するときには、可能なかぎり、メッセージング/データの標準規格を使用するように努めています。Gateway から Hub、Gateway から Gateway の全通信は、通常の場合、標準メッセージ・フォーマットを使用し、Web サービスで送信されます。Gateway から Hub への通信は、Connecting for Health Common Framework の Record Locator Service (RSL) 規格を使用しています。Gateway から Gateway の通信の場合、HL７ v３ メッセージにより臨床データが要求され、そのデータを返すために CDA 文書が使用されます。
| HealthShare がサポートする医療データ交換の標準規格 | |
|---|---|
| HL7 v2 | Health Level 7 version 2 (www.hl7.org) |
| HL7 v3 | Health Level 7 version 3 (www.hl7.org) |
| CDA | Clinical Document Architecture (www.ansi.org) |
| CCD | Clinical Care Record (CCR) encapsulated in CDA (www.astm.org) |
| DICOM | Digital Imaging and Communications in Medicine (medical.nema.org) |
| NCPDP | National Council for Prescription Drug Programs (www.ncpdp.org) |
| RLS | Record Locator Service (www.connectingforhealth.org) |
| Healthcare data exchange standards supported by HealthShare. | |
ただし、HealthShare が、HealthShare に含まれる他のコンポーネントと内部的に通信するときには、高性能な独自のプロトコルに自動的に切り替わるため、応答時間が短縮され、スケーラビリティが高くなります。
プライバシとセキュリティ
同意管理
HealthShare には、同意管理が組み込まれています。同意は、以下の 2 つの方法で実行されます。
- 患者の照合: Hub は、照合要求を受信すると、EMPI に掲載されることに同意した患者のみを返します。
- 臨床データ: Gateway は、特定の患者のデータ要求を受信すると、共有することに患者が同意した部分のみを返します。
患者ごとに明示的な同意を必要とするか、患者が同意しないことを明示的に指定している場合以外は同意と見なすようにシステムを設定することができます。
セキュリティ
プライバシとセキュリティを厳格に遵守するために、HealthShare では、暗号化、厳密な認証、ロールベースの権限、きめ細かいセキュリティ・ポリシー、改ざん防止機能を備えた監査ログをはじめとする一連の高度なテクノロジが採用されています。
HealthShare に組み込まれた Caché データベースが備える暗号化テクノロジにより、インデックスを含め、データベースに格納されているすべての内容が暗号化されます。Hub と Gateway の機密データはすべて保護されます。保護対象には、"実際の" 診療および個人情報と、監査記録や監査ログのような他の "システム" データの両方が含まれます。
データベースの暗号化は、米国の連邦情報処理規格 197 (Federal Information Processing Standard 197) によって規定された Advanced Encryption Standard (AES) アルゴリズムによって実装されます。AES は強力で高速な対称暗号アルゴリズムであり、256 ビットの暗号キーが使用されます。この暗号キーは HealthShare の外部 (メモリ・スティック、CD、ファイルなど) に保管され、システムの起動時にロードされます。暗号キーにアクセスするにはパスワードが必要です。実行時、暗号キーは保護された記憶場所に格納されます。
HealthShare Hub および Gateway の各種コンポーネント間の通信の安全性を確保するために、HealthShare では SSL (2.0 および 3.0) と TLS をサポートしています。Gateway 間および Gateway と Hub 間の接続要求は、要求側の Gateway が有効な証明書を提示し、その証明書に記述された識別情報をサーバが認識した場合にのみ受け入れられます。証明書が有効であるためには、認定された認証局によって発行された、有効期限内のものであることが必要です。
HealthShare は、厳密な認証ポリシーの実行時に必要とされる、基本的な認証テクノロジをサポートしています。HealthShare EPR のユーザは、ユーザ名とパスワードの入力を要求されます。これらの資格情報は HTTPS 接続を介して (暗号化された形式で) HealthShare Gateway に送信されます。Gateway は、Kerberos 鍵配布センター (KDC) に接続して、このユーザの識別情報を確認します。KDC は、パスワードの長さやパターン、変更頻度など、厳密なパスワード・ポリシーを適用するように設定できます。
HealthShare は、非常に柔軟でパワフルなロールベースのセキュリティ・メカニズムを備えています。ロールは様々なレベルのユーザ・アクセスに対して定義され、必要に応じてユーザに割り当てられます。監査証跡情報へのアクセスなど、その他のシステム・アクセスのタイプを制御するためにロールを追加定義できます。
HealthShare Hub および Gateway は、改ざん防止機能を備えたセキュアな監査ログを使用して要求をすべて記録する、柔軟なロギング機能を備えています。このデータは、システム使用状況の監視、悪用が疑われる場合の調査、および定期監査の実行時に利用できます。
IV. HealthShare システムの運用
パフォーマンスとスケーラビリティ
治療中に瞬時の応答が得られないようなシステムは、医師が利用しません。HealthShare では、地域または全国に配備されている状況で、多数のユーザに同時にサービスを提供していても、臨床データに迅速にアクセスできます。
スケーラビリティも同様に重要です。多くの場合、医療情報共有プログラムは数十万の患者を対象とするパイロット・システムとして開始されますが、患者数は時間の経過と共に 10 倍から 100 倍またはそれ以上の規模に増えていきます。HealthShare では、サーバへのプロセッサの追加と多層構成でのサーバの追加の両方を行なうことにより、コスト効率のよいインクリメンタルな拡張が可能です。Caché 独自の Enterprise Cache Protocol (ECP) を使用すると、すべてのユーザが同じコンピュータにアクセスするように、複数のコンピュータが同時に接続して共通データベースにアクセスすることが可能です。これにより、Caché では数万人の同時ユーザと数百万人の患者をサポートするスケーラビリティが実証されています。
信頼性と高可用性
HealthShare は、年中無休、1 日 24 時間稼働できるように設計されています。HealthShare は、このような高可用性を実現できるように、Caché および Ensemble の自動永続アーキテクチャを採用し、広範囲な高可用性サポート機能を備えています。以下にその例を示します。
- アプリケーションの実行中およびデータベースの変更中に並行して行われるフル・バックアップとインクリメンタル・バックアップ
- トランザクションの整合性を確保する、トランザクション・ロギングとロールフォワード・リカバリ
- データベースの整合性を保護する、イメージ・ジャーナル記録の作成
- 迅速なフェイルオーバのためのサーバのシャドーイング
- クラスタ化されたデータベース
- データ・サーバをバックアップするための、自動フェイルオーバ機能を備えたECP
さらに、HealthShare では、処理の各段階でメッセージの "状態" が組み込みのデータベースに自動的に保存されます。これにより、システム・クラッシュなどの障害が発生しても、短時間で確実に復旧できます。
監視と管理
数百の Gateway、数千の診療システムで絶え間ない変化が日々生じるなど、多くの "変動部分" が存在するなかで、運用スタッフが直面している最も困難な課題は、問題の迅速な発見、診断、および解決です。
HealthShare では、Ensemble を使用することにより、このような課題に対処する 2 つの強力な機能を用意しています。それは、リモート・システムの管理を目的とする、自動ロギングおよび高機能な監視と管理のためのコンソールです。Ensemble により、要求処理時の各アクションは、問題の正確な診断に必要な詳細レベルで自動的に記録されます。たとえば、Gateway が特定の患者の臨床データの呼び出し要求を受信し、この要求を満たすために 5 または 10 の病院システムに要求を送信するとします。それぞれの要求と応答はログに記録され、完全なトレーサビリティが確保されます。
メッセージ・トレース (図 4 参照) は、Ensemble の管理ポータルが提供する機能の 1 つに過ぎません。この管理ポータルはブラウザベースであるため、適切なセキュリティ権限を持つ管理者は、どこからでもネットワークの任意の場所にある問題を調査できます。
図 4. HealthShare は、Ensemble の Visual Trace 機能を利用し、メッセージとその内容を簡単に監視可能
V. まとめ
診療情報の共有に対し、HealthShare は、実証済みの診療情報テクノロジをシステムのベースとする一方、迅速に機能拡張を実現する能力をもち、多様なニーズに応えるというアプローチを採用しています。その実現のため、HealthShare には、TrakCare がもつ EPR および Edge Cache データベース構造と、先進的オブジェクト・データベースCachéおよびインテグレーションプラットフォームEnsemble が組み込まれています。このアプローチでは、インターシステムズのパートナ各社が提供する多くの医療アプリケーションとの接続、またはそうしたアプリケーションの組み込みが簡単です。
HealthShare は高度な標準規格に基づいており、強力なセキュリティ機能を備えています。また、患者記録を、システムが共有する医療情報の中核として位置付けるという前提で設計されています。この患者中心の視点により、当初はデータ共有が最小限なシステムであっても、使用状況と機能要求が高まるに連れて拡張可能な強固な基盤を持つことができます。
接続は第 1 段階に過ぎません。HealthShare を導入した地域は、複合アプリケーションを導入または構築して、地域全体の診療オーダや電子処方などの拡張機能を実現し、容易に修正できるビジネス・ルールやビジネス・プロセスを利用して、変化するニーズに対応するなど、進化させてゆくことが可能です。
世界中の多数の医療システムでメインの医療アプリケーションをサポートするソフトウェアを 30 年以上にわたって提供してきた実績を誇るインターシステムズが、パフォーマンスに優れ、スケーラビリティが極めて高いソフトウェアの分野で確立した事業実績は、医療セクタ全体で認知されています。医療情報共有プログラムのパイロット・システムでは、扱う患者数は限られていますが、数百万の患者や数千のユーザをサポートできるようにスケール・アップする機能は、本格的な展開に必ず必要です。
関連情報
詳細については、InterSystems HealthShare Web サイトを参照してください。
*1：「2006 KLAS インターフェースエンジンマーケットレビュー」（Top 20 Year End KLAS Report） KLAS confidential information. © 2006 KLAS Enterprises, LLC. All rights reserved. www.healthcomputing.com
*2：「2007年 第２四半期 コンポジットアプリケーションプロジェクトのためのアプリケーションインフラストラクチャに関するマジック・クアドラント」 Massimo Pezzini, Michael Barnes, Kimihiko Iijima, David Gootzit, Yefim V. Natis, Daryl C. Plumer, Jess Thompson, Dale Vecchio, Janelle B. Hill, Simon Hayward 共著2007年6月7日 (G00147640)
