Looking after people during social distancing

Hi All,

I’m using TBX to manage people at church now that church is no longer meeting due to COVID-19. We have many high risk people (due to age), many with known health problems, and many who will now be isolated. We also have a group of volunteers that will contact people.

I have done the following:

  1. Added all the people in outline form with their details as KA.
  2. I’ve added KA for volunteers that shows all the volunteers.
  3. I’ve added KA for high risk, known health problems and isolated.
  4. I’ve created an agent to show only those in these categories.
  5. I’ve added a KA for those who are responsible for each person.
  6. I’ve created an agent for each volunteer that shows those they are responsible for.

So far so good it’s all working.

I’m now trying to work out how to track when people have been contacted. Our current guideline is that each person is contacted at least once in 3 days. The volunteers let me know when they have done so. As this level of care may persist for at least 3 months (I’m in the UK) I have a couple of questions.

  1. How do I log when a person has been contacted? Currently I create a note inside their name that has date and method of contact.
  2. How do I stop them showing in the volunteer agent if they have been contacted in the last 3 days or how do I create a dashboard to track who has not been contacted in the last 3 days?

Many thanks for your kind help.

I would do something like this:

  1. Create a stamp that does two things. First, schedules the next call. Second, makes a record of the call just made. When the call is made, invoke the stamp on the person’s note. The stamp would read like this:

$CallDate = date("today + 3 days"); $CallRecord = $CallRecord +"\n"+ date("today")

  1. Create an agent that reveals people who need calls. Query would be something like this:

$CallDate > date("today") & $CallDate == date("today")

See here for more on date comparisons

You might also have this agent turn notes red or something like that.

@derekvan Many thanks!

A quick question:

  1. $CallRecord is an attribute. Will it keep adding and storing new data? I don’t need to put that into a note?

You could do it either way. The attribute can hold the running record of data, and you can copy that data into a note if desired. Or you can modify the stamp to something like this:

$CallDate = date("today + 3 days"); $Text = $Text +"\n"+ date("today")

This would store the record in the text of the note. You could even then write additional notes about the call if you wanted there, which might be a good approach. These notes wouldn’t be wiped out by the next stamp, because all existing text is preserved before the new date stamp is added. If you wanted to store it in the text of another note, or create a new note with the text, you’d need to do it another way (which I can’t think of off the top of my head this moment–sorry!).

Consider the footnotes feature. Or the new ziplinks method allows linking to an existing (or made-new) note and supplying $Text for the target note. The latter is good if you’re a good touch-typist.

@derekvan Thanks Again1

With your help I have got this to work the way I need. The code for the stamp is:

$ContactLastDate = date("today"); 
$Text = $Text +"\n"+ date("today");

I then run the query on the volunteer:

inside("People") & $Responsible.contains("name") 
& ($ContactLastDate==date("today - 3 days")
|$ContactLastDate=="never") | $NeedToCall=="true"

The $NeedTCall is simply to circumvent the system as I may need to call the person about something else.

One area that’s causing a slight problem is date parsing.

If now is 20/03/2020 15:00, then I would expect the query to show entries 17/03/2020 14:58, but not 17/03/2020 15:45. However this is untrue. I suspect that the today - 3 days works from a different time than the one in the $ContactLastDate attribute?

This is an interesting task and a model that may be useful to others in the current pandemic.

Reading @svsmailus general description, other things the document may help you with is producing ‘call lists’ that can be exported as HTML (or some other format) to help your helpers. The data powering the exports with be things like date of last/next message, the additional affordance being a mechanism for you to promulgate the information more widely.

Good luck with the project and do ask any additional questions if they arise.

Thanks Mark, but I prefer having one note per person with the new date being appended with notes where necessary.

Times are normally included in comparisons, I think, and can make things more complicated.

Presumably, the actual time of the call doesn’t matter for the comparison itself, only the fact that the last call was sometime on Tuesday and it’s now Friday so they need another call today. So you could use a query similar to

$LastContacted.format("l") < date("today - 2 days").format("l")

At least this worked when I tested it a couple of hours ago…

That format string forces both sides just to use the date alone (“l” is the local short date form from your computer’s preferences, e.g. 20/03/2020 – or more strictly, it forces both times to 00:00 perhaps?).

If you do want it to be a strict 72 hours rather than 3 calendar days, then you could use the same syntax but with a suitable time format string to make sure both sides are using the same basis.

No problem (and sorry I missed your last as I was typing my msg). What works for you is best.

Date queries can be like this as depending on what we (humans) are doing we often do/don’t want the time element of a date, or only want a ‘day’ to mean a workday, etc.

This article and this article might help explain the status quo.

I’ve not tested, but interval measures, might help. Some along the lines of (N.B. untested):

interval(datetime1,datetime2)< "3 days";

The Interval data type is intended really for (few) day scope or smaller—they handle day/hour/minute scope. (Sorry, deep in a big thing or I’d run a trst)

Idea: Might it be a good idea to set up a small Tinderbox task force that could share this Tinderbox and refine it? It’s not highly sensitive information, and it’s an emergency.

I suggest this because (

  1. we might get a better solution,
  2. other people might actually need the solution, and
  3. when this is sorted, the team can take on the next problem.
3 Likes

Very happy to help. I suspect we can probably pull a model out of it too, though it helps to start with real data.

Note any real/personal data can always be removed or substituted with made up specimen data. But making up good test data is hard unless you know the problem areas edge cases at outset (which is rarely so).

1 Like

I can supply my TBX file. Just need to clean it up a little. As my original data includes superfluous user attributes, is there a way to delete them on mass?

Not unless doing so in the XML. Offline for few hours now, by all send me a copy of the TBX via a forum PM (or email).

if(!$NeedToCall){$Badge=“no”;$NameStrike=true;}else{$Badge=“yes”;$NameStrike=;};

Might be useful to toggle a badge for those needing a call (your boolean ) with the others in strikeout text - especially in column views in outline

This is working really well at the moment. I may be running too many agents, but it’s really helping manage our COVID-19 response for our people at church.

Using TBX we are able to keep our list of people up-to-date. Add new one’s on the fly. Immediately see who is high risk/has known health issues/is isolated. We can see who has volunteered and who the volunteer is responsible for. We can also see who has not been contacted in the last 3 days. We’ve also added the ability to check who wants to be part of a Whatsapp group and assign them to a group.

This will continue to morph as new needs are made known, but TBX has been sterling in handling this. Thank you!

3 Likes

Don’t forget that if you have too many agents and they are degrading the performance of the tinderbox file you can adjust it’s priority (key attribute $AgentPriority): AgentPriority.

One thing I sometimes do is to have two stamps: one with code to disable an agent, other with code to enable an agent - because I don’t need all agents running all the time. Another thing I do is to highlight disabled agents in some way (with color, outline color, stamp, strikethrough over the agent’s name…) for me to know that the agent is disabled.

In modern Tinderbox on modern machines, you’re not likely* to need to worry very much about agents degrading performance.

  • Exception 1: if you use Tinderbox on batteries a lot and are far from power outlets, switching to manual agent updates helps preserve battery power. This chiefly matters for transoceanic flights, which no one is doing right now, but also for work in the field.

  • Exception 2: Agent queries with very complex regular expressions, or queries that require Tinderbox to compare each note with every other notes — chiefly find() clauses — can be a burden if you have thousands of notes. (Comparing every note to every other note means 10,000 comparisons with a hundred notes, but ten million comparisons with three thousand notes.

  • Exception 3: If the agent forces a screen update, that can be slow. For example, try to avoid Pushmepullyou situations where Agent 1 sets a note’s color to red, and then Agent 2 sets the same note’s color to green on every agent update.

1 Like