Keeping Patients Safe With a Sliding Window Algorithm

ERI Group, formerly Evergreen Research, designs, develops and manufactures medical devices. This past year, they began work on a mechanical system that helps individuals who are fighting cancer.

While the core functionality of this machine is potentially life-saving, it also needs to be FDA-approved. Therefore, many safeguards need to be in place to maintain safety for the patient. Devetry (part of DEPT®) worked alongside the ERI team to support their embedded development efforts.

When blood leaves your body, you have about four minutes until it starts to coagulate.

If an anticoagulant is not added before that point, the blood begins to clot and is no longer safe to return to your body.

Therefore, the machine needs to have the ability to sound an alarm if the blood has been sitting in the line for four minutes or more. If they try to start pumping again, they're going to risk returning blood clots to the patient.

However, the real challenge is knowing exactly when the blood has completely exited the line. In a clinical setting, the machine might start, then stop, then start again. The same line of blood could have different times out of the body, and we need to account for that.

How can we solve this problem of time tracking in such a complex environment?

To solve this problem, we had to create a sliding window algorithm.

A sliding window algorithm (more of a technique than an algorithm) is a problem-solving approach that attempts to detect a specific condition within a list.

Algorithm

Once per second, the system checks whether the pump is paused. If the pump is stopped, increment the “idle” time of all blood segments in the queue. If the pump is currently running, increment the “active time” of all blood segments in the queue and remove all blood segments from the queue whose “active time” is greater than T, where T is the amount of time it takes for blood to travel from the patient to the device. If the pump was running during the last check but is now stopped, push a new “blood segment” data structure into the queue.

If the oldest blood segment is older than two minutes and the pump is stopped, trigger a warning alarm. If during any check the oldest blood segment has been in the queue for four minutes or more, trigger the idle blood alarm and prevent the operator from resuming the pump.

This was a critical piece to getting this into a clinical trial because an alarm is absolutely necessary to get FDA-approved. On top of that, the algorithm needs to be testable.

Being able to test this alarm not only proves reliability. It also makes it easier for software engineers in the future, because the code is modular and testable.

Thoughts from Lead Engineer, Andrew R

“This was a particularly fun and rewarding problem to solve. Most of my career has been spent working on mission-critical systems, so I understand how important reliability and testability are to the software development process. We had to gather a lot of data on how quickly blood moves through the line, how long it takes for a single blood cell to reach the machine after leaving the patient’s body, etc.

Designing an algorithm for a resource-constrained system like a microcontroller where everything shares the same processor requires you to think carefully about your solution to make sure you’re not tying up precious resources (specifically, time and memory) that other parts of the system are relying on.”

Learn more about the life-saving work of ERI Group.