コラム一覧に戻る
医療情報セキュリティ13分で読める

SLAと責任分界の書き方|稼働率だけでは足りない理由

2026年9月14日

SLAと責任分界の書き方|稼働率だけでは足りない理由
この記事をシェア

電子カルテの保守契約書に「稼働率99.9%を保証」と書かれているとき、それが何を保証しているかを考えたことがあるでしょうか。月間30日で計算すると、99.9%は月あたり約43分の停止を許容するという意味です。そしてこの43分は、深夜のバッチ時間帯に起きても、火曜の午前外来の最中に起きても、同じ1回としてカウントされます。

さらに重要なのは、多くのSLAでランサムウェア被害のような事象が稼働率の計算対象外になっていることです。「不可抗力」「第三者の行為に起因する事象」といった除外条項があれば、数週間システムが止まっても稼働率違反にはなりません。実際に医療機関が最も困るシナリオこそ、SLAが守ってくれない領域にあるという構造です。

SLA(Service Level Agreement)は、サービス水準を約束する文書であると同時に、約束していない範囲を確定させる文書でもあります。稼働率の数字を比べるのではなく、止まったときに何が起きるのか、誰が何をするのか、いつまでに復旧するのかを書き込むことが実務上の要点になります。

本記事は、医療情報システムのSLAと責任分界について、契約前に決めておくべき項目を整理したものです。責任共有の考え方そのものは AI電子カルテのセキュリティ設計と責任共有モデル で扱っていますので、あわせてご覧ください。

免責:本記事は一般的な情報提供です。契約条項の効力・解釈は個別の契約書と適用法令によります。実際の契約にあたっては顧問弁護士にご確認ください。ガイドラインの要求事項は厚生労働省・経済産業省・総務省の公表資料が正本です。

稼働率が守ってくれないもの

稼働率は「一定期間のうちサービスが利用可能だった時間の割合」です。これだけでは、医療機関が本当に困る場面をカバーできません。

稼働率が定めるもの稼働率が定めないもの
年間・月間で何%利用可能かいつ止まるか(診療時間かどうか)
計画停止を含むか除くか止まった直後に誰がどう動くか
違反時のペナルティ(多くは利用料の減額)何時間で復旧するか
データがどの時点まで戻るか
診療が止まったことによる損失をどう扱うか
サイバー攻撃による停止を含むか

この表の右側こそ、実際の事故で問題になる部分です。「稼働率99.9%」と「稼働率99.5%」を比べるより、右側の項目が書かれているかどうかを見るほうが、はるかに重要です。

もうひとつ、稼働率のペナルティが実効性を持たない構造にも触れておきます。稼働率違反のペナルティは、多くの契約で当月利用料の数%〜数十%の減額です。月額が数十万円の保守契約であれば、ペナルティは数万円。一方、電子カルテが1日止まったときの機会損失と現場の負荷は、その比ではありません。ペナルティは抑止力としては弱く、SLAの価値は金銭ではなく、対応手順を事前に確定させる点にあると考えたほうが実態に合います。

SLAに書くべき4つの時間

医療情報システムのSLAでは、次の4つの時間を明確にしてください。順に、事故が起きてからの時系列に対応します。

指標定義決めるときの観点
検知〜通知事業者が異常を検知してから医療機関に通知するまで通知の基準(何をもってインシデントとするか)とセットで決める
一次応答時間医療機関からの連絡に対して担当者が応答するまで平日日中/夜間/休日で分けて定める。医療は24時間365日
RTO(復旧目標時間)障害発生からサービス復旧までの目標時間「全面復旧」か「縮退運転でも可」かを定義する
RPO(復旧目標時点)どの時点のデータまで復旧できるかの目標バックアップ頻度と直結する。24時間なら1日分の記録を失う

RPOの意味を現場の言葉に翻訳する

RPOは技術的な指標に見えますが、**「何時間分のカルテを書き直すか」**という現場の問題です。RPOが24時間なら、最悪の場合、丸一日分の診療記録・オーダー・検査結果が失われます。その日の紙記録が残っていれば再入力できますが、電子カルテに直接入力していた分は復元できません。

RPOを短くするにはバックアップ頻度を上げる必要があり、コストに跳ね返ります。だからこそ、「この数字は、最悪の場合に一日分の記録を再入力するという意味です」と院内で共有したうえで決めるべき項目です。技術的な合意ではなく、診療部門を含めた合意にしてください。バックアップ方式との関係は 医療機関のバックアップ設計|3-2-1ルール で扱っています。

通知の基準を先に決める

「検知〜通知」の時間だけを決めても、何を通知対象とするかが決まっていなければ機能しません。次の3段階で整理するのが実務的です。

  1. 即時通知 — 不正アクセスの成功、データの外部流出の可能性、サービス停止
  2. 当日中に通知 — 不正アクセスの試行の検知、重大な脆弱性の公表と影響調査の開始
  3. 定期報告に含める — 軽微な事象、パッチ適用、設定変更

このうち2の扱いが事業者によって大きく異なります。攻撃の試行を検知するたびに連絡していては運用が回らない、という事業者の事情も理解できますが、御院のシステムを狙った試行が継続しているという情報は、院内の警戒レベルを上げる判断材料になります。どこで線を引くかを契約前に合意してください。

責任分界点をどう書くか

責任分界は「どこまでが事業者の責任か」を定める作業ですが、境界を一本の線で引こうとすると必ず破綻します。現実には、同じ対象について「誰が実施するか」と「誰が結果に責任を負うか」が別だからです。

そこで、RACI的に4象限で書くと整理しやすくなります。

対象実施結果責任典型的な合意
OS・ミドルウェアのパッチ適用事業者事業者適用時期と事前通知のルールを定める
アプリケーションの脆弱性修正事業者事業者重大度別の適用目標日数を定める
利用者アカウントの発行・削除医療機関医療機関退職者の権限削除は院内の手続
権限設計(ロール定義)共同医療機関事業者が選択肢を示し、医療機関が決める
バックアップの取得事業者共同取得は事業者、要件の定義と検証は医療機関
バックアップからの復旧試験共同医療機関年1回の実施を契約に書く
端末の管理(院内PC)医療機関医療機関事業者が納入した端末の扱いを明記
ネットワーク機器・VPN要確認要確認最も抜けやすい。院内NW業者と電子カルテ業者の間で落ちる
ログの取得事業者事業者取得対象と保管期間を仕様に書く
ログの点検医療機関医療機関点検の頻度と方法を院内で定める
職員教育医療機関医療機関事業者が教材提供する場合は範囲を明記

ネットワーク機器・VPNの行が、実務上いちばん危険です。 公表されている被害事例に共通する構造として、VPN機器の既知脆弱性が侵入口になったパターンが繰り返し指摘されています。ところが院内では、VPN機器はネットワーク工事業者の納入物であり、電子カルテ業者の契約範囲外、ネットワーク業者は「保守契約は回線までで機器のファームウェアは含まない」——という具合に、誰も見ていない状態が生まれがちです。契約を並べて、「この機器のファームウェア更新は誰の責任か」を一つずつ確認してください。VPN機器固有の論点は VPN機器の脆弱性対策 にまとめています。

「共同」を放置しない

上表で「共同」となっている行は、そのままでは責任の空白地帯になります。共同とする場合は、必ず手順に分解して、各手順の担当を決めてください

たとえば「バックアップの復旧試験」であれば、次のように分解します。

  • 試験計画の作成:事業者
  • 試験の実施日程調整:医療機関
  • 復旧作業の実施:事業者
  • 復旧されたデータの妥当性確認:医療機関(診療部門を含む)
  • 結果の記録と保管:医療機関

ここまで書くと、「実施はするが妥当性の確認は医療機関側でお願いします」という事業者の前提が明示され、院内で誰が確認するのかという議論に進めます。責任分界の詳細な考え方は 責任分界点の決め方|医療機関と事業者 を参照してください。

診療報酬の要件とSLAの接続

2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算は、SLAの設計にも影響します。加算の要件には、ガイドラインへの準拠と専任の医療情報システム安全管理責任者の配置(共通要件)に加え、加算1では複数方式によるバックアップ(一部はオフライン保管)サイバー攻撃等を想定したBCPの策定・訓練が含まれます。

加算の要件SLA・契約に書いておくべきこと
ガイドライン準拠事業者側が準拠すべきガイドラインの明記と、要求ごとの実施主体の対応表
安全管理責任者の配置院内の役割だが、事業者側の窓口責任者との対応関係を定める
複数方式のバックアップ方式・世代数・オフライン保管の有無を仕様に明記。取得の責任主体を明確にする
BCPの策定・訓練訓練に事業者が参加するか、参加する場合の費用負担と頻度

とくにBCP訓練への事業者の関与は、契約に書いていなければ都度の有償対応になります。年1回の訓練に事業者が参加することを保守契約に含めておくと、実効性のある訓練になり、加算の要件充足も説明しやすくなります。訓練の設計は サイバー攻撃を想定したBCP、改定全体の動向は 2026年度診療報酬改定 をご覧ください。

バックアップについては、疑義解釈で複数の方式が要件を満たすとされています。外部媒体方式(RDX等の別媒体で世代管理)、自動転送方式(NAS等へ自動転送し常時ネットワークから切り離す)、クラウド内方式(クラウドサービス内の論理的に切り離された領域へのバックアップで速やかな復旧が可能な場合)のいずれも該当します。日次バックアップの場合は少なくとも3世代の確保が示されています。どの方式を採るかは事業者の提供形態に依存するため、契約前に確認が必要です。

SLAが守られなかったとき

SLAには、違反時の扱いを書きます。実務的には次の3層で考えてください。

内容実効性
報告違反の原因分析と再発防止策を書面で提出させる高い。事業者側に負荷がかかり、繰り返しを抑止する
減額利用料・保守料の減額低い。金額が小さく、損害と釣り合わない
解除一定回数・一定期間の違反で契約解除できる中。ただし電子カルテは乗り換えコストが極めて高く、行使は現実的でないことが多い

最も実効性があるのは報告義務です。「RTOを超過した場合、超過の理由・経過・再発防止策を2週間以内に書面で提出し、当院との会議で説明すること」という条項は、減額条項より強く働きます。

解除条項については、電子カルテの場合、解除できてもデータを持ち出せなければ意味がありません。解除条項とセットで、契約終了時のデータ返還条項(返還形式・期限・移行協力の範囲・費用)を必ず入れてください。この点は 電子カルテ更新時のセキュリティ要件事業者に確認すべき質問リスト でも扱っています。

まとめ

医療情報システムのSLAと責任分界について、押さえるべき点は次のとおりです。

  1. 稼働率はいつ止まるか・何時間で戻るか・データがどこまで戻るかを定めない。数字の比較には意味が薄い
  2. 書くべきは4つの時間——検知〜通知、一次応答時間、RTO、RPO。夜間・休日を分けて定める
  3. **RPOは「何時間分のカルテを書き直すか」**という現場の問題。診療部門を含めて合意する
  4. 責任分界は「実施」と「結果責任」を分けて表にする。ネットワーク機器・VPNが最も抜けやすい
  5. 「共同」の行は手順に分解して担当を決める。分解しなければ空白地帯になる
  6. 違反時は報告義務が最も実効性がある。減額条項は損害と釣り合わない
  7. 解除条項はデータ返還条項とセットでなければ機能しない

SLAの見直しは、既存契約の棚卸から始まります。複数の事業者との契約を並べて、責任の空白がどこにあるかを確認する作業は、院内だけで進めるには重い作業です。次期更改に向けた要件整理を含めて、お問い合わせ からご相談ください。

参考・出典

※診療報酬の算定要件は告示・通知および疑義解釈が正本です。契約条項の効力は適用法令と個別契約によります。最新の公表資料と顧問弁護士の確認に基づいて判断してください。

この記事をシェア

関連記事

医療情報セキュリティ

アクセス権限設計と特権ID管理|医療機関で現実的にどこまでやるか

職種別の権限設計、最小権限の考え方、退職・異動時の棚卸し、ベンダー保守アカウントの管理、そして共有IDをやめられない現場での次善策。理想論ではなく、医療現場の制約のなかで被害の広がりを実際に抑えるための権限設計を整理します。

2026年9月14日
医療情報セキュリティ

ウイルス対策とEDR|医療機関が導入前に決めておくこと

従来型のウイルス対策とEDRは何が違うのか。EDRは「入れれば守られる」製品ではなく、検知したあとに誰かが判断し動くことで初めて機能します。運用体制の選び方、医療機器のように導入できない端末への代替策、そして導入前に確認しておくべき項目を整理しました。

2026年9月14日
医療情報セキュリティ

ログ管理と監査証跡|取っているが見ていない状態から抜け出す

何のログを取るか、どれだけ保管するか、そして最大の課題である「取っているが見ていない」問題。インシデント発生時に実際に必要になるログは何か、点検を運用に乗せるにはどうするかを、限られた人員の医療機関を前提に整理します。

2026年9月14日
医療情報セキュリティ

医療機関のバックアップ設計|3-2-1ルールと加算1の要件

2026年度改定で、複数方式によるバックアップと一部のオフライン保管が加算1の要件になりました。要件を満たすとされる3つの方式(外部媒体・NASへの自動転送・クラウド内の論理分離領域)、日次なら少なくとも3世代という世代管理、そして復旧試験をしていないバックアップは無いのと同じという論点を整理します。

2026年9月14日
AIカルテ

AIカルテを見る

受付から診療記録、会計、レセプト、経営分析までを一つの循環でつなぐAIネイティブ電子カルテ。

製品ページを見る

ISMS取得支援という選択肢

適用範囲の設計から文書整備、教育、内部監査、審査機関とのやり取りまで。ポテックがヘルスケア企業のISMS(ISO/IEC 27001)認証取得を一気通貫で支援します。