Jump to section

マイクロサービスで医療における IT 統合をサポート

URL をコピー

マイクロサービスを使用すると、医療やその他の業界の開発者は、疎結合のサービスから作られるアプリケーションを構築でき、開発、テスト、デプロイ、アップグレードを容易に行えます。これらのメリットにより、医療業界の開発者は前世代の IT 統合テクノロジーであるエンタープライズ・サービス・バス (ESB) よりも、マイクロサービスを採用するようになりました。

他の大規模エンタープライズと同様に、医療機関の IT 環境では、ミッションクリティカルなデータの共有を必要とする多様なシステムが広範囲に広がっています。少し例を挙げるだけでも、入退院・移動システム (ADT)、スケジューリングシステム、ラボシステム、放射線システム、請求システムなど、あらゆるシステム間で情報のやり取りが必要であり、そのデータは、救命救急の際には極めて重要です。

デジタル時代において、医療提供者は電子医療記録 (EHR) を導入していますが、それら多数のアプリケーション間でデータを共有できない限り、EHR の価値が最大限に発揮されることはありません。医療システム統合への挑戦は、数十年前の 1987 年に始まり、当時、医療で使用されるアプリケーション間で臨床データと管理データを伝達するための国際標準規格である Health Level Seven (HL7) が確立されました。この共通言語が確立された後、医療業界では、HL7 を介して情報交換できるようにアプリケーションを接続する方法が必要になりました。

IT 関係者は、各アプリケーション間で直接ポイントツーポイント接続を行うのは実用的ではなく、エンタープライズの規模が拡大するにつれてより困難になるということを、何年も前から知っていました。さらに、HL7 はユニバーサル形式を提供しましたが、そのフィールドを解釈する共通の方法がなかったため、医療システム間のやり取りをサポートするためには、接続だけでなく、データ変換も必要でした。

医療提供者が導入した最初の統合テクノロジーは、病院内のすべてのシステム間のハブとして機能するサーバーである、インタフェースエンジン (IE) でした。各システムは IE に接続し、IE はデータを変換し、必要に応じて他のシステムにルーティングしました。その後、約 20 年前に、エンタープライズ・サービス・バス (ESB) が登場しました。IE と同様に、ESB は、主に HL7 を使用して、医療アプリケーション間でデータを交換するためのハブとして機能します。ESB は、データ変換、プロトコル変換、ルーティング、そして Web サービス、JMS、HTTP、SOAP のサポートを提供するだけでなく、簡単な管理と監視も行います。ESB は 20 年間にわたり (医療業界およびその他の業界で)、最も多く利用されてきた統合のためのソリューションでした。

ESB の登場以来、アプリケーション開発は大幅に進化しました。最も重要な変化の 1 つは、アジャイル開発と DevOps への移行であり、これにより ESB は過去のテクノロジーとなりました。

DevOps パイプラインは、段階的な変更と継続的な自動テストに基づく開発ライフサイクルです。DevOps の時代において、かつて ESB が普及した要因であった特性はむしろ妨げになっています。ESB では、すべての統合が 1 つのモノリスにデプロイされます。これには以前は利点がありましたが、今では ESB が DevOps と両立できない要因であり、問題になっています。

先進的な開発環境において、ESB には次の制限があります。

  • アジャイル開発者および DevOps ツールとの非互換性:現在、新卒の開発者の多くは DevOps 環境で教育を受けています。そのようなアジャイル開発者は、市販されている最新の DevOps ソリューションで使い慣れたツールを使用すると最高の生産性を発揮しますが、ESB はこれらのツールをサポートできる設計ではありません。
  • 変更がシステム全体に影響:ESB のルールに変更を加える必要がある場合、たとえ小さな変更であっても、エンジン全体を一時停止する必要があります。つまり、ESB とやり取りするすべてのアプリケーションにおいて、破壊的かつ非生産的なダウンタイムが発生します。同様に、変更によって発生したエラーは、すべての統合に影響を与える可能性があります。その結果、チームはアップグレードや修正の適用を嫌がるなど、反生産的なメンタリティを持つようになってしまいます。
  • 単一障害点:すべての統合が同じハブを介してルーティングされるため、ESB はエンタープライズ全体の単一障害点になります。ESB がダウンすると、すべての統合がダウンします。
  • テストを自動化できない:テストの自動化は DevOps の重要な要素です。DevOps パイプラインでは、すべての更新が個別にテストされるため、開発プロセスが中断されることはありません。これは自動化によって可能になります。しかし、ESB では、プロプライエタリーの GUI とバージョン管理により、自動化が不可能です。

医療は、他の業界と同様に、マイクロサービス、DevOps、アジャイルといった新しい開発手法を採用しています。これは、医療の統合にも拡大しています。新しいアプリケーションとデジタルタッチポイントには、HL7、REST、その他のプロトコルへの統合が必要です。医療業界のマイクロサービス開発者は、彼らが開発する他のコード (データ、ストリーミング、GUI、コマンドアンドコントロールなど) とともに統合を制御し、CICD を通過するデプロイ可能なユニットにすべての変更をパッケージ化したいと考えています。上記の制限が、他のコードとの統合コードに関する CICD のこの目標の妨げになっています。

マイクロサービスは開発の未来であり、ESB とは全く両立できません。ESB はモノリシックですが、マイクロサービスはその逆で、開発者は疎結合サービスの構成要素を使用してアプリケーションと統合を構築できます。アプリケーションを独立したモジュールに分割することで、開発、テスト、変更、再テスト、修正、デプロイ、本番環境でのテスト、アップグレードなどが容易になります。

マイクロサービスではテストの自動化が可能なので、DevOps が可能になります。マイクロサービスは小さなコンポーネントなので、コンテナに簡単に収まり、テストプロセスを自動化して、継続的インテグレーションと継続的デリバリー (CI/CD) を促進できます。一方、モノリシックな ESB は大きすぎてコンテナに収まらず、コンポーネントに分割できないため、同じ方法でテストすることはできません。

しかし、マイクロサービスベースの統合を導入する最も重要な理由は、アジャイル開発者をサポートし、彼らが好む DevOps ツールを使用できるようにすることかもしれません。諸要素から ESB を取り除くことにより、開発者は、彼らが精通しているだけでなく、使用したいと考えるアジャイル開発環境で作業できるようになります。ESB がなければ、開発者はプロプライエタリー・システムに関するトレーニングを受ける必要がなく、より生産的な開発アプローチの方に専念できます。

さらに、ESB による統合はスペシャリストのチームにしか行えませんが、マイクロサービスであれば開発者が自分たちの統合のニーズを詳しく検討できるようになるため、統合が民主化されます。アプリケーション開発者以上にアプリケーションのデータ要件を理解している人はいないので、これはより理にかなっています。

マイクロサービスは API 管理もサポートしているため、必要に応じて API ベースの統合が可能です。

一方、マイクロサービスベースの統合には、グラフィカルな変換や、エンタープライズ内でのデータの流れに関する高度なルールを作成するロジックなど、ESB から得られるのと同じ利点があります。たとえば、ESB のグラフィカルな開発キャンバスが気に入っている場合は、マイクロサービスベースの統合をサポートする同様のキャンバスを見つけることができます。

マイクロサービスベースの統合は、最終的に次のようなメリットをもたらします。

  • 包括的な監視と管理:マイクロサービスは、アジャイル開発者が好む最先端のツール (たとえば、Kibana、Elasticsearch、Grafana、Prometheus など) で監視を行い、障害点を特定できるため、ビジネスへの影響が生じる前に問題を解決できます。
  • テストの自動化:マイクロサービスと DevOps の最大の利点の 1 つは、テストを自動化できることです。各統合は、テストプロセスを通過する際に独立したコンポーネントとして扱われ、アプリケーションの他のコンポーネントや他のアプリケーションを中断することはありません。
  • 優れたソフトウェア品質:プロセスの効率化とテスト結果の改善により、最終的に、ソフトウェアの品質が向上します。
  • 開発の加速:DevOps と自動化で統合開発プロセスを効率化し、以前は手動で行っていたプロセスを排除することで、開発ライフサイクルを加速できます。
  • スケーラビリティの向上:アプリケーションは独立したモジュールで構成されているため、アプリケーションの他の部分に影響を与えることなく、各サービスを個別にスケールアップできます。
  • 高度なイノベーション:マイクロサービスと DevOps を組み合わせることで、開発者は統合ソリューションを革新できるようになり、組織は新しいサービスを導入して、顧客により良いサービスを提供できるようになります。
  • ビジネスアジリティ:アジャイル開発は当然、ビジネスアジリティ、つまり市場の変化に迅速に対応する能力につながります。たとえば、アジャイル開発チームがマイクロサービスを活用してビジネス上の関係をサポートするために必要な統合を迅速に構築するので、データ共有を必要とする新しいパートナーやベンダーの迅速なオンボーディングが可能になります。
  • カスタマーエクスペリエンスの向上:医療組織の基本的な目標は顧客、つまり、毎日医療サービスを利用している患者にサービスを提供することです。プロセスを改善し、システムと部門間でデータをシームレスに共有することにより、最終的に満足度の高いペイシェント・エクスペリエンス (患者の医療体験) を提供できます。

統合をマイクロサービスに移行するのは、気が遠くなるほど膨大な作業だと思うかもしれません。なぜそのような変更が必要なのでしょうか。結局のところ、チームはすでに、組織が長年利用してきた ESB のプロプライエタリーな要素に精通しています。しかし、そこに問題があります。ESB の担当者のうちの 1 人、あるいは 2 人が組織を離れたら、どうなるでしょうか。そのレベルのスキルを回復するには何が必要でしょうか。

このモノリシックな ESB から移行するのは非常に面倒なことのように思えますが、まさにそれこそが移行すべき理由です。ESB による制限から解放されると、まったく新しい統合の世界が持つメリットを享受できます。

イベントメッシュのユースケース

イベント駆動型アーキテクチャとイベントメッシュを組み合わせると、さまざまなアプリケーションスタックを使用して、複雑で広く分散されたマルチクラウドのトポロジー全体にデプロイされる広範なユースケースをサポートできます。以下は、イベントメッシュを活用できる可能性がある多くのユースケースのほんの一例です。

マイクロサービスの統合

イベントメッシュは、マイクロサービスベースのアプリケーションを相互に、そしてレガシー・テクノロジーと簡単に接続します。

e コマース

イベントメッシュにより、トランザクションの迅速な処理が可能になり、Web サイトやアプリケーションを介して、顧客と高速で信頼性の高いやり取りが行えるようになります。

カスタマーサポート

イベントメッシュは顧客とのやり取りのデータを高速で提供できるため、サポートチームは顧客にリアルタイムで応答し、パーソナライズされたエクスペリエンスを生み出すことができます。

金融サービス

イベントメッシュを使用すると、金融サービスプロバイダーは、リアルタイムの取引データを少ない待ち時間で同期できるようになります。さらに、イベントメッシュは、疑わしいトランザクションに関する情報をリアルタイムで伝達し、不正の検出をサポートします。

IoT 接続

イベントメッシュは、信頼性が高くスケーラブルな IoT (モノのインターネット) 接続をバックエンドシステムにもたらし、ほぼすべてのセンサーのメトリクスを処理します。

イベントメッシュは、最終的に、ビジネスに次のようなメリットをもたらします。

リアルタイムの応答性

ビジネスの成功は、変化への対応力に基づいています。イベントメッシュの主な利点の 1 つは、データを (イベント駆動型アーキテクチャを介したイベントのストリームとして) リアルタイムで提供し、タイムリーな応答を可能にすることです。イベントメッシュは非常に効率的で、イベントプロデューサーとコンシューマーを結ぶ最速のパスを決定し、メッセージングのレイテンシーを実質的に排除します。これにより、ビジネスのステークホルダーは、時間的制約のある意思決定を必要とする重要な問題に迅速に対応するためのアジリティを得ることができます。

カスタマーエクスペリエンスの向上

イベントメッシュは、顧客対応チームと e コマース・テクノロジーが使用するデータのリアルタイム提供を可能にし、顧客へのサービス提供を支援するため、カスタマーエクスペリエンスが向上します。

運用コストの削減

イベントメッシュは、製造、販売、在庫、出荷をリアルタイムで可視化することにより、運用の最適化、効率の向上、コストの削減を可能にします。

開発者の生産性

さまざまな種類の環境、メッセージングシステム、プロトコルに依存しないイベントメッシュのサポートを受け、アプリケーション開発者は、利用可能な最善の技術を使用してビジネスロジックの実装に専念できます。これにより、開発者は、複雑なデータ配信ネットワークを開発することなく、開発環境、メッセージング・プラットフォーム、またはクラウドの種類に制限を加えずに、イノベーションを起こすことができます。

関連資料

記事

マイクロサービスで医療における IT 統合をサポート

マイクロサービスを使用すると、医療やその他の業界の開発者は、疎結合のサービスから作られるアプリケーションを構築でき、開発、テスト、デプロイ、アップグレードを容易に行えます。

記事

マイクロサービスとは

マイクロサービスとは、独立して機能する個々のサービスを組み合わせてアプリケーションを構築するアーキテクチャ・スタイルです。

記事

サービスメッシュとは

サービスメッシュはアプリケーションに組み込まれたインフラストラクチャ・レイヤーであり、サービスの相互作用を文書化して、通信の最適化とダウンタイムの回避を容易にします。

マイクロサービスの詳細はこちら

製品

Red Hat OpenShift

エンタープライズ対応の Kubernetes コンテナ・プラットフォームで、ハイブリッドクラウド、マルチクラウド、エッジのデプロイメントを管理するフルスタックの自動運用機能を備えています。

リソース

アナリスト資料

アジャイル・インテグレーション:エンタープライズ・アーキテクチャのブループリント

トレーニング

無料のトレーニングコース

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

その他の関連コンテンツ

無料のニュースレター「Red Hat Shares」(英語) では、注目の IT トピックスに関するコンテンツをお届けしています。