Electronic Health Reporter

Guest post by Lucas Vogel, principal consultant, Endpoint Systems.

Imagine being a software developer at a company where your job description involves building HIPAA-compliant apps and services. As you onboard with your new company, you receive some formal basic training and learn about the privacy, security and breach notification rules, and after some additional training on various topics about your job, you enter your department and get acquainted with your work environment. This is the point where you find out what you’re really getting yourself into.

There is a direct correlation between the maturity level of applications developed in your organization and the quality of your work life. For example, if you walk into a developer role for a healthcare provider, you’re likely walking into a large and well-established IT group with many old and new technology platforms deployed, where you’ll take your place with a department that’s existed for several years and does fairly predictable work on prebuilt systems. But let’s say you’re working at the more cutting edge of healthcare technology, at a startup straddling innovation with compliance. In that case, understanding HIPAA compliance can feel incredibly daunting, especially as you may essentially be learning as you go with little guidance.

The good news is that it’s never been a better time to work on HIPAA-compliant healthcare apps. Advances in identity and access management (IAM) and consent frameworks make it easier for apps to authenticate, authorize and audit users, logging who is performing what within your application; advances in machine learning make it easier to parse these log streams, detecting threats and anomalies to application use, among other countless benefits. Further advances in application architecture, cloud and API technologies, database and container platforms (not to mention containerized database platforms), and development methodologies over the past decade have dramatically changed the way companies build applications and deploy platforms, culminating in what is known as the “twelve-factor application.”

A twelve-factor application is a software-as-a-service (SaaS) app with the following fundamental characteristics:

• Leveraging declarative formats for setup automation
• A clean contract with the underlying OS, offering maximum portability
• Suitable for deployment on cloud platforms, minimizing the need for infrastructure and administration
• Minimal divergence between development and production, enabling continuous deployment and maximum agility
• Scalability with minimal change

As the name suggests, there are twelve different factors tied to an application to make this work, such as dev/prod parity, logging, and port binding. What’s important about the twelve-factor application, and why it matters when it comes to HIPAA, is that it gives developers the flexibility and the separation of concerns that allows them to focus on the ‘software factory’, a combination of development and environment has the greatest potential to allow for developer freedom – and focus.

But twelve factors aren’t enough for your HIPAA application, and it becomes necessary to consider a thirteenth factor. The single most critical component to building high-quality HIPAA compliant applications is having high quality test data for testing your application. This includes the critical PHI you may be storing in one of more systems in your apps.

Let’s say you’re a specialized care company, and your business involves the management of data from the major healthcare providers; you have everyone from Aetna to Zorgverzekering sending you EDI data every month containing subscriber data and details. You are part of the team dispatched to handle the intake of this EDI data, absorb it into your company’s data platform(s), and integrate it with several different internal systems. Each piece of EDI data you receive from your customers (the healthcare providers) comes with PDFs detailing all the special requirements each provider has regarding their EDI data. To make matters even more precarious (for you), some of your customers change their data fields and requirements as their businesses evolve and change.

The worst time to find out that your team didn’t plan for data disparity is in your production environment where your attempt to absorb their production data backfires on you, and you need to quickly turn around a fix. For developers and managers alike, this is your worst nightmare, because you need to test before you deploy, and if you ran into this error at this point in the process, it means your process is in dire need of improvement. It is at this precise moment where IT companies find themselves in a moment of weakness where they consider putting their PHI at risk.

Generating test data can be frustrating and time-consuming; fortunately, there are sites like GenerateData.com and the Faker-CS project on GitHub to help speed up the process, but you absolutely cannot use real customer data. The more you build to mock and test the vendor data you prepare to manage, the longer and stronger the strategic value your platform will generate in the long run. It’s vital to add this additional factor in the 12 factors of modern app architecture, at the very least where HIPAA compliance is concerned.