The Details of GDPR and HIPAA Certification
Conducting legal business means compliance with all regulations of the region in which you work. For example, gathering, storing, or processing the personal information of EU residents, requires following all the GDPR privacy regulations.
The healthcare sector in the USA adheres to HIPAA federal laws. At Go Wombat, we pay particular attention to the compliance of the software we create with appropriate regulations, depending on the geographic region.
This article will provide some insight into HIPAA, and more specifically, how we ensure the compliance of the created software with GDPR.
Health Insurance Portability and Accountability Act is the US federal law that describes rules of medical information exchange, and its protection from unauthorised use. The law was adopted in 1996 and applies to hospitals, doctors’ offices, and other establishments where patient information is collected, or where healthcare services are provided. It applies to both paper and electronic information.
The law specifies only people involved in the healthcare sector, or those specifically designated, are allowed to see this information. HIPAA is based on two essential principles of patient care: privacy and confidentiality.
Privacy implies that any individual has the right to restrict access to their medical information. Confidentiality means that healthcare specialists must keep the information correctly and make every effort to prevent unauthorised third-party access. The data cannot be disclosed without a patient's consent, except for cases when it is required under law or for specific clinical reasons.
Not limited to the healthcare sector, GDPR is a data protection law that covers all sectors, including healthcare. GDPR is an international law that became enforceable on 25 May 2018. Although it was adopted in the EU, it covers all countries that work with the personal data of EU residents, including foreign citizens.
The law provides the protection of the user data on the Internet, regulating the transfer, processing, and storage of personal data of each individual who is located on the EU territory, or an EU citizen. This has been a point of focus for the newly emerging technology 'Internet of Things' (IoT) and Internet of Behaviour' (IoB). This collection of data has developed into what is known as Big Data and is used to better understand both current and potential customers. These two elements are strongly linked with personal data and the analysis of data collection. The international status allows extending the law not only within the EU territory. If the entity uses resources within the EU territory or the individual is an EU citizen, but he or she is located in any other region — they are still subject to the law, and subsequently protected.
It means that all US organisations that process, gather, or store the personal information of EU residents must follow the GDPR law.
It is crucial to identify what personal data means since GDPR protects all personal data, not only anonymous ones. According to GDPR, personal data is any information related to the data subject (individual) that can be identified. An identified individual is a person that has an identifier (name, phone number, login, email, ID, etc.).
Thus, any entity that performs specific operations in the EU, offers goods or services to people in the EU, or monitors the behaviour of EU residents must comply with all the GDPR rules.
Compliance with local regulations is not only legal, but it is also crucial. Contact us to get detailed consulting services!
Even though both laws protect personal information, GDPR is a much broader law than HIPAA. Furthermore, GDPR more strictly applies to personal information protection. So let’s take a closer look at the three main differences between HIPAA and GDPR.
According to HIPAA, some PHI (personal health information) can be disclosed without the patient's consent. For example, under HIPAA, healthcare organisations can send PHI to other healthcare providers for treatment purposes. Also, in case of emergencies (urgent surgical procedures.), healthcare providers may disclose PHI without patient consent.
Under GDPR, any PHI cannot be disclosed without explicit patient consent. The same applies to any marketing and communication activities between the healthcare provider and the data subject.
This right is available under GDPR, while HIPAA doesn’t contain this rule. It means that any user may request your company/organisation to erase their personal data.
Unfortunately, a data breach is a severe problem that should be considered when businesses process confidential data. The HIPAA Breach Notification Rule stipulates that all healthcare providers must notify individuals if their unsecured PHI is breached. If more than 500 individuals were affected, it is also required to notify the OCR (Office Of Civil Rights) of the U.S. Department of Health & Human Services within 60 days. In case of more minor breaches, it is necessary to notify the OCR by March 1 of the following year.
Under GDPR, all companies must notify the regulatory body about the data breach within 72 hours, regardless of the number of affected individuals.
As Go Wombat is a software development company, we work extensively with clients from Europe. This means it is vital to ensure that all relevant projects we create comply with the GDPR guidelines.
At Go Wombat, we have a CISO (Chief Information Security Officer) responsible for the software compliance process and is a certified DPO as well.
The Data Protection Officer is a specialist in charge of carrying out regular security audits, training employees, and monitoring compliance with the GDPR rules.
The main task of the DPO is to ensure that all sensitive information is protected adequately from unauthorised access. Furthermore, if the company violates the process of gathering and processing personal data, the DPO must notify the supervisory authority about it.
The DPO is fully qualified to ensure compliance with the GDPR. At Go Wombat, we develop our specialists and our CISO has completed thorough training and obtained full DPO certification.
Having defined the project type, our DPO specialist identifies what personal data can be used. Once the data has been identified, the DPO draws up the scope of use for any personal data. This is then tested by conducting a data protection impact assessment, resulting in the creation of a matrix of responsibilities. Finally, when the project is developed, the DPO verifies everything to make sure that all personal data is processed and transferred (or not transferred) correctly.
Most projects we create work with personal data since even email is referred to as personal data.
Our specialists analyse what PII (Personally Identifiable Information) we receive, and then it is necessary to study all the requirements.
Our next step is to follow Article 32 under the GDPR, which stipulates the use of technical measures to protect personal information. These measures include many stages, but the most critical ones are anonymisation and encryption.
Anonymised data cannot be identified without supply data or key tables. Separated usernames can be an excellent example of anonymised data. Usernames are stored in a separate database to avoid the comparison of a username with an email address.
We follow the best option, which means the creation of UUIDs (Universally Unique Identifier) that each user has. UUID is a range of digits, so there is no name or surname, each user has its own UUID making it impossible to identify the user without the table containing user data.
This is a process of storing data securely that cannot be read without a supplied key or master key. One of the best ways to ensure this is to use RDS (Related Database System) from AWS in the European region. That’s what we do at Go Wombat.
According to Article 32, AWS RDS allows us to ensure that encryption keys and databases are stored on different servers. So if there is a database leakage, but there are no keys — it is impossible to do something with a database. So RDS makes it possible to store everything separately.
Then, the following mandatory step includes creating recovery points in case of any unforeseen incidents. We enforce backup systems to ensure the stable performance of the software. For example, if the system is down due to a DDoS attack, a recovery point enables the restoration of regular functionality, so users have uninterrupted access to the software.
We must monitor all personal data transfers, and we need to know when and where all data were used. We log all accesses and users’ activities with the help of AWS CloudWatch.
As we have mentioned, according to GDPR, each user has the right to be forgotten, so we should have all activities in one place to delete them upon request. Logs turn into anonymous UUIDs, and PII is not used anymore.
Under GDPR, we need to ensure secure data transfer, so we use SSL protocols (Secure Socket Layer) to encrypt the data transferred between resources.
The last but certainly not least step we must follow is to build a strict access system to personal data. We never work directly with personal data during development. Instead, we create blank tables and populate them with random data to test them.
It is crucial since we aim to secure confidential data and avoid any disclosures. Therefore, we do not use personal data unless we need it for specific reasons or bug fixing, but that must be agreed upon with a controller.
For example, here is an insight into one project we created where GDPR and HIPAA rules were applied. The project goal is to store patients’ records and health conditions. Physicians can update patients’ status, and keep information on appointments, procedures, or prescriptions.
Also, the system can synchronise to remote sensors and receive real-time information about saturation, glucose level, heart rate, and other indicators.
We used Amazon services compliant with HIPAA and GDPR. The first is RDS (mentioned above), where we had our database with enabled data duplication and encryption.
The second service is AWS Cognito. It was used for registration/authorisation, and it keeps users’ passwords and access tokens. (An access token is used in place of specific personal information when regular repeated access is required. This token is a form of a password and is used in case of a breach. This ensures the integrity of personal information. This form of the process is covered within our Articles on** Cybersecurity** and Integration of APIs)
Additionally, we implemented data anonymisation on the server at the users’ request. Different time intervals are determined for data storage and anonymisation, so data are not deleted immediately — their deletion is performed depending on HIPAA requirements.
Go Wombat does its best to ensure the compliance of projects being developed with GDPR, HIPAA, and any other regulations. Our CISO is continuously developing his skills, working on cybersecurity issues, making new software more secure, and preventing data leakage.
We also have a recent article on cybersecurity and the importance of this. Click here for further interesting insights.
Now you have a better understanding of we follow GDPR compliance since the integrity and security of created software is our reputation. If you are still hesitant and have any questions — feel free to ask us.
Contact us to find out more about project security!
- What do they do and how important are HIPAA and GDPR?
- What GDPR and HIPAA Do
- What Key Differences do GDPR and HIPAA Have?
- How We Follow GDPR When Creating Software
- The scope of activity of the Data Protection Officer at Go Wombat
- The Process Of Technical Compliance of GDPR At Go Wombat
- Expertise Of Go Wombat: Healthcare Project
- Drawing The Line