Congrats on the massive process improvement on using readily-available technology. I'm no lawyer but I'm pretty certain that this violates HIPAA, which means it's a new market just screaming for PII-managing image-transfer networks and startups.
Congrats on the massive process improvement on using readily-available technology. I'm no lawyer but I'm pretty certain that this violates HIPAA, which means it's a new market just screaming for PII-managing image-transfer networks and startups.
That said, we were in a Paramedic system with a relatively short to-hospital drive time, and going to an academic medical center that had 24/7 in-house interventional cardiologists. If you're in a aystem with only EMT-Basics (who are trained to perform the EKG but cannot interpret the printout), or going to a hospital where the interventional cardiologists need to come in from home, or if your primary hospital doesn't even have a cath lab and will need to divert you to another bigger hospital, it makes a lot of sense to be able to send the EKG from the field and get the ball rolling early.
Those steps could be automated. And since this would usually be life-threatened situations, they should be automated. I wonder how much HIPAA rules complicate the technology; they certainly don't make the space attractive or fun to work in. This sounds like a great disruption for a startup to make, if they can deal with HIPAA effectively.
I interviewed for Physio, but turned down their offer due to mandatory drug testing. They seemed to be really, really locked down due to regulations, and I suppose I do want the regulations on defibrillators to be fairly strict.
There are several companies (including a couple YC alums like Aptible) working in the helping-developers-deal-with-HIPPA space already. Creating a compliant application for transmitting ECGs wouldn't really be a new thing-- when attending an emergency medicine conference two years ago I met a physician/programmer who had done just this for both stroke and heart attack, designed and marketed as a wraparound subscription-based solution. The trick is doing it well, and if you could integrate the information with the receiving hospital's workflows (e.g. EPIC integration or something) you could sell it easier. Pictures of ECGs are also a fairly inelegant solution compared to sending it to the ECG printers that a receiving hospital has, or sending the actual waveform data, but for rural/underfunded EMS agencies it would be nice.
(FWIW, I work in a Bay Area emergency department that is a STEMI receiving center but does not receive field-transmitted ECGs prior to arrival. There's room to work on this stuff. If anyone wants to do research relating to it or build a system and then let me do research with it, get in touch.)
The entire process: - Hit the send button - Click the wheel to pick the destination - Spin the wheel to highlight the destination hospital - Click the wheel to select - Spin the wheel to 'Transmit' - Click the wheel to send it
Done...
There would clearly be some concerns with making sure that the right data was matched up with the right patient, I'm just wondering about how the technology could work, and what the more subtle issues might be.
edit: I see in your other comment that you are talking about scrolling to the correct hospital. It seems less good for the immediately involved technician to spend time on this than for whoever it is at the hospital to do it (I did already mention the caveat about record matching).
If I'm sending an EKG, I'm also going to be picking up the phone shortly to talk things over with the doc at that ER. There would never be a situation where I don't already know where I'm going before transmitting an EKG.
When you pick up the phone and are talking to someone, the system could be showing them the EKG you did, with no intervention on either end.
I realize there is much opportunity there for bad implementation, I'm more interested in understanding the characteristics of a great implementation. Maybe there are reasons to leave it to the discretion of the EMT, but it being easy for the EMT to handle isn't one that I find very satisfying (I find it arbitrary to the implementation).
I call the hospital because I want to make sure they got the transmission and are going to be ready for me when I get there. The transmission and the call are generally a couple minutes apart.
There are certainly _plenty_ of places where the workflow in the back of the rig could be improved, but this really isn't one of them.
This is an obvious opportunity for improvement: I call the hospital because I want to make sure they got the transmission. The ideal case would be that you don't even have to think about whether they have the information or not, the system should handle that with very high reliability.
You've also taken "decision" differently than I meant it. I meant, why do you have to decide to transmit the EKG, not the decision about which hospital to go to. Repeating myself, it would seem to be an improvement if you didn't have to pay any attention to whether the appropriate hospital had access to any readings/recordings that you had (I would think it would be better if it were trivial for someone there to pull them up, of course with high reliability).
I'm not feeling around for some opportunity to innovate/improve, I'm just curious about the factors that such a system has to deal with, and which of those factors are less idea than they could be, and why. That it isn't a big opportunity for improvement is useful feedback in general, but it doesn't really address the curiosity.
The act of transmitting the EKG serves to give the hospital a heads up that I'm coming, and that I think this patient needs care right away. I understand you're suggesting a system where every bit of data my monitor collects is available in every hospital in real-time, so I just have to call them up and reference it. My point is that is that the act of sending the EKG is a really miniscule part of the process. You're talking about 5 seconds over the course of a 30 minute event.
I don't think the tradeoffs in complexity and quiet failure modes would be worth it. If I transmit something, I get a confirmation right then that it did or didn't work. If a passive data aggregation system fails (and I'm used to it 'just working'), then I may not notice that it failed.
After reading the procedure you've described I feel very grateful for our highly developed acute care system, and the dedicated pros who make it all work.
Implementing a more stable - and legal - system for exchanging medical data is next to impossible because there's a bunch of stakeholders who actively undermine what's in the interest of the patients for their own good.
So, for the time being, transmitting patient data via WhatsApp and the likes unfortunately - and quite bizarrely - probably is the only option to act in the patient's interest. Besides, the regulators won't notice anyway because for them the Internet still is some passing fad.
PS - its HIPAA not HIPPA.