If Twilio will sign a business associates agreement, this could be huge in the healthcare field. EMRs have terrible interoperability so doctors and health systems typically fax health records to one another. However, this service does not look HIPAA compliant based on the sparse documentation. It doesn't look promising that they will sign a BAA according to this document. <a href="https://support.twilio.com/hc/en-us/articles/223136467-Ensuring-HIPAA-compliancy-with-Twilio-made-applications" rel="nofollow">https://support.twilio.com/hc/en-us/articles/223136467-Ensur...</a>
This has been kicked around for a really long time and I'm happy they finally launched it.<p>Around 2013 or so, one of the junior engineers on the Twilio Voice team pitched his innovation week project with a single slide saying "Fax: The time is now." The time has finally arrived! Congrats John.
I just assumed from first glance that this was an early April Fools (I guess it must be April 1st in Australia by now)<p>But after seeing full API docs... is this real? I'm so confused!
If anyone's first reaction was along the lines of: "Faxing in 2017?" or "Is this an April Fool's joke?", consider that the healthcare industry still uses faxes frequently.<p>I once interviewed at a company that was building software for ordering durable medical equipment in hospitals. They told me that all orders were faxed to the insurance companies, and the error rate for copying data to the faxed form was about 90%. This results in repeated fax transmissions and patients waiting days to know whether their insurance company will buy them a wheelchair.<p>Using an API like this, you can at least digitize one end of the process, error-free, and still deliver the expected fax to the other side which hasn't upgraded yet.
Here's how it looks like it works to me:<p>(their stuff is of course HTTPS, and I'm assuming the caller's support links would be as well. Each REST call also has authentication tokens, of course)<p>=== Out: ===<p>You POST data to their REST resource, including a link to your PDF document, which they pull (as well as phone number data). Presumably, you want to add some kind of temporary security token/nonce to the link that you give them.<p>Twilio uses the link to pull your PDF, and sends it to the previously indicated number.<p>=== In: ===<p>You GET a list of FAX doc IDs. I don't see query parameters for date ranges and/or phone numbers, but presumably you can do so.<p>You GET the metadata for a FAX ID obtained from the previous list. This includes a temporary link for the image data.<p>You GET the image data from the indicated "authenticating" temporary link. It's unclear what the format is (accept headers???), but it's likely PDF only.<p>===<p>What seems to be missing in this process is a way to associate an inbound FAX with an outbound FAX (e.g. - barcode or other built in OCR index value). This is needed so that you can support "sign this and send it back" workflows. The phone number is not enough: many docs could go to the same phone number, and the remote signer could send the FAX back from any number, anyway.
Anyone see anything about how they handle simultaneous incoming faxes to the same number? With other faxing APIs we've used, if we get a new inbound fax while another is being received, the second (new) inbound fax will get a busy signal and not get procewsed.<p>Phaxio has said they can handle any number of simultaneous inbound faxes, but we haven't had a chance to try them yet. It would be nice to know if Twilio is an option.
The shocking thing about this is that there must still be enough Faxes being sent to actually justify this new product.<p>Where are they still used at 'scale'?
This is pretty neat. From the API docs it looks like they've really reduced it down to, "<i>Here's a PDF, send this to number XYZ</i>".<p>Here's a fun side project for somebody: Make a network tunnel that uses faxes as a way to send packets back and forth. You can encode the packets as a QR code, ship it over via fax, and then reply back with another fax. Be cool to see that in action with a human doing the receipt / transport vs. a fully automated one (two computers using Twilio API).
Tons of great information on this thread.
The idea that in the year 2017 we are transmitting sensitive data at modem speed technology is somewhat mind boggling. The fax server market is very mature and has evolved, however the transport has not. etherFAX has created the largest ecosystem when it comes to fax and healthcare (<a href="https://etherfax.net/solutions/etherfax-sen" rel="nofollow">https://etherfax.net/solutions/etherfax-sen</a>).
etherFAX supports and serves every major fax server application and EMR. Having over 6 million connected endpoints in healthcare allows for end-to-end encrypted transmissions and guaranteed delivery, without traversing the PSTN. The Fax Federation (faxfederation.com) allows for other fax server providers (like Twilio) to join said ecosystem.
This is neat! But I have to expose the PDF to the internet for Twilio to pick up the file and send it?<p><a href="https://www.twilio.com/docs/api/fax/quickstart#send-a-fax" rel="nofollow">https://www.twilio.com/docs/api/fax/quickstart#send-a-fax</a>
WTF?<p>"Programmable Fax" - as if fax was somehow not accessible to computers before twilio invented a proprietary API for it. Yes, it was, believe it or not: You can indeed send faxes from software, via a fax modem connected to a landline, or an ISDN TA connected to an ISDN line, via a GSM MT connected to a GSM network ...<p>Or, if you like your internet and don't want to deal with older communications networks directly, there even is a frickin non-proprietary API for it that was standardised nearly two decades ago: T.37 and T.38. And there have been companies offering gateway services that allow you to send faxes to the PSTN using those APIs for about as long.
I am interested in how this works on the back end, and whether or not they're using t.38. And if they're using t.38, how reliable this service is. As someone that played with -- nay, engineered -- a faxing solution over a couple of years' worth of side project time in order to facilitate playing an ARG, I can say confidently that faxing over VOIP lines ("t.38") is almost impossible to do reliably.
Ugh. How can it be possible that my favorite technology service in 2017 is perpetuating something that <i>absolutely must die</i> ?<p><i>Common decency</i> dictates that we must do everything possible to make faxing as <i>hard as possible</i>.<p>When someone asks you to fax something, <i>pretend you have no idea what they're talking about</i>.<p>Then ridicule them.
Twilio and Phaxio just had a fax based conversation live on youtube<p><a href="https://ibb.co/ksStrF" rel="nofollow">https://ibb.co/ksStrF</a>
<a href="https://ibb.co/fUFDrF" rel="nofollow">https://ibb.co/fUFDrF</a>
Oh thank goodness! I've been waiting for this. Been looking for a quality alternative to efax for my wife and now I can build one for about 1/10th of the ongoing cost.
I think the last time I sent a fax must have been more than ten years ago. How is sending a fax better than emailing the document file or a scan of the document if it was already on paper?<p>As for doctors using faxes,that sounds like a disaster waiting to happen.<p>I live in Norway, all the health records are online so my GP and any hospital in the country can see my records (if I give consent), prescriptions are electronic and paperless, etc. I still get snail mail letters from the health system but that is simply because I have not got around to applying for a secure email account (the state gently reminds me now and again).