If you or your clients are working with patient information in the United States, you are likely already familiar with the
Health Insurance Portability and Accountability Act (HIPAA).
HIPAA strictly regulates the transmission of Protected Health Information (PHI). PHI is similar to
Protected Personal Information (PPI), a topic we discuss often in relation to global privacy laws like the
General Data Protection Regulation (GDPR) in Europe or local laws like the
Colorado Privacy Act in our own home state. However, unlike PPI, PHI is regulated federally in the United States and includes more topics like plan numbers, dates, and, of course, medical diagnoses or other related health information.
The
University of Colorado in Denver shares 18 common identifiers that may constitute PHI, but understand that this list isn’t comprehensive. A good rule of thumb is that if the data can
be traced back to a particular patient, it’s PHI. Their list includes, verbatim:
- Names;
- All geographical subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code, if according to the current publicly available data from the Bureau of the Census: (1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and (2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000;
- All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
- Telephone numbers;
- Fax numbers;
- E-mail addresses;
- Social Security numbers;
- Medical records numbers;
- Health plan beneficiary numbers;
- Account numbers;
- Certificate/license numbers;
- Vehicle identifiers and serial numbers, including license plates;
- Device identifiers and serial numbers;
- Web Universal Resource Locators (URLs);
- Internet Protocol (IP) address numbers;
- Biometric identifiers (including finger and voice prints);
- Full face photographic images and any comparable images; and,
- Any other unique identifying number, characteristic, or code (with some exceptions and requirements).
HIPAA compliance can be a major source of anxiety for web professionals. So much so that many agencies in particular won’t even bother taking any medical clients out of an over-abundance of caution. If that sounds like you, I’ve got some good news—you are more than capable of creating great websites for medical practitioners. That’s because, and I may be getting ahead of myself a little here, there really is no such thing as a “HIPAA compliant website.”
What HIPAA is, and what it isn’t
At its core, HIPAA is a form of
privacy regulation. However, unlike generalized regulations like the
Colorado Privacy Act or the
European Union’s GDPR, HIPAA is narrowly tailored towards protecting patient data. Whether or not HIPAA applies to you, then, depends upon where you lie on the “chain of liability.”
The chain of liability is a metaphor that describes how compliance requirements flow through the various actors interacting with patient data. Doctors, medical systems, and insurers all exist on the chain—for obvious reasons. They interact with that data directly, and may even originate it. Under HIPAA, these links on the chain are known as “covered entities,” because they’re directly covered by HIPAA.
However, doctors aren’t the only ones who may interact with patient data. Intermediates, like cloud storage providers, IT contractors, and billing networks, may, in some capacity or another, find themselves exposed to patient data. These entities are referred to as “business associates." Unlike covered entities, business associates are tangential to the administration of care, yet they still interact with PHI.
Agencies are not inherently business associates—although, if they aren’t careful, they certainly could be.
Imagine that an agency has contracted with a dermatologist in Boulder, CO to create a beautiful new patient-facing website advertising their services. This agency creates a brochure-style website full of interesting copy, stock photos, and contact information, but no interactive elements. Since this website doesn’t, in any way, collect or store PHI, the agency who created it would not be classified as a business associate under HIPAA.
Now, what if a competing agency in Denver, CO contracted with a different dermatologist to create a more interactive website. Theirs is in many ways similar to the website the Boulder agency created, except it includes one small addition; a contact form. The inclusion of this form exposes the agency to PHI, linking them to the chain of liability. It also links their form processor to the chain, a serious liability if the form isn’t explicitly HIPAA compliant.
This singular focus on healthcare information is what separates HIPAA from other privacy laws. The Boulder agency may use analytic software on their website, or may employ a website builder that includes embedded analytic tools, but that doesn’t matter.
Current HHS guidance differentiates between “authenticated” and “unathenticated” traffic; meaning an IP address alone isn’t identifiable enough to fall under HIPAA purview. The data needs to connect a person to their PHI.
That’s why websites themselves shouldn’t be a concern when considering HIPAA compliance. It’s the interactive elements, and the processors behind those elements, who may or may not be compliant. Think forms, questionnaires, payment processors, scheduling tools, etc. The website itself? Not so much.
That doesn’t mean you’re in the clear, though. Customers, including patients,
expect interactivity from their websites. SMBs do too.
In a survey we conducted last year, 88% of SMBs desired some kind of direct integration between their website and backend software. So, how can you offer the experiences your customers, and their customers, expect without linking yourself to the chain of liability?
Oh iframes, my beloved
One of the most popular, and underrated, technologies in the world of compliance is the
iframe. This is a technology you’re undoubtedly familiar with. If you’ve ever embedded anything, from a Youtube video to a
Google Maps element, you’ve used an iframe.
What makes this technology so popular in the world of compliance is their ability to
sandbox data. Without getting too technical, essentially a website cannot view, modify, or manipulate the contents of an iframe. Stripe, a leading payment processor, uses this to create a
PCI compliant environment within a website without the entire webserver needing to be PCI compliant. This works because the card information entered into the iframe isn’t accessible to the website in any capacity.
Many third-party software providers offer HIPAA compliant solutions using the same fundamental technology.
Jotform, for instance, offers HIPAA compliant forms that can be embedded onto websites via an iframe. So long as the website itself isn’t collecting any PHI, then the coast is clear.
Other website owners simply link off from the marketing front-end to a back-end technology, like Epic’s ever-so-popular MyChart portal.
SaaS companies integrating Duda into their solution can leverage this flow as well by creating custom widgets that use iframes to deliver their technology to client websites. However, those clients should not use Duda’s first-party forms, as the backend is
not HIPAA compliant.
Do I need to worry about HIPAA compliance?
If you’re an agency building websites for medical professionals, you should be aware of HIPAA but you shouldn’t worry about it. It’s easy to avoid exposure to PHI by simply refusing to accept it. Include specific language in your client contract that you are not responsible for PHI, and communicate clearly with your clients that they are responsible for the management of any patient data. You can recommend HIPAA compliant software, but do not retain any login information for that software.
SaaS companies should absolutely concern themselves with HIPAA, but not in regards to their clients' websites. They should instead embed their own HIPAA compliant technologies into the website builder via custom widgets, ensuring a seamless, low-stress experience for their customers.
Remember, PHI needs to be both safe and secure. The easiest way for an agency to ensure that is by not collecting that data at all.
