Software Engineer’s Guide to Healthcare Projects

Photo by National Cancer Institute on Unsplash

Introduction

Throughout my career as a software engineer, I have had the opportunity to work on a number of projects in a few different industries — including education, media, civic tech, and healthcare.

While the technical skills we, software developers, acquire over the years are quite transferable, every project is a new set of challenges — because a lot of things change. To be able to deliver maximum value, in addition to our technical expertise, we need to have some domain knowledge. We need to “feel” the business of a client, and have a general understanding of the industry we operate in.

When it comes to the industry-related domain knowledge, I have found the healthcare industry to have a learning curve steeper than others. There is often a lot of red tape involved, a number of terms to understand, complex procedures to follow, and requirements to meet.

I have learned a few things since I started working on my first healthcare project, and I would like to share them with you — who might be at the beginning of the journey into the challenging (but very rewarding!) world of healthcare software.

If you are a software developer who is considering, or is about to start working on a project in the healthcare industry, I hope this will be a good primer. I am going to explain some of the concepts and terms, and share some insights so you can hit the ground running without feeling lost during your first months.

Important aspects

We will discuss a couple of areas that we need to pay special attention to in projects in the medical space. Our main points of discussion will be:

• Regulations and compliance,
• Data security considerations,
• Reliability of systems, and
• Healthcare projects’ impact and potential.

Let’s take it from the top!

Regulations and compliance

Healthcare is one of the most heavily regulated industries, and it is so for a reason. It lives on the intersection of:

• significant and widespread impact,
• huge risks (both for individuals and the society), and
• massive amounts of money.

One of the first things that you notice entering this world is that regulations, standards, and operating procedures are taken very seriously. Of course regulations vary from country to country — here we will be talking about the U.S. — but I believe this general point stands true everywhere.

HIPAA

When it comes to software projects in this space in the U.S., almost everything is heavily influenced by the Health Insurance Portability and Accountability Act. You will probably hear the term HIPAA thrown around a lot.

The goal of HIPAA is to establish standards and requirements that institutions need to comply with if they work with medical information. The idea is to keep modernizing the medical space, but avoid fraud and theft at the same time.

There are three areas that HIPAA aims to regulate in its “rules”:

1. The Privacy Rule — specifies when and how health data (PHI; see below) may be used and disclosed,
2. The Security Rule — sets security standards for technology that needs to be implemented to protect that data, and
3. The Breach Notification Rule — specifies rules for notifying individuals and other parties about potential health data disclosures.

To read more about the HIPAA in general, please head over to this primer from Travis Good of Datica, or this one, prepared by Stanford.

Most of the subjects we discuss here are practical implications of, or are at least related to HIPAA.

PHI

Another term that is widely used by healthcare professionals is PHI, which stands for Protected Health Information. In its Privacy Rule, HIPAA regulates what constitutes PHI, and the requirements that must be met when handling that data of sensitive nature.

While PHI describes mainly physical records, ePHI is the term used to describe PHI that is being created/stored/transmitted electronically, so that is our primary point of focus here.

Long story short, you need to be very careful with data that is considered PHI. We will talk about best practices around handling such data in more detail later. For now, let’s go through a list of data points that might constitute PHI. Having this awareness will hopefully raise a flag when you need to change the way those data points are stored, handled, or exposed.

For information to be considered PHI, it needs to meet two criteria:

• relate to the health status of an individual that is created/stored/transmitted by a HIPAA-covered entity, and
• make it possible to identify that individual.

There are a lot of data points that, when linked to health records, constitute PHI — including:

• names of patients,
• email addresses,
• geographic locations (more “specific” than a state),
• dates of birth,
• telephone numbers,
• social security numbers,
• … and more.

You can find a more comprehensive list of sensitive data points here or here.

HIPAA BAA

One more regulation introduced by HIPAA is related to cooperation between institutions working with medical information, and their business partners.

If the institution wants to use third-party providers’ solutions to work with medical data, it needs to sign a BAA — Business Associate Agreement — with them. Some of the areas that the BAAs typically cover are: type of PHI being handled, data lifecycle events, restrictions on services’ usage, etc.

For example, if the institution wants to store medical data in the cloud — be it AWS, GCP, or Azure — it needs to sign a BAA with Amazon, Google, or Microsoft. If your company sells a product that utilizes PHI from an entity “covered” by HIPAA, it will most likely need to have a BAA signed with that entity.

The practical implication for us, software professionals working on systems handling PHI, is that integrating with third party tools and platforms is not only a question of technical feasibility — it is also a legal one. We need to make sure all the boxes are checked before we start sending PHI anywhere, even to services we personally know and trust.

Security

Most of the regulations described above are put in place to make sure that medical data, which might include some of the most intimate details of our lives, is protected and handled with utmost caution.

Providers of software in the healthcare industry need to follow best practices when it comes to security of their solutions. Carelessness in that area may have serious consequences — data leakages, financial penalties, and even criminal charges.

There are a few aspects to keep in mind when designing software systems for security. We will not go into much detail; entire books have been written on each of these areas. However, it may be useful to list some practices and techniques that can lower the risk — and consequences — of potential vulnerabilities.

Data storage

If we need to store medical data, especially including PHI, we need to make sure that it is protected from threats like data loss (caused by e.g. software bugs, hardware failures, power outages), data breaches (caused by careless staff, external malicious actors, etc.), and others.

The list of the practices that we may want to use to prevent these includes:

• Data storage redundancy,
• Data backups,
• Encryption at rest,
• Data retention policies,
• Data immutability techniques (avoiding altering data).

If you are interested in reading more about data storage best practices, head over to the articles on eSecurity Planet or Enterprise Storage Forum.

Data transfer

The software systems we build often need to integrate with external entities and applications. Even if we don’t integrate with external systems, chances are that our systems comprise of multiple, interrelated components. Some of these integrations might be used to send sensitive data — over various communication protocols. To ensure that data is not intercepted or tampered with in transit, you should consider employing the following practices:

• Authentication for APIs etc.,
• End-to-end encryption,
• Firewalls, Private Networks, VPNs,
• IP whitelisting,
• Auditing and end-to-end communication monitoring,
• Automated data transfer workflows.

Data processing — server and application security

If we are confident that data is stored using all the best practices, and is always transferred securely, we need to make sure there is nothing within our system’s environment that could increase the risk of data breaches. There are a few techniques we can, or should use here:

• Regular vulnerability patches for our servers,
• Regular patches and updates for frameworks and external libraries,
• Access control mechanisms for infrastructure,
• Application vulnerability scanning.

You can read more on security measures for servers in this piece by DigitalOcean.

Data access

Now that we know that we have a safe environment to run our software and store data, we need to make sure that our software itself is secure. One of the most important requirement is to only give authorized users access to the data in our system. To do that, we need to implement:

• Secure authentication — industry standard Single Sign-On solutions are best; it’s rarely a good idea to build your own authentication logic,
• Multi-factor authentication mechanism,
• Robust access control system — defaulting to the “least privilege” rule,
• Audit trail — to make sure we know exactly what happened in case of suspicious activities,

You can find more information about access control best practices in this article on Help Net Security.

Reliability

Software systems (especially in the healthcare industry) need to collect, store, and process data in a safe manner. This is not the only thing to keep in mind, though. As application developers, we need to be aware that systems we work with can affect people’s health and life — especially if they don’t work.

Of course, a booking system for small orthopedic clinics is not a safety-critical system but we can easily imagine how a failure of a ECG device can put someone’s life in danger.

Because of that, we need to make sure that critical systems like that adhere to highest standards of availability and reliability.

We will not go in detail into best practices for developing safety-critical systems here, but there are a few areas worth exploring:

• Software development practices: code reviews, extensive testing, code coverage metrics,
• Data loss prevention: data immutability, regular backups, data fingerprinting, etc.
• Infrastructure and deployment automation,
• Logging: extensive, but omitting sensitive data,
• Infrastructure monitoring,
• Reliable error reporting,
• Chaos engineering.

Impact

As we have seen, bringing a new software system to market is a process that requires a lot of consideration, effort, and caution. With all the challenges, however, comes a number of unique opportunities.

The medical space, for one, is full of initiatives that have a genuinely positive impact on the world. If you want to work on projects that improve (or even save!) people’s lives, you are more likely to find those in the healthcare industry than, say, entertainment. Examples abound: you could be working on bringing drugs to market faster, fighting neurodegenerative diseases, responding to the COVID-19 crisis, and many more!

Even if the project you are (or would be) working on is not on the bleeding edge of medical science, chances are it is either:

• Helping (possibly overworked) medical professionals do their job better and save time, or
• Improving patient experience in (typically stressful) life situations related to their health, or
• Making the complex world of healthcare more effective in general.

Given the importance of medical sciences in our lives and societies, it is easy to see how even seemingly trivial initiatives in this space have a chance of making the world a better place.

There is something in it for you, too!

Working on healthcare projects might not only be rewarding, but it can also be a great experience for your professional career.

You would be hard pressed to find an industry that puts more emphasis on quality (and risk avoidance!). A project related to healthcare might therefore be a great place for you to learn and use best practices from many different areas of software development.

Often, the amount of information processed by healthcare systems require innovative approaches to data processing. Uniqueness and novelty of challenges sometimes calls for interesting (e.g. machine learning-based) approaches. The research-related nature of some projects might expose you to new, interesting areas and technologies (IoT, AI, etc.).

Even if you don’t end up saving people’s lives, you might be in for an eye-opening and challenging experience that will make you a better software professional.

Summary

Hopefully by now, you have a better understanding of some of the aspects of software projects that are unique to the healthcare industry.

There is a lot of new domain knowledge to acquire and complexities to understand. Now you know where to start and what to look out for.

Projects in the healthcare space can be challenging, for sure — but they might be the most rewarding and interesting experiences you can gather. Have fun, and I hope you will help save people’s lives and make the world a better place!