Insights & Ideas

Written by Stage7 Systems with Cindy Schwerdtfeger, Manager of Security & Access, Allina Health System

When most of us think of compliance in healthcare we think of HIPAA. That’s not uncommon for any number of reasons. However, over the past few years, PCI-DSS (commonly referred to simply as “PCI”) has been giving HIPAA a run for its money as the “top of mind” compliance initiative in healthcare. Why? In part, because of the sprawling nature of PCI compliance programs, but also because PCI’s bite is actually far worse than its bark. These two factors are largely responsible for elevating PCI’s state of urgency at Allina Health System in Minnesota. What follows is an inside look at their initiative along with some lessons learned that could help you reign in your own PCI compliance efforts.

For background purposes, the Payment Card Industry Data Security Standard (PCI-DSS, or PCI) came on the scene in late 2004. Since then, it has been widely accepted by most organizations as a solid standard for baseline information security in transaction processing environments.

A close relative to PCI aimed at software vendors, the Payment Application Data Security Standard (PA-DSS), was introduced in 2008. This provides an added layer of security at the application level within transaction processing environments.

While the standards of both compliance programs evolve over time, their core functions are to help organizations create and maintain a secure infrastructure to process, transfer, and store financial transaction data (credit/debit cards, etc.).

HEED THE WARNING

It would be an understatement to say that it’s difficult to prepare for a PCI compliance initiative because it’s hard to know how long it will take until you’re in so deep you don’t know which way is up. It’s often said that PCI compliance boils down to 12 key points but that’s not necessarily the whole truth. In reality, there are over 200 sub-components to the PCI standards and because of that, there will always be pieces of the puzzle that catch you off-guard. Allina was no exception.

Allina had PCI compliance on their radar for a couple of years prior to launching a formal initiative but their call to arms was a deadline that said, “Validate your PCI compliance to prevent non-compliance fees.” Because there had been preliminary scoping and assessment work done and significant work on reducing the scope of the IT environment to which PCI DSS apply, as those deadlines began coming into full view they were able to mobilize quickly to start documenting their departmental processes, internal applications, and workflows against the laundry list of PCI standards to determine where they were most at risk.

UNDERSTAND THE RISKS AND CONSEQUENCES OF A BREACH

Over the past few years, Allina has paid close attention to the data breach horror stories that make headlines in the healthcare industry and they’ve developed a keen awareness of the potential liabilities to the health system if they were to experience a breach. This awareness has made their PCI initiative run more smoothly because it’s proven easier to get executive sponsorship to back up the effort.

At its core, PCI compliance has some pretty compelling motivators attached to it. These “motivators” can range from breach notification laws to financial penalties from card issuers to potentially having your ability to process credit transactions denied entirely, all of which could be detrimental to a health system of any size. In addition, any merchant that has had a breach resulting from an account data compromise may be escalated to a higher validation level.

By understanding and communicating the financial and operational risks associated with non-compliance, set alongside the risk to their reputation with patients and the community, it was easier for Allina’s staff to rally around a common objective, not only for the solidarity of their health system but also for the benefit of their patients.

UNDERSTAND THE DISTINCTION BETWEEN PA-DSS AND PCI-DSS

At times there is a misconception that if an application is certified as PA-DSS compliant then implementing it will insure your compliance with PCI standards. This is not necessarily the case and you’re not totally off the hook. Yes, you want to ensure that the payment applications you use to process transaction data are PA-DSS compliant but in addition, it’s how you implement those applications that allow you to achieve PCI compliance. An application that’s PA-DSS compliant doesn’t alleviate the need for any of the other safeguards that should surround the application. Understanding and making this distinction early on will save you headaches down the road.

NARROW THE SCOPE

When Allina formally kicked off their PCI compliance project, there were a number of activities that had to take place so they could comply with the standards from a technical perspective. One thing that served as a foundation to all subsequent activities was the idea that their entire network couldn’t possibly be considered “in scope” or the effort would be cost prohibitive. They needed to narrow the field to include only those applications and infrastructure components that were directly related to the entering of credit card transaction data, the display of that data, the storage of that data, or the transfer of that data.

Allina set out to identify the various sources and flows of transaction data throughout the health system. Upon starting this process, they realized just how quickly the PCI project could fan out. When you consider what might happen during a typical hospital visit – a patient swiping their credit card in the parking garage, paying their co-pay at the registration desk, visiting the common area for lunch and making a purchase there, and finally visiting the pharmacy on their way out the door – the flow of transaction data starts to come into view.

During this process, Allina started out with many potential applications that might be considered “in scope” and from there they analyzed the workflow and how the data is being handled in each of those scenarios. Is there a card swipe function right at the desktop terminal that encrypts the data and sends it off to the processor? Or, if credit card information is being taken over the phone, is it being recorded or displayed, written down, and then entered into a system manually before being transmitted to the processor?

Taking each individual scenario and application into account they had to ask themselves:

1. Where does the data flow start?
2. How do we get the credit card and transaction data?
3. Is the data entered into an application where we’re storing it or is it sent immediately to the processor?
4. If it’s written down or recorded, how should we be handling that?
5. If it is displayed or recorded in a phone transaction, do we need to encrypt the phone conversation?
6. If we’re storing the data, is it being replicated to our offline data center? And what about backups?
7. Is the application used to store cardholder data compliant with PCI’s requirements?
8. For data in transit and stored in the data center, what are we doing to encrypt it?

It was a long process to be sure, but upon completion this effort significantly narrowed the scope of their project, which will save them time and money in the long run.

CREATING AN ISLAND

When Allina first started their PCI project, their infrastructure was designed to support clinical and healthcare business activities, with segmentation used primarily for diagnostic equipment on the network. As they moved through the process, they began creating what became known as a “PCI Island” where they segment off workstations, servers and other devices that are specifically impacted by PCI, into their own area, virtually or physically.

By doing this, Allina is essentially taking everything considered “in scope” relative to PCI and isolating it so that their infrastructure is more manageable when it comes time to make changes, comply with newer versions of PCI standards, and so on.

GET (AND KEEP) THE RIGHT PEOPLE INVOLVED

As evidenced by Allina’s experience, a PCI engagement isn’t representative of a typical project with a pre-set charter, schedule, go-live date(s), etc. Rather, it’s filled with hundreds of moving parts that seemingly never stop for rest. Because of this, and because there’s no “here’s how to do it” manual, assigning a core team with vested interests in the project’s success will be critical.

For example, at Allina, PCI is primarily viewed as a function of the Treasury and IT Security groups if for no other reason than those two groups have the most to gain (or lose) from the project. Treasury is ultimately responsible for managing income and IT Security is, of course, the steward of data access controls. But in addition, many other IT and business staff are key players in attaining compliance, from network/telecom, desktop, operating and web development groups in IT to business office and registration staff in business operations.

Having all these parties working collaboratively towards this common objective will serve Allina well going forward too. Each day, week, month, and quarter, there will be things to follow-up on as quarterly compliance checks begin and as standards evolve. In order to ensure that the proper follow-up actions take place, PCI compliance needs to be “owned” by those with the greatest interest in its ongoing success.

WHAT’S NEXT

Allina has made great progress towards achieving PCI compliance but there’s still a ways to go. They’ve learned some valuable lessons and have uncovered a few areas that require additional attention before their number comes up. As far as what’s coming down the pike for them, a few items include:

Addressing data loss prevention:
Part of the PCI standards require data-at-rest to be secured. To meet that requirement, Allina is implementing a Data Loss Prevention (DLP) solution that will enable them to scan for PCI data on file shares and summarily lock it down.

Application upgrades:
Some of the applications at Allina are in need of upgrading to help automate some of the tasks relevant to maintaining PCI compliance (or to at least make those tasks easier).

Other efforts at Allina include updating their logging system, continuing on with plans around intrusion detection, and a number of other initiatives that will help enhance their overall security posture.

Allina will stay focused on the need for continuous monitoring for PCI compliance as our goal is to ensure that compliance with PCI DSS is treated on an ongoing basis.

ABOUT ALLINA HEALTH SYSTEM

Allina is a not-for-profit system of hospitals, clinics and other healthcare services, providing care throughout Minnesota and western Wisconsin. Allina owns and operates 11 hospitals, more than 90 clinics, and healthcare services, including home care, hospice care, palliative care, oxygen and medical equipment, pharmacies and emergency medical transportation. Allina delivers exceptional healthcare and support services through its nearly 24,000 employees, 5,000 physicians and 2,500 volunteers. For more information, visit www.allina.com