Presentation

[Audio] Welcome to this sales training on the external connections of the NightWatch+. In this training we look at the external connection options for the NightWatch+, and in particular at the three extended DIS settings that have recently been added. We build it up in three steps. First, a refresh on the difference between a DAS and a DIS. Then one overview of all connection options, and what each of them means for assurance. Then the three extended DIS settings, one by one, and what happens when they are combined. We close with the questions you can use in a customer conversation, the order in which you present the options, the handout, and a few practice scenarios. The key message is this. These new settings are not simply convenience options for the care homes. Each extended DIS setting removes a hardware-level safeguard, and that changes what the care organization has to control through procedures, infrastructure and training to keep their patients safe. Your role in sales is to explain that clearly. We do not assess or approve the customer's procedures, and we do not prescribe how the customer must organize its care processes. We make sure the customer understands the technical difference, the risk created by the requested configuration, and the types of measures that can help create a safer situation. The customer then decides what it will implement and remains responsible for that implementation..

[Audio] Let's start with a refresh. What is a Distributed Alarm System, in short a DAS. And what is a Distributed Information System, in short a DIS. With a DAS connection, every API message sent out by the NightWatch+ is acknowledged by the receiving system. If the NightWatch+ cannot deliver a message, the alarm station detects that failure and alarms locally. The DAS and the NightWatch+ continuously talk to each other, back and forth, to confirm that the connection is working. Did you receive my message? Yes, I received your message. Did you receive my message? Yes, I received your message. And so on. Because of that, a qualifying certified DAS can take over the alarming function of the NightWatch+. A DIS is different. It receives information, but it does not confirm to the NightWatch+ that the alarm has reached the end user. The NightWatch+ therefore does not know whether an alarm has been received by the connected system. That is why the local fallback stays in place. The alarm station keeps sounding, and the alarm keeps going until a caregiver presses the button on the alarm station. So a DIS must never be described as equivalent to a DAS, or as a complete replacement for the alarm station. Make that distinction explicit, so the customer understands where delivery assurance exists, and where it does not. Hold on to that difference, because next we put both of them, and everything that can be built on top of them, side by side in one overview..

[Audio] This is the overview. It shows the connection paths ordered by technical assurance, from the highest at the top to the lowest at the bottom. At the top, a certified DAS via the API. Delivery is confirmed, and the connection uses a so-called heartbeat, where the two systems talk back and forth to make sure the connection is intact. Because delivery is confirmed, the local fallback may be transferred to the DAS. The sound on the alarm station can be turned off, and the button on the alarm station does not have to be pressed to acknowledge the alarm. Through the API, the DAS also receives what kind of alarm it is, technical or epilepsy, and which device it came from. The customer responsibility here is low. Second, a DIS via the API. It receives the same detailed messages, and the heartbeat can be monitored. But the delivery of a message sent by the NightWatch+ to the DIS stays unconfirmed. So the local fallback stays in place. The sound on the alarm station cannot be turned off, and the button still has to be pressed to acknowledge the alarm. Responsibility is moderate. Third, a DIS via the relay connection, in normally-closed. This path is simpler, and it cannot distinguish between alarm types. This means the caregiver does not know whether they receive an epilepsy alarm or a technical alarm.. A broken cable or a loss of power becomes visible as an open circuit, so the DIS will raise an alarm so that the user knows there is something wrong. The local fallback stays in place here as well as the NightWatch cannot confirm if a message is received by the DIS. Responsibility is high..

[Audio] The three red rows are not another kind of connection. They are the three extended DIS settings which have been added: Audio-Off, Managed Acknowledge, and the relay in normally-open. They can be requested on top of a DIS connection. Each of them takes away one of the safeguards that is still present in the rows above. That is why line supervision now reads in these rows: cable break silent. And why customer responsibility reads: highest. The asterisk under the table makes the same point from the other side. The local fallback in the DIS rows only holds as long as Audio-Off and Managed Acknowledge are not enabled. We will look at each of the three settings in detail in the following slides. This gives us the sales principle. Explain the options from the highest assurance to the lowest, and make the trade-off visible. We do not decide which organizational measures are sufficient. The customer chooses the configuration and determines how it manages the associated risks. Suggestions are provided in the user manual..

[Audio] Now we zoom in on those red rows: the three extended settings themselves. On the left is the default DIS behaviour. This is the baseline you compare every request against. First, the local acoustic alarm stays active, at the minimum permitted volume. Second, a seizure alarm stays active until a member of staff presses the button on the alarm station. Third, the relay is normally closed. The circuit is closed in standby, a seizure or technical alarm opens the contact for two seconds, and a cut cable or a loss of power also creates an open circuit, so the fault becomes visible to the connected DIS. These three safeguards matter, because they give local, hardware-level protection exactly at the moment the external information path fails..

[Audio] On the right are the three settings that can now be enabled on request. Local Audio-Off allows the sound to be reduced to zero decibels. It relaxes the minimum sound limit. DIS Managed Acknowledge lets the local alarm reset automatically after three minutes, without a button press on the alarm station. It relaxes the persistent local alarm. DIS Normally-Open changes the relay, so that a broken cable, or a cable that is suddenly removed, is no longer automatically detected. It relaxes the continuous line supervision. These settings are not upgrades. They are exceptions, for situations where the default configuration on the left cannot be used. Each one removes or relaxes one of the safeguards on the left. LivAssured only enables them once the request and the responsibilities are understood, so the conversation you have with the customer is part of that process. In that conversation, your task is to explain what changes, to describe the resulting failure scenario in plain language, and to discuss examples of measures the customer could take. Those examples are described in the manual and in the handout, so you do not have to design or approve the customer's process. The customer decides how to manage the additional risk, and stays responsible for selecting, implementing and maintaining the measures that fit its organization. Let's take the three settings one by one, in the order on the right..

[Audio] The first of the three. Local Audio-Off allows the sound of the alarm station to be reduced to zero decibels. This can be relevant for residents with reflex or startle epilepsy, where sound itself triggers an epileptic seizure. For residents who experience severe distress from a loud alarm. Or where the alarm sound triggers destructive behaviour. The trade-off is that the bedside acoustic safety net disappears. If the connection to the DIS fails, there is no local sound to alert staff in or near the room. The manual describes ways in which the customer can create a safer situation. Continuously displaying and tracking the incoming alarms in the DIS. Routinely checking the status LEDs, physically or by video. And letting the DIS escalate an alarm automatically when the first caregiver does not accept it in time. Explain these possibilities, and explain the risk that remains. The customer decides how these measures are implemented, and is responsible for their operation..

[Audio] The second of the three. With DIS Managed Acknowledge, the alarm is still sent to the DIS, and the local light and sound still start. This option is implemented for customers where it is not possible to place the alarm station within reach of the caregivers to press the button. The important change happens after three minutes. The local visual and acoustic alarm reset automatically, and seizure detection resumes. Whether or not a caregiver has arrived. So this is not a confirmation that care has been given. It is only an automatic reset of the alarm station. That is why the manual describes measures such as time-bound, multi-tier escalation by the DIS, timestamped logging of the alarm lifecycle, and physical protection of the cable where tampering is foreseeable. Explain to the customer why those measures are relevant. Once the persistent local alarm is removed, the DIS has to carry much more of the alarm lifecycle..

[Audio] The third of the three. Normally-closed is the standard relay configuration. In standby, the circuit is closed. If the cable breaks, or is unplugged, the circuit opens, and the DIS can show a continuing alarm. In normally-open mode, the circuit is already open during standby. A broken or unplugged cable can then look exactly like a quiet night. No alarm signal, and no indication that the line is no longer working. And a loss of power produces only a single relay event, not continuous line supervision. For that reason, normally-open should only be discussed when the customer's own system cannot accept a normally-closed input. The manual asks for a test of the complete DIS connection before every use, and again after maintenance, and for that test to be documented in the care protocol. Explain the silent-failure risk, and explain these measures. The customer chooses how to organize and document the process..

[Audio] We have now seen the three settings separately. They also have to be explained as a complete configuration, because the risks combine. Audio-Off together with normally-open can turn a broken cable into a completely silent failure. No central signal, and no local sound. Managed Acknowledge together with normally-open can mean that a missed DIS message is followed by the local alarm clearing itself after three minutes. And Audio-Off together with Managed Acknowledge leaves the status LED as the only local indication. And that indication resets as well. So whenever more than one setting is requested, describe the combined failure scenario. We do not determine the customer's final control design. We help the customer understand that combining settings removes several independent safeguards at the same time, we discuss the kinds of measures described in the documentation, and we record the configuration the customer chooses..

[Audio] That completes the technical part. The rest of this training is about how you bring this into a customer conversation. These six questions help you explain the relevant risks. They are not an audit of the customer. One. Which interface is available? The RJ45 API, or the RJ11 relay. Two. Is the receiving system a certified DAS? If it is not, treat it as a DIS. Three. Can the system detect a lost connection? Through an acknowledged heartbeat, through a heartbeat the DIS monitors itself, through a normally-closed line, or not at all. Four. Why can the standard setup not be used? That reason is resident-specific or infrastructure-specific, and it determines which extended setting is on the table. Five. Which risk does the requested setting create? Make the failure scenario concrete. Six. Which measures can the customer consider? Use the manual and the handout to explain them. The customer then decides what it will implement. And you record the requested configuration in Salesforce..

[Audio] This is the overview from the beginning of the training again, now as the order in which you structure the discussion. Start with a certified DAS via the API, when the receiving system meets the DAS conditions. If it is not a DAS, explain the DIS via the API. That keeps the detailed messages and the heartbeat, while the local fallback stays in place. If an API connection is not available, explain the default relay in normally-closed. Normally-open is the last option, and it is meant for systems that cannot accept a normally-closed input. It appears in this list as a connection option, because it is a different wiring of the relay line. Audio-Off and Managed Acknowledge are not in this list. They are additional settings within a DIS pathway, and they do not create a new type of connection. This sequence helps the customer see the difference in technical assurance. It is not a decision tree that lets you approve the customer's safety arrangements. The customer chooses the configuration, and decides which organizational and technical measures it will use..

[Audio] TD-NWP-578 is the customer-facing handout for this conversation. There are four steps. Explain. Use the handout to show the connection options, where assurance is provided by the NightWatch+, and where responsibility shifts to the care organization. Discuss. Clarify which setting is being requested, and why the standard configuration does not suit the customer's situation. Then use the extended-configuration section to explain the removed safeguard, the resulting risk, and examples of measures the customer can consider. Provide. Give the handout to the customer, so the information is available during their own decision-making. Record. Capture the configuration the customer requests, and forward that request through the normal LivAssured process. The handout supports the discussion, but the external connections manual and the customer's own site protocol remain authoritative for technical requirements and testing instructions. Sales does not approve the customer's implementation..

[Audio] Let's apply this to four short examples. The first. We want no sound, but our nurse-call system has no escalation. Do not judge whether the nurse-call system is acceptable. Explain that Audio-Off removes the local acoustic fallback, and discuss escalation as one possible way to reduce the risk. The second. Our wall socket only accepts normally-open. Explain that normally-open can be supplied on request, but that a broken cable may stay silent, and that the manual asks for a test before every use and after maintenance. The third. The alarm station is locked away, so staff cannot press its button. Explain that Managed Acknowledge resets the local alarm after three minutes, and discuss escalation, logging and cable protection as possible measures. The fourth. Our DIS should completely replace the alarm station. Here you correct the underlying assumption. A DIS cannot completely replace the alarm station. Only a qualifying certified DAS can take over the alarming function. In every one of these, explain first. Discuss the reason, not just the name of the setting. The customer decides, and the customer implements..

[Audio] One sentence to remember. Default first. Exceptions with informed choice. So, before an extended DIS configuration is requested. Explain the standard pathway and the safeguards it provides. If the customer asks for an extended setting, explain which safeguard is removed, and what risk that creates. Discuss the ways in which the customer can create a safer situation, as described in TD-NWP-52 and TD-NWP-578. And provide the handout and record the choice the customer makes. Do not present those measures as a sales approval checklist, and do not tell the customer how its organisation must be designed. The customer chooses what it implements, and stays responsible for implementation, training, testing and maintenance. Every removed safeguard creates a risk the customer must understand and manage. Our responsibility is to communicate that risk accurately, answer questions, provide the handout, and record the configuration the customer requests..