import type { Patient } from 'fhir/r4';

/**
 * - the ONE rule for describing a Patient's active state to a human.
 *
 * `PatientProfile` used to render `active === true ? "Active": "Inactive"`, which labels a patient
 * INACTIVE whenever the field is merely ABSENT. That is the common case, not an edge case: per card
 * 134's analysis, **61 of 81 staging Patients carry no `active` key at all**.
 *
 * FHIR treats an absent `active` as *no assertion* - and this codebase already agrees wherever it
 * MATTERS. `PatientService.searchPatients` filters on `active !== false` precisely so those records
 * stay findable and bookable. So the badge contradicted the product's own behaviour: a patient the
 * system happily books was told, on their own profile, that they are inactive. (The profile badge is
 * not role-gated, so the patient sees it.)
 *
 * Keep this keyed the SAME way as that filter. Two answers to "is this patient active?" is how the
 * badge drifted from the behaviour in the first place, and a test pins the two together.
 *
 * `FhirPatientDisplay.renderActiveValue` deliberately does something different - Yes / No / "-" for
 * the three states - and that is correct there: it renders `active` as a FIELD VALUE, where "not
 * recorded" is a meaningful answer. This is a STATUS badge, which must describe behaviour.
 */

/** True only when the record has been explicitly deactivated. Absent is not a denial. */
export const isPatientDeactivated = (patient?: Patient): boolean => patient?.active === false;

/** The status label for a patient badge. Mirrors the `active !== false` bookability rule. */
export const patientStatusLabel = (patient?: Patient): 'Active' | 'Inactive' =>
    isPatientDeactivated(patient) ? 'Inactive' : 'Active';