Skip to content
P.M.C P.M.C P.M.C Documentation

Case History

1. What does this feature do? (High-Level Overview)

Section titled “1. What does this feature do? (High-Level Overview)”

This feature presents the Case History section of the BIP in a structured clinical workflow so teams can document and review baseline context before finalizing intervention decisions, while keeping all updates inside the same BIP experience; clinically, it consolidates client demographics, treatment history, educational/medical status, trauma/comorbidity context, assessment findings, medications, and environmental antecedents to support medically necessary, individualized planning.

2. Who is this for? (Roles & Permissions)

Section titled “2. Who is this for? (Roles & Permissions)”
  • Superadmin/Admin/Owner/Manager (or any role granted manage_bips): Primary users of the tabbed BIP flow; can review and update Case History fields.
  • RBT/Analyst without manage_bips: Usually redirected to full BIP read-only flow (/bip/show/client/:id) instead of tabbed editing flow.
  • Users without BIP access permissions (view_bips/manage_bips): Cannot access BIP actions from normal client workflows.

Required permissions used by this feature path:

  • manage_bips: Required to stay in tabbed BIP route (guard keeps this flow editable).
  • view_bips: Used in non-tabbed BIP viewing entry points.

3. Business Rules & Enforcements

Section titled “3. Business Rules & Enforcements”
  • Rule 1: This tab is defined as overview with title Case History in the BIP tab catalog.
  • Rule 2: If no BIP exists yet, normal tab interaction is blocked globally and users must first create a BIP through the fused initial state.
  • Rule 3: Every Case History field change emits bipUpdated, which triggers parent autosave (debounced) to persist changes without a separate explicit Save button in this tab.
  • Rule 4: Tab completion for Case History requires all three fields: patient_identifier, background_information, and assestment_conducted.
  • Rule 5: The tab is flagged with validation warning state when patient_identifier is missing.
  • Rule 6: Service Start Date change can trigger a confirmation dialog; confirmed action calls backend startServices and reloads BIP state.
  • Rule 7: Medication and assessment setting rows support add/remove actions, and deletion requires explicit confirmation.

4. UI Placement

Section titled “4. UI Placement”
  • Medical > clients list > Client actions > BIP View / Update.
  • Inside BIP tabbed view: tab Case History (tab id overview).
  • Route family used for tabbed BIP: /bip/tabbed/:patient_id and /:id route variant under BIP module.

5. How-To Guide (Step-by-Step)

Section titled “5. How-To Guide (Step-by-Step)”

Scenario A: Complete Case History during BIP build

Section titled “Scenario A: Complete Case History during BIP build”
  1. Go to Medical and open the Clients list.
  2. Open client actions and click BIP View / Update.
  3. Open tab Case History.
  4. Review and complete key blocks: Patient Information, Behavior Analysis Assessment, Background Information, Physical and Medical Status, Assessment Conducted, and Documents and Results.
  5. Update specific inline fields (for example type of assessment, background text, trauma/comorbidities, medication entries).
  6. Wait for autosave confirmation/toast after edits.

Scenario B: Start services from Case History

Section titled “Scenario B: Start services from Case History”
  1. In Case History, set Service Start Date.
  2. Confirm start action when prompted.
  3. System submits start-services request and refreshes BIP data.

Scenario C: Manage medication or assessment settings

Section titled “Scenario C: Manage medication or assessment settings”
  1. In Case History, go to Medication or Stimulus Preference Assessment sections.
  2. Click Add Setting to create a new row.
  3. Fill values inline.
  4. If removing a row, confirm deletion in the warning dialog.

6. What happens if…? (Edge Cases / FAQ)

Section titled “6. What happens if…? (Edge Cases / FAQ)”

  • Q: What happens if no BIP exists yet?

  • A: Tabbed editing stays disabled. User sees the create-BIP initial state first and only after creation can interact with Case History.

  • Q: What happens if a user without manage_bips tries tabbed BIP routes?

  • A: Guard behavior redirects the user to the full BIP view route, preventing editable tabbed flow.

  • Q: What if Service Start fails in backend?

  • A: The tab restores the prior date value and shows an error snackbar; no silent state drift is kept.

APPENDIX

Section titled “APPENDIX”

Default role examples considered:

  • Superadmin
  • Admin
  • Owner
  • Manager
  • RBT/Analyst

Implementation notes:

  • Tab id is overview, UI title is Case History.
  • Component used is app-bip-overview-tab.