Back

Secure the Silver

While most healthcare organizations work on securing PHI there is usually one element that I’ve found that isn’t secured with the same rigor as most other physical PHI; X-rays. X-rays waiting for disposal companies to come and haul them away are usually left unsecured and not monitored. The problem is that individuals have found that they can recover the silver found within the film. While it isn’t a lot of silver (roughly 2% of the film’s weight) a few hundred pounds could make it a lucrative venture. That’s why it’s not surprising that thieves have begun stealing them. Let’s be honest here, when was the last time you checked the credentials of the crew coming to take away what you would consider to be garbage? The issue here isn’t that these films will be used for identity theft purposes, it’s that you are now forced to go through breach notification procedures at your cost… for what is technically considered refuse! Three organizations in Pennsylvania already had to go through this as they’d fallen victim to thieves stealing the films from unsecured areas, and in one instance posing as a radiological film destruction company. What can you do? Start securing X-rays and make sure they aren’t accessible to unauthorized parties, regardless whether the file is useful or scheduled for destruction. Many organizations store the X-rays near the equipment in semi-open rooms. If the rooms aren’t used 24×7 then you should either secure the room when not in use using your normal physical security system (key, badges, dragons, etc.) and monitoring equipment. If you don’t want to go to such extreme measures (I hear dragons eat a lot) then you may consider digitizing your x-rays and then securely dispose of the physical copies. Otherwise you may want to start recovering the silver yourself to help pay for the breach notification efforts you might find yourself facing.

Further reading:

Back

Data Breach Alphabet Soup

Theodore J. Kobus III published his A to Z of Healthcare Data Breaches, which he presented at the annual America Society for Healthcare Risk Management conference. This list may be ideal to use or model your own internal training after for more than just data breaches. Initially I thought of trying to showcase some of them in a silly reference; but I thought it might be too OPAQUE.

O – Overreacting is not going to get you through the event

P – Preparedness is key

A – Accept that it will happen to you

Q – Quit keeping old data

U – Understand the laws that impact your organization

E – Empathize with your customers/patients/employees – how are they going to react to your response?

In all seriousness; Q and A (no pun intended here) are both important and I wanted to point those two out. If you don’t need the data, as an organization you need to ask yourself, “what are we gaining by keeping this data?”  The liability is attached to every piece of information you retain regardless if you use it or not.  Having (and following) data retention policies will limit such a liability. Accepting that it is going to happen, now that’s a hard pill to swallow.;but similar to Emergency Preparedness techniques that many organizations routinely practice.  As they say, practice makes perfect even if you never have to use those techniques.  Organizations that routinely train for various circumstances are the ones best prepared to handle them.  If you accept that a data breach is going to happen, you’ll find yourself equipping and (more importantly) training for how to respond.  Whether you attach this to existing emergency practices or not is not as important as actually having a response.  Many organizations have suffered both from a Public Relations perspective and financially (fines) by their seemingly lack of response. In the end, training staff how to deal with data breaches because you accept that it will happen will yield positive results from a negative situation.  It’s amazing how people remember what to do during emergency situations; I still remember to get under my desk during an earthquake.

Back

PCI PA-DSS in Healthcare – Part 2

What Can I Do?

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:

  • Compile a list of potential applications and check the PA-DSS validated list at the PCI SSC’s website – https://www.pcisecuritystandards.org/security_standards/vpa/
    • 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.

References

PCI Council Sites / Documents of Interest:

Additional Sites / Documents of Interest:

Back

DEA Electronic Prescription of Controlled Substances – Certification Clarification

On October 16th, 2011 the DEA released a series of clarifications regarding the requirements for Electronic Prescriptions of Controlled Substances (EPCS). While overall this clarification was very helpful and confirmed the comprehensive nature of the certification process, it did introduce / revive a concept that triggered several calls and inquiries. More specifically, DEA listed a company that has been certified to conduct DEA EPCS Certifications, which raised excellent questions:

  • Why is NetSPI not listed on their website?
    (Answer: We don’t need to be; we meet other requirements that make us qualified certifiers)
  • Is NetSPI allowed to certify our application before you are listed on DEA’s website?
    (Answer: Yes)

According to 21 CFR 1311.300(a), there are two alternative processes for achieving the necessary qualifications:

  1. A third-party audit conducted by a person qualified to conduct a SysTrust, WebTrust or SAS 70 audit or a Certified Information System Auditor as stated in 21 CFR 1311.300(b), which comports with the requirements of paragraphs (c) and (d) of 21 CFR 1300.300” or
  2. A certification by a certifying organization whose certification process has been approved by DEA

Therefore, the certification process emphasized within the clarification is simply one of the alternatives, and is in no way required or mandatory.  While the principal consultant involved with the EPCS Certification is a Certified Information System Auditor (CISA) in good standing, there should not be any issues with qualifications.  Experience with SysTrust, WebTrust, or the slightly outdated SAS-70 (in my opinion) are more a derivative of training provided by ISACA as part of CISA. The bigger question would be whether having appropriate qualifications is the only measure by which you should select your certifying agent. This is where things like experience with certifying applications in other standards, experience in healthcare, and understanding of software development lifecycle can be significant differentiating factors.  Certainly, like with any other regulatory standard, there will be (perhaps already are) many low-cost, rubber-stamp firms that might get you the certification letter you are seeking.  They may let you replace application controls with policies and documentation, conduct the whole assessment by phone, and turn the whole certification process around in 24 hours.  However, obtaining the certification is only the first step in the long journey of maintaining DEA EPCS compliance.  If your client decides that your application does not meet requirements or is in violation of EPCS, you will have to investigate all such claims and if confirmed, announce to all of your customers that they can no longer use your application to prescribe or accept electronic prescriptions of controlled substances. (21 CFR 1311.302)  While it may seem appealing to take a run at getting through the certification fast, trust me, taking this shortcut is not a good idea, and any perceived savings of time and money will likely come back to haunt you in the future.  Going for the low-cost auditor in this case may actually be the most expensive option.

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X