医療機関向け電子カルテシステム開発の進め方/やり方/流れや方法/手法/工程/手順

電子カルテ導入は、要件整理と選定から始めます。設計・開発とテストを経て、稼働と定着へ進めると、診療を止めずに現場へ定着しやすくなります。各段階で完了条件を決めてから次へ進むのが基本です。

▼全体ガイドの記事
・医療機関向け電子カルテシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

医療機関向け電子カルテシステムの全体像

電子カルテは、単独のアプリではなく、診療科、病床、職種、既存機器、請求業務、情報共有を支える業務基盤です。そのため、導入の検討も院内の業務全体を対象に進めます。

診療と経営をつなぐ基幹システムとしての電子カルテ

電子カルテは扱う情報が多く、連携する範囲も広いため、どこまでを対象にするかを早い段階で決めます。

• 患者情報：基本情報、保険・資格、受診履歴、アレルギー、既往歴、病名を扱います。加えて、診療録、処方、検査結果、画像、文書も扱います。
• 共通連携：オーダリング、看護記録、病床管理、予約・問診、医事会計を扱います。加えて、レセプト、電子処方箋、オンライン資格確認も扱います。
• 病院の連携：PACS、RIS、検体検査、病理、薬剤を扱います。加えて、給食、リハビリ、手術、地域連携も扱います。
• 評価の視点：機能数よりも、受付から診療、検査、会計、退院後の連携までの流れ

外来中心の診療所では、病棟管理に予算をかけても、入力や予約・会計が改善しないことがあります。一方で、病院が診療録だけを導入すると、看護・薬剤・検査・医事会計との二重入力が残ります。

診療所と病院で比べるシステムの違い

診療所と病院では、必要な機能や運用条件が異なるため、施設別に比べます。

• 診療所：少ない端末で受付から資格確認までを速く扱えること。予約、問診、診療録、処方、レセコンも含みます。
• 在宅・複数拠点：訪問先からの参照、患者ID共有、通信障害時の運用
• 診療所向けクラウド：短期間で導入しやすく、サーバー更新を自院で抱えずに済む
• 病院：病床数、診療科、職種、部門、端末が費用と工期を左右し、機器連携や夜間・休日体制も影響します。
• 比較軸：病院では、部門間の患者情報共有、紙運用、監査ログ、バックアップ、復旧目標も見ます。

診療所向けSaaSと大規模病院向けの統合システムは、比べる軸を分けて考えます。

デジタル庁は、標準規格に準拠したクラウドベースの「標準型電子カルテ」を整備しています。医療DX工程表では、遅くとも2030年までに概ねすべての医療機関で標準化された電子カルテの導入を目指しています（出典: デジタル庁「健康・医療・介護」、2026年）。

導入時は、HL7 FHIR、SS-MIX2、DICOM、APIなどとの連携可能性と、データの持ち出しやすさを確認しておくと、将来の更改費用を抑えやすくなります。

医療機関向け電子カルテシステムの6段階の進め方

電子カルテの導入は6段階で進め、要件整理と選定から始めます。設計・開発とテストを経て、稼働と定着へ進みます。各段階に完了条件を定めておき、現場で使えることと、診療を止めないことを段階ごとに評価します。

フェーズ1：要件整理での現場業務の一覧化

代表者は、経営者、医師、看護師、薬剤師、検査技師、放射線技師から集めます。リハビリ職、医療事務、情報システム担当も加えます。そのうえで、現状業務を患者の流れに沿って描きます。

• 患者の流れ：受付から診療終了、入院から退院、検査依頼から結果確認、処方から会計まで
• 情報の所在：紙、Excel、既存システム、機器のどこに情報があるかの記録
• 業務上の課題：重複入力、後回しの入力、手書きや電話、診療科ごとの帳票
• 機能の優先順位：稼働日に必要な機能、3か月以内に追加する機能、将来検討する機能への振り分け
• 完了条件：業務フロー、機能・非機能要件、連携一覧、移行対象、優先順位、承認者を文書にまとめた状態

処方から会計までの流れも確かめ、月末や夜間に作業が集中する場面を記録しておきます。

フェーズ2：選定での同じ診療シナリオによる比較

選定の前にRFP（提案依頼書）を用意し、候補会社に同じ条件を示します。

RFPには、施設区分や病床数、診療科などの基本条件と、端末数、既存システム、医療機器などの既存環境を記載します。加えて、稼働日、患者数、移行範囲、予算上限、保守時間も書き込みます。

操作性は機能一覧では比べにくいため、実際の診療シナリオを示してデモを依頼します。

• 機能の対応範囲：標準機能、設定、API連携、個別開発のそれぞれの範囲
• 導入と保守：同規模の事例、夜間対応の体制
• 契約終了時：データ返却の形式と移行支援
• 保守と更新：障害時の連絡先、制度改定への更新

デモの診療シナリオとして、患者受付から診察、検査結果の確認までを一つの流れで指定します。

続けて、処方、会計、入院、退院文書も同じ流れに含めます。

評価は最安値だけで決めず、5年後までの業務負担と変更可能性も含めて行います。

フェーズ3：設計・開発での標準機能の活用

画面や帳票に加えて、患者ID、職種別権限、マスタを設計します。

設計の対象には、連携、監査ログ、バックアップ、障害時の手作業も含まれます。

• 診療録と看護記録：確定後の修正者と閲覧できる職種の決定
• 薬剤と検査結果：情報を連携するタイミングの決定
• アクセス権限：職種、所属、業務、患者との関係に応じた最小権限

まず標準パッケージに業務を合わせられるかを検討し、個別開発は安全性や診療継続に関わる領域に絞ります。

独自帳票が増えると、制度改定への対応や将来の更改費用が膨らみます。そのため、HL7 FHIRやDICOMなどの標準規格による連携を優先します。

データベースを独自形式だけに閉じないことも欠かせません。

AI音声入力や診療録要約は下書きとして扱い、医療者が確認する手順と、修正履歴、参照根拠、停止手段を設計します。

フェーズ4：テストでの実データに近い業務の再現

テストは、患者の一連の流れを通して行います。機能単位の確認に加えて、受付から診察、オーダー、検査結果までと、処方、会計、文書作成の連携を確かめます。

• 患者情報：同姓同名、保険資格の変更、アレルギー更新
• 障害と権限：検査結果の遅延、通信断、停電、権限のない閲覧の場面
• 訂正と重複：誤入力の訂正、二重登録
• 利用者受入：職種ごとの画面操作の時間、帳票なしでの判断、入力漏れの発見
• データ移行：氏名と患者ID、病名、処方、検査値、画像、文書の紐付けと表示順

合格の判定は医療者が行います。

未解決の課題は、重大度、暫定運用、修正期限、責任者を記録してから次へ進みます。

フェーズ5：稼働での切替手順と障害時運用の準備

本稼働前には、移行リハーサル、権限、端末・プリンター・バーコード機器、ネットワーク負荷を確認します。加えて、操作研修、問い合わせ窓口、切戻し条件を見ておきます。

切替当日は、旧システムの停止時刻と最終バックアップの担当者を決めます。

あわせて、当日の患者情報の記録先と、新システムへの反映時刻を定めます。

院内の意思決定者と、現場の一次対応者も明確にしておきます。「何かあればベンダーへ連絡する」という決め方では、院内の判断が抜けてしまいます。

稼働後の数日間は、ベンダーと院内担当者が現場の近くで問い合わせを受けます。

• 障害の分類：診療を止める重大障害、部門の不具合、操作質問
• 復旧対応：優先順位と復旧目標に沿った対応
• 代替手順：紙運用への切替、連絡手段、復旧後の再入力の訓練（通信断やサイバー攻撃時の判断遅れを防ぐ）

フェーズ6：定着での利用状況の測定と改善

導入後は、業務の改善を測ります。診療録の確定時間、患者一人あたりの入力回数、検査結果の確認漏れ、レセプト返戻を、導入前と比べます。

患者待ち時間、問い合わせ件数、障害からの復旧時間、紙帳票の利用量も指標になります。利用率だけを目標にすると、入力が増えるだけの場合があります。

月1回または四半期ごとに電子カルテ委員会を開き、現場から出た改善要望を分類します。

• 要望の分類：制度対応、安全性、時間短縮、経営分析、将来構想の区分
• 対応方法：設定変更、教育、追加開発のどれで解決するかの判断
• AI機能：誤生成の報告、医師の最終確認、利用ログ、患者情報の外部利用範囲の見直し

設定や教育で解決できる要望と追加開発を分けておくと、変更費用を抑えやすくなります。

2025年5月に本稼働した土佐病院では、旧システムのデータをすべては移しませんでした。患者基本情報や診療履歴などを移行し、院内で再作成する文書・情報とは分けて扱いました。必要なデータを絞り、費用対効果と作業負荷を見ながら役割を分けた事例です（出典: JBCC「土佐病院の挑戦――クラウドネイティブ電子カルテで切り拓く医療DX」、2025年本稼働事例）。

この考え方は、医療機関の規模を問わず、データ移行の方針を決める際の参考になります。

医療機関向け電子カルテシステムの費用相場と内訳

費用は、施設規模、病床数、部門数、端末数、機器連携、移行量で変わります。加えて、カスタマイズと保守時間によっても変わります。

病院向けの全国一律の公開相場は、まだ十分に整っていません。こうした中、厚生労働省は2026年度に、病院規模別の導入・運用費用と、オンプレミス型・クラウドネイティブ型のTCOを調査する事業を公募しています（出典: 厚生労働省「令和8年度地域医療基盤総合推進調査事業」、2026年）。

次の数値は、公開料金と類似システムからの推定を分けて示した、初期検討用のレンジです。

施設タイプ別の初期費用と月額の目安

電子カルテの初期費用と月額は施設の規模で異なるため、診療所から病院までタイプ別に比べます。

• 診療所のクラウド型：公開料金では、初期0〜150万円程度、月額1〜5万円程度が比較の基準
• 無床・有床診療所、小規模医療機関：予約・会計・院内連携・移行・研修を含め、初期100万〜800万円、月額または保守5万〜30万円程度を仮置き
• 中小病院：電子カルテ、医事、看護、検査、画像の連携を含め、初期500万〜3,000万円、月額または保守10万〜80万円程度が推定レンジ
• 中大規模病院：総合病院情報システムは初期3,000万円〜1億円超、年間保守は初期費用の10〜20％程度と試算

たとえばエムスリーデジカルは、初期費用0円、月額11,800円からと案内しています。プラン、レセコン連動、サポート、端末、周辺オプションによって、総額は変わります。

（出典: エムスリーデジカル公式サイト、2026年8月閲覧）

公開価格は診療所向けです。

病院の費用は全国標準ではなく、病床数や連携範囲に基づく試算です。

見積書で分けて確認する初期費用の内訳

初期費用の対象範囲と数量は、見積書で確かめます。「導入一式」とだけ記載された見積もりでは、内訳が分かりません。

• システム構築：ライセンス、要件定義、設定、画面・帳票開発、連携開発
• 研修と稼働支援：研修、稼働支援が含まれるかどうか
• 移行と機器：データ移行、端末、サーバー、ネットワーク、バックアップ、セキュリティ設定
• 周辺機器：プリンター、バーコード機器、回線二重化

旧データの変換や職種別の研修も、後から追加されやすい項目です。

端末台数と、PACSや検査機器との接続も、見積もりに含まれているかを確かめます。

ランニングコストには、クラウド利用料、保守、制度改定、監視、バックアップが含まれます。加えて、回線、端末更新、セキュリティ、ヘルプデスク、追加アカウントの費用も見込みます。

オンプレミス型では、機器更新、バックアップ媒体、パッチ、院内担当者の工数も計上します。

5年TCOは、初期費用と月額・保守60か月分に、端末、回線、移行を加えて算出します。

教育、追加開発、障害対応費も、5年TCOに含めます。

クラウドとオンプレミスのTCOと運用責任による比較

導入後の費用と運用の責任は、方式によって違いが出ます。そこで、クラウド型、オンプレミス型、スクラッチ開発を比べます。比べる範囲は、初期費用に加えて、月額・保守60か月分と、端末、回線、移行の費用までです。

• クラウド型：院内サーバーが不要で、機器購入や更新の負担を抑えやすい
• オンプレミス型：院内ネットワークや既存機器に合わせやすい
• 総費用：数年後の更新で、導入時との費用差が逆転する場合がある
• スクラッチ開発：初期1,000万円から数億円規模と推定され、保守責任も大きい。まずは標準パッケージと限定開発を検討する

クラウド型では、月額利用料、専用回線やVPN、接続冗長化、障害時運用を確認します。

契約面では、データ保管場所、委託先、契約終了時の返却も確かめます。

オンプレミス型では、冗長化、バックアップ、パッチ、監視、保守要員を自院か委託先が担います。

5年後は、サーバーや端末の更新、回線、災害復旧、制度改定、データ出力も見積もります。

見積もりを取る際のポイントとチェックリスト

同じ業務範囲と責任分界の前提で、見積もりを比べます。そのうえで、稼働後の管理、障害時の復旧、制度改定、データ移行の扱いを確認します。

見積書の前にそろえる要件と前提条件

相見積もりの前には、施設概要、患者数、診療科、病床数、職種、端末数を整理します。加えて、既存システム、接続機器、移行データ、稼働日、研修対象、サポート時間もまとめます。

RFPには、診療録、オーダリング、看護、検査、画像、薬剤の各機能を記載します。会計、予約、問診、オンライン資格確認、電子処方箋を対象に加えます。帳票と分析も含め、必須・希望・対象外に分けて書きます。

• 対応方法：標準機能、設定、連携、追加開発、運用での対応の区分
• 移行範囲：全量か直近分か、過去情報を参照用PDFにするかの決定
• 作業責任：対象項目、期間、品質検査、変換方法、病院とベンダーそれぞれの作業

移行する文書の範囲によって、工数と責任範囲が変わります。

複数社の同じ条件と診療シナリオによる比較

少なくとも3社程度に同じRFPを渡し、同じ診療シナリオでデモと見積もりを依頼します。

• 大手SIer：大規模な部門連携や長期運用の実績
• 医療IT専業：診療業務への適合度
• クラウド専業：短期導入や運用負担の軽さ

各社の強みは、傾向として捉えます。知名度よりも、自院に近い規模、診療科、移行条件の実績を確認します。

デモでは、受付、診療、オーダー、検査結果、処方、会計までのシナリオを試します。その際は、入力回数、画面遷移、検索速度、修正方法、アラートを見ます。

問い合わせ件数、担当者の継続性、夜間障害の連絡方法、制度改定の提供時期、ユーザー会や研修も聞きます。現地見学や導入先へのヒアリングで、提案と実運用の差も確かめます。

セキュリティとBCPの責任分界の文書確認

2026年6月、厚生労働省は「医療情報システムの安全管理に関するガイドライン」第7.0版を公表しました。また、医療機関・薬局向けのサイバーセキュリティ対策チェックリストも更新されました（出典: 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年）。

• 管理とアクセス：管理責任者、権限、不要アカウント、アクセスログ、接続元制限
• 防御と復旧：セキュリティパッチ、二要素認証、サイバー攻撃を想定したBCP

見積もりでは、MDS・SDSなどの開示、保管場所、暗号化、バックアップ世代、復旧目標、ログ保存期間を確認します。さらに、保守担当者のアクセス、リモートメンテナンス、脆弱性対応、インシデント報告期限を確かめます。

クラウド事業者、電子カルテベンダー、医療機関の担当範囲は、契約書と運用手順に記載します。厚生労働省のチェックリストも、保守契約の内外で責任分界を確認するよう示しています。

契約終了時のデータ返却と追加費用

更改時のデータ移行条件と、稼働後の追加費用は、次のように確認します。

• データ返却：標準形式での出力可否、費用、画像・文書の参照性、受け渡し期間
• 独自形式：他社への移行で、変換費用と再検証工数が発生する
• 追加費用：変更時の単価と承認手続き

更改時期は5年後や10年後を想定します。追加費用では、アカウント、端末、帳票、制度改定、連携先の単価を確かめます。加えて、再移行、現地・夜間休日対応、研修追加の単価も見ておきます。単価と承認手続きまで比べておくと、稼働後の予算超過を防げます。

よくある質問（FAQ）

施設規模や既存環境によって答えが変わるため、判断の軸とベンダーへの確認内容をまとめます。

電子カルテシステムの開発は何か月かかりますか？

診療所から大規模病院まで、導入期間は施設の規模や連携・移行の範囲で変わります。

• 診療所向けクラウド型：要件確認から稼働まで1〜3か月程度
• 無床・有床診療所、小規模医療機関：連携や移行を含めて2〜6か月程度
• 中小病院：6〜12か月程度
• 大規模病院：12〜24か月以上

診療科数、部門連携、移行、研修、リハーサルで変わるため、稼働日から逆算して要件整理を始めます。

クラウド型とオンプレミス型はどちらを選ぶべきですか？

方式は、施設の優先条件に照らして選びます。

• クラウド型：短期導入、複数拠点、サーバー更新負担の軽減を重視する施設が候補
• オンプレミス型：院内ネットワーク連携、特殊設備、通信障害時の院内運用、自院での大量データ管理を重視する施設が候補

オンプレミス型は保守とセキュリティの責任が増えます。そのため、5年TCO、診療継続、データ返却、標準規格対応の観点で両方式を比べます。初期費用だけで判断しないよう注意します。

紙カルテや旧システムのデータはすべて移行できますか？

移行できるかどうかと、費用対効果は分けて考えます。稼働後によく参照する患者基本情報、現病歴、病名、処方、検査値、会計などを優先します。

• 参照用データ：旧システム固有の帳票や、画像付きの文書を参照用にする
• 期間を限定：必要な期間だけ移行する
• 院内で再作成：必要な文書や情報の作り直し

対象期間、データ品質、変換方法、検証方法、作業分担を定めておきます。全量移行を前提にしないことが、現実的な進め方です。

AI音声入力や要約機能を電子カルテに組み込めますか？

組み込める可能性はありますが、判断の範囲と確認の手順を先に定める必要があります。

• 最終判断：診断や投薬などの最終判断を、AIに委ねないこと
• 下書きの確定：医療者が確認・修正して確定する、音声入力や要約
• 記録と情報管理：参照情報と生成日時、承認者、修正履歴を記録し、外部送信と学習利用、保存期間と削除方法を確認する

障害時の手動入力方法も、ベンダーへ確認してください。

セキュリティ要件はベンダーに何を聞けばよいですか？

厚生労働省の第7.0版ガイドラインと2026年版チェックリストを基準に、確認を進めます。

• 技術対策：権限、二要素認証、ログ、パッチ、バックアップと復旧、リモート保守
• 責任分界：医療機関、電子カルテベンダー、クラウド事業者、保守会社それぞれの担当の文書化

誰がいつ確認し、問題が起きたときに何分以内に連絡し、どの手順で診療を続けるかまで聞きます。

まとめ

医療機関向けの電子カルテは、要件整理から定着まで6段階に分けて進めます。

まず、診療所か病院か、無床か有床か、連携する部門を決めます。そのうえで、現場業務と既存データを一覧にします。標準機能、設定、連携、追加開発のどれで対応するかを切り分け、同じ診療シナリオで複数社を比べます。

発注前に確認する5つの判断基準

候補会社を比べるときは、次の5点を同じ基準で確認します。

• 導入実績：自院に近い規模・診療科の事例
• 連携性：患者情報と部門業務をつなげられるか
• 移行と検証：移行範囲とデータ確認方法
• 費用：5年TCOと追加費用
• 安全と継続：セキュリティ、BCP、終了時のデータ返却

デモでは、機能数よりも、入力のしやすさ、安全な参照、障害時の診療継続を確かめます。

現状業務とRFPのたたき台づくり

発注前の準備では、次の順に現状を整理し、候補会社へ相談します。

• 現状業務：各部門と患者の流れの整理、重複入力、紙運用、移行データ、連携機器の洗い出し
• RFPと会社選定：たたき台づくりと、同条件での3社程度への相談、機能、導入支援、責任分界の比較
• 導入範囲：医療DXや標準型電子カルテを見据えた、必要な範囲からの段階的な導入

この進め方が、現場に定着するシステム開発につながります。

▼全体ガイドの記事
・医療機関向け電子カルテシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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