訪問看護システム開発の進め方/やり方/流れや方法/手法/工程/手順

訪問看護システム開発は、要件整理から定着まで6段階で順に進みます。業務を整理して要件に合う方式を選び、現場テストと段階導入を重ねると、請求と記録をつなげやすくなります。

▼全体ガイドの記事
・訪問看護システム開発の完全ガイド

訪問看護システム開発の全体像

業務基盤を中心に、利用者台帳、モバイル記録、計画書・報告書、請求を放射状に示した図。
一度の入力を記録や請求へつなぐ構成です。

訪問看護システムは、利用者台帳や訪問予定、モバイル記録をまとめる業務基盤です。計画書・報告書や請求、関係者連携も、同じ基盤の中で扱います。

電子カルテ単体で捉えると、必要な範囲を誤りやすくなります。そのため、訪問前から訪問中、訪問後、月次請求までの流れで評価します。

一度の入力を記録・帳票・請求へつなげる仕組み

現場では、まず利用者情報を登録して予定を組みます。訪問先でバイタルや処置内容を入力し、その後、記録書や報告書を整えて、月末に請求データを確認します。

二重入力は作業時間を増やし、転記ミスや記録漏れにもつながります。そのため、訪問実績の入力を計画書・報告書・請求の下書きに反映できるデータ構造にします。

利用者・現場・管理者・外部関係者の情報整理

利用者台帳には、基本情報や保険情報、主治医を登録します。家族や緊急連絡先、疾患やアレルギー、同意情報なども、同じ台帳に入れておきます。

看護師は、訪問先でスマートフォンやタブレットから入力します。一方で管理者は、訪問件数やキャンセル、稼働率を確認します。さらに、加算とスタッフの負荷も見ていきます。

医師やケアマネジャーと共有する場合は、閲覧できる人と情報を先に決めておく必要があります。そのうえで、保存期間と訂正履歴を残すかどうかも決めます。

ポイント

判断の目安は、訪問前から月次請求までを一つの流れとして扱えるかどうかです。記録、帳票、請求へ一度の入力が反映されるか、関係者ごとの情報の持ち方が合うかも、判断の分かれ目になります。

訪問看護システム開発の進め方

訪問看護システムのテスト観点として、現場業務、請求処理、品質と復旧を並べた図。
現場の操作から障害時の復旧まで確認範囲をそろえます。

請求担当と看護師に早くから参加してもらい、一訪問を予約から請求まで通して確認しておくと、導入後の手戻りを抑えやすくなります。開発は、現状の整理から利用の定着まで、次の6段階で進みます。

  1. 現状業務と目標を整理する
  2. 要件と総額を基準に製品・開発会社を選ぶ
  3. 優先機能から設計・開発する
  4. 現場・請求・障害の観点でテストする
  5. 請求月とバックアップ運用を見て稼働する
  6. 利用率と業務指標を90日間追う

各段階で現場と請求の一連の業務を確かめると、問題を次へ持ち越しにくくなります。順番に消化するだけでは不十分です。

フェーズ1:要件整理で現状業務と目標を定義

要件整理では、まず業務の現状と規模を押さえます。続けて、必要な条件と優先順位を明確にします。

  • 業務の流れ:訪問前から月次請求までを書き出す
  • 体制と規模:担当者、利用者数、拠点数などを整理する
  • 必要な条件:訪問対応、既存データ、外部連携の有無を確認する
  • 優先順位:必須、できれば欲しい、将来検討に分ける

紙帳票やExcel、個人メモに分かれた作業を洗い出します。電話やFAX、既存ソフトで行っている作業も対象です。次に、「誰が」「いつ」「何を入力し」「誰が確認するか」を表にしておきます。

利用者数や看護師数、拠点数は数値で記録し、緊急訪問や夜間対応は条件として残します。医療保険と介護保険の比率、既存データ量、外部連携も、数値か条件で書いておきます。優先して守るのは、請求の安全、訪問先での記録、個人情報保護です。

AIによる記録下書きや高度な経営分析は、台帳と保険判定が安定してから検討します。優先順位は、予算と納期を判断する際の基準にもなります。

フェーズ2:要件と総額で比べる製品・開発会社の選定

選定では、開発方式の適合性と現場での動作、導入後を含む総額を比べます。

  • 方式:SaaS、パッケージ、API連携、スクラッチから選ぶ
  • 業務適合:標準業務か、独自ルールや連携が必要かを見る
  • 実機デモ:訪問記録から請求確認まで操作する
  • 総額:月額以外の導入・運用費も含めて比べる

小規模で、標準業務に合わせられる場合は、法改正対応やバックアップを任せやすいSaaSが現実的です。一方で、複数法人の独自ルールや既存基幹との深い連携、独自の経営指標が重要なら、パッケージ連携や個別開発を検討します。

デモでは、看護師のタップ数や、通信が不安定な場所での動作を確かめます。訂正履歴と権限設定も、あわせて見ておきます。

見積もりには、端末や初期設定、研修、移行を含めます。追加拠点やAPI、サポート、解約時のデータ出力も対象にします。

フェーズ3:優先機能から段階的に進める設計・開発

設計・開発では、データ設計と現場での操作を決めます。加えて、段階導入の進め方とAIの利用範囲を定めます。

  • データ設計:利用者・訪問・記録・書類・請求・権限を定義する
  • モバイル操作:片手操作や圏外時の保存方式を決める
  • 段階導入:必要な機能から着手し、段階的に追加する
  • AIの範囲:医療判断や緊急度判断を自動で確定しない

モバイル画面では、文字サイズや入力候補、途中保存を現場で確認します。写真・音声メモや、訪問の開始・終了も、使いやすさを確かめます。

圏外のときは、端末に一時保存するか、完全オフラインを対象外としてエラーを出すかを決めます。まずは一拠点・一チームで、台帳と予定、モバイル記録を作ります。請求もそこに含め、その後に外部連携や複数拠点、経営分析を追加します。

計画書・報告書の下書きや訪問ルートの候補をAIに扱わせる場合は、Human-in-the-Loopを要件に入れます。

フェーズ4:現場・請求・障害の3方向で行うテスト

テストでは、現場業務、請求処理、復旧と安全性を確かめます。看護師には訪問記録、管理者には予定変更や緊急訪問を試してもらいます。請求担当には、医療保険・介護保険、加算、返戻・過誤を含む月次処理を確認してもらいます。

  • 現場業務:記録、予定変更、緊急訪問を試す
  • 請求処理:保険、加算、返戻・過誤を確認する
  • 品質と復旧:移行、権限、性能、障害対応を試す

受け入れ基準は、測れる条件にしておきます。たとえば、記録の完了時間や必須項目の検知、通信断後の重複登録を確かめます。職種別の閲覧範囲とバックアップからの復旧も、対象です。

個人情報を使うテストデータは匿名化し、本番データを安易にコピーしません。

フェーズ5:請求月とバックアップ運用を踏まえた稼働の判断

稼働時期、初回請求の準備、障害時の対応を決めておきます。本稼働日は、現場が使い、記録がそろい、最初の請求を安全に確認できる日とします。システムの完成日とは、分けて考えます。

  • 切り替え時期:請求月と業務負荷を見て選ぶ
  • 稼働の条件:必要な記録と初回請求を確認できる
  • 緊急時の備え:連絡先、役割、代替手段を決める

候補としては、請求締め直前を避け、月初や業務負荷が低い時期を選びます。旧システムや紙帳票の参照期間と、二重運用の日数も決めておきます。

稼働初日は、管理者や現場リーダー、請求担当、ベンダーの役割を明確にします。誰へ何分以内に連絡するか、紙や電話で業務を続けるかも、手順書に書いておきます。

端末の紛失や通信障害、ログイン不能、誤登録や請求データの不整合への対応も決めておきます。

厚生労働省は2026年6月に医療情報システム安全管理ガイドライン第7.0版を公表しています。契約前には、権限や監査ログ、暗号化を確かめます。バックアップや委託先管理、インシデント対応も、契約前の確認事項です(出典:厚生労働省「医療情報システムの安全管理に関するガイドライン第7.0版」、2026年)。

フェーズ6:利用率と業務指標を90日間追う定着

定着には研修と現場支援が必要です。導入後90日間は、利用状況と業務品質を続けて確かめます。

  • 研修と改善:質問を集め、入力の障害を見直す
  • 現場支援:各拠点に相談役を置き、管理者だけに頼らない形にする
  • 90日間の評価:導入前の実績と指標を比べる

職種別に、短い動画や手順書を用意します。入力されない理由は、画面の使いにくさ、通信環境、入力項目の多さに分けて考えます。そのうえで、理由に応じて設定変更と業務ルール変更を使い分けます。

入力完了率と記録時間、予定作成時間は毎月確認します。返戻・過誤や残業、ログイン率、問い合わせ件数も追います。目標値は、導入前の実績を基準に定めます。

入力時間が短くなっても、記録の質や請求精度が下がれば、成功とはいえません。そのため、速度と正確性、利用率を組み合わせて評価します。

ポイント

迷ったときは、要件に合う方式か、導入後を含む総額で選べるかで判断します。稼働は、現場テストと段階導入を経て、請求と記録がつながるかを見てから進めます。

訪問看護システム開発の費用相場とコストの内訳

費用は、既製クラウド、既存製品のカスタマイズ、独自開発のどれを選ぶかで変わります。公開料金と個別見積もり、初期費用、端末や回線などの運用費を分けて考えます。

ここに示す金額は、公開情報と類似業務システムの見積もり慣行をもとにした、予算検討用の目安です。訪問看護システム全体の公的な平均値とは異なります。

クラウド型の月額料金は公開価格で8,000円〜25,000円程度の幅

月額料金は、公開価格を起点に、利用量と追加費用を含めて比べます。

  • 課金方式:定額か、基本料金と従量料金の組み合わせか
  • 利用規模:開業直後と利用者増加後の負担を比べる
  • 追加費用:端末、拠点、移行、帳票などの費用

ナーシングネットプラスワンは月額8,000円から、カイポケ訪問看護は月額25,000円(税別)です。iBowは、基本料金と証明書費用、訪問件数などに応じた料金を組み合わせた形です(出典:各社公式料金ページ、2026年8月確認)。

公開価格を基準にしたSaaSの目安は、月額8,000円〜25,000円程度です。実際の額は、電子カルテや医療・介護レセプト、複数拠点を使うかどうかで変わります。端末や従量料金、追加サービスも、金額を左右します。

月額25,000円で訪問件数にかかわらず使える製品もあります。ただし、定額型でも、端末レンタルや回線、追加拠点は別料金になる場合があります。データ移行や特別な帳票にも、別料金がかかることがあるため、見積書で確認します。

月の訪問件数が少ない開業直後は、従量型が合う場合があります。一方で、利用者が増えると、定額型が有利になることもあります。

導入費は0円〜100万円程度の幅

導入費は、事業所の規模や支援範囲で変わります。端末や設定、研修、移行が費用になる場合があります。加えて、帳票調整や請求開始前の伴走支援も、費用に入ることがあります。

  • 1事業所・少人数・移行データ少:0円〜30万円程度が目安
  • 複数端末・研修・移行・個別設定込み:30万円〜100万円程度を見込む

金額は、公開料金と一般的な導入項目からの試算です。見積書の「一式」は、アカウント発行、マスタ登録、研修、移行に分けます。テスト支援や立ち会い、稼働後サポートも、内訳として確かめます。

含まれない作業は、自社の工数として見積もります。端末を月額で借りる場合は、36か月の総額と買い切り価格を比べます。さらに、故障交換や返却条件も確かめます。

独自開発は800万円〜3,000万円・6〜15か月程度の試算

独自開発の予算は、開発範囲と保守費、5年間の総保有コストを合わせて検討します。

  • 開発範囲:連携、制度対応、拠点数などで変わる
  • 初期費用と期間:800万円〜3,000万円、6〜15か月程度
  • 保守費:初期開発費の年15〜25%程度と仮置きする慣行もある
  • 総保有コスト:保守や運用費を含めて5年間で比べる

費用は、台帳と予定だけにするか、モバイルアプリや電子カルテまで含むかで変わります。また、医療・介護請求やオンライン資格確認、API、複数拠点、経営分析まで含めるかどうかでも変わります。モバイル、請求、連携、制度対応まで含む場合には、上に挙げた初期費用と期間を見込むことがあります。

この金額は、類似する医療・介護系の個別業務システムを基にした推定で、公表された相場ではありません。要件を仮置きした、予算検討用のレンジです。

保守や法改正対応、クラウド利用料は、毎年見込んでおきます。監視や障害対応、セキュリティ診断、端末更新、問い合わせ対応も、毎年の費用に入れます。

保守費の慣行は、契約内容や対応時間で変わります。保守を削ると、制度改定や障害時の業務継続が難しくなります。そのため、保守費も予算に含めます。

ポイント

費用は、既製クラウドか独自開発かで変わります。そのため、月額料金だけでなく、導入費と保守費を含めた総額で比べます。

訪問看護システムの見積もりを取る際のポイント

RFPに含める事業と移行、業務機能、非機能、端末と制度の4項目を示した図。
提案条件をそろえると開発会社ごとの差を見比べやすくなります。

見積もりの精度は、業務と条件をどれだけ明確に伝えるかで決まります。そこで、同じ前提で比べられるRFPを用意します。

機能だけでなく、現場シナリオや移行、セキュリティまで含めます。導入支援と保守も、RFPに入れておきます。作業の抜けや将来の追加費用を確認したうえで、金額を比べます。

RFPに入れる業務シナリオと非機能要件

RFPでは、同じ前提で提案を比べられるよう、業務と機能、非機能を整理します。モバイルや制度対応についても、あわせて記します。

  • 事業と移行:事業所や利用者の規模、既存環境を示す
  • 業務機能:入力から通知・請求までの流れを書く
  • 非機能:性能、安全、復旧、保管条件を定める
  • 端末と制度:現場環境と制度対応を確認する

事業所数や利用者数、職員数は、数値で記します。訪問件数や保険、営業時間、夜間対応の条件も書き添えます。既存システムや移行対象、連携先は、一覧にして示します。

機能要件は、緊急訪問の登録から担当者への通知、実績記録、請求反映までの流れで書きます。

非機能要件には、稼働時間、応答性能、バックアップ頻度を入れます。さらに、復旧目標や監査ログ、暗号化、多要素認証を含めます。権限や保管場所、障害時の連絡体制も、決めておきます。

端末やOS、画面の向きを確認します。圏外や紛失、電池切れにも備えます。写真や通知の扱いも、確かめておきます。

オンライン請求・資格確認は2024年6月に開始し、2024年12月2日から義務化が案内されています。そのため、2026年時点の製品対応、端末要件、経過措置を確かめます(出典:厚生労働省「オンライン資格確認について」「訪問看護レセプトの電子化」、2026年確認)。制度更新時の責任分担は、契約書に残します。

デモでの一訪問の操作確認

看護師に一件の訪問を操作してもらい、負担や連携の欠落を確かめます。利用者登録から訂正履歴の確認までを、次の7つの操作で順に試します。

  1. 利用者情報と保険情報を登録する
  2. 担当者と訪問枠を設定する
  3. 訪問先でバイタル・処置・写真・音声メモを入力する
  4. 途中保存し、通信断から復旧する
  5. 計画書・報告書への反映を確かめる
  6. 管理者の承認と請求データを確かめる
  7. 訂正履歴を見る

欠落や負担の大きい箇所が見つかれば、契約前に条件を修正できます。

無料トライアルがあれば、少なくとも一つの実業務サイクルを試します。看護師、管理者、請求担当が同じデータを使い、困った点を記録します。

サポートへの質問を通じて、回答時間や制度判断の相談範囲を見ます。操作以外の支援や障害時の窓口も、確認しておきます。これらは、料金表からは分からない比較の材料です。

契約前のデータ・保守・責任分担の確定

契約前には、納品や保守、データ、安全管理について、どこまでを誰が受け持つかを決めておきます。

  • 契約範囲:納品、検収、変更、研修、障害対応を確認する
  • データと継続:出力、消去、保守移管の条件を決める
  • 安全管理:自社運用と委託先の責任を明確にする

見積書と契約書では、納品物と検収条件、仕様変更、移行範囲を確認します。研修や問い合わせ、法改正対応も、書かれているかを見ます。障害復旧やバックアップ、解約時のデータ出力も、確かめておきます。

SaaSでは、画像・帳票を含むCSV出力と退会後の消去時期を確かめます。ベンダーのセキュリティ認証があっても、自社の運用は別に決めておきます。

独自開発では、ソースコードとクラウドアカウントの管理者を明確にします。ドメインやAPIキーについても、管理者を決めておきます。

保守会社を変更できる条件も決めておきます。職種別の権限や退職者の停止、端末ロックは、運用規程に盛り込みます。認証や監査ログ、遠隔消去、紙帳票の廃棄も、同じ規程に含めます。

開発会社には、委託先や再委託先、データの保管地域、インシデント時の初動と報告期限を尋ねます。

ポイント

見積もりは、同じ前提のRFPをもとに条件をそろえ、デモと契約条件もあわせて比べます。作業の抜けや将来の追加費用を確認したうえで、金額を判断材料にします。

よくある質問(FAQ)

発注前には、開発方法や費用、現場での使いやすさに疑問が生じがちです。よくある質問への答えを、順に示します。

訪問看護システムは既製品と独自開発のどちらがよいですか?

標準業務で早く導入したい場合は既製クラウド、独自ルールや深いシステム連携が重要なら独自開発が向いています。まず既製品のデモで業務を再現し、不足部分を設定やAPIで補えるか確認します。そのうえで、開発費と保守費を含めて判断します。

訪問看護システムの開発期間はどのくらいですか?

既製クラウドの初期設定は数日〜1か月程度です。さらに、データ移行や研修まで含めると、1〜3か月程度が目安です。

パッケージのカスタマイズは3〜9か月、スクラッチ開発は要件と連携範囲により6〜15か月程度を、検討の幅にします。請求開始日から逆算して、要件、移行、テスト、研修の期間を確保します。

訪問看護システムでオンライン請求や資格確認に対応できますか?

対応できるかどうかは、製品と契約プランによって異なります。確認するのは、訪問看護の医療保険請求とオンライン請求・資格確認のほか、端末要件、制度改定時の更新時期です。

厚生労働省は訪問看護のオンライン請求とオンライン資格確認を進めており、2026年にもステーション向け端末要件を更新しています。そのため、自社の対象範囲と経過措置を確認し、ベンダーの対応予定を書面で受け取ります(出典:厚生労働省、2026年)。

まとめ

訪問看護システム開発は、要件整理から定着までの6段階で進めます。一度入力した訪問情報を、記録や帳票、請求、経営管理へ再び使える状態を目指します。

比べるときは、月額料金や機能数に加えて、訪問先での入力や請求精度を、同じ条件で見ます。移行やサポート、セキュリティも含めて比べます。

最初の請求を安全に通せる最小機能での開始

新規開発で最初から全機能を実現しようとすると、予算と期間が膨らみ、現場の確認が追いつかなくなります。

まずは、台帳や訪問予定、モバイル記録を最小構成として先に検証します。計画・報告と請求も、その中に含めます。

その後、複数拠点や医師・家族との連携、経営分析、AI支援を追加します。RFPでは、必須機能と将来機能を分けたうえで、受け入れ基準を数字で定めます。

次の一歩は、現場を含む小さな検証と同条件の見積もり

発注前に、現場の操作から導入後の効果まで順に確かめます。

  1. シナリオを作る:看護師、管理者、請求担当を集め、一訪問を予約から請求まで記録する
  2. デモと見積もりを依頼する:そのシナリオで複数の製品・開発会社に依頼する
  3. 比較する:入力時間、請求反映、データ移行、障害対応、5年間の総額を比べる
  4. KPIも確認する:KPIまで合意できる相手を選ぶと、負担軽減と請求品質の改善につながります

▼全体ガイドの記事
・訪問看護システム開発の完全ガイド

会社紹介

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

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

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

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

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

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