A patient in Lakewood is sent home with a monitoring device that beeps for attention and needs a button press twice a day. A hospital in Brooklyn admits an observant patient whose care plan involves a device with a capacitive touchscreen. Neither situation is unusual, and in both the same question reaches the manufacturer: can this be used on Shabbat, and if not, can it be built so that it can?
This article is written from the engineering side. Whether a specific action is permitted is a halachic question belonging to a qualified posek, not to a product team. The engineering job is narrower: build a mechanism whose behavior a posek can evaluate, and document it clearly enough that the evaluation is possible.
Pikuach nefesh comes first — and it changes what you are solving
The starting point every rabbinic authority states plainly is that saving a life overrides Shabbat prohibitions. A device treating a genuinely life-threatening condition is used on Shabbat the way it is used any other day, without modification and without hesitation.
That means the interesting engineering space is everything else — the large middle ground of devices for chronic conditions, comfort, mobility, monitoring, rehabilitation, and quality of life, where a patient would prefer not to perform an ordinary weekday action if the device can be designed to avoid requiring one. That is where a manufacturer can add real value.
The engineering toolkit
A handful of design patterns recur across every Shabbat-compatible product category.
Pre-set and continuous operation
The simplest compliant mode is one where the device is configured before Shabbat begins and then runs on its own for 25 hours or more. Compression therapy pumps, air mattresses, nebulizer schedules, feeding pumps, and lighting on treatment equipment can all be built around a scheduled program set in advance. Two engineering requirements follow: the schedule must be long enough to cover Shabbat plus a Yom Tov day adjacent to it (plan for a 73-hour window), and the device must recover from a power blip without needing a human to press anything — a real-time clock with battery backup and automatic resumption of the stored program, not a boot into a setup screen.
Grama — indirect action
Where a patient may need to influence the device during Shabbat, the standard engineering answer is an indirect mechanism: the user's action does not itself complete a circuit, but instead removes an obstacle or alters a condition that a continuously running process will later act upon. A typical implementation has the controller polling a state on a fixed cycle and acting on what it finds, so the human input and the electrical result are separated in both time and causation. The design details matter enormously to the ruling, which is why this deserves its own treatment — see grama mechanisms and indirect-action engineering.
Uncoupling the interface from the state
Modern medical electronics fail this test constantly. Capacitive touch panels, backlit LCDs that wake on approach, LED bar graphs that track a sensor in real time, and screens that redraw on every user action all create a direct and immediate electrical consequence from a human act. Compliant designs tend to include a mode where the display is either continuously on and static, or continuously cycling on its own timer regardless of what the user does, so nothing the patient does changes what the screen shows. Mechanical controls with detents, pre-existing motion, and physical position indicators are far easier to certify than a touchscreen. This is the same reasoning behind the display behavior in Sabbath mode on appliances.
Alarms
Alarm design is the hardest part of the problem, because alarms are safety functions governed by IEC 60601-1-8 and cannot simply be muted for a day. The workable approach is usually to separate alarm tiers: a technical or informational alert can be suppressed or deferred by a pre-set schedule, while a clinical alarm indicating patient risk stays fully active because that situation falls under pikuach nefesh anyway. Build the tiers as separate logical channels, document them, and never let silencing a nuisance alert also acknowledge a clinical alarm.
The home-use case and the institutional case
Most of this work lands on devices used at home by a patient or a family member, which brings its own regulatory weight — a non-clinical user, an unpredictable environment, and labeling that has to be understood without training. Everything in designing home-use medical devices for a non-clinical user applies on top of the halachic requirements, and the two sets of constraints occasionally conflict, so the two modes must be designed together rather than layered.
The institutional market is larger and less visible. US hospitals with significant observant patient populations already run Shabbat accommodations: elevators on automatic cycles, doors held open on continuously running sensors, unit lighting on timers, and pre-programmed meal service. Vendors selling monitoring, call-button, and bed-control systems into these hospitals, nursing homes, and senior facilities are routinely asked whether a Shabbat configuration exists. Very few have one. The equivalent thinking in hospitality is covered in Shabbat technology for hotels and institutions.
Getting it into the spec and getting it approved
The single most common failure is treating this as a feature request late in development. It is a requirement, and it belongs in the product requirements document alongside every other one, phrased in engineering terms — "no user input shall directly change the state of any output" rather than "make it kosher for Shabbat." Our guide to writing halachic requirements into a product spec covers how to phrase them so both the engineering team and the reviewing rabbi can act on them.
Approval follows a documented review. A certifying body such as Star-K, or a posek engaged directly by the manufacturer or by the institution buying the device, examines the actual mechanism: schematics, firmware state diagrams, timing, and failure modes. Expect detailed questions about edge cases: power loss, sensor failure, a double button press. Our overview of halachic certification for products describes how that process runs and what documentation it needs.
One practical note: a mode patients cannot find has no value. Human factors work under IEC 62366, described in usability engineering for medical devices, should cover the pre-Shabbat setup path with real users from the community.
Projects House develops medical and monitoring devices for the US market and builds halachic operating modes in as engineering requirements — specified early, documented properly, and presented to the posek or certifying agency in a form they can review. If you are developing a device for this market, describe it through our contact form.