Why Badly Designed iPad Apps Put Patients at Risk: EMS and ePCR

Why Badly Designed iPad Apps Put Patients at Risk: EMS and ePCR

7
SHARE

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).

Leave a Reply

7 Comments on "Why Badly Designed iPad Apps Put Patients at Risk: EMS and ePCR"


Member
csa819
Sep 16, 2015

This has nothing to do with the iPad. It has entirely to do with poor software aquisition practices employed by EMS agencies. And ANY sort of technology has the potentail to be dangerous if the providers are too stupid to stop playing with it and treat the patient. There’s an old saying in EMS, treat the patient, not the monitor, the same can apply to the epcr.

The iPad is a perfectly acceptable device for completing an epcr, IF the software is well designed, well implemented and in the right environment. There’s no reason the iPad epcr cannot store the data locally and transmit when connected.

The point made that cardiac monitors cannot interface directly with an iPad is probably a valid one, and that should be a major consideration when purchasing software. It’s not Apple’s fault the monitor vendors built their SDK’s on Windows, and thus require a conduit through different means to get data into the system. Android tablet software is probably in the same boat as well. If there is enough market demand, Physio, Zoll and Phillips will include a generic or iPad/Android specific connection through the SDK. Zoll and Physio both have epcr ecosystems, and if the demand is there, they will build it.

The real issue here that I think you may be really mad at, is that agency managers seem to be opting for cheaper (probably) less capable platforms without doing true due dilligence to discover all the wonder and valuable information that a well designed, well implemented system can provide. That’s the problem, combined with the fact that EMS agencies will do what EMS agencies have always done, often take the cheapest route possible, because they don’t care/can’t afford to/read an article in JEMS and we know what we’re looking for.

I recently read an article on the EMS world site where a VP of an on premise solution was bashing cloud EMS, it was pathetic. The platform is not relevant. Linux, Windows, iPad Surface tablet or a Blackberry. The point is to deliver software that does the job, meets the requirements and provides a frictionless user experience. This is like saying your TV sucks because you don’t get HBO with a set of rabbit ears. Or maybe that paper charts are dangerous because it might rain or they might spill coffee on it at the nurses station.

Guest
Joe
May 29, 2014

Steve Jobs didn’t say that about the iPad, the Time magazine writer wrote that.

Guest
Nick
May 26, 2014

Yet another article pushing the technology their own software company creates. Johnathan…why not try to be part of the solution and fully maximize and utilize the benefits iOS brings to the table? I fully understand that the interface is more difficult to code for but that’s not an excuse. Why single out iPads and the operational backbone they function on?

Guest
Oct 8, 2013

Glad to see this kind of detailed Health IT candor. We need more of it (the detail; not the angry troll anti-HIT bumper sticker screaming).

Admin
Oct 8, 2013

Jonathan:

Can you tell us a little more about certification and standards for the apps we’re talking about? Or rumored plans in that direction? It seems like this is an area the FDA would be likely to look closely

I’d also be very interested to know how the companies you’re singling out would respond to the accusations you’re making today here …