Healthcare CFOs and CIOs have to work more closely than ever to address the challenges and opportunities associated with the rise and expansion of "self-pay."
Where the term used to refer to the uninsured or underinsured, today self-pay also includes the increased out-of-pocket costs expected from covered patients. Whether it's a sizeable co-payment or payments toward a $1500 deductible,1 more hospital revenue is coming directly from consumers. And what that means for the CFO and CIO is more credit card data they have to keep secure.
The fact is that accepting even a single credit card payment immediately subjects a hospital to PCI (Payment Card Industry) compliance requirements. But the massive rise in credit card use in hospital settings—via customer service representatives, on-site terminals, and online portals—is drawing the attention of both hackers and regulators.
Here are the 4 key steps hospitals need to take to simplify the PCI compliance process and avoid unnecessary costs:
1. Find out: where you stand
Any provider that accepts credit cards must comply with the PCI Data Security Standards. Hospitals process credit cards via two pathways. First, hospital customer service representatives (CSRs) assist patients with payments either by phone or in person, typically with the CSR entering the credit card data on their computer or in a hospital-provided terminal. Second, patients submit the information themselves via an online patient portal.
For hospital CFOs and CIOs, finding out where you stand means understanding how you have implemented business processes for both of these pathways. For instance, you may be using a vendor solution that is PCI compliant, but that does not remove the provider's risk or PCI requirements. Data can be breached during transmission on a CSR's computer before it even touches the vendor's system. Understanding the hospital's vulnerabilities to under-the-radar hacking is critical, but even more important is grasping that the hospital, not any vendor, owns 100% of the compliance obligation.
2. Understand: the available options
To cover the different payment pathways, hospitals need to ensure compliance from end to end. For in-person and over the phone payments, providers have three main options:
- Do nothing and complete an enterprise audit: Leave the hospital's network as is, but perform a comprehensive audit that includes every mobile device used by the staff right up to the CEO's computer, in order to identify vulnerabilities and monitor breaches.
- Network segmentation: Set up and maintain a dedicated network for the purpose of processing credit cards, which means that any CSR taking payments must use a separate terminal. While this option reduces the scope of the audit, compared to an enterprise audit, it can be disruptive to business process and is costly to implement and maintain.
- PCI-validated P2PE (Point-to-Point Encryption): Encrypts the credit card data immediately upon entry and prevents it from transmitting across the network. This is the preferred PCI Standards Council solution for capturing and processing credit cards—and therefore results in the lowest scope and most cost-effective solution to meet PCI compliance.
- Third-Party Vendor Site: Patients are directed to a third-party payment portal that is hosted by a PCI-compliant vendor. This ensures that no patient-entered card data touches the hospital's network.
- Secure iFrame: For providers that want to accept patient payments within their EHR (e.g., Epic MyChart), a secure iFrame—or embeddable payment form—can be implemented by a third-party, PCI-compliant vendor to capture and process card data off of the hospital's network. The iFrame can be seamless from the patient's perspective, and can post payments in real-time.
3. Implement: options that provide the highest security at the lowest PCI scope
Before P2PE existed, an enterprise audit or network segmentation were the only options to achieve PCI compliance. P2PE was developed to replace these options and to improve security, reduce scope, and cut costs for compliance. Therefore, providers should be making plans to include PCI-validated P2PE as their PCI compliance strategy for in-person and over-the-phone payments.
For patient payments, several factors will drive the implementation decision between a third-party payment portal and a secure iFrame. The most important consideration is whether the provider's strategic direction includes taking payments on the hosted EHR. If so, it is critical to design the payment process using the secure iFrame. For providers that prefer a third-party payment portal, then PCI compliance scope for patient online payments is effectively outsourced.
4. Stay vigilant: by continuously evaluating your data security
Compliance is neither a sprint nor a marathon; it's a race without a finish line. Combined with proactive staff training, PCI compliance can help hospitals preserve their reputation and meet patient expectations for secure payment. But compliance isn't something that happens once a year during an audit. As long as hackers continue to hone existing weapons and create new ones, hospitals, technology partners, and the PCI Standards themselves must continue to evolve.
About the author
David King, co-founder and CTO of OnPlan Health, has over 20 years of experience in the payments space including in healthcare and higher education. He was on an advisory group to the PCI Security Standards Council from 2006 through 2010 and also served as a member of the National Automated Clearing House Association (NACHA) Council for Electronic Billing and Payments. King has presented extensively across the US and Australia as an expert in data security and compliance.
1 In 2016, the average deductible for single coverage was $1,478 for people whose insurance was covered by employers. See: http://kff.org/report-section/ehbs-2016-summary-of-findings/.
The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of Becker's Hospital Review/Becker's Healthcare. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.