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.
The Mayo Clinic recently launched Mayo Clinic Center for Social Media (http://socialmedia.mayoclinic.org/) intended to help train medical practitioners and patients about the use of social media to improve patient care. While it’s easy to see how greater access to healthcare related information can be very valuable, problems with doctors and nurses posting PHI inappropriately has made news headlines more than a handful of times. Therefore, this new development comes at a great time, just as more and more organizations are beginning to appreciate the value of a comprehensive social media strategy.
With the goal of delivering better quality care to patients, many healthcare systems are sharing EMR applications and medical data repositories and setting up interfaces between different systems. This increases exposure of medical records to a larger group of healthcare practitioners by allowing better, faster, and easier collaboration between doctors. With increased collaborative efforts, it’s become more likely that doctors will choose social media as the catalyst of collaborative efforts and patient information sharing. Therefore, organizations that act as custodians of PHI, such as hospitals, clinics, and research labs, must take active steps in educating their workforce about the dangers of social media, and how these tools can be used effectively and without violating patient confidentiality or current healthcare compliance requirements.
Through the Center for Social Media, Mayo Clinic seems to approach the problem from multiple angles. While the portal is still very young, the articles already posted address issues of creating well-designed social media policies, creating appropriate training materials, as well as provide analysis of documented cases of misuse of PHI. Overall, I view this as a very positive development and will continue to monitor this website for insightful information about the best use of social media in healthcare. After all, this technology is here to stay, and draconian policies of simply blocking access to Facebook from the workplace have proven to be ineffective. The answer to these challenges clearly point to better guidance and training for the healthcare practitioners, as well as developing tools for responsible, effective, and secure collaboration.
One of the most promising technologies for automatically enforcing compliance with sensitive data handling practices is Data Loss Prevention (DLP) technology and it is quickly gaining popularity and adoption across many industries. Does this mean that DLP is the answer to all sensitive information handling concerns?
In short, I am sorry to say that while DLP offers excellent solutions within a limited range of data, such as payment cards, social security numbers, and other easily identifiable data, it does not offer great solutions for HIPAA compliance. Most recently a case of an employee being fired from Oakwood Hospital in Michigan has once again highlighted the utter impossibility of automatically enforcing HIPAA compliance. In this case, Cheryl James made some comments on Facebook which were interpreted as a violation of HIPAA requirements. This was not the case of medical records being leaked out, but rather a comment made by a medical professional. More information about the incident can be obtained here. (http://www.fiercehealthcare.com/story/hospital-worker-fired-over-facebook-comments-about-patient/2010-08-01)
More and more people are using websites such as Facebook as a part of their everyday conversations with their friends and family. However, a comment made to a spouse in the privacy of one’s home is clearly not the same as posting that comment on Facebook. Since this is not the first time a comment made on a social networking website has landed a hospital employee in trouble, it’s clear that it will take some time before everyone fully realizes the risks of communication of sensitive data on social networking websites. Naturally the question that begs to mind is if there is anything that hospitals can do to prevent such incidents in the future.
The advantage of DLP technology is that if you are able to define the pattern or a structure for the data that can be automatically identified as sensitive, the DLP technology will be able to prevent most inappropriate transfers of such data, including posting on social websites. However, with regard to healthcare, data that falls in the range of being considered PHI is very diverse and does not allow for automated identification. Therefore, techniques for reducing risks of inappropriate disclosure must fall back on the low-tech controls such as training and blocking high-risk websites like Facebook for all employees.
I like to watch industries evolve in how they deal with information security. It was interesting to watch retail evolve as PCI got more organized. The PCI Council put together the DSS with dates and penalties for breaches and non-compliance, and that drove significant change. It appears that a similar major change within healthcare is starting to take place. We have begun to see a proactive shift that incorporates compliance with HIPAA, an understanding of risk, and the development of security programs.
As I’ve discussed in the past, the healthcare industry is significantly behind in dealing with IT-related risk. For an industry to change its approach to information security / risk, its culture needs to evolve. In my opinion, risk is the most effective driver of this change. If the risk is great enough, industries develop a mature understanding of risk management (of which security is a subset). The military and banking have tangible risks tied directly to their IT assets; therefore, they understand risk. The problem is that this mature understanding of risk doesn’t exist in most other industries. Without risk driving a security program, industries must rely on other drivers – usually compliance (also a subset of risk).
What we’re seeing within healthcare is that PCI is driving the maturation of risk. For example, one key issue that keeps coming up, especially in hospitals, is the belief that PHI is more important than PCI / credit card information. Yet it is PCI compliance that has forced organizations to think systematically about risk. How do you reconcile the budget for PCI compliance with the lack of budget for PHI-related security?
In addition, PCI has forced multiple groups (including IT, security, audit, and finance) to work together to deal with compliance and, ultimately, information security issues. Many of these same groups are now being asked to deal with HITECH / ARRA / updated HIPAA. With the new interpretations of HIPAA, the new regulations, and with these new sets of eyes, these groups are beginning to understand that they are not compliant with HIPAA, that they have significant risk exposure, and that they need to develop programs to deal with this exposure.
From what we are seeing with many of our healthcare clients, the combination of a more pervasive awareness of PCI and new healthcare-specific regulations are creating a more mature understanding of risk and driving a new focus on developing successful information security programs. Let’s hope this trend continues.
