電子カルテの更新やリプレイスは、数年に一度しか経験しないため、費用の全体像がつかみにくく、見積もりを見ても妥当性を判断しづらいという声をよく聞きます。特にデータ移行は範囲や工数が読みにくく、当初想定を超える費用が後から発生しがちです。
本稿では更新が必要になる理由から、費用の内訳、データ移行の範囲と進め方、オンプレとクラウドのコスト構造の違い、費用を抑える考え方までを実務目線で整理します。制度や価格は変わりやすいため、最終的な判断は必ず一次情報と複数社の見積もりで確認してください。
なぜ電子カルテの更新・リプレイスが必要になるのか
電子カルテは導入して終わりではなく、サーバやクライアント端末といったハードウェアの耐用年数、OSやミドルウェアのサポート終了、ベンダーの保守期限などが重なり、一定年数で更新の判断を迫られます。多くの現場ではおおむね5年から7年前後が一つの目安とされます。
サポートが切れたOSや機器を使い続けると、セキュリティ上の脆弱性が放置され、障害時に部品や技術者を確保できないリスクが高まります。診療を止められない病院にとって、この可用性の低下は経営リスクそのものであり、計画的な更新が欠かせません。
- ハードウェアの経年劣化と保守部品の供給終了
- OS・データベース・ミドルウェアのサポート終了
- 制度改定や新機能への追随が現行バージョンで難しくなる
- ベンダーの製品終息（EOL）や保守契約の満了
更新を検討し始めるサイン
更新の判断は耐用年数だけで決まるわけではありません。動作が重くなった、障害の頻度が増えた、現場の運用が制度に追いつかず手作業の回避策が増えた、といった日々の兆候も重要な材料です。これらは費用対効果を語るうえでの説得力ある根拠になります。
- レスポンス低下や月末のバッチ処理遅延が慢性化している
- ベンダーの改修対応が遅く、制度改定に間に合わない場面が出てきた
- 他システムとの連携要望に現行環境が応えられない
費用の全体像を分解する
更新費用は一つの数字ではなく、複数の要素の合計です。大きくは初期費用（イニシャル）とランニング費用に分かれ、初期費用の中にハードウェア、ソフトウェア・ライセンス、データ移行、導入作業や教育が含まれます。見積もりを比べる際は同じ粒度に揃えることが大切です。
見積書の項目名はベンダーごとに異なるため、同じ言葉でも範囲が違うことが珍しくありません。特にデータ移行や教育は含む範囲が曖昧になりやすく、後から追加費用として現れやすい領域です。何が含まれ何が含まれないかを一項目ずつ確認してください。
- ハードウェア：サーバ、クライアント端末、ネットワーク機器
- ソフトウェア：電子カルテ本体、周辺システム、各種ライセンス
- データ移行：抽出・変換・投入・検証にかかる作業
- 導入作業・教育：設定、テスト、操作研修、立ち上げ支援
- 保守・運用：更新後に継続的に発生するランニング費用
ハードウェアとソフトウェアの費用
ハードウェア費用は、オンプレミス型では自院にサーバ群を構える前提となり、冗長構成やバックアップ機器まで含めると相応の規模になります。一方クラウド型ではサーバ調達が不要になる代わりに、月額の利用料や通信環境の整備費用に置き換わる構造です。
ソフトウェア費用には電子カルテ本体に加え、部門システムや連携オプション、利用者数に応じたライセンスが含まれます。パッケージの基本価格だけでなく、自院に必要なオプションを積み上げた総額で比較しないと、実態とかけ離れた判断になりかねません。
見落とされやすいのが保守・運用というランニング費用です。ソフトの保守料、ハードの保守契約、監視やサポートの費用は毎年発生し、数年積み上がれば初期費用に匹敵する規模になることもあります。初期の安さだけで選ぶと、後年の負担が想定を超えかねません。
データ移行費用の考え方
データ移行費用は、移すデータの種類・量・品質、そして旧システムからの取り出しやすさで大きく変わります。構造化された項目はプログラムで変換しやすい一方、自由記載のテキストやスキャン画像、独自形式のデータは手作業や個別開発が必要になり、工数が膨らみやすい領域です。
旧ベンダーがデータの取り出しに協力的かどうかも費用を左右します。標準的な形式で書き出せない場合、抽出作業そのものに追加費用が発生することがあります。契約段階で自院のデータを取り出せる権利と手段を確認しておくことが、将来の移行コストを抑える鍵になります。
- 移行しやすい：患者基本情報、病名、処方・オーダーなど構造化データ
- 工数が増えやすい：自由記載の経過記録、スキャン文書、画像
- 要判断：どこまで過去分を移すか、参照用に旧環境を残すか
データ移行の範囲と工数
移行では「すべてを新システムへ完全移行する」以外にも選択肢があります。直近数年分だけを移行し、それ以前は旧環境を参照専用で残す、あるいは画像や文書は外部保存に切り出す、といった方法です。範囲を絞るほど費用と検証の負担は下がりますが、現場の利便性とのバランスが必要です。
工数を左右する要因は、データ量だけでなく項目のマッピングの複雑さです。旧システムと新システムで項目の持ち方が違えば、対応関係を一つずつ定義し、変換ルールを決める作業が発生します。ここを曖昧にすると、移行後にデータの欠落や取り違えが見つかり、手戻りが大きくなります。
- 移行対象を全件か直近分かで切り分ける
- 項目マッピングと変換ルールを事前に文書化する
- 画像・文書など重い資産は外部保存や参照方式も検討する
移行の進め方とリハーサルの重要性
データ移行は本番一発勝負にせず、必ずリハーサル（テスト移行）を挟むのが定石です。実データの一部または全部を使って変換と投入を試し、件数や内容が正しく移ったかを現場の担当者が検証します。ここで見つかった不整合を修正し、手順書を確定させてから本番に臨みます。
本番移行は診療への影響が少ない時期を選び、切り替え当日の役割分担と、問題が起きた場合に旧環境へ戻す判断基準（切り戻し）まで決めておきます。移行直後は入力に不慣れで問い合わせが増えるため、立ち上げ数日間の支援体制を厚くしておくと混乱を抑えられます。
移行後しばらくは旧環境をすぐに止めず、参照できる状態で並走させる期間を設けると安心です。移行漏れや変換ミスが後から見つかっても、原本にあたって確認や補正ができます。停止の判断は、現場が新環境に十分慣れ、検証が完了してから行うのが安全です。
- テスト移行で件数・内容を突合し、検証記録を残す
- 切り替え日の役割分担と切り戻し基準を明文化する
- 立ち上げ直後の問い合わせ対応体制を厚くする
オンプレミスとクラウドのコスト構造（TCO）
費用は初期費用だけでなく、数年間の総保有コスト（TCO）で比べる視点が欠かせません。オンプレミス型は初期のハードウェア投資が大きく、更新のたびにまとまった支出が発生します。クラウド型は初期投資を抑えやすい一方、月額利用料が継続的に積み上がる構造です。
どちらが安いかは利用年数や規模、更新の頻度によって逆転し得ます。オンプレは自院で機器を持つぶん運用や電源・空調、保守要員の負担が乗り、クラウドはそれらをサービス料に含めて平準化します。自院の条件で複数年のキャッシュフローを並べて比較するのが実務的です。
- オンプレ：初期投資が大きく、更新時に再投資が集中する
- クラウド：初期を抑えやすいが月額が継続する
- 運用・電源・保守要員などの見えにくい費用も総額に含める
費用を抑える考え方
費用を抑える出発点は、自院に本当に必要な機能と移行範囲を見極めることです。使わない機能や過剰な移行範囲は費用を押し上げます。要件を優先度で整理し、必須と要望を分けたうえで複数社に同じ条件で見積もりを依頼すると、比較の土台が揃い交渉もしやすくなります。
補助金や税制上の支援策が利用できる場合もありますが、対象や要件は年度や制度で変わります。利用可否は思い込みで判断せず、厚生労働省や自治体などの一次情報で最新の条件を確認し、申請の締切や必要書類を早めに押さえておくことが大切です。
契約形態の工夫でも負担は平準化できます。大きな初期投資を一度に抱える買い切りだけでなく、月額や年額で分散させる方式、機能を段階的に導入する方式など、資金繰りに合わせた選択肢を比較しましょう。総額とキャッシュフローの両面で無理のない形を探すことが肝心です。
- 要件を必須・要望に分け、過剰な機能と移行範囲を削る
- 同一条件で複数社に見積もりを依頼し比較する
- 補助金・支援策は一次情報で最新の要件と締切を確認する
導入・移行チェックリスト
更新プロジェクトは関係者が多く、抜け漏れが後の費用増につながります。契約前・移行前・本番前の各段階で確認すべき項目をチェックリスト化し、担当と期限を割り当てておくと、進行の可視化と手戻りの防止に役立ちます。
- 自院データを標準形式で取り出せる権利と手段を契約で確認したか
- 移行範囲（全件か直近分か）と検証方法を合意したか
- テスト移行と切り戻し手順が計画に含まれているか
- 見積もりに教育・立ち上げ支援・保守が明記されているか
- 複数年のTCOで総額を比較したか
よくある誤解と回避策
更新費用をめぐっては、思い込みが判断を誤らせることがあります。代表的なのは「初期費用が安ければお得」という誤解です。ランニングや移行、保守まで含めた総額で見なければ、数年後に逆転していることも珍しくありません。目先の数字だけで結論を出さないことが重要です。
- 誤解：データ移行は全部やって当然 → 回避：範囲を絞れば費用も検証も軽くなる
- 誤解：見積もりの総額だけ見れば十分 → 回避：項目の範囲を一つずつ確認する
- 誤解：移行はベンダー任せでよい → 回避：検証は現場が主体で行う
注意点（一般論として）
移行は診療情報という重要データを扱うため、作業中の情報漏えいや消失を防ぐ管理が欠かせません。移行データの取り扱い範囲、作業者、保管方法を取り決め、テストで使った実データの廃棄まで手順に含めるとよいでしょう。安全管理は関連ガイドラインの趣旨に沿って設計してください。
本稿の相場観や年数はあくまで一般的な目安であり、実際の費用は規模・要件・既存資産で大きく変わります。個別の判断は、自院の条件をもとにベンダーや専門家と相談し、制度面は必ず最新の一次情報で確認することをおすすめします。
想定Q&A
Q. 過去のカルテはすべて移さないといけませんか。A. 必須ではありません。直近数年を移行し、それ以前は旧環境を参照用に残す運用も広く行われます。診療上の必要性と費用のバランスで範囲を決めるのが現実的です。
Q. クラウドにすれば必ず安くなりますか。A. 一概には言えません。利用年数や規模で総額は逆転し得ます。初期を抑えたい、更新の手間を減らしたいといった目的に合うかどうかで判断してください。当社の Sakigake Platform のようなクラウド基盤も、TCOと運用体制の両面から検討する対象になります。
移行スケジュールとプロジェクト体制の組み方
更新プロジェクトは、要件の整理から製品選定、データ移行、本番稼働までを合わせると半年から一年以上かかることも珍しくありません。稼働希望日から逆算し、いつまでに何を決めるべきかを工程表に落とし込み、院内の合意形成や予算確保、契約の時期まで織り込んでおくと、直前になって慌てる事態を避けられます。
体制面では、事務長や情シスだけで進めず、実際にカルテを使う診療部門や看護、医事の代表者を早い段階から巻き込むことが成功の鍵です。現場の運用を知る人が要件確認やテスト移行の検証に加わることで、稼働後に「使いにくい」「必要な情報が移っていない」といった手戻りを大きく減らせます。
スケジュールには、移行リハーサルと本番稼働の間に、見つかった不整合を修正し再検証するための予備期間を必ず設けておきます。ここを詰め込みすぎると、問題が残ったまま稼働日を迎えることになりかねません。余裕を持った日程が、結果的に稼働後の混乱と追加費用を抑えることにつながります。
- 要件定義・選定・移行・稼働の各工程に余裕を持った期限を置く
- 診療・看護・医事など現場の代表者を早期に巻き込む
- 予算確保や院内承認のタイミングを逆算して組み込む
まとめ
電子カルテの更新費用は、ハードウェア・ソフトウェア・データ移行・保守の合計であり、初期費用だけでなく複数年のTCOで捉えることが失敗回避の第一歩です。特にデータ移行は範囲と工数の見極めが費用を左右するため、テスト移行と検証を計画に組み込みましょう。
自院の要件を優先度で整理し、同条件で複数社を比較し、制度・補助金は一次情報で確認する。この基本を押さえれば、更新は過度に恐れる対象ではなくなります。次世代の電子カルテ Sakigake Prime のような選択肢も、TCOと移行のしやすさの観点から比較検討してみてください。