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. https://support.twilio.com/hc/en-us/articles/223136467-Ensur...
InterFAX is the SaaS version of RightFax. No installation of hardware, software, or phone lines required. (But, as with any Saas, trust in the vendor is necessary).
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 business that is the limiting factor.
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 applicable to use cases like this that's why I am asking: https://www.cipheredtrust.com/
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.
HIPAA compliance has nothing to do with encryption, and little to do a traditional tech sense of privacy/security. If you handle patient information, encrypted or otherwise, you are subject to compliance hurdles (with the exception of extremely-limited-scope entities treated as "conduits", but the policy does not distinguish between ciphertext and plaintext when it comes to PHI). Fax, email, SMS, etc are all (fairly explicitly) within the realm of things subject to BAA for compliance.
HIPAA (and a broad swath of other tech legislation) is not necessarily indicative of actual security. For example, HIPAA-compliant hospitals are currently seeing a rash of ransomware attacks; any meaningful definition of computer security would include defenses against these kinds of things. HIPAA is domain-specific policy with a poor understanding of the domain. That's (in no small part) a bilateral educational failure; technology makers don't understand policy and policy makers don't understand technology.
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/covered entities entering a legally binding business associates agreement to outline how PHI would be protected.
Scrypt is a company that does faxing in the health tech space today and they sign BAAs and went through a HITRUST assessment.
EDIT:
So, maybe let me clarify what I mean about facilitating that transfer of data.
So, let's say there is:
Vendor ----> Health Care Provider
Even if you are sending data over TLS or some other encrypted protocol, the Vendor and the Health Care Provider need to have an agreement to protect patient data and which restrict what can be done with the PHI being transmitted. If you add a new party to this equation, like:
Vendor ----> Twilio ----> Health Care Provider
Even if you encrypt the data to Twilio and Twilio "promises" to not store the data and promises to encrypt the data when sending it down stream, promises aren't good enough in the eyes of HIPAA/HITECH. You need to have an agreement in place like a Business Associates Agreement in which all parties agree to protect PHI. You can read more about what these agreements commonly outline here: https://datica.com/academy/business-associate-agreements/
There are exceptions to this referred to as the "Conduit Exception" of HIPAA which were clarified in 2013. This doesn't really apply to API vendors or someone like cloudflare. It applies more to phone carriers, postal services and ISPs.
It's a complex topic, but I can keep jamming to discuss some of the nuances.
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 without any risk that the intermediary can access it. That is the solution we've created with our API, you can see the full docs here: https://www.cipheredtrust.com/doc/
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.
> 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.
HIPAA cares deeply about the logistics, which is what the privacy, security, breach notification, etc. rules largely address. The logistics just don't come into play until after the determination that you are a business associate and therefore required to sign a BAA and comply with the rules.
There are lots of ways to securely transmit data -- which is a large part of the problem, there are so many ways to do it that there's no standard way that you can count on all of your clients/customers having access to... or trusting.
But everyone trusts fax since it goes over "secure" voice lines.... even though in many cases it doesn't.
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.
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?
The solution is: Do not FAX or use phone lines to transmit data.
Practically though there isn't a 'good enough' standard from an end user perspective. The very things that make FAX a poor security standard make it user friendly.
* Fire and forget
* 'Just works'
* Short, simple destination identifier
* No real crypto or other security.
A real solution would be for everyone to use (good) key-based SFTP transfers. This isn't that hard to setup (once you've done it once) but it IS difficult to have end users use such software.
The next best thing is FTPS, but that has account management issues (since if you were doing client certs, which are an option here as well, you'd just use SFTP).
What makes both of those harder are the lack of integration in to the existing infrastructure (clinics/hospitals don't have, E.G., WinSCP / FileZilla and/or another SFTP client already setup and in their whitelist of allowed software) and having end user accounts.
Ah also, SFTP has the benefit of transferring time-stamps correctly. FTP, even wrapped in a TLS connection, still doesn't have a standards approved way of transmitting file time-stamps.
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 (https://etherfax.net/solutions/etherfax-sen). 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.
Not at all. There are APIs and also a data transfer protocol called Direct that can facilitate that data exchange in healthcare. You've just got to follow the rules of the road wrt to compliance.
The rules for faxes are pretty strange in Alberta, Canada. The main security measure seems to be adding a cover letter as the first page. Meanwhile, personal health information in emails is a big no-no.
Unless a sandboxed version can be run on site within a private network, OR they make a secure HL7 service, I do not expect healthcare to adopt this over other products like RightFax.
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.
Our pricing might seem higher (and may be in certain situations), but it works a bit differently that Twilio's. Twilio charges you the 1c _plus_ the costs of the call. Phaxio is an "all in" rate _including_ retrying the call. And, at Phaxio, if the calls all fail there's no cost to you.
I'm not saying that we won't adjust our pricing (#competition), but there's a difference in the actual unit cost.
Long time user of Phaxio. We tried many other services and your seems the be the best when it comes to crunching documents - Word, PDF, Images, you name it.
I don't know how Twilio does it, but unless one day in 100 years from now we will be sending 1 million faxes, we will be reluctant to switch and probably save ourselves a headache just to save few bucks a month.
How long does it take to send a page of fax? Their pricing is 0.007 per minute. I haven't seen many fax machines take more than a minute per page, but they would have to take 10 minutes to catch up to your pricing.
I'd be surprised to see more than a couple minutes for even a complicated fax page. I've seen 45-70 seconds average for a not-too-complicated page.
It also depends on the baud rate (never thought that term would come back, eh?) negotiated between both ends. A 14400 baud transmission will of course be faster than 9600.
I paid $10 to send a 28 page fax. I absolutely believe utility and govt companies still use fax because they want to make somethings very hard for the average customer. There's no reason why I shouldn't be able to send an email a pdf to show good credit so they don't charge me a deposit fee.
Twilio please build a mobile app so those of us who don't live with typewriters and fax machines can deal with our nasty govt.
Was surprised at the results. It may not be the only conduit, but it is there for job applications, VA benefits, applying for a headstone in a national cemetery, court filings, IRS documents, and much more.
Quick answer is that it depends on what's on the page. It can be as quick as a minute or significantly longer if there are images or lots of data the page.
I'm not sure the Phaxio pricing is all that much higher than Twilio. They're covering failed faxes, cancelled faxes, faxes that require multiple retries, and faxes that just take a long time — only charging per page delivered. Those will all eat up minutes that you'll pay for with Twilio.
We (Twilio) are also only charging for successful delivery. Failures to not incur any billing. Retry is (currently) on the customer to implement, but since we don't charge for failures, that doesn't affect cost.
Yes, we're charging per-minute fees, but for US, at least, it's sub-1-cent, and with my testing so far, I haven't seen it go more than a couple minutes per page for something fairly complex, and that's worst case.
After reading these arguments I was expecting something in the range of dollars per fax.
Is 7 cents per page really that much? I'm not very knowledgeable about this stuff, but are there really that many places out there faxing thousands of pages where 7 cents per page vs 5 cents per page is really going to make a difference for them?
There isn't consensus on the 5 cents per page part. Some think it is closer to 3. If that's true, generally, I'm concerned if a competitor launches at less than half my price.
Even if it is 5 cents, that's a 30% discount, which seems significant.
When your user-base is comprised of doctors, lawyers and blue-chip companies with ancient business processes you can get away with charging what you like.
Actually though! This has been an internal meme since then, there's been PRs for implementing it just hanging around for years =P I had to check the date to make sure it wasn't an April Fools joke.
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.
A corollary from William Gibson's famous quote, "The future is already here — it's just not very evenly distributed.", is that just because you're living in the future where you, and all your friends have smartphones, doesn't mean that everyone does.
In fact, there are huge swaths of people that don't even have broadband Internet access, even in the US, even using the FCC's antiquated definition of broadband of 2 Megabit. Meanwhile, I can get 20 Mbit with my cellphone on 4G LTE on a good day.
Be careful when extrapolating from things you don't use because it doesn't necessarily follow that others don't.
I got a snotty reply from someone at Twilio when I suggested it might be an April Fool's joke on Twitter.
Amazon prime buttons were announced on 3/31/15 or 4/1/15 (I forget which date it was) and I remember a bunch of buzz around my office wondering if it was an April Fool's stunt or not. I don't really see the harm in waiting a few days to launch some kind of new/potentially unbelievable product so you don't do it on 4/1, since the internet tends to go nuts on that day.
The concept of mailing pieces of paper as a way to pay bills is so strange to me. Fore reference, I'm in my mid thirties and have never used a check in my life. I remember my mom used them when I was very young, but I don't think I've even seen one in about thirty years.
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.
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.
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.
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.
A lot of the personal financing industry still does too, particularly for car loans. There are some web solutions but they always involve some third party service that both the car dealership and bank has to sign up (and pay) for.
(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)
=== Out: ===
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.
Twilio uses the link to pull your PDF, and sends it to the previously indicated number.
=== In: ===
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.
You GET the metadata for a FAX ID obtained from the previous list. This includes a temporary link for the image data.
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.
===
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.
Your description is right. To give this a visual dimension, here are sequence diagrams showing how outbound and inbound faxing work at another provider (disclaimer: I'm a co-founder at Interfax):
Your suggestion for a "sign this and send it back" workflow is an excellent idea. Indeed it shouldn't require more than a single fax number per client, leaving the barcode to do any necessary association. But I would say that this functionality is not best placed on the fax service provider's system, but rather in the application that creates the document to be signed and eventually receives it back. Here's what I mean: http://imgur.com/a/JEldx
Are document-specific replies part of current manual faxing technology? This seems like something that would depend on your own internal document management rather than the fax protocol itself.
Our current vendor supports this. There is a barcode (or on older stuff, just digits) in a "window" on the document which the system OCRs and uses to index incoming documents. This allows the incoming (returning) docs to be routed back into a workflow for the right user. Important due to volume and data privacy issues.
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.
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.
Any reasonable fax service provider will allow reception of multiple faxes concurrently. Some might deliberately limit the number of concurrent connections so that one client's activity doesn't kill their other clients, but even that sort of throttling would in practice be a very rare event.
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 actuators to their software without having to bizdev the company into adding an actual API integration.
To explain the typical workflow here, the restaurant receives a fax from the marketplace with a phone number to call to acknowledge the delivery. There is a short numeric code on the fax print out that the restaurant types into the IVR system.
This is how these marketplaces can confirm someone is there to actually receive the order and provide that feedback to the customer that their order has been received.
I think (but am not sure) that they can provide time estimates through the IVR system as well.
For years the operating procedure for Seamless/Grubhub/Delivery.com orders was a form that would be faxed to a restaurant, the restaurant would communicate that order to the kitchen (either by it's own POS system, writing the order on a regular order ticket or even giving the kitchen the fax sheet) and then the service would call the restaurant and the employee would enter the confirmation code into the phone.
Some restaurants moved towards having tablets and receiving order via an app, but I'd guess that fax is still an option since it's difficult to integrate with a bunch of different POS systems and there are also a fair amount of restaurants that use hand written tickets to communicate orders to a kitchen.
I wouldn't be surprised if this Fax API is the same technology that those companies use to fax orders to restaurants.
Kitchens are still a rough place for technology, and even though the latest iPhone might survive a drop in the toilet, I don't want to drink the soup after a phone's taken a swim in it.
I've seen tablets in cafes at the front of the house, and sometimes the cashier (who can't touch food while they're also touching money) copies the order off the tablet and onto a piece of paper and passes it off to the kitchen the old fashioned way, while acknowledging it was received on the tablet.
AFAIK HotelTonight also use faxes for every booking, as do almost every other booking site. Mainly due to the same issue: all hotels use different systems.
I was under the impression that HelloFax/HelloSign basically did this -- they would let you digitally sign the document, and then fax it out to someone (possibly yourself).
So it's easier/cheaper for a restaurant to have a dedicated phone line for faxing (plus fax and supplies) than connect a printer to a PC?
Is this because someone needs to actually print incoming emails or orders? And if yes, is there an opportunity for some kind of software solution that would always print what it receives, with no human intervention?
The short answer is 'yes' — fax machines are actually a pretty great solution to this problem. If you think about it, there isn't really that much overhead for having a fax line and a $40 fax machine vs running a full computer + printer combo, set up is trivial, faxes have a very well-understood track record, and the 'sender' gets direct feedback on whether or not the physical document was successfully delivered.
If there's a software gap here, it's being filled as features in modern Point Of Sale systems. That space is really crowded right now (Revel, Clover, Toast, 'more modern' offerings from legacy providers like Micros and NCR). There may be an opportunity to provide a more niche offering rather than a comprehensive solution like those, but the space is far from empty.
I'm not looking for startup ideas in this domain, I was just wondering "in general". If the PC + printer is already there (surely it has to be for accounting, etc.) why have a fax.
But ok, if the fax and the phone line cost next to nothing and it "just works", then sure it makes a lot of sense.
A lot of these restaurants _do_ have a PC + printer in a back room or office somewhere. If the restaurant is owned by a group (or small chain), that setup may only exist at one location.
They can (and do!) put the fax machine right by the kitchen.
Email-to-printer is a built-in feature on many high-end printers already (HP calls it ePrint), and it's easy enough to glue together some software (fetchmail --python/whatever glue--> cups) and package it up as a distro for the raspberry pi 3 (with its built-in wifi and regular usb ports). Plug Twilio in and now the system can also receive faxes.
If you have lots of friends in the restaurant business and am itching to get into sales, there's a cottage-industry that fits between a $50 on-sale inkjet printer, and $1000 high-end HP, but it includes on-site installation, configuration, and support.
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!).
Two years ago I had to work on integrating a SaaS product with fax. The client was a large financial organization who had a contract with a counterparty. Under this contract, they had to give notice to each other of a certain action and the contract stipulated the message was sent by fax. It was easier to implement fax than get lawyers involved in redrafting the contract.
I think a faxed signature counts as a "wet" signature. Also it's easier to sign then feed into a fax machine than:
- sign
- scan (usually sent as a weird filename to your corporate email)
- save the attachment, rename the file, create a new email, attach the file, send
Could you elaborate on the "not so much"? A lot of companies (including law firms and Fortune 100 corps) have had me sign documents with DocuSign/HelloSign with no reservation. What would be the potential legal differences compared to an actual signature?
I'm working on the California death certificate automation system. DocuSign is not legally accepted for a doctor to sign off on cause of death for a decedent.
Laws for your use case will be different. That's mine.
47 states (New York, Washington and Illinois the outliers) have passed an Uniform Electronic Transaction Act that confers electronic signatures with equal weight. A federal law has existed since 2000. Unfortunately a self-fulfilling prophecy of people not accepting the validity of electronic agreements because no one else does has kept usage low. Even faxed contracts are often followed up with Fedex delivered versions. The only electronic agreement I've done is FAFSA's PIN blessed submission. The recent high profile payment card breaches and politician email doxxing have further decreased public confidence in all things computerized.
> For some reason the fax is legally sounder than email.
I suspect that faxes have been around for so long, and tested in court so many times, that by this time they are as good as holding the original if a lawsuit were to happen.
> They are viewed as "safe" for credit card information, as opposed to emails.
The odds of someone obtaining credit card information from a plaintext email is a lot higher than someone decoding a VOIP SIP/T38 stream over the public internet, and reading the secrets out of that.
And if its through a traditional carrier (not an Internet provider), its digital, but almost always over their internal network. It is more secure through obscurity alone than plain text email.
> Yes. I'm not skeptical that fax is safer than email. I'm skeptical that it's safe.
Nothing is 100% safe. It is just a matter of being safer than the effort the attacker is willing to spend gaining hold of the data (or that it will take so long that the data is no longer worth having).
The context is that companies that continue to push fax could, and should, do something better. The manufacturers I mentioned, for example, could implement paypal or stripe payments with very little effort. Aside from security issues (fax to email gateways, cc info sitting on a shared fax machine for everyone to see), it would reduce costs.
Does it matter? The point is that fax isn't inherently a great idea for confidential info.
There's also the issue that many fax endpoints that are fax to email gateways. Or fax to non https website gateways.
Edit: Nobody is arguing for using email instead of fax. The argument is to use something better. Like paypal or stripe instead of full cc info + cvv2 on a piece of paper.
When it comes to liability for breaches of confidentiality, yes, it matters very much whether the sender chose an poor channel or the recipient had choose poor practices around what was done with information once it was received.
Faxes seem to be in use at places where there is an established system/bureaucracy. We use them regularly in aviation because our suppliers/customers/service providers require them for some reason. Medical offices use them to adhere to HIPAA requirements. The government and large corporations use them because it was how the system was developed at some point and they haven't gotten around to changing it yet. (UPS, for example, can't resend us certain invoices via e-mail, only fax. I have no clue why.)
Booking.com uses it alot. They have a MASSIVE fax system for servicing European hotels because many of them (generally smaller ones) aren't connected in any meaningful way. So when Booking.com makes a reservation they fax confirmation details to the Hotel. The hotel can also make modifications by faxing details back
I've had to use fax to verify my identity in NYC when setting up a Con Edison account (electricity). I had no way of sending a fax physically so resorted to using some shit online service that tricked me and kept charging me every month after sending the original single page I needed. Horrible experience.
At one point, I heard Apple used to require you to fax a certified copy of legal documents relating to your company in order to open an App Store developer account.
Also, fax is still used for a lot of financial and legal stuff generally, especially in countries with less developed Internet infrastructure.
This is pretty neat. From the API docs it looks like they've really reduced it down to, "Here's a PDF, send this to number XYZ".
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 (https://etherfax.net/solutions/etherfax-sen).
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.
I'd be surprised if it wasn't similar to (or exactly like) their POST auth. They concatenate the URL, the post variables (alphabetically sorted) and your twilio account id and hash it with your auth key. They put that hash into an auth header on the post.
I had to dig into it because we had a reverse proxy in front of our app and the hash generated by their client .net library was understandably different than what they sent because the domains were ultimately different.
"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 ...
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.
You could easily add it yourself but it there could be other uses if they implement it. They could use the barcode data to add additional meta data to the fax file record. The meta data could then be used in task router.
For us — we send out requests for medical records to doctors' offices. When doctors send records back to us, they usually include the cover sheet we sent over. Since that cover sheet has a barcode on it, we know which record request the incoming records are for.
Same. At work we are in the process of rewriting an application that sends FAXes to doctors for their signatures. The barcode is on the edge of the doc, rather than the coverpage, but otherwise, same. The barcode is used as less error prone OCR for a record number so the FAX can be associated with the right "file". The users requesting the FAX loop view the returned document when it comes back to verify it (or at least, they will, when I finish recreating that feature :-) ). HOWEVER, users DO NOT sift through all incoming documents with data for other people which is none of a given user's business. Having to do so would be not only an inconvenience, but a data privacy issue.
Plus, I would rather somebody else build doc ID OCR in a language other than Java so I don't have to build it myself. This is going to come up time and time again.
Some companies use the barcode value to route the fax to certain person or group or filing into a specific area. There are lots of industry specific applications.
Not everyone that demands a fax wants it through fax. Making someone's job harder socially won't get a business, organization, or agency to change their ways.
If you want places like healthcare to stop using faxes, propose a secure solution that meets their needs and fulfills government requirements / restrictions.
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?
As for doctors using faxes,that sounds like a disaster waiting to happen.
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).
