Ifitwala Logo Ifitwala Ed

Applicant Health Profile: Health Disclosure and Clearance

Capture health details, control family/staff editing by applicant status, and feed readiness for admissions decisions.

On this page

Before You Start (Prerequisites)

  • Create the Student Applicant record first.
  • Decide your internal review process (Pending, Needs Follow-Up, Cleared) before staff start updating rows.
  • If family-side editing is used, ensure applicant portal access/linkage is already set up.

Applicant Health Profile stores health and safeguarding information needed during admissions review.

What It Captures

  • Blood group
  • Allergy check and details (food_allergies, insect_bites, medication_allergies)
  • Condition detail fields (from asthma through vision_problem)
  • Diet and history fields (diet_requirements, medical_surgeries__hospitalizations, other_medical_information)
  • Vaccinations child rows (vaccine_name, date, vaccination_proof, additional_notes)
  • Applicant declaration fields (applicant_health_declared_complete, applicant_health_declared_by, applicant_health_declared_on)
  • Staff review status and notes

Where It Is Used Across the ERP

  • Student Applicant: readiness checks require a cleared health review.
  • Admissions portal APIs:
    • get_applicant_health
    • update_applicant_health
  • Staff review UI: reviewer metadata stamped when moving to review outcomes.
  • Admission workspace card: direct operational access.

Review States

  • Pending
  • Needs Follow-Up
  • Cleared
Practical workflow

Families can provide health details in portal phases where edits are allowed, then staff can move review status to Cleared or Needs Follow-Up.

Operational Guardrails

Do

  • Keep reviewer outcomes explicit (Pending, Needs Follow-Up, Cleared) and let reviewer metadata stamp automatically.

  • Use governed vaccination-proof uploads and canonical file URLs.

Don't

  • Approve applicant decisions while health review is unresolved.

  • Allow family-side edits after terminal applicant states (Rejected, Promoted).

Lifecycle and Linked Documents

Applicant Health Lifecycle
1

Create Profile

Create health profile context as soon as an applicant enters active review.

2

Capture Details

Capture family-provided health details and keep entries current through the review window.

3

Review

Staff reviewers move the profile through review outcomes (Pending, Needs Follow-Up, Cleared).

4

Gate Decisions

Applicant approval readiness depends on the health review state being complete.

5

Promote

On applicant promotion, health fields and vaccination rows are copied into Student Patient / Student Patient Vaccination.

6

Governed Proof Files

Vaccination proof images are uploaded through governed dispatcher storage and linked via canonical file URLs.

Admissions decision impact

Do not move applicants to final approval while health review remains unresolved; readiness checks are designed to prevent this.

Reporting

  • No dedicated Script/Query Report currently declares this doctype as ref_doctype.
Related Applicant Review Docs

Student Applicant: The Admission Record of Truth

->
Admission

Manage applicant lifecycle from invitation to promotion, with readiness checks, governed files, policy acknowledgements, and portal access.

Applicant Interview: Structured Interview Evidence

->
Admission

Record interview evidence, participants, and outcomes with audit trail comments pushed to the Student Applicant timeline.

Applicant Document: Governed Admission File Record

->
Admission

Track each applicant document type, review status, and promotion relevance with strict immutability and governed file handling.

Technical Notes (IT)

Latest Technical Snapshot (2026-02-21)

  • DocType schema file: ifitwala_ed/admission/doctype/applicant_health_profile/applicant_health_profile.json

  • Controller file: ifitwala_ed/admission/doctype/applicant_health_profile/applicant_health_profile.py

  • Required fields (reqd=1):

    • student_applicant (Link -> Student Applicant)

  • Lifecycle hooks in controller: validate

  • Operational/public methods: none beyond standard document behavior.

  • DocType: Applicant Health Profile (ifitwala_ed/admission/doctype/applicant_health_profile/)

  • Autoname: hash

  • Primary link: student_applicant -> Student Applicant (immutable once set)

  • Portal/API surfaces:

    • endpoints in ifitwala_ed/api/admissions_portal.py:
      • get_applicant_health
      • update_applicant_health
    • SPA page consuming these APIs: ifitwala_ed/ui-spa/src/pages/admissions/ApplicantHealth.vue

  • Controller methods:

    • permission gating by role and applicant status
    • reviewer metadata stamping (reviewed_by, reviewed_on)
    • promotion handoff consumed by Student Applicant.promote_to_student

Permission Matrix

Role Read Write Create Delete Notes
System Manager Yes Yes Yes Yes Full Desk access
Academic Admin Yes Yes Yes Yes Staff review role
Admission Manager Yes Yes Yes Yes Full Desk access
Admission Officer Yes Yes Yes Yes Full Desk access
Guardian Yes Yes Yes No Family-facing write allowed by DocType permissions

Runtime controller rules:

  • Family/applicant editing is allowed for non-promoted applicant phases (Draft through Withdrawn, excluding Rejected).
  • Review fields are staff-only.
  • Terminal applicant states (Rejected, Promoted) are read-only.