Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmable Fax – API for sending and receiving faxes

twilio.com

Post reply on HN
Print view View original

121–130 of 174 posts

Re: Programmable Fax – API for sending and receiving faxes

#121

Post by a2tech »

jandrese wrote: post #118
Edmond wrote: post #96

Earlier quoted context omitted.

can you elaborate on the HIPAA concerns related to faxing/transmitting health data? Faxing is a transport service... is the concern around security and privacy while en route from the API to the destination? If there was a way to facilitate that transfer without compromising privacy or security en route would that address HIPAA concerns? We've developed a privacy preserving trust relay protocol which might be applica…

Aren't faxes unencrypted? Are we living in a world where tapping phone lines is impossible?

No one said HIPAA made any logical sense

Re: Programmable Fax – API for sending and receiving faxes

#122

Post by pg_bot »

Edmond wrote: post #96
viggity wrote: post #88

Earlier quoted context omitted.

I'm in healthcare. I'm not kidding you, we got an 800 page fax last month from one of our clients. It wasn't a generated e-fax either, we received it electronically (we use sfax), but the lady who sent it literally printed 800 pages and put them on her fax machine. It isn't the business opportunity that is the problem (that is huge), it is the all of the HIPAA/HITECH regulations which creep into every part of your bu…

can you elaborate on the HIPAA concerns related to faxing/transmitting health data? Faxing is a transport service... is the concern around security and privacy while en route from the API to the destination? If there was a way to facilitate that transfer without compromising privacy or security en route would that address HIPAA concerns? We've developed a privacy preserving trust relay protocol which might be applica…

I can elaborate since I own a business that requires HIPAA compliance. The main issue is not transmission, it is storage. According to their documentation "We store a list of your sent and received faxes, along with the media, for 180 days". This line opens you up to the privacy/security rules of HIPAA since your health records are littered with protected health information (duh). These regulations are not unreasonable to comply with if you have done a lot of planning upfront, but if you have to change the technology culture of an organization you may run into a bunch of problems.

Now you have to store all of these faxes encrypted at rest, log who has accessed any of the files and why they needed access, always transmit over https, safeguards to ensure high availability, the list goes on and on. Surprisingly HIPAA/HITECH does not have an authority or a checklist by which you can guarantee compliance. That designation is solely determined by the covered entity or their business associates since the rules allow for a lot of leeway in implementation. Due to this ambiguity a lot of people will forego the healthcare field entirely which causes crazy prices for what I think are relatively simple services.

Re: Programmable Fax – API for sending and receiving faxes

#125

Post by markolschesky »

Edmond wrote: post #116
markolschesky wrote: post #114

Earlier quoted context omitted.

I wouldn't think that a Fax API provider would be exempt under the conduit exception of HIPAA/HITECH. You couldn't guarantee that the API vendor wasn't sniffing/storing/protecting data while transmitting the data between entities. You can read more about this exception here: http://www.hitechanswers.net/when-does-the-hipaa-conduit-exc... You would facilitate that transfer by having both parties of business associates…

You actually can guarantee the transmission of information from one entity to another without sniffing or alteration...that is how internet transport layer security works....our API is built on those principles. Of course there may be other caveats that I am not aware of, I don't know much about HIPAA. EDIT: You don't need to trust twilio (or any intermediary)...You can transmit encrypted information end-to-end witho…

HIPAA doesn't care about the logistics of whether or not the intermediary can/cannot decrypt the data. If the intermediary touches the data and it's not exempt by the conduit exception, then there has to be a BAA in place. It's why even though FaceTime hypothetically has E2E encryption and Apple claims to not have the capability to decrypt the data, it's still inappropriate to use for patient-doctor communication due to the lack of that BAA being in place.

Re: Programmable Fax – API for sending and receiving faxes

#126

Post by pyre »

jenamety wrote: post #112
kevinburke wrote: post #2

This has been kicked around for a really long time and I'm happy they finally launched it. 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 have previously integrated with eFax in 2010, so an internet fax provider is not new to me, but forgive my ignorance as I haven't visited the space in a while. Which innovation are you excited about and referring to? From the comments it seems to be 'developer friendly API' or 'Simplicity in pricing' as the to big draws, just curious what has changed since my last days?

Being "developer-friendly" can be a big draw. Take Stripe for example. It's an HTTP API with bindings in a number of languages. Previously I worked with a payment processor that required we run some sort of Java application even though we weren't a Java shop. Someone had to setup a way to wrap the Java application to interface with the payment processor (not even getting into the issue that now we have to deal with running a JVM-based application). Some companies are actively developer hostile in their interfaces.

Re: Programmable Fax – API for sending and receiving faxes

#127

Post by Edmond »

markolschesky wrote: post #125
Edmond wrote: post #116

Earlier quoted context omitted.

You actually can guarantee the transmission of information from one entity to another without sniffing or alteration...that is how internet transport layer security works....our API is built on those principles. Of course there may be other caveats that I am not aware of, I don't know much about HIPAA. EDIT: You don't need to trust twilio (or any intermediary)...You can transmit encrypted information end-to-end witho…

HIPAA doesn't care about the logistics of whether or not the intermediary can/cannot decrypt the data. If the intermediary touches the data and it's not exempt by the conduit exception, then there has to be a BAA in place. It's why even though FaceTime hypothetically has E2E encryption and Apple claims to not have the capability to decrypt the data, it's still inappropriate to use for patient-doctor communication due…

got it.

Re: Programmable Fax – API for sending and receiving faxes

#128

Post by sstradling »

patio11 wrote: post #12
bizzleDawg wrote: post #3

The shocking thing about this is that there must still be enough Faxes being sent to actually justify this new product. Where are they still used at 'scale'?

A lot of the Uber-for-food-delivery startups use them for ordering at restaurants because there is no text-based API to restaurants and the UX of receiving an automated phone call is poor. They're pervasive in finance, insurance, employee benefits, etc. They're also a good one-to-many API multiplexer. So many businesses can take a fax and have a human operate on it that many software companies can use them to add act…

Exactly. I used phaxio with a group-ordering side project I built a while back, there really was no better option for getting/confirming orders to restaurants reliably. Love that Twilio is doing this (even though I'm out of the food-delivery business!).

Re: Programmable Fax – API for sending and receiving faxes

#129

Post by giarc »

sorenjan wrote: post #106
coffeedoughnuts wrote: post #7

I just assumed from first glance that this was an early April Fools (I guess it must be April 1st in Australia by now) But after seeing full API docs... is this real? I'm so confused!

I'm guessing it's an American thing. I think they still use checks too.

I was in New Jersey once and was trying to catch a cab to a hotel. I had no US cash and needed to use credit card. Cabs in New Jersey apparently don't accept credit card. At the airport I had to buy a check for $10 or $15 at a machine using my credit card. When I reached my destination I filled out the check for the driver. It was linked to my credit card and charged later on.

Re: Programmable Fax – API for sending and receiving faxes

#130

Post by jandrese »

markolschesky wrote: post #120
jandrese wrote: post #118

Earlier quoted context omitted.

Aren't faxes unencrypted? Are we living in a world where tapping phone lines is impossible?

Phone carriers are exempted under the carrier exception of HIPAA. Same thing with phone calls. API transactions are not exempted, even when encryption is used or data is not persisted in the middleware. http://www.hitechanswers.net/when-does-the-hipaa-conduit-exc...

Is this one of those cases where implementing a solution is practically impossible, so all of the existing solutions are just the horrible old ones that were grandfathered in?
Post reply on HN