I know that companies would never do this but I will suggest it anyway. Don't store customer data. Instead, cache a copy of the customers encrypted blob in th

I know that companies would never do this but I will suggest it anyway. Don't store customer data. Instead, cache a copy of the customers encrypted blob in the customers client side application. Customer sets the TTL for their cache to expire. The customer and only the customer may decrypt the data. If they wish to share their data with a health practitioner then they can screen share. If the government want this data, they will have to subpoena every individual customer. No lawful intercept. No intentionally weak frameworks. No "Oops we stored this in an unsecured S3". Just put the data and decryption keys under full control of the hands of the customers. Forward NSL's and subpoenas to the customers. Data retention policies are entirely up to the customer at this point. Create a disclaimer that explains it is on the customer to back up their data and/or decryption keys. If the keys are lost, just start over with a blank slate, or manually put in some stats from a customers copy of a printed report. One could probably even compress/encode the data in a way that a customers printed copy could be ingested into a program to re-encrypt and store it. QRCodes, Dots, etc... One argument against this would be that a company can't run reports on all their customers, use machine learning, etc... to which I say, "Good, cease and desist treating customers like cattle." If there are specific data points that a company wish to gather from its customer base, send a beacon to customers that would ask them if they wish to volunteer this specific data and make it painfully clear who will have access and for how long and how the data will be anonymized. Before a customer clicks "Send" they get a highly detailed display of what exactly is being shared in easily human readable format.