Are there any HIPAA like technical requirements in EU for developing health related web software? It looks like in the USA developers adhere to HIPAA standards when developing and hosting health-related software. But I can't find anything similar to the EU. GDPR is all about being transparent and asking for consent and there nothing about any technical requirements that I must follow legally. Does that mean I don't need all these expensive HIPAA hosting solutions? And can just get away with a GDPR compliant approach? Maybe, there is another HIPAA like standard for the EU? I'd love to read about it. My goal is to make sure our customers feel safe sharing health-related data with us through our web application. This web application collects some health-related data, stores it and analyses it. Everything will be done through the website (Wordpress based).
In France, one needs to ensure that the medical application respects the Code de la Santé Publique (CSP). https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante (mirror) gives an overview of different CSP laws pertaining to medical data. dispositions relatives aux référentiels de sécurité et d’interopérabilité des données de santé (art. L. 1110-4-1 du CSP) ; dispositions sur l’hébergement des données de santé (art. L. 1111-8 et R. 1111-8-8 et s. du CSP) ; dispositions sur la mise à disposition des données de santé (art. L. 1460-1 et s. du CSP) ; interdiction de procéder à une cession ou à une exploitation commerciale des données de santé (art. L. 1111-8 du CSP, art. L 4113-7 du CSP) Google Translate: provisions relating to the security and interoperability standards for health data (art. L. 1110-4-1 of the CSP); provisions on the hosting of health data (art. L. 1111-8 and R. 1111-8-8 and s. of the CSP); provisions on the provision of health data (art. L. 1460-1 et seq. of the CSP); prohibition to proceed with a transfer or a commercial exploitation of health data (art. L. 1111-8 of the CSP, art. L 4113-7 of the CSP) In my experience living in France and the US, CSP is more strict than HIPAA. E.g. medical professionals in the United States keep selling patient data to commercial, private entities (mirror), which would typically send you straight to jail if you were to do so in France.
The cookie consent requirement comes from the ePrivacy Directive, not from the GDPR. While the GDPR defines consent, cookie consent is required regardless of whether the cookie actually contains personal data. Instead, it says we can access information stored on an end users device under the following circumstances. Technical access to the information is used for the sole purpose of performing a transmission over a network, e.g. using a browser cache. Accessing the information is strictly necessary for providing a service explicitly requested by the user, e.g. session cookies or a consent-declined cookie. The user has given consent to the access, where consent is defined by the GDPR (freely given, informed, specific, …). The first scenario likely doesn't apply because your cookies aren't likely to be “technical storage or access” in the sense of ePrivacy, and because the tracking cookies wouldn't be used for the sole purpose of carrying out a transmission. The second scenario doesn't apply because tracking cookies are not strictly necessary to interact with the webshop, as evidenced by the possibility to opt out. The service explicitly requested by the user is the webshop or website, not the A/B testing. This only leaves consent as possible grounds for storing or accessing information on the user's device. It is already the storing or access that is covered by ePrivacy, not only later use as a persistent identifier. Your suggestion – to first set the cookie and then delete it if it shouldn't have been set – is more compliant than many set-ups I've seen, but is still technically non-compliant. It is also likely to fail in practice under non-ideal network conditions: if the request to see whether GDPR applies times out, or if the user closes the browser tab before the cookie will be deleted, the tracking cookie will remain without consent. I would instead suggest to consider the following points. It seems that by itself, Optimizely Web cannot be used in a compliant manner since it doesn't provide sufficient control over how cookies are managed. Thus, you should avoid loading such tracking scripts unless consent has been given, or unless this processing falls outside of EU/UK law. Currently, you defer loading of tracking scripts until you know if you have to ask for consent. This can be avoided if you always ask for consent :) This can also be avoided if you load the tracking scripts from a server that can independently determine whether the requests comes from the EU. For non-EU requests and for users with opt-in, the server can return the original tracking scripts. Otherwise, the server returns a dummy script. This server can be independent from your website's hosting. By combining the jurisdiction decision with the loading of the script, one roundtrip is saved and latency is reduced. Finally, no one is forcing you to use Shopify, and ePrivacy/GDPR is not required to accommodate their limitations. You do have different choices: use Shopify, at the cost of slow pages and limited A/B tests use a different A/B test provider that can be used without setting cookies use edge computing to do stuff in between of the browser and the original server use a different webshop platform ignore EU laws Well, one of them is clearly unethical. But you do have choices, and which choice you take is a business decision. Slow pageloads and consent banners are likely costing you conversions, but Shopify might be providing massive value that outweighs all that.
Its special personal information The GDPR uses “special” not “sensitive”. Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
HIPAA applies to covered entities Which, broadly speaking are entities that provide health care in the USA regardless of where they might be based. The nationality of the patient is irrelevant.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
Sure, you can make such a request, but its not likely to help you. Scammers are criminals and don't generally care about GDPR compliance. Scammers are criminals, and won't just publish their real world identity. Serving them with a lawsuit will be difficult, especially if they are from outside the EU. GDPR lets you sue data controllers, but it's not worth it. You can sue for compliance (e.g. to compel fulfillment of your access request), and you can sue for damages stemming from GDPR violations. Compared to the damages you have suffered, a lawsuit is very expensive.
The information in telephone books is public. so are postal change-of-address records. So are records of the ownership of real estate. So are vital statistics such as birth records. So are voter registration lists -- i myself purchased a voter registration list (in digital form) for a municipality which showed people's names, addresses, and the years when they voted, when I was a political candidate for local office in NJ. It cost about $100. I believe that many states also make driver's license information available for a fee to marketers. Credit records are available for certain limited purposes, also. No doubt there are other public sources I haven't thought of. If such a site relies on public records, or other publicly available data, it is not illegal. Many such sites offer to remove names on an opt-out basis, but there is no legal requirement that sites do so. This kind of information is not considered nto be "private facts" under US tort law. Aside from opting out, if the sites provide that option, I don't think you have any recourse. One could ask the local legislature to pass a law prohibiting such sites, or making them require consent, similar to the GDPR that the EU has. But I don't know of any such law in the US to date.