That’s a pretty broad set of questions.
1 Can a case be made for added asymmetric + symmetric encryption of
data in transit over TLS v1.3?
According to what you wrote, at the very least either end-to-end encryption or hybrid encryption is required for data in transit. But even if you plan on using end-to-end encryption, it’d be questioned if you didn’t use TLS 1.2 or stronger anyway. End-to-end raises questions of secure key management in the client. Do you really want to risk distributing copies of your long-term storage keys to your clients?
2 Can PHI be stored anonymously somehow so we can analyze it and opt
out of explicit encryption? That necessitates handling/control logic
of that data to be in client apps.
Take a look at homomorphic encryption. It’s a way that allows you to perform some processes on encrypted data that returns the same results you’d get from processing the data on the clear text. It might remove the need to handle secret keys in your analytic logic.
3 Can we have permanently assigned, unchanging asymmetric keys for
users? If not, for how long can we have them safely? How do these
changing keys work with already encrypted data?
Generally you’d issue clients their asymmetric keys on a client certificate, and set the certificate to expire in a timeframe that meets your organization’s key rotation policies and requirements. That might be one year, sixty days, or whatever. You wouldn’t use those asymmetric keys to encrypt the data for long term storage, however; you’d use them only for mutual TLS authentication, establishing session keys for the duration of the connection. You’d transmit the data via the TLS-encrypted socket; then at the server you’d encrypt the data with your server’s secret key (a key no client would ever access to.)
Your service would most likely be responsible for managing its own secret keys. Some systems will tag each encrypted data element with a key identifier that can be used to find the proper decryption key when it comes time to read the data. That way, you can rotate the server’s secret encryption key on a schedule so that a new key is used every month, or every year, and will still be able to decrypt all your old data. This avoids the huge risks associated with decrypting and re-encrypting all the data every year. (This same approach can also be performed using a commercial key management system, in conjunction with a client-side encryption library.)
Of course all these are only some possible suggestions; they are in use in some organizations, but may or may not be suitable for your organization or your data. Check with your compliance team, your risk management team, your security auditors, or whoever your organization uses to approve such decisions.
