病院情報システム（HIS）の開発は、要件整理から定着化まで6フェーズで進みます。なかでも製品と開発会社の選定は、連携費用や追加開発費を左右します。
段階ごとにテストと移行を確かめながら稼働させると、診療を続けたまま導入でき、導入後の定着にもつながります。
▼全体ガイドの記事
・病院情報システム（HIS）開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
病院情報システム（HIS）の全体像
病院情報システム（Hospital Information System、HIS）は、患者情報を起点に、診療、看護、部門業務、会計、経営管理をつなぐ情報基盤です。電子カルテはその中核機能の一つで、HISにはオーダリングや医事会計、部門システムも含まれます。
さらに、認証やネットワーク、バックアップ、データウェアハウスも含まれます。開発の初期には、製品を選ぶ前に対象業務とデータ、停止条件を定義しておきます。
電子カルテだけでなく診療から経営までの対象範囲
HISで扱う主な業務領域は、診療の現場から経営管理まで広がっています。
- 診療記録とオーダー：受付・予約・患者情報、診療録、看護記録を含みます。処方・注射・検査・放射線・病理・手術・麻酔・輸血・リハビリのオーダーも含めます。
- 会計と院内部門：医事会計・レセプト・DPCに加え、薬剤・給食・物品管理も対象にします。
- 院外連携と経営：PACSや検査機器との接続、地域連携、患者ポータル、電子処方箋、オンライン資格確認、病床稼働率・収益分析も候補になります。
医療安全の機能は、業務シナリオのなかで定義しておきます。アレルギーや重複投薬、禁忌について、誰がいつ確認するかを決めます。検査値の確認者と時点も、あわせて決めておきます。
また、操作履歴や訂正履歴、電子署名、承認ルートも、あらかじめ定義しておく必要があります。誤入力を防ぐ仕組みや緊急時の代替手段を欠くと、病院全体のリスクは高いままになります。
パッケージ・クラウド・スクラッチの違いと業務適合性
方式ごとに、業務との合い方と、導入後に担う運用を比べて選びます。
- パッケージ型：標準機能や法改正対応、保守体制を活用しやすい一方で、独自の運用を標準業務に寄せる判断が必要です。
- クラウド型：サーバー更新と保守の負担を抑えやすく、初期投資も平準化しやすい方式です。通信断時の診療継続、データの保管場所、復元手順、終了時の返却を確かめます。
- スクラッチ型：特殊な診療機能や独自業務も再現できる一方、品質管理や制度改正への対応、長期保守、セキュリティ対応を継続して担うことになります。
- 拡張範囲：標準パッケージを軸にして、安全や競争力に直結する部分を拡張すると、導入後の負債を抑えやすいケースが多いです。
病院情報システム（HIS）開発の進め方と6フェーズ
HIS開発は、要件定義だけでは終わらない、診療を止めずに業務を変える取り組みです。工程ごとに、意思決定者、現場代表、開発会社の責任を分けておく必要があります。
次の工程へ進む判定条件を置き、現場の利用者が要件整理とテストに参加する形にします。データ移行と障害時の運用は、本番の前に実証しておく必要があります。
フェーズ1：現状業務と将来像をそろえる要件整理
現状の把握から将来像の合意まで、要件整理で何をそろえるかを押さえておきます。
- 病院の現況：病床数、病棟・診療科、救急・手術機能、外来・入院業務量を押さえます。端末数、既存システム、契約更新日、連携機器も一覧にします。
- 業務フロー：受付から診療、オーダー、実施、会計、退院後の分析までを流れで描き、情報の発生場所、確認者、受け渡し先を示します。
- 要件の成果物：現状業務一覧、課題一覧、将来業務フロー、機能・非機能要件を作ります。連携一覧、移行対象データ一覧、概算スケジュールも作成します。
- 評価基準：各要件が医療安全、法令・制度対応、業務効率、経営の見える化のどれに効くかを、説明できるようにします。
現場ヒアリングには、医師、看護師、薬剤師、検査技師、放射線技師の代表を入れます。さらに、医事、経営、情報システムの代表も加えます。
フェーズ2：製品・開発会社の選定と実業務でのデモ評価
製品と開発会社は、同じ条件で集めた提案を、実務のシナリオに当てはめて評価します。
- RFPの条件：対象部門や利用者数、端末・モバイル環境、連携対象、データ形式を書き、複数社に同じ条件で提示します。
- RFPの盛り込み：可用性や復旧目標、認証、監査ログ、保守時間に加えて、教育、移行、契約終了時のデータ返却も含めます。
- デモの操作範囲：救急受付、入院指示、アレルギー確認、検査結果の参照を操作し、薬剤変更、退院サマリー、レセプト確認も同じデモで試してもらいます。
- 操作中の記録：入力回数、画面遷移、検索速度を記録し、アラートの妥当性、権限設定、障害時の代替操作も残します。
- 導入事例：自院と似た病床規模・診療機能のものを2〜3件示せるかを確かめます。製品名や画面の印象だけで比べると、連携費用や追加開発費が増えやすくなります。
フェーズ3：標準機能と追加開発の境界を決める設計・開発
標準機能と追加開発の線引きを決め、連携・移行・基盤の設計事項をそろえます。
- 設計範囲：基本、詳細、連携、データ移行、権限、インフラを設計します。独自の慣習をすべてカスタマイズで合わせることは避けます。
- 開発の区分：標準機能に業務を合わせる項目、設定対応、追加開発を分けます。追加開発には、安全上の理由や利用者、受入条件、保守方法を添えます。
- システム連携：標準規格への対応状況と、機器・システムごとの実装差を確かめます。
- ネットワーク：診療端末、無線LAN、認証基盤、バックアップ、外部接続を分けたうえで、ランサムウェアに侵入されても被害が広がらない構成を検討します。
規格は、HL7やFHIR、SS-MIX2、DICOMなどを確認します。そのうえで、連携エンジンやマスタ、コード変換を設計し、再送、エラー通知、障害時の手動登録も決めておきます。どこまでを誰が受け持つかも、文書にしておきます。
フェーズ4：機能・連携・移行・障害対応を実証するテスト
機能だけでなく、連携・移行・障害時の動きも、受入の前に実証しておきます。
- 段階テスト：単体、結合、総合、運用、受入の各テストを分けて行い、開発会社だけの機能テストで終わらせません。
- 異常時の確認：障害や通常時と異なる状況を想定して、テストも行います。
- 移行リハーサル：患者基本情報、病名、アレルギー、処方を対象にします。
- 移行条件：移行対象の期間、旧システムの参照期間、欠損・文字化けの判定方法、現場の確認者を決めておきます。
- 受入判定：重大障害の有無、未解決課題の許容数、性能目標、復旧時間、バックアップ復元の結果を基準にします。
移行リハーサルでは、検査結果、画像、文書なども含めて、抽出・変換・取込・照合を複数回行います。受入判定で不合格であれば、次の段階へは進みません。
機能、権限、連携、性能を確認し、セキュリティやバックアップ復元、災害時の代替運用も確かめます。さらに、検査結果の遅延や患者の重複登録、医事会計への未連携も試します。
フェーズ5：切替方式と診療継続の管理による稼働
診療を続けられるよう、切替の方法と本番前後の支援体制を固めておきます。
- 方式選定：一斉切替、段階切替、並行稼働から選びます。
- 切替当日の役割：作業責任者、ベンダーの指揮系統、各部門の判断者、障害時の連絡先を、書面で明確にします。
- 診療継続の準備：紙運用へ切り替える条件と、復旧・切り戻しの判定時刻を決めます。
- 研修と支援：医師、看護師、医事、薬剤、検査、管理者ごとに実務研修を行います。
方式の選定では、病院規模や診療科の依存関係、夜間・休日の運用、旧システム参照の要否に合わせます。本番前には、切替リハーサルも行います。研修と支援では、問い合わせ窓口や回答時間、現場支援要員、重大障害の連絡先を契約に含めます。
フェーズ6：利用状況の把握と改善を続ける定着化
稼働後も、利用状況と現場の負担を見ながら、運用を継続して改善します。
- 確認時期：稼働後の1か月、3か月、6か月といった節目で、状況を見直します。
- 利用状況：ログイン率、記録完了率、入力漏れ、アラート無視率を追います。問い合わせ件数、処理時間、レセプト返戻、病床稼働の見える化も見ます。
- 現場の評価：数字だけでなく、医療安全上のヒヤリハットや現場の負担感も聞き取ります。
- 改善管理：要望を緊急、法令・制度、安全、効率、将来構想に分けて、優先順位をつけます。追加開発が連携や更新を壊さないかも、あわせて確かめます。
- 継続体制：業務オーナーと情報システム担当を置きます。定例会では、KPI、障害、脆弱性、バックアップ復元、教育計画を見直します。
病院情報システム（HIS）の費用相場とコストの内訳
HISには全国一律の価格表がなく、病床数だけでは費用は決まりません。さらに、診療科や部門数、端末数、連携機器、移行データの量によっても、金額は変わります。
ネットワークや冗長化、教育、保守、カスタマイズの量でも変わります。厚生労働省は、2026年度に導入・運用費用と方式別のコストを調べる事業を設けています。
この事業の対象は、電子カルテの導入・運用費用と、オンプレミス型・クラウドネイティブ型の比較です。統計的な標準相場は、まだ整備の途上にあります（出典：厚生労働省「令和8年度 地域医療基盤総合推進調査事業」、2026年）。
病床規模別の初期費用と比較範囲のそろえ方
病床規模別の推定レンジと公開価格は、対象範囲をそろえてから比べる必要があります。
- 100〜200床：HIS一式で5,000万円〜2億円程度が目安です。
- 300〜500床：初期費用の目安は2億円〜8億円程度です。
- 500床以上・大学病院級：8億円〜15億円を超える場合も想定されます。
- AHISの公開料金：10台構成の基本料金は、月額24万5,850円（税込）からです。
病床規模別の額は、電子カルテ単体の公開価格ではありません。医事会計や部門システム、端末、ネットワークを含む、類似案件の推定レンジです。移行、教育、保守も含めた金額です。病院機能や連携数が違えば、対象範囲をそろえて比べる必要があります。
AHISの料金は、中小病院向けのクラウド電子カルテの価格です。端末は5台追加するごとに、月額1万1,000円が加算されます。
医事会計は別途必要です。初期設定やデータ移行、部門連携、オプションも、病院ごとの見積もりになります（出典：AHIS「料金プラン」、2025年改定後料金）。このため、HIS全体ではなく、本体機能の公開価格として扱います。
初期費用の内訳：ライセンス・連携・移行・教育
初期費用は項目ごとに分け、増減する条件まで見積書で確認します。
- システム構築：ソフトウェアのライセンス、導入設定、要件定義、設計・開発を、それぞれ別の項目にします。
- 機器と基盤：連携インターフェース、サーバーや端末、院内ネットワーク、認証、バックアップを、項目として分けて書きます。
- 導入作業：データ移行、テスト、研修、稼働立会いも、見積書で分けて記載してもらいます。
- 連携・移行費：接続本数、送受信の方向、データ項目、リアルタイム性、エラー処理で変わります。
- 教育費：集合研修のほか、教材、eラーニング、各部門のスーパーユーザー育成、稼働後の現場支援が含まれるかを確かめます。
連携・移行費は、抽出方式や旧データの品質、画像・文書の容量によっても金額が変わります。「導入一式」とだけ書かれた見積書では、どの条件で金額が増減するのかを判断できません。
ランニングコストと5〜10年TCOによる方式比較
5〜10年のTCOで比べるときは、利用料だけでなく、更新や運用の継続費用も含めて見ます。
- クラウド：初期投資は抑えやすい一方で、利用者数や端末数、オプション、連携料金が月額として積み上がります。
- オンプレミス：資産として管理しやすい反面、更新時の投資や保守要員、災害対策もTCOに含めて考えます。
運用費には、クラウド利用料または保守料と、制度改正・セキュリティ更新が含まれます。端末・ネットワークの更新、バックアップ、監視、ヘルプデスクも対象です。さらに、追加開発、教育、データセンター、回線も含まれます。
京都府立医科大学附属病院の公的調達では、総合医療情報システム開発業務の委託上限が15億4,770万円（税込）でした。この案件は、500床以上の実績などが参加条件となる特定機能病院向けのため、一般病院の相場にはそのまま当てはめられません。
京都府の案件は、長期の要件整理から構築、移行、教育、運用までを一体で予算化する規模感として参考になります（出典：京都府立医科大学附属病院公募資料、2025年）。
病院情報システム（HIS）の見積もりを取る際のポイント
見積を比べる際は、合計金額だけでなく、同じ範囲と品質条件で比べられるかを確かめます。そのうえで、業務範囲や連携、移行、テストの条件をそろえます。教育、保守、障害対応、契約期間も同じ条件にします。
見積には、含むものと含まないもの、前提条件、追加料金の単価を明記してもらいます。
RFPに書く業務・データ・非機能要件
RFPでは、業務、データ、非機能要件を具体的に書きます。1日あたりの外来数・入院数も示し、各社が同じ条件で提案できるようにします。
- 病院・利用条件：病床数、端末数、外来・入院数、病棟・診療科、手術・救急の有無を記載します。利用者ロール、既存製品、契約満了日も書いておきます。
- 接続・移行対象：検査機器やPACS、医事会計との接続、移行対象データ、旧システムの参照期間を記します。
- 非機能要件：稼働時間、レスポンス、同時接続数、計画停止、復旧目標を明示します。バックアップ保持、監査ログ、暗号化、脆弱性対応、サポート時間も書きます。
- 連携仕様：「HL7対応」「FHIR対応」といった表示だけでなく、データ項目、コード体系、送受信頻度、エラー処理を確かめます。
- 移行条件：対象件数、変換ルール、検証方法、責任者、再移行の条件を含めます。
条件を明記しておけば、提案金額と品質条件を比較しやすくなります。
複数社比較の観点：機能・体制・将来コスト
同じ比較表で、費用、品質、体制、将来の変更しやすさを評価します。
- 機能と費用：機能の有無、標準・設定・追加開発の区分、初期・月額・年額を並べます。連携・移行・教育の費用も並べます。
- 保守条件：保守範囲、制度改正への対応、障害対応時間、データ返却の条件を比べ、見積もりの前提をそろえます。
- 除外範囲：安い提案で、一部の部門や移行が対象外になっていないか、保守が平日の日中だけになっていないかを確かめます。
- 開発体制：医療システムの経験、類似病院での稼働実績、責任者の継続性、協力会社の範囲、24時間の障害対応体制を質問します。
- 将来の移行性：更新時にカスタマイズが壊れない仕組み、標準形式でのデータ返却、ベンダーを変えるときの引継ぎ資料を確かめます。
ベンダーへの依存を減らせる提案ほど、更新時に交渉力を保てます。
セキュリティ・BCP・責任分界の契約への落とし込み
セキュリティと事業継続の要件は、見積の段階で決め、契約と訓練に反映します。
- ガイドライン：国の指針と関連資料を確認し、その内容を安全要件に反映します。
- 基本対策：多要素認証、最小権限、監査ログ、暗号化、脆弱性管理を要件に含めます。
- クラウド：通信断時のローカル運用、データセンターの冗長化、サービスレベル、障害報告を確かめます。データの所在や委託先、バックアップ保持期間も確認します。
- オンプレミス：院内ネットワークの停止、認証基盤の障害、サーバー室の災害を想定して訓練します。判断者や復旧担当、紙運用へ移る条件も、そのなかで確かめます。
基本対策では、バックアップの隔離、復元テスト、教育、インシデント時の連絡経路も、あわせて要件に入れます。
厚生労働省の「医療情報システムの安全管理に関するガイドライン 第7.0版」は、2026年6月に改訂されました。同省は、医療機関・薬局向けのサイバーセキュリティ対策チェックリストと、サイバー攻撃を想定したBCP確認表も示しています（出典：厚生労働省、2026年）。
訓練の費用と回数も、契約に入れておきます。
病院情報システム（HIS）の進め方でよくある質問（FAQ）
HISの検討では、費用や製品だけでなく、既存データや現場の負担、クラウドの安全性、導入期間も相談されます。検討の初期によく出る質問に、判断の軸から答えます。
病院情報システム（HIS）の開発・導入には何か月かかりますか？
100〜200床のパッケージ・クラウド導入は12〜24か月、300〜500床は18〜30か月が目安です。大学病院級の刷新は、24〜36か月が目安です。
病床数だけでなく、部門数、連携本数、移行データ、教育、並行稼働の有無で変わります。短い計画では、要件整理や移行リハーサル、現場訓練、稼働後の支援を削っていないかを確かめます。
病院情報システム（HIS）はクラウドとオンプレミスのどちらがよいですか？
方式は、通信環境、診療継続の方針、運用要員、既存資産、予算の平準化、データ移行の方針から判断します。
- クラウドの利点：保守や更新の負担を抑えやすい方式です。
- 採用前の確認：通信断時の運用、SLA、データ返却、バックアップ復元が確認できない提案は、採用しないほうが安全です。
国も、電子カルテやレセコン、部門システムを一体化したクラウド型への刷新を検討しています（出典：デジタル庁「病院情報システム等の刷新に向けた協議会」、2026年）。
既存の電子カルテやPACSのデータは安全に移行できますか？
移行は可能ですが、対象データと品質を早い段階で確定することが欠かせません。抽出、変換、取込、照合のリハーサルを、複数回行う必要があります。
患者基本情報や病名に加えて、アレルギーや処方、検査結果を移行の対象にするかを決めます。画像や文書、監査情報についても、扱いを決めます。
旧システムの参照期間や、欠損・文字化けが見つかった場合の責任者は、契約で定めておきます。移行件数が多いほど、費用と期間は先に予算へ組み込んでおく必要があります。
HIS開発を失敗させないために最初に何を決めるべきですか？
最初に決めるのは、守るべき診療業務、停止を許容できる時間、医療安全上の必須要件、現場の意思決定者です。これに加えて、移行対象データや予算上限、稼働希望日も定めておきます。
病院側は、現状の業務を一覧にし、標準機能に合わせる業務と、追加開発する業務を分けます。
経営層だけで決めず、現場の代表がデモと受入テストに加わる体制を先に作っておきます。そうすると、稼働後の定着と追加費用の抑制にもつながります。
まとめ：6フェーズで現場と経営が判断するHIS開発
HIS開発は、要件整理から定着まで6フェーズで考えると、抜け漏れを確認しやすくなります。
各段階で、現場業務、医療安全、外部連携、データ移行を一緒に評価します。さらに、セキュリティや費用、将来の保守も合わせて評価すると、導入後の手戻りを抑えられます。
発注前の最終チェック項目
発注前は、見積書と契約書がそれぞれの項目に対応しているかを確かめます。
- 対象範囲：HISと電子カルテの対象、部門・機器・地域連携の接続範囲
- 開発・移行：標準機能と追加開発の境界、移行対象と検証方法
- テスト・切替：テストと受入基準、切替・切戻しと紙運用
- 支援・安全：教育と稼働後支援、多要素認証・ログ・バックアップ・復元テスト
- 費用・返却：月額を含む5〜10年TCOと、契約終了時のデータ返却
この5点が見積書と契約書に対応していれば、会社間の比較に使えます。
価格より診療を支える継続性で選ぶ基準
価格だけでなく、導入後の変化や障害に対応し続けられる基盤かどうかで判断します。
- 継続対応：制度改正や診療体制の変化、サイバー攻撃、機器更新、スタッフの入れ替わりに、対応し続けられるかを確かめます。
- 実績と可搬性：類似病院の稼働実績や障害時の支援、データの可搬性、標準化への対応を見て選びます。
- 共同管理：現場が使い続けられる仕組みを整え、病院と開発会社が要件整理から定着化まで共同で管理できる体制かどうかを見ます。
▼全体ガイドの記事
・病院情報システム（HIS）開発の完全ガイド
▼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を創業。