コンテンツにスキップ

園児健康管理機能 仕様レビューと追加要件

  • 文書種別: 設計レビュー履歴
  • 初回レビュー: 2026-04-19
  • 現況再確認: 2026-08-11
  • 実装状況: Phase 1相当を実装済み。Phase 2以降は未実装

この文書は実装前レビューを残したものである。現行実装の確認には本節と仕様書一覧を優先し、後続節の「現行実装」は初回レビュー時点の意味で読む。

現在の実装状況

現在は専用ルーターrouters/child_health.pyとtemplates/child_health/に分離され、次を実装している。

  • 健康管理一覧/healthと園児別健康サマリー/children/{child_id}/health
  • 健康プロフィールと園で優先して管理する事項
  • アレルギーの登録・編集・無効化・再有効化
  • 健診記録と、同日・異なる健診種別を保持できる身長・体重の時系列表示
  • children.extra_dataの既存アレルギー・医療メモからの起動時移行と互換同期
  • 閲覧のみ職員による更新の拒否

感染症管理、与薬依頼、睡眠チェック、添付文書、専用の通知・監査画面は未実装であり、後続フェーズの仕様として残す。

1. 結論

元の仕様書は、法令・ガイドラインの整理、データモデルの切り分け、アクセス制御の方向性がよくまとまっており、健康管理機能の土台として十分に良い内容です。

一方で、現在の open-hoikuict に実装する前提では、次の4点を明確にしたほうが安全です。

  • 初期リリース範囲を絞ること
  • 既存の children.extra_data からの移行手順を具体化すること
  • 添付文書、監査履歴、通知連携の扱いを補うこと
  • 身長・体重の「成長曲線」を、まずは標準値比較ではなく時系列グラフとして明文化すること

2. 初回レビュー時点のopen-hoikuictとの整合

初回レビュー時点では、園児の健康情報は主に以下に留まっていました。

  • children.extra_data.allergy
  • children.extra_data.medical_notes
  • 園児詳細画面 /children/{child_id}
  • 保護者ポータルのプロフィール申請フロー

実装基盤には以下の特徴があり、専用ルーターへ分離する判断は現在の実装へ反映済みです。

  • バックエンドは FastAPI + SQLModel
  • 画面は Jinja + Tailwind + HTMX
  • DB変更は Alembic ではなく database.py の加算型 migration 関数で対応
  • 権限は大きく admin / can_edit / view_only の3段階

このため、健康管理機能は routers/children.py に追記するより、専用のルータとテンプレート群に分離する前提で仕様化したほうが保守しやすいです。

3. 元仕様の評価

3-1. 良い点

  • 法令、通知、ガイドラインの参照元が明確で、保育現場向け仕様として説得力がある
  • child_health_profiles、child_allergies、health_check_records など、責務ごとの分割が自然
  • 論理削除や参照専用の保護者ポータルなど、運用上の安全性が考慮されている
  • children.extra_data からの段階移行が明記されている
  • 健康サマリー、感染症、与薬、睡眠チェックまで含めて、将来像が描けている

3-2. 修正推奨

1. 初期リリースの範囲が広い

健康プロフィール、アレルギー、予防接種、健診、感染症、与薬、事故、睡眠チェックを一度に入れると、UI、権限、通知、テストが大きく膨らみます。

初期リリースは次に絞るのが現実的です。

  • 健康サマリー
  • アレルギー管理
  • 健康診断記録
  • 身長・体重グラフ
  • extra_data からの移行

2. 添付文書の扱いが弱い

source_document を文字列で持つだけでは、生活管理指導表、与薬依頼書、医療的ケア計画書の原本管理として不足します。

将来的には以下のような添付テーブルが必要です。

class HealthRecordAttachment(SQLModel, table=True):
    __tablename__ = "health_record_attachments"

    id: Optional[int] = Field(default=None, primary_key=True)
    child_id: int = Field(foreign_key="children.id", index=True)
    record_type: str                 # allergy / medication / health_profile など
    record_id: Optional[int] = None
    document_type: str               # life_management_sheet / medication_request / care_plan
    original_filename: str
    storage_path: str
    uploaded_by: Optional[str] = None
    uploaded_at: datetime = Field(default_factory=utc_now)

3. 監査履歴の対象が不足している

child_health_profile_history だけでは不十分です。少なくとも以下は変更履歴か更新者の記録が必要です。

  • アレルギー
  • 感染症
  • 与薬
  • 事故・ケガ
  • 健康診断記録

最低限、各テーブルに次を揃えることを推奨します。

  • created_at
  • updated_at
  • created_by
  • updated_by

4. 権限モデルを既存実装に合わせて簡略化する必要がある

元仕様のアクセス制御は妥当ですが、現状のアプリは細かい権限マトリクスをまだ持っていません。

初期段階では次のマッピングが安全です。

  • view_only: 閲覧のみ
  • can_edit: 登録・編集
  • admin: 重大事故報告、権限の強い修正、論理削除

5. 入力バリデーションと重複ルールを先に決めるべき

実装時に迷いやすいので、仕様側で次を決めておくとよいです。

  • 身長は 30.0 <= height_cm <= 200.0
  • 体重は 1.0 <= weight_kg <= 100.0
  • 体温は 30.0 <= temperature <= 45.0
  • 同一園児・同一日付・同一健診種別の重複登録は警告する
  • 同日複数記録は許容するが、グラフ表示では updated_at が最新の記録を優先する

6. 「成長曲線」という用語は段階分けしたほうがよい

現在の Child モデルには性別や在胎週数がなく、厚生労働省等の標準曲線と正確に比較するための前提が不足しています。

そのため、初期リリースでは次のように分けるのが適切です。

  • v1: 身長・体重の時系列推移グラフ
  • v2: 標準値やパーセンタイルを重ねた成長曲線

4. 推奨リリース順

Phase 1

  • child_health_profiles
  • child_allergies
  • health_check_records
  • 健康サマリー画面
  • 身長・体重グラフ
  • children.extra_data からの移行

Phase 2

  • infectious_disease_records
  • medication_records
  • sleep_check_records
  • 出欠確認、お知らせとの連携

Phase 3

  • vaccination_records
  • incident_injury_records
  • 添付文書管理
  • 標準値付き成長曲線

5. 身長・体重グラフ 追加仕様

5-1. 目的

職員と保護者が、園児の身体発育の推移を一覧で把握できるようにする。

初期リリースでは、医療用の標準成長曲線比較ではなく、実測値の推移を見せる時系列グラフを提供する。

5-2. 対象画面

  • 職員向け: /children/{child_id}/health/check-records
  • 保護者向け: /parent-portal/children/{child_id}/health

保護者向けは閲覧専用とし、他の要配慮情報よりも表示を限定する。

5-3. データソース

グラフの元データは health_check_records を使用する。

初期表示では以下のみを対象とする。

  • check_type = entrance
  • check_type = periodic

初期表示では以下を除外する。

  • check_type = daily
  • check_type = post_illness

ただし将来的に、フィルタで日常観察を含められる拡張は許容する。

5-4. 抽出条件

  • height_cm または weight_kg のいずれかが入っているレコードを対象とする
  • 表示順は checked_at ASC
  • 同一日付に複数レコードがある場合は updated_at が最新のものを採用する
  • 値が NULL の項目はその系列ではプロットしない
  • 欠測データを補間しない

5-5. 表示仕様

グラフ構成

  • 身長グラフと体重グラフは別カードで表示する
  • 初期リリースでは二軸の複合グラフは採用しない
  • 各点は実測値を示すドット付き折れ線とする
  • 線はスムージングしない

軸

  • X軸: checked_at
  • Y軸（身長）: cm
  • Y軸（体重）: kg

補助表示

各グラフの上部に次を表示する。

  • 最新測定日
  • 最新値
  • 前回値との差分
  • 直近3回の測定日へのショートリンクまたは表表示

ツールチップ

各点のホバーまたはタップで次を表示する。

  • 測定日
  • 身長または体重
  • 健診種別
  • 総合所見があればその有無

5-6. 空データ・少量データ時の表示

  • データ0件: 「身体測定記録がまだありません」を表示
  • データ1件: 単一点のみ表示し、推移比較は非表示
  • データ2件以上: 折れ線グラフとして表示

5-7. 一覧表との併用

グラフの下に、同じ抽出条件の測定一覧表を表示する。

一覧表の列は以下とする。

  • 測定日
  • 健診種別
  • 身長
  • 体重
  • 記録者または医師名
  • 総合所見の有無

これにより、JavaScript が使えない環境でも最低限の参照を可能にする。

5-8. フィルタ

初期リリースでは以下の期間切替を設ける。

  • 直近1年
  • 在籍期間すべて

将来的には学年単位や年度単位の絞り込みを追加してよい。

5-9. 実装方針

現行構成を踏まえ、初期リリースでは以下を推奨する。

  • サーバーサイドは FastAPI + Jinja のまま維持する
  • グラフ描画は軽量な JavaScript ライブラリを画面単位で読み込む
  • SPA 化やフロントエンドビルド導入は行わない

推奨案は以下。

  • ライブラリ: Chart.js
  • 読み込み方法: 対象画面のみ CDN 読み込み
  • データ受け渡し: テンプレートに JSON を埋め込む

5-10. レスポンシブ要件

  • スマートフォン幅では縦並び表示
  • 横スクロールなしで凡例と軸ラベルが読めること
  • 親指操作でも期間切替とグラフ確認ができること

5-11. アクセス制御

  • 職員 view_only: 閲覧可
  • 職員 can_edit: 閲覧可、測定記録の登録・編集可
  • 職員 admin: 上記に加え、強い権限操作可
  • 保護者: 閲覧のみ

5-12. 受け入れ条件

  • 健康診断記録を登録すると、同一園児のグラフに即時反映される
  • 身長のみ、または体重のみの記録でもグラフが崩れない
  • 同日重複がある場合も、採用ルールどおり1点だけ表示される
  • データがない場合に空状態メッセージが表示される
  • モバイルでもグラフと一覧表の両方が読める

6. 元仕様への反映ポイント

元仕様にそのまま追記する場合は、少なくとも以下を修正すると実装しやすくなります。

6-1. 5-3 健康診断記録

現行:

  • 時系列グラフ（身長・体重の成長曲線）

修正案:

  • 身長・体重の時系列推移グラフ
  • 初期表示は entrance / periodic のみを対象とする
  • グラフの下に測定一覧表を表示する
  • 標準値比較付き成長曲線は将来拡張とする

6-2. 7 保護者向け機能

現行の「身体測定記録（成長曲線）」は、次の文言に寄せると明確です。

  • 身体測定記録（身長・体重の推移グラフ、閲覧専用）

6-3. 10 未決事項

次のように段階分けすると、実装優先度を整理しやすいです。

  • 身長・体重推移グラフ: 高
  • 標準値重ね表示付き成長曲線: 低
  • 生活管理指導表のPDF取込: 中
  • 医療的ケア計画書の電子管理: 中

7. 実装メモ

この仕様を現行コードへ入れる場合、構成は次の分離を推奨します。

  • routers/child_health.py
  • templates/child_health/
  • models.py に健康管理系モデル追加
  • database.py に _migrate_add_health_tables() 追加

健康管理機能は園児基本情報より責務が大きく異なるため、既存の routers/children.py へ集約しすぎないほうが保守しやすいです。