{"v":"

Where the code stands today<\/h2>\n

Per visit type, part of this is already handled and part is not.<\/p>\n\n\n\n\n\n\n\n\n\n
Varies by visit type<\/th>\nToday<\/th>\n<\/tr>\n<\/thead>\n
Which forms<\/strong><\/td>\n\u2705<\/span> The packet (docs\/form-packets\/*.json<\/code>) decides, including when<\/code> choices (PAS\/PHC vs PCS consent on the program).<\/td>\n<\/tr>\n
Which questions, order, wording, conditions<\/strong><\/td>\n\u2705<\/span> The structure allows it: there is one interview file per packet (docs\/form-v2-interviews\/{PACKET}.json<\/code>). But only SOC_AO.json<\/code> exists<\/strong>. The other 14 packets have no interview yet.<\/td>\n<\/tr>\n
Answer choices<\/strong><\/td>\n\u26a0\ufe0f<\/span> Only partly. Choices come from the form definition, which is global. An interview can relabel a choice and add option_info<\/code>, but it can't offer a subset<\/strong> of the choices.<\/td>\n<\/tr>\n
Fixed answers (never asked)<\/strong><\/td>\n\u274c<\/span> Not per visit type. A derived<\/code> + fixed<\/code> element in code\/form_v2_shared.inc.php<\/code> is install-wide<\/strong>. Examples are supervision level = Non-RN and frequency = Q12\/PRN. Nothing lets a fixed value depend on the visit type.<\/td>\n<\/tr>\n
Fixed answers that are shown<\/em><\/strong><\/td>\n\u274c<\/span> A fixed<\/code> element is never shown. A step's shows<\/code> can only list values pinned from the record (auth.*<\/code> etc.), not derived ones.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Concrete cases already in the files<\/h3>\n
    \n
  • Client Information Sheet visit_type<\/code><\/strong> (Start of Care \/ Annual Reassessment) is currently asked<\/em> in SOC_AO, with help text "almost always Start of Care". It should be fixed by the visit type: SOC_AO \u2192 soc<\/code>, AR \u2192 ar<\/code>.<\/li>\n
  • 3040 attendant_{a,b,c}_visit_type<\/code><\/strong> (AO \/ SV \/ SA) is asked once per attendant. It is probably fixed by the visit type (SOC_AO \u2192 AO, SV \u2192 SV\u2026). There may be an exception when one attendant is new and another is being supervised.<\/li>\n
  • 3040 visit_setting<\/code><\/strong> has help text "Tick it at a first visit", so it is also visit-type dependent.<\/li>\n<\/ul>\n

    Ideas<\/h2>\n
      \n
    1. \n

      Make the visit type a fact.<\/strong> Add a pinned visit.packet_code<\/code> (or visit.type<\/code>) to form_packet_facts()<\/code> \/ the visit's pins. Then every existing mechanism can key off it:<\/p>\n

        \n
      • conditions: {"==": [{"field": "visit.type"}, "AR"]}<\/code><\/li>\n
      • shows<\/code> can show it ("This is an Annual Reassessment")<\/li>\n
      • a derive can map it, e.g. derive: {op: "map", from: "visit.type", values: {SOC_AO: "soc", AR: "ar"}}<\/code><\/li>\n<\/ul>\n

        This reuses the existing map<\/code> op (#105) instead of inventing a new concept.<\/p>\n<\/li>\n

      • \n

        Fixed answers per visit type: choose the file that declares them.<\/strong><\/p>\n

          \n
        • (a)<\/strong> Use a map<\/code>-from-visit-type derive in form_v2_shared.inc.php<\/code> (the idea above). Everything stays in one place, but that file starts knowing about packets.<\/li>\n
        • (b)<\/strong> Add a fixed<\/code> block to each interview file ("fixed": {"form.client-information-sheet.visit_type": "soc"}<\/code>), with an optional "show": true<\/code> per entry for answers the supervisor should see. This keeps "what this visit type does" in one file per visit type, as interviews are now.<\/li>\n<\/ul>\n

          I lean towards (b)<\/strong> for anything that varies per visit type. I'd keep form_v2_shared<\/code> fixed<\/code> for things that never vary at this customer. The publish check should refuse a key that is both fixed in the interview and asked in it.<\/p>\n<\/li>\n

        • \n

          Shown vs hidden fixed answers:<\/strong> extend shows<\/code> to accept a fixed\/derived element (read-only, in words, as pinned values are shown now). Anything not listed there stays silent and only prints.<\/p>\n<\/li>\n

        • \n

          Choice subsets:<\/strong> allow an interview question to carry "only": ["ao", "sv"]<\/code>. The rule would be that it may narrow a form's choices but never add one, the same principle as "required<\/code> can only be made stricter". If only one choice is left, it becomes a fixed answer.<\/p>\n<\/li>\n

        • \n

          Write the next interview to test the design.<\/strong> AR is the obvious one, since it shares most forms with SOC_AO. Writing AR.json<\/code> will show exactly which SOC_AO questions turn into fixed or shown answers, and which choices narrow.<\/p>\n<\/li>\n<\/ol>\n

          Questions<\/h2>\n
            \n
          1. Combined visits.<\/strong> V2 runs one packet per visit<\/strong> today, even though form_packet_merge()<\/code> can union several. Will staff ever do two visit types at once (e.g. AR + SV, or SOC + a transfer)? If so, two visit types may fix the same box differently (CIS visit_type<\/code> = soc vs ar). We'd need a precedence rule, or the publish check refuses the combination. Interviews would also need merging, which nothing does yet.<\/li>\n
          2. Which fixed answers should the supervisor see?<\/strong> Is the rule "show anything the client is told or signs" and hide administrative boxes? Or does the customer want to list them one by one?<\/li>\n
          3. 3040 attendant visit type:<\/strong> is it always the same for every attendant on a visit, or can one attendant be AO while another is SV on the same visit?<\/li>\n
          4. Is there a list from the customer<\/strong> of per-visit-type differences, or do we derive it from the packets and the paper? The Compliance RVSD. 5.13.2025<\/code> checklist names the forms but not the answers.<\/li>\n
          5. Should a supervisor ever be able to override<\/strong> a fixed answer (e.g. a visit started as the wrong type)? Or is the answer always "start the right visit type"? I'd suggest the latter, so the paper can't disagree with the visit record.<\/li>\n<\/ol>\n"}