Hacker News Reader

Comment by dawhizkid | Hacker News Reader

As someone who most recently worked in product at a healthcare startup I found the most difficult thing about innovation in the space is the cost of compliance/regulation.

When you work in an industry that is so highly regulated, and assuming you are working at a company that follows the rule of law, how do you actually "disrupt" a set of problems in this industry when there is so little wiggle room for doing things differently? Following legal guidelines in healthcare means reenforcing bad norms rather than disrupting them.

One of the biggest WTF moments I had when I first started was realizing that fax communication is HIPAA-compliant whereas email/SMS are not, even though in theory anyone could walk by a fax machine at any time and take medically sensitive information sent over.

View on HN

I work in medical devices. The regulation can be unnecessarily prohibitive, but more often than not I see it used as a cop-out.

Where one entrepreneur says "the status quo in this space is so behind the times I can't work there," another says "there are enhancements waiting to be back-ported into this tightly controlled space from domains that have already been proven it to be a good idea." Only one of those people knows how to make money.

That's just the low-hanging fruit. And there's so much of it. Foot-stomping about having a formal quality system instead of "move fast and break things" is letting the perfect be the enemy of good.

> One of the biggest WTF moments I had when I first started was realizing that fax communication is HIPAA-compliant whereas email/SMS are not

That's not exactly the case; fax communication can easily violate HIPAA and email, appropriately secured, can be compliant, even for PHI (SMS is more problematic because it's unsecurable).

The issue is specifically that there is precedent (or, at least, a widely held interpretation, not sure there is actually directly applicable case law) that fax is not an electronic communication mechanism for the purposes of HIPAA law and regulation, so while general rules on disclosure and communication apply to it.

> even though in theory anyone could walk by a fax machine at any time and take medically sensitive information sent over.

Not having appropriate safeguards to prevent that at a HIPAA covered entity is, itself, a violation of HIPAA.

It could be your mindset. When I worked in drug development (wet chemistry and lots of animal studies) the regulation, while everpresent, just didn’t seem like any kind of burden when compared to everything else we had to deal with.

I'm pretty sure email can be HIPAA compliant as long as you implement the system using the established guidelines.

Indeed it is as long as you’ve configured your email system to use TLS and not downgrade to no encryption if the handshake fails for mail systems where HIPAA-governed information is departing to.

Source: Not a lawyer, not your lawyer. Sign off provided by non profit bio research orgs lawyer before I set it up.

This is my understanding as well. Additionally, I believe you can send encrypted attachments over an unencrypted connection. Furthermore, https://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.p... suggests that it's acceptable to send patients unencrypted PHI if they've explicitly agreed to accept the risks associated with that (although I'd be extremely cautious in those situations)

That’s more for B2B use cases. Like between a medical practice and hospital.

The unreliability of delivery to destinations that don’t support TLS will create customer service issues in B2C scenarios.

Re email: Because you don't know if the destination server is encrypted (you send emails from your server and it finds the destination), any email must be intercepted at your server and a hyperlink to a secure site inserted in place of the email body. The email becomes just a notification via SMTP. The recipient then goes to the site and logs in to view the email. The PHI is what you care about (and it's, very, very strict). No PHI in the subject either.

I suspect the reason faxes are compliant is a few:

1. Grandfathered in. 2. The number of unauthorized people that can see them is very limited (to whomever has access to the fax machine). 3. Modern fax machines print face down. 4. Data is in hard copy format which is more difficult to copy.

As an aside, modern fax machines are probably less secure than the old ones. Fax machines using digi-boards and databases and whatnot. The vast majority of US healthcare use faxes though.

> Re email: Because you don't know if the destination server is encrypted (you send emails from your server and it finds the destination), any email must be intercepted at your server and a hyperlink to a secure site inserted in place of the email body

Couldn't this be solved by just encrypting the email itself? Even the headers could be encrypted along with the body.

On the subject of fax machines, would they still be compliant if they're connected to a VOIP system?

>Couldn't this be solved by just encrypting the email itself? Even the headers could be encrypted along with the body.

Yes, but that's typically more cumbersome as you have to trade keys with everybody that needs an email. I wrote an emailer for a medium sized company and it sent about 500K emails and 500K faxes a month. That's a lot of key management.

You could use symmetric encryption, but then you give out the shared key to so many people, it tends to lose value, especially when you don't control how your recipient organizations protect the key. (it could be in a file on a shared folder named Email-EncryptionKey.txt).

On top of all that, each client will have to be taught how to decrypt (and encrypt) emails, either at the employee level or at the network admin level. Most provider organizations are small. Typically a doctor or two with a nurse and a couple people working the schedule and regulatory. In summary, it would achieve the objective but it's not ideal.

>On the subject of fax machines, would they still be compliant if they're connected to a VOIP system?

Yes, as long as no PHI went over an unencrypted channel and all servers are secured (physical and computational) and logged.

> but that's typically more cumbersome as you have to trade keys with everybody that needs an email.

What would be needed is a public key infrastructure. If organizations like the state board of medicine could serve as a certificate authority for physicians licensed in that state (or maybe the DEA since they issue id numbers to physicians that are needed for controlled substance prescriptions), then the key management would not be as much of an issue. In other words, it shouldn't be handled by individual organizations; it should be handled by the authorities who are responsible for licensing doctors, nurses, pharmacists, hospitals, etc.

> On top of all that, each client will have to be taught how to decrypt (and encrypt) emails

This is certainly something that can be automated and shouldn't have to be a manual process. A plug-in for a program like Outlook should work in the vast majority of cases. That is, if the email is sent to the wrong address, then the recipient would only see encrypted text, but it would automatically be decrypted for the correct recipient.

That sounds fine in theory and if implemented well it would work, but I'm not sure how well it would work in reality. I just refer to my small business tax return every year to get an idea of how many forms would need to be filled out to just send email. How would that work for offices that send non PHI emails? Would it go through that system too, or would it have to key on recipient email addresses? How hard would it be to shut down and create a new email for each employee that left, etc. Would you have to have a special email server just for PHI and another for regular? How many times would employees accidentally send PHI over a non-secured channel on accident?

Also, physicians themselves rarely send emails, they have office assistants do it. They are busy providing care. How would that work? The office assistant position doesn't have any direct regulation (that I know of) so you'd either have to have the physicians send out emails (ya right), have an assistant use the physician's account (oh no), or add a bunch of regulation to office assistants (to the tune of doctors and nurses) which would make them more expensive and make office visits more expensive (etc).

It sounds good as a technologist, but if you look for unintended consequences (costs), I'll bet there are a bunch I didn't even think of.

Also, organizations are highly motivated to get this right because the fines have teeth. Up to $50K per incident capped at $1.5 million per annum.

https://www.truevault.com/blog/what-is-the-penalty-for-a-hip...

> How would that work for offices that send non PHI emails?

They could encrypt those emails as well. While sending a non-encrypted email that contains PHI is a problem, sending an encrypted email that doens't contain PHI shouldn't be an issue (as long as the intended recipient can decrypt it, which they should).

> How hard would it be to shut down and create a new email for each employee that left, etc.

That comes down to revoking the certificate or using shorter intervals for the duration where the certificate is considered valid. For example, if the organization requires that one changes their password every 60 days, then a certificate should not have more than a 60 day period where it's valid.

> Would you have to have a special email server just for PHI and another for regular?

This wouldn't be server dependent. This would be dependent on the email client handling the encryption and decryption. The more that's automated, the less chance that there's a mistake with regards to email containing PHI.

> Also, physicians themselves rarely send emails, they have office assistants do it. They are busy providing care.

Physicians have to do all sorts of things like writing progress notes, dictating admission and discharge summaries, calling in prescriptions, writing orders, etc. The system they use could also be used to securely send PHI containing email to other physicians, pharmacists, or hospital systems.

But regulation could be a good incentive against physicians allowing others to use their account credentials to do things like sending PHI information to other organizations. No physician would like to be summoned by the board of medicine of the state they're licensed in over something like that.

But I think that a lot of the problems could be addressed by those who have cross-domain knowledge about technology and health-care (speaking as someone who went through medical school and subsequently changed fields to computer science/software development).

Good discussion, but I think you are solving a problem that has already been solved, but you are proposing a much more cumbersome and complex way.

The current method is for insurance companies to install software on their SMTP server and that's about it. Much less overhead, much less chance of mistakes, much less cost to the physician's office, much cheaper overall and just as good for protecting PHI (since it's automated, no accidents).

Also, the vast majority of communication containing PHI is with insurance companies and the government, so your solution moves the onus of protecting PHI from the insurance companies to the small physicians, which I don't think is overly helpful.

Of course there is no way to really tell unless we complete vet it out and put cost associations with everything and do PHI leak risk assessments. I'm perfectly happy leaving this as a thought experiment though. :)

> The current method is for insurance companies to install software on their SMTP server and that's about it.

I would hope that they require TLS encryption for any connection to their SMTP server. Otherwise, any communication containing PHI could easily be intercepted. This also doesn't address the issue of securing the IMAP or Exchange and MTA server(s) that the sender uses to send the email to the insurance company.

> much less chance of mistakes

Unless the sender CCs a copy to another address where the MTA doesn't require TLS encrypted connections and doesn't have any such software installed on the MTA. That's why the solution I proposed (having the client program automatically encrypt the email before sending it and relying on PKI to handle decryption on the other end) would be more fool-proof since, even if the email was CC'd to another address, it couldn't be decrypted by the unintended recipient.

As for the cost argument, I think it could be implemented as a nominal cost on top of the costs that the physician already incurs in the process of applying/renewing their license, the practice license, etc (e.g. name, mailing address, telephone number, fax number, email address along with your PKI state board signed certificate).

> Also, the vast majority of communication containing PHI is with insurance companies and the government

Doctors have to communicate with other physicians outside of their group practice, hospitals they may not be affiliated with, and pharmacies. How is PHI communication in this context currently handled?

> Of course there is no way to really tell unless we complete vet it out and put cost associations with everything and do PHI leak risk assessments.

That is true. But I think that the technology we currently have to secure communication between clients and webservers (that allows us to do things like buy things online, interact with the bank, file taxes, etc along with client side certificates) should work perfectly well with PHI containing information. The problem is setting up the PKI for that type of communication.

Since governments, universities, and private companies have already done this, there's no reason why hospitals (especially university affiliated hospitals), state boards, and health care providers can't also do this.

Based on that response, I don't think you are understanding how it works (or I didn't explain it well). This is for emails originating from insurance companies.

Software intercepts any queued or targeted outbound email, then:

  1. Replaces the body with a hyperlink to a web site and instructions, removing all PHI.
  2. Hyperlink instructs recipient to login create account / login to view mail over SMTP.
  3. Recipient logs into website (with TLS obviously) and reads email with PHI over secured channel.
  4. Recipient can now read and reply using the website.

Pretty simple. As far as physicians communicating with each other and pharmacies, they typically use faxes and phone calls.

> This is for emails originating from insurance companies.

That was the part I misunderstood. I thought it was for physician offices sending information to the insurance company.

> Pretty simple. As far as physicians communicating with each other and pharmacies, they typically use faxes and phone calls.

And that's an issue that could be addressed if all entities had a PKI set up such that they could communicate online regardless of application protocol used while maintaining compliance with HIPAA).

Yes, if you wanted to extend a nationwide system for any and all PHI communications, your idea would be a good approach.

In a more wonderful world than what we live in today, the US government would have setup a simple, unreadable (even by them) secure channel for everyday citizens to be able to transfer sensitive data to verified businesses and other citizens. They can't see past the criminals using it to subvert the police though.

> In a more wonderful world than what we live in today, the US government would have setup a simple, unreadable (even by them) secure channel for everyday citizens to be able to transfer sensitive data to verified businesses and other citizens.

We pretty much already have that with the PKI system that web browsers (and other programs) check when verifying certificates for various websites we connect to (including this one). It doesn't require government intervention. It does require configuring servers that doctors, pharmacists, hospitals, labs, insurance companies, etc use to authenticate themselves with each other and a number of authorities to verify their identities (like the CA bundle that your web browser uses to verify that the server you connect to is indeed Hackernews and not some rogue entity).

PKI is a powerful tool which certainly can be used in a healthcare setting. Unfortunately, because of organization inertia, it's probably not going to happen (despite the fact that the technology behind it has been around for decades).

>We pretty much already have that with the PKI system that web browsers (and other programs) check when verifying certificates for various websites we connect to (including this one).

As an aside, it took a seismic event (the confirmation of mass government spying) to actually get it implemented properly, and the US government did file a few lawsuits about being able to openly break encryption with a back door. We're fortunate to still have it fully intact.

>It doesn't require government intervention. It does require configuring servers that doctors, pharmacists, hospitals, labs, insurance companies, etc use to authenticate themselves with each other and a number of authorities to verify their identities (like the CA bundle that your web browser uses to verify that the server you connect to is indeed Hackernews and not some rogue entity).

Yes, that's more in line with the solution that we implemented (well paid to have implemented) with the outbound email interception and website redirection. All PHI goes through TLS via the website.

>PKI is a powerful tool which certainly can be used in a healthcare setting. Unfortunately, because of organization inertia, it's probably not going to happen (despite the fact that the technology behind it has been around for decades).

Ironically, they use it heavily in integration from third parties. Their SFTP/FTPS was locked down. They use a login whitelist and PGP signatures for login, everything must be encrypted with asymmetric PGP keys, folders were locked down, the works.

Many of our larger clients requested that all email and fax correspondence go exclusively through those SFTP/FTPS channels. Smaller clients had difficulty handling that on their own and usually had to call in a local support guy eventually.

It certainly happens in the bigger companies. They don't mess around. It's the smaller companies that struggle with it because they don't readily have the expertise.

The Direct Project has an SMTP implementation which allows for emailing medical data in a secure, HIPAA compliant way. http://wiki.directproject.org/SMTP+Implementation+Developmen...

> fax communication is HIPAA-compliant whereas email/SMS are not

I thought that HIPAA had the provision that stated that encrypted communication is compliant. That is, if the email or SMS was encrypted, then it would be in compliance with the act.

FWIW, healthcare compliance is a solved problem (disclaimer: I work for the company that solved it - Datica.com).

The larger problem is that young companies don't understand what it takes to be compliant, nor the resources to do it themselves. Remember, compliance is all about proving what you say you do. If you can prove it, you're golden.

So it's not that SMS or email isn't HIPAA compliant, it's that the work, controls, and monitoring you'd need to put in place to prove compliance is a massive burden. This is where risk management comes into play. If risk isn't a core tenant of your offering, you're better off building the preferred UX (like using email over fax) and assuming no risk.

so ELI5 why we shouldn't just get rid of HIPAA? from the way people talk, all HIPAA does is guarantee that things will always be awful(?) how does HIPAA help if it just keeps us in the past?

It’s also the law that prevents doctors from telling their friends about your hilarious medical conditions, or selling information about you to pharmaceutical companies to market to you directly.

It’s a very thorny law, but it’s like that for a reason.

For the same reason you won't call Uber to take you to the hospital if you cut off your arm.

Aerospace also has high compliance hurdles. But rockets are extremely phallic. Even urology can't beat aerospace on that axis.

And yes, having been in this space for a while, the fax is a great example, a loophole for lawyers, who still do lots of paperwork by fax, because there's case law to support the practice (not the security mind you, just the practice).

Neither the lawyers nor the doctors understand math. Between the two, the lawyers at least took a formal logic course.

Doctors think most of the software they use is just magic, if they think of it at all. The only other association with computers that they have is the IT guy who comes to replace their tower every other year.

Reply on news.ycombinator.com