電子カルテシステム開発の発注/外注/依頼/委託方法について

電子カルテシステムの発注・外注は、製品を一つ選んで購入する作業ではなく、診療所や病院の業務、医療情報連携、セキュリティ、将来の制度対応を含めて委託範囲を設計するプロジェクトです。最初に自院の規模と業務を整理し、パッケージ・クラウド・追加開発・スクラッチの適性を見極め、同じ条件のRFPで複数社を比較することが成功の近道です。

本記事では、電子カルテシステムを発注・外注・委託するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較の順に解説します。診療所と病院を同じ価格表で比べず、初期費用だけではなくデータ移行、他システム連携、研修、保守、契約終了時のデータ返却まで含めて判断できるようにしています。

▼全体ガイドの記事
・電子カルテシステム開発の完全ガイド

電子カルテシステムの発注・外注は何から始めますか?

電子カルテシステムの発注計画を整理する担当者

電子カルテシステムの発注は、現状業務の棚卸しと、導入後に達成したい状態の定義から始めます。いきなりベンダーへ「電子カルテを作ってください」と依頼すると、会社ごとに前提条件が異なる見積書が並び、価格も納期も比較できなくなります。

発注の目的と委託範囲を最初に決めます

目的は「紙をなくす」だけでは不十分です。受付から診察、検査、処方、会計、文書作成までの時間を短くしたいのか、複数拠点で診療履歴を参照したいのか、入力ミスを減らしたいのか、電子カルテ情報共有サービスや電子処方箋へ対応したいのかを具体化します。目的が決まると、開発会社へ委託する範囲も、標準機能で済ませる範囲も判断しやすくなります。

診療所と病院では発注条件が変わります

無床診療所は、診療科、医師数、端末数、訪問診療の有無、レセコンとの連携を軸に考えます。有床診療所や病院では、病棟、看護、薬剤、検査、放射線、リハビリ、手術、栄養、医事会計などの部門連携が増え、同時接続数や停止時の代替運用も重要になります。病院向けの大規模製品を小規模診療所へそのまま当てはめると、不要な機能と保守負担を抱える可能性があります。

2026年は標準連携とデータ可搬性を確認します

2026年は、電子カルテ情報共有サービス、電子処方箋、オンライン資格確認、標準API、契約終了時のデータ引き継ぎを早い段階で確認する必要があります。厚生労働省は2026年3月に医科診療所向けと中小病院向けの電子カルテ及びレセプトコンピュータ標準仕様の基本要件を公開しており、標準APIや互換性、接続可否を比較する材料が増えています(出典: 厚生労働省「電子カルテ及びレセプトコンピュータ標準仕様(基本要件)」、2026年)。

電子カルテシステムの発注形態はどれを選びますか?

クラウドとパッケージの発注形態を比較する場面

発注形態は、費用だけでなく、導入までの期間、制度改定への追随、院内の運用変更、障害時の責任分界を左右します。標準業務を早く安定させたいのか、独自の診療フローを残したいのかを基準に、次の選択肢を比較します。

パッケージ型・クラウド型は標準業務を短期間で始めやすいです

パッケージ型は、医療機関で利用される機能をあらかじめ備えているため、要件定義の負担を抑えやすい選択肢です。クラウド型は、サーバー保有やバックアップ運用の負担を軽くしやすく、院外利用や災害時の復旧を考えやすい一方、通信障害、月額料金の改定、データ返却、ベンダーロックインを確認する必要があります。クラウドだから安全と決めつけず、バックアップの世代数、復旧目標、認証方式、ログ保存期間を質問します。

追加開発・連携基盤は既存業務を活かしたいときに向いています

既存の電子カルテを残し、予約、問診、PACS、検査機器、オンライン診療、地域連携の機能だけを追加する方法もあります。全面刷新より移行範囲を絞れる可能性がありますが、古いシステムの仕様やAPI制約がボトルネックになるため、連携方式と障害時の切り分けを設計段階で確認します。標準機能では足りない入力画面や帳票だけを追加する場合は、変更後もバージョンアップを妨げない拡張方法かどうかが重要です。

フルスクラッチは自由度と継続責任を引き受ける方式です

フルスクラッチ開発は、独自の病棟運用、研究、複数拠点の統合、特殊な文書作成など、既存製品に合わせにくい要件で検討します。ただし、診療録の正確性、権限、操作ログ、バックアップ、監査、制度改定、セキュリティ更新を自院と開発会社が継続的に担う必要があります。新規開発の自由度だけでなく、5年後の保守会社、担当者交代、仕様書更新、データ移行まで予算と体制に含められる場合に適しています。

RFPと要件整理はどのように進めますか?

RFPと要件を整理する医療システム担当者

RFPは、開発会社やベンダーへ提案を依頼する文書です。製品名や画面の希望を並べるだけでなく、対象施設、業務課題、必要な連携、データ移行、非機能要件、納期、保守条件、見積の分け方を同じ書式で提示すると、提案内容と金額を比べやすくなります。

現状業務は職種と場面ごとに聞き取ります

要件整理では、医師だけでなく、看護師、医事、薬剤、検査、放射線、リハビリ、地域連携、経営、情報システムの担当者を巻き込みます。受付から会計までの患者動線を時系列で描き、誰が、どの端末で、どの情報を入力し、次の部門へ何を渡すかを確認します。紙の帳票やExcelを単純に画面へ置き換えるのではなく、二重入力や確認待ちが発生する理由を見つけることが大切です。

RFPには機能・連携・移行・非機能を分けて書きます

機能要件には患者基本情報、診療記録、オーダー、文書、予約、会計、権限、検索を記載します。連携要件にはレセコン、PACS、検査機器、オンライン資格確認、電子処方箋、電子カルテ情報共有サービス、予約や問診の接続先を記載します。データ移行では、患者基本情報だけを移すのか、過去何年分の診療履歴・処方・検査・画像・PDF・自由記載まで対象にするのかを分けます。

非機能要件には、同時接続数、応答時間、稼働時間、バックアップ、復旧目標、認証、権限分離、監査ログ、端末要件、通信断時の運用、サポート受付時間を含めます。厚生労働省の安全管理ガイドライン第7.0版は2026年6月に公開され、経営管理編、企画管理編、システム運用編、保守委託機関編などに分かれています(出典: 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年)。RFPでは、ベンダー側と医療機関側の責任分界をこの考え方に沿って確認します。

デモと移行サンプルで提案の実現性を確かめます

提案書だけで判断せず、実際の患者受付、診察、検査依頼、処方、会計、紹介状作成のシナリオを使ってデモを依頼します。画面の見た目より、入力クリック数、検索のしやすさ、訂正履歴、他部門への通知、権限による表示制御、通信が止まったときの対応を確認します。医師と医療事務で操作感が違うため、複数職種が同じシナリオを評価します。

データ移行は、サンプルデータを使った試験を契約前に依頼します。旧システムから出力できる項目、文字コード、画像の形式、欠損や重複の扱い、移行後の検索方法、移行責任者を明らかにします。全件移行が高額になる場合は、直近数年分を構造化データで移し、それ以前はPDFや参照アーカイブにするなど、診療安全と費用のバランスを検討します。

電子カルテ開発の契約形態はどのように選びますか?

電子カルテ開発の契約条件を確認する担当者

契約形態は、要件が固まっているか、検証しながら進めるか、導入後の運用をどこまで任せるかで決まります。電子カルテは医療現場の合意形成に時間がかかるため、開発部分だけでなく、要件定義、移行、研修、稼働立会い、保守を契約書と個別仕様書で分けて記載します。

請負契約は完成物と受入条件を明確にできる場合に使います

請負契約は、合意した仕様のシステムを完成させ、検査と引き渡しを行う場合に検討します。画面、帳票、連携、性能、移行データ、受入テストの合格条件を具体的に書き、納品物と検収期限を定めます。「使いやすい」「十分な性能」などの抽象的な表現だけでは判定が難しいため、診療シナリオ、応答時間、エラー時の表示、ログの確認方法まで受入条件に落とし込みます。

準委任契約は要件整理や継続的な改善と相性がよいです

準委任契約は、専門家が一定の業務を遂行することを委託する契約です。現状分析、RFP作成支援、プロジェクトマネジメント、アジャイル開発、データ移行支援、運用改善など、進めながら内容が具体化する業務で使われやすい形態です。作業時間や体制が費用の基準になる場合は、月ごとの作業範囲、成果物、報告方法、稼働上限、追加作業の承認手順を明記します。

契約書では責任分界と終了時の扱いを確認します

契約では、知的財産権、診療データの所有・利用範囲、秘密保持、再委託、障害対応、脆弱性対応、個人情報保護、監査、損害賠償、料金改定、解約、データ返却、契約終了後の閲覧期間を確認します。クラウドの場合は、バックアップと復旧を誰が担うか、セキュリティパッチをいつ適用するか、インシデント発生時に何時間以内に通知するかをSLAや約款に落とし込みます。

再委託先がクラウド基盤や保守を担当する場合は、委託先の一覧、再委託時の承認、アクセス権限、ログの保管場所も確認します。契約終了時にCSVや標準形式でデータを受け取れるか、移行支援費用はいくらか、返却後にベンダー側のコピーがいつ消去されるかまで合意できれば、将来の乗り換えリスクを抑えられます。

電子カルテシステムの費用相場とコスト内訳は?

電子カルテシステムの費用内訳を確認する場面

電子カルテシステムの費用は、施設規模、端末数、ユーザー数、診療科、部門連携、データ移行、導入支援、保守条件で大きく変わります。以下の金額は、公開料金と行政資料で確認できる事例、企画段階での検討レンジを組み合わせたもので、すべての医療機関に適用できる一律相場ではありません。

小規模診療所は初期0円から月額2万円前後の公開例があります

小規模診療所向けのクラウド型では、初期費用0円から、月額1万2,000円台から2万円台までを検討の入口にできる公開例があります。株式会社DONUTSのCLIUS Directは、カルテとレセコンを含む月額19,800円、初期費用0円から、最短5日での開通を掲げています(出典: 株式会社DONUTS「クラウド型電子カルテCLIUS 料金」、2026年確認)。ただし、ユーザーID数、連携数、追加端末、レクチャー、訪問支援などで別途費用が発生するため、表示価格だけで総額を決めてはいけません。

中小病院では月額24万円台からの公開例があります

中小病院向けでは、月額制でも診療所向けより大きな費用になります。AHISのスタンダードプランは、2025年1月改定後の公開情報で、端末10台構成の参考価格として月額245,850円からです(出典: 株式会社エイトス「AHISクラウド電子カルテ料金プラン」、2026年確認)。初期費用は病院の規模や環境ごとの見積で、医事会計システムや部門システム連携も別途確認が必要です。したがって、単純に月額へ利用年数を掛けるのではなく、導入支援・端末・ネットワーク・移行を加えた5年TCOで比べます。

病院の導入・個別開発は数千万円から数億円の可能性があります

東京都の資料には、無床診療所の実支出額200万円、100床病院の実支出額7,000万円という活用例が掲載されています。これは補助制度を利用した個別の実支出例であり、全国一律の価格や電子カルテ本体だけの相場ではありません(出典: 東京都保健医療局「電子カルテの導入についてご相談ください」、2025年)。病棟や部門システムを含む大規模導入では、初期費用3,000万円から7,000万円級、独自開発や複数拠点連携では数億円まで広がる可能性がありますが、公開事例が限られるため、具体額はRFPに基づく個別見積で確認します。

見積書は、ライセンス、クラウド・サーバー、端末、ネットワーク、連携インターフェース、マスタ整備、移行、教育、現地立会い、保守、バックアップ、セキュリティ診断、制度改定、解約・データ返却に分けてもらいます。初期費用が安くても、移行や連携が別見積であれば、稼働までの予算は大きく変わります。

委託先の選定と見積比較では何を確認しますか?

電子カルテの委託先候補と見積書を比較する場面

委託先は知名度だけでなく、自院と似た施設の導入経験、医療業務の理解、連携・移行の実績、保守体制、契約の透明性を総合評価します。特に、販売会社、導入支援会社、開発会社、クラウド運用会社が別々になる場合は、障害時の窓口と責任分界を確認します。

実績は施設規模・診療領域・移行条件まで照合します

「医療機関への導入実績がある」という説明だけでなく、無床診療所、有床診療所、中小病院など、自院と近い条件の事例を確認します。診療科、病床数、端末数、旧システム、移行したデータ範囲、稼働までの期間、現場教育の方法、稼働後の問い合わせ件数を質問します。事例を開示できない場合は、匿名化した工程表や受入テストのサンプルを示してもらう方法もあります。

見積比較は同じ前提と5年TCOで行います

相見積もりでは、候補会社へ同じ患者数、端末数、ユーザー数、連携先、移行年数、研修回数、保守時間、稼働希望日を提示します。A社だけが移行費を含み、B社は連携費を含まない状態では、安い見積が本当に安いとはいえません。見積の比較表には、必須機能の充足、追加開発の有無、前提条件、除外項目、納期、支払条件、5年間の総支払額を並べます。

価格以外の評価項目には、診療シナリオの操作性、データ移行の再現性、標準API、障害時の復旧、問い合わせへの一次回答、現地支援、制度改定への対応、データ返却のしやすさを含めます。厚生労働省の標準仕様では、価格、セキュリティ開示、データ移行に必要な事項、インターフェース仕様などの情報提供が重視されています(出典: 厚生労働省「中小病院向け電子カルテ及びレセプトコンピュータ標準仕様書」、2026年)。これらを質問票に入れると、営業資料だけでは見えない差が比較できます。

リスクは受入テストと段階導入で小さくします

全施設を一度に切り替えるのではなく、1診療科、1拠点、または一部業務で先行検証し、患者受付から会計までの受入テストを行います。テストでは正常系だけでなく、誤入力の訂正、権限外の閲覧、通信断、停電、バックアップからの復旧、連携先の停止、旧カルテ参照も確認します。現場が合格と判断する基準を先に決めておけば、稼働直前の「想定と違う」を減らせます。

医療現場では、システムの完成がゴールではなく、使い続けられる状態がゴールです。操作研修を一度実施するだけでなく、職種別のマニュアル、問い合わせ窓口、スーパーユーザー、稼働後の改善会議を設けます。AI機能を採用する場合も、診療判断の自動化を前提にせず、文書下書きや要約など補助用途に限定し、医療者の最終確認、ログ、評価、停止手順を要件と契約に含めます。

電子カルテシステムの発注・外注でよくある質問

電子カルテシステムの疑問を確認する担当者

発注前に多く寄せられる疑問を、判断の基準と一緒に回答します。料金や制度は製品の契約条件、施設の所在地、補助制度、最新の公募要件によって変わるため、最終的には候補会社と行政の最新情報を確認してください。

電子カルテシステムは自社開発と外注のどちらがよいですか?

医療情報の安全管理、標準連携、制度改定、24時間の障害対応まで自社で継続できる体制がなければ、医療システムに詳しい会社への外注が現実的です。独自業務があっても、まずパッケージやクラウドを基盤にし、API連携や限定的な追加開発を組み合わせると、自由度と保守性のバランスを取りやすくなります。

電子カルテの見積もりは何社から取ればよいですか?

比較可能なRFPを作成できる場合は、まず3社程度を候補にすると、提案品質と担当体制を確認しやすくなります。施設規模や特殊な連携がある場合は、総合ベンダー、クラウド型、導入支援に強い会社など性格の異なる候補を含め、同じ条件でデモ、移行サンプル、保守条件、5年TCOを比較します。

電子カルテのデータ移行は全件実施する必要がありますか?

全件移行が必須とは限りませんが、診療安全と参照性を損なわない範囲で移行方法を決める必要があります。直近の診療履歴やアレルギー、継続薬などを構造化データで移し、古い記録はPDFや参照アーカイブにする方法もあります。移行対象、変換精度、原本性、検索方法、費用、旧システムをいつ停止するかを、医療者と開発会社で合意します。

クラウド型電子カルテを契約するときの注意点は何ですか?

通信障害時の業務継続、バックアップと復旧、認証・権限、監査ログ、セキュリティ更新、障害通知、料金改定、再委託、契約終了時のデータ返却を確認します。厚生労働省の電子カルテ情報共有サービスは2026年6月にもシステムベンダー向け技術解説書を更新しているため、導入時点の対応状況だけでなく、制度や仕様の更新を保守契約にどう含めるかも質問すると安心です(出典: 厚生労働省「電子カルテ情報共有サービス」、2026年)。

まとめ

電子カルテシステムの発注計画をまとめる場面

電子カルテシステムの発注・外注では、最初に診療所か病院か、標準業務か独自業務か、全面刷新か既存システムとの連携かを決めます。そのうえで、RFPに現状業務、機能、連携、移行、セキュリティ、障害時運用、保守、データ返却を記載し、複数社へ同じ条件で提案を依頼します。

価格ではなく5年TCOと責任分界で選びます

公開料金には、CLIUSの月額19,800円やAHISの10端末構成月額245,850円からのような参考例がありますが、移行、連携、教育、保守、端末、ネットワークを加えると総額は変わります。見積書の安さだけでなく、5年間の支払額、現場が使えるか、制度改定に対応できるか、障害時に誰が責任を持つか、契約終了後にデータを取り出せるかを総合的に比較します。

発注前に同じ診療シナリオで候補を比較します

候補を3社程度に絞ったら、同じ患者・同じ診療シナリオでデモを行い、移行サンプル、受入テスト、障害時の紙運用、セキュリティ責任、保守窓口を確認します。現場の医師、看護師、医事、情報システム担当者が納得できる評価結果を残してから契約へ進むことで、導入後の定着と医療業務の継続性を両立しやすくなります。

▼全体ガイドの記事
・電子カルテシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。