The Emergency Medical Services and Fire industry is complex. Reporters covering Health and Health IT— including iBeat, the most recent darling — must carefully vet companies’ “Big Claims.”
I do not often comment on articles written about other companies — particularly because, having been a journalist for the first half of my career, I empathize with the challenge of writing quickly about hot topics, especially when they are complex, technical, and the interview subject is a something of a celebrity. But journalists are in hindsight eulogizing the many signs that were missed with respect to Theranos, so this article is intended to highlight claims being made by and about iBeat that fail to stand to technical scrutiny in light of the way Fire and Emergency Medical Services operate in the U.S.
It must be stated upfront that I hold no stake in iBeat, its technologies, or any competitive technology or company. Quite to the contrary: If iBeat’s claims were accurate, its technology would be wonderfully informative for the Fire and EMS agencies that I serve, and their patients nationwide. Alas…
Healthcare is different from other startup disciplines (or it should be). The pressure to be correct should be highest if one is to buy a certain product, and then rely on information provided by it, to “save your life in an emergency.”
Since May 2018, MobiHealthNews, Vator, Business Insider and other media outlets have published articles about iBeat, whose own website calls it “The Heart Monitor Smartwatch That Can Save Your Life.”
Indeed, Bloomberg TV asked Mr. Howard whether it was concerned about making such a claim without FDA approval as support, but apparently Bay Area startups waiting for major regulatory clearance isn’t a thing anymore (again?).
At 18:48 into the video linked below, Emily Chang says “You say it’s a watch that can save your life. You don’t have FDA approval yet.” Mr. Howard says, “We actually are going through FDA approval right now….we feel we can serve the users now, help them, while going through FDA in tandem.” See: https://www.bloomberg.com/news/videos/2018-07-11/-bloomberg-technology-full-show-7-11-2018-video
Fast-forward to 18:48 of this Bloomberg TV segment for Emily Chang’s challenge to iBeat CEO Ryan Howard regarding his company’s lack of FDA approval, despite claims that the watch it makes can “save your life.”
One of the key alleged benefits of iBeat was described as follows by Business Insider, and similarly by MobiHealthNews: “It does, however, have a corresponding smartphone app, where you can add your medical history, medical conditions, and known allergies, which will automatically be provided to paramedics in the case of an emergency.” (Emphasis added.) Given the current state of dispatch technology in the U.S., it is essentially impossible for this claim to be substantiated.
We can leave aside the claims Mr. Howard makes about 9–12 minute times for EMS/Fire to arrive on-scene, which he also cites as a basis for his product’s need. Those numbers fail to match figures for the San Francisco area, where iBeat is headquartered, or national figures. However, it might be possible to cherry-pick a location in the U.S. where those response times are accurate (e.g., a rural station). The San Francisco Chronicle found “that Fire Department ambulances reached emergency scenes within 10 minutes 87 percent of the time in June, short of the state standard of 90 percent.” According to the Medical News Bulletin (2017), “The average time for the arrival of EMS personnel to an emergency scene is seven minutes.”
iBeat is conflating and confusing expectations about how data are collected and shared in prehospital environments, which can put people who use its watch at risk. It also confuses the investor marketplace, which — lacking detailed expertise with respect to the American prehospital (i.e., Fire & EMS) ecosystem—wrongly believes that all prehospital technologies sit on a continuum, some version of iBeat or RapidSOS or another company making big claims. All of their claims sound awesome, but here’s a difference: in the case of RapidSOS, the fact that they have been overblown will be Uber’s and Apple’s problem to manage. In the case of iBeat, however, the claims are just wrong —and made worse by the fact that iBeat is being marketed to the elderly.
If all that Mr. Howard were claiming is that iBeat relays a call to 9–1–1, there would be no issue (he contrasts his technology to LifeAlert, and could make a similar analogy to OnStar). But each of the following outlets attributed to him nearly identical quotes, none of which stands to scrutiny:
According to Vator: Mr. Howard said that “During [an emergency] event, from a biological and physiological perspective, if the user stops breathing, has pulselessness, is no longer pumping blood into their capillaries, our sensors detect all those components and then the device has an LT radio on it, so it turns that radio on, it has GPS on it, it turns that on, and it reaches out to our dispatch, who reaches out to paramedics with your location, reaches out to the emergency contacts previously set up.” (Emphasis added.)
According to Business Insider: “The iBeat watch has GPS and a cellular connection built in, and it doesn’t rely on your smartphone by way of Bluetooth. It does, however, have a corresponding smartphone app, where you can add your medical history, medical conditions, and known allergies, which will automatically be provided to paramedics in the case of an emergency.” (Emphasis added.)
According to MobiHealthNews: “[The watch] is going to be fully autonomous. It is going to reach out to our cloud platform our 24–7 multilingual dispatch that is going to coordinate with 911. [The intermediary dispatchers] have a direct connection to the 911 system, and what we are doing is giving them data about you. Your location, when you set the device up originally we gathered your medical conditions allergies, medications, and all of that data, so we gave it to paramedics while they are en route to your location.” (Emphasis added.)
I contacted MobiHealthNews and advised them to correct their article, after which they inserted the parenthetical edit above, and elaborated:
“In an email to MobiHealthNews iBeath [sic] further explained that in this situation where a person is having an emergency but unable to call on their own, the watch will connect them to a dispatch center. The dispatcher will then call the victim’s local 911 PSAPs and relay this information to the 911 operator, according to the company. However, getting complicated clinical data from the 911 operator to the EMS responding can be difficult because 911 dispatch centers send the coded information, and typically don’t have the capabilities to send specific patient data.” (Emphasis added.)
The first cause for pause: To reduce response time in cardiac arrest, iBeat says it will add a step into the dispatch process, relaying data to a secondary dispatch point (i.e., a call center), which will then send medical and location information to 9–1–1 dispatchers…rather than calling 9–1–1 directly, like a phone does. The dispatchers on the second step will then send information about the incident to paramedics. How does adding a secondary relay into the dispatch process make things faster? On its face, adding a step will slow things down. It also introduces a risk of human or machine error during the first call, or during the communication to the second step (i.e., the Public Safety Answering Point, or PSAP, explained below).
The second (and arguably bigger) concern is where the proposed workflow diverges from the prehospital reality: Mr. Howard’s quotes suggest that information about a patient’s health context (e.g., allergies) will be sent directly to “paramedics.” This is simply nonsensical. Calls to 9–1–1 in the U.S. are generally not routed directly to a Fire or EMS agency, for various reasons including the risk of false activations. Instead, they are routed via a Public Safety Answering Point (PSAP, popularly called “9–1–1 dispatch,” though dispatch and PSAPs are in fact not always combined). As noted in iBeat’s email to MobiHealthNews, the PSAP itself has no organized way to convey details like medications and allergies to Responders.
This link offers an idea of the sorts of data that are collected by PSAPs and then conveyed to Fire and EMS agencies. Notice that they are NOT personal to the patient. EMS dispatch systems function a bit differently (some of the codes are distinct) but for all intents-and-purposes the differences are around the edges. In many places, the same Computer-Aided Dispatch (CAD) system is used for fire and EMS, sometimes even police. Furthermore, CAD calls are broadcast, so for privacy reasons (e.g., HIPAA), clinically unique medical details are not usually conveyed via public, insecure channels. How are paramedics — assuming it is even paramedics who are being dispatched to the scene , as opposed to Responders with other certification levels— supposed to aggregate data provided to dispatch regarding allergies, medications, etc.?
The answer would be for the data to land in the electronic patient care record (ePCR). [DISCLOSURE: ePCR is the area in which my company operates.]
However, the feed received by ePCRs from CAD does not include clinical details. It is convenient and sounds nice to suggest that providing data to the PSAP would send them on to the responding crews, but that’s not how these things work. RapidSOS has been being glorified in similar tones — according to GovTech, RapidSOS’s CEO said “ it could deliver health information for an unresponsive person being driven to a hospital.” How? The company says its technology operates between the incident and the PSAP call / dispatch, but to communicate healthcare information per se, its data would have to pass into the ePCR—yet its impact on data conveyed to Responders is a matter of providing more granular location data. How does one obtain “health information” for an unresponsive patient, when one cannot definitively confirm his or her identity (i.e., John or Jane Doe)?
Finally: Both RapidSOS and iBeat lack channels through which to deliver contextual, patient-specific “health information” to Responders in the field. Data that flow INTO the dispatch center / PSAP do not flow OUT in the same manner; the PSAP is not a tunnel or pipe, rather, it is a chokepoint or funnel, intentionally by design. Data flow out of a PSAP in highly structured, coded fashion that is practically universal and built for sharing with the ePCR, Fire Record Management System (RMS), police record system, or other receiving data system. Thus, that PSAPs are better informed by an influx of information DOES NOT mean that emergency responders can consume their insights.
PSAP operators do amazing work guiding patients through medical and other lifesaving procedures while they are on the phone — but the steps they take are not necessarily conveyed to the Responders in real-time. (Crews may learn about them later, e.g., on the nightly news.) The way to convey clinical data to the crews in a manner that is sufficiently detailed to be meaningful while en route to the scene is to place them directly in the electronic patient care record (ePCR) that is being used by the responding agency, or to transfer them via the CAD feed (which cannot happen, as noted above).
To use the ePCR channel, one would need to know who the Responder(s) is (are), and what ePCR system the agency is using, and then how to output data in a consumable and compliant format (i.e., NEMSIS, or the National EMS Information System for EMS; NFIRS, or the National Fire Incident Reporting System for Fire; or CJIS, the Criminal Justice Information Services for Law Enforcement). But again, CAD data transferred to a responding crew (if a CAD call exists at all, since not every jurisdiction uses one) DO NOT contain the clinical details being described in the news articles cited above. Failure to clarify what each technologies does and doesn’t do confuses the market.
Neither iBeat’s Mr. Howard nor RapidSOS CEO Michael Martin references an ePCR interface, and they do not provide a reason to believe that their respective companies have such interfaces in place. Their broad statements suggest a degree of interoperability that does not reflect the present state of the EMS and Fire industry (even though many in our industry wish things were better connected).
Grand claims made about Responders without substantiation destroy value for investors and customers alike by advancing theories that sound good on paper but are simple, and when they break down on the rocks of reality they also erode trust in the prehospital care ecosystem among members of the public who were unaware of the industry’s complexity. For example, they induce investors to conflate alerting apps (e.g., Twiage, TrackEMS) that provide a narrow but useful function, with full-fledged record management systems. Doing so is like confusing a motorcycle with a big-rig: both get you where you need to go, but they are designed for very different purposes and the motorcycle fits comfortably inside the big-rig. Dispatch gets confused with triage, which gets confused on-site care, which gets confused with on-route care. Public, private, hospital-affiliated, and fire-based EMS services smush together in folks’ minds despite very relevant differences (for example, private ambulance services can be pre-scheduled to visit one’s home, whereas public services cannot; in most cases, the latter must be dispatched by PSAP).
At risk of loss are many millions of investor dollars. Plus, when it comes to emergency services that directly touch patients, there are also human risks. Details matter in the EMS and Fire industry, which is robust, nuanced and highly regulated at federal, state and local levels. I don’t know much about watches, but as CEO of a firm that has been described as “Silicon Valley’s Emergency Medical Technology Experts,” I do know something about interoperability through “prehospital pipes.” Anyone seeking to sell into or leverage the U.S. Fire/EMS workflow should know how the parts connect — and how they don’t in today’s world.