What the Coming HHS Audits Mean for Your Healthcare System
With the announcement that KPMG really is going to start performing HIPAA Privacy Audits in the New Year, we’ve had numerous conversations with healthcare providers around getting their privacy and security programs up to scratch.
It’s a well-known secret in the healthcare industry that HIPAA compliance does not receive the attention (or the funding) that it should. There are of course exceptions and I should note that most security and privacy professionals in the healthcare industry take their jobs very seriously and honestly do consider the protection of patient data to be their number one priority. But, it’s often difficult to do your job if you don’t have the funding or resources needed to do it properly.
The federal government hasn’t helped – creating a mandatory requirement, but not putting in place any mechanism for testing compliance with that requirement rapidly creates a sense of non-urgency. What’s the point of REALLY making sure that we’re HIPAA compliant if no one’s going to check? It costs a lot of money, it’s annoying to doctors, it’s not even the slightest bit sexy, and it’s going to impact options to the organization.
And, if none of your competitors are limiting themselves and spending extra money on ensuring HIPAA compliance, a healthcare executive is going to see true HIPAA compliance as a competitive disadvantage. Now it looks like everything is going to have to change. Don’t believe me? Think the audits are going to be ‘no big deal?’ Let’s draw a parallel with another compliance requirement – PCI DSS.
For those of you not familiar with PCI, you should be – you probably have to comply with this as well. In any case, it’s the data security standard inflicted on merchants and service providers (companies that facilitate credit card payments) by the large credit card brands (VISA, MasterCard, etc.) Anyone that takes (or processes) a credit card for payment needs to be PCI compliant.
Although the card brands catch a lot of flak for ‘inflicting’ PCI on the world, the truth of the matter is, something needed to be done. Credit card data was not being protected and it was costing the card brands a LOT of money in fraudulent charges and impacting consumer credit ratings. If they hadn’t created their own standard the government most likely would have.
When PCI was first rolled out to the community there were a lot of merchants that thought it was no big deal, but they didn’t plan on three things:
The card brands were perfectly willing to let non-compliant merchants make ‘examples’ of themselves (link, link)
The PCI standard gave consumers a benchmark against which to judge the merchant’s brand.
These points have been effective because the card brands maintain a unified front when it comes to PCI (they all agree to the codified requirements as the baseline required by merchants to transact credit cards securely) and because they have a mandatory audit mechanism in place that gives them the power to take action if the merchant or service provider isn’t complying with PCI.
I think that we have the same dynamic going on now with HIPAA.
KPMG is going to be looking to justify their million dollar contract with the government – they will find issues with compliance during their audits.
The legal community is already very aware of privacy breaches in healthcare and what that means for things like multi-million (and multi-BILLION) dollar class-action lawsuits (link, link, link)
Everyone now has a benchmark against which to judge how much a healthcare provider cares about their patients’ data
I think that it’s time to figure out a plan on how to really address HIPAA – both in the short-run (i.e. achieving an initial compliant state) and long-run (maintaining compliance moving forward.) If you aren’t familiar with the recent announcement involving the upcoming audits here’s a link on the HHS sitewhich includes a sample of the letter that will be sent out to organizations. Also note – the first round of audits is going to focus on Covered Entities, but future rounds will also include Business Associates.
For some additional information on how to put together a workable approach to really achieving HIPAA compliance please see material on the NetSPI blog and NetSPI services pages. Also – NetSPI will be putting together whitepapers, additional blog posts, and (possibly) a webinar on this topic over the next couple of months. Please check back here for more information, make a comment, or send me an email (link below) if you would like to discuss.
What can you do to take action and address the issue? There are a number of strategies for addressing PA-DSS as a healthcare organization in the short run:
NOTE – you need to make sure that you are checking application revision as well – it matters in this process (i.e., if the app is listed, is your release listed?)
Contact any of your software vendors that might fit the criteria noted above and ask them to document a response to a few questions:
If the application (or the revision) is not on the list, ask why and what are the vendors’ plans?
If the vendor does not feel that PA-DSS applies to their application, ask them to document why and have their response looked at by someone qualified to provide an opinion (a list of organizations that can validate applications can be found here – https://www.pcisecuritystandards.org/qsa_asv/find_one.shtml)
If the vendor has indicated that their application is PA-DSS-compliant, but it’s not on the list, ask why – the PCI SSC has indicated that the validated payment application list (#1) is the only list that’s going to matter.
Again, if the application is not on the validated list, and the vendor indicates that they are in process with a PA-QSA, ask which one and the timeline. Ask to talk with the PA-QSA. Most would be very happy to speak with you as long as the application vendor is willing and allows them to do so.
Educate yourself and your team on the PA-DSS and how others in healthcare are addressing PA-DSS with their vendors. There are a number of good blogs and documents from the PCI Council. I know that a number of leading healthcare application vendors are providing educational opportunities addressing PA-DSS. Finally, most PA-QSA firms would be happy to talk with you and answer questions (although I’d pick one that has healthcare experience; otherwise, they may be heavily focused on retail). I’ll include links and resources below.
For upcoming applications that you are considering for purchase and that fit the criteria for PA-DSS:
Explain to potential vendors that you are screening for PA-DSS. If they aren’t on the PA-DSS validated list either now or by a mutually agreed-upon date, take them out of the purchase process.
Stipulate in your contracts that applicable vendors will not only achieve compliance, but will also maintain PA-DSS compliance as required by the PCI SSC. Validation is not a one-time event for application providers; it is an on-going process that needs to be continuously addressed.
Summary
The healthcare industry is one of the most highly regulated industries on earth. Given the myriad requirements that your organization faces on a daily basis, I do not wish to raise one more to your attention; however, the far-reaching nature of the Payment Card Industry Data Security Standard and its sister standard, the Payment Application Data Security Standard, requires that the healthcare community not ignore some critical industry mandates.
HITECH and HIPAA have driven security and privacy and, given the nature of the information that they are protecting, that approach is understandable. The need to protect credit card data is often not seen as a priority in healthcare the way it is in other industries (like retail), but the PCI DSS can create significant issues for any organization that takes credit cards as payment.
Gaining a better understanding of PA-DSS, its applicability to your software solutions, and its potential impact on your organization is important. This is a standard that is largely dependent on vendor compliance and therefore can pose some unique challenges that other standards and regulations do not share. Please take the time now to analyze the potential impact of the PA-DSS on your organization and take the steps that you can to minimize that impact.
Healthcare executives are concerned with a broad array of regulatory and compliance-related issues. Many of those concerns are focused on patient health, government oversight and regulation, HITECH and meaningful use, financial cost controls, and even on credit card security. That last item might not be a complete surprise, but I suspect that, for many of you, it is way down on the priority list.
It’s an understandable approach given the magnitude of your other concerns, but it is a decision that may come to haunt you, particularly given the emphasis that card brands (VISA, MasterCard, American Express, Discover, and JCB) have put on credit card security and the focus that they have been bringing to the healthcare field. Retailers have been struggling with credit card security for years, but the card brands have started to cast a wider net, and healthcare has become a primary focus for PCI compliance.
I am sure that you are aware of the Payment Card Industry Data Security Standards (PCI DSS), a very broadly applicable security standard that concerns itself with all aspects and environments that deal with credit card information. What you might not be fully aware of (or may not fully understand the implications of) is the Payment Application Data Security Standard (PA-DSS.) This standard is managed by the same organization that manages the PCI DSS and, with some important due dates having recently passed us by, healthcare software companies are only just starting to “wake up” to the fact that they may have to worry about PA-DSS. In this pair of articles I attempt to do three things:
Provide a brief overview of PA-DSS and why it came into existence.
Help you understand why you should know and care about the PA-DSS.
Provide you some steps that you can take to make sure your vendors are addressing PA-DSS
What is the PA-DSS?
To provide a bit of context, it’s important to understand where the PA-DSS originated. PA-DSS was born from a previous program known as the PABP, or the Payment Application Best Practices program. The PABP program was a voluntary program created and administered by VISA that would allow application vendors to have a third-party assessor validate that their applications were built using security industry best practices. The PABP was a program that didn’t have a lot of teeth, wasn’t overly prescriptive, and wasn’t mandated by VISA, so only a handful of companies (mostly retail-focused) bothered to go through the process – almost entirely for marketing purposes.
In 2008, the PCI Security Standards Council (the organization created by the major credit card brands to administer the PCI DSS) was asked to take over the PABP program and align it fully with the PCI DSS. The outcome of that effort is the PA-DSS, which translates the requirements of the PCI DSS into a standard that application companies follow to ensure that they are providing an application that their clients can utilize in a PCI DSS-compliant manner. The PA-DSS is a very, very detailed standard whose requirements span documentation, technology, architecture, coding practices, process, lab testing, and a full SDLC investigation to provide a complete assessment of the security of the application.
These dual standards did create some confusion for organizations concerned with or subject to the PCI DSS. Anyone accepting a credit card needs to be PCI DSS-compliant, but they didn’t have to use PA-DSS validated applications (a standard administrated by the same council.) To make their own position clear, VISA stepped forward and stated that they required the use of PA-DSS validated applications for organizations processing VISA transactions. As VISA accounts for the largest volume of credit card transactions in the United States, their stance on PA-DSS certainly carries a lot of weight.
Now, you may be thinking, ‘why all of this concern over a standard that is so focused on payment applications’? The concern within the healthcare community comes from the definition of “payment application” – the PCI SSC has declared that, if an application fits certain criteria, it is considered a payment application, regardless of industry or the primary focus of the application. The criteria can be boiled down to:
Does the application transmit, store, or process cardholder data? (i.e., does it touch relevant credit card information?)
Is the application sold, licensed, or distributed to third parties? (i.e., it’s not an application that you developed internally or had custom developed for your organization)
An FAQ on the PA-DSS program and its requirements is located on the PCI SSC’s website but, if you consider just the two points above, this standard covers a lot of application solutions within the healthcare space. Basically, any software application that deals with credit card data, even if it’s the most ancillary aspect of that software’s functionality, is subject to the PA-DSS.
Why Should I Care?
So, why should you care? Well, first of all, because VISA has mandated that every merchant (i.e., any organization taking a credit card for payment) must use PA-DSS-validated applications after a particular date. That date was July 1st of 2010 (yes, we’re already past the mandated date.) VISA has indicated that acquirers (the organizations that process credit card transactions) “must take prompt action to move all merchants and agents to PA-DSS-validated applications” and, although they have not at this point documented consequences for non-compliance, typical consequences could include fines, higher interchange rates, or a straight refusal from VISA to process any of your transactions. Also, as VISA works through the acquirer, not with you directly, your acquirer might simply cut you off from processing any credit card transactions.
A second reason to care is that you may already be contractually obligated to address both PCI DSS and PA-DSS. Many payment processors already include provisions for your PCI DSS compliance in their contracts, but, given the pressure from VISA, PA-DSS requirements are starting to show up as well. That means that utilizing PA-DSS compliant applications for managing and accepting payment may be a requirement for taking any credit card, not just VISA-branded cards. Even if a processor doesn’t restrict card acceptance, it may impose a penalty in the form of a higher interchange rate to cover their own exposure to potential security ramifications or action by VISA.
The third reason (although not the least important) you should care is that this is an issue which may have a material impact on your organization, but is largely out of your direct control. You cannot have someone validate the software that you use in your facility (unless you are utilizing internally developed or fully customized applications) – the process needs to be initiated by the software vendor, the documentation updates need to be done by the vendor, the testing needs to be done on specific revisions of the applications, etc. You can’t fix this problem no matter how good you are at making your environment and facility secure. This is the responsibility of the application vendor, but it has the potential to have a significant impact on your organization’s ability to accept credit card payments.
I’ll elaborate a little further in the next section, but action needs to be taken to get your vendors moving in the right direction on PA-DSS. In the retail community, it took retailers screening vendors for PA-DSS and building PA-DSS into contracts for application companies to finally stop arguing and get moving on their PA-DSS requirements. Healthcare organizations are only starting to recognize that they need to keep their vendors’ feet to the fire on PA-DSS, and it’s only now becoming a big issue as a few of the more forward-thinking application companies targeting the healthcare space are starting to prepare for and go through PA-DSS validation.
This post is a result of many, many conversations with software companies regarding the PCI Payment Application Data Security Standard (PA-DSS). What’s really interesting about all those conversations is that they tend to fit into two categories – the first involves software companies that know that they need to go through PA-DSS validation and are looking for real guidance, the other typically involves organizations that are looking for someone to tell them that the standard doesn’t apply to them for some reason.
The questions below are the most common ones that we receive from that second group. Hopefully, the answers will help those non-POS companies that are wondering whether PA-DSS applies to them.
1. We are a healthcare (or some other type of) software company, not a POS vendor. We’re not even implemented in a retail setting. PA-DSS doesn’t really apply to us, right?
No, this is not correct. If your situation matches the criteria for the standard (just below), then PA-DSS applies. That doesn’t mean that you have to go through the validation process, it just means that you have to go through the validation process if you want to keep selling your software to companies that accept Visa transactions. Keep reading and I’ll explain.
General Criteria:
Is the application being sold, distributed, or licensed to a third party?
Does the application store, process, or transmit cardholder data (credit card information)? Note – ‘process’ doesn’t necessarily mean financial transaction. For example, taking and hashing a card number would be considered ‘processing’ cardholder data.
2. Our company is really a Service Provider – 80% of our business is hosted, and we only sell our software to a subset of our clients for implementation at their location. We don’t have to bother going through this, do we?
According to the PCI SSC, if your software matches the criteria (see #1), then you need to go through the process. In fact, if you haven’t already, you most likely need to go through the full PCI DSS process as a Service Provider as well.
There are exemptions for one-off, customized solutions, but if you are selling the same base application to two or more clients (and, again, you meet the criteria) you need to address PA-DSS.
3. Isn’t there some way of doing this more cheaply?
Not really. The process of validating an application under PA-DSS is actually quite involved. It includes documentation review, lab testing, interviewing, process and controls review, documentation, documentation, documentation, and some more documentation.
This is not PABP (if you are familiar with the original Visa software security standard). We have seen significant issues with companies that thought they could treat PA-DSS with the same level of attention and effort as they gave to the older standard.
4. Are the PCI Council and the card brands trying to put my company out of business?
No – I honestly don’t think so. They are just looking to make sure that applications capable of being implemented in a PCI-compliant manner are what are being sold in the marketplace to handle credit card information and transactions. Their interest is primarily in keeping their card data secure and in making sure that the merchant is choosing applications that will support that goal.
6. Do my customers need to have our product validated for them to be compliant with the PCI DSS?
No, your customers are not required by the PCI DSS to utilize PA-DSS validated applications today.
In practice (a point stressed at the recent PCI Community Meeting), Visa will be requiring merchants and service providers to use PA-DSS validated applications (unless the applications are developed internally). That Visa announcement makes PA-DSS a practical requirement (even if not technically a PCI requirement) for companies that want to continue accepting Visa as a form of payment.
7. How long does the PA-DSS process take?
It actually depends heavily on the software vendor. If they are highly motivated, committed, and well prepared (and timing with the PA-QSA matches up), the process can be fairly quick. This isn’t necessarily typical, however.
At NetSPI we work with our PA-DSS clients in a very interactive manner. We want to identify gaps and allow you to address them prior to testing and review being complete. Closing identified gaps requires the software vendor to take real action; without that action and commitment, the process can really drag. There is little the PA-QSA can do to move the process along without that commitment.
8. Why are there fewer PA-QSAs vs. PCI-QSAs?
In my opinion, it is due to a few things:
Application expertise and app security expertise are NECESSARY for PA-DSS – it’s not quite so easy to throw outside resources at PA-DSS and try to survive on a rigid audit process; you actually have to know what you are talking about.
The rigorous QA program that the PCI SSC has implemented on the PCI DSS side was actually ‘turned on’ from day one on the PA-DSS side and required a level of documentation and commitment on the part of the PA-QSA that many in the PCI community simply didn’t want to (or couldn’t) handle.
In PA-DSS, the relationship between the firm validating the software and the vendor going through validation is extremely important. This isn’t just about an audit and we’re done. If a PA-QSA firm is doing its job correctly, the QSAs are having discussions with their client about future updates, version control issues, architecture issues, how to operationalize future PA-DSS validation efforts, etc. That’s a consulting/partnership relationship, and many in the PCI community aren’t focused on that type of relationship.
9. Implementing our solution in our PA-DSS partner’s lab is a real pain, do we have to?
Not necessarily – the council prefers that your application be tested in a PA-QSA’s lab, but it’s not required. If it is impractical for the application to be installed in the testing lab (and your PA-QSA feels comfortable defending that opinion), you can bring the PA-QSA to your location.
10. We think this whole thing is ridiculous. What if we refuse?
You certainly have the right, but the PCI SSC has been very straightforward: the PCI PA-DSS list is to be the de facto standard on PCI–acceptable applications. If your application is not on the list, you are taking a risk, the potential impact of which would most likely go far beyond the expense of going through the process.
11. We’ve gone through CCHIT (or some other standard that includes security). Aren’t we covered?
No. PA-DSS is not a suggestion from Visa– it’s a requirement. It is also the only standard that is entirely focused on cardholder data (the data that card brands really care about). If your solution has been successfully audited or validated under another security-focused standard, you may have a head start on getting your solution to a PA-DSS-compliant state. That effort may help prepare you for PA-DSS validation.
In a post that I wrote earlier, “The Far-Reaching Impact of the PCI DSS,” I mentioned the influence of the PCI DSS on industries other than retail and hospitality. I’d like to expand on that topic by taking a look at healthcare software and the Payment Application Data Security Standard(or PA-DSS, a standard within the broader PCI DSS.)
Since the introduction of the PA-DSS, and the ‘retirement’ of the former standard (PABP), NetSPI has been constantly engaged with companies that suddenly have to address what was previously a voluntary standard and one that was considered relevant only by Point-Of-Sale (POS) vendors.
However, what has been pretty clear from the beginning is that PA-DSS is in no way limited to the retail checkout environment. As defined by the PCI SSC, the PA-DSS applies to applications that:
•Store, process, or transmit cardholder data
•Are sold, distributed, or licensed to third parties
It’s really pretty straightforward – if you are a software company and your product fits these two criteria, PA-DSS applies to you. That means that healthcare application companies whose products touch cardholder data now need to add PA-DSS to the list of standards they need to be concerned about. Also, I should mention that the deadline that VISA has set for PA-DSS compliance is July 2010.
Many integrated healthcare solutions are built to support a wide range of needs inside a complicated hospital or practice environment – managing workflow, interaction, and data sharing internally between departments as well as externally with patients, insurance companies, and, potentially, public health representatives.
Often these highly valuable (and highly intricate) systems were not built with a primary focus on financial transactions – they sprang from the needs of doctors, patients, and the medical system. The requirements involved with PA-DSS and the broader PCI DSS can be confusing and hard to translate for healthcare software companies that have certainly incorporated security and privacy into their products, but have traditionally focused on patient confidentiality rather than cardholder data protection.
Today, my recommendations for healthcare software companies would be:
Rapidly determine if their solutions meet the criteria for PA-DSS and, if so,
As the deadline approaches, addressing these two things is the first step in a process that really needs to be more holistic and take into account the full spectrum of security concerns that face the healthcare software community. That holistic view now includes validating against a standard that was not developed by a healthcare-centric entity, but rather by an organization that was created to ensure credit card security (regardless of the market or environment.)
Understanding where and how the PA-DSS translates into their solutions is one of the challenges for software providers in the space, and there are few knowledgeable, experienced partners to turn to as July gets closer
