As should come as no surprise to anybody, our clients in the healthcare industry have been inundated in recent years by a slew of new healthcare IT regulations that affect processes ranging from how they keep records, to how they get paid, to what services they prioritize. In our experience, finding a good summary of these rules and regulations is a challenge, and the few resources that exist on the internet are often written with so much legal jargon that they are hard to understand. So the purpose of this summary article is to provide people with a layman’s high-level view of just a few of these rules that are on the books, and to explain them in a way that developers and software development managers can understand.
(Disclaimer: Keep in mind, we are in no way healthcare attorneys – these are merely rules that we’ve run into in the course of developing software applications for customers. If you need legal advice, please contact a real attorney!)
HIPAA – The Health Insurance Portability and Accountability Act
This healthcare IT regulation is probably the one we get asked about most from clients. HIPAA controls how you access protected health information, what you can do with it, where and how you can store it, and what happens if a breach occurs. Before the days of HIPAA, if your sensitive health information leaked out of a healthcare facility, and you were fired (say because it was revealed you had been undergoing treatment for drug addiction), you faced a difficult and expensive battle to sue the healthcare provider for such a breach. Today, at least theoretically, HIPAA basically allows the government to fight on your behalf, by imposing fines and other penalties – which can be quite hefty.
Those are some of the high level details around the “Accountability” side – the “Portability” side basically has to do with a person’s ability to take coverage with them when they change jobs, or have some other life event, and probably doesn’t affect most software development much unless you’re writing software for insurance companies (in which case it affects a lot of things).
HIPAA was enacted in 1996, so it’s been with us for quite some time, but surprisingly, a lot of healthcare organizations and systems still don’t really have their information totally secured, and breaches still seem to happen a lot more than they should.
Implementing HIPAA controls in a custom software project is something we’re very comfortable doing, but can be an imposing task for a lot of software developers. And even if you’ve built HIPAA-compliant software, you still have to have it hosted in a properly set up location for HIPAA compliance. Building a HIPAA compliant app in PHP and then hosting it on GoDaddy ain’t going to cut it.
Also, one other question we often get asked by customers is “Does this system need to be HIPAA compliant?” – as in, does the data I’m storing in this system require us to go through the expense of adding HIPAA compliant features to this software?
Free Project Cost Estimation Tool
Download this free Microsoft Excel Project Estimator tool to gain some insights into what your software development project might cost! Fill out the form at the right to download this FREE resource.
The simplest answer to this question is that if the data you are storing or displaying in your system came from a “protected entity” (i.e. a healthcare provider, hospital, physician, or health insurance company), then it qualifies as PHI (protected health information) and the system needs to be HIPAA-compliant.
So if you are displaying a screen in your system that shows a person’s blood pressure, and that number came from a test they had done at their doctor’s office – your system needs to be HIPAA compliant. It doesn’t matter if that value originated with your company or not.
The Affordable Care Act (ACA/“Obamacare”)
If you haven’t heard of this one, I’m not sure which rock you’ve been living under. But, what you may not know is exactly how it has affected software systems in a healthcare environment. At a high level, the ACA has increased the pressure on healthcare organizations to protect consumers, track outcomes better, and have better reporting on quality. While this isn’t the only law doing this, I have seen a lot of pressure to track outcomes in the industry, which is partly due to efforts to link payment for services to the outcomes that they create. From a software development standpoint, this mainly means a lot of new reports being necessary, and we have personally created systems to track outcomes much more carefully partly because of these requirements.
HITECH – Health Information Technology for Economic and Clinical Health Act
HITECH is a set of healthcare IT regulations that was passed as part of the stimulus bill of 2009 (American Recovery and Reinvestment Act of 2009), which promotes the use of electronic health records, as well as increases the safety, quality, security, and privacy of information exchange.
In a nutshell, HITECH causes the HIPAA requirements mentioned above to expand to not only apply to primary healthcare organizations, but also business associates of those organizations. This is a big deal because it means that consultants, developers, and IT providers that work with hospitals and healthcare organizations need to follow the same rules they do, and are subject to some of the same penalties. HITECH also creates processes for reporting information breaches and expands penalties for non-compliance.
MACRA – Medicare Access and CHIP Reauthorization Act
MACRA is a set of laws that defines thresholds for reporting healthcare performance data, as well as how much history must be reported on. The act provides incentives and penalties for healthcare providers who report on key patient metrics, and specifies the details that should be provided about how their treatment has improved them. So it 
focuses a lot on clinical practice improvement, and also defines some of the requirements of participating in Medicare.
From a software systems standpoint, it probably has increased the demand for better EHR software at the physician level, or at least required more features to be added to the products used to help track that information.
Hopefully these summaries give you an idea of whether or not you need to look into each of these regulations more for your organization. If we can be of service from a software and technology standpoint, please feel free to reach out!
References:
https://www.healthit.gov/sites/default/files/fdasiahealthitreport_final.pdf
http://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html
http://www.govtech.com/health/Digital-Health-Dilemma-Regulators-Struggle-to-Keep-Pace-with-Health-Care-Technology-Innovation.html
http://www.hipaasurvivalguide.com/hitech-act-summary.php
http://www.modernhealthcare.com/article/20160102/MAGAZINE/301029961
http://searchhealthit.techtarget.com/definition/HITECH-Act
http://searchcompliance.techtarget.com/feature/FAQ-What-is-the-impact-of-HIPAA-on-IT-operations
https://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf
