Thoughtful HIPAA

Originally posted on Skiplist blog

HIPAA compliance is an intimidating road that must be traversed for any organization that has aspirations of breaking into any part of the medical domain. Skiplist can show you how to thoughtfully traverse the technical side of this path.

Let your product earn its complexity.

We stand up a HIPAA compliant walking skeleton, with zero cost of ownership, the day of project kickoff. As a result, you focus on developing the customer value driving features of the product, not compliance!

Organizational Context

First and foremost, while implementing the necessary Security Standards, keep in mind that flexibility of approach and reasonably and appropriately implement are explicitly written into the law.

In deciding which security measures to use, a covered entity or business associate must take into account the following factors:

• The size, complexity, and capabilities of the covered entity or business associate.
• The covered entity's or the business associate's technical infrastructure, hardware, and software security capabilities.
• The costs of security measures.
• The probability and criticality of potential risks to electronic protected health information.

This means the context of the organization and the sensitivity of the data matters. For a fledgling startup creating an MVP with little or no customers, a data policy that dictates manual backups at a regular basis is an acceptable solution. In contrast, an organization the size of the Cleveland Clinic, requires a rigorous automatic approach to the same data policy.

HIPAA Overview

General Administrative Requirements (160) and Administrative Requirements (162)

Regardless of technology choices, Parts 160 and 162 are necessary domain specific administrative overhead (Muda Type 1) that will need to be filled out by your organization.

A general template is a great starting point to help cover these bases. If your context requires specific templates, there are a great many examples available to pull from (Google search "HIPPA document template").

Security and Privacy (164)

Part 164 consists of six relevant subsections: § 164.306 Security standards, § 164.308 Administrative safeguards, § 164.310 Physical safeguards, § 164.312 Technical safeguards, § 164.314 Organizational requirements, and § 164.316 Policies and procedures and documentation requirements. The organizational policies for 306, 308, 310, 312, and 316 should be determined prior to beginning implementation of § 164.312 Technical Safeguards in your product software. If not, assume the system will accrue a significant amount of technical debt.

As an example, § 164.308(5)(D) Password management: "(Addressable). Procedures for creating, changing, and safeguarding passwords." A thoughtful approach is for an organization to have an existing password policy in place before software development begins. A policy to manually reset all passwords every 90 days, will allow much faster speed to market (at an operational cost of course). In comparison, deciding early to implement a two factor authentication service (please don't write your own) could extend an already volatile product timeline (YAGNI).

Summary: § 164.312 Technical Safeguards

Partitioning HIPAA compliant infrastructure simplifies overall system architecture. Ephemeral virtual machines and logs, lend us to only encrypt the database at rest per compliance requirements. The technical stack and details of the following policy are listed after. The following technical safeguards only apply to the api system, its datastore(s), and access log aggregator.

Sample Technical Safeguards Policy

Access control:

• (i) Unique user identification (Required)

  • Each user within the platform is assigned a unique id upon creation.
  • Each user within the platform has unique login credentials.

• (ii) Emergency access procedure (Required)

  • Persistent data for the platform can be accessed using secured database credentials. Logs can be reviewed in the aggregate logging platform. The application server does not allow external access.
  • Audit control information can be retrieved via aggregate logging functionality built into the platform.

• (iii) Automatic logoff (Addressable)

  • The platform User authentication key is invalidated after 30 minutes of inactivity

• (iv) Encryption and decryption (Addressable)

  • The platform supports and uses SSL encryption for all requests

Audit controls:

• Each request for data in the platform is logged with the requesting user identifiable. Log aggregation utilized to allow for historical review.

Integrity:

• Modifications to any records are stored in an audit log containing previous and new values along with the unique user identified.

Person or entity authentication:

• The platform implements verified authentication by requiring a user to be associated with a known good email address.

Transmission security:

• (i) Integrity controls (Addressable)

  • No unauthorized access to the database is permissible outside of procedures defined within the “Security management process”. Updates through the application are recorded using the operations log.

• (ii) Encryption controls (Addressable)

  • User credentials are stored using a one way hash.
  • The database that contains patient information is encrypted at rest

Sample Technical Stack

• User management via Auth0
• JWT Token Based Authentication
• ReactJS Front End Hosted on Netlify
• Python Eve on Heroku
• Heroku Postgres

Earn Your Complexity

The suggested technical stack allows the development of HIPAA compliant application that easily grows with your organization. Utilizing Heroku, the platform hooks (audit log) in the Eve, and logging aggregation, a thoughtful approach creates a flexible HIPAA compliant platform in less than a few thousand lines of code.

Let Skiplist help you earn your complexity by discover your product on a totally zero cost of ownership platform.

As you gain “size, complexity, and capabilities” (i.e. customers), let the platform scale to any number of beefy isolated horizontally scalable nodes, while you focus on product market fit, not compliance.

This is your competitive advantage!

Cheers,

Justin Beall