It Has Never Been HIPAA Being a Developer In Healthtech
Software is a driving force in pushing improvements in the healthcare sector over the past few years. From improving diagnosis to treating ailments and identifying social determinants of health, software has become the way forward going into 2020.
While these changes are amazing in improving overall quality of life, these advancements to not come without a price. Health tech, as it should, has strict data compliance that we as product designers and developers need to comply to as there is sensitive data involved. In 2018, the Data Protection Act was instated to update data protection laws in the UK which complements the European Data Protection Regulation. This is similar to the HIPAA (Health Insurance Portability and Accountability Act of 1996) which is a United States legislation that provides data privacy and security provisions for safeguarding medical information. Whether you or your company have been asked to build a product for a pharmaceutical company, hospital systems or the NHS and biotech companies, we have made sure to put measures in place in order to comply with the compliance standards put in place and improve the outcome for patience and users overall.
Over time, we have noticed that a number of developers have joined or are planning on building products in the health tech realm in order to make a positive impact for clients and patients. We at Borne have worked with companies in the health tech sector. Here are words of advice we would give developers that are planning of building health tech products and are not sure where to start:
If you are a developer in health tech, you would have heard about HIPAA and GDPR compliance. Compliance with both ensures that your software systems and equipment which contains sensitive healthcare information are carefully monitored and controlled, with access to this information is limited to a set number of authorised individuals.
Things you need to be aware of are:
✔️ Data being disposed of improperly, stolen, lost or not accounted for.
✔️ Hackers compromising data
✔️ Data disclosure without authorisation from the patient
Data protection under GDPR and HIPAA requires knowledge of both non-technical and technical concerns. On the non-technical side, you would need to take new staff on-boarding requirements, incident reporting protocols and password policies that you would need to take into account. On the technical side, you may encounter technical infrastructure requirements and penetration testing to ensure safeguards are adequately put in place.
It is important that employees at every level of the organisation that you work for maintain awareness of phishing scams and ransomware. Emails are disguised as internal comms asking for sensitive information such as passwords or logins that would cause people to click on links that would install this malware. Keep this in mind when you are building and adapting systems so you are always aware of this and prepared for these situations. It is important to remember that GDPR and HIPAA are not temporary checkboxes that you need to tick. They are an protocols that are ongoing that requires maintenance as it is constantly evolving.
Your Users are People Too
It is important to remember that your users of the product are people too. This may seem obvious, but this is particularly important that health-tech end-users are humans that may be particularly vulnerable or in vulnerable situations. Whether your systems that are in development is a program that is in use in a doctor’s office, or your system is powering the machinery that their lives depend on, you are building for a population that may be more likely to have disabilities or be less familiar with tech overall.
With the nature of the product, it is likely that the user did not choose the software that you are building as it was provided to them. For this reason alone, practicing user empathy is vital while building your product. You also need to take accessibility into account during development. If you structure high-quality accessibility standards into the development and design sprints which can set things up for a broad user-base. This is especially important for people that may have motor or visual importance or may have the need for voice tech to access the system you are building.