病院情報システム(HIS)の開発は、電子カルテを導入するだけではなく、医事会計、検査、放射線、薬剤、看護、PACS、経営分析までを一つの診療業務としてつなぐプロジェクトです。成功のポイントは、要件整理から定着化までを6つのフェーズに分け、医療安全・連携・データ移行・事業継続を費用と同じ重さで判断することです。
本記事では、病院情報システム(HIS)開発の進め方を、要件整理、製品・開発会社の選定、設計・開発、テスト、稼働、定着の順に解説します。100〜200床、300〜500床、大学病院級で変わる費用の見方、RFPに入れる項目、見積書の比較方法、現場が使い続けるためのチェックポイントまで、発注者が実務で使える形に整理しています。
▼全体ガイドの記事
・病院情報システム(HIS)開発の完全ガイド
病院情報システム(HIS)とは何ですか?全体像を先に整理します

病院情報システム(Hospital Information System、HIS)は、患者情報を起点に診療、看護、部門業務、会計、経営管理を連携させる情報基盤です。電子カルテはHISの中核機能の一つですが、HIS全体にはオーダリング、医事会計、部門システム、認証、ネットワーク、バックアップ、データウェアハウスなども含まれます。したがって、開発の初期から「どの製品を入れるか」ではなく「どの業務とデータを、どの停止条件でつなぐか」を定義する必要があります。
電子カルテだけでなく診療から経営までを対象にします
対象範囲は、受付・予約・患者基本情報、医師の診療録、看護記録、処方・注射・検査・放射線・病理・手術・麻酔・輸血・リハビリのオーダー、医事会計・レセプト・DPC、薬剤・給食・物品管理まで広がります。さらに、PACSや検査機器との連携、地域連携、患者ポータル、電子処方箋、オンライン資格確認、病床稼働率や収益の分析も要件に含める場合があります。
医療安全に関わる機能も、機能一覧の端に置いてはいけません。アレルギー、重複投薬、禁忌、検査値の確認、操作履歴、訂正履歴、電子署名、承認ルートを誰がいつ確認するのかまで業務シナリオで定義します。画面が便利でも、誤入力の防止や緊急時の代替手段が不足していれば、病院全体のリスクが下がらないためです。
パッケージ・クラウド・スクラッチの違いを業務適合性で見ます
パッケージ型は、医療現場で使われる標準機能、法改正対応、保守体制を活用しやすい方式です。一方で、独自運用を標準業務へ寄せる判断が必要です。クラウド型はサーバー更新や保守の負担を抑えやすく、初期投資を平準化しやすい反面、通信断時の診療継続、データの保管場所、復元手順、サービス終了時のデータ返却を確認する必要があります。
スクラッチ型は、特殊な診療機能や病院独自の業務を細かく再現できますが、医療ドメインの品質管理、制度改正、長期保守、セキュリティ対応を発注者と開発会社が継続的に担います。全面スクラッチを前提にするより、標準パッケージを軸に、医療安全や競争力に直結する部分だけを拡張する方が、導入後の負債を抑えやすいケースが多いです。
病院情報システム(HIS)開発の進め方を6フェーズで解説します

HIS開発は、要件定義だけで完了するIT導入ではありません。診療を止めずに業務を変えるため、フェーズごとに意思決定者、現場代表、開発会社の責任を切り分け、次の工程へ進む判定条件を置きます。特に、現場で使う人が要件整理とテストに参加し、データ移行と障害時運用を本番前に実証することが重要です。
フェーズ1:要件整理で現状業務と将来像をそろえます
最初に、病床数、病棟・診療科、救急や手術などの病院機能、外来・入院の業務量、端末数、既存システム、契約更新日、連携する機器を一覧化します。部門ごとに業務フローを描き、受付から診療、オーダー、実施、会計、退院後の分析まで、情報がどこで生まれ、誰が確認し、どこへ渡るかを整理します。
成果物は、現状業務一覧、課題一覧、将来業務フロー、機能要件、非機能要件、連携一覧、移行対象データ一覧、概算スケジュールです。判断基準は「要望を何件書いたか」ではなく、医療安全、法令・制度対応、業務効率、経営可視化のどれに効く要件かを説明できることです。現場ヒアリングには医師、看護師、薬剤師、検査技師、放射線技師、医事、経営、情報システムの代表を入れます。
フェーズ2:製品・開発会社を選定し、デモを実業務で評価します
要件をRFPにまとめ、複数社へ同じ条件で提示します。RFPには、対象部門、利用者数、端末・モバイル環境、連携対象、データ形式、可用性、復旧目標、認証、監査ログ、保守時間、教育、移行、契約終了時のデータ返却までを書きます。製品名や画面の印象だけを比較すると、後から連携費用や追加開発費が増えやすいためです。
デモは説明会ではなく、実際のシナリオで実施します。たとえば、救急患者の受付、入院指示、アレルギー確認、検査結果の参照、薬剤の変更、退院サマリー、レセプト確認を一連で操作してもらいます。入力回数、画面遷移、検索速度、アラートの妥当性、権限設定、障害時の代替操作を記録し、自院と似た病床規模・診療機能の導入事例を2〜3件提示できるかも確認します。
フェーズ3:設計・開発で標準機能と追加開発の境界を決めます
選定後は、基本設計、詳細設計、連携設計、データ移行設計、権限設計、インフラ設計を進めます。ここで重要なのは、病院独自の慣習をすべてカスタマイズしないことです。標準機能に業務を合わせる項目、設定で対応する項目、追加開発する項目を分け、追加開発には医療安全上の理由、利用者、受入条件、将来の保守方法を添えます。
連携は、HL7、FHIR、SS-MIX2、DICOMなどの標準規格に対応できるかだけでなく、各機器・システムの実装差まで確認します。連携エンジン、マスタ、コード変換、再送、エラー通知、障害時の手動登録を設計し、責任分界を文書化します。ネットワークでは、診療端末、無線LAN、認証基盤、バックアップ、外部接続を分け、ランサムウェア侵入時に被害を広げない構成を検討します。
フェーズ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円(税込)からで、端末を5台追加するごとに月額1万1,000円が加算されます。ただし医事会計は別途必要で、初期設定、データ移行、部門連携、オプションは病院ごとの見積もりです(出典: AHIS「料金プラン」、2025年改定後料金)。これはHIS全体ではなく、本体機能の公開価格として扱います。
初期費用はライセンス・連携・移行・教育に分けて確認します
初期費用の見積書では、ソフトウェアライセンス、導入設定、要件定義、設計・開発、連携インターフェース、サーバーや端末、院内ネットワーク、認証、バックアップ、データ移行、テスト、研修、稼働立会いを分けて記載してもらいます。「導入一式」の一行だけでは、どの条件で金額が増減するのか判断できないためです。
連携費用は、相手システムごとの接続本数、送受信方向、データ項目、リアルタイム性、エラー処理で変わります。移行費用は、抽出方式、旧システムのデータ品質、画像・文書の容量、移行対象期間、照合作業の回数に左右されます。教育費用も、集合研修だけでなく、教材、eラーニング、各部門のスーパーユーザー育成、稼働後の現場支援を含めるかで差が出ます。
ランニングコストと5〜10年TCOで方式を比較します
ランニングコストには、クラウド利用料または保守料、制度改正対応、セキュリティ更新、端末・ネットワーク更新、バックアップ、監視、ヘルプデスク、追加開発、教育、データセンターや回線が含まれます。クラウドは初期投資を抑えやすい一方、月額の利用者数・端末数・オプション・連携料金が積み上がります。オンプレミスは資産として管理しやすい反面、更新時のまとまった投資、保守要員、災害対策をTCOに入れる必要があります。
大学病院級の公的調達では、京都府立医科大学附属病院の総合医療情報システム開発業務で委託上限15億4,770万円(税込)が示された事例があります。500床以上の実績などが参加条件となる特定機能病院向けの案件であり、一般病院の相場にそのまま適用できませんが、長期の要件整理・構築・移行・教育・運用を一体で予算化する際の規模感として参考になります(出典: 京都府立医科大学附属病院公募資料、2025年)。
病院情報システム(HIS)の見積もりを取る際のポイント

HISの見積比較では、合計金額の安さだけでなく、同じスコープ・同じ品質条件で比較できているかを確認します。見積依頼の段階で業務範囲、連携、移行、テスト、教育、保守、障害対応、契約期間をそろえ、含むもの・含まないもの・前提条件・追加料金の単価を明記してもらいます。
RFPには業務・データ・非機能要件を具体的に書きます
RFPには、病床数や端末数だけでなく、1日あたりの外来数・入院数、病棟や診療科、手術・救急の有無、利用者ロール、既存製品と契約満了日、接続する検査機器・PACS・医事会計、移行対象データ、旧システムの参照期間を記載します。非機能要件では、稼働時間、レスポンス、同時接続数、計画停止、復旧目標、バックアップ保持、監査ログ、暗号化、脆弱性対応、サポート時間を明示します。
標準規格への対応も、単に「HL7対応」「FHIR対応」と書くだけでは不十分です。どのデータ項目を、どのコード体系で、どの頻度に、どのエラー処理で送受信するのかを確認します。移行については、移行対象件数、変換ルール、検証方法、責任者、再移行の条件までRFPに入れると、提案金額と品質条件を比較しやすくなります。
複数社比較では機能・体制・将来コストを同じ表で確認します
比較表は、機能の有無だけでなく、標準・設定・追加開発の区分、初期費用、月額・年額、連携費用、移行費用、教育費用、保守範囲、制度改正時の対応、障害時の対応時間、データ返却条件を並べます。提案書の美しさより、見積書の前提が揃っているかを重視します。安い提案が一部の部門や移行を対象外にしていないか、保守が平日日中だけになっていないかも確認します。
開発会社には、担当者の医療システム経験、類似病院の稼働実績、プロジェクト責任者の継続性、協力会社の範囲、24時間障害対応の実施体制を質問します。さらに、標準機能のアップデートで過去のカスタマイズが壊れない仕組み、契約終了時にデータを標準形式で返却できる仕組み、ベンダー変更時の引継ぎ資料を確認します。ベンダー依存を減らせる提案ほど、更新時の交渉力を保ちやすいです。
セキュリティ・BCP・責任分界を契約に落とし込みます
セキュリティは、導入後に別途検討する項目ではありません。厚生労働省の「医療情報システムの安全管理に関するガイドライン 第7.0版」は2026年6月に改訂され、医療機関・薬局向けのサイバーセキュリティ対策チェックリストや、サイバー攻撃を想定したBCP確認表も示しています(出典: 厚生労働省、2026年)。見積段階から、多要素認証、最小権限、監査ログ、暗号化、脆弱性管理、バックアップの隔離、復元テスト、教育、インシデント時の連絡経路を要件に含めます。
クラウドを選ぶ場合は、通信断時のローカル運用、データセンターの冗長化、サービスレベル、障害時の報告、データの所在と委託先、バックアップの保持期間を確認します。オンプレミスでも、院内ネットワークの停止、認証基盤の障害、サーバー室の災害を想定します。誰が判断し、誰が復旧し、どの時点で紙運用へ移行するのかを訓練し、その費用と回数を契約に含めることが安全です。
病院情報システム(HIS)の進め方でよくある質問(FAQ)

HISの導入では、費用や製品の質問だけでなく、既存データ、現場の負担、クラウドの安全性、導入期間に関する相談が多くなります。ここでは、検討初期に特に確認したい質問へ、判断の軸を先に回答します。
病院情報システム(HIS)の開発・導入には何か月かかりますか?
目安は、100〜200床のパッケージ・クラウド導入で12〜24か月、300〜500床で18〜30か月、大学病院級の刷新で24〜36か月です。病床数だけでなく、部門数、連携本数、移行データ、教育、並行稼働の有無で変わります。短い計画を提示された場合は、要件整理、移行リハーサル、現場訓練、稼働後支援を削っていないかを確認します。
病院情報システム(HIS)はクラウドとオンプレミスのどちらがよいですか?
どちらが一律に優れるわけではなく、病院の通信環境、診療継続方針、運用要員、既存資産、予算の平準化、データ移行方針で決めます。クラウドは保守・更新の負担を抑えやすく、国も電子カルテ、レセコン、部門システムを一体化したクラウド型への刷新を検討しています(出典: デジタル庁「病院情報システム等の刷新に向けた協議会」、2026年)。ただし、通信断時の運用、SLA、データ返却、バックアップ復元を確認できない提案は採用しないことが安全です。
既存の電子カルテやPACSのデータは安全に移行できますか?
移行できますが、対象データと品質を早い段階で確定し、抽出・変換・取込・照合のリハーサルを複数回行う必要があります。患者基本情報や病名だけでなく、アレルギー、処方、検査結果、画像、文書、監査情報を対象にするかを決め、旧システムを参照できる期間と、欠損・文字化けが見つかった場合の責任者を契約で定めます。移行件数が多いほど、費用と期間を予算に先に組み込むことが重要です。
HIS開発を失敗させないために最初に何を決めるべきですか?
最初に、病院として守るべき診療業務、停止許容時間、医療安全上の必須要件、現場の意思決定者、移行対象データ、予算の上限、稼働希望日を決めます。そのうえで、現状業務を可視化し、標準機能に合わせる業務と追加開発する業務を分けます。経営層だけで決めず、現場代表がデモと受入テストに参加できる体制を先に作ることが、稼働後の利用定着と追加費用の抑制につながります。
まとめ:HIS開発は6フェーズを通じて現場と経営で判断します

病院情報システム(HIS)の進め方は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで考えると、抜け漏れを確認しやすくなります。各段階で、現場業務、医療安全、外部連携、データ移行、セキュリティ、費用、将来の保守を一緒に評価することが、導入後の手戻りを抑える基本です。
発注前に確認する最終チェック項目です
発注前は、(1)HISと電子カルテの対象範囲、(2)部門・機器・地域連携の接続範囲、(3)標準機能と追加開発の境界、(4)移行対象と検証方法、(5)テストと受入基準、(6)切替・切戻しと紙運用、(7)教育・稼働後支援、(8)多要素認証・ログ・バックアップ・復元テスト、(9)月額を含む5〜10年TCO、(10)契約終了時のデータ返却を確認します。この10項目が見積書と契約書に対応していれば、会社間の比較がしやすくなります。
価格だけでなく診療を支える継続性で決めます
HISは一度導入して終わるシステムではなく、制度改正、診療体制の変化、サイバー攻撃、機器更新、スタッフの入れ替わりに対応し続ける基盤です。最安値の提案ではなく、自院と似た病院での稼働実績、障害時の支援、データの可搬性、標準化への対応、現場が使い続ける仕組みまで含めて選びます。要件整理から定着化までを病院側と開発会社が共同で管理できることが、長期的に価値を生む選定条件です。
▼全体ガイドの記事
・病院情報システム(HIS)開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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