Google Pixel Watch Adds Automated EMS Calls for Severely Low Oxygen

Pixel Watch’s New Breathing Emergency Feature, Explained — Made by Google Podcast

Made by Google Podcast

Consumer smartwatches can prevent fatal unwitnessed respiratory crises by combining optical and motion sensors to autonomously summon emergency responders when wearers become incapacitated.

AI-assisted summary of Pixel Watch’s New Breathing Emergency Feature, Explained — original source. Check the original for full context.

Source published:

Key ideas

  • Google introduced Breathing Emergency Detection for the Pixel Watch 4 and 5 in select European countries, using on-device optical and motion sensors to automatically alert emergency services when oxygen saturation drops dangerously low. (1:45)
  • The detection system pairs machine learning models with a staged escalation protocol—progressing from subtle haptic checks to loud alarms—before autonomously placing an emergency dispatch call with location data, text transcription, and an open audio channel. (10:00)
  • To prevent false alarms from overwhelming EMS infrastructure, algorithms were calibrated to distinguish catastrophic, sustained hypoxia from transient, self-resolving events common in conditions like obstructive sleep apnea. (15:00)
  • Google aims to shift the consumer wearable paradigm from passive fitness tracking into active health guardianship, openly encouraging industry competitors to adopt similar life-saving emergency protocols. (25:52)

Detailed notes

## Background Published by the Made by Google Podcast on September 21, 2026, across RSS and web platforms, this episode features host Rachid Finge speaking with Google Health research scientist Jake Sunshine and product manager Pramod Rudrapatna. According to the show description, the conversation explores the creation of the Pixel Watch's Breathing Emergency Detection feature, charting its progression from initial concept and clinical testing to user-centered design aimed at turning smartwatches into life-saving health guardians.

## TL;DR In this episode, Jake Sunshine and Pramod Rudrapatna explain the clinical motivation and engineering architecture behind the Pixel Watch's Breathing Emergency Detection feature, which identifies severe blood oxygen desaturation during isolated emergencies like overdoses, pneumonia, or choking. The system pairs optical biosensors with motion tracking and machine learning models to detect acute state changes, deploying a staged escalation of haptics and audible alarms before autonomously dialing emergency medical services with location and contextual data. The guests detail the extensive clinical hypoxia testing conducted to distinguish fatal events from self-resolving conditions like sleep apnea, alongside outreach initiatives designed to prepare 911 dispatch networks for automated wearable calls. Ultimately, they describe Google's broader 'health guardian' vision, which aims to shift the Overton window across consumer wearables from passive fitness tracking toward active clinical safety intervention.

## Atmosphere & style The conversation carries an earnest, intellectually rigorous, and grounded tone, balancing technical discussions of sensor fusion with the solemn realities of acute respiratory arrest and public health emergencies. Rachid Finge maintains an engaging, inquisitive rapport with the guests, while Sunshine’s clinical background and Rudrapatna’s systems perspective lend authority and transparency to the development process. The narrative builds to a poignant, reflective emotional peak when discussing direct correspondence from families affected by unwitnessed fatal overdoses, instilling a palpable sense of purpose, empathy, and technological optimism.

## Bulletin - `01:45` Google introduced Breathing Emergency Detection for the Pixel Watch 4 and 5 in select European countries, using on-device optical and motion sensors to automatically alert emergency services when oxygen saturation drops dangerously low. - `10:00` The detection system pairs machine learning models with a staged escalation protocol—progressing from subtle haptic checks to loud alarms—before autonomously placing an emergency dispatch call with location data, text transcription, and an open audio channel. - `15:00` To prevent false alarms from overwhelming EMS infrastructure, algorithms were calibrated to distinguish catastrophic, sustained hypoxia from transient, self-resolving events common in conditions like obstructive sleep apnea. - `25:52` Google aims to shift the consumer wearable paradigm from passive fitness tracking into active health guardianship, openly encouraging industry competitors to adopt similar life-saving emergency protocols.

## Key takeaways - `01:45` Breathing Emergency Detection targets unobserved, life-threatening drops in blood oxygen saturation resulting from acute events like accidental overdoses, severe pneumonia, or choking. - `01:45` The primary clinical objective of the feature is converting unwitnessed medical emergencies into witnessed events by summoning emergency medical services on behalf of incapacitated individuals. - `03:45` Google transitioned its wearable product strategy from routine fitness logging toward addressing major unmet public health needs where continuous wrist monitoring can actively protect users. - `05:40` Modern consumer smartwatches possess greater computational processing power than traditional, bulky hospital monitoring equipment, enabling sophisticated clinical sensing outside institutional walls. - `07:44` The detection algorithm combines optical pulse oximetry data with accelerometer motion tracking to identify when a user transitions from a healthy baseline to critical hypoxia and immobility. - `10:00` A multi-stage escalation protocol initiates with silent haptic vibrations and progresses to loud audible alarms to allow conscious users to cancel false alarms and attract nearby bystanders. - `10:00` Autonomous emergency calls provide dispatchers with precise location coordinates, context regarding impaired oxygenation, an automated transcription, and an open voice line to evaluate the scene. - `12:35` Unlike loss of pulse events where unconsciousness is immediate, breathing emergencies exist on an evolving conscious continuum that requires dynamic user-facing interfaces and fail-safe escalations. - `15:00` Clinical hypoxia trials with safe, medically supervised desaturation provided ground truth data to confirm the algorithm's sensitivity to true hypoxemic signatures. - `15:00` Algorithmic alert thresholds were specifically engineered to avoid false positives caused by undiagnosed obstructive sleep apnea, where oxygen saturation naturally rebounds after brief desaturations. - `17:41` End-to-end software and hardware validation was performed across internal employee cohorts to verify that daily wear does not trigger false alarms before deploying into formal regulatory design controls. - `20:00` Google conducted proactive outreach to emergency dispatch networks through webinars and documentation to prepare 911 centers for automated, wearable-initiated distress calls. - `21:44` Controlled hypoxia laboratory testing served as the breakthrough validation milestone, confirming high true-positive sensitivity while keeping false-positive rates comparable to standard fitness sensors. - `23:31` Feedback from clinicians and affected families underscored the severe public health impact of unobserved respiratory failure and validated Google's multi-year development effort. - `25:52` Google envisions smartwatches shifting the broader Overton window from basic athletic accessories to active safety layers that intervene during acute morbidity and mortality crises. - `25:52` Google's 'health guardian' roadmap combines daily wellness tracking, early chronic disease detection, and automated emergency interventions, welcoming industry-wide adoption to maximize public health benefits.

## Detailed walkthrough ### `00:00` Introduction and Guest Backgrounds

Host Rachid Finge introduces a breakthrough feature coming to the Google Pixel Watch: Breathing Emergency Detection. Joining the podcast to discuss this life-saving capability are Google Health research scientist Jake Sunshine and product manager Pramod Rudrapatna. Both guests operate at the convergence of consumer electronics, artificial intelligence, and healthcare sensing.

Jake Sunshine brings a clinical and academic perspective to Google. As a physician by training and a faculty member at the University of Washington, he has dedicated his career to examining how everyday consumer devices—such as smartphones, smart speakers, and wearables—can be repurposed for advanced health sensing. His academic research and work with collaborators at the University of Washington led to a spin-out company that Google acquired in 2022 to continue pushing the frontiers of consumer health technology.

Pramod Rudrapatna works as a product manager within the Google Health organization, focusing on advancing device sensing capabilities. He arrived at Google around five years earlier via the Fitbit acquisition. While his background was rooted in hardware, software, and AI, transitioning to digital health resonated deeply with his career aspirations. As Pramod Rudrapatna explains: “I started working on health about five years back, as I truly believe that this is an area where we can truly make an impact.”

`01:45` Defining Breathing Emergency Detection

When asked to summarize the new feature in a single sentence, Pramod explains that Breathing Emergency Detection can automatically place a call to emergency medical services if a user's blood oxygen saturation persistently falls to dangerously low levels. The critical value of this technology lies in addressing scenarios where a medical crisis happens in total isolation. Critical drops in oxygen can stem from severe medical emergencies, such as accidental drug overdoses, severe pneumonia, or acute choking.

In many such cases, the victim is incapacitated and completely alone. Even though proven, life-saving clinical interventions exist, they cannot be deployed if nobody is present to dial emergency services. As Pramod Rudrapatna emphasizes: “I think Breathing Emergency Detection transforms that from converting these emergencies from unwitnessed to witnessed and prompting a call to emergency medical services so that people can get the potentially life-saving intervention from these public assets which are already put in place.”

- **Availability:** Breathing Emergency Detection is rolled out as an opt-in feature on Pixel Watch 4 and Pixel Watch 5 in select European countries. - **Target Medical Causes:** Persistently low oxygen events precipitated by accidental drug overdoses, severe pneumonia, choking, and related respiratory compromise.

`03:45` Moving Beyond Step Counting to True Health Guardianship

Rachid notes that smartwatches originally entered consumer awareness as simple activity trackers for logging daily steps or monitoring basic sleep stages. Advanced capabilities like Loss of Pulse Detection (discussed in the prior year) and Breathing Emergency Detection signify a dramatic shift in scope. Pramod explains that although fitness trackers have been on the market for more than a decade, the potential of wrist-worn hardware extends far past routine activity logging.

The product and research teams at Google began by examining major unmet public health needs where smart wearables could make a genuine impact. Their focus shifted toward conditions that are often invisible because they do not present obvious everyday symptoms—meaning users remain unaware of them until an annual physical—or severe acute crises where the victim is physically incapacitated. Wearables are uniquely positioned to intervene because users already wear them continuously throughout the day and night.

As Pramod Rudrapatna frames the overarching philosophy: “How about we detect something where the user is not in the position to get help themselves, right? So these are like truly moments where these wearables can offer peace of mind and truly act as a health guardian.” Loss of pulse, whether triggered by cardiac arrest or sudden respiratory collapse, is an enormous public health challenge where the vast majority of events occur unwitnessed. Equipping consumer devices with the ability to bridge that gap and dial emergency services on behalf of an unresponsive user represents an evolutionary leap in wearable capabilities.

```mermaid flowchart TD accTitle: Evolution of Wearable Health Capabilities accDescr: A progression showing how wearable devices evolved from fitness tracking to active emergency health guardianship.

subgraph Legacy["Traditional Wearable Capabilities"] A["Step Tracking & Distance"] B["Sleep Stage Analysis"] C["Routine Workout Heart Rate"] end

subgraph Evolution["Paradigm Shift to Public Health"] D["Identify Unmet Health Needs"] E["Continuous Day & Night Wrist Contact"] end

subgraph Guardian["Active Health Guardian Features"] F["Loss of Pulse Detection"] G["Breathing Emergency Detection"] H["Automatic EMS & Emergency Contact Dispatch"] end

Legacy --> Evolution Evolution --> Guardian ```

`05:40` Clinical Inspiration and Computational Power

Addressing how the concept originated, Jake reflects on his extensive clinical background in hospital settings, including intensive care units, operating rooms, and general hospital wards. In those environments, specialized medical monitors run continuously to keep patients safe. However, looking at traditional hospital equipment alongside consumer electronics reveals a startling technological disparity.

Jake observed that consumer smartphones, smartwatches, and smart speakers actually possess significantly higher computational processing capabilities than the rigid, bulky monitoring equipment traditionally found inside clinical facilities. Recognizing this computational gap shifts how one evaluates potential emergency applications: medical crises that were previously viewed as manageable only inside a hospital could now be identified outside hospital walls using mass-market devices.

According to Jake Sunshine: “The real challenge was making people aware that someone was experiencing an emergency in the first place.” Interventions exist to reverse acute respiratory depression and cardiac events, but they are useless if no one knows help is needed. To bridge that gap safely, the Google Health team conducted incremental, rigorous research to de-risk the sensing technology, gather extensive clinical validation data, and prove that consumer smartwatches can reliably pinpoint unwitnessed emergencies without triggering hazardous false alarms.

`07:44` The Underlying Sensing Mechanism and AI Models

Rachid observes that while listeners can intuitively grasp how Loss of Pulse Detection works—the watch senses the heart beating, and sounds an alarm when the pulse vanishes—detecting a breathing emergency sounds far more nuanced. Jake explains that the Pixel Watch houses optical sensors comparable to those found in hospital-grade pulse oximeters and monitors, which have historically been applied in consumer tech simply to record heart rate during athletic exercise.

During an acute breathing emergency, blood oxygen levels do not merely dip slightly; they drop precipitously into dangerously low, life-threatening zones. To recognize this phenomenon accurately, the engineering team trained sophisticated machine learning models to identify physiological transitions. The models track the exact state change when a user moves from a baseline healthy state with stable oxygen saturation to an abnormal, critically depressed blood oxygen level.

To prevent errors and establish high confidence, the system fuses multiple sensor inputs. Optical signals tracking oxygenation and pulse are evaluated alongside motion sensors like accelerometers that detect whether the user has become completely motionless or unresponsive. When these combined signals confirm an acute health crisis, the watch utilizes its connectivity to dispatch help:

```mermaid flowchart LR accTitle: Multi-Sensor Breathing Emergency Detection Flow accDescr: Sensor inputs flow into trained machine learning models, leading to automated emergency dispatch when an emergency state is detected.

subgraph Sensors["Pixel Watch Hardware Sensors"] S1["Optical Biosensors: Drop in Oxygen Saturation"] S2["Motion Sensors: Immobility & Unresponsiveness"] end

subgraph ML["On-Device Intelligence"] M1["Machine Learning Models"] M2["Detect State Transition from Healthy to Critical"] end

subgraph Escalation["Emergency Outreach"] E1["Emergency Medical Services (EMS / 911)"] E2["Designated Close Emergency Contacts"] end

S1 --> M1 S2 --> M1 M1 --> M2 M2 --> E1 M2 --> E2 ```

As Jake Sunshine explains: “We bring all of that together to identify someone who we think was in sort of a healthy state a moment ago, and now they're showing signals that they're not in a healthy state.” Because the watch maintains independent or tethered network connectivity, it can automatically alert both emergency services (such as 911 or local equivalents) and designated personal emergency contacts when the wearer is incapacitated and unable to call for help themselves. Rachid then turns to Pramod to explore the exact, step-by-step user experience that unfolds when the watch suspects a breathing crisis is taking place.

`10:00` Escalation Protocol and Emergency Dispatch Integration

Developing a feature capable of contacting emergency services requires a strong balance between advanced technology and user responsibility. Pramod Rudrapatna explains that the team combined state-of-the-art machine learning with thoughtful user-centered design to avoid overburdening the user or overwhelming emergency medical services (EMS). Rather than immediately dispatching an emergency call the instant a drop in blood oxygen is detected, the watch initiates a staged check-in process. It first vibrates via haptics to ask if the user is okay. If the wearer moves around or dismisses the notification, the system stands down. If the user does not respond, the alert escalates to an audible countdown with loud alarms, both to penetrate whatever state the user is in and to attract the attention of bystanders who might be able to help.

```mermaid flowchart TD accTitle: Breathing Emergency Escalation Protocol accDescr: Flow diagram showing how Pixel Watch escalates a detected breathing emergency from user check-in to calling emergency services. subgraph Detection["Detection Phase"] A["Oxygen drop detected"] --> B["Initial Check-in<br/>(Haptics only)"] end subgraph Escalation["Escalation Phase"] B -->|"User dismisses or moves"| C["Alert cancelled"] B -->|"No response"| D["Countdown Stage<br/>(Loud alarm + Haptics)"] D -->|"Bystander / user responds"| C end subgraph Dispatch["Dispatch Phase"] D -->|"No response to alarm"| E["Auto-dial EMS<br/>+ Notify emergency contacts"] E --> F["Automated text transcription<br/>& location sent to dispatcher"] E --> G["Open voice line maintains<br/>two-way audio with dispatch"] end ```

When an alert goes unanswered throughout the countdown, the Pixel Watch places an automated call to emergency medical services and can optionally alert designated emergency contacts. Rudrapatna details that the call provides the operator with critical context, stating that someone has impaired oxygenation along with their exact physical location and an accompanying text transcription. Crucially, the phone line remains open so the 911 dispatcher can listen in, speak directly to the wearer or anyone on scene, and determine whether immediate assets must be mobilized. As Rudrapatna emphasizes regarding dispatch efficiency:

> “So they know what's happening, they know where is it happening, they also have an opportunity to engage with the person before they deploy a response.”

`12:35` Loss of Pulse vs. Breathing Emergencies: Designing for Conscious and Evolving States

Host Rachid Finge brings up the Pixel Watch’s previously introduced Loss of Pulse detection, asking how breathing emergencies compare from the watch's operational perspective. Dr. Jake Sunshine notes that while both are time-sensitive clinical events with clear evidence-based interventions—such as CPR and defibrillation for cardiac arrest—loss of pulse requires immediate, zero-latency action because the heart has ceased pumping. Breathing emergencies are likewise critical, but they feature a much broader clinical continuum. While someone suffering a loss of pulse is almost universally unconscious and unable to interact with the device, someone in the early stages of a respiratory emergency may remain fully conscious and responsive.

This variability introduces immense design complexity. The watch interface must inform a conscious user about what the sensors are observing without causing panic, providing clear health information and lowering every barrier so they can dial 911 themselves if needed. Furthermore, because a person's condition can deteriorate rapidly, the system is designed to monitor progression; if a user gradually loses consciousness after an initial alert, the device will re-alert and execute an autonomous emergency call on their behalf. As Sunshine explains:

> “Because they're sort of diversity of presentation that can happen when someone's experiencing a true emergency. It had to be extremely thoughtfully designed no matter where the person might be as that situation is evolving.”

- **Time-sensitivity spectrum**: Loss of pulse requires instantaneous action (CPR/defibrillation), whereas breathing emergencies allow a small window to assess evolving consciousness. - **Unwitnessed incidents**: Wearable tech is specifically targeted at bridging the gap when an emergency occurs without any bystanders present to intervene. - **Dynamic alerting**: The Pixel Watch supports voluntary user-initiated emergency calls when conscious, transitioning to automated fail-safe calls if the wearer loses responsiveness.

`15:00` Clinical Hypoxia Testing and the Challenge of Sleep Apnea

Validating an algorithm that detects life-threatening drops in oxygen cannot rely on typical office testing. Dr. Sunshine explains that clinical validation was performed under strict informed consent and medical supervision, where human participants had their blood oxygen levels transiently lowered in a safe, controlled clinical setting before being promptly brought back up. This provided the ground truth data needed to evaluate the algorithm's sensitivity to hypoxemic signatures. In an actual medical crisis, the expectation is that blood oxygen will drop and remain depressed, unlike these brief, controlled dips.

```mermaid flowchart LR accTitle: Clinical Testing vs Real-World Discrimination accDescr: Diagram illustrating the clinical trial validation alongside the challenge of filtering out transient sleep apnea events. subgraph Clinical["Controlled Clinical Testing"] A["Informed consent & medical supervision"] --> B["Transient, safe oxygen desaturation"] B --> C["Verify sensitivity to hypoxemic signature"] end subgraph RealWorld["False-Positive Suppression"] D["Undiagnosed sleep apnea"] --> E["Oxygen drops during stillness"] E --> F["Oxygen naturally rebounds"] F --> G["Algorithm suppresses alert<br/>to protect EMS resources"] end ```

Simultaneously, the team had to tackle false-positive rates to avoid burdening the broader public health infrastructure. A prominent real-world challenge is obstructive sleep apnea—a very common, often undiagnosed condition where an individual remains motionless while their oxygen level dips. However, in sleep apnea, the individual's oxygen levels almost always rebound naturally on their own. The algorithm's thresholds had to be calibrated precisely to differentiate between temporary, self-resolving desaturations and sustained, catastrophic breathing failures. As Sunshine reflects on setting those operational limits:

> “And so a lot of thought went into designing that threshold for when we're going to make an alert to make sure that for cases like that, where someone isn't really experiencing something that's very healthy from that event, but might not be an emergency, to make sure that we have things balanced to identify true emergencies and not bother people who might have sleep apnea that's maybe not diagnosed yet.”

`17:41` Pre-Validation Engineering, Dogfooding, and Regulatory Controls

Finge points out that unlike conventional software features where bug fixes are quickly pushed to internal dogfood testers, simulated clinical hypoxia cannot simply be repeated on demand whenever an engineering bug pops up. Rudrapatna agrees, detailing the exhaustive preparation required before entering clinical trials. Google engineers conducted robust end-to-end testing by running the algorithms against historical datasets that had been deliberately held back from model training, as well as testing against internal "dogfood" populations (Google employees wearing the device during everyday life).

By the time the team reached formal clinical validation, the feature was tested as a complete, fully integrated end-to-end product rather than a prototype. The formal validation process serves a dual role: proving the device works under strict criteria in real-world scenarios and fulfilling design controls mandated for submissions to regulatory bodies. Finge clarifies that the primary goal of testing on internal Google employees is to wear the watch normally and verify that it does not fire false alarms during ordinary activities. As Rudrapatna summarizes regarding real-world performance:

> “Our goal here is to build a valuable product minimizing false positives to the great extent.”

`20:00` Validating Across Cohorts and Coordinating with Emergency Responders

Developing life-saving features requires walking a fine line between sensitivity and alarm fatigue. The team had to ensure that the watch reliably triggers when an emergency occurs while keeping false alarms to a minimum, because a safety feature that causes unnecessary panic will quickly be ignored or turned off. To achieve this, the engineering and research teams compared results across several distinct test groups, evaluating data from controlled clinical validation cohorts against internal testing cohorts. Synthesizing these data streams gave Google the confidence that the algorithm would perform as designed once released to the general public in unpredictable, real-world environments.

Rachid Finge notes that beyond the users wearing the watch, there is another critical set of stakeholders: emergency first responders who must handle automated distress calls originating from a wrist wearable. Google recognized early that sending automated calls into public dispatch infrastructures required proactive education rather than unexpected deployment. To prevent emergency call centers from being caught off guard, the team engaged directly with 911 response centers across multiple regions through professional trade organizations, distributing detailed FAQs and hosting educational webinars where dispatchers and public safety administrators could ask technical questions.

```mermaid flowchart TD accTitle: Pre-Launch Protocol for Emergency Services accDescr: Flow diagram showing Google's testing and outreach process before deploying automated emergency calls to 911 centers. subgraph Validation ["Algorithmic Validation"] A["Clinical Hypoxia Cohorts"] --> C["Cross-Cohort Performance Synthesis"] B["Internal Testing Cohorts"] --> C end subgraph Outreach ["Public Safety Outreach"] D["Trade Organization Engagement"] --> E["Webinars & Technical FAQs"] E --> F["911 Dispatch & Response Centers"] end C --> G["Public Deployment with 911 Integration"] F --> G ```

- Pramod Rudrapatna highlights the delicate algorithmic balance required for life safety features: “So there is a very delicate balance that you need to strike.” - Jake Sunshine underscores the gravity of interfacing with public infrastructure: “We, again, take this responsibility extremely seriously when we're building things that connect into these public resources, these 911 systems.” - Google conducted outreach to 911 dispatch networks via webinars and detailed informational materials to ensure emergency personnel understood how and why automated watch calls would be generated.

---

`21:44` The Hypoxia Lab Turning Point and Developing at Society-Level Scale

When Rachid asks Jake whether it was obvious from day one that a consumer smartwatch could detect breathing emergencies, Jake acknowledges that while the scientific theory was promising, translating it into a consumer product posed a massive scalability hurdle. The central obstacle was not merely proving that sensors could identify respiratory distress in ideal circumstances, but achieving a low enough false-positive rate that the system could be distributed broadly without inundating users and emergency networks with incorrect alerts.

The moment the team realized they were genuinely “in the game” occurred during controlled trials inside a hypoxia laboratory. In that setting, researchers induced and observed low-oxygen states under strict medical supervision, proving that the watch maintained high sensitivity for true-positive events. Once those lab-verified algorithms were applied to larger population data sets outside the clinic, the false-positive frequency remained comparable to existing, widely accepted health and fitness sensors, demonstrating that society-scale deployment was technically feasible.

- Jake Sunshine reflects on the central technical challenge: “I think the really hard piece is can you build something that is deployable at sort of society level scale, meaning can you have false positives low enough?” - The hypoxia laboratory acted as the proving ground for true-positive detection before the team evaluated false-positive baselines across larger non-clinical cohorts.

---

`23:31` Working Silently on Public Health Crises and Hearing from Affected Families

Bringing Breathing Emergency Detection to market required years of silent, behind-the-scenes work by multidisciplinary teams across Google Health and hardware engineering. Jake emphasizes that respiratory arrest represents one of modern medicine’s most devastating public health crises, particularly in the context of drug overdoses where individuals frequently die because they are alone and unable to summon assistance. The ability to leverage Google’s manufacturing scale to build an automated safety net for unobserved emergencies felt like an immense responsibility and privilege.

Because the development process occurred under strict secrecy for several years, the team became accustomed to living with the technology in isolation. The true emotional impact hit once the feature was announced publicly and feedback began arriving from external medical specialists and members of the public. Jake notes that hearing from clinical experts who had dedicated their careers to harm reduction and respiratory health—and who viewed this feature as a massive breakthrough—validated years of painstaking research.

The most poignant responses, however, came from people whose loved ones had died during unobserved breathing emergencies where resuscitation came too late. Families reached out to express their gratitude that an engineering team had taken the time and capital to build an automated mechanism capable of sparing other households from identical tragedies.

- Jake Sunshine emphasizes the privilege of addressing large-scale health crises: “And so working on something like that at sort of Google scale is really like a tremendous privilege.” - Jake Sunshine describes the most meaningful user feedback the team received: “And so hearing directly from people who might have had a family member impacted by such a tragedy and, you know, being thankful for us taking the time to build something to help prevent that tragedy for someone else has really been immensely gratifying.”

---

`25:52` Shifting the Overton Window on Wearables and the Health Guardian Vision

Rachid asks whether working on life-saving technology becomes addictive, prompting Jake to describe his role at Google as “the best job in the world” because very few organizations have the engineering talent and capital required to solve problems of this magnitude. Looking to the future, Jake explains that Google wants to shift the “Overton window” regarding consumer expectations for wearables. Instead of viewing smartwatches merely as passive digital accessories meant for tracking jogging routes, counting steps, and previewing text messages, the category should be understood as an active, clinical-grade safety layer that intervenes during acute morbidity and mortality events.

Both Jake and Pramod state that they do not want Google to remain the sole provider of these safety features; rather, they hope competitors across the tech industry adopt similar emergency detection technologies to maximize public health benefits. Pramod explains that both Loss of Pulse detection and Breathing Emergency Detection fit directly under Google’s overarching “health guardian” product vision. This philosophy spans the entire user journey: supporting daily wellness, highlighting subtle chronic health anomalies so users can visit a physician proactively, and serving as an automated emergency responder when unexpected crises render an individual incapable of calling for help.

- Jake Sunshine outlines Google’s broader ambition for wearable devices: “I think what we're trying to do is sort of shift the Overton window on what these devices do.” - Pramod Rudrapatna invites the broader technology industry to follow their lead: “We would love if others, you know, join the bandwagon and build, because the more people who build these potential life-saving features, it's going to be a bigger contribution towards public health.” - The “health guardian” concept is anchored in Google’s mission to help people live longer, healthier lives by providing peace of mind during everyday activities and summoning automated assistance when life brings the unexpected.

## Notable quotes > `21:44` I think the really hard piece is can you build something that is deployable at sort of society level scale, meaning can you have false positives low enough? — Jake Sunshine

> `25:52` We would love if others, you know, join the bandwagon and build, because the more people who build these potential life-saving features, it's going to be a bigger contribution towards public health. — Pramod Rudrapatna

## Mentioned Breathing Emergency Detection, Fitbit, Google, Google Health, Jake Sunshine, Loss of Pulse Detection, Pixel Watch, Pixel Watch 4, Pixel Watch 5, Pramod Rudrapatna, Rachid Finge, University of Washington

## Video description <p>How can a smartwatch on your wrist do more than just track steps and actually help in a life-threatening situation? </p><br><p>Host Rachid Finge sits down with Google Health research scientist Jake Sunshine and product manager Pramod Rudrapatna to go deep on Breathing Emergency Detection, a breakthrough feature for the Google Pixel Watch. </p><br><p>They uncover the incredible story of its creation, from the initial "what if" moment to the immense challenges of clinical testing and the user-centered design that ensures it can summon help when someone is unable to themselves. It’s a look at how everyday devices are being reimagined to act as true health guardians, potentially saving lives when every second counts.</p><hr><p style='color:grey; font-size:0.75em;'> Hosted on Acast. See <a style='color:grey;' target='_blank' rel='noopener noreferrer' href='https://acast.com/privacy'>acast.com/privacy</a> for more information.</p>

[Source](https://sphinx.acast.com/p/open/s/63e39eb02e631f0011a284ac/e/6aaf867851da7059ecd7c88b/media.mp3)

中文简报

Google Pixel Watch 针对严重低血氧新增自动呼救功能 消费级智能手表通过结合光学与运动传感器,可在佩戴者失去行动能力时自主呼叫急救人员,从而防范无人在场时的致命呼吸危机。 在本期节目中,Jake Sunshine 与 Pramod Rudrapatna 阐释了 Pixel Watch“呼吸紧急检测”功能背后的临床动机与工程架构。该功能可在药物过量、肺炎或窒息等孤立紧急情况下,识别严重的血氧饱和度下降。该系统将光学式生物传感器与运动追踪及机器学习模型相结合以检测急性状态变化,在自动拨打急救医疗服务并提供位置与背景数据之前,先执行从触觉提示到声音警报的分级上报流程。嘉宾们详细介绍了为将致命事件与睡眠呼吸暂停等自愈性状况区分开来而开展的大量临床缺氧测试,以及旨在帮助 911 调度网络适应可穿戴设备自动呼叫的外联倡议。最后,他们描绘了 Google 更广泛的“健康守护者”愿景,力求推动消费级可穿戴设备领域发生理念转变,从被动的健身追踪迈向主动的临床安全干预。 Google 在欧洲部分国家为 Pixel Watch 4 和 5 推出了呼吸紧急检测功能,利用设备内置的光学和运动传感器,在血氧饱和度降至危险低位时自动向急救服务报警。 (1:45) 该检测系统将机器学习模型与分级预警机制相结合——从轻微的触觉确认逐步升级到大声警报——随后自主拨打急救调度电话,并提供位置数据、文本转录以及开放音频通道。 (10:00) 为防止误报令急救医疗服务网络不堪重负,算法经过校准,能够将灾难性的持续缺氧与阻塞性睡眠呼吸暂停等常见病症引起的短暂、可自愈事件区分开来。 (15:00) Google 旨在推动消费级可穿戴设备范式从被动健身追踪转向主动健康守护,并公开鼓励行业竞争对手采用类似的救命应急机制。 (25:52)

Reading summary

Google Health has introduced Breathing Emergency Detection for the Pixel Watch, utilizing optical sensors and machine learning to automatically call emergency services when persistent, life-threatening oxygen drops occur during unwitnessed medical crises. Targeting Unwitnessed Respiratory Crises (1:45) According to Google Health research scientist Dr. Jake Sunshine and product manager Pramod Rudrapatna, acute breathing emergencies—such as accidental drug overdoses, severe pneumonia, or acute choking—frequently occur when individuals are alone and physically incapacitated. Although effective clinical interventions exist, they cannot be deployed if nobody is present to contact emergency services. Breathing Emergency Detection aims to convert these unobserved crises into witnessed events by autonomously summoning aid. The capability is launching as an opt-in feature on the Pixel Watch 4 and Pixel Watch 5 in select European countries. Unlike sudden loss of pulse, which typically causes immediate unconsciousness, respiratory emergencies present along a continuum where individuals may remain temporarily conscious before deteriorating, requiring the system to support both voluntary user calls and automated fail-safes. Multi-Sensor Detection and Sleep Apnea Discrimination (7:44) The feature uses consumer-grade optical sensors comparable to hospital pulse oximeters alongside motion sensors like accelerometers. Machine learning models evaluate these combined data streams to identify physiological transitions from a stable baseline to critically depressed blood oxygen levels accompanied by immobility, rather than momentary fluctuations. A central technical challenge involved filtering out common non-emergency anomalies, particularly obstructive sleep apnea, where an individual remains motionless while their oxygen level temporarily dips. Because oxygen levels almost always rebound naturally during sleep apnea episodes, the engineering team calibrated the algorithm's thresholds to identify sustained, non-recovering desaturations to avoid overburdening emergency responders. Staged Escalation and Emergency Dispatch Integration (10:00) To prevent accidental 911 calls, the watch executes a tiered escalation process upon detecting an oxygen crash. The device first initiates a check-in using haptic vibrations; if the wearer moves or dismisses the notification, the system cancels the alert. If the user remains unresponsive, the device escalates to an audible countdown with loud alarms designed to pierce the user's state and attract bystanders. If the countdown expires unanswered, the watch automatically dials emergency medical services and alerts designated personal contacts. The call delivers automated text transcription, communicates that the user has impaired oxygenation, and transmits their exact physical location, while keeping an open two-way voice channel so dispatchers can listen and speak directly to the scene. Google also conducted outreach to 911 dispatch networks via technical FAQs and webinars to ensure first responders understood the automated call format before deployment. Clinical Hypoxia Validation and Controlled Testing (15:00) Validation required controlled clinical trials conducted with informed consent and medical supervision, where human participants underwent transient, safe oxygen desaturations to establish ground truth data. Jake Sunshine described the hypoxia laboratory trials as the turning point that confirmed the watch could identify true-positive hypoxemic signatures with high sensitivity. Prior to formal clinical trials, Google engineers validated complete software builds against held-back historical datasets and deployed internal tests across Google employees during everyday routines. Synthesizing data between daily non-clinical wearers and clinical hypoxia cohorts verified that the feature could maintain low false-positive rates at society-level scale and fulfilled design controls required for regulatory submissions. Shifting Wearables Toward Active Health Guardianship (25:52) Google frames Breathing Emergency Detection and the earlier Loss of Pulse feature as part of an effort to shift the "Overton window" for consumer wearables. Instead of viewing smartwatches merely as passive activity trackers for step counts and notifications, the team envisions them as active, clinical-grade safety guardians capable of intervening during acute health events. Both Sunshine and Rudrapatna emphasized that Google hopes competing technology companies will implement similar emergency detection capabilities. In their view, broad industry adoption of automated crisis detection on continuous day-and-night wearables maximizes the overall public health benefit. Breathing Emergency Detection expands consumer wearables into autonomous emergency response, but its real-world effectiveness relies on maintaining low false-positive rates to prevent alarm fatigue and emergency dispatch strain. Its initial rollout remains limited to select European countries and newer Pixel Watch hardware as an opt-in feature.

精炼阅读摘要

Google Health 团队在 Made by Google 播客中详细介绍了 Pixel Watch 推出的“呼吸紧急情况检测”(Breathing Emergency Detection)功能。该技术旨在通过光学与运动传感器融合及机器学习模型,在佩戴者因药物过量、重症肺炎或窒息导致血氧持续骤降且失去求救能力时,自动联系紧急医疗服务。 技术定位:将无人目击的危局转为可干预事件 (1:45) 据 Google Health 产品经理 Pramod Rudrapatna 与研究科学家 Jake Sunshine 介绍,呼吸紧急情况检测被设计为 Pixel Watch 4 和 Pixel Watch 5 上的可选开启功能,首批在欧洲部分国家上线。该技术聚焦于药物过量、重症肺炎或急性窒息等突发状况。这类危急情况往往发生在用户独处且失去行动能力时,即便现有的公共医疗体系具备成熟挽救生命的手段,也会因无人能够拨打求助电话而错过时机。该功能的核心目的正是将“无人在场的隐蔽危局”转变为“已被感知的干预事件”,自动调度公共医疗资源。 多传感器融合与分级升级警报机制 (7:44) 与单纯监测心跳消失的脉搏骤停检测(Loss of Pulse)不同,呼吸急症在临床上表现为一个连续的生理演变过程。Jake Sunshine 指出,Pixel Watch 采用相当于医用级脉搏血氧仪的光学传感器,结合加速度计等运动感应硬件,通过在设备端运行的机器学习模型捕捉用户从健康基线到危险缺氧及完全静止的状态转变。 为避免不必要的恐慌并减轻公共急救负担,系统设计了阶梯式的升级流程。Pramod Rudrapatna 说明,当监测到血氧危急降低时,手表首先通过触觉震动进行轻量询问;若用户移动或手动关闭,警报即刻终止;若无响应,系统会升级为高分贝声音倒计时警报,以此唤醒佩戴者或引起周围旁人注意。若倒计时结束仍无人应答,手表将自动呼叫紧急医疗服务并通知预设紧急联系人,向接警员播报包含缺氧状况和精准地理位置的文字转录语音,同时保持通话线路开启,以便接警人员随时介入评估现场情况。 临床试验验证与睡眠呼吸暂停的假阳性过滤 (15:00) 将算法部署于数以百万计的日常消费设备,关键在于确保极低的误报率。Jake Sunshine 透露,团队在严格的知情同意与医疗监护下,于低氧实验室开展临床验证,通过让受试者产生短暂且受控的安全低氧血症,获取真实的生理特征数据。他们同时使用被隔离于训练集之外的历史数据和 Google 内部员工日常佩戴测试来进行端到端验证。 现实场景中最严峻的技术挑战来自阻塞性睡眠呼吸暂停。这类常见且多未确诊的疾病同样表现为“睡眠时身体不动伴随血氧下降”,但其缺氧通常能在短时间内自行反弹恢复。Google 团队经过严密标定,设立了精确的时间与生理阈值,使算法能够智能区分“可自行恢复的短暂缺氧”与“致命且持续的呼吸衰竭”,从而避免对未确诊睡眠呼吸暂停的正常用户造成打扰,保护紧急救援资源不被虚假警报耗尽。 协同公共安全网络与构建健康守护者生态 (20:00) 由于智能手表具备直接接入公共 911 调度系统的能力,团队在发布前积极对接了多地的紧急呼叫中心与行业组织,通过专业网络研讨会和详尽的技术 FAQ 提前开展沟通,避免自动化求助电话对第一响应人员造成困扰。研发团队表示,这项耗时数年在保密状态下开发的技术,在对外公布后收到了来自伤害预防医学专家以及曾因救援延迟痛失亲属的家庭的积极反馈。 Google 团队提出,这标志着智能可穿戴设备正在推动行业“奥本海之窗”(Overton window)的转移——从以往步数记录和运动追踪的被动工具,进化为具备临床级安全监护能力的“健康守护者”。Pramod Rudrapatna 与 Jake Sunshine 明确表示,希望竞争对手也能跟进并开发类似的自动求救功能,共同扩大对公众健康危机的防护覆盖面。 该技术目前作为特定机型及特定欧洲地区的自选功能推出,其长期有效性依赖于算法在更大规模人群中对偶发假阳性的压制,以及与各地公共急救调度基础设施的持续协调配合。

Detailed notes — zh

## Background 本期内容源自 Made by Google Podcast 于 2026 年 9 月 21 日在 RSS 及网络平台上发布的播客节目。根据页面简介,主持人 Rachid Finge 邀请了 Google Health 研究科学家 Jake Sunshine 与产品经理 Pramod Rudrapatna,深入探讨 Pixel Watch 最新推出的“呼吸急救检测”(Breathing Emergency Detection)突破性功能。节目聚焦于该功能从最初构想到攻克临床测试挑战、再到以用户为中心的挽救生命交互设计全过程,展现了日常可穿戴设备如何演进为守护生命的健康卫士。 ## TL;DR 节目全面拆解了 Google Pixel Watch 突破性的“呼吸急救检测”功能:当用户因意外药物过量、重症肺炎或窒息等原因导致血氧严重暴跌且失去自救能力时,手表能结合光学传感器与运动传感器识别险情并代为呼叫急救。嘉宾详细阐述了以触觉和警报为主的渐进式报警升级机制,既能保护意识模糊的用户,又能避免给公共急救网络造成骚扰。同时,团队分享了在低氧实验室进行的严谨临床验证、排除睡眠呼吸暂停等假阳性的算法调优经验,以及提前对接 911 等急救调度系统的沟通策略,旨在推动大众对消费级穿戴设备认知边界的转变。 ## Atmosphere & style 对谈整体洋溢着深厚的人文关怀与严谨克制的专业医学精神。主持人的发问清晰流畅,两位嘉宾则在深奥的临床病理学、端到端机器学习算法与细腻的产品交互之间自如穿梭,叙事既具有硬核工程的逻辑张力,又始终不脱离挽救鲜活生命的崇高使命。当谈到在低氧实验室取得突破、以及收到遭遇变故的家庭发来的真诚感谢时,现场流露出真挚而动人的敬畏与欣慰,让听众深刻体会到消费级科技在面对生死关头时所蕴含的守护力量。 ## Bulletin - `00:00` Google 在 Pixel Watch 4 与 Pixel Watch 5 上推出了“呼吸急救检测”功能,当佩戴者血氧持续严重下降且失去反应时,手表将代为拨打当地紧急医疗救助电话。 - `00:00` 该功能专为“无人目击”的致命场景设计,针对因药物过量、重症肺炎或异物窒息导致的严重缺氧,打破了以往因患者无法自救而错失急救黄金时间的痛点。 - `10:00` 交互流程采用递进式升级机制:首先通过触觉振动进行确认,若无反应则升级为高分贝警报和强震动,倒计时结束后自动呼叫 EMS 并保持线路畅通以供现场双向监听。 - `15:00` 为了避免假阳性,团队在算法中特别排除了睡眠呼吸暂停等可自愈的短暂血氧骤降,并在正式进行临床验证前通过 Google 员工的长期日常佩戴(Dogfooding)压低误报率。 ## Key takeaways - `00:00` 呼吸急救检测能在佩戴者血氧持续降至危险阈值且失去反应时,主动向当地紧急医疗救助机构(EMS)呼救并通知紧急联系人。 - `00:00` 该技术解决的核心临床痛点是将致命但“无人目击”的孤立危急事件(如意外药物过量、窒息),转化为有公共急救资源介入的被见证险情。 - `05:00` 现代智能手表与手机的计算能力已大幅超越传统医院病房设备,使得原本局限于重症监护的生命监测技术有潜力向日常消费级设备迁移。 - `08:00` 系统结合了光学血氧传感器与 IMU 运动传感器,通过机器学习算法综合研判血氧断崖式下跌与身体持续静止不动两个关键指标。 - `10:00` 报警流程严格遵循以用户为中心的设计:由静默的触觉振动提示递进至高分贝声光警报,只有在倒计时耗尽且无反应时才触发自动报警,避免给急救系统带来误报负担。 - `10:00` 在拨打急救电话时,设备会播报结构化医疗信息、自动转录文本和精准位置,并持续开启语音线路供调度员实时监听现场状况。 - `12:21` 与心跳骤停几秒内即丧失意识不同,呼吸急救初期患者往往仍有意识,这要求系统必须兼顾清醒状态下便捷的手动求救与失去意识后的自动呼救升级。 - `15:00` 算法研发的关键挑战在于区分真正的窒息急症与睡眠呼吸暂停;后者虽然同样伴随身体静止和血氧下降,但机体会自行反射性恢复,无需触发公共医疗求救。 - `17:41` 进入严苛的监管临床验证之前,团队利用历史独立数据集反向验证,并依赖全职员工的大规模日常佩戴测试来检验算法在复杂现实场景下的鲁棒性。 - `20:00` 为避免自动化呼叫给急救网络造成认知冲击,Google Health 团队在功能上线前通过行业协会向各地 911 调度中心下发 FAQ 并开办答疑研讨会。 - `22:15` 该项目的关键突破点在于低氧实验室测试,团队验证了算法不仅灵敏度达标,且误报率低至足以进行社会级规模部署的水平。 - `25:00` 从被动的步数和健身追踪走向关键时刻的主动生命干预,Google 试图推动大众对可穿戴设备认知能力的“奥芙顿之窗”,将其重塑为全天候的健康守护者。 ## Detailed walkthrough ### `00:00` 嘉宾背景与呼吸急救检测的定义 主持人 Rachid Finge 欢迎 Google Health 研究科学家 Jake Sunshine 以及产品经理 Pramod Rudrapatna 来到《Made by Google Podcast》,共同探讨 Pixel Watch 带来的突破性健康功能——“呼吸急救检测”(Breathing Emergency Detection)。在进入核心技术之前,两位嘉宾分享了各自进入消费级医疗科技领域的成长轨迹: - **Jake Sunshine** 拥有医生执业背景,并担任华盛顿大学(University of Washington)教席。他长期致力于探索如何将智能手机、智能音箱及可穿戴设备等大众消费级设备用于健康传感。2022年,Google 收购了他与华盛顿大学团队创立的衍生公司,推动了消费级传感技术在医疗健康前沿领域的落地。 - **Pramod Rudrapatna** 现任 Google Health 团队产品经理,负责推进设备前沿传感技术。五年前,他随着 Google 对 Fitbit 的收购加入团队。尽管此前一直在硬件、软件与 AI 的交汇点工作,但他始终对健康科技抱有热忱,坚信这是能对公共健康产生深远影响的领域。 当被问及如何用一句话概括这项功能时,Pramod Rudrapatna 给出了明确定义:“呼吸急救检测能够在你的血氧饱和度持续下降到危险的极低水平时,代为拨打紧急医疗服务电话。”(“Breathing emergency detection can place a call to emergency medical services when your oxygen saturation drops to dangerously low levels persistently.”) Pramod Rudrapatna 解释,导致血氧骤降的原因包括意外药物过量(accidental drug overdose)、重症肺炎(severe pneumonia)以及异物窒息(choking)等。这类事件极其致命的核心痛点在于:它们绝大多数都属于“目击者缺位”(unwitnessed)的险情。现场往往没有任何人能协助呼叫救援,尽管医疗体系中早已备有现成的急救方案,患者却无法获取。该功能的核心突破,就在于将这类型缺位孤立的突发危急事件转变为“被见证的紧急状况”,借助公共急救资产挽救生命。目前,这是一项在指定欧洲国家、Pixel Watch 4 与 Pixel Watch 5 上可选择开启(opt-in)的功能。 --- ### `05:00` 从步数追踪到“健康守护者”:突破消费电子的算力边界 主持人提到,大众对智能手表的认知通常停留在步数追踪和睡眠监测,很难想象手表能检测脉搏消失(Loss of Pulse Detection)乃至呼吸急救。对此,Pramod Rudrapatna 分析了可穿戴设备的演化逻辑:健康追踪设备面世已有十余载,但手腕设备的潜力远超计步和测睡眠。团队开始思考公共健康层面尚未被满足的需求:用户无法通过日常显性症状察觉的问题,或者“在用户自身完全丧失求救能力时进行识别”。 在传统认知中,无脉搏或呼吸衰竭等公共健康挑战多由心脏骤停或呼吸系统衰竭引发,且大部分发生在无人看护的场景下。消费级设备若能抓住这一关键契机,代表失去行动能力的用户发起呼救,就能让可穿戴设备真正实现质的飞跃。 Jake Sunshine 从临床医学的视角补充了技术可行性的发端。在手术室(operating room)、重症监护病房(ICU)和普通病房工作的岁月里,他经常观察那些维持患者生命的传统医疗仪器。他发现了一个巨大的技术反差:“如果你对比现代医院里医疗设备的技术规格,再把它放在现代智能手机、智能音箱或手表的旁边,你会发现我们口袋里随身携带、日常围绕着我们的这些设备,在计算能力上与现代医院里的传统设备相比存在着巨大的差距。”(“It's actually quite funny, if you compare the sort of the technical specifications of medical equipment that's sort of in the hospital, and then you put it next to like a modern smartphone or smart speaker or watch, there is a huge difference in computational capabilities in these devices that we have all around us and that we carry in our pockets compared to this like traditional equipment that's in like a modern hospital.”) 这种算力反差让团队意识到,外界看似只属于临床病房的生命监护需求,完全有潜力转移到院外的大众生活场景。通过严谨且递进式的研究,团队逐步降低了技术风险:先是攻克了脉搏消失检测,如今又将呼吸急救检测落地,用详实的数据证实了这些日常设备在无人目击场景下预警致命风险的安全性与有效性。 --- ### `08:00` 多模态传感与机器学习协同求救 相比于“脉搏消失”这种直观的心率停跳逻辑,呼吸急救的检测原理更为复杂。Jake Sunshine 详细拆解了 Pixel Watch 背后的传感架构与判断机制: 手表内置了与医院级设备同等原理的光学传感器。这些传感器最初多用于运动期间的心率监测。当用户遭遇严重的呼吸危急情况时,血液中的氧气水平会断崖式暴跌至非健康的危险阈值。团队通过训练机器学习(ML)模型,敏锐捕捉佩戴者生理状态的断层突变——即从前一刻指标平稳健康的基线状态,转变为血氧严重失常的极危状态。 ```mermaid flowchart TD accTitle: 呼吸急救检测与救援链路 accDescr: 展示从传感器采集、机器学习模型综合研判到触发急救呼叫的多模态流程。 subgraph Sense ["多模态信号感知"] PPG["光学传感器<br>(实时监测血氧/心率突变)"] IMU["运动传感器<br>(监测身体静止/丧失响应)"] end subgraph Analyze ["机器学习研判"] ML["ML 异常模型<br>(比对健康基线与危险暴跌状态)"] end subgraph Action ["级联求救响应"] EMS["拨打当地紧急医疗服务<br>(如 911 / 112)"] Contacts["自动通知紧急联络人"] end PPG --> ML IMU --> ML ML -->|"判定处于失能状态的呼吸急救"| EMS ML -->|"同步警报与位置"| Contacts ``` 在判断过程中,算法并不是单看某项指标,而是引入了运动传感器: - 观察身体是否长期保持静止不动; - 确认用户是否已经处于失去反应(unresponsive)的状态; - 将运动静止与血氧暴跌的信号交织分析,锁定“前一秒状态良好,此刻陷入生命危险且无力自救”的特定状态。 一旦确认险情成立,由于 Pixel Watch 具备网络连接能力,它不仅能直接联系当地急救服务中心(如 911),还能同步通知预设的紧急联络人,确保在用户失去意识的生死关头,多方救援网络能够即刻响应。最后,主持人向负责用户体验设计的 Pramod Rudrapatna 提问,试图探讨当呼吸危机突发时,佩戴者在手表端究竟会经历怎样的交互细节与级联救援流程。 ### `10:00` 呼吸急救检测的交互设计与报警升级机制 在设计呼吸急救(Breathing Emergency Detection)功能时,团队的核心考量是负责任的技术落地:既不能用频繁的通知过度打扰用户,也不能给公共卫生体系和紧急医疗服务(EMS)带来不必要的拨打负担。产品经理 Pramod Rudrapatna 解释道,Pixel Watch 并没有在算法发现异常时立即盲目拨打急救电话,而是结合了以用户为中心的设计(User-Centered Design),设置了一套渐进式的确认流程: ```mermaid flowchart TD accTitle: 呼吸急救报警升级与响应流程 accDescr: 展示从检测到血氧骤降到通知急救人员的完整升级逻辑,包括触觉询问、声光倒计时及最终通话。 subgraph UserCheck["第一阶段:用户主动确认"] A["算法检测到血氧异常下降"] --> B["触觉振动 Check-in:<br>'发现血氧下降,你还好吗?'"] B -->|"用户移动或手动点击忽略"| C["流程终止<br>判定非紧急情况"] end subgraph Escalation["第二阶段:报警升级"] B -->|"无响应"| D["触发倒计时阶段"] D --> E["高分贝报警音 + 强触觉反馈"] E -->|"唤醒用户或引来周围路人协助"| F["用户/路人手动处理"] end subgraph EMSCall["第三阶段:呼叫紧急医疗救助"] E -->|"倒计时结束仍无响应"| G["自动拨打急救电话 (EMS)"] G --> H["发送转文字信息与精准地理位置"] G --> I["(可选)同步通知紧急联系人"] G --> J["保持线路畅通<br>接线员可直接与现场双向通话"] end ``` 当算法监测到用户发生呼吸异常时,手表首先会以纯触觉振动(Haptics)形式向用户弹出 Check-in 询问:“我们观察到您的血氧水平下降,您还好吗?”若用户尚有意识且认为无需就医,可通过移动手腕或手动在屏幕上将其关闭。若用户完全没有反应,系统则会进入倒计时升级阶段。此时,手表会发出尖锐响亮的警报音并伴随更强烈的触觉刺激——这既是为了促使处于昏睡或迷糊状态的用户做出反应,也是为了引起周围路人的注意以便实施救助。如果倒计时结束后用户依然毫无回应,Pixel Watch 才会自动向紧急医疗救助机构发起呼叫,并同步通知预设的紧急联系人。 针对主持人 Rachid Finge 提出的“急救调度员接通后会听到什么”这一疑问,Pramod 详细描述了呼叫环节的实际体验:系统会明确告知接线员“检测到当事人处于血氧不足状态”,并同步报送佩戴者的精准地理位置及自动转录文本;与此同时,语音通话线路会始终保持开启状态,接线调度员能直接听到现场声音并尝试与佩戴者远程对话。正如 Pramod 所强调的,这种设计让救护机构不仅能获取定位与生理状况,还能在出车前根据现场声音更精准地研判紧急程度,确保最宝贵的救援资源得到最合理的调度。 - 系统首要原则是“以用户为中心”,绝不因单次算法判定而盲目直拨 911/EMS。 - 第一层响应仅使用触觉振动提示,为误触或轻微身体变化留出反应窗口。 - 倒计时阶段的高音量警报具备双重作用:唤醒佩戴者或提示周围旁观者介入。 - 接线端包含结构化数据播报、地理位置上报及双向实时通话监听。 --- ### `12:21` 呼吸急救与脉搏骤停检测的临床异同 谈及与去年推出的“脉搏骤停检测”(Loss of Pulse Detection)的对比,Google Health 研究科学家 Jake Sunshine 详细拆解了两者的临床特征与干预逻辑。这两种算法均聚焦于“时间极度敏感”的致命危机,但心跳骤停与呼吸骤停在急迫程度和患者交互能力上有着根本性的区别。 Jake 指出:“你可以认为脉搏骤停对时间更加敏感,因为病人的心脏已经停止跳动,他们需要立即得到救治才能活下来;我们通常会想到心肺复苏术(CPR)和除颤器,这些属于分秒必争的干预措施。”相比之下,呼吸急救虽然同样十分致命,但患者通常会经历一段逐渐缺氧的过程。脉搏骤停患者通常会在几秒内瞬间丧失意识,根本无法对穿戴设备做出任何反馈;而呼吸急救的佩戴者在初期往往仍保留意识,这反倒给交互设计带来了极高的复杂度。 > “这在一定程度上让问题变得复杂得多,因为人们可能正处于呼吸急救的最初阶段,并且依然能够做出回应。” —— Jake Sunshine 因此,在呼吸急救功能的设计中,系统必须向清醒的用户清晰传达报警原因,以极低的门槛帮助他们主动发起呼救;而若患者在异常发展过程中失去意识,设备必须具备二次报警(Re-alert)及代表用户自动呼救的能力。Jake 总结道:“由于一个人在遭遇真正的紧急状况时可能呈现出多样的体征与反应,因此无论当事人处于病程发展的哪一个阶段,整个系统的设计都必须经过极其审慎的推敲。” --- ### `15:00` 临床模拟测试与睡眠呼吸暂停等假阳性排除 涉及生命安全的功能无法通过普通的“让同事戴上手表试用”来完成全流程验证。针对如何在确保受试者绝对安全的前提下进行临床验证,Jake 介绍了专门的“受控降氧测试”:在获得知情同意并由专业医护人员全程严密监护的临床环境下,受试者体内的血氧水平会被人为、短暂地诱导下调,以此采集手表传感器捕获到的血氧暴跌特征数据,随后医护人员会立即帮助受试者恢复正常血氧。 在真实发生的急救事件中,患者的血氧水平往往持续处于危险低位;然而,在日常生活场景中,也存在多种血氧短暂骤降却并非致命急症的生理现象,最典型的便是睡眠呼吸暂停(Sleep Apnea)。Jake 解释说,睡眠呼吸暂停是一种极其普遍但很多人并未确诊的疾病;患者入睡后身体同样会保持静止,血氧也会出现下降,但随后人体的保护反射几乎总能让血氧自行回升,这并非突发急救事件。研发团队花费了大量精力精细校准警报触发的生理阈值,旨在既能准确捕捉真正的窒息危局,又不会将未确诊的呼吸暂停患者在睡眠中无休止地惊醒打扰。 - 临床真阳性数据采集:在医疗监护与知情同意下,让受试者经历短暂、可控的血氧降低并立即复原。 - 真实急危重症特征:血氧骤降后长时间维持在极低水平,伴随持续无肢体反应。 - 假阳性常见诱因:睡眠呼吸暂停引发的间歇性缺氧(通常能自行代偿回升且非即时致命)。 - 算法挑战:在保证高灵敏度的同时提高特异性,避免对日常无生命危险的生理波动发出误报。 --- ### `17:41` 监管验证标准与员工“吃狗粮”测试 针对传统软件产品经理面对 Bug 时“修完发补丁再测”的常规操作,主持人提出疑问:在严苛的医疗穿戴场景下,团队显然不可能随意召集受试者反复进行降氧实验。Pramod 确认了这一研发流程的特殊性与严肃性——在正式进入临床验证前,算法必须达到极高的确定性。 为此,团队制定了极其严密的端到端准备方案:在启动正式临床验证前,算法不仅在未参与过训练的历史独立数据集上进行反向验证,还通过庞大的 Google 员工“吃狗粮”(Dogfooding)测试群体在现实生活中长时间佩戴运行。Pramod 直言:“我们不能保证 100% 绝对无误,但我们必须以高度确信能通过的心态进入测试。我们必须穷尽一切手段运行各种边缘场景,确保在正式进入临床验证之前整个系统坚不可摧。” 在提交给监管机构进行审查及遵循设计控制(Design Control)规范的临床验证中,团队所部署的是功能完全就绪的端到端软硬件产品。与此同时,大规模的员工日常佩戴测试被用作一种现实环境中的“健全性检查”(Sanity Check)。Pramod 强调,在现实世界中构建这类系统,假阳性概率很难做到绝对的零,但团队的核心目标是在实现生命救援价值的同时,将误报率压制在极低水平。 > “在进入临床验证时,我们拿出的已经是能够端到端正常工作的完整产品,我们在验证中使用的是功能完备的终版产品。” —— Pramod Rudrapatna ### `20:00` 误报率平衡与急救系统的提前沟通 在将呼吸紧急检测功能(Breathing Emergency Detection)推向真实世界之前,工程与产品团队必须在误报与漏报之间找到极其精准的平衡。Pramod Rudrapatna 指出,研发团队绝不能为了追求零误报而让整个算法变得过度钝化:“你绝对不希望陷入一种为了追求零误报、结果导致整个功能毫无用处的境地;这里面需要把握一种非常微妙的平衡。”团队在内部受试人群和不同临床验证队列之间比对数据,确保算法在多组人群中表现出高度一致性,从而有极大把握让手表在面向大众推送时能够完全按照预期工作。 与此同时,手表在触发紧急求助时会直接拨打公共急救电话,这使得与公共安全接警中心(911 等机构)的沟通成为不可妥协的一环。团队非常谨慎地对待连接公共急救资源这一巨大责任,避免急救调度员在接到手表自动求救电话时感到突兀或不知所措。 ```mermaid flowchart TD accTitle: 911及急救系统对接流程图 accDescr: 展示 Google Health 团队在功能发布前如何与急救系统进行多渠道沟通与培训的流程 subgraph Align["前期标准与队列对齐"] A["多组临床队列与内部测试"] --> B["算法误报/漏报平衡"] end subgraph PreLaunch["面向公共急救系统的前期沟通"] B --> C["行业组织渠道下发 FAQs"] C --> D["面向各地 911 调度中心开办线上研讨会"] D --> E["答疑与沟通,消除突发认知空白"] end subgraph PublicRollout["正式推送与应用"] E --> F["Pixel Watch 算法全面推向大众"] F --> G["遇险时自动拨打紧急电话求助"] end ``` - **行业组织沟通**:利用急救调度行业的行业协会与组织,提前向全美各地的 911 接警响应中心下发常见问题清单(FAQs)。 - **线上研讨会答疑**:团队通过举办网络研讨会(Webinars),为一线急救人员提供直接提问和深入沟通的机会,消除任何可能因自动化呼叫带来的意外与误解。 --- ### `22:15` 从低氧实验室到社会级规模:研究突破的决定性时刻 主持人 Rachid Finge 询问研究科学家 Jake Sunshine,这项功能在最初立项时是一开始就明朗可行,还是摸着石头过河。Jake 坦言,理论上团队相信这是可行的,但最艰难的技术死穴在于:“真正的难点在于——你是否能够打造出一套可以在社会级规模上部署的系统,也就是说,在误报不可避免客观存在的前提下,你是否能把误报率压得足够低,让这项功能真正具备实用价值?” 转折点发生在低氧实验室(Hypoxia Lab)的测试期间。当团队看到算法在实验室诱发低氧环境中表现出优异的敏感度(真阳性检测率),并且随后扩展到更大规模人群中进行对比测试仍能保持极高水准时,大家终于确信:“我们完全有戏了(we're likely in the game)。” 谈及多年潜心研发终于落地的心理感受,Jake 表达了强烈的震撼与感恩。呼吸急救问题(例如药物过量导致的呼吸暂停)是极其严峻且普遍的公共卫生挑战。对于研发团队而言,默默无闻耕耘数年后突然公之于众,那种感觉几乎难以言表。 - 领域内将毕生精力投入此类公共卫生挑战的专家们给予了极高评价,称该功能为“重大突破(huge breakthrough)”,并预测它将挽救大量生命。 - 最令团队动容的反响,来自那些曾经因为家人遭遇呼吸急救事故未能及时复苏而失去亲人的普通人;听到他们感谢团队愿意花时间打造这一系统以防止其他家庭重演悲剧,给整个团队带来了巨大的成就感。 --- ### `25:00` 移动手表的“奥芙顿之窗”与守护健康的终极使命 当 Rachid 问及打造救命功能是否会“让人上瘾”时,Jake 坦言自己拥有世界上最好的工作。全球极少有企业能像 Google 一样投入如此庞大的计算、工程与临床资源来直面社会级的重大疾病和死亡率挑战。Jake 认为,这项工作的更深层意义在于重塑大众对消费类穿戴设备的认知: > “我想我们正在努力做的,是推动人们对这些设备能力认知的‘奥芙顿之窗’(Overton window)发生转移。” —— Jake Sunshine 手表不再仅仅是记录步数、查看短信或健身追踪的配件,而是演变为在无人在场或无法自救时真正能够挽救生命的健康守门人。Jake 和 Pramod 都真诚呼吁行业内的其他公司也加入这一行列。Pramod 强调,越多的厂商跟进打造同类救命功能,对全人类公共健康的推动就越大。 ```mermaid flowchart LR accTitle: Pixel Watch 健康守护者定位模型 accDescr: 展现从日常健康监测到突发被动求救的健康守护者功能层级 subgraph Daily["日常全周期伴随"] M1["健身运动追踪"] M2["被动健康洞察<br/>提示潜在身体问题并就医"] end subgraph Emergency["突发危急事件介入"] E1["脉搏骤停检测<br/>(Loss of Pulse)"] E2["呼吸急救检测<br/>(Breathing Emergency)"] end Daily -.->|"构筑心理基石"| G["Health Guardian 核心理念"] Emergency -->|"用户无法自救时介入呼救"| G ``` Pramod 总结了 Google 开发此类功能的核心使命——赋能用户过上更长寿、更健康的生活: - **Health Guardian(健康守护者)理念**:通过持续监控为用户提供内心的安宁(peace of mind),帮助他们察觉平时无法自知的健康隐患,以便及时就医或进行健康干预。 - **全生命周期陪伴**:从日常的健康与健身管理,到遭遇脉搏骤停(Loss of Pulse Detection)或呼吸急救(Breathing Emergency Detection)等突发意外、无法为自己呼救的关键时刻,设备始终在场守护并主动代为求援。 ## Notable quotes > `20:00` 你绝对不希望陷入一种为了追求零误报、结果导致整个功能毫无用处的境地;这里面需要把握一种非常微妙的平衡。 — Pramod Rudrapatna > `17:41` 我们必须穷尽一切手段运行各种边缘场景,确保在正式进入临床验证之前整个系统坚不可摧。 — Pramod Rudrapatna > `12:21` 由于一个人在遭遇真正的紧急状况时可能呈现出多样的体征与反应,因此无论当事人处于病程发展的哪一个阶段,整个系统的设计都必须经过极其审慎的推敲。 — Jake Sunshine ## Mentioned Pixel Watch, Pixel Watch 4, Pixel Watch 5, Google Health, Fitbit, 华盛顿大学, Jake Sunshine, Pramod Rudrapatna, Rachid Finge, Made by Google Podcast, EMS, 911 ## Video description <p>How can a smartwatch on your wrist do more than just track steps and actually help in a life-threatening situation? </p><br><p>Host Rachid Finge sits down with Google Health research scientist Jake Sunshine and product manager Pramod Rudrapatna to go deep on Breathing Emergency Detection, a breakthrough feature for the Google Pixel Watch. </p><br><p>They uncover the incredible story of its creation, from the initial "what if" moment to the immense challenges of clinical testing and the user-centered design that ensures it can summon help when someone is unable to themselves. It’s a look at how everyday devices are being reimagined to act as true health guardians, potentially saving lives when every second counts.</p><hr><p style='color:grey; font-size:0.75em;'> Hosted on Acast. See <a style='color:grey;' target='_blank' rel='noopener noreferrer' href='https://acast.com/privacy'>acast.com/privacy</a> for more information.</p> [Source](https://sphinx.acast.com/p/open/s/63e39eb02e631f0011a284ac/e/6aaf867851da7059ecd7c88b/media.mp3)

Source quotes

[20:00] Pramod Rudrapatna: 你绝对不希望陷入一种为了追求零误报、结果导致整个功能毫无用处的境地;这里面需要把握一种非常微妙的平衡。 [17:41] Pramod Rudrapatna: 我们必须穷尽一切手段运行各种边缘场景,确保在正式进入临床验证之前整个系统坚不可摧。 [12:21] Jake Sunshine: 由于一个人在遭遇真正的紧急状况时可能呈现出多样的体征与反应,因此无论当事人处于病程发展的哪一个阶段,整个系统的设计都必须经过极其审慎的推敲。

Source quotes

[21:44] Jake Sunshine: I think the really hard piece is can you build something that is deployable at sort of society level scale, meaning can you have false positives low enough? [25:52] Pramod Rudrapatna: We would love if others, you know, join the bandwagon and build, because the more people who build these potential life-saving features, it's going to be a bigger contribution towards public health.

Original transcript

[0:00] How about we detect something where the user is not in the position to get help themselves, right? So these are like truly moments where these wearables can offer peace of mind and truly act as a health guardian. Welcome to the Made by Google podcast, where we meet the people who work on the Google products you love. Here's your host, Rashid Finj. Another breakthrough feature for Pixel Watch. it gains breathing emergency detection. Here to tell us all about it are Pramad Rudrapatna and Jake Sunshine. This is the Made by Google podcast. Jake, Pramod, welcome to the Made by Google podcast. You both work at the intersection of consumer tech and health. What are your roles exactly at Google and how did you end up here? Can we start with you, Jake? Yeah, so I'm a physician by training. I'm also on faculty at the University of Washington. I have spent my career thinking about how mass market devices like phones, speakers, and wearable devices could be useful for health sensing applications. I had a spin-out company that was acquired by Google in 2022 based on my research and collaborators at the University of Washington the frontiers of what sensing can do for various health applications. Amazing. And we'll get to that research a little bit later. Pramad, what's your story? What do you do at Google and how did you end up here? I'm a product manager within the Google Health Arc, advancing some of our state of the art sensing on our devices. I joined Google about five years back. I came to Google as a part of the Fitbit acquisition. So I was part of the Fitbit before this, but working on health was for me But I was always passionate and always worked at the intersection of hardware, software, and AI. And I started working on health about five years back, as I truly believe that this is an area where we can truly make an impact. Pixel Watch 4 and 5 now have breathing emergency detection. In a sentence, how would you describe what it does? Breathing emergency detection can place a call to emergency medical services when your oxygen saturation drops to dangerously low levels persistently. I think one of the reasons why this is really important is this can happen due to various reasons, including accidental drug overdose, severe pneumonia and choking. And many of these events are unwitnessed. That is, there's no one around. And though there are interventions available, practically there's no one. to call in for those interventions. It happens in unwitness situations. I think Brady image in detection transforms that from converting these emergencies from unwitnessed to witnessed and prompting a call to emergency medical services so that people can get the potentially life-saving intervention from these public assets which are already put in place. This is an opt-in feature available on Pixel Watch 4 and 5 in select European countries. Now, I guess when most people think about smartwatches, they think maybe about tracking steps when it comes to health, maybe tracking sleep. But they don't think about loss of pulse detection, something we talked about last year, Jake. And now, of course, breathing emergency. So how did work on these kinds of advanced health features start, Pramod? Yeah, I think the trackers on wearables have been in the market for over a decade now, and people have used it. in meaningful ways of course, but the utility of these devices that sit on your wrist is beyond what steps and sleep tracking is about. So I think that's something that we've been thinking very hard on in terms of, What are some of the unmet needs are problems that we could solve that has a public health impact. So when we think about that angle, that's when we start the journey to think about, okay, people are already wearing their watches to track their steps, they track their sleep, track their heart rate, what if we could Think about detecting things that the users might not know because it doesn't generally come and open symptoms. People might not know unless until they have their annual physical with their doctors. R. How about we detect something where the user is not in the position to get help themselves, right? So these are like truly moments where these variables can offer peace of mind and truly act as a health guardian. loss of pulse, [5:00] It's a pretty big public health challenge and that can happen due to various reasons including cardiac arrest and other respiratory failures. But majority of them are unwitnessed. So we felt there's a sweet spot where you have a variable, which can detect these unwitnessed events and have an opportunity to place a call on behalf of the user to get the help that they need and also potentially life-saving care. So I think that's the journey where we thought about where we can really leap what these consumer devices can do. And that's how we've evolved this from loss of pulse detection. announced a few weeks back. Now, Jake, Pramod makes it sound easy, right? We have wearables. Let's just add these features. But of course, it's not that simple. You already mentioned this is the kind of work that, you know, you've spent a lot of time on thinking about. Do you remember the first time you thought it would be possible to build something like loss of pulse detection in a watch or a breathing emergency detection on a smartwatch? Yeah, it's a great question. I mean, I go back to spending lots of time in a hospital environment where we use equipment all of the time to keep people, you know, safe in the operating room, in the intensive care unit, on the floors of hospital. And it's actually quite... Funny, if you compare the sort of the technical specifications of medical equipment that's sort of in the hospital, and then you put it next to like a modern smartphone or smart speaker or watch, there is a huge difference in computational capabilities in these devices that we have all around us and that we carry in our pockets compared to this like traditional equipment that's in like a modern hospital. So that's like a really big disconnect. And I think once you start Thinking about that, you realize that there's a lot you can do with these everyday devices that we sort of take for granted. And so if you have that mindset, it sort of changes how you look at potential problems that might traditionally seem like more relevant for a clinical environment for what you can do outside of a hospital. And I think what Pramod mentioned, loss of pulse, breathing emergency detection, these are great examples of true emergencies that can happen outside of a hospital, There's known interventions that can help people. The real challenge was making people aware that someone wasn't experiencing an emergency in the first place. And that's where these devices come in. And through a lot of thoughtful and incremental research, we have successfully de-risked what these devices can do, first with loss of pulse and most recently with breathing emergency, to build a case or process. generate the data that's necessary that makes it clear that it's safe and we can use these devices effectively to potentially identify these emergencies and unwitnessed scenarios. Now, Jake, I guess most listeners can imagine sort of how loss of pulse works because the watch detects your pulse rate and when it's not there, then maybe there's a problem. That's, of course, the layman explanation, right? But it seems maybe a little bit more complicated when it comes to a breathing emergency. Could you walk us through how Pixel Watch detects a breathing emergency? Yeah, well, these watches, they have sensors that are embedded within them that are, again, also embedded within sort of hospital grade equipment. Traditionally, they've been used for measuring heart rates for workouts and things like that. When someone experiences a breathing emergency, their oxygen levels can drop precipitously to levels that are sort of in the unhealthy range. And this can happen for a variety of reasons. And so what we've done is trained machine learning models to identify these transitions from when someone was in sort of a more healthful state and had a normal oxygen level in their blood to when it has dropped really, really low. watch, centers that measure motion, where someone might be still, they might be unresponsive, and we bring all of that together to identify someone who we think was in sort of a healthy state a moment ago, and now they're showing signals that they're not in a healthy state. And because the watches are connected, they're able to summon help both through 911 or emergency services, but also have the ability to contact close contacts who can help in an emergency when someone might be unable to help themselves. Now, Pramod, I guess you're sort of in charge of making that user experience, right? Could you tell us, like, What if, God forbid, a breathing emergency occurs right now? Maybe I have my Pixel Watch on. What would I notice when that happens and what happens in Cascade after? [10:00] Yeah, I think these kinds of features is something that We have put in a lot of thought into developing this responsibly because we don't want to overburden the user with these notifications. At the same time, overburden the public health code and pharma emergency medical services. So we brought together the state of the art machine learning that Jake just alluded to. But we've combined that with user-centered design. So what we do is when the algorithm thinks the user has a breathing emergency, We just don't blindly call emergency medical services. What we do is we go to the state where we check in with the user to see that, hey, we've observed a drop in your oxygen levels. - Are you okay? So we kind of like check in, give the user an option or opportunity to react. If they move around or they have an opportunity to dismiss it, If they think it's not an emergency, But if the user is not responsive, It escalates to the next level where there's a countdown. There's a loud noise that comes out because there could be people around them. They could come and check in on them. Or if the user is not in the state where they could react to the check-in which has just haptics. This haptics as well as alarms in the countdown stage kind of like prompts them to respond to it. So if the user doesn't respond to even that, That's when an escalation call is sent to the emergency medical services and optionally an emergency contact is also notified. You mentioned Pixel Watch can call emergency services, it can notify family or friends, your emergency contacts. I'm just wondering if you're like a first responder, what's that experience like? Do you hear a pre-recorded message or what happens? Yeah, so when the call goes through, we tell the emergency medical services that, you know, we've seen someone with impaired oxygenation. Here is their location and also a transcription would be sent to them. And while we send that, the phone line will be open for the responder to talk to the person on whose watch we have placed a call. So they can understand more and also see if it's actually not necessarily an emergency or if it is an emergency, learn a little bit more on what's happening. so that they have more information and they can make better decisions in terms of deploying their most prized assets. So they know what's happening, they know where is it happening, they also have an opportunity to engage with the person before they deploy a response. Exactly. Got it. Jake, last year, of course, we spoke about loss of pulse detection, and I encourage everyone to listen to that episode if you're interested in that as well. So now we're talking about breathing emergencies. I'm wondering how, from the perspective of the watch, are these two the same and different? That's a great question. Both of these systems are designed to detect time-sensitive emergencies. You might be able to make an argument that a loss of pulse is significant. more time sensitive because someone's heart has stopped, they need immediate attention in order to survive an event like that. We think of CPR, we think of defibrillation. time-sensitive intervention, it needs to happen right away. Breathing emergencies are also very, very time-sensitive, but perhaps slightly less time-sensitive. I think the thread connecting both of these are we know what these events can look like clinically, And then we also know what... the intervention is. There's evidence behind sort of both of those, what they look like, and how to treat them. And so what we're trying to do is sort of bring those things together more efficiently. And that's what a wearable device can do, particularly when someone is in an unwitnessed circumstance. Something I learned about these two features, actually, as you mentioned, your loss of pulse detection, very unlikely, if not impossible, to respond to your watch. But that's not necessarily the case for a breathing emergency. Is that right? Yeah, and that's in part what makes this a lot more complex because people might be in the initial stages of a breathing emergency and still might be responsive. And we still need to make sure that people have information for why an alert might have happened and make it as easy as possible if they're still sort of, you know, in control to make sound decisions about what they should do next. alerts look like, making sure that if someone is conscious, we give them information about what might be causing this and basically make the barrier as low as possible for them to call 911 if they want to. And then it's been designed for if someone, say, maybe progresses through the emergency and maybe they lose consciousness, that it will re- [15:00] alert and still has the capability to make a call on someone's behalf if they lose the ability to respond themselves. So because they're sort of diversity of presentation that can happen when someone's experiencing a true emergency. It had to be extremely thoughtfully designed no matter where the person might be as that situation is evolving. Let's talk about testing. You know, when we talk about testing on this podcast, it's very often that we're testing a new feature, you know, a new app or something new on a Pixel device. That's something that maybe other Googlers are testing. I presume no Googlers were hurt in testing a breathing emergency. But then the question, of course, is, Jake, how do you clinically test and validate that Pixel Watch indeed can detect such an emergency? where under informed consent and under medical supervision, people can transiently have their oxygen levels dropped. And so we're able to do that in a safe environment to measure what it looks like when that can occur, and then quickly their oxygen levels are brought back up. In sort of a real emergency, the expectation is it will go down and it will likely remain down in sort of truly emergent events. sensitivity of the device, how often it can identify that signature that we've developed the system for. And then separately, as Pramod alluded to, it's really hard to build these systems that are connected to these public resources that we all rely on. And so we take a lot of responsibility in designing something like that, like responsibly. And so in order to do that, you have to do testing in environments where you think it's really unlikely that someone's but you can get more people and you can basically see, as people are living their lives wearing the watch to see how often false positives might occur. And you might be surprised, but there are false positive situations that can occur where people might have their oxygen dropped, But it's not an emergency. Common example of that is someone who might have sleep apnea. really common disease and people might not know they have it. We know that that's the case. And so sometimes people can be still, Their oxygen levels can drop. But in that situation, it almost always comes back up. That's not an emergency. And so a lot of thought went into designing that threshold for when we're going to make an alert to make sure that for cases like that, where someone isn't really experiencing something that's very healthy from that event, but might not be an emergency, to make sure that we have things balanced to identify true emergencies and not bother people who might have sleep apnea that's maybe not diagnosed yet. So, and maybe this is a question for Pramod. I guess in other situations where you're a product manager, if there is a bug, you just send out a new version and the tester will test it. But I'm going to presume you're not going to have these people at the ready whenever you want them to undergo under supervision, like a simulated breathing emergency. So, It sounds like there is a lot weighing on getting it right as soon as possible. Did that always work that way? So before you go into validation, what we did was we did a very robust end-to-end testing, ran it against our dog food population, ran it against the previously collected data sets which we had not trained on. We cannot be 100% sure always, but we want to go in there with high degree of certainty that we will pass. had to take utmost care in running various scenarios to make sure everything was Yeah. bulletproof as it can get before we enter the clinical validation. So, when we went to this clinical validation, we had the end-to-end product working. So it was the full blown product that we used. validation to be sure that this works for the criteria that we have defined in a real-world environment. On top of that, what we do is we also run it in our dog food population just to make sure that there's nothing over the ordinary as a sanity check. But majority of our validation is something that we do. as part of our design control or that is submitted to regulatory bodies. And just to clarify, Pramod, for people listening, the dog food population, those are people working at Google who are happy to test a new feature. And it sounds like in this case, you make them... Try the feature and just hopefully there is no false positive. That's, I guess, what you're looking for with them. Yeah, I mean also, I mean false positives are not necessarily zero. Our goal here is to build a valuable product minimizing false positives to the great extent. [20:00] because you don't want to be in a situation where there is no false positive. But and now the feature is useless, right? So there is a very delicate balance that you need to strike. So we look to make sure that Based on the criteria that we have defined, we observe something similar across different cohorts, right? So because we did clinical validation with different cohorts, and here is our internal cohorts. So we want to kind of bring all the information together to be certain that or have high confidence that when we roll it into the wild, when we have real people using, it behaves as intended. testing it on actual people, right? But there's probably also some testing going on with the first responders. I guess they need to know in advance that something like this could happen, that they get an automated call from a watch. How do you speak with first responders in many countries telling them about this. Yeah, that's a great, great point. We, again, take this responsibility extremely seriously when we're building things that connect into these public resources, these 911 systems. And so we take a lot of care to communicate. things that are being built before they are released to the public and they might receive messages for them. So we send out FAQs through trade organizations because, as you said, there are a lot of these different 911 response centers. We reach out to them beforehand. We provide them FAQs. We provide them opportunities to ask us questions, sometimes through webinars. And so we try to be very diligent about that to avoid this possibility of any sort of surprises for calls that might come through. You know, Jake, I'm so curious to ask, when you started working on this feature, Was it for you as a researcher immediately clear that this could be done, or were you also like figuring it out along the way? You know, I think that we... thought that this could be done. I think the really hard piece... is Can you build something that is deployable at sort of society level scale, meaning can you have false positives low enough? given the fact that there are always false positives, can you have that low enough to make this feature useful? And sort of the moment where we thought, okay, yeah, we're likely in the game, is when we saw that it was quite performant within the hypoxia lab, where we tested sort of the sensitivity or sort of true positive situations, and then we started seeing what this could look like once we got into larger populations level comparatively to say other features. So, and this is a question for the both of you, but I'll start with you, Jake. Once you sort of notice that, so it works in the lab and basically works outside of the lab, you know, in normal situations. What does that feel like when you sort of you know, made that accomplishment? Where does that sit in the many things you've done in your careers? I mean, it feels incredible. You know, you're just talking to Pramod and I, but there's so many people behind the scenes doing incredible work to like bring these things to life. I mean, it's so energizing working with people who are like on a mission to build something like this. You know, breathing emergencies are one of the biggest public health challenges for certain types of causes. You know, overdose is a very, very common one. It's just a massive and staggering public health challenge. system like this was to potentially help people be identified that they might need help. And so working on something like that at sort of Google scale is really like a tremendous privilege. And it feels amazing to get this out there. And sometimes, you know, you forget about it until you until it's public, you know, that we're working silently on this for years. It's public like what you know, you're totally have internalized it. And then hearing the feedback that you get from, you know, experts in the field, it's really gratifying. It's hard to describe how great of a feeling it is. Is there a particular piece of feedback that stands out in your memory? I think the most gratifying feedback we've had is firstly from domain experts who might have devoted their careers to some of these public health challenges that Breathing Emergency is looking to help mitigate. Hearing from them that they think this is a huge breakthrough, it's going to have the potential to save a lot of lives. who have been tragically affected by breathing emergencies that [25:00] have not been resuscitated and led to people dying. And so hearing directly from people who might have had a family member impacted by such a tragedy and, you know, being thankful for us taking the time to build something to help prevent that tragedy for someone else has really been immensely gratifying. You know, Jake, I imagine there might be something addictive. about building features that could save lives. Is there something in that? I mean, I tell people I feel like I, you know, have the best job in the world because we get to spend time building systems to try to solve some of these problems. And, you know, it really is amazing. There's probably a few places that can devote the types of resources that are necessary to do that. important challenges and devoting resources to it. It's just immensely gratifying. Yeah, so I guess that's what I would say. What's in the future? Like not literally what's in the future, but like how much room is there still for for features like this, you think? I think what we're trying to do is sort of shift the Overton window on what these devices do. Like you mentioned earlier, they've traditionally been thought of as these devices to manage your fitness, get your text messages, things like that. And so we're really trying to rethink things. how they might be able to actually save somebody's life, and by tackling clinically important challenges where we think they could play a unique role that just like nothing else really could. And so I think, you know, these two features contribute a lot of morbidity and mortality in society. And we think that as these things scale, we hope to sort of lessen the burden though, right? It's going to take time to grow. And we hope that, you know, Others may follow in trying to build similar things because that's what's needed from sort of a public health standpoint. But yeah, no, it's a real privilege to build systems like this, and we look forward to building more. Yeah, we would love if others, you know, join the bandwagon and build, because the more people who build these potential life-saving features, it's going to be a bigger contribution towards public health. We would encourage others to build as well. What is the goal of adding features like loss of pulse detection and breathing emergency detection? Yeah, I think it goes back to our mission, right? So our mission is to empower people to live longer and healthier lives. So as a part of that mission, We have an umbrella concept of health guardian which offers peace of mind to our users, which can help them know about something that they don't know about their health. So they can go consult the doctor or make interventions. But there are also scenarios where life brings unexpected. like a loss of pulse detection or breathing emergency detection. So we want to be there for the users and scenarios where they cannot get help for themselves. So I think our goal here is to support users throughout their journey, whether they want to track their fitness and their wellness or want to know about their health that they might not know otherwise, or also be with them offering peace of mind. And when life brings unexpected and they cannot get help for themselves. So that's how this all comes together in alignment with our mission. Amazing. Jake, Pramod, first of all, thank you so much for building these features. They make such a difference. And thank you, of course, for joining the Made by Google podcast. And please come back when you have something new to share with us. Thanks so much. Yeah, it's been a pleasure. Thank you so much, Rashid, for taking the time and trying to understand what we have built and sharing this information to the rest of our community. you