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

電子カルテシステムの発注は、自院の業務整理、共通RFPの作成、同条件での比較と契約の順に進めると、運用に合う導入につながります。発注形態や要件整理、契約、費用、委託先の選定は、この流れの各段階で検討する項目です。

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

電子カルテシステムの発注・外注の始め方

発注は、現状の業務を洗い出し、導入後に達成したい状態を定めるところから始めます。前提をそろえないまま開発会社に依頼すると、各社が異なる前提で見積もるため、価格や納期を比べにくくなります。

発注の目的と委託範囲の決め方

目的は「紙をなくす」だけで止めず、改善したい業務や診療の状態まで具体的に書き出します。

  • 時間短縮:受付から診察、検査、処方、会計、文書作成までの所要時間の短縮。
  • 情報共有:複数拠点から診療履歴を参照できる状態。
  • 入力・制度対応:入力ミスの減少と、電子カルテ情報共有サービスや電子処方箋への対応。

目的が決まれば、開発会社に委託する範囲と、標準機能で済ませる範囲を分けて考えられます。

診療所と病院で変わる発注条件

無床診療所では、診療科、医師数、端末数、訪問診療の有無、レセコン連携を基準に条件を整理します。

有床診療所や病院では、病棟、看護、薬剤、検査、放射線との部門連携が増えます。さらに、リハビリや手術、栄養、医事会計も、連携先として加わります。

また、同時接続数と停止時の代替運用も条件に含めます。大規模な製品を小規模診療所に導入すると、不要な機能や保守の負担が生じる可能性があります。

2026年の標準連携とデータ可搬性

制度や接続仕様の更新に備えて、導入前に次の2点を確かめます。

  • 標準連携:電子カルテ情報共有サービス、電子処方箋、オンライン資格確認、標準APIへの対応状況。
  • データ可搬性:契約終了時にデータを引き継げるかどうか。

厚生労働省は2026年3月に、医科診療所・中小病院向けの基本要件を公開しました(出典は同省「電子カルテ及びレセプトコンピュータ標準仕様(基本要件)」、2026年)。この資料は、標準APIや互換性を比べる際に役立ちます。

電子カルテシステムの発注形態の選び方

電子カルテの発注形態を、標準業務向け、既存業務向け、独自業務向けの3つのパネルで示した図。
業務の独自性に合わせて発注形態を見比べられます。

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

パッケージ型・クラウド型の特徴

パッケージ型は医療機関向けの機能を備えているため、要件定義の負担を抑えやすい選択肢です。また、クラウド型はサーバーの保有やバックアップ運用の負担を軽くし、院外利用や災害時の復旧も考えやすくします。

  • 通信・料金:通信障害への備えと、月額料金の改定条件。
  • データ・契約:データ返却の方法と、ベンダーロックインの有無。
  • 安全性:バックアップ世代数、復旧目標、認証方式、ログ保存期間について質問します。

クラウドという形態そのものより、ここで挙げた運用条件を見て判断します。

既存業務を活かす追加開発・連携基盤

既存カルテは残したまま、予約、問診、PACS、検査機器、オンライン診療、地域連携だけを追加できます。

全面刷新と比べると移行範囲を絞れる可能性があります。ただし、旧システムの仕様やAPIの制約が障害になります。

連携方式と障害時の切り分けは、設計段階で確かめておきます。また、画面や帳票を追加する場合は、バージョンアップを妨げない拡張方法かどうかも見ておきます。

フルスクラッチの自由度と継続責任

独自の病棟運用、研究、複数拠点の統合、特殊な文書作成などで既存製品に合わせにくい場合に、検討の対象になります。

この方式では、診療録の正確性や権限、操作ログ、バックアップを、自院と開発会社が継続して担います。監査や制度改定、セキュリティ更新も、長く担い続けることになります。

5年後の保守会社や担当者の交代、仕様書の更新、データ移行まで予算と体制に含められる場合に適した方式です。

ポイント

発注形態は、標準業務を早く安定させたいか、独自の診療フローを残したいかで選びます。費用や導入期間、障害時の責任分界まで含めて比べると、選びやすくなります。

RFPと要件整理の進め方

RFPの要件を機能、連携、移行、非機能の4分類に分けたチェックリスト図。
分類をそろえると、各社の提案条件を照合しやすくなります。

RFPは、開発会社やベンダーに提案を依頼するための文書です。対象施設や業務課題、連携、移行、非機能要件を書き、納期や保守、見積の分け方も、同じ書式でそろえて示します。

職種と場面ごとの現状業務の聞き取り

聞き取りには、医師だけでなく、看護師、医事、薬剤、検査、放射線の担当者にも加わってもらいます。さらに、リハビリや地域連携、経営、情報システムの担当者も関わります。

受付から会計までの患者の動きを時系列で描き、誰がどの端末で何を入力し、次の部門へどう引き継ぐかを確かめます。

紙帳票やExcelを画面に置き換えるだけで終えず、二重入力や確認待ちが起きる理由まで探します。

RFPの機能・連携・移行・非機能の分け方

RFPを要件の分類ごとに書いておくと、抜け漏れや提案の前提の食い違いを抑えられます。

  • 機能:患者情報、診療記録、オーダー、文書、予約、会計、権限、検索。
  • 連携:レセコン、PACS、検査機器、オンライン資格確認、電子処方箋、情報共有サービス、予約・問診の接続先。
  • 移行:患者基本情報だけか、過去何年分の診療履歴・処方・検査・画像・PDF・自由記載までか。
  • 非機能:接続数、応答時間、稼働、バックアップ、復旧目標、認証、権限分離、ログ、端末、通信断時の運用。

端末要件やサポートの受付時間も、非機能要件に含めます。

厚生労働省の安全管理ガイドライン第7.0版は、2026年6月に公開され、経営管理編、企画管理編、システム運用編、保守委託機関編などに分かれています。出典は厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」(2026年)です。

RFPでは、同ガイドラインの考え方に沿って、ベンダーと医療機関の責任の分け方を書き込みます。

デモと移行サンプルによる提案の実現性の確認

デモと移行試験では、複数の職種が実際の業務シナリオを使って、提案を評価します。

  • デモ:受付、診察、検査依頼、処方、会計、紹介状作成までを通して試す。
  • 操作確認:クリック数、検索、訂正履歴、部門通知、権限表示、通信停止時の対応。
  • 移行試験:契約前に、サンプルで出力項目や文字コード、画像形式、欠損・重複を確かめます。
  • 移行範囲:全件移行が高額な場合は、直近数年分を構造化し、古い記録はPDFや参照アーカイブに置きます。

移行後の検索方法と、移行の責任者も明らかにしておきます。

ポイント

現状業務は職種ごとに聞き取り、そのうえでRFPを機能・連携・移行・非機能に分けて書きます。提案の実現性は、デモと移行サンプルで確かめます。

電子カルテ開発の契約形態の選び方

請負契約と準委任契約を左右に並べ、合意仕様の完成と一定の業務遂行を対比した図。
契約の中心を完成物と業務遂行に分けて把握できます。

契約形態は、要件が固まっているか、検証しながら進めるか、運用をどこまで任せるかで決まります。また、要件定義や移行、研修のほか、稼働立会いと保守も、契約書と個別仕様書に分けて記載します。

請負契約の完成物と受入条件

請負契約は、合意した仕様どおりにシステムを完成させ、検査と引き渡しを行う場合に検討します。

その際は、画面や帳票、連携、性能を含め、移行データと受入テストの合格条件を定めます。

納品物と検収期限を書き、診療シナリオや応答時間も受入条件に入れます。エラー表示やログの確認方法も、対象にします。「使いやすい」などの抽象的な表現だけでは判定が難しいためです。

準委任契約と要件整理・継続的な改善との相性

準委任契約は、専門家に一定の業務遂行を委託する契約です。現状分析やRFP作成支援、プロジェクト管理で用いられ、アジャイル開発や移行支援、運用改善にも使われます。

作業時間や体制を費用の基準にする場合は、月ごとの範囲や成果物、報告方法を明記します。そのうえで、稼働上限と追加作業の承認手順も定めます。

契約書の責任分界と終了時の扱い

契約書では、データの権利や委託先の管理から、障害時の責任、契約終了時の扱いまでを項目ごとに確かめます。

  • データと権利:知的財産権、診療データの所有・利用範囲、秘密保持。
  • 委託と安全:再委託先の一覧と再委託時の承認、アクセス権限、ログの保管場所。
  • 障害と責任:障害・脆弱性対応、個人情報保護、監査、損害賠償。
  • 終了時:料金改定、解約、終了後の閲覧期間。

たとえばクラウドでは、バックアップと復旧の担当、パッチの適用時期、インシデント発生時に何時間以内に通知するかを、SLAや約款に定めます。

データ返却では、CSVや標準形式でデータを受け取れるかを確かめ、移行支援の費用とコピーの消去時期まで合意します。

ポイント

要件が固まっていて完成物を明確にできるなら請負、要件整理や継続的な改善が中心なら準委任を検討します。どちらの契約でも、責任分界と終了時のデータの扱いは契約書で確認が必要です。

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

電子カルテの費用は、施設規模、端末数、ユーザー数によって変わります。診療科や連携、移行、導入支援、保守も費用を左右します。

ここで示すのは、公開料金や行政資料の事例、企画段階の検討レンジであり、一律に当てはまる相場ではありません。

小規模診療所の初期0円から月額2万円前後の公開例

小規模診療所向けのクラウド型では、初期費用0円から、月額1万2,000円台から2万円台の公開例があります。

たとえば、DONUTSのCLIUS Directは、カルテとレセコンを含み、月額19,800円、初期費用0円からです。

同社は、最短5日で開通できるとしています(出典: 株式会社DONUTS「クラウド型電子カルテCLIUS 料金」、2026年確認)。

  • 利用条件:ユーザーID数や連携数に応じた別途費用。
  • 導入支援:追加端末、レクチャー、訪問支援も、別途費用がかかります。

表示価格だけで総額を決めず、上に挙げた別途費用も含めて比べます。

中小病院の月額24万円台からの公開例

AHISスタンダードプランは、端末10台の構成で月額245,850円からです。この価格は、2025年1月改定後の公開情報です(出典: 株式会社エイトス「AHISクラウド電子カルテ料金プラン」、2026年確認)。

一方で、初期費用は病院の規模や環境ごとの見積になります。医事会計や部門システムとの連携も、別途確かめます。

  • 比較する費用:導入支援、端末、ネットワーク、移行まで含めた費用。
  • 比較期間:月額だけでなく、5年TCOでの比較。

病院の導入・個別開発の費用の幅

東京都の資料には、無床診療所の実支出額200万円と、100床病院の実支出額7,000万円の例があります(出典: 東京都保健医療局「電子カルテの導入についてご相談ください」、2025年)。

これは補助制度を使った個別の例であり、全国一律の価格や、カルテ本体だけの相場を示すものではありません。

  • 大規模導入:病棟・部門連携を含む初期費用は、3,000万円から7,000万円級の可能性があります。
  • 独自開発:複数拠点連携を含め、数億円まで広がる可能性があります。
  • 個別見積:公開事例が限られるため、RFPに基づいて具体額を確かめます。
  • 見積項目:ライセンス、基盤、端末、ネットワーク、連携、マスタ、移行、教育、保守。
  • 追加項目:現地立会い、バックアップ、診断、制度改定、解約、データ返却。

初期費用が安く見えても、移行や連携が別見積であれば、稼働までの予算は変わります。

ポイント

費用は施設規模や端末数、ユーザー数で変わり、公開例は一律の相場ではありません。比べるときは、導入支援や別途費用を含め、5年TCOで見ます。

委託先の選定と見積比較で確認する項目

委託先は、知名度よりも、類似施設での経験や医療業務の理解、連携・移行実績、保守体制、契約の透明性で評価します。また、販売、導入支援、開発、クラウド運用を別々の会社が担う場合は、障害時の窓口と、どこまでを誰が受け持つかを確かめます。

施設規模・診療領域・移行条件による実績の照合

導入実績は、無床・有床診療所や中小病院など、自院に近い条件のものを確かめます。

加えて、診療科や病床数、端末数、旧システム、移行データの範囲を尋ねます。稼働までの期間や現場教育の方法も、あわせて質問します。

稼働後の問い合わせ件数も確かめます。事例を公開していない場合は、匿名の工程表や受入テストの例を求めます。

同じ前提と5年TCOによる見積比較

各社の条件をそろえておくと、見積金額や提案内容の違いを判断できます。

  • 共通条件:患者・端末・ユーザー数、連携先、移行年数、研修回数、保守時間、稼働日。
  • 見積項目:機能、追加開発、前提、除外項目、納期、支払条件、5年間の総額。
  • 運用評価:操作性、移行再現性、標準API、復旧、問い合わせへの一次回答、現地支援。

たとえば、A社だけが移行費を含み、B社は連携費を含まない場合、見積額だけでは割安かどうか判断できません。さらに、制度改定への対応と、データ返却のしやすさも確かめます。

標準仕様では、価格やセキュリティの開示、データ移行に必要な事項、インターフェース仕様などの情報提供が重視されています。出典は厚生労働省「中小病院向け電子カルテ及びレセプトコンピュータ標準仕様書」(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社程度に絞ったら、同じ診療シナリオを使って、複数の職種が導入条件を確かめます。

  1. 同じ患者・診療シナリオを使った、各社のデモ。
  2. 移行サンプル、受入テスト、障害時の紙運用、安全管理、保守窓口の確認。
  3. 医師、看護師、医事、情報システム担当者の評価に合意したうえで、契約します。

この手順を踏むと、導入後の定着と医療業務の継続性を両立しやすくなります。

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

会社紹介

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

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

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

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

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

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