Boojee Companion Care
Clinical Protocols

1.1 — Permissible Functions

• Screening: Administer validated, public-domain psychometric instruments (UCLA-3, PHQ-2, PHQ-9, GAD-7) using their exact published item stems and response anchors to identify elevated risk for loneliness, depression, or anxiety.
• Monitoring: Track member scores longitudinally to detect trend changes and produce pre/post deltas for outcome reporting.
• Engagement: Provide companionship conversation, daily wellness check-ins, medication and appointment reminders framed as adherence support.
• Escalation: Route any elevated screen result, detected risk language, or PHQ-9 Item 9 response to a designated human responder (caregiver, clinical staff, or emergency services) per the escalation SOP in Section 3.

1.2 — Prohibited Functions

• This program does not diagnose any mental-health condition, medical condition, or disease state — including depression, anxiety, or loneliness as clinical diagnoses.
• This program does not treat any condition. No clinical recommendations, psychotherapy, counseling, or treatment planning may be delivered by the companion AI.
• Screen results must not be communicated to members as diagnoses or presented with language that implies clinical pathology (e.g., "abnormal," "your results show you have depression"). The companion uses band labels (e.g., "moderate range") and routes the member to a qualified human.
• The companion must not substitute for a clinician-administered structured risk assessment (e.g., Columbia Suicide Severity Rating Scale, C-SSRS) or crisis intervention. PHQ-9 Item 9 is a safety trigger, not a suicide-risk assessment.
• The program must not hold itself out as an FDA-cleared or FDA-regulated medical device. It operates within the FDA general-wellness lane (FDA General Wellness Policy for Low Risk Devices, final guidance January 6, 2026).

1.3 — Regulatory Lane

This product is positioned inside the U.S. FDA General Wellness / non-device category (21st Century Cures Act §520(o)(1)(B); FDA General Wellness Policy for Low Risk Devices, final revision January 6, 2026). This is a design constraint the program holds itself to as a condition of operation. It does not represent any FDA clearance, authorization, or certification the company possesses.

The program stays wellness-exempt by design: it screens, tracks, and connects to humans — it does not diagnose, treat, or render clinical findings about named conditions. This design choice also satisfies the crisis-escalation requirement payers impose independently of FDA posture.

2.1 — Instruments in Use

All four instruments are in the public domain or freely licensed for clinical use without fee. The PHQ and GAD-7 instruments were developed by Drs. Spitzer, Williams, and Kroenke; PHQ instruments are available at phqscreeners.com with no permission required to reproduce.

2.2 — Screening Cadence

2.3 — Score Interpretation Bands (for internal routing only)

The following bands are used internally to trigger alerts and actions. They are not communicated to members as diagnoses. Members receive only a general summary ("your check-in is complete; your results have been noted") and any crisis resources required by the escalation SOP.

3.1 — Information Tier (Low Concern)

• Triggers: Check-in gap exceeding a configured number of days; UCLA-3 near-threshold (score 5); low-mood language detected in conversation that does not meet the concern or crisis threshold; member notes a change in sleep, appetite, or activity level.
• System action: Info alert placed in caregiver dashboard; no immediate notification sent.
• Human action required: Caregiver reviews alert on next dashboard login. Documents review in the alert acknowledgment field.
• Response window: [ clinical director to set — recommended: within 3 business days ]
• Documentation: Alert acknowledgment logged with reviewer name and timestamp.

3.2 — Concern Tier (Elevated Screen)

• Triggers: UCLA-3 ≥ 6 (loneliness positive screen); PHQ-2 ≥ 3 (positive depression pre-screen); PHQ-9 ≥ 10 (moderate depression); GAD-7 ≥ 10 (moderate anxiety); PHQ-9 20–27 (severe depression, non-Item-9 crisis path).
• System action: Concern alert placed in caregiver dashboard; outbox email queued to designated caregiver when email delivery is active (currently pending SES configuration — see companion technical brief).
• In-session member response: Companion acknowledges the check-in, thanks the member, and states (in friendly language): "These results have been noted and your care team will follow up with you." Companion does not convey the score or name a condition.
• Human action required: Designated caregiver or clinical staff contacts the member or arranges a clinical follow-up within the response window. Documented in alert acknowledgment.
• Response window: [ clinical director to set — recommended: within 2 business days for PHQ-9 ≥ 10; within 1 business day for PHQ-9 15+ ]
• Caregiver notification: Designated caregiver for that member. If no designated caregiver is on file, escalate immediately to the program's named human responder (see Section 5).
• Documentation: Alert acknowledgment + contact attempt log (date, method, outcome) within the care record.

3.3 — Crisis Tier — PHQ-9 Item 9 > 0 / Risk Language Detected

• Triggers: PHQ-9 Item 9 (thoughts of being better off dead or of hurting yourself in some way) answered at any value above zero; or free-text language in conversation that the companion's safety classifier identifies as indicating self-harm, suicidal ideation, or immediate harm to self or others.
• In-session member response (required language, non-negotiable):
  The companion must immediately display or speak: "I want to make sure you're safe. Please reach out for support right now — you can call or text 988 (Suicide & Crisis Lifeline) any time, 24 hours a day. If you are in immediate danger, please call 911 or go to your nearest emergency room. Would you like me to notify someone who cares about you?"
  This language is not customizable. The clinical director must confirm this language before enrollment.
• System action: Crisis alert generated in real time in the caregiver dashboard; outbox email queued as high-priority; alert cannot be dismissed without a documented resolution code.
• Human action required: Named human responder (see Section 5) acknowledges the alert and initiates contact attempt within the response window. Attempt is documented in the care record whether or not contact is successful. If contact is not successful within the window, the responder must escalate to local emergency welfare-check services.
• Response window: [ clinical director to set — recommended: < 1 hour for acknowledged alert; immediate escalation to 911/welfare check if member cannot be reached within 2 hours ]
• Caregiver notification: Both the member's designated caregiver and the program's named human responder are notified simultaneously.
• Important limitation: The companion's Item 9 response and risk-language detection are safety-net triggers only — they are not a validated suicide-risk assessment instrument. A structured clinician-administered assessment (e.g., C-SSRS) is the appropriate clinical tool and remains outside the scope of this software. The program's crisis pathway is designed to route to a human clinician immediately, not to replace one.
• Documentation: Full crisis record: trigger source (Item 9 score or risk-language classifier); timestamp; in-session response delivered; human-responder notification timestamps; contact attempts and outcomes; resolution.

3.4 — Medical Emergency

• Triggers: Member expresses acute physical emergency in conversation (chest pain, difficulty breathing, fall, unresponsiveness, etc.).
• In-session member response: Companion immediately says: "Please call 911 right now or ask someone nearby to call for you. This sounds like a medical emergency."
• System action: Crisis alert with reason "medical emergency" raised.
• Human action: Same response-window requirement as Section 3.3.

4.1 — Informed Consent Requirements

• Explicit opt-in: No health-data collection — including screening responses, check-in responses, or caregiver alerts — may be initiated without the member's or their legally authorized representative's explicit, documented, informed consent. Consent is enforced at the API layer: all health-data write operations return HTTP 403 without a valid consent record on file.
• Consent disclosure must include: (a) what data will be collected; (b) how it will be used (outcome tracking, caregiver notification, escalation); (c) who will see it (clinical staff, designated caregiver, program operator); (d) data retention period; (e) the right to withdraw at any time without penalty; (f) the limitations of the program (screening not diagnosis; not a medical device; not a substitute for clinical care).
• Withdrawal: A member may withdraw consent at any time. Withdrawal is recorded with timestamp. Prior screening records are not immediately deleted on withdrawal (the current system preserves them) but a member-facing data-deletion request initiates a purge workflow. [ clinical director and legal counsel to review purge timeline before enrollment ]
• Legally authorized representative: For members who may lack capacity to consent independently (cognitive impairment, guardianship), consent must be obtained from the legally authorized representative per applicable state law. The program operator must document the basis for representative consent.

4.2 — Data Classification & Handling

• Data classification: Screening responses, check-in data, and caregiver alerts are classified as sensitive health information and handled as potential Protected Health Information (PHI) under HIPAA from the moment of collection.
• Infrastructure: Data is stored on AWS HIPAA-eligible services (DynamoDB, Lambda). These services are covered under the AWS Business Associate Addendum (BAA) program.
• BAA requirement: A signed AWS BAA must be executed before real PHI is stored in production. The program currently holds pilot / de-identified test data only. [ program operator to execute AWS BAA via AWS Management Console before enrollment opens ]
• Encryption: Data is encrypted in transit (TLS) and at rest. Production PHI requires a customer-managed KMS key for DynamoDB encryption. [ engineering to implement CMK before production PHI is stored ]
• Access controls: Least-privilege IAM. The care-engine Lambda role is scoped exclusively to the six care DynamoDB tables. No cross-service access.
• Audit log: Every health-data action — consent grant, screening submission, alert creation, alert acknowledgment, consent withdrawal — is written to an append-only audit table (boojee-care-audit) with actor, timestamp, and action detail. The audit table is not modifiable after write.
• Retention period: [ clinical director and legal counsel to specify — recommended: 7 years from last date of service, consistent with HIPAA minimum ]
• Breach response: Any suspected or confirmed data breach triggers the program operator's HIPAA breach notification procedures. [ operator to attach HIPAA breach response plan here before enrollment ]

4.3 — Caregiver Access Controls

• The caregiver dashboard surfaces alerts, trends, and outcome reports only for members for whom the caregiver is designated. Access is not anonymous: caregiver authentication is required before viewing any member data.
• The caregiver dashboard is a [ noindex, credential-gated internal tool — production deployment must add authentication layer before real PHI is visible ]. The current demo dashboard does not authenticate and is for demonstration purposes only.
• Health plan or payer outcome reports must be de-identified at the member level (aggregated) unless the plan's BAA and member consent explicitly permit individual-level sharing.

5.1 — Supervising Clinician Role

A named, licensed clinical director (doctoral-level psychologist, MD psychiatrist, or equivalent licensed clinician) must be formally appointed before any real member enrollment. The clinical director's responsibilities include:

• Review, amend, and sign off on this protocol document in its entirety. No section takes effect unsigned.
• Certify that the companion AI's current response policy (system prompt, guardrails, safety classifiers) satisfies the clinical-boundaries constraints in Section 1.2 before enrollment opens.
• Define and approve the screening cadence in Section 2.2 for the enrolled population.
• Set and approve the escalation response-time windows in Section 3 (all [ placeholder ] values above).
• Review and approve the in-session crisis response language in Section 3.3.
• Name the program's human responder(s) — the individuals (by role and contact) who are on-call to respond to Concern and Crisis alerts within the defined windows.
• Design or approve a fidelity/concordance study to compare conversational-mode and standardized-mode screening scores when the program has sufficient enrollment data.
• Participate in outcome report review on the cadence specified in Section 5.2.
• Be the named clinical contact for payer compliance inquiries.

5.2 — Review & Audit Cadence

5.3 — Human Responder Register

The following named individuals are designated as human responders for Concern and Crisis alerts. These fields must be completed before enrollment: