Most hospitals are simply noncompliant with credit card data protection regulations. And if they are in compliance, the degree of compliance typically is unnecessarily high.

Healthcare revenue cycle leaders are acutely aware of the need to facilitate patient pay, particularly for the growing number of patients enrolled in high-deductible health plans (HDHPs). Although they often defer to the chief technology officer (CTO), chief security officer (CSO), or similarly titled leader on questions of how protect those payments, it is important for anyone who bears responsibility for patient payment processing to understand how the payment solutions they select affect their internal security and compliance obligations—and that includes revenue cycle leaders as well as finance leaders, in general. These leaders also should consider their role in avoiding the costly penalties, damage to their organization’s reputation, and loss of patient trust that can come from a credit card data security breach.

To protect payments—and patient credit card data, in particular—revenue cycle leaders require a basic understanding of the types of hacking threats hospitals face and how these threats affect the different payment pathways used by the solutions they choose.

The payment security equation

To ensure payment security, it is necessary to address five essential financial factors of payment processing:

The devices, software, and policies necessary for hospitals to process credit card data

The cost of meeting the compliance obligations triggered by different processing solutions

The challenge of keeping pace with constantly evolving security threats

The penalties for noncompliance

The costs of a breach occurring (which can vary based on whether the institution was in compliance at the time of the breach)

In any event, the best solution for any hospital will involve obtaining secure payment processing devices and software that best facilitate compliance, maintaining the standards required to avoid penalties, and minimizing the risk of a breach.

At the very start, learning about different forms of hacking can help finance leaders and other executives outside the IT arena to understand how to define “most secure” in terms of payment processing.

To provide context for the importance of having such understanding, it is important to note that health care held the distinction of being the most breached industry in 2016, according to the San Diego-based Identity Theft Resource Center (ITRC).1 In 2015, ITRC analysts identified 780 major data breaches across industries in the United States, 35 percent of which occurred in health care, and that percentage increased to 43 percent in 2016. The industry is such a rich target for hackers because hospitals often transmit credit card data alongside personal information that can’t be “canceled,” such as addresses, birthdates, and social security numbers.

Credit card security threats in context

Patients are increasingly turning to credit cards to pay their healthcare bills, and they make these payments either with staff assistance—in person or over the phone, typically with a customer service representative (CSR) entering in the data—or via an online patient portal, where they submit this information themselves through a process commonly referred to as eCommerce. Different threats are associated with these two payment pathways.

Staff-assisted payments. For hospitals and health systems, as for any industry, the main threat to data security is not a mastermind criminal hacking his or her way into some data-rich central database. The more likely threat is in some ways more insidious and much less obvious: malware, a catchall term that describes malicious code that gains access to a computer via seemingly legitimate “phishing” emails.

One of the most common forms of malware is keylogging software—code that detects when credit card information is being entered, captures it, and sends it back to the code’s source. Because a keylogger lives on the hospital computer, it can succeed in stealing the credit card information when a CSR enters it onto the infected computer. Although the payment application may be compliant with the standards of the Payment Card Industry (PCI) Security Standards Council, the vulnerability is at the point of capture, or when the patient card data are being entered into the CSR’s terminal, and during transmission of the clear-text data on the provider’s network.2 When it comes to malware, the key is solving the data capture and transmission issue, because the threat is not to the card data processing or storage.

In 2015, malware was the leading cause of data security incidents across the United States.3 With the bulk of patient self-pay still happening with the help of CSRs (and their networked computers), addressing hospitals’ vulnerability to malware is paramount.

Patient-entered payments. Phishing scams and malware pose less of a threat to hospitals when it comes to patients entering card data online. However, special consideration needs to be taken when the payment portal is hosted on the hospital’s network because card data are still being transmitted.

For online payments, patients are directed to a hosted patient portal or a secure third-party vendor site to enter their credit card information. The first option puts patient credit card data at risk and typically requires the PCI audit, which is the most detailed—and costly—audit in accordance with the PCI security standards. In the third-party vendor scenario, the credit card data never touch the hospital’s network and typically require only a short PCI audit to achieve compliance.

Revenue cycle leaders should keep in mind, however, that compliance obligations are determined by all the pathways for payment, not just one. As long as the hospital accepts a single credit card payment over the phone, in person, or online, it is responsible for protecting that information and maintaining compliance with network security standards.

Available technologies

Depending on the payment pathway, there are four primary technology solutions that healthcare providers use for protecting credit card data and complying with PCI security requirements.

Network segmentation. A traditional way of complying with the PCI data security standards is to maintain network segmentation, which aims to separate credit card transactions from the larger network. This compliance strategy is costly to maintain and requires CSRs to enter credit card data on a separate, dedicated computer. It includes hiring someone to manage the details of the segmentation and ongoing annual costs between $250,000 and $300,000. Hospitals also still must perform yearly audits involving more than 300 questions, and have the audits validated by outside auditors.

Web-based payment application. Providers commonly use web-based payment applications for staff-assisted payments, with the idea that the data are protected because the application is PCI compliant. But in reality, the card data remain at risk, and despite the widespread perception of such applications as means for protecting card data, the only way to fully protect the data during staff-assisted payments is with a PCI-validated point-to-point encryption (P2PE) device.

P2PE. Over the past two years, the development of P2PE technology has enabled hospitals to avoid the inconvenience and costly implementation of network segmentation. P2PE is a standard established by the PCI Standards Council describing solutions that “encrypt data from the point of interaction (for example, at the point of swipe or dip) until the data reaches the solution provider’s secure decryption environment.”4

Specifically, P2PE solutions help hospitals meet compliance requirements for in-person and over-the-phone payments. With this solution, CSRs enter card data via a PCI-approved point-of-entry swipe or keypad device. Because the credit card data are encrypted immediately, there is no need for network segmentation: The data never touch the network. Specifically, these devices avoid the liabilities associated with personal computers (including phishing emails and other exposure to malware). Further, P2PE devices often are equipped with additional safeguards that shut the operating system down if anyone were to attempt to install malware on the device or tamper with it in any way. A P2PE solution gives a hospital the chance to lower its PCI maintenance costs, while dramatically reducing its PCI scope of compliance, resulting in reduced costs associated with a PCI audit.

Secure iframe implementation. Patient online payments prompt a different set of considerations from those addressed by P2PE solutions. A hospital that opts for a third-party eCommerce solution that follows PCI standards will meet its compliance obligations for this channel. If a hospital prefers to use its own hosted eCommerce site instead, it must consider a technology solution to prevent card data from entering its network. One answer to this problem is an embeddable payment form known as a secure iframe, or inline frame, which provides a third-party page embedded in the hospital’s website but isolated from the hospital’s network, to capture and store card data outside the network. This approach solves the problems associated with card data and the patient experience seamlessly, because the patient never leaves the hosted site and the provider achieves the highest level of security with the lowest reasonable scope of compliance.

Minimizing scope: PCI validation

The PCI Standards Council assigns organizations to different classifications, each of which carries a requirement for the completion of a specific audit. This practice is where the cost issue comes into play, because the audits are of various lengths, ranging from about 20 to well over 300 questions.

The council is, in a sense, using the rigor and length of the audits to point merchants toward the most effective solutions: the better the data protection scheme, the simpler the audit.

A hospital with a PCI-validated P2PE solution, which prevents card data from transmitting “in the clear” (i.e., in a plain text or unencrypted format), undergoes the simplest audit, whereas a hospital with a nonvalidated P2PE solution requires the most extensive—and costly—validation process. In turn, a hospital using a hosted iframe within its eCommerce site that is implemented according to the Standards Council guidelines will undergo the simplest audit, provided it also has a validated P2PE solution in operation. If only one solution is in place, hospitals are still subject to the highest level of PCI audit. Both PCI-validated P2PE and secure iframe solutions must be in place for a hospital to be eligible for the lowest PCI scope.

In theory, both validated and nonvalidated P2PE devices should be strong responses to the existing threats to credit card data. In terms of installation and operation costs, too, validated and nonvalidated devices are the same. The single difference arises in the realm of compliance: The hospital is paying for someone, typically an external auditor, to perform an annual audit to achieve compliance, and a nonvalidated P2PE device is subject to that vastly longer, 300-question audit. (Auditors themselves will be unlikely to complain if a hospital uses a nonvalidated device, as a longer audit makes them more useful to the institution.) The compliance-related cost reduction and benefit accrues only to organizations that opt for PCI-validated P2PE devices.

The costs of noncompliance

On the other end of the spectrum from optimal compliance is noncompliance, a status that has for years been the default status for most hospitals. As patients rely increasingly on credit cards to pay higher deductibles and copayments, however, the PCI Standards Council is turning its scrutiny towards health care for violations of security protocols. The costs of noncompliance are outlined in the sidebar.

The multimillion dollar payouts from notorious breaches like those incurred by Target and Home Depot exemplify the enormous consequences that follow a credit card data breach.5 The consequences of such breaches are more dire in health care, because it is a unique setting in which trust is a matter not only of brand loyalty but also of a successful patient-provider relationship. In this setting, the sense of violation felt by exposed cardholders as a result of a breach is heightened.

Revisiting the payment security equation

Financially speaking, a hospital can go wrong with PCI compliance in one of three ways:

It can pay too much to be in compliance.

It can ignore the issue entirely.

It can obey the letter of the law without following its spirit.

The last way listed is known as “living for the audit.” The goal of measures such as P2PE should not be only to pass the yearly audit, and then let standards lapse during the remaining months. It should be to take advantage of the most effective and most sophisticated forms of defense against data loss.

Addressing security and compliance issues up front when selecting payment processing services is becoming imperative. Hospitals must ask the following questions:

Where are we entering patient card data?

Are we using P2PE for our patient card data transactions? If so, is our P2PE solution PCI-validated?

Are our CSRs keying patient card data into a third-party web service? Can that web service be integrated with a PCI-validated P2PE provider?

How do we implement our eCommerce payments? Does this method protect our patient card data?

What path to P2PE are our vendors using (assuming the hospital is using vendors)?

Just as security threats evolve constantly, security efforts can never be fully addressed and resolved. Hospital leaders may feel that because they have done network segmentation once, their work is done. But as the PCI Standards Council has indicated through its validation program, newer technologies can provide greater protection with fewer potential vulnerabilities. Moreover, some of these technologies may allow hospitals to save money by qualifying for a lower necessary scope of compliance and avoiding the management of earlier, more complex approaches to data security.