Everyone who knows my writing can attest that I neither pull punches nor play politics. It may distress people, and hopefully it won’t harbinger my demise. But as CEO of a young firm bringing overdue innovations to the Fire and Emergency Medical Services industry, there are only four groups to whom I am duty-bound: our partner-clients, their patients, our team members, and our investors (in no specific order). To remain mum on topics that could affect the physical or financial health and wellbeing of any of these parties would be a disservice.
When I was in the magazine business, I often used the phrase “Respect the medium.” The meaning was simple: when every industry player surfing the waves of innovation is trying something new, how many are asking whether the form is appropriate to the intended function? What changes need to be made to magazine’s font so its text can be read clearly on a small, backlit screen? What interactivity can be embedded into a digitally delivered? How will the user’s experience change when network access is down? (In February 2012, I wrote about these topics for Electronic Design Magazine.)
Failure to ask these questions is often the downfall of the delivery method: either the medium changes or its use declines; rarely do customers acclimate. In the publishing world, if your readers ignore you, you go away—no lasting harm or foul. Not so in healthcare or public safety. Especially during emergencies, if a product fails to work as intended—or to work at all—it can mean lost productivity, mountainous legal fees, brain death, or loss of life, limb and property.
Healthcare IT offers outsized benefits to Emergency Response teams, which depend on speed, ease of training and use, data accuracy, and interoperability. But the stakes of failure or disruption are so high that one can say there are few areas of development with a more desperate need for criticism.
And criticism there has been! Few complaints garner broader consensus among Fire and EMS practitioners than that leading manufacturers of electronic patient care records (“ePCR”) have abysmally neglected UX and design considerations. Agencies—and their patients—pay the price through decreased productivity and even lost records. As Tom Bouthillet, a fire captain, paramedic, and widely published Fire-EMS technology expert wrote in an instructional op-ed:
“If you’re like most paramedics, especially those who were around before electronic patient care reporting, you’re not a big fan of ePCR. With all the emphasis on compliance, data collection, and billing, it seems like ePCR serves everyone except the one person it should be serving — the patient. A dozen things can go wrong when filling out ePCR…Of course, any problem requiring technical support will happen at 0300 on Sunday morning.”
Fire-EMS agencies and their patients face the risk that medics in the field—relying on their software systems and expecting them to perform the critical job of collecting, storing, and transmitting patient data—will be distracted by or unprepared for system failure:
- Firefighters and medics may lose key clinical and incident details due to a lack of network connection and be forced to restart their reports. Data may also be lost if the iPad breaks;
- Firefighters and medics may be distracted because they expect data to integrate into their ePCR (e.g., ECG waveforms), but when they attempt to import such, they cannot do so;
- Firefighters and medics may be unable to convey critical details captured in the field to the hospital ahead of EMS arrival, a Best Practice that may become a CA state requirement.
Simply put: attempts by Fire and EMS agencies to use iPad-based ePCR “solutions” in the field is dangerous, given the current limitations of the device and its operating system. iPad is excellent for consumer and business device (I have one at home), and let me be clear: it is possible to build applications that capitalize on what iPad does excellently (e.g., a protocol review device or a training tool for use in the classroom) —but only by being honest about its capabilities. Despite iPad’s popularity in the consumer and business worlds, we must account for its deficiencies, too: it is fragile and has network dependencies that are problematic when Emergency Responders have to do their sacred work in austere environments or during disasters when cell networks have gone dark. It was not designed to create ePCRs in the field.
Don’t take my word for it. Consider Steve Job’s own words about the artful tablet he created. “If I have a beef with the iPad,” Jobs said, “it’s that while it’s a lovely device for consuming content, it doesn’t do much to facilitate its creation.”
Or consider the assessment of the El Dorado County Emergency Services Authority, which itself today uses an iPad-based ePCR—despite material risks to this community based in the mountains of California’s Sierra Nevada Mountains. In its own written policies, the county’s Joint Powers Authority (JPA), which incorporates several fire protection districts, states: “…the EPCR system consists of several component parts that include the [software application currently being used by the county] which is installed on to the [company’s server] and uses a Verizon Wireless cellular service for connectivity to the internet and the server…A problem with any one of these component parts will impact system operations.” The county requires a “hard copy paper system…in the event of system failure.”
Despite the El Dorado County JPA’s reliance on cellular service, Verizon Wireless’s own service maps show several “no coverage” area within the county, notably in and around the towns of Placerville and Pollock Pines. Why start out using an ePCR that has been noted to have the potential for system failure? Why not opt for a more robust system, in the interest of safety, when several such systems are commercially available?
In July 2013, a similar operational risk was acknowledged by the New York City Fire Department when it found itself hamstrung by poor network connectivity while attempting to respond to a medical call from Speaker Christine Quinn’s office.
Even beyond the risks posed by network-reliant software for use during emergencies, no ePCR system exists for iOS that is both compliant with the National EMS Information System (NEMSIS) and can directly integrate an electrocardiogram (ECG) signal in the absence of an Internet connection. The major ECG monitor-defibrillators serving the Fire and EMS market (i.e., Zoll, Physio-Control, and Philips) don’t allow a direct integration of ECG signals to an iOS device. Technical and product literature by all three manufacturers says that a Windows operating system is required. For non-Windows ePCRs, a web-based application may be used instead. But a web-based ECG import linkage ties the ePCR to the Internet and raises the risk of system failure during a natural disaster or, as mentioned above, when responding inside a cellular “dead zone.” Zoll has released a basic patient care record form for use on iPad, but this thin application does not directly import ECGs even from Zoll’s own monitor-defibrillators, and it is not NEMSIS compliant.
Some advisor have cautioned that I may be persona non grata in certain California counties and beyond after highlighting the deficiencies associated with iPad-based software for Fire and EMS. I hope that’s not the case: after all, we’re all on the same side, working to make Fire and EMS safer and more efficient for providers and patients alike. One experienced EMS sales executive, who now works for a county, told me that “all providers are cautious of vendors who try and sell vaporware,” but he also noted that Fire and EMS is a tight-knit brotherhood, where the phalanx is an instinct and no technology innovator wants to be “boxed out.”
Still, how can I stand idly by while unscrupulous companies peddle false technical and business promises that gamble with lives and livelihoods? Ethics and a mission to serve together compel me to blow the whistle on underhanded business practices that can (and do) leave agencies and their patients vulnerable. Unfortunately we are seeing more and more agencies having to retrench and start their search for documentation solutions from scratch when their chosen vendor fails.
Occasionally I have raised these concerns and been challenged in reply: “But you’re talking about documentation—if it gets lost, it isn’t the end of the world. No one is going to die.” Sadly, that’s not necessarily true: the risk of medical errors in emergency environments is terrifyingly high. If the public knew about the battery of studies we often cite, which show data loss at hospital handoff averaging around 46% (and anecdotes from places like the University of Pittsburgh Medical Center pegging this number as high as 80%), there would be a scramble to invest in technologies that close the data gap.
There would also be a push by regulators to develop a Prehospital Health Information Exchange. After all, the loss of essential data from EMS—from clinical and incident details to intervention information—means that patients have to be re-assessed upon ambulance arrival. This delays treatment and adds profoundly large avoidable expenses to the hospital handoff process.
Fire and EMS professionals love the idea of iPad-based ePCRs because the device is sexy and in vogue. But consumer, business, and Emergency Responder-grade equipment are fundamentally different, and each medium must be respected lest it fail in the field. iPad may be easy to use and replace if broken, but it wasn’t designed for use in disaster management or emergency response.
Those of us who speak the industry’s parlance and have deep technical knowledge are duty-bound to counteract hyperbole, misinformation—even fraud—despite the fact that, as a colleagues at another ePCR firm recently said, no one wants to tell a chief that he or she is wrong. I don’t know that I agree with that sentiment: I have met many Fire and EMS chiefs, and can say unequivocally that their commitment to their teams and communities is sterling. These leaders would likely want to know if a decision (e.g., using an iPad-based ePCR), made without full knowledge of its ramifications, could lead to injuries, inefficiencies, or legal exposure.
Jonathon S. Feit, MBA, MA, is Co-Founder & Chief Executive of Beyond Lucid Technologies, Inc (www.beyondlucid.com). Prior to BLT, Jonathon served in the White House Office of Management and Budget, where he helped spearhead the relaunch of USAJOBS, the federal government’s hiring portal.
DISCLOSURE: The author owns stock in Apple, Inc. (AAPL).