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).
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.
Steve Jobs didn’t say that about the iPad, the Time magazine writer wrote that.
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?
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).
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 …
Hi, John –
You ask several great questions here, and I’ll try to take them in turns (I apologize in advance for the length, but anyone who is interested in more detail can always reach me using the contacts below):
This is the easiest, so I’ll address it first. IN GENERAL, electronic patient care record (ePCR) applications — the acronym is unnecessarily confusing; it boils down to the EMS version of an electronic health record (EHR) – fall into the FDA category known as “Medical Device Data Systems,” or MDDS. According to the FDA, this identifier refers to applications that “transfer, store, convert formats, and display medical device data. An MDDS does not modify the data or modify the display of the data, and it does not by itself control the functions or parameters of any other medical device.” (SOURCE: http://bit.ly/FDA-MDDS)
Practically speaking, this means that ePCR companies must register with the FDA, pay a fee (tax?), and comply with adverse reporting requirements as appropriate. Because the documentation software is not controlling lifesaving devices or otherwise interacting with the patient directly in any manner that could cause physical harm, the real burden of adverse reporting is almost nil. (If anything, the extent of an “adverse event” would be loss of data or a report, but ePCRs are NOT used for diagnostic purposes.) In fact, some device manufacturers specifically bar ePCRs from interacting with their products in any manner that would trigger a change in the device’s FDA clearance levels (e.g., by manipulating data otherwise than has been approved).
FDA is therefore highly tangential to the ePCR business.
More interesting is how Meaningful Use requirements “touch” the ePCR business – they also do so only tangentially, but that’s been less-than-helpful. Indeed, the artificial split between ePCRs and EHRs is unfortunate (in my opinion), and the current iterations of ePCR technology seem oriented to remedy this “distinction without a difference”….the recent reorientation speaks to the Big Picture goal to enable end-to-end communications from EMS in the field, to the receiving hospital, to the physician (and across an ACO), all the way to the family.
I have long wishes that someone at the federal level would explain this Big Picture model to the public, because it is actually quite intelligent but roundly underreported. The Big Picture model may be worth its own blog entry!
[NOTE: The connected health model is also core to my firm’s business, as four counties in three states have said that our MEDIVIEW™ software could serve as a viable solution for a Prehospital Health Information Exchange, connecting ambulances with receiving hospitals within 30 seconds.]
(2) CERTIFICATIONS AND STANDARDS:
Here’s where things start to get interesting.
Sometimes – like every technology entrepreneur – investors ask the question, “Why can’t I just take a bunch of money, hire a bunch of engineers working oversees, and out-build you?”
In the EMS world, the answer to that question stems from the National EMS Information System (NEMSIS) – which might well be called “the industry’s built-in barrier to entry.” First, I’ll briefly address NEMSIS version 2, a data set comprising 250 or so points, which is in the process of being fazed out.
Software companies could certify on this data set at two different levels of compliance: NEMSIS GOLD or NEMSIS SILVER. Basically, Gold was “more compliant,” or compliant with more points that Silver. Many states — including New York and Pennsylvania, among others — required Gold certification; those that allowed Silver saw a preponderance of tiny, locally oriented ePCR companies. Not all of these can be considered “competitors” at every level, however. Many Silver compliant agencies only built to their local requirements, without any plans to expand nationally; they therefore could not be considered competitors to nationally oriented ePCR companies. There are around 12-15 national companies – but these companies differ from one another in substantial ways that stratify their position in the market (for example, one or two companies focus on Big Data, others focus on device integration, others focus on billing….Beyond Lucid Technologies focuses on disaster management, rural healthcare, and interoperability with care facilities.)
** A list of both Silver- and Gold-compliant companies can be found online at http://nemsis.org/v2/compliantSoftware/index.html **
The move toward a new generation of ePCR technology gained with the passage of the American Recovery and Reinvestment Act (“ARRA,” or “the Stimulus”), coincident with the birth of the Office of the National Coordinator of Health IT (“ONCHIT”), and the move toward Meaningful Use of EHRs.
In essence, the requirement that healthcare facilities use EHRs – coupled with the Emergency Medical Treatment & Labor Act (“EMTALA,” or as I like to call it, “the more powerful healthcare law you’ve never heard of”) – stirred interest in interoperability between prehospital health records and in-hospital health records. The preponderance of HL7 as the “backbone” of modern EHRs induced the development of a data set that would map prehospital and in-hospital data onto one another.
NEMSIS version 2 was insufficient for this task, for technical reasons, so NEMSIS 3 was born with an eye to bridging the divide between EMS and hospital, EMS billing, quality assurance, and clinical data collection purpose. As of this writing (10-8-2013), NEMSIS 3 is on the order of 580 data points in length – more than double the number of data points in version 2.
This conversion was so monumental that about half of the EMS documentation technology industry has gone out of business or been absorbed into larger, nationally focused, NEMSIS Gold-compliant firms. Whereas there are more than 40 NEMSIS Gold-compliant software systems, as of this writing there are only about 20 firms that are moving to NEMSIS 3.
Yet it appears that EVERY state will require a move to NEMSIS 3 in the next 12-18 months, so there will be a “land grab” effect, with success depending on the specific nature of each state’s operational requirements. (In September 2013, California announced its intention to have every EMS agency in the state using a NEMSIS 3-certified ePCR system by December 31, 2014.) (SOURCE: http://bit.ly/siren-magazine-NEMSIS3-and-HIEs)
(3) RESPONSE FROM OTHER COMPANIES:
I can only hope that other ePCR firms will engage with this article. I admire several of my competitors as upstanding, forward-thinking, and fierce-but-honorable. Healthy competition is a good thing, keeping prices in check and ensuring top-notch service. Ultimately the agency and the public win.
However, some recent actions have been very distressing, pointing away from transparency toward closed-door meetings, under-the-table dealings, and a subjugation of the public bidding process in favor of local vendors with inherent conflicts of interest (e.g., individuals who are on the payroll of the purchasing agency AND on the payroll of the company whose software is being purchased). In two vivid examples, two firms claimed to have state certifications when they did not; in one case, the agency was unable to bill for its services because the state rejected the output records as uncertified.
Some of the largest companies in the industry have shared our concerns about these actions, because they make everyone look bad AND put Emergency Responders and their patients at risk. We believe that technology choices should be based on the merits, such as best fit, quality, price and service. This might sound naive, but choices should not be made on the basis of personal relationships, undue influence by third-parties, or false advertising.
In some cases, anti-competitive actions lead to higher prices and inconvenience; in the Fire, EMS, and healthcare and public safety arenas, it can lead to higher healthcare costs, degraded quality of care, and even injuries or death.
Some states and municipalities are working to change the rules and requirements for engaging with EMS agencies; we applaud them! Unfortunately for the public, though, these policies often have an anti-innovation effect, because they favor large incumbents.
Still, as Fire and EMS agencies nationwide get younger and more tech-savvy, technology companies are being asked to prove their capabilities beyond marketing hype.
I appreciate your straightforward approach to this topic.
The fundamental problem is the dozens of ePCR vendors who provide reporting to dozens of EMR systems. Ultimately, the patient suffers as lost EMS reports directly impact the care and at times, clinical decision making within the emergency department, not to mention the millions in lost billing information and poor revenue capture. Medmerge Solutions has solved that problem using a vendor neutral approach be providing a universal bi-directional feed between all ePCR vendors and EMR’s. Lost reports and faxing are a thing of the past, face sheets are eliminated, all stakeholders operate in a HIPAA compliant environment and efficiency is maximized.