PCI PA-DSS in Healthcare – Part 1

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:

1. Provide a brief overview of PA-DSS and why it came into existence.
2. Help you understand why you should know and care about the PA-DSS.
3. 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:

1. Does the application transmit, store, or process cardholder data?  (i.e., does it touch relevant credit card information?)
2. 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. Next up – what can I do?…

Alex Crittenden