Close this search box.

Beginner’s Guide: HIPAA Compliance and Software Development


An image of a doctor reading a tablet for a blog about HIPAA compliance and software development.

In 1996, the federal HIPAA law forever changed how the healthcare industry should store, access, and share patient information.

Since then, HIPAA regulations continue to evolve alongside technology. The latest rules extend compliance beyond healthcare providers. It also includes software developers, or any third-party vendor with access to patient data. All organizations need to pay close attention to the security of patient data– or risk the fines and penalties of a violation.

Keep reading to learn how vendors can ensure compliance when developing software used by healthcare providers.

HIPAA Compliance and Software Development

A Crash Course in HIPAA Rules

If you aren’t already, it’s best to familiarize yourself with the HIPAA terms and rules below. Knowing the basics helps you understand how software providers and applications should comply.

Already know the basics? Skip ahead to see what type of software should be compliant.

What is HIPAA?

The Health Insurance Portability and Accountability Act of 1996, also known as HIPAA, is a federal law that required national standards for the use and disclosure of protected health information (PHI). 

Today, HIPAA is regulated by the US Department of Health and Human Services (DHHS) and enforced by the Office for Civil Rights (OCR). 

Through these departments, HIPAA ensures the privacy and security of patient information used by healthcare providers and within their technology.

What is PHI?

Protected health information (PHI) is any information that can be used to identify a patient, including demographic data, test results, insurance info, and more. Common PHI examples are names, phone numbers, social security numbers, IP addresses, and more.

HIPAA regulatory standards also cover ePHI, or PHI that is shared, stored, or accessed electronically.

Who needs to be HIPAA compliant?

HIPAA regulations apply to two groups of organizations.

1. Covered Entities (CE)

This includes any organization that creates, stores, or shares PHI such as healthcare providers, insurance providers, and clearinghouses.

But since 2013, HIPAA was extended to include any vendors that work with covered entities, which are defined as business associates.

2. Business Associates (BA)

An organization that stores, collects, processes, and shares PHI on behalf of a covered entity.

Most software providers, IT vendors, and cloud service providers fall under the BA category, even if they do not deal with patients directly. If you store or transfer PHI, you are required to protect it and can be found liable for any violations.

HIPAA Rules to Know

HIPAA guidelines are defined by a number of regulations such as:

1. HIPAA Privacy Rule

Privacy Rule standards address the use and disclosure of PHI, along with individuals’ rights to understand and control the use of their information.

2. HIPAA Security Rule

Security Rule standards address the secure maintenance, transmission, and handling of ePHI by covered entities and business associates. It includes physical, administrative, and technical subsets for the safety of ePHI (more on that below).

3. HIPAA Breach Notification Rule

Breach Notification Rule standards must be followed by covered entities and business associates in the event of a data breach of PHI or ePHI. Data breaches of any size must be reported to the affected individuals AND HHS, but the protocols differ by the type of breach.

For example, a breach of 500+ people must be reported to HHS in 60 days, but smaller breaches can be reported on an annual basis.


Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 promoted the use of electronic health records by healthcare providers, while also ensuring that both CEs and BAs are enforcing HIPAA compliance like breach notifications.

It also outlines the use of Business Associate Agreements (BAAs), which is a contract executed between covered entities and business associates (or between two BAs) before any PHI or ePHI can be transferred or shared.

5. HIPAA Omnibus Rule

As part of the HITECH Act, the Omnibus Rule mandates that some of the Privacy Rule and all of the Security Rule apply directly to BAs and their subcontractors. It includes provisions around a patient’s right of how their PHI is used in marketing, fundraising, or in exchange for payment.

What Type of Software Should be HIPAA Compliant

Not all apps or software developers that collect or use PHI are required to be HIPAA compliant. See how.

What Should Be Compliant: Any apps or software that are developed by the covered entity for use by patients to collect, store, or use PHI. This can include software such as an online patient portal that stores care plans, test results, and more, whether it was developed in-house or by an outside software developer (considered a BA).

What Doesn’t Have to Be Compliant: In most cases, apps that track health information like your heart rate, BMI, stress levels, and more do NOT fall under HIPAA rules. Even if a doctor recommends one of these apps, it isn’t subject to compliance, IF the app doesn’t transmit data to a healthcare provider.

If you fall under the first category, see below what it means for software providers to be HIPAA compliant.

How Software Providers Can Be HIPAA Compliant

As part of their jobs, software vendors and their employees can come into contact with PHI in several ways. To help businesses maintain and enforce compliance effectively, HIPAA breaks down requirements into three subsets:

  • Physical – Protects the physical security of your offices and equipment where PHI or ePHI may be stored or maintained.
  • Technical – Protects the cybersecurity and ePHI of your business
  • Administrative – Staff members are properly trained to execute the safeguards you have in place

See common examples under each category below. This checklist isn’t exhaustive, but it shows the breadth of HIPAA requirements.

Hacking is the leading case of healthcare data breaches


  • Office security – Can include alarms, security cameras, and secure storage of physical PHI.
  • Device and software control  – Monitored and secured use of devices like workstations, laptops, and software programs that store and use ePHI.


  • Firewalls – Protection against malware, ransomware, and other malicious software
  • Data encryption – Transforms data so it can’t be easily read, which protects it in the case of lost devices or data breaches
  • Data backup – Ensures any ePHI accidently deleted can be recovered or restored
  • Secured Data – Use of secure passwords and password management system for any workstation or applications that store ePHI
  • Disposing Data – Proper way to dump protected data so it’s beyond readability or destroyed permanently


  • Policies, Procedures, Employee Training –  Includes employee background checks and thorough documentation and training on how PHI is handled and accessed within the organization
  • Risk Assessments / Audits – A recurring audit of your current safeguards to reveal any gaps or weaknesses where your organization’s PHI could be at risk
  • Risk Management Strategy – Any identified gaps in risk analysis must be documented and scheduled to be addressed
  • Vendor Management – Document any vendors who you share PHI with and execute BAAs
  • Incident Management – Procedures on how data breaches should be handled

How to Tell if Your Software Provider Is Compliant

Is there a badge or certification that says an organization is HIPAA compliant?

Unfortunately, no.

Companies can spend 2 to 3 years ensuring they’re HIPAA compliant, without one accepted way to prove it.

So if you’re evaluating a software provider like SPARK to work with, here are a few ways to verify their HIPAA compliance.

Do they use a third-party software to audit and verify their compliance?
Some companies turn to third-party software to audit and track their compliance efforts. From this software, the vendor could show you a checklist that verifies what measures they have in place.

Do they execute Business Associate Agreements (BAA)?
As part of the rules, any software vendor transmitting PHI should execute a BAA with the covered entity or another business associate.

What does their risk assessment and mitigation strategy look like?
A vendor should be able to describe in detail how they regularly check for gaps in compliance and what their strategies are for managing them.

Have they worked with PHI and healthcare clients in the past?
Prior experience in handling and securing PHI can show you that the vendor can offer compliance solutions that meet your business standards.

Stay HIPAA Compliant with the Right Software

Today, healthcare tech and HIPAA compliance can seem overwhelming. But you need to keep a close eye on potential new risks, including how your software vendors and subcontractors are handling their own safeguards.

Remember that HIPAA rules are complex and constantly evolving. This article is not a comprehensive guide, so be sure to speak with a professional about your individual business needs.

Looking to develop your own custom healthcare software? Reach out to SPARK and see how we can help!

Contact SPARK Business Works

More from the author

Suzanne Motter
Vice President As a Vice President of SPARK, Suzanne uses her background in IT to lead her team to create tools that streamline business processes and grow their business with thoughtful design. She also serves as Director of Operations to develop, analyze, and execute strategic plans. connect on Linkedin

More Related Articles

black babkgorund with green money sign

Cost of Custom Software Development: How Transparent Process Leads to Accurate Project Estimates

Learn how SPARK goes from a ballpark estimate to an accurate cost estimate for your...

Read More
How to build a SaaS solution with $0 investment

How To Build a SaaS Solution with $0 Investment and a Customer-Centric Approach

Learn how to use a customer-centric approach for building a sucessful SaaS platform with $0...

Read More
A pciture of a computer with tools over top of it

From Burden to Advantage: How to Embrace and Modernize Your Legacy Software

A client recently came to me and said, “We have this legacy software we built....

Read More