シリーズ最終編では、中小病院向け電子カルテ標準仕様書の「非機能要件」と、標準仕様を活かした導入の進め方を解説します。機能だけでなく、止まらない・守られる・移せるといった品質面の基準が、実は選定の成否を大きく左右します。
非機能要件は平常時には見えにくく、後回しにされがちです。しかし、障害や災害、セキュリティ事故が起きたときにこそ効いてくる領域であり、診療の継続性そのものを支えます。
第1編で全体像を、第2編で機能要件を確認してきました。本編ではもう一方の柱である非機能要件を、可用性・性能・運用・移行・セキュリティという観点ごとに、実務で確認すべきポイントに落とし込んで解説します。
非機能要件とは（IPA非機能要求グレード）
標準仕様の非機能要件は、独立行政法人情報処理推進機構（IPA）の「非機能要求グレード」を基に整理されています。可用性・性能・運用保守・移行・セキュリティなど、システムの品質を体系的に扱う枠組みです。
医療機関が電子カルテを選定する際に参考となる項目を選び、医療機関の要請があった際にベンダーが開示する「要開示項目」として一覧化されています。病院はこの一覧を使って、各社に同じ観点での開示を求められます。
遵守事項と要開示項目の違い
非機能の基準は、大きく「遵守事項」と「要開示項目」に分けて理解すると整理しやすくなります。前者は満たすべき条件、後者は水準を開示して比較・判断するための項目です。
- 遵守事項：安全管理などで満たすことが求められる条件
- 要開示項目：可用性・性能などの水準を、病院の求めに応じて開示する項目
- 実務では、開示された水準が自院の要求に見合うかを判断することが要点
可用性（1）稼働時間と計画停止
可用性は、診療を止めないための最重要領域です。まず確認すべきは、システムの稼働時間と、計画停止（メンテナンス）の有無・時間帯・頻度です。夜間や休日の診療体制と噛み合うかを見ます。
24時間救急を担う病院と、日中中心の外来病院では、求める稼働時間が異なります。自院の診療実態に照らして、計画停止が許容できる時間帯かを具体的に確認しましょう。
「99.9%稼働」といった数値だけで判断せず、その内訳、すなわち計画停止を含むのか、停止時にどのような代替手段があるのかまで確認することが、実務では欠かせません。
- 稼働時間（何時から何時まで、24時間か）
- 計画停止の有無・実施時間帯・頻度・事前通知の方法
可用性（2）RTOとRLO
障害が起きたときに重要なのが、RTO（目標復旧時間）とRLO（目標復旧レベル）です。RTOは「どれだけの時間で復旧を目指すか」、RLOは「どの水準まで復旧させるか」を示します。
たとえば「4時間以内に、直近の診療記録まで復旧」といった具合に、時間と範囲の両面で目標が示されます。この数値が自院の診療継続の許容範囲に収まるかを、契約前に必ず確認します。
- RTO（目標復旧時間）：復旧までに要する時間の目標
- RLO（目標復旧レベル）：どの範囲・水準まで復旧させるかの目標
可用性（3）大規模災害・DR・データ冗長化
さらに、大規模災害時のシステム再開目標や、ディザスタリカバリ（DR）方針、データの冗長化・バックアップ範囲も要開示項目に挙げられています。地震や水害の多い日本では、これらが現実的な備えとして重要です。
クラウド・ネイティブ化の利点の一つは、データを地理的に分散して保持し、被災時の復旧性を高めやすい点にあります。自院のBCP（事業継続計画）と、ベンダーのDR方針が整合するかを確認しましょう。
- 大規模災害時のシステム再開目標・データ復旧範囲
- ディザスタリカバリ（DR）方針・遠隔地バックアップ
- データの冗長化・バックアップの頻度と保持期間
紙運用（BCP）との組み合わせ
どれだけ可用性の高いシステムでも、障害や災害でシステムが使えない時間帯はゼロにはできません。だからこそ、システムが止まったときに診療をどう継続するか、紙運用を含めた業務継続計画（BCP）をあらかじめ用意しておくことが重要です。
RTOやDR方針を確認する目的は、単に数値を集めることではありません。「復旧までの時間を、紙運用でどう乗り切るか」という現場の段取りと組み合わせて初めて、実効性のある備えになります。
- システム停止時に使う紙帳票・手順を事前に整備しておく
- 復旧後にデータを戻す手順・担当を決めておく
性能・拡張性
性能・拡張性では、取扱い可能なユーザ数・同時アクセス数・オンラインレスポンス（画面応答時間）などが開示項目として整理されています。ピーク時にもたつかないかが、現場の満足度を左右します。
外来のピーク時間帯に多数の端末から同時アクセスしても、画面が実用的な速さで応答するか。自院の規模（医師・看護師・事務の端末数）を前提に、想定される同時利用に耐えるかを確認します。
また、将来の増床や診療科の拡大、健診受託の増加などで利用が増えても対応できるかという拡張性の視点も欠かせません。導入時点の規模だけでなく、数年先の見通しも含めて開示を求めましょう。
- 取扱い可能なユーザ数・同時アクセス数
- オンラインレスポンス（主要画面の応答時間の目安）
運用・保守性
運用・保守性では、障害検知時のベンダー対応可能時間や、現地への駆けつけ体制などが開示項目になります。トラブル時に「いつ・どのように」対応してもらえるかは、情報システム体制の弱い中小病院ほど重要です。
- 障害検知時のベンダー対応可能時間（受付時間・対応時間帯）
- 現地駆けつけの可否・所要時間・遠隔サポート体制
- 定期的なアップデート・パッチ適用の方法と頻度
移行性
移行性では、移行作業の分担（病院側とベンダー側の役割）や、リハーサルの範囲・回数などが開示項目として整理されています。乗り換えを伴う中小病院では、移行性の確認が特に重要です。
データ移行は導入プロジェクトの最大の山場です。第2編で触れた共通データ移行レイアウトと合わせ、「どのデータを、誰が、どうテストして移すか」を早い段階で握っておくと、移行トラブルを大きく減らせます。
移行の失敗は稼働直後の混乱に直結します。過去データの範囲、移行できない項目の扱い、リハーサルで発見した不整合の修正方法まで、開示された内容をもとに具体的に詰めておくことが、安全な切り替えの鍵になります。
- 移行作業の分担（病院側・ベンダー側の役割分担）
- 移行リハーサルの範囲・回数・本番移行の手順
セキュリティと関連ガイドライン
非機能要件は、医療情報を扱うための各種ガイドラインと結び付いています。標準仕様は、医療情報システムの安全管理に関するガイドライン、医療情報を取り扱う事業者向けの安全管理ガイドライン（経済産業省）などとの関係を整理しています。
さらに、デジタル庁のGCASガイドや、政府情報システムにおける脆弱性診断導入ガイドラインなどとの関係も示されています。クラウド利用が前提となるなかで、これらの遵守は信頼性の土台になります。
医療情報は特に機微性が高く、万一の漏えいは患者と病院の双方に重大な影響を及ぼします。標準仕様がこれらガイドラインとの関係を整理しているのは、病院が個別に一から調べなくても、確認の勘所をつかめるようにするためです。
- 医療情報システムの安全管理に関するガイドライン（厚労省）
- 医療情報を取り扱う事業者向け安全管理ガイドライン（経産省）
- デジタル庁GCASガイド・脆弱性診断導入ガイドライン
脆弱性診断という観点
別紙には脆弱性診断に関する考え方も含まれます。これは、システムにセキュリティ上の弱点がないかを定期的に点検する取り組みで、外部からの攻撃リスクを下げるために重要です。
中小病院が自前で高度な診断を行うのは難しいため、ベンダーがどのような頻度・範囲で脆弱性診断を実施し、結果にどう対応するかを確認しておくと安心です。
クラウド・ネイティブな製品では、こうした診断や更新をベンダー側でまとめて担いやすいという利点があります。院内に高度なセキュリティ人材を抱えにくい中小病院ほど、この体制の差は大きな意味を持ちます。
要開示項目のヒアリング・チェックリスト
非機能要件は、口頭では曖昧になりがちです。要開示項目を使って、ベンダーに具体的な水準を書面で開示してもらうと、比較が明確になります。最低限おさえたい確認事項を挙げます。
- 稼働時間・計画停止・RTO/RLOは、具体的な数値で示されているか
- 大規模災害時のDR・データ冗長化の方針は、自院のBCPと整合するか
- 同時アクセス数・レスポンスは、自院のピーク時規模に耐えるか
- 障害時のベンダー対応時間・駆けつけ体制は、自院の運用時間に合うか
- 移行の役割分担・リハーサル回数は、無理のない計画になっているか
- 各種安全管理ガイドラインへの適合と、脆弱性診断の実施状況
標準仕様を使った導入の進め方（RFP）
標準仕様は、病院とベンダーが同じ基準で対話するための共通言語です。導入・更新にあたっては、これをRFP（提案依頼書）や要件定義の骨格として活用すると、比較の精度と交渉の透明性が高まります。
具体的には、機能一覧で自院に必要な機能の実装有無を確認し、非機能の要開示項目で可用性・セキュリティ・移行の内容を提示してもらいます。これにより、営業トークに左右されない客観的な評価が可能になります。
- 機能一覧を自院向けに絞り込み、必須機能の実装有無を各社に回答させる
- 要開示項目を提示し、可用性・性能・運用・移行・セキュリティを書面で開示させる
- 回答を横並び表にして、経営層・現場・情報システムで合議する
契約後・運用開始後の見直し
非機能要件は、契約時に確認して終わりではありません。診療科の追加や患者数の増加、制度改正などで、求められる水準は時間とともに変わります。定期的に、実際の稼働実績と当初の目標値を突き合わせることが大切です。
たとえば、障害が起きた際に実際のRTOがどうだったか、レスポンスは想定内だったかを記録し、ベンダーと定期的に振り返る仕組みを作っておくと、品質を継続的に維持・改善できます。
- 稼働実績・障害対応の記録を残し、目標値と定期的に比較する
- 診療科・患者数の変化に応じて、性能や可用性の要求を見直す
想定Q&A
- Q. 非機能は後回しでよい？ A. いいえ。障害・災害時に効く領域で、診療継続性を左右します。早期に確認を。
- Q. RTOは短いほど良い？ A. 短いほど安心ですが費用も上がります。自院の許容範囲との釣り合いが要点です。
- Q. クラウドはセキュリティが不安？ A. 安全管理ガイドライン遵守と脆弱性診断の実施状況を確認すれば判断できます。
まとめ
非機能要件は、電子カルテを「安心して使い続けられるか」を左右する基準です。標準仕様の要開示項目を活用すれば、中小病院でも可用性・性能・運用・移行・セキュリティを客観的に確認できます。
Sakigake は、クラウド・ネイティブかつ標準仕様の思想に沿った電子カルテを目指しています。全3編を通じて、機能と非機能の両面から標準仕様を読み解いてきました。制度・要件は改訂され得るため、最新は必ず厚生労働省・デジタル庁の一次情報でご確認ください。