# MediCue プロダクト仕様書 ## 1. 文書概要 本書は、個人クリニック向け予約管理SaaS「MediCue」のプロダクト仕様を整理したものです。 MediCueは、予約受付、リマインド、事前問診、キャンセル対策を一体化し、来院前後の患者対応をやさしく効率化することを目的とします。 本仕様書は、デモSaaSとしての実装範囲、将来的な拡張余地、運用上の前提条件を明確にするために作成します。 記載する数値、利用量、時間、比率などは、現時点では合理的な推定値であり、実運用前に検証が必要です。 推定値には原則として「[要検証]」を付記します。 ## 2. プロダクト概要 MediCueは、個人クリニックにおける予約管理と来院準備業務を支援するWebベースのSaaSです。 対象となる業務は、患者からの予約受付、予約変更、キャンセル受付、来院前リマインド、事前問診の回収、院内スタッフへの情報共有です。 従来、これらの業務は電話、紙、口頭確認、表計算ソフト、既存レセコン周辺の手作業によって分断されがちです。 MediCueは、患者接点と院内業務を一つの流れとして整理し、受付・看護・医師が同じ予約情報を参照できる状態を目指します。 本プロダクトは、診療そのものを代替するものではありません。 医療判断、診断、処方、緊急時対応は、引き続き医療機関の責任範囲とします。 ## 3. ターゲットユーザー 主な利用者は、予約管理やキャンセル対応、問診回収に課題を持つ個人クリニックの院長および受付責任者です。 院長は、診療前の情報整理、無断キャンセルの抑制、院内スタッフの負荷軽減を重視します。 受付責任者は、電話対応件数の削減、予約枠の見える化、患者への案内漏れ防止を重視します。 看護師や診療補助スタッフは、来院前問診の確認、初診・再診の準備、検査前の注意事項確認に利用します。 患者は、スマートフォンから予約、問診回答、予約確認、キャンセル、来院前案内の確認を行います。 ## 4. 想定利用シーン 初診患者がクリニックのWebサイトから診療科目と希望日時を選び、予約を確定します。 患者は予約完了後、SMSまたはメールで確認通知を受け取ります。 来院前に、患者はオンライン問診フォームへ回答します。 受付スタッフは、当日の予約一覧から問診回答済みの患者を確認します。 来院予定時刻の前日または数時間前に、患者へ自動リマインドを送信します。 患者がキャンセルする場合は、通知内リンクからキャンセル手続きを行います。 キャンセルされた枠は、必要に応じて再予約可能枠として公開されます。 ## 5. スコープ 本デモ版では、個人クリニック1院での利用を主な前提とします。 複数院展開、複雑な権限階層、電子カルテとの深い双方向連携は、初期スコープ外とします。 ただし、将来的な拡張を妨げないよう、テナント単位のデータ分離とAPI設計は考慮します。 患者向け画面は、スマートフォン利用を第一に設計します。 スタッフ向け画面は、PCブラウザでの利用を第一に設計します。 ## 6. 機能一覧 ### 6.1 予約受付機能 - 患者が診療メニューを選択できること。 - 患者が予約可能な日時をカレンダー形式で確認できること。 - 患者が氏名、電話番号、生年月日、初診・再診区分を入力できること。 - 患者が予約内容を確認して確定できること。 - 予約確定後、患者へ確認通知を送信できること。 - 受付スタッフが手動で予約を登録できること。 - 受付スタッフが電話予約を代理入力できること。 - 予約枠ごとに所要時間を設定できること。 - 診療メニューごとに予約可能な曜日と時間帯を設定できること。 - 予約の重複登録を防止できること。 ### 6.2 予約変更・キャンセル機能 - 患者が予約確認リンクから予約内容を確認できること。 - 患者がクリニック設定に基づき予約をキャンセルできること。 - 患者がキャンセル理由を選択または入力できること。 - 受付スタッフが管理画面から予約日時を変更できること。 - 予約変更時に患者へ通知を送信できること。 - キャンセルされた予約枠を自動的に空き枠へ戻せること。 - 直前キャンセルの集計ができること。 - 無断キャンセルを予約ステータスとして記録できること。 ### 6.3 リマインド機能 - 予約前日にSMSまたはメールでリマインドを送信できること。 - 予約当日の指定時間前にリマインドを送信できること。 - 送信タイミングはクリニック単位で設定できること。 - 初診患者と再診患者で通知文面を分けられること。 - 診療メニューごとに持ち物や注意事項を差し込めること。 - 通知送信の成否をログとして確認できること。 - 送信失敗時にスタッフへ管理画面上で警告を表示できること。 - SMS利用量を月次で集計できること。 ### 6.4 事前問診機能 - 診療メニューごとに問診フォームを設定できること。 - 患者がスマートフォンで問診へ回答できること。 - 問診回答は予約情報に紐づけて保存できること。 - 必須項目と任意項目を設定できること。 - 単一選択、複数選択、自由記述、日付入力に対応できること。 - 既往歴、服薬状況、アレルギー、妊娠可能性などの標準項目を用意できること。 - 回答完了状況を予約一覧で確認できること。 - 回答内容をスタッフ向け画面で閲覧できること。 - 問診未回答の患者へ再通知できること。 - 回答内容の印刷またはPDF出力に対応すること。 ### 6.5 スタッフ向け管理機能 - 当日予約一覧を表示できること。 - 予約ステータスを受付前、来院済み、診察中、会計待ち、完了、キャンセルで管理できること。 - 患者名、予約時間、診療メニュー、問診状況で絞り込みできること。 - 予約詳細画面で患者情報、問診、通知履歴を確認できること。 - 受付スタッフ、看護師、院長の役割別に表示内容を調整できること。 - 予約枠の休診、臨時休診、時間変更を設定できること。 - ダッシュボードで当日予約数、キャンセル数、問診回収率を確認できること。 - 月次の予約件数とキャンセル率を確認できること。 ### 6.6 患者向け機能 - 患者はアカウント作成なしで予約できること。 - 予約確認リンクは推測困難なトークンで保護すること。 - 予約完了画面で日時、場所、持ち物、注意事項を表示すること。 - 問診回答画面はスマートフォンで読みやすいこと。 - 入力途中の離脱を減らすため、フォームは段階的に表示できること。 - 患者が通知停止希望を申請できること。 - 緊急症状がある場合は電話または救急相談へ誘導する注意文を表示すること。 ### 6.7 設定機能 - クリニック基本情報を登録できること。 - 診療時間、休診日、祝日対応を設定できること。 - 診療メニューと予約枠長を設定できること。 - 通知文面テンプレートを編集できること。 - キャンセル可能期限を設定できること。 - 問診フォームを診療メニュー単位で紐づけられること。 - スタッフアカウントを招待・無効化できること。 - 監査ログの保持期間を設定できること。 ## 7. 非機能要件 画面表示は、通常操作において3秒以内に主要情報を表示することを目標とします [要検証]。 予約確定処理は、同一予約枠への同時アクセスが発生しても重複登録を防ぐこと。 スタッフ向け画面は、診療時間中の連続利用を前提に、一覧性と操作回数の少なさを重視します。 患者向け画面は、専門用語を避け、短い文と明確なボタン表現を用います。 ブラウザは、最新版のChrome、Safari、Edgeを主な対応対象とします。 スマートフォンは、iOSおよびAndroidの標準ブラウザ利用を想定します。 デモ版の想定同時利用者数は、スタッフ5名、患者30名程度とします [要検証]。 将来的な本番利用では、1クリニックあたり月間予約数1,000件程度を初期設計目安とします [要検証]。 ## 8. アーキテクチャ概要 MediCueは、フロントエンド、バックエンドAPI、データベース、通知基盤、管理用ジョブの複数コンポーネントで構成します。 フロントエンドは、患者向け予約画面とスタッフ向け管理画面を提供します。 バックエンドAPIは、予約、患者、問診、通知、設定、認証、監査ログを管理します。 データベースは、クリニック、ユーザー、予約、問診回答、通知履歴などの業務データを保持します。 通知基盤は、SMSおよびメール送信サービスと連携します。 管理用ジョブは、リマインド送信、未回答問診の検知、古い一時データの削除を行います。 各コンポーネントは、将来的なマルチテナント化を前提に、clinic_idを中心としたデータ分離を行います。 予約枠の確保処理では、データベーストランザクションまたは一意制約を用いて競合を制御します。 監査ログは、患者情報へのアクセス、予約変更、問診閲覧、通知送信などの重要操作を記録します。 ## 9. 主要技術 フロントエンドは、Reactまたは同等のコンポーネントベースUIフレームワークを想定します。 スタッフ向け管理画面では、予約一覧、フィルター、詳細ペインを効率的に扱える構成とします。 患者向け画面では、軽量なページ読み込みとモバイル操作性を重視します。 バックエンドは、Node.js、Python、Ruby、Goなどの一般的なWeb API基盤で構築可能とします。 データベースは、リレーショナルデータベースを第一候補とします。 予約枠、予約、患者、問診、通知履歴は関係性が明確であるため、PostgreSQL等が適しています。 認証は、スタッフ向けにはメールアドレスとパスワード、または外部IDプロバイダー連携を想定します。 患者向け予約確認は、ログイン不要のワンタイムまたは期限付きトークン方式を想定します。 通知は、SMS送信サービスおよびメール配信サービスを利用します。 ジョブ実行には、キューまたはスケジューラーを利用します。 ログ収集と監視には、アプリケーションログ、エラートラッキング、メトリクス監視を組み合わせます。 ## 10. データモデル概要 主要エンティティは、Clinic、StaffUser、Patient、Appointment、AppointmentSlot、Questionnaire、QuestionnaireResponse、NotificationLogです。 Clinicは、クリニック名、住所、電話番号、診療時間、通知設定を保持します。 StaffUserは、スタッフの氏名、メールアドレス、ロール、所属クリニックを保持します。 Patientは、患者氏名、連絡先、生年月日、患者識別情報を保持します。 Appointmentは、予約日時、診療メニュー、予約ステータス、患者、クリニックを保持します。 AppointmentSlotは、予約可能枠、所要時間、公開状態、上限数を保持します。 Questionnaireは、問診フォーム定義、診療メニューとの紐づき、公開状態を保持します。 QuestionnaireResponseは、患者回答、回答日時、予約との紐づきを保持します。 NotificationLogは、通知種別、宛先、送信日時、送信結果、関連予約を保持します。 AuditLogは、操作ユーザー、操作対象、操作内容、実行日時、IPアドレスを保持します。 ## 11. API 設計 APIはREST形式を基本とし、JSONでリクエストとレスポンスを扱います。 内部用途と患者公開用途を明確に分け、認証方式とレート制限を分離します。 APIのバージョンは、`/api/v1` のようにURL上で管理します。 エラー応答は、HTTPステータスコード、エラーコード、ユーザー向けメッセージ、開発者向け詳細を含めます。 ### 11.1 認証API - `POST /api/v1/auth/login` は、スタッフのログインを行います。 - `POST /api/v1/auth/logout` は、スタッフのログアウトを行います。 - `POST /api/v1/auth/password-reset` は、パスワード再設定メールを送信します。 - `GET /api/v1/auth/me` は、ログイン中スタッフの情報を取得します。 ### 11.2 予約API - `GET /api/v1/appointments` は、予約一覧を取得します。 - `POST /api/v1/appointments` は、スタッフ操作による予約を作成します。 - `GET /api/v1/appointments/{appointment_id}` は、予約詳細を取得します。 - `PATCH /api/v1/appointments/{appointment_id}` は、予約日時やステータスを更新します。 - `POST /api/v1/appointments/{appointment_id}/cancel` は、予約をキャンセルします。 - `GET /api/v1/public/slots` は、患者向けに予約可能枠を取得します。 - `POST /api/v1/public/appointments` は、患者向け予約を作成します。 - `GET /api/v1/public/appointments/{token}` は、患者向け予約確認情報を取得します。 ### 11.3 問診API - `GET /api/v1/questionnaires` は、問診フォーム一覧を取得します。 - `POST /api/v1/questionnaires` は、問診フォームを作成します。 - `PATCH /api/v1/questionnaires/{questionnaire_id}` は、問診フォームを更新します。 - `GET /api/v1/appointments/{appointment_id}/questionnaire-response` は、予約に紐づく問診回答を取得します。 - `POST /api/v1/public/questionnaire-responses` は、患者の問診回答を登録します。 - `GET /api/v1/public/questionnaires/{token}` は、患者向け問診フォームを取得します。 ### 11.4 通知API - `GET /api/v1/notifications/logs` は、通知履歴を取得します。 - `POST /api/v1/notifications/test` は、テスト通知を送信します。 - `POST /api/v1/appointments/{appointment_id}/notifications/remind` は、個別リマインドを送信します。 - `PATCH /api/v1/settings/notification-templates/{template_id}` は、通知文面を更新します。 ### 11.5 設定API - `GET /api/v1/settings/clinic` は、クリニック設定を取得します。 - `PATCH /api/v1/settings/clinic` は、クリニック設定を更新します。 - `GET /api/v1/settings/menus` は、診療メニュー一覧を取得します。 - `POST /api/v1/settings/menus` は、診療メニューを作成します。 - `PATCH /api/v1/settings/menus/{menu_id}` は、診療メニューを更新します。 - `GET /api/v1/settings/schedules` は、診療時間設定を取得します。 - `PATCH /api/v1/settings/schedules` は、診療時間設定を更新します。 ## 12. 画面設計方針 スタッフ向けトップ画面は、当日の予約一覧を中心に構成します。 一覧では、予約時間、患者名、初診・再診、診療メニュー、問診状況、ステータスを一目で確認できるようにします。 予約詳細は、画面遷移を増やさず、右側ペインまたはモーダルで確認できる構成を想定します。 患者向け予約画面は、診療メニュー選択、日時選択、情報入力、確認、完了の順に進めます。 患者向け問診画面は、長いフォームを避け、カテゴリごとに区切って回答しやすくします。 設定画面は、クリニック情報、診療時間、メニュー、通知、問診、スタッフをタブで分けます。 ## 13. セキュリティ要件 通信はすべてHTTPSで暗号化します。 スタッフ向け管理画面には認証を必須とします。 スタッフアカウントには、ロールベースアクセス制御を適用します。 受付スタッフは予約と患者基本情報を扱えますが、システム設定の一部は管理者に限定します。 問診回答には要配慮個人情報が含まれる可能性があるため、閲覧権限を必要最小限に制御します。 患者向け予約確認リンクには、推測困難なトークンを使用します。 予約確認トークンには有効期限を設定します。 管理者操作、予約変更、問診閲覧、データ出力は監査ログに記録します。 パスワードは安全なハッシュアルゴリズムで保存します。 ログには、不要な個人情報や問診本文を出力しないよう制御します。 データベースのバックアップは暗号化して保管します。 本番環境では、秘密情報を環境変数またはシークレット管理基盤で扱います。 外部通知サービスとの連携キーは、ソースコードに含めません。 管理画面にはCSRF対策、XSS対策、SQLインジェクション対策を実装します。 APIにはレート制限を設け、公開予約APIへの過剰アクセスを抑制します。 アカウントロックまたは追加認証により、総当たり攻撃への耐性を高めます。 個人情報の保管期間は、クリニックの運用方針と法令要件を確認して決定します [要検証]。 ## 14. プライバシー・コンプライアンス MediCueは医療機関の業務支援システムであり、患者の個人情報および健康関連情報を扱います。 個人情報保護法に基づく適切な取得、利用目的の明示、保管、削除対応を前提とします。 患者向け画面には、利用目的、問い合わせ先、個人情報の取り扱いへの導線を設置します。 問診回答の利用目的は、来院前準備および診療補助であることを明示します。 患者が送信した問診内容は、医療者による確認を前提とし、自動診断には利用しません。 外部委託先となるSMS事業者、メール配信事業者、クラウド事業者については、契約条件とデータ処理範囲を確認します [要検証]。 海外リージョン利用の有無は、導入クリニックへの説明事項とします [要検証]。 ## 15. SLA デモ版では商用SLAを保証しません。 商用版を想定する場合、月間稼働率99.5%を初期目標とします [要検証]。 診療時間中の主要機能である予約一覧、予約詳細、問診閲覧は、高い可用性を優先します。 計画メンテナンスは、原則として診療時間外に実施します。 計画メンテナンスの通知は、少なくとも3営業日前に行う運用を目安とします [要検証]。 重大障害発生時は、管理者向けに障害内容、影響範囲、暫定対応、復旧見込みを通知します。 復旧目標時間は、主要機能で4時間以内を目安とします [要検証]。 復旧時点目標は、データベースバックアップ基準で24時間以内を目安とします [要検証]。 通知遅延については、SMSおよびメール事業者の障害影響を受けるため、外部サービスのSLA確認が必要です [要検証]。 ## 16. 運用・監視 アプリケーションエラーは、エラートラッキングツールで検知します。 API応答時間、エラー率、ジョブ失敗数、通知送信失敗数を監視対象とします。 予約作成失敗、問診保存失敗、通知失敗は、業務影響が大きいため優先度を高く設定します。 管理者向けダッシュボードには、システム利用状況と通知利用量を表示します。 バックアップは日次で取得することを初期目安とします [要検証]。 監査ログは少なくとも1年間保持することを初期目安とします [要検証]。 不要となった一時トークンは、定期ジョブで削除します。 送信失敗した通知は、再送可否を判定したうえで再試行します。 ## 17. キャンセル対策設計 予約完了時に、キャンセル期限と連絡方法を明確に表示します。 前日リマインドで、来院できない場合のキャンセル導線を提供します。 キャンセル理由を取得し、予約枠設計や案内改善に活用します。 無断キャンセルが複数回発生した患者については、スタッフ画面で注意表示できるようにします。 ただし、患者への不利益な扱いにつながる判断は、必ずクリニック側の運用判断とします。 キャンセル率、直前キャンセル率、無断キャンセル率を月次で集計します。 初期目標として、無断キャンセル率を20%削減することを仮説とします [要検証]。 ## 18. 成功指標 予約受付に関する電話対応件数の削減率を主要指標とします。 問診事前回収率を主要指標とします。 無断キャンセル率を主要指標とします。 受付スタッフの予約入力・確認にかかる平均時間を補助指標とします。 患者の予約完了率を補助指標とします。 通知到達率を補助指標とします。 初期仮説として、問診事前回収率70%以上を目標とします [要検証]。 初期仮説として、予約完了までの平均所要時間を3分以内とします [要検証]。 初期仮説として、受付電話件数を15%削減することを目標とします [要検証]。 ## 19. 制約事項 MediCueは、電子カルテやレセプトコンピューターの置き換えを目的としません。 医療行為の判断、診断、治療方針決定は対象外です。 緊急性の高い症状を持つ患者には、オンライン予約ではなく電話または救急相談を促す必要があります。 SMS通知は、患者の電話番号入力誤りや通信事業者都合により到達しない場合があります。 メール通知は、迷惑メール判定や受信設定により到達しない場合があります。 外部通知サービスの料金は、送信件数に応じて変動します [要検証]。 予約枠の運用ルールはクリニックごとに異なるため、初期導入時に設定支援が必要です。 ## 20. リリース段階 ### 20.1 デモ版 デモ版では、主要画面と代表的な予約フローを確認できることを重視します。 予約作成、予約一覧、問診回答、通知履歴の疑似表示を含めます。 外部SMS送信はモックまたはテスト送信に限定しても構いません。 ### 20.2 MVP版 MVP版では、実クリニックで限定的に運用できる範囲を目指します。 スタッフ認証、予約枠設定、患者予約、問診回答、メール通知、監査ログを含めます。 SMS通知は、費用対効果を確認したうえで導入します [要検証]。 ### 20.3 商用版 商用版では、マルチテナント対応、バックアップ、障害監視、運用手順、契約管理を整備します。 権限管理、データ出力、セキュリティレビュー、サポート体制を強化します。 電子カルテや外部予約導線との連携は、導入先の要望に応じて検討します。 ## 21. 今後の拡張候補 LINE等のメッセージング連携を検討します [要検証]。 オンライン決済による予約金またはキャンセルポリシー運用を検討します [要検証]。 電子カルテへの問診PDF連携を検討します [要検証]。 再診患者向けの定期通院リマインドを検討します。 ワクチン接種や健診など、枠管理が特殊なメニューへの対応を検討します。 複数スタッフによる診療枠管理を検討します。 患者満足度アンケートの配信を検討します。 院内待ち時間表示との連携を検討します。 ## 22. リスクと対応方針 患者情報を扱うため、セキュリティ設計の不備は重大な信用リスクとなります。 初期段階からアクセス制御、監査ログ、暗号化、最小権限を設計に含めます。 予約枠の二重登録は、業務混乱に直結するため、技術的制約で防止します。 通知の未達は完全には防げないため、送信結果の可視化と代替連絡手段を用意します。 問診フォームが長すぎる場合、患者の離脱率が上がる可能性があります。 導入時には、必要項目を絞ったフォーム設計を推奨します。 クリニックごとの運用差が大きいため、過度に固定的なワークフローは避けます。 ただし、設定項目を増やしすぎると運用が難しくなるため、初期値とテンプレートを用意します。 ## 23. 受け入れ基準 患者がスマートフォンから予約を完了できること。 予約完了後、患者が予約内容を確認できること。 スタッフが当日予約一覧を確認できること。 スタッフが予約詳細と問診回答を確認できること。 患者が予約に紐づく問診へ回答できること。 スタッフが予約ステータスを更新できること。 予約キャンセルが予約一覧へ反映されること。 通知履歴として、予約確認、リマインド、問診依頼の送信結果を確認できること。 管理者が診療時間、診療メニュー、通知文面を設定できること。 主要操作が監査ログに記録されること。 ## 24. まとめ MediCueは、個人クリニックの予約から来院準備までの業務を一体化し、受付負荷の軽減と患者体験の改善を支援するSaaSです。 初期段階では、予約受付、リマインド、事前問診、キャンセル対策に機能を絞り、現場で継続利用しやすい業務導線を重視します。 医療機関向けサービスとして、セキュリティ、プライバシー、監査性、安定運用を前提に設計します。 本仕様はデモおよびMVP検討の土台であり、実導入前には法務、セキュリティ、運用、医療現場ヒアリングによる検証が必要です。