医療機関の IT で SLA 基準を満たすために

医療機関の IT 部門は、新しいアプリケーションやインフラストラクチャ・プロジェクトに取り組む際、サービスレベル・アグリーメント (SLA) を作成することがよくあります。その場合、SLA の各項目に関連するマトリクスを定期的に収集して確認することが重要です。

医療分野においては、生死を分けるような重要なアプリケーションも、特に厳重な監視をする必要のないアプリケーションも存在します。全部門に必要なサービスを提供するためには、リスクに応じて確認するマトリクスに優先順位をつけることが重要です。

アプリケーションとインフラストラクチャをクラス分け

医学博士の John Halamka 氏は、ベス・イスラエル・ディーコネス・メディカル・センター (BDIMC) の最高情報責任者です。Halamka 氏は、公開している Geekdoctor ブログで、病院のアプリケーションの可用性分類に従ってメトリクスをクラス分けしています。

• AAAA. 重要な医療機器を作動させるか、または患者の安全に不可欠なアプリケーションは、恒常的な可用性が求められます。アグリーメント内容は、予定外のダウンタイムが1年間に1時間以内、スケジュールされたダウンタイムが1カ月に4時間以内、内部障害時の目標復旧時間 (RTO) は1時間、外部災害では24時間です。
• AAA. 医療環境内で円滑に機能し続けることが前提の大規模システムは、継続的な可用性を必要とします。予定外のダウンタイムが年間10時間以内、計画されたダウンタイムが1カ月に８時間以内、内部障害時の RTO は８時間、外部災害では48時間です。
• AA. 生命にかかわるほどではないにしても機能的に重要なアプリケーションには、一般的な可用性が指定されます。予定外のダウンタイムが年間100時間以内、計画されたダウンタイムが１カ月に12時間未満、RTO は社内問題で最大24時間、外部災害で3日以内となります。
• A. あまり使用されないアプリケーションは、限定的な可用性が確保できればいいでしょう。優先度は低く、予定外のダウンタイムは年間150時間以内、断続的にスケジュールされたダウンタイムは容認可能です。RTO は、内部問題で翌営業日、外部災害の場合は数週間程度の機能停止は認められます。

さらに Halamka 氏は、アプリケーションクラスごとにリカバリポイント目標 (RPO) も SLA に加えます。AAAA と AAA に分類されたアプリケーションの場合、データ損失は認められません。AA アプリケーションは15分でリカバリ可能なことを目標にし、A アプリケーションには RPO に関する言及は行いません。

SaaS ソリューションのメトリクス

医療機関の多くは SaaS アプリケーションを利用しており、サードパーティーの SLA は IT 部門が組織内の部門とで結ぶ SLA と同様に重要です。メトリクスには、アプリケーションの分類に応じたアップタイムの保証、機能パフォーマンスに関連する項目、エスカレーションされたアプリケーション問題にサードパーティーがどう対処するか、SLA を満たせなかった場合の保守クレジットなどの救済措置、が含まれるべきです。

予測的監視の活用

多くの場合 SLA に必ずしも含まれていないアプリケーション・パフォーマンスの指標は、SLA コンポーネントに違反しないためのしくみとして機能します。Quocirca のサービス部長、Clive Longbottom 氏は、TechTarget の記事で、ユーザーからの要請に対するサービス応答時間の例を示しています。応答時間が特定のしきい値を下回ると可用性の問題が考えられるので、事前に検査・診断し、問題解決する必要があります。

IT 部門で、SLA 未達とならないためにチェックすべき、アプリケーションやシステム・パフォーマンスの兆候的な指標となるものを特定します。インフラストラクチャの指標としてはメモリ使用率や CPU 使用率、アプリケーションの指標としてはデータベース・クエリ応答時間などが含まれます。帯域幅使用率やエラーなどのネットワーク指標や、平均キュー長などのミドルウェアの指標を監視することもできます。

重要なアプリケーションの兆候的指標には、可能なら自動応答と警告を設定します。警告慣れして重要な警告を見逃すことがないよう、警告を出すためのトリガーをどう設定するかには十分な検討が必要です。

SLA のレビュー

年次レビューは問題のない SLA ではうまくいきますが、達成できていないことが分かっている場合は、年次レビューを待たずに上層部に状況と事情を説明した方がいいでしょう。また、AA や A レベルのアプリケーションに関しては、レビューすべきかどうかも確認しておいた方がいいでしょう。

SLA を満たせないのは IT が非現実的なレベルを設定したことに起因する場合が多く、設定レベルを見直す柔軟性も必要です。アグリーメントの見直しが困難な AAAA や AAA アプリケーションの場合は、適切なレベルのサービスを提供するために適切な修正またはインフラ投資を行います。たとえば、電子健康記録 (EHR) や画像アーカイブ/通信システム (PACS) のファイル転送に関する規定を満たすごとができず、患者の安全をリスクにさらす可能性があれば、マネージド・ファイル・トランスファー・ソリューションの導入が考えられます。SLA 未達のペナルティーを受けずにすむだけでなく、患者の命を救うことにつながるかもしれません。