医療業界のシステム開発の進め方/やり方/流れや方法/手法/工程/手順

医療業界のシステム開発は、診療業務・法令・個人情報・医療標準・既存システムとの連携の要件を整理し、現場と検証を重ねながら、要件定義から運用・保守まで段階的に進めます。

  • 要件の整理:診療業務、法令、個人情報、医療標準の観点から要件を洗い出す
  • 条件の定義:既存システムとの連携、品質、セキュリティの条件を決める
  • 計画の範囲:テストから移行、研修、運用改善までを計画に含める

▼全体ガイドの記事
・医療業界のシステム開発の完全ガイド

医療業界のシステム開発の概要

医療業界のシステムとは、医療機関の診療・業務を支えるITシステムの総称です。たとえば、電子カルテ・病院情報システム(HIS)・医事会計システム・医用画像管理システム(PACS)・調剤支援システムなどが含まれます。

独自に開発したりカスタマイズしたりする利点は、各医療機関のワークフローや診療科の特性に、完全に合わせたシステムを作れる点です。また、既存のORCA(日医標準レセプトソフト)や他システムとの連携も、自社の要件に合わせて組み立てられます。

医療システムは患者の生命・健康に直結するため、一般的なシステム開発以上に、品質・安全性・法令遵守が求められます。

医療業界のシステム開発の全体的な流れ

医療業界のシステム開発は、一般に次の工程で進みます。

  1. 要件定義
  2. 基本設計
  3. 詳細設計
  4. 開発・実装
  5. テスト
  6. リリース・移行
  7. 運用・保守

各工程で何を決めて何を作るのか、順に解説します。

ステップ1:要件定義

医療システムの要件定義で確認する業務フロー、法令、システム化、権限管理と監査ログを4枚のカードで示した図。
現場の業務から監査ログまでを要件に含めます。

現状の業務フローと診療ワークフローの整理

要件定義では、まず現状の業務フローを細かく整理します。外来受付・診察・処方・会計・入院管理など、診療プロセス全体を把握したうえで、どの部分をシステム化するかを明確にします。

ヒアリングは、医師・看護師・医事課担当者・薬剤師・システム管理者など、複数の職種を対象に行います。現場の運用と院内規定が食い違うケースも珍しくないため、両方を確かめる必要があります。

医療業界のシステム開発では、次の法令やガイドラインへの準拠が欠かせません。

  • 医療法:電子カルテの保存要件(5年保存など)
  • 個人情報保護法・医療情報の安全管理ガイドライン:患者情報の取り扱い、アクセス制御
  • 医薬品・医療機器等品質確保法(薬機法):医療機器としての届出が必要な場合
  • 厚生労働省「医療情報システムの安全管理に関するガイドライン」:電子カルテ等のセキュリティ要件

ポイント

迷ったときは、医師や看護師、医事課担当者など複数の職種から現場の運用を聞き、院内規定と突き合わせたうえで要件を決めてください。現場と規定が違う場合も、まずは運用の実態を確かめます。

システム化の要件定義

業務フローの整理が終わったら、発注側の担当者と開発会社が、システム化する範囲と要件を定めます。要件には、次のような機能や連携が含まれます。

  • 診療記録:SOAP形式などでの入力・表示
  • オーダリング機能:処方・処置・検査の各オーダー
  • 医療標準規格:HL7 FHIR、DICOMへの対応
  • ORCA:レセプトシステムとの連携
  • 医用画像システム:PACSとの連携

加えて、権限管理と監査ログについても、要件を決めておく必要があります。

  • アクセス権限:職種・診療科別の設定
  • ログの取得範囲:監査ログと操作ログ

ステップ2:基本設計

システム全体のアーキテクチャの決定

基本設計では、システム全体の構成を決めます。オンプレミス型・クラウド型・ハイブリッド型のどれを選ぶかは、院内のセキュリティポリシーや医療情報システムの安全管理ガイドラインに照らして検討します。

クラウドを使う場合は、医療情報を扱うための「3省2ガイドライン」(厚労省・総務省・経産省)への準拠も求められます。

データベース設計の基本方針

患者情報・診療記録・処方データ・検査結果などのデータ構造を設計します。医療情報は長期の保存が義務付けられているため、将来の拡張やデータ移行に対応できる設計が求められます。

HL7 FHIRを採用する場合は、FHIRのリソース仕様に沿ってデータモデルを検討する必要があります。

ポイント

構成の型で迷ったときは、院内の規定とセキュリティ上の条件を先に並べてから、型を選んでください。クラウドを使う場合は、3省2ガイドラインへの準拠も同じ並びで見ておきます。

UI/UXの基本方針

医師・看護師・医事課担当者それぞれの業務に合わせて、画面設計の基本方針を定めます。なかでも、診察中の入力負荷を最小化するUI設計は、現場への普及率に直結します。

ステップ3:詳細設計

画面設計・API設計

各画面の入力項目、入力チェック(バリデーション)、画面遷移などの仕様と、APIのインターフェース仕様を設計します。また、HL7 FHIR APIを採用する場合は、FHIRサーバーとのインターフェース仕様を先に定義します。

医療ロジック・業務ルールの設計

医療システムの中核となる業務ロジックは、次のような部分を詳細に設計します。

  • 処方ロジック:用量チェック、相互作用チェック、アレルギーチェック
  • 検査オーダー:結果の取り込みフロー
  • 診療記録の更新・修正:改ざん防止のルール
  • 請求計算:診療報酬の点数計算ロジック
  • ORCA連携:連携インターフェース

ステップ4:開発・実装

フロントエンド開発

受付画面、診察画面、処方入力画面、看護記録画面などのUI開発を行います。医師や看護師が素早く操作できるよう、キーボード操作やテンプレート機能、音声入力への対応も検討します。

バックエンド開発

バックエンドでは、診療ロジックや処方チェック、外部システムとの連携を実装します。HL7 FHIRに準拠したAPIにしておくと、将来ほかのシステムと連携する際に扱いやすくなります。

インフラ構築

医療情報を扱うシステムは、可用性やセキュリティへの要求が特に高くなります。

クラウド(AWS・Azure・GCP)を使う場合でも、暗号化、アクセス制御、監査ログといった医療情報向けのセキュリティ設定を徹底します。あわせて、バックアップと災害復旧(DR)の設計も欠かせません。

ステップ5:テスト

単体・結合、ユーザー受け入れ、セキュリティ、パフォーマンスのテストを示すパネル図。
機能の確認から利用環境の負荷確認までを並行して計画します。

単体テスト・結合テスト

各モジュールを個別に確かめる単体テストと、組み合わせて確かめる結合テストを実施します。処方チェックや診療報酬計算など、医療業務に直結する部分では、特に網羅的なテストが必要です。

ユーザー受け入れテスト(UAT)

実際の医師・看護師・医事課担当者にシステムを操作してもらい、診療の流れに沿って動くかを確かめます。そのうえで、本番に近い環境で実証テストを行い、現場からのフィードバックを集めます。

ポイント

処方チェックや診療報酬計算など、医療業務に直結する部分から優先してテストを組んでください。受け入れテストは、実際の医師や看護師に操作してもらう前提で計画します。

セキュリティテスト・パフォーマンステスト

患者情報を扱うシステムとして、脆弱性診断とペネトレーションテストを行います。さらに、外来が混み合う時期や入院患者が多い時期を想定した負荷テストも必要です。

ステップ6:リリース・移行

データ移行

既存システムから新システムへ、患者情報や診療記録を移行します。移行データの整合性確認は特に慎重に行い、移行前後のデータ検証を徹底します。

段階的リリース

一部の診療科や部門から段階的にリリースすれば、全診療科へ一斉に切り替える場合に比べて、リスクを抑えられます。そのうえで、旧システムとの並行運用の期間も計画します。

ポイント

迷ったときは、どの診療科から始めるかを、並行運用の期間も含めて現場と一緒に決めてください。一斉に切り替える場合の影響も、あわせて比べておきます。

利用者向けトレーニング

医師、看護師、医事課担当者のそれぞれに、操作の説明会を行います。特に電子カルテは医師の入力の負担が大きいため、診療科ごとのテンプレート設定を支援することも有効です。

ステップ7:運用・保守

継続的な改善

リリース後も、診療報酬改定(2年ごと)や院内規定の変更に合わせて、システムを更新し続けます。特に、診療報酬改定への対応は、多くの医療機関で欠かせない保守の項目です。

セキュリティ・法令対応

患者情報は、特に高い機密性が求められる情報です。そのため、定期的にセキュリティ診断を行い、医療情報システムの安全管理ガイドラインの改訂にも合わせて対応する必要があります。

医療業界のシステム開発を成功させるポイント

医療業界のシステム開発を中央に置き、現場のヒアリング、設計段階での標準・規制要件の組み込み、ORCAなどとの早期連携を注釈で示した図。
現場理解と設計時の検討が、連携の見通しを支えます。

医療現場のヒアリングの徹底

医師や看護師など現場担当者へのヒアリングが不十分だと、リリース後に「実際の診療フローに合わない」という問題が起きます。

医療標準・規制要件の設計段階での組み込み

HL7 FHIR対応、セキュリティ要件、法令遵守は、後から追加すると大幅なコスト増につながります。このため、要件定義の段階から設計に組み込むことが重要です。

ポイント

迷ったときは、現場の診療フローに合っているかを、医療標準と法令への対応を含めて要件の段階で確かめてください。連携先は、どの診療科の業務で使うかまで並べておくと判断しやすくなります。

ORCA・既存システムとの連携の早期検討

ORCAや既存PACSとの連携は技術的に複雑です。そのため、要件定義の段階から連携方式を確認し、開発工数を見積もることが大切です。

まとめ

医療業界のシステム開発では、要件定義から運用・保守までの各工程を丁寧に進めることが、成功の鍵になります。特に、医療法や個人情報保護法への対応、HL7/FHIRなどの医療標準への準拠、ORCAなど既存システムとの連携設計は、長く使い続けられるシステムを実現するうえで欠かせません。

開発会社に依頼するときは、医療業界でのシステム開発の実績や、医療情報ガイドラインへの対応経験が豊富なベンダーを選ぶことをおすすめします。

▼関連記事

会社紹介

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

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

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

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

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

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