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.
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.