{"v":[{"id":1510,"html_url":"https:\/\/www-s01.apinet.com\/codeforge\/apiintl\/hhmanager\/issues\/167#issuecomment-1510","pull_request_url":"","issue_url":"https:\/\/www-s01.apinet.com\/codeforge\/apiintl\/hhmanager\/issues\/167","user":{"id":1,"login":"charles","login_name":"","source_id":0,"full_name":"Charles Willgren","email":"charles@noreply.www-s01.apinet.com","avatar_url":"https:\/\/www-s01.apinet.com\/codeforge\/avatars\/d3c894f7297c5a18eb3f6ac837c335b11a00aa9cc0961323771632b1e2d61bb2","html_url":"https:\/\/www-s01.apinet.com\/codeforge\/charles","language":"","is_admin":false,"last_login":"0001-01-01T00:00:00Z","created":"2025-12-08T10:03:41-06:00","restricted":false,"active":false,"prohibit_login":false,"location":"","pronouns":"","website":"","description":"","visibility":"public","followers_count":0,"following_count":0,"starred_repos_count":0,"username":"charles"},"original_author":"","original_author_id":0,"body":"## Thinking it through: emergency priority list by area\n\n**Short version.** We can ship a useful first version **without a map**, using VESTA fields we already load and the county we already hold. After that comes geocoding with the local Nominatim, plus a map you can select from by county, polygon or radius. Last, the answers collected on the V2 Emergency\/Disaster form take over from VESTA's coarser fields. The priority should be **tiers with visible reasons, not a single score**, and the rules belong to the customer.\n\n---\n\n### 1. What VESTA already gives us\n\n\"Bed-ridden\" is not a VESTA field. Several fields come close, and all of them already land in `hh_member_record.detail_enc` on the report path (Members export \/ Master List):\n\n| Field | What it tells us | Notes |\n|---|---|---|\n| `cliclass` | HHSC client classification (Class I = priority) | The closest thing VESTA has to an emergency tier. Our glossary text for Class III\/IV (`code\/glossary.inc.php`) is a guess and should be checked with the customer before anything ranks on it. |\n| `priority` (export) \/ `Priority` bool (API roster) | Priority-client flag | The API roster returns `Priority`, but it isn't in `VESTA_MEMBER_CONTRACT`. Adding it as a tolerated key costs one line. |\n| ADL flags + `freq_*`: `transfer`, `ambulation`, `walking`, `toileting`, `feeding_eating` | Mobility proxy: transfer + ambulation + toileting all assigned is roughly \"cannot leave without hands-on help\" | These are *tasks on the plan*, not a mobility assessment. Label them \"needs help with transfer \/ walking\", never \"bed-bound\". |\n| `dnr` | DNR on file | Responders need to know it. It is not a priority input. |\n| `able_to_respond` | Language, or \"Unable to Respond\" | \"Unable to respond\" should raise priority: the client can't answer a welfare call. |\n| `county` (Master List; MemberPlus for API) | Area selection **without geocoding** | Already a plaintext column on `hh_member_record`. |\n| `diagnosis` (Master List, free text) | Words like oxygen, dialysis, ventilator, insulin | Free text. Use it only as a \"check this\" hint, never as a rank input. |\n| `hh_auth` weekly hours \/ program | Heavier care plans | Secondary signal. |\n| `hh_calendar` \/ `sp-schedule` | Who has a visit in the next 24\u201372 h, and which attendant | Covers \"whose care is interrupted\" and \"which attendants to call\". |\n| Emergency contact, phone, address | The call list itself | Already stored (encrypted). |\n\n\u26a0\ufe0f **API cutover gap.** The live API roster carries **no** `cliclass`, `DNR`, ADL pairs, `ABLE_TO_RESPOND` or `County` (VestaAPIPlan \u00a73.1). The Master List enrichment brings back the ADL flags and county. `cliclass` and `DNR` only come back through **MemberPlus**: one call per member, throttling not yet known (Q7\/Q8). If this feature leans on `cliclass`, an agency moving to the API loses it. We have to decide this **before cutover**, not after.\n\n**First step: measure.** How many open clients per agency actually have `cliclass`, `priority`, the ADL flags and `county` filled in? I tried to count this from the local DB, but that means decrypting `detail_enc`, and I didn't do it without your OK. The count should be a read-only script that prints aggregate numbers only, run where we're allowed to read PHI.\n\n### 2. What the forms add (V2), and what they could add\n\nThe **Emergency \/ Disaster Preparedness Plan** (`emergency-disaster-form`) is the actual triage instrument. It already asks:\n\n- `disaster_class` I\u2013IV: the state's emergency scale. Class I is \"unable to withstand any interruption in power supply\u2026\". The answer is shared with the CIS `classification` as `shared.client.emergency_class`, and the CIS version adds \"Bed confined \/ Ambulatory\".\n- `special_needs` (yes\/no), `has_transportation` + `transportation_by_whom`, `evacuating_with_count`, `has_pet`.\n- `registered_211_stear` \/ `stear_status`.\n- DME + DME phone, physician, pharmacy, emergency contact.\n\n**Possible additions.** These would be interview questions, not new paper fields; they need a ruling under \"one meaning is one question\":\n\n- Power-dependent equipment: oxygen concentrator, ventilator, powered wheelchair or lift, hospital bed, home dialysis.\n- Medication that needs refrigeration (insulin).\n- Dialysis center and schedule (an outage interrupts *their* care, not just ours).\n- Mobility, stated directly: bed-bound \/ wheelchair \/ walker \/ independent.\n- Lives alone (nothing in VESTA says this; `evacuating_with_count` comes close).\n- Hearing, vision or cognitive impairment that affects receiving a warning.\n\n**Freshness matters.** A form answer is only as current as the last signed visit, which can be up to a year old. Every value on the emergency list should show \"as of {date}, from {VESTA | visit}\".\n\n### 3. The priority rule\n\n- **Tiers, each with reasons shown as chips:** \"Class I (visit 3\/2026)\", \"Oxygen\", \"No transportation\", \"Unable to respond\", \"Visit due tomorrow\". Staff need to *see why* someone is near the top. An opaque score invites distrust and quiet overrides.\n- **Order of precedence:** form `disaster_class` from a signed visit within 12 months \u2192 VESTA `cliclass` \/ `priority` \u2192 ADL proxy. Then modifiers inside a tier: power-dependent, no transportation, unable to respond, lives alone, care scheduled during the event window.\n- **Code layout:** a pure rule file (`code\/hh_emergency_rules.inc.php`) with a standalone test, plus a block per rule in a short customer-facing sheet, the same way FlagRules.md works. The customer writes the rule; we transcribe it.\n- **Per-event overrides:** a coordinator can pin a client up or down for one event without changing the rule.\n\n### 4. Geocoding (shared with RoutePlan.md, which is still plan-only)\n\nRoutePlan \u00a75\u2013\u00a77 already designs this, and the emergency list should be its first consumer:\n\n- `hh_geocode` exists and **nothing writes it**. Alter it **before** it holds anything: `lat_enc`\/`lng_enc` (a home coordinate is an address, so it's PHI), `geohash5` as a prefilter index (not de-identification), `precision` (rooftop \/ interpolated \/ centroid \/ none), `address_hash` so we only re-geocode when the address changes, and `source`.\n- `scripts\/geocode-members.php` against the local Nominatim (`NOM_HOST`\/`NOM_PORT`). Run it after `vesta-api-sync.php` and after the report-path load.\n- **Expect a long tail in the Valley.** Rural routes, colonias, PO boxes and \"FM 1234 & \u2026\" addresses will fall back to a ZIP or city centroid. We need:\n  - a coverage report per agency and branch (rooftop \/ centroid \/ failed), shown with the list so \"47 clients in this county could not be placed\" is visible;\n  - **manual pin correction**: staff drag the pin, it saves as `source = 'manual'`, and it stays until the address changes;\n  - centroid-only clients **included in county selection** (by VESTA county) but marked as approximate in radius and polygon selections.\n- **Tiles:** `MAP_TILE_URL` falls back to `tile.openstreetmap.org` when unset. For this page the fallback should fail closed (no map rather than a public tile server), so a misconfigured box never shows public servers which areas staff are looking at during an event. The reassessment planner's map is still switched off (\"tile server still building\"). Finishing that build is a prerequisite here, same as for routing.\n\n### 5. Choosing the area\n\n| Mode | How |\n|---|---|\n| **County** | Works on day one from the VESTA `county` text, no coordinates needed. Once geocoded, a point-in-polygon county check that **disagrees** with VESTA's county is worth flagging as a data-quality item. |\n| **Radius** | Click a point or search an address (local Nominatim), set the miles. Haversine on decrypted coordinates, prefiltered by geohash cells. |\n| **Polygon** | Draw on the map (Leaflet + leaflet-geoman or Leaflet.draw, loaded from an allowed CDN at an exact version, or vendored like PDF.js). Point-in-polygon in pure PHP, tested. |\n| **ZIP \/ branch \/ HHSC region** | Cheap filters. `DADS_Indv_Region` is on the API roster too. |\n| **Imported shape** (later) | GeoJSON\/KML upload from county emergency management, or **NWS warning polygons** from `api.weather.gov` (a fetch of public alerts that sends nothing of ours). For example: \"everyone inside tonight's flood warning, Class I first\". |\n\nBoundaries: Census TIGER\/Line counties and ZCTAs (public domain), loaded once into a `geo_area` table. They aren't PHI.\n\n**Scale.** Coordinates are encrypted, so MariaDB spatial indexes can't help. That's fine: one agency's open clients number in the thousands, sodium decryption at that volume takes milliseconds, and a geohash\/bounding-box prefilter cuts it down further. Don't trade encryption for `ST_Contains`.\n\n### 6. The output\n\n- **Ranked list + map** colored by tier, filtered by the selected area and scoped by `hh_member_scope()` (administrators see everyone, field supervisors their caseload).\n- **Call sheet export (PDF\/CSV):** name, phone, emergency contact, address, tier + reasons, DME, assigned attendant + phone, next scheduled visit. **Print before landfall**, because power and internet may be gone when it's needed. Every export goes through the PHI audit.\n- **Event tracking (phase 3):** `emergency_event` (name, area shape, opened\/closed) + `emergency_event_client` (status: not reached \/ safe \/ needs help \/ evacuated \/ hospitalized, who called and when, note). Turns the list into a welfare-check board several staff can work at once. It also produces the after-action record surveyors ask for.\n- **Attendants are affected too.** `hh_attendant` has addresses. \"Which attendants live inside the shape\" tells the coordinator whose shifts will drop.\n- **Permission:** our own right, e.g. `client.emergency\/View` (+ `\/Manage` for events), classified in `code\/perms.inc.php` and seeded only when the screen checks it. Staff-only by name.\n\n### 7. Suggested order\n\n1. **Phase 0, decide and measure:** fill rates of `cliclass` \/ `priority` \/ ADL \/ `county` per agency; customer confirms the tier rule and what Class I\u2013IV mean in their practice; decide `cliclass`\/`DNR` for API agencies (MemberPlus vs keeping the Members export); add `Priority` to the API roster mapping.\n2. **Phase 1, no map:** priority list filtered by county \/ branch \/ ZIP, with reasons and an \"as of\" source, plus the printable call sheet. Delivers most of the value and needs no new infrastructure.\n3. **Phase 2, geo:** finish the tile server; alter `hh_geocode` + `geocode-members.php` + coverage report + manual pin; map with radius and polygon selection; TIGER counties.\n4. **Phase 3, forms + events:** form `disaster_class` and the special-needs answers override VESTA in the rule; the extra interview questions above (pending a decision); event tracking board; attendants-in-area.\n5. **Phase 4:** NWS alert polygons; STEAR registration reconciliation (\"Class I and not registered with STEAR\" is an action item before hurricane season).\n\n### Questions for the customer\n\n1. When an emergency happens today, what do they do? Is there a spreadsheet or a list we should match?\n2. Does `cliclass` in VESTA mean what we think it means, and is it kept current?\n3. Do they want the extra special-needs questions (power-dependent equipment, lives alone, \u2026) added to the visit, even though the paper form doesn't print them?\n4. Who works the list during an event: office staff only, or field supervisors for their own caseloads?\n5. Should attendants be on the same map (whose shifts will drop)?","assets":[],"created_at":"2026-10-07T23:32:28-05:00","updated_at":"2026-10-07T23:32:28-05:00"}]}