Compliance, Incentives and Penalties: Hot Topics in US Health IT

Transcription

1 Compliance, Incentives and Penalties: Hot Topics in US Health IT Table of Contents Introduction... 1 The Requirements... 1 PCI HIPAA ARRA Carrot and Stick How does third party assurance fit into the overall HIT picture?... 3 Before and After Trusted and Qualified Relevant About ICSA Labs... 4 Authors Al Potter Stephen Gaus Amit Trivedi

2 Introduction American Recovery and Reinvestment Act (ARRA) and the HITECH Act recently celebrated their second anniversary since they were signed into law by President Obama. It has only been one year since the law became effective, but Uncle Sam means business. Health Information Management (HIM) and Information Technologies (IT) departments in the Healthcare Provider industry now have increased privacy, security, reporting, compliance and remediation requirements. CFOs are struggling with how to fund these requirements. Adoption of new Electronic Health Records (EHR) technology does offer substantial financial incentives through It has been called the present day moon launch as the Federal appropriations funding the program match the scale of those for the original moon launch. Failure to adopt and comply can also mean financial penalties. Violations of HIPAA regulations can lead to fines, penalties and even criminal convictions with prison sentences. Delays and failure are no longer tolerated outcomes. This paper examines some aspects of the state of the USA s HIT (Health IT) with respect to security. The Requirements Some of the most noteworthy requirements for security in the USA s Healthcare Provider IT market are: PCI HIPAA BAA ARRA HITECH (HIPAA II) covered entity Only one of these requires true independent testing and certification of individual components or modules in the IT environment: the ONC-ATCB (Office of the National Coordinator Authorized Testing and Certification Body) program for certification of Electronic Health Records (or their components) in support of qualifying for meaningful use incentives under HITECH/ARRA. All of the other requirements are upon the IT or organizational environment to assess (today through self assessment, in the future via independent audit), and manage. Let s examine some details. PCI At first glance, one might question the relevance of PCI to a discussion of HIT, but consider the following: most, if not all, health care organizations in the US accept credit cards, and therefore have to be PCI compliant. The systems that accept and process payment cards are most likely in the same physical environment as, and most likely networked with, the systems which store and process patient information. While the compliance domains for PCI and the other requirements are likely not exactly the same, there is very likely an overlap, and that is good news from one perspective at least. The PCI DSS is a relatively mature standard at this writing, and while it is specific to payment card data, the general intent is to protect sensitive information, to prevent breaches and to detect them and limit their impact when they do occur. At a high level, these goals are common with several of the other regulations listed above. While the PCI DSS is not rocket science in that it merely captures what most security professionals would recognize as baseline industry best practices, it is quite specific in its requirements. HIT organizations can leverage the specificity of the PCI DSS requirements. Applying required PCI controls outside the strict confines of the PCI compliance domain (where practical) means providing the same level of protection to other (patient data) sensitive information. PCI does not require third party certification of specific required components in the environment. Nonetheless, an organization which requires components to be certified by a third party can clearly demonstrate more than baseline diligence. Further, ICSA Labs has mapped ICSA Labs Certification Criteria to PCI DSS, so HIT shops selecting ICSA Labs certified components know which individual PCI requirements the component is capable of satisfying. Page 1 of 4

3 HIPAA Covered entities which now include what were previously known as Business Associates, must now comply with the requirements of the HIPAA Privacy and Security Rules by conducting risk analyses and implementing physical, administrative and technical safeguards that each covered entity determines as reasonable and appropriate. This typically involves the 3 P s: Policies, Process and People. Breach notification requirements will increase the administrative burden for healthcare providers but more significant are the fines, penalties and risk of other real financial consequences to include plaintiff s lawsuits and/or increased insurance premiums. The administration has put sufficient safeguards and teeth into place so providers now have sufficient motivation for true root cause analysis and remediation. The inherent transparency required by the new reporting requirements should also help eliminate the sweep it under the rug or don t ask don t tell modus operandi that was previously too often the norm or accepted behavior. Use of third party assurance programs as part of the component selection process and following industry best practices (perhaps best illustrated in PCI DSS), while not explicitly required by HIPAA, allow organizations to clearly demonstrate that they are thoughtfully and methodically diligent in their efforts to satisfy not only the letter but the spirit of the law; therefore, it generally exceeds the HIPAA standard of reasonable and appropriate. Insurance underwriters and carriers will help provide the first wave of independent assessments as they grapple with risk, its mitigation, and the necessary building of actuarial pools to fund the consequences of breaches or incidents for their policy holders. ARRA ARRA s HITECH Act provides substantial financial incentives for healthcare providers who can demonstrate meaningful use of certified HIT. The requirement to use certified HIT is similar to PCI in that it requires specific technologies (EHRs and/or their modules) but it differs in that it requires those components to be certified. The Office of the National Coordinator (ONC) within the U.S. Department of Health and Human Services (HHS) has, in cooperation with American National Standards Institute (ANSI), National Institute of Standards and Technology (NIST) and others, established a program whereby ONC Authorized Testing and Certification Bodies (ONC-ATCB) can test and certify EHRs, either in totality or component modules, making healthcare providers eligible to demonstrate meaningful use (as defined by the ONC) to qualify for the ARRA incentives of up to $44,000 per provider for Medicare and $65,000 per provider for Medicaid. The payer mix determines which incentive is applicable per provider. In December 2010, ICSA Labs became an ONC-ATCB and has been accepting complete EHRs and EHR modules for testing and certification. The program requires that specific security related functionalities such as authentication and access control, encryption, and the capability to generate audit logs are present in any technology that is certified. Carrot and Stick Two of the stated intents of the ARRA HITECH Act are improved patient outcomes and reduced costs through the deployment and adoption of EHRs. ARRA provides financial incentives to encourage adoption and meaningful use of these EHRs. The first wave is focused on providers utilizing technology for electronic prescriptions. Reading the fine print one quickly realizes that what today and for the next few years is an incentive for adoption also introduces penalties for lack of adoption, or the proverbial carrot and stick approach. In 2015, the rules for Medicare reimbursement change. After the transition, healthcare providers billing Medicare through other than electronic means will be Page 2 of 4

4 reimbursed at reduced rates. In other words, those providers who have not adopted EHRs and demonstrated their meaningful use will be financially penalized. Non-compliance is not really a viable business model. How does third party assurance fit into the overall HIT picture? Third party assurance programs (like the product testing and certification programs operated by ICSA Labs) offer additional information to the consumer purchasing security products, potentially both before and after the sale. This information takes on the form of a certification from a trusted, qualified (more on that later) third party indicating that the product or device in question meets or passes the requirements of a relevant published standard. Let s look at some of the italicized notions above. Before and After ICSA Labs and some other certification programs like the ONC-ATCB program for EHRs deliver assurance before and after the purchase point. The pre-purchase assurance should be obvious. Post-purchase, or more accurately, post-certification is where it gets interesting. Both ICSA Labs and the ONC-ATCB programs contain provisions which require the certified item to be retested, either on some stated interval or upon release of an updated version. By requiring this retesting feature in a certification program, the consumer (or the government) receives assurance after the certification (or purchase) point. Trusted and Qualified In the world of assurance, formal standards exist for the various entities involved. ISO applies to the qualification of a testing lab, ISO Guide 65 to the certification body. ONC will require accreditation to and Guide 65 when the permanent EHR certification program comes on line in Today, under the rules of the temporary program, the ATCB is required to satisfy these ISO requirements, but in the interest of getting the new program up quickly, ONC does not currently require external accreditation, but rather a self assessment. Nonetheless, ICSA Labs anticipated the need to be able to demonstrate trustworthiness and qualification several years ago and is accredited to ISO by ANSI (a multi-year project). ICSA Labs accreditation to Guide 65 is underway. Relevant In the area of EHRs, the question of the relevance of third party assurance is simple. In order to qualify for the available incentives (and to avoid future penalties) the healthcare provider must demonstrate meaningful use of certified health IT. The word certified and the rules in place mandate that the EHR technologies involved be certified whether they are commercially available products or custom developed. For the rest of the compliance requirements facing health IT today, there is no requirement for the IT components to be certified. Nonetheless, going back to the language of the code and being able to demonstrate or even to exceed the standard of reasonable and appropriate can help mitigate the risk of fines, penalties, damages or increased insurance premiums. Remember that all of the requirements we have discussed have some aspects in common: A stated goal of protecting sensitive data (in its various states of in motion, at rest, in use or data disposed ) and potentially limiting the scope of damage in the event of a breach. Teeth in the form of incentives for adoption and compliance in the ARRA HITECH Act and penalties for disclosures and breaches as well as reduced reimbursements. Page 3 of 4

5 IT departments specify software, networking, security and other IT components. They typically oversee the implementation, management and break / fix through its life cycle. Their configuration is designed to solve business requirements while satisfying compliance requirements. It is reasonable to assume that the IT staff would want to make the best, most well-informed decisions when selecting components of the network security solution that will help the organization maintain compliance. Tasks to consider when selecting and configuring these components (firewalls, VPN concentrator and other security devices) and others may now include risk management, mitigation and the ability to demonstrate reasonable and appropriate safeguards. Independent third party assurance of the components capabilities could prove useful for compliance and risk mitigation. A recent industry periodical estimated the cost per breached record to be in excess of $185 each. This can quickly add up if there are thousands of records that are breached. While independent certification testing of the components on the entire compliance domain is not a requirement of the programs in those cases, it is clearly something that bears consideration as an additional requirement imposed internally. About ICSA Labs ICSA Labs is an independent division of Verizon Business which has been providing credible, independent, third party product assurance for end users and enterprises for over 20 years (since 1989). A compelling feature of the certification programs operated by ICSA Labs is the continuing assurance offered by periodic re-testing after the initial certification point. This provides significant additional assurance value to an organization which not only requires ICSA Labs certified products, but which requires their product suppliers to maintain ICSA Labs certification in subsequent years. When considering and selecting security products, it is important for IT staff to determine which products offer independent third party assurance and to and give preference to products which are ICSA Labs Certified. ICSA Labs helps enterprises make better informed purchasing decisions by providing testing and certification of security products and solutions for many of the world s top security product developers and service providers. Enterprises can rely on ICSA Labs to set and apply objective testing and certification criteria for measuring product compliance and performance. Details on ICSA Labs product certification programs including certification criteria, a list of certified products, certification testing reports, etc., are available at no charge to the end user at Copyright 2011 Cybertrust. All Rights Reserved. WP /11.