...
The core record of visits. This is the trunk of the tree.
Many of the following will have a program_visit_activity_id field which refers back to the id field of this table.
On anonymized solution, would convert client_id to a one-way-hashed alphanumeric string to allow uniquely identifying clients, but not tying them to their visible L2F IDs.
These records include a is_completed field that is set to true only when a visit has been fully completed. The data may include scheduled appointments that a client never showed up for. (eg- is_completed = false, is_appointment = true).
These records include a total_members column. This is NOT a count of the members of the household that participated in the visit, but instead the number of members in the household as a whole. For example:
Link2Feed has the ability in the UI to select which clients in a household were served, in this case there may be three l2f_test_program_visit_household_members records tied to this program_visit_activity_id, but the total_members field may have the value 5. This is not an error, it simply states that “This is a household of 5, but only 3 people participated in this visit.”
There are also some programs (like CSFP) which allow only one member of the household to be the visitor of record for each visit. In this case, there will only be one l2f_test_program_visit_household_members record tied to this program_visit_activity_id, but other members of the household may be accounted in total_members. In a household of two seniors, each receiving CSFP services, there may well be two l2f_test_program_visit_activities records for the same day, with the same household_id, but different client_id, and each only having one l2f_test_program_visit_household_members associated record, but a total_members count of 2. This does not mean 4 people visited, It meant that the same household of 2 people was served twice: the two seniors living together.
Some of these records will be missing program_id, module_id, and some other details. These records are used in our system to tie to a survey or assessment response so that demographic details of survey and assessment responders can be included in the survey and assessment exports. We record these in a way similar to a “visit snapshot” so that they export easily, but these are not actual program visits in the same way that someone receiving food is a program visit, these are used by the survey and assessment systems. In the future, if we expose our survey and assessment systems to the API layer, this link will be more clear, and this data will be more useful, but for now it can effectively be ignored.
l2f_test_program_visit_household_addresses
...