電子カルテシステム開発は、業務要件の整理、同じ条件での製品選定、設計・開発、テスト、稼働、定着の順に進めます。
段階ごとに何を決めるかを押さえておくと、判断の抜け漏れを減らせます。
▼全体ガイドの記事
・電子カルテシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
電子カルテシステム開発の全体像
電子カルテシステムは、診療科や職種が同じ情報を参照し、検査・薬剤・医事会計・画像管理などへ正確に情報を渡す基盤です。患者情報の入力画面は、その一部にすぎません。
機能から先に決めると、運用ルールや、どこまでを誰が受け持つかが後から膨らみがちです。そのため、業務の流れと将来の連携を先に整理します。
対象範囲は医療業務全体
業務フローと要件は、どこまでを対象にするかと、どれを優先するかを分けて整理します。
- 外来業務：予約から次回予約までの流れを、受付、診察、検査、処方、会計の順に並べます。
- 入院業務：入院機能があれば、入退院、病棟、看護、食事を含めます。リハビリ、手術、退院サマリーも対象にします。
- 情報連携：電子カルテ、レセコン、PACS、検査、予約・問診、オンライン資格確認の間で、何をどう受け渡すかを洗い出します。
- 必須機能：多くの施設で求められる患者情報、既往歴、アレルギー、病名、診療履歴を押さえます。権限管理、操作ログ、バックアップ、障害時運用も含みます。
- 追加機能：必須・希望・導入後の3層に分けます。AI文書下書きや高度な分析は、効果を検証してから取り入れます。
受け渡しを図に描くと、二重入力や連携漏れを見つけやすくなります。また、これらの機能は、医療者による最終確認と、ログが残ることを前提にします。
自院の差別化要件と運用体制に応じた開発方式の選び方
方式は、診療所・病院の標準業務と、自院の差別化要件に合わせて選びます。
- 診療所：標準業務が中心で導入を急ぐ場合は、SaaS型クラウドやパッケージが候補になります。
- 病院：病棟・看護・部門システムとの連携が多く、パッケージにAPIや追加開発を組み合わせる方式が候補です。
- 独自要件：研究、複数拠点、特殊な診療フローを強みにしたい場合は、個別開発も検討します。
個別開発を選ぶ場合は、制度改定や安全管理、保守を長期にわたって担う体制まで計画します。
2026年時点では、医療DXへの接続も選定の段階から確認します。対象には、電子カルテ情報共有サービス、電子処方箋、オンライン資格確認が含まれます。
厚生労働省は2026年6月に、安全管理ガイドライン第7.0版を公開しました（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年）。
製品機能に加えて、脆弱性対応、バックアップ、インシデント連絡を確認します。
データの返却に関わる責任も、契約で定めておきます。
電子カルテシステム開発の進め方と6フェーズ
全体は6フェーズで進み、要件整理と選定の後に、設計・開発から定着までを順に扱います。
フェーズの区切りごとに判断を残しておくと、どこで何を決めたかを後から振り返れます。
期間の目安は、診療所の標準導入が数週間から3か月程度のケースがあり、病院は半年から1年を超える場合もあります。特に、病院で複数部門・機器・過去データを扱うと、期間が延びることがあります。期間を短くしたい場合も、テストや教育を削るのは避けてください。
フェーズ1：要件整理と現場業務の言語化
要件整理は、院長や情報システム担当者だけで決めず、各職種の代表者を参加させて進めます。
- 参加者：医師、看護師、医療事務、検査、薬剤の代表者が入ります。リハビリ、地域連携、経営管理の代表者も加えます。
- 業務の聞き取り：「誰が・いつ・どの情報を・どの画面で扱い、次の誰へ渡すか」を聞き取ります。
- 要件の整理：現在の困りごとと、変えてはいけない安全上のルールを切り分けます。
- 作成する資料：業務・機能・非機能・連携の一覧、移行方針、権限表、障害時運用、教育計画。
- 非機能要件：同時接続数、応答時間、稼働時間、バックアップ頻度、復旧目標を定めます。監査ログ、認証、端末・ネットワーク、保守時間も含めます。
現場の暗黙知は、そのままカスタマイズ要件にせず、標準機能で運用を変えられるかも検討します。
停止時の紙への切り替えと、復旧後に誰が再入力するかも決めておきます。そうしておくと、稼働直前の混乱を抑えられます。
フェーズ2：同じシナリオでの選定比較
候補は、同じRFPと診療シナリオを使って比べます。
- 候補条件：規模、診療科、病床数、端末数、既存システムを揃えて、3社程度に絞ります。
- 評価軸：要件適合、追加費用、導入体制、契約終了時のデータ可搬性を観点にします。
- 診療デモ：新患受付から次回予約まで、診察、検査オーダー、処方、会計の順に操作して確かめます。
- 職種別確認：医師はクリック数と過去カルテ検索、看護師は指示と記録、事務は患者情報と会計、管理者は権限・ログ・バックアップを見ます。
- 契約前確認：同じ患者データの移行サンプル、連携仕様、障害画面、通信断時の運用について、開発会社に質問します。
候補は、標準機能中心、連携に強い、個別開発に対応する会社など、性格を分けて選びます。
フェーズ3：設計・開発での標準と個別の切り分け
選定のあとは、要件を具体化して、システム同士の境界を設計します。
- 設計対象：画面、データ、権限、連携、運用の内容を詰め、各システムの境界を図に示します。
- 接続先：電子カルテ、レセコン、PACS、検査機器、予約・問診が対象です。電子処方箋とオンライン資格確認も含まれます。
- データ管理：どのシステムを正本にするかを決め、患者番号、職員ID、診療科、薬剤、検査、病名ごとに管理者を置きます。
- 優先順位：医療安全、法令・制度対応、業務効率、将来の保守性の観点で、カスタマイズを判断します。
- 必須仕様：患者取り違え防止、権限分離、監査ログ、重要連携の仕様と受入条件を定めます。
標準機能で代替できる要件まで個別開発にすると、更新のたびに検証費用が生じがちです。そのため、標準と個別の境界を見極めておきます。
フェーズ4：本番に近い患者シナリオでのテスト
医療機関側の受入テストでは、通常の外来に加えて、例外と受入条件も確かめます。
- 例外シナリオ：救急、紹介患者、検査結果の訂正、薬剤変更、入院・退院を含めます。返戻、通信断、停電、権限外閲覧も対象です。
- 実データ：利用目的を確認したうえで匿名化し、テスト環境の権限は本番と分けます。
- 受入条件：患者検索、オーダー連携、検査・画像参照、会計連携、操作ログ追跡を確認します。
- 不具合管理：重要度、回避策、修正期限、担当者を記録し、未解決項目を一覧にします。
- 稼働判定：安全・請求に影響する項目が解消し、現場が回避策を理解しているかで判断します。未解決項目をすべて0にする必要はありません。
開発会社の機能テストに加えて、現場の業務の流れで確かめることが必要です。
フェーズ5：稼働時の切替方法と障害時運用
切替方法、移行対象、当日の体制は、稼働の前に決めておきます。
- 一括移行：ある日を境に一度に切り替えます。小規模施設では現実的な場合があります。
- 段階移行：診療科や拠点ごとに、順に広げていきます。病院や複数拠点では管理しやすい場合があります。
- 並行利用：旧システムと新システムを、一定期間並べて使う方法もあります。
- 過去カルテ：全件を完全移行するとは限りません。基本情報と直近履歴を構造化し、古い自由記載、画像、PDFは参照用アーカイブに残す方法もあります。
- 切替準備：移行の対象期間、移行できない項目、確認方法、誤りが見つかった時の責任者を決めます。当日の体制と復旧基準も定めます。
移行日は、診療の少ない曜日や時間帯に加えて、月末月初、請求、休日・夜間の体制も踏まえて決めます。
移行の範囲が曖昧なまま切り替えると、現場ごとに認識がずれます。
切替当日は、ベンダーの立会い、院内の意思決定者、問い合わせ窓口、紙運用、復旧判断の基準を、一枚にまとめておきます。
フェーズ6：定着と現場改善の継続
稼働後1か月から3か月は、問い合わせと改善要望が集中します。そのため、問い合わせを個別に処理するだけでなく、傾向をまとめて扱う仕組みが要ります。
問い合わせは中身によって対応先も急ぎ度も変わるため、まず5種類に分けて優先度を付けます。
- 操作方法：使い方や画面の動かし方についての問い合わせ
- マスタ修正：登録内容の変更を求める問い合わせ
- 業務ルール：現場の運用ルールに関する問い合わせ
- 不具合：システムに問題があると分かった際の報告
- 追加要望：新たな機能や仕組みを求める内容
各部門には、現場のキーパーソンを置きます。さらに、定例会で改善の結果を共有すると、職員が自分たちのシステムだと感じやすくなります。
定着は、二重入力、受付から診察までの時間、オーダー差戻しを導入前と比べて測ります。ログイン数は、その目安の一つにすぎません。加えて、紙帳票の残数、入力漏れ、問い合わせの解決時間、障害復旧時間、職員アンケートも見ておきます。
AI機能を使う場合は、生成結果の確認率、修正内容、誤提案の報告数を記録します。そのうえで、医療者の最終判断を必須にします。
電子カルテシステム開発の費用相場とコストの内訳
費用は、施設規模、端末数、ユーザー数、診療科、連携機器によって変わります。
データ移行、研修、立会いの範囲も、費用を左右します。
公開価格は比較の起点と見ます。ただし、診療所の月額と病院の導入費は、同じ尺度で比べないようにします。
掲載する金額は、リサーチノートと公開情報で確認した事例と参考価格です。全国で共通の相場として扱うより、企画段階のレンジとして見るのが適切です。
施設規模別に見た費用レンジ
公開されている金額は、診療所向けのクラウド型から中小病院、東京都の補助事例まで幅があります。ここに挙げる施設規模別の金額は、全国一律の相場ではなく、比較の起点として見ます。
- 小規模診療所：クラウド型は初期費用0円から30万円程度、月額1万2,000円から2万円台。
- CLIUS Direct：初期費用は無料、月額は19,800円です。設定支援や連携条件は、別に確認が必要です。
- 中小病院：AHISの10台構成は月額245,850円（税込）から。周辺費用は別途確認が必要です。
- 東京都の活用例：無床診療所の実支出額200万円、100床病院は7,000万円。
CLIUS Directの公開価格の出典は株式会社DONUTS「クラウド型電子カルテCLIUS 料金」、確認日2026年8月です。
導入期間は最短5日とされています。ただし、実際は施設ごとに変わり、院内ネットワーク、端末、マスタ、研修も準備期間に関わります。
AHISの公開価格は、株式会社エイトス「AHISクラウド電子カルテ 料金プラン」の2025年改定価格です。
医事会計、部門連携、端末、ネットワーク、初期設定は、別に押さえておきます。
東京都の金額は、補助制度の事例です。全国標準の価格や製品本体の定価ではありません。
見積での初期費用・月額・5年TCOの区分
見積もりは、初期費用、月額費用、5年TCOのそれぞれに含む範囲を分けて確認します。
- 初期費用：要件定義、環境、ライセンスを含みます。端末・サーバー・ネットワーク、連携開発も対象です。マスタ、移行、研修、立会いも対象です。
- 月額費用：利用料、端末・ユーザー追加、クラウド基盤の費用がかかります。保守、問い合わせ、バックアップ、制度改定対応も含めます。
- オプション：PACS、検査機器、レセコン、オンライン資格確認、電子処方箋の扱いを確認します。
- 5年TCO：初期費用に5年分の月額を加えます。端末更新、連携・制度対応、移行も含めます。保守外作業、追加教育も足します。
- 契約終了時：データ出力、長期保管、旧システム閲覧費用も総額に含めます。
価格表に「標準」と書かれていても、機器や連携機能がオプションの場合があります。そのため、含まれているかを項目ごとに確かめます。
補助金は、確定前であれば差し引かずに表示します。総額で比べると、導入時だけ安い提案を見抜きやすくなります。
電子カルテシステムの見積もりを取る際のポイント
相見積もりでは、同じ条件を全社に提示します。そのうえで、提案会社ごとの前提、作業範囲、責任範囲、将来費用を揃えて比較します。
要件が曖昧なまま価格だけを求めると、追加開発や移行費が増え、納期と現場負担も膨らみます。
RFI・RFPに入れる確認項目
依頼書では、施設条件、機能要件、移行要件を分けて書きます。
- 施設条件：施設種別、病床数、診療科、拠点を記載します。職種別利用者数、端末数、現行システム、稼働希望日も書きます。
- 機能要件：患者検索、診察記録、オーダー、検査、画像、文書を求めます。会計、予約、権限、ログ、バックアップ、障害時運用も求めます。
- 要件の区分：必須・希望・将来に分け、標準・設定・追加開発・対応不可を回答してもらいます。
- 移行対象：患者情報、病名、アレルギー、処方を項目ごとに確かめます。検査、画像、PDF、自由記載も対象に含めます。
- 移行検証：構造化データとして検索できるかを確かめます。文字化けや欠損を見つける担当者と、リハーサルの費用も確認します。
回答に「移行可能」とだけ書かれている場合は、構造化データとして検索できるのか、画像やPDFとして参照するだけなのかを、具体的に質問します。
サンプルデータの移行リハーサルを見積に含めておくと、本番直前の想定外を減らせます。
契約・セキュリティ・保守の責任分界
方式ごとに、誰がどこまで担当するかと、契約・保守で確認する項目を明らかにします。
- クラウド：回線、端末、認証、基盤、アプリの担当を明確にします。バックアップと脆弱性対応も、誰が担うかを決めます。
- オンプレミス：サーバー、電源・空調、媒体の担当を確認します。遠隔保守、パッチ、障害部品も、誰が担うかを確かめます。
- 安全管理：多要素認証、最小権限、ログ、復元テスト、ランサムウェア時の連絡体制を確認します。
- 契約・SLA：障害受付・一次回答時間、制度改定や脆弱性の費用、再委託範囲を質問します。
- データ返却：契約終了後の形式、費用、期限を決めます。委託先も含めた責任の境目を明記します。
厚生労働省の第7.0版は、保守委託機関を含めた管理を示しています（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年）。
価格以外の評価軸と重み付け
価格だけに偏らないよう、施設の優先事項を評価表に反映します。
- 評価項目：機能適合、操作性、連携・標準規格、移行を比べます。セキュリティ、導入、保守、拡張性、5年TCOも見ます。
- 重み付け：医師の入力速度や部門連携・病棟管理など、施設の優先事項で配点します。
- 契約前確認：経営層、現場、情報システム、医事が懸念を出し、未解決のまま契約しません。
- 価格交渉：導入時期、支援範囲、研修回数、移行対象、保守レベルも調整します。
各社を同じ基準で採点します。ただし、診療所と病院では重視する点が異なり、同じ製品でも評価が変わります。
重要なテストや教育を削ると、稼働後の残業や問い合わせが増え、結果的にTCOが高くなります。
電子カルテシステム開発でよくある質問
質問は、費用、期間、移行、クラウドの安全性に集まりやすい傾向があります。ただし、回答は施設規模や既存環境によって変わります。
判断の起点になる考え方を、質問ごとにまとめます。自院の条件に当てはめて考えます。
電子カルテシステムの開発費用はいくらですか？
公開価格や事例の金額には幅があり、施設規模や個別連携の有無で変わります。
- 小規模診療所：クラウド型は初期費用0円から30万円程度、月額1万2,000円から2万円台。
- 中小病院：月額20万円台からの公開例があります。
- 100床前後・個別連携が多い施設：初期費用が数千万円規模の事例もあります。
いずれも一般的な相場ではありません。そのため、端末数、連携、移行、教育を含めた見積もりで確認してください。
導入・開発にはどのくらいの期間がかかりますか？
期間は、施設規模と導入範囲によって異なります。目安は、次に示すとおりです。
- 小規模診療所：標準機能なら準備を含めて数週間から3か月程度。
- 病院：部門・機器連携、データ移行を伴う場合は半年から1年超のことがあります。
小規模診療所の目安は、標準機能を使う場合のものです。一方で、病院では部門システムや機器との連携、過去データの移行、複数職種の受入テストを行うと、期間に影響します。
また、院内の意思決定、データ整理、職員の参加、稼働日の制約も、期間に関わる点です。
各工程の担当者と完了条件は、事前に決めてください。
過去の電子カルテデータはすべて移行できますか？
すべてのデータを新システムで同じように検索・編集できるとは限りません。そのため、データの性質に応じて移行方法を分けます。
- 構造化データ：患者基本情報や直近の処方・検査を移します。
- 参照用データ：古い自由記載、画像、PDFをアーカイブに保存する方法があります。
- 契約条件：移行対象期間・項目と、欠損時の扱いを決めます。
- 照合方法：サンプル検証と本番後の照合方法を定めます。
クラウド型電子カルテは安全ですか？
安全性は、運用と契約の両面から確かめます。クラウド型であることは、安全性の判断材料の一つにすぎません。
- 情報保護：認証、権限、暗号化、監査ログ、バックアップ、復元テストを確認します。
- 委託・契約：脆弱性対応、障害連絡、再委託先、データ返却、双方の責任を定めます。
- 通信障害：診療を続けるための紙運用や代替手順を準備します。
- 継続点検：厚生労働省の最新ガイドラインを基準に、導入後も点検を続けます。
電子カルテシステム開発の進め方まとめ
要件整理から定着までを一つのプロジェクトとして設計し、製品や開発会社は、その後に選びます。
診療所と病院は分けて考え、標準機能と個別開発、初期費用・月額・5年TCOも分けて確認します。そうすると、自院に合わない安さや過剰な機能を避けやすくなります。
最後に確認したい6フェーズのチェックリスト
6フェーズを、担当と完了条件の観点から一つずつ見直します。
- 要件整理：業務フローと必須要件を定めます。
- 選定：同じ診療シナリオと質問票で候補を比べます。
- 設計・開発：標準と個別の境界、データの正本、権限、連携責任を決めます。
- テスト：例外を含む受入条件を確かめます。
- 稼働：移行範囲、切替、障害時運用を準備します。
- 定着：問い合わせと改善を記録し、導入前後の業務指標で効果を評価します。
現状業務と見積条件の一枚まとめ
準備した条件をもとに、3社程度の候補へ同じ前提を示し、比較します。
- 受付から会計までの業務フロー、連携・移行対象、困りごと、稼働希望日を一枚にまとめます。
- デモ、移行サンプル、障害時運用を確認し、契約上の責任の範囲を確かめます。
成果は、医療者が安全に使い続け、業務改善につなげられる状態を作ることです。導入日は、その途中の一段階にあたります。
▼全体ガイドの記事
・電子カルテシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。