{"v":"

Thinking it through: emergency priority list by area<\/h2>\n

Short version.<\/strong> We can ship a useful first version without a map<\/strong>, 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<\/strong>, and the rules belong to the customer.<\/p>\n\n

1. What VESTA already gives us<\/h3>\n

"Bed-ridden" is not a VESTA field. Several fields come close, and all of them already land in hh_member_record.detail_enc<\/code> on the report path (Members export \/ Master List):<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Field<\/th>\nWhat it tells us<\/th>\nNotes<\/th>\n<\/tr>\n<\/thead>\n
cliclass<\/code><\/td>\nHHSC client classification (Class I = priority)<\/td>\nThe closest thing VESTA has to an emergency tier. Our glossary text for Class III\/IV (code\/glossary.inc.php<\/code>) is a guess and should be checked with the customer before anything ranks on it.<\/td>\n<\/tr>\n
priority<\/code> (export) \/ Priority<\/code> bool (API roster)<\/td>\nPriority-client flag<\/td>\nThe API roster returns Priority<\/code>, but it isn't in VESTA_MEMBER_CONTRACT<\/code>. Adding it as a tolerated key costs one line.<\/td>\n<\/tr>\n
ADL flags + freq_*<\/code>: transfer<\/code>, ambulation<\/code>, walking<\/code>, toileting<\/code>, feeding_eating<\/code><\/td>\nMobility proxy: transfer + ambulation + toileting all assigned is roughly "cannot leave without hands-on help"<\/td>\nThese are tasks on the plan<\/em>, not a mobility assessment. Label them "needs help with transfer \/ walking", never "bed-bound".<\/td>\n<\/tr>\n
dnr<\/code><\/td>\nDNR on file<\/td>\nResponders need to know it. It is not a priority input.<\/td>\n<\/tr>\n
able_to_respond<\/code><\/td>\nLanguage, or "Unable to Respond"<\/td>\n"Unable to respond" should raise priority: the client can't answer a welfare call.<\/td>\n<\/tr>\n
county<\/code> (Master List; MemberPlus for API)<\/td>\nArea selection without geocoding<\/strong><\/td>\nAlready a plaintext column on hh_member_record<\/code>.<\/td>\n<\/tr>\n
diagnosis<\/code> (Master List, free text)<\/td>\nWords like oxygen, dialysis, ventilator, insulin<\/td>\nFree text. Use it only as a "check this" hint, never as a rank input.<\/td>\n<\/tr>\n
hh_auth<\/code> weekly hours \/ program<\/td>\nHeavier care plans<\/td>\nSecondary signal.<\/td>\n<\/tr>\n
hh_calendar<\/code> \/ sp-schedule<\/code><\/td>\nWho has a visit in the next 24\u201372 h, and which attendant<\/td>\nCovers "whose care is interrupted" and "which attendants to call".<\/td>\n<\/tr>\n
Emergency contact, phone, address<\/td>\nThe call list itself<\/td>\nAlready stored (encrypted).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u26a0\ufe0f<\/span> API cutover gap.<\/strong> The live API roster carries no<\/strong> cliclass<\/code>, DNR<\/code>, ADL pairs, ABLE_TO_RESPOND<\/code> or County<\/code> (VestaAPIPlan \u00a73.1). The Master List enrichment brings back the ADL flags and county. cliclass<\/code> and DNR<\/code> only come back through MemberPlus<\/strong>: one call per member, throttling not yet known (Q7\/Q8). If this feature leans on cliclass<\/code>, an agency moving to the API loses it. We have to decide this before cutover<\/strong>, not after.<\/p>\n

First step: measure.<\/strong> How many open clients per agency actually have cliclass<\/code>, priority<\/code>, the ADL flags and county<\/code> filled in? I tried to count this from the local DB, but that means decrypting detail_enc<\/code>, 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.<\/p>\n

2. What the forms add (V2), and what they could add<\/h3>\n

The Emergency \/ Disaster Preparedness Plan<\/strong> (emergency-disaster-form<\/code>) is the actual triage instrument. It already asks:<\/p>\n

    \n
  • disaster_class<\/code> 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<\/code> as shared.client.emergency_class<\/code>, and the CIS version adds "Bed confined \/ Ambulatory".<\/li>\n
  • special_needs<\/code> (yes\/no), has_transportation<\/code> + transportation_by_whom<\/code>, evacuating_with_count<\/code>, has_pet<\/code>.<\/li>\n
  • registered_211_stear<\/code> \/ stear_status<\/code>.<\/li>\n
  • DME + DME phone, physician, pharmacy, emergency contact.<\/li>\n<\/ul>\n

    Possible additions.<\/strong> These would be interview questions, not new paper fields; they need a ruling under "one meaning is one question":<\/p>\n

      \n
    • Power-dependent equipment: oxygen concentrator, ventilator, powered wheelchair or lift, hospital bed, home dialysis.<\/li>\n
    • Medication that needs refrigeration (insulin).<\/li>\n
    • Dialysis center and schedule (an outage interrupts their<\/em> care, not just ours).<\/li>\n
    • Mobility, stated directly: bed-bound \/ wheelchair \/ walker \/ independent.<\/li>\n
    • Lives alone (nothing in VESTA says this; evacuating_with_count<\/code> comes close).<\/li>\n
    • Hearing, vision or cognitive impairment that affects receiving a warning.<\/li>\n<\/ul>\n

      Freshness matters.<\/strong> 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}".<\/p>\n

      3. The priority rule<\/h3>\n
        \n
      • Tiers, each with reasons shown as chips:<\/strong> "Class I (visit 3\/2026)", "Oxygen", "No transportation", "Unable to respond", "Visit due tomorrow". Staff need to see why<\/em> someone is near the top. An opaque score invites distrust and quiet overrides.<\/li>\n
      • Order of precedence:<\/strong> form disaster_class<\/code> from a signed visit within 12 months \u2192 VESTA cliclass<\/code> \/ priority<\/code> \u2192 ADL proxy. Then modifiers inside a tier: power-dependent, no transportation, unable to respond, lives alone, care scheduled during the event window.<\/li>\n
      • Code layout:<\/strong> a pure rule file (code\/hh_emergency_rules.inc.php<\/code>) 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.<\/li>\n
      • Per-event overrides:<\/strong> a coordinator can pin a client up or down for one event without changing the rule.<\/li>\n<\/ul>\n

        4. Geocoding (shared with RoutePlan.md, which is still plan-only)<\/h3>\n

        RoutePlan \u00a75\u2013\u00a77 already designs this, and the emergency list should be its first consumer:<\/p>\n

          \n
        • hh_geocode<\/code> exists and nothing writes it<\/strong>. Alter it before<\/strong> it holds anything: lat_enc<\/code>\/lng_enc<\/code> (a home coordinate is an address, so it's PHI), geohash5<\/code> as a prefilter index (not de-identification), precision<\/code> (rooftop \/ interpolated \/ centroid \/ none), address_hash<\/code> so we only re-geocode when the address changes, and source<\/code>.<\/li>\n
        • scripts\/geocode-members.php<\/code> against the local Nominatim (NOM_HOST<\/code>\/NOM_PORT<\/code>). Run it after vesta-api-sync.php<\/code> and after the report-path load.<\/li>\n
        • Expect a long tail in the Valley.<\/strong> Rural routes, colonias, PO boxes and "FM 1234 & \u2026" addresses will fall back to a ZIP or city centroid. We need:\n
            \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;<\/li>\n
          • manual pin correction<\/strong>: staff drag the pin, it saves as source = 'manual'<\/code>, and it stays until the address changes;<\/li>\n
          • centroid-only clients included in county selection<\/strong> (by VESTA county) but marked as approximate in radius and polygon selections.<\/li>\n<\/ul>\n<\/li>\n
          • Tiles:<\/strong> MAP_TILE_URL<\/code> falls back to tile.openstreetmap.org<\/code> 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.<\/li>\n<\/ul>\n

            5. Choosing the area<\/h3>\n\n\n\n\n\n\n\n\n\n
            Mode<\/th>\nHow<\/th>\n<\/tr>\n<\/thead>\n
            County<\/strong><\/td>\nWorks on day one from the VESTA county<\/code> text, no coordinates needed. Once geocoded, a point-in-polygon county check that disagrees<\/strong> with VESTA's county is worth flagging as a data-quality item.<\/td>\n<\/tr>\n
            Radius<\/strong><\/td>\nClick a point or search an address (local Nominatim), set the miles. Haversine on decrypted coordinates, prefiltered by geohash cells.<\/td>\n<\/tr>\n
            Polygon<\/strong><\/td>\nDraw 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.<\/td>\n<\/tr>\n
            ZIP \/ branch \/ HHSC region<\/strong><\/td>\nCheap filters. DADS_Indv_Region<\/code> is on the API roster too.<\/td>\n<\/tr>\n
            Imported shape<\/strong> (later)<\/td>\nGeoJSON\/KML upload from county emergency management, or NWS warning polygons<\/strong> from api.weather.gov<\/code> (a fetch of public alerts that sends nothing of ours). For example: "everyone inside tonight's flood warning, Class I first".<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            Boundaries: Census TIGER\/Line counties and ZCTAs (public domain), loaded once into a geo_area<\/code> table. They aren't PHI.<\/p>\n

            Scale.<\/strong> 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<\/code>.<\/p>\n

            6. The output<\/h3>\n
              \n
            • Ranked list + map<\/strong> colored by tier, filtered by the selected area and scoped by hh_member_scope()<\/code> (administrators see everyone, field supervisors their caseload).<\/li>\n
            • Call sheet export (PDF\/CSV):<\/strong> name, phone, emergency contact, address, tier + reasons, DME, assigned attendant + phone, next scheduled visit. Print before landfall<\/strong>, because power and internet may be gone when it's needed. Every export goes through the PHI audit.<\/li>\n
            • Event tracking (phase 3):<\/strong> emergency_event<\/code> (name, area shape, opened\/closed) + emergency_event_client<\/code> (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.<\/li>\n
            • Attendants are affected too.<\/strong> hh_attendant<\/code> has addresses. "Which attendants live inside the shape" tells the coordinator whose shifts will drop.<\/li>\n
            • Permission:<\/strong> our own right, e.g. client.emergency\/View<\/code> (+ \/Manage<\/code> for events), classified in code\/perms.inc.php<\/code> and seeded only when the screen checks it. Staff-only by name.<\/li>\n<\/ul>\n

              7. Suggested order<\/h3>\n
                \n
              1. Phase 0, decide and measure:<\/strong> fill rates of cliclass<\/code> \/ priority<\/code> \/ ADL \/ county<\/code> per agency; customer confirms the tier rule and what Class I\u2013IV mean in their practice; decide cliclass<\/code>\/DNR<\/code> for API agencies (MemberPlus vs keeping the Members export); add Priority<\/code> to the API roster mapping.<\/li>\n
              2. Phase 1, no map:<\/strong> 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.<\/li>\n
              3. Phase 2, geo:<\/strong> finish the tile server; alter hh_geocode<\/code> + geocode-members.php<\/code> + coverage report + manual pin; map with radius and polygon selection; TIGER counties.<\/li>\n
              4. Phase 3, forms + events:<\/strong> form disaster_class<\/code> and the special-needs answers override VESTA in the rule; the extra interview questions above (pending a decision); event tracking board; attendants-in-area.<\/li>\n
              5. Phase 4:<\/strong> NWS alert polygons; STEAR registration reconciliation ("Class I and not registered with STEAR" is an action item before hurricane season).<\/li>\n<\/ol>\n

                Questions for the customer<\/h3>\n
                  \n
                1. When an emergency happens today, what do they do? Is there a spreadsheet or a list we should match?<\/li>\n
                2. Does cliclass<\/code> in VESTA mean what we think it means, and is it kept current?<\/li>\n
                3. 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?<\/li>\n
                4. Who works the list during an event: office staff only, or field supervisors for their own caseloads?<\/li>\n
                5. Should attendants be on the same map (whose shifts will drop)?<\/li>\n<\/ol>\n"}