Active vs. Passive Support

Introduction

Recently, there’s been a lot of conversation about what exactly “Active“ and “Passive“ mean in the context of Remote Supports. Here, we’ll outline the issues with current conceptions of “Active“ vs “Passive“ discussions, pull apart the two terms, establish their respective definitions, and recontextualize the conversation.

Background

Originally, terms like “Active“ and “Passive“ Remote Supports were marketing terms designed to help explain certain aspects of the service. Because the service was new at the time, Remote Support providers had to come up with plain language that communicated the different service capacities of Remote Supports.

For example, an RS provider might refer to a check-in as an “active“ component of their support because it is initiated by the RSP and involves direct, two-way communication between the Remote Support Professional (RSP) and the individual. Conversely, they might describe the way that RSPs survey sensor data in real time as “passive“, because it doesn’t involve direct, two-way communication and happens “behind the scenes.“

Additionally, RS providers used these terms to differentiate their specific brand of services from other RS providers. For example, a provider that uses cameras as a common part of their services might say their specific brand of Remote Supports is, generally speaking, more “active“ than ones that don’t use cameras.

Problems with “Active“ vs “Passive“

Problems with the terms “active“ and “passive“ arise when they are taken out of the context of general education and marketing and are instead used as regulatory terms. Because “active” and “passive“ have different meanings even among different RS providers, establishing regulatory requirements based on these terms causes confusion and compliance headaches.

Defining “Active” and “Passive“ Remote Supports

When attempting to lay out a concrete definition for these two terms, it’s important to understand that there are not two separate and distinct services, “Active” and “Passive“ Remote Supports. Rather, all Remote Supports have active and passive elements within them, depending on the individual’s specific needs and Remote Supports Plan.

Active Supports

Active elements can be thought of as intervals of direct communication with the individual. This could be a two-way audio or video call. The cause for these short stretches of direct communication, or “active support“, could be something like the activation of a sensor (e.g. John presses his pendant to get in touch with an RSP), a scheduled intervention (e.g. Jane gets a call every day at 6a to remind her to pack her lunch for work), or a combination of the two (e.g. Billy gets a call in the afternoons to check on how he’s doing whenever his Front Door sensor indicates he’s arrived back from Day Program).

Regardless of the cause, these stretches of direct communication have specific characteristics: First, they’re brief. When compared to consecutive hours of in-person staff presence during a residential habilitative service, these periods of direct communication during Remote Supports are short. Some can be as quick as a minute, some can last as long as fifteen minutes, but overall they are relatively short.

Second, they address a specific need/goal/intended outcome. Check-ins are performed to see if the individual is present, safe, and happy. Reminders are intended to help individuals remember certain things needed to live independently. Responses, such as John’s example above, are often just to reassure the individual that someone is supporting them and answer questions that they may have in the moment.

Passive Supports

Passive elements of Remote Supports comprise all the times that these intervals of direct communication are not occurring during the scheduled Remote Supports period. For example, if an individual has overnight Remote Supports from 10p to 6a and has a reminder at 5:30a, then the periods from 10p-5:30a and 5:35a-6a are all considered passive.

This may seem like a lot of passive time, but let’s remember why Remote Supports are implemented in the first place. The goal of Remote Supports is to provide a safe environment where individuals can exercise and develop skills related to independent living. The purpose is to create an environment where they can reach out to someone immediately if they have a problem, question, or concern, but also where certain elements of behavior that may complicate independent living (e.g. a tendency to let strangers in the home) can be mitigated.

During times of passive support, RSPs are still actively engaged with the individual’s Remote Supports system, they just aren’t in direct communication with the individuals themselves. If we take the example above of an individual who struggles with visitor safety, we can imagine a DSP who works in the home to help with that specific concern. During an overnight period of support, the DSP may not be engaged in direct communication with the individual, they’re just keeping an eye and ear out for the doorbell or people entering the home. We can imagine the exact same absence of direct communication in that period with an RSP. Except instead of using their eyes and ears to listen to the door that’s right next to them, they’re using the information from door sensors to monitor whether it opens during the night. Both examples are instances of “passive“ support. They are awaiting a set of circumstances that would require them to intervene.

Conclusion

It may seem that more “Active“ support would be preferable for most folks. More direct communication = more support = a better outcome for the person served, the thinking goes. This isn’t the case. Like most in-person residential services, Remote Supports are intended to be habilitative. Though the method of habilitation differs from services with in-person DSPs, the intended outcome is the same: to help bring individuals to a place where they can live with fewer and fewer supports while remaining safe and successful. For individuals using Remote Supports, this means that the goal is to end up with supports that are as passive as possible.

Next
Next

CAIRSS Remote Supports Integration White Paper