パターン1: 問診の提出、院内の内容確認、同意書への署名の段階を区別できていない
Web問診を送信した時点では、院内で内容を確認したとは限りません。同意書も、文書を表示した、説明した、署名を得た、という各段階を分けて記録する必要があります。
状態が一つしかないと、当日に確認が必要な回答や、改訂後の文書への再同意を受付で判断できません。
来院前の問診、説明・同意の記録、施術メモ、経過写真、回数券、問い合わせ履歴を患者ごとに確認するWebシステムの構成例です。
患者別画面と院内管理画面を使い、問診・同意確認、施術記録、支払い、問い合わせ、備品・外注・点検を扱う5つの画面をご紹介します。
紙、共有フォルダ、メッセージ、担当者のメモに情報が分かれている場合は、前回の説明内容や次回の確認事項を探しやすくする画面を追加できます。電子カルテ、予約、POSレジ、会計はそのまま使用し、必要な情報だけを表示・連携する構成にも対応します。診断、施術の可否、医療上の説明や同意の有効性はシステムでは判断しません。
ここで挙げるシーンは、下の「ダッシュボード(管理画面)構成イメージ集」の各画面に対応しています。
Web問診を送信した時点では、院内で内容を確認したとは限りません。同意書も、文書を表示した、説明した、署名を得た、という各段階を分けて記録する必要があります。
状態が一つしかないと、当日に確認が必要な回答や、改訂後の文書への再同意を受付で判断できません。
施術メモ、経過写真、次回の候補を同じ欄へ書くと、実施済みの内容と今後の予定を読み分けなければなりません。
誰がいつ記録・修正したかも残らなければ、担当変更時にどの情報を基準にするか確認が必要になります。
回数券を使ったという受付メモと、POSレジや会計側の売上確定が別々に行われると、取消や返金の後に残数が合わなくなることがあります。
患者別画面へ表示する場合も、どのシステムの購入・利用・入金情報を正式な記録とするかを決めておく必要があります。
電話・メール・LINEなど窓口が複数あると、連絡を受けたことは分かっても、誰が対応するのか、患者からの返信を待っているのか、完了したのかが共有されない場合があります。
既存患者への紐付けを氏名だけで行うと別人の記録へ登録するおそれがあるため、本人確認の方法も必要です。
初回来院前に、問診フォーム、施術前の注意事項、同意書を案内します。ただし、患者が送信や署名をしただけで、院内確認や必要な説明まで完了したとは扱いません。
管理画面では、記入途中、提出済み、要確認、確認済みを分け、回答内容に応じて当日に確認する項目を受付と施術者が把握できるようにします。同意書は、提示した文書の版、説明日時・担当者、署名日時を記録し、内容を改訂した場合の再確認にも対応します。
画面イメージ:初回受け入れボード(問診・同意・注意事項)
画面構成イメージはPCからご覧ください。
患者別の画面に、施術日、担当者、実施内容、施術前後の所見、写真、次回確認事項を時系列で表示します。予定していた内容と実際に行った施術を別項目にし、修正した場合は変更者と日時も残します。
医療機関の診療録、整骨院の施術録など、法令や院内規程に基づく記録が別にある場合は、この画面を正式な記録にするのか、既存システムを参照する補助画面にするのかを先に決めます。写真についても、撮影目的、撮影日、対象部位、院内で閲覧できる職種を設定します。
画面イメージ:患者別の施術記録(メモ・写真・申し送り)
画面構成イメージはPCからご覧ください。
回数券の購入、利用、取消、返金と、物販の購入、支払い状況を患者別に表示します。利用を仮登録した段階と会計処理後の確定を分け、取消時には残数を自動で戻すなど、数字が変わる条件を明確にします。
POSレジや会計システムを利用している場合は、患者画面へ要約だけを表示する方法もあります。手書きの支払いメモで正式な売上・入金記録を上書きせず、会計側との不一致があるときは確認対象として表示します。
画面イメージ:チケット・物販・支払い(患者別の台帳)
画面構成イメージはPCからご覧ください。
電話、メール、LINEなどで受けた問い合わせを一件ずつ登録し、受付、担当決定、院内確認、患者への返信、返信待ち、完了までを記録します。受信しただけでは対応済みにせず、次に対応する担当者と期限を表示します。
既存患者へ結び付けるときは、氏名だけでなく登録済みの連絡先などで本人を確認します。連絡本文に症状や施術内容が含まれる場合は、通知画面へどこまで表示するか、LINEやメールの内容をシステムへ保存するかも院内ルールに合わせて決めます。
画面イメージ:問い合わせボックス(受付・対応・履歴)
画面構成イメージはPCからご覧ください。
備品の補充、外注先への依頼、設備点検、掲示物の更新など、患者ごとの記録に含まれない院内業務を一覧で管理します。発注依頼、発注済み、納品確認、外注作業の完了報告、院内での完了確認を段階ごとに記録します。
患者情報と院内業務を同じダッシュボードから開ける構成でも、データの保存先と閲覧権限は分けます。外注先のアカウントを設ける場合は、依頼された作業以外の院内情報や患者情報を表示しない設計が必要です。
画面イメージ:院内ToDo(備品・外注・点検)
画面構成イメージはPCからご覧ください。
問診、同意書、施術記録、写真、問い合わせ履歴を患者別に確認できるようにします。既存の電子カルテや予約システムに原本がある情報は、複製して別々に更新するのではなく、参照元と最終更新日時が分かるようにします。
問診の送信は内容確認ではなく、署名の取得だけで説明の記録が完成するわけでもありません。誰が次に確認するか、当日に追加説明が必要か、文書改訂後の再確認が必要かを状態として表示します。
実施した施術と次回の候補を同じ記述欄に混在させず、記録者と日時、修正履歴を残します。受付、施術者、管理者などの役割に応じて、症状・写真・支払い情報の閲覧範囲も決めます。
購入、利用、取消、返金によって残数や売上が変わります。POSレジ、会計、患者別画面のうち、どこで取引を確定するかを決め、ほかの画面はその情報を参照する構成にします。
備品、外注、点検は患者別の施術記録とは性質が異なります。同じダッシュボードへ入口を設ける場合でも、外注先を含む利用者ごとに必要な情報だけを表示します。
最初に、現在使用している予約、電子カルテ、POSレジ、会計、LINEなどを確認し、どの情報を新しい画面で管理するかを決めます。重複入力が発生する範囲や、既存システムから連携できない情報が分からないまま機能を増やすと、職員が確認する画面も増えてしまいます。
最初の開発範囲としては、次のような組み合わせが考えられます。
問い合わせ履歴、回数券・物販、院内業務は、それぞれ連絡手段や会計処理、外注先の権限に関する確認が必要です。初期範囲の運用を確認した後、必要な領域を追加する方法も選べます。
ご相談の際は、現在の記録方法と、新しい画面で扱いたい範囲が分かる資料をご用意いただくと、必要な機能を検討できます。
クリニック全体としての活用イメージは、 クリニック向けWebシステム活用アイデア でもご覧いただけます。
この業務で確認しておきたい点と、個別開発の進め方・費用・保守についてまとめています。
送信・受領と院内での確認を分ける構成です。問い合わせの担当者と期限も記録し、確認や返答が必要なものを追えるようにします。電子カルテなど既存の記録との役割分担は事前に確認します。
来院・写真の記録、回数券の残数、請求・未払いを分けて管理する構成です。利用者ごとに閲覧範囲を決め、来院したことと利用回数・支払いの確認を区別します。
はい。掲載画面は一例です。受付や進捗確認など、必要な部分から開発できます。現在の管理方法とお困りごとを伺い、画面構成をご提案します。初回相談と概略の構成案のご提案は無料です。Excelや帳票があれば参考にしますが、資料がなくてもご相談いただけます。
可能です。基幹システム、CRM、Excel、共有フォルダを残し、不足する機能を追加できます。正式なデータの保存先と更新担当・時点を決め、自動連携はAPIや出力機能を確認します。移行は項目の対応、重複・欠損、添付ファイルの状態を調べてお見積もりし、対象を限定する場合があります。公開後の機能追加にも対応できます。
認証、閲覧・更新権限、操作履歴、通信の暗号化、バックアップ、保存期間・削除方法、退職・契約終了時の利用停止を確認します。扱う情報、利用者、社外公開の有無、社内規程、サーバー環境に応じ、必要な対策と運用担当を設計時に決めます。
表示価格は「対象範囲例」を中心とした目安で、画面内の全ボタン・集計・通知・外部連携を含む価格ではありません。画面、項目、利用者、権限、通知、履歴などの対象範囲を見積書に記載します。複数シーンは共用機能と追加設計を確認し、初期開発費・月額保守費を算定するため、単純な合計にはなりません。
表示価格はすべて税別です。サーバー費用、外部API、ファイル保存、メール配信などの利用料は一律に含めていません。必要な費用を初期開発費・月額保守費と分け、正式なお見積もりで消費税を含む合計額をご案内します。
不具合の調査・修正、軽微な表示調整、利用環境・外部仕様の変更に伴う確認、運用相談などが対象例です。監視、バックアップ、セキュリティ更新、対応時間は構築先と重要度によって異なり、見積書・保守契約に範囲を明記します。画面や機能の追加は個別にお見積もりします。
必須ではありません。未契約でも調査・修正・機能追加を依頼ごとにお見積もりできます。ただし、優先対応、定期確認、対応時間の確保は月額契約と異なり、即時対応を保証するものではありません。扱う情報と業務への影響に応じて選べます。
原則として、現在の会社ドメインまたはサブドメインのサーバー内に構築します。PHP・データベース、容量、SSL、バックアップ、外部通信の制限などはこちらで事前確認するため、専門的な仕様を調べてから相談する必要はありません。安定運用が難しい環境では、必要条件と代替案をご案内します。
紙の問診票とWeb問診が併存している、施術記録と写真の保存先が異なる、回数券の残数確認に複数の台帳が必要になるなど、現在の運用を伺ったうえで画面構成をご提案します。既存システムを残す部分、新たに管理する部分、連携が必要な部分を確認し、開発範囲を検討できます。
受付、予約、顧客・案件管理、申請・承認など、必要な業務や機能に近いWebシステムの開発例をご紹介します。