The Convergence of Health Care and Banking

Posted by John Barnes on February 15, 2013

Bank Steth.pngContributed by Marcia L. Augsburger as part of the ongoing Compliance Matters series

      On January 25, 2013, the Office of Civil Rights (OCR) within the Department of Health and Human Services published guidance on whether banks and other financial institutions must comply with the Health Insurance Portability and Accountability Act (“HIPAA”) when they receive, transmit, use or disclose Protected Health Information (“PHI”) - patient-specific health information created by health care providers, health plans, health care clearinghouses, and other specified entities. 

      The OCR clarified that financial institutions are not required to comply with HIPAA when they conduct certain payment processing activities.  These activities include cashing a check, conducting a funds transfer, and authorizing, processing, clearing, settling, billing, transferring, reconciling, or collecting payments for health care or health plan premiums.

      However, OCR instructed that a financial institution may be a “business associate,” which must comply with HIPAA, where the institution performs functions “above and beyond” payment processing activities “on behalf of a covered entity,” such as accounts receivable functions on behalf of a physician, hospital, or other health care provider.  OCR did not describe what is “above and beyond payment processing” or define “accounts receivable functions.”  For health care providers, “accounts receivable functions” include payment processing activities and billing, but they may also include mailing letters to patients who are behind on payment, reviewing the terms of coverage agreements and provider contracts with health plans and other payers and applying them in dealing with patients, setting up payment schedules, and tracing changes to patient addresses.  Presumably, financial institutions performing these kinds of activities on behalf of providers are business associates.

      Thus, unlike other entities, whether financial institutions must comply with HIPAA does not turn on their receipt, disclosure, or use of PHI.  If this were the test, all banks would be business associates according to experts who have estimated that 40% of the information contained in most bank lockbox accounts meets the definition of PHI.  However, OCR instructs that the focus is on the nature of the information but on what financial institutions are doing with the information.

      If you are a bank or other financial institution that is performing an activity beyond processing payment, such as an accounts receivables function, you need:

  • Internal audits of current practices and a risk assessment;
  • Written HIPAA policies and procedures based on the results of the audits and risk assessment;
  • Workforce training on HIPAA designed around the activities and the results of the audits and risk assessment;
  • Contract review, development, and negotiation;
  • Assurance that existing methodologies render PHI “secure” within the meaning of HIPAA and take advantage of “safe harbors”;
  • Information about compliance deadlines and fast-paced modifications to HIPAA law;
  • Experienced legal analysts equipped to perform compliance audits and risk analyses, make compliance recommendations, deal with covered entities and other business associates, and offer informed and educated mitigation advice;
  • Support in responding to any potential breaches of PHI;
  • Representation when a breach occurs; and
  • General guidance from qualified health care attorneys on HIPAA, HITECH, and other federal and state privacy regulations.

DLA Piper’s Health Care Practice Group offers unique expertise in issues relating to financial and claims’ services, from regulations to coding.  Our attorneys also work with consultants and experts who focus on assisting financial institutions with expanding their health care service revenues.  We can assist with education and training, operations, and transactions in the health care industry.  For further information, please contact Marcia L. Augsburger at marcia.augsburger@dlapiper.com.

HIPAA and Emerging Technologies

Posted by Rebecca Jones McKnight on December 12, 2011

DocWithiPhone.jpgContributed by Marcia Augsburger and Scott Koller.

The Health Insurance Portability and Privacy Act of 1996 (HIPAA) is 15 years old this year – still acting a bit like an uncertain, wide-eyed teenager responding to new developments. Although more mature, clarified by regulations, and supplemented by the HITECH Act, at its core HIPAA has remained relatively unchanged since its enactment. Societal changes implicating HIPAA, however, have been significant. Over the past five years alone, we saw the rise of Facebook, the domination of Google, and the introduction of powerful personal electronic devices such as Apple’s iPhone and iPad. In addition, technologies such as cloud computing, wireless communication, and telemedicine have reached a level of reliability and affordability that has allowed healthcare providers to expand their reach and services. With every emerging technology, the specter of HIPAA compliance remains a key concern, while its application becomes more murky. 

HIPAA was designed to be technology neutral. Accordingly, the statute is worded in terms of principles of compliance instead of specific measures to be implemented. While this permits flexibility so that the law can continue to be relevant as time and technology progress, it also creates ambiguity. Indeed, so ambiguous are HIPAA statutes that there continues to be a debate over its application to a technology as ubiquitous as email.

Nonetheless, HIPAA offers a methodical, step-by-step process for reviewing new programs, applications, and technologies to ensure technical safeguards are in place. The safeguards cover five areas:  Access controls; audit controls; integrity controls, authentication, and transmission security.  This article addresses each of these, and explains the challenges they present in evaluating compliance issues as applied to emerging technologies.   

I.          Access Controls

The first area addressed by the Technical Safeguards deals with Access Control. HIPAA requires the covered entity (CE) or business associate (BA) to implement technical policies and procedures that allow only authorized persons access to protected health information (PHI).[i] Apart from this rather broad requirement, HIPAA left the implementation of access controls to CEs and BAs, who may select the technologies that best fit their organizations, so long as the controls are consistent with the four areas of focus within the Access Control standard. The controls must include a unique user identification system, emergency access procedure, automatic termination with inactivity, and encryption.

            A.        Unique User Identification (Required). HIPAA requires each user to be assigned a unique name or number.[ii] The purpose is to allow the CE to track specific user activity and to hold those users accountable for functions performed while logged into covered systems. When selecting an identification scheme, CEs and BAs should consider how the unique identifier will be used internally and externally. If the identifier is used primarily within an organization by employees, then an entity may use the employee name or similar variation (e.g., jsmith). However, using a random set of numbers and characters may be preferred if the name itself may express PHI (e.g., jsmith on a list of Alcoholics Anonymous members).[iii]

System designers must also be careful to limit the use of the selected unique identifiers. Software programmers for Apple’s iPhone learned this lesson the hard way when, at Apple’s suggestion, they identified specific users using the unique device identifiers (UDID) that were built-into iPhones.[iv] These UDIDs were accessible by other apps, some of which had significantly less security in place for the protection of personal information.  By using the same UDID, the protection accorded that identifier is only as good as the least secure app using the identifier. This illustrates the advisability of avoiding a user identification scheme that other applications or software also use.   

            B.        Emergency Access Procedure (Required). The CE must have a procedure in place for obtaining necessary electronic PHI (ePHI) during an emergency.[v] In an emergency, especially where a natural disaster cuts off power, electronically stored information is imperiled. After all, the lifeblood of technology is electricity. To determine the need for back-up generators or paper files, CEs and BAs should evaluate from the outset what information will be needed in an emergency for patient care and treatment and how best to create redundancies to preserve it. 

            C.        Automatic Logoff (Addressable)[vi]. When reasonable and appropriate, a CE must implement electronic procedures that terminate an electronic session after a predetermined period of inactivity.[vii] This is particularly important when dealing with applications for personal electronic devices such as smart phones, which are highly portable and can be easily misplaced. While HIPAA does not mention a specific timeframe, the termination or logoff function should take into account the likelihood of an unauthorized user encountering the system. In addition, screensavers and/or automatic logoffs, which are built into many systems, should always be enabled. 

            D.        Encryption and Decryption (Addressable). To take advantage of a HIPAA “safe harbor,”[viii] CEs must use encryption to protect data from unauthorized access.[ix] Of the four Access Control safeguards, encryption is by far the most difficult to implement. Whereas a unique identifier, an emergency back-up, and an automatic log-off are fairly easy to implement, encryption involves the use of complex algorithms and a series of confidential “keys” used to code or access the data. 

At the core of every encryption scheme is a mathematical algorithm, the strength of which depends on its key-length size or bits. HIPAA does not mandate the use of any specific type or strength of encryption.  Most financial institutions use 256 bit encryption for banking transactions, while several reputable e-commerce sites use key lengths of 128 bits to process credit cards. Although HIPAA permits flexibility, it would be inadvisable to implement a key shorter than 128 bits. To put this in perspective, it would take a modern computer 149,745,258,842,898 years to break a 128 bit key whereas the same computer could crack a 64 bit key in approximately four minutes.[x] 

Even if a lengthy key is used, a mistake or flaw in the mathematical formula can render the entire encryption scheme vulnerable. New or customized encryption schemes pose a greater risk of discoverable flaws than encryption algorithms that have been certified by the National Institute of Standards and Technology (NIST).[xi]  This may explain why using NIST standards for encryption qualify as a “safe harbor” under HIPAA.[xii]

In addition to using flawed or short encryption keys, a common mistake in encryption is failure to secure the key itself. When online whistle-blower website WikiLeaks distributed classified government cables to the press, it used a top of the line AES-256 bit encryption but failed to secure the key. The key was published, rendering the entire encryption scheme useless. The security surrounding encryption keys, including old and retired keys, should receive the same level of scrutiny as the data they are protecting. 

This is part one of a three part series discussing HIPAA and emerging technologies.  Part two explores Authentication, Audit and Integrity controls under HIPAA. 

 

 

 

[i] 45 C.F.R. § 164.312(a) for covered entities and business associates under the HITECH Act. 

[ii] 45 C.F.R. § 164.312(a)(2)(i).

[iii] Department of Health & Human Services (DHHS), Security Standards. Published 5/2002, revised 3/2007 (“A randomly assigned user identifier is more difficult for an unauthorized user (e.g., a hacker) to guess, but may also be more difficult for authorized users to remember and management to recognize.” 

[iv] Hardawar, Devindra, Apple phasing out iOS UDID access to solve privacy woes. Retrieved September 18, 2011, from http://venturebeat.com/2011/08/23/ios-5-udid-privacy/.

[v] 45 C.F.R. § 164.312(a)(2)(ii).

[vi] DHHS provides flexibility to covered entities. stating whether a specification is "required" or "addressable." If the specification is "required," the CE must implement the specification as stated in the Security Rule. If the specification is "addressable" then the CE must:1. Assess whether the specification is a reasonable and appropriate safeguard in its environment and likely to contribute to protecting the entity's electronic protected health information; and 2. Implement the specification or document why it would not be reasonable and appropriate and implement an equivalent alternative measure if reasonable and appropriate. DHHS, What is the difference between addressable and required implementation specifications in the Security Rule? Retrieved September 19, 2011 from http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2020.html.

[vii] 45 C.F.R. § 164.312(a)(2)(iii).

[viii] Specifically, HHS has stated that if an organization uses recommended technologies and methodologies that render PHI unusable, unreadable, or indecipherable to unauthorized individuals, then that PHI would not qualify as “unsecured” PHI for purposes of the breach notification requirements, which only applies to “unsecured” PHI. “Guidance Specifying the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements Under Section 13402 of Title XIII (Health Information Technology for Economic and Clinical Health Act) of the American Recovery and Reinvestment Act of 2009; Request for Information,” 74 Fed. Reg. 19006 (April 27, 2009)

[ix] 45 C.F.R. § 164.312(a)(2)(iv)

[x] Clayton, Richard, Brute force attacks on cryptographic keys. Retrieved September 18, 2011, from http://www.cl.cam.ac.uk/~rnc1/brute.html.

[xi] National Institute of Standards and Technology, Computer Security Division. Retrieved September 18, 2011 from http://csrc.nist.gov/.

[xii] “Guidance Specifying the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements Under Section 13402 of Title XIII (Health Information Technology for Economic and Clinical Health Act) of the American Recovery and Reinvestment Act of 2009; Request for Information,” 74 Fed. Reg. 19006 (April 27, 2009).

Worried about Employees Snooping for Patient Information? Worry More.

Posted by John Barnes on July 27, 2011

'Money tunnel' photo (c) 2010, Keith Ramsey - license: http://creativecommons.org/licenses/by-sa/2.0/

Contributed by M. Scott Koller as part of the Privacy Matters series. 

Hospitals are facing increased scrutiny over the privacy of patient medical records.  An investigation by HHS’s Office of Civil Rights concluded that a Southern California hospital failed to reasonably restrict access to patient information to only those employees with a valid reason to view the information.  A link to the OCR's decision is here.  As part of the settlement with Department of Health and Human Services, the hospital must implement new privacy and security policies approved by OCR, to conduct regular trainings for all employees with access to protected health information, to sanction offending employees, and to designate an independent monitor who will assess the hospital’s compliance over the next 3 years. 

Interestingly enough, this settlement comes on the heals of a dramatic increase in enforcement activity by the HHS.  The most recent enforcement action is the third major settlement to be announced this year.  In fact, the first monetary penalty imposed by the HHS for violations of the HIPAA Privacy took place on February 22, 2011 when HHS fined Cignet $4.3 million for failing to provide 41 patients with access to their medical records.  That same month, Massachusetts General Hospital paid the HHS $1 million in connection with the loss of 192 billing records for HIV/AIDs patients.  The HHS confirmed the renewed focus on HIPAA violations in a statement by OCR’s Director Georgina Verdugo stating, "We hope the healthcare industry will take a close look at this agreement and recognize that OCR is serious about HIPAA enforcement." 

As a result, covered entities should take this opportunity to take a close look at their HIPAA compliance programs in light of the HHS’s increased enforcement efforts.  Contact John Barnes if you would like to discuss strategies for protecting your organization from such sanctions. 

You Aren't Necessarily Home Free If Your Handling of Private Health Information Complies with Federal Law: Compliance with State Law is Also Required, at Least in California

Posted by John Barnes on July 14, 2011

PRIVATEphoto © 2011 Rupert Ganzer | more info (via: Wylio)

Contributed by Marcia Augsburger as part of the ongoing Privacy Matters series.

In a closely watched decision, the California Supreme Court has ruled that the federal HIPAA privacy law does not preempt California privacy laws. 

The case, Brown v. Mortensen, 51 Cal.4th 1052 (2011), available here, addressed whether federal privacy law, specifically Health Insurance Portability and Accountability Act ("HIPAA") and the Fair Credit Reporting Act ("FCRA"), preempts California state law, specifically the Confidentiality of Medical Information Act (Civil Code sections 56 et seq.), which provides for compensatory damages and other remedies.  The Court held preemption does not apply, overturning the decisions in the courts below.

In the wake of this decision, compliance and privacy officers in California need to ensure that their entities' practices comply with both state and federal statutory schemes. 

More about the decision after the jump.

 

Continue Reading

HHS Imposes First-Ever Civil Money Penalties for HIPAA Privacy Rule Violations

Posted by Kim Egan on March 07, 2011

Contributed by Darrell W. Taylor and Kate Lucente as part of our ongoing Privacy Matters series.

privacy.jpg

The US Department of Health and Human Services has imposed the first-ever civil monetary penalty for alleged violations of the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule: $4.3 million in total.

 

In late February, HHS fined Cignet Health of Prince George’s County, Maryland $1.3 million for allegedly denying patients access to their own medical records and an additional $3 million because Cignet failed to cooperate with HHS’s investigation from the start.

 

According to HHS, Cignet ignored government subpoenas for patient medical records for more than a year.  HHS went to court to enforce the subpoena; Cignet failed to answer and the court entered a default judgment against the company. 

 

As permitted by the HITECH Act’s “willful neglect” provision, HHS assessed $50,000 a day for 27 separate complaints on Cignet, assessing up to the maximum $1.5 million per year for calendar years 2009 and 2010 – a total of $3 million.

In its investigation, HHS looked at 41 individual complaints from Cignet patients about Cignet’s denial of access to medical records.  HIPAA requires that a covered entity provide patients with a copy of their medical records within 30 (and no later than 60) days of the patient’s request.  Cignet did deliver the patient records to HHS, but not until April 2010, after the default judgment had already been entered against it.  HHS notes that Cignet also never provided the patients with their records and “otherwise made no efforts to resolve the complaints through informal means.”

 

HHS states it “will continue to investigate and take action against those organizations that knowingly disregard their obligations under these rules.”

 

HHS Secretary Kathleen Sebelius said in a press release that “[e]nsuring that Americans’ health information privacy is protected is vital to our health care system and a priority of this Administration. The U.S. Department of Health and Human Services is serious about enforcing individual rights guaranteed by the HIPAA Privacy Rule.”

OCR Issues Risk Analysis Guidance on HIPAA

Posted by Kim Egan on July 21, 2010

Contributed by risk.jpgDarrell W. Taylor as part of our ongoing Privacy Matters series.

The Department of Health and Human Services Office for Civil Rights (OCR) has released its first annual security guidance on the Health Insurance Portability and Accountability Act (HIPAA) to implement changes required by the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act).  The HITECH Act was enacted last year as part of the American Recovery and Reinvestment Act of 2009.

To assist covered entities and business associates (collectively, organizations) in complying with HIPAA security standards, the HITECH Act requires HHS to issue annual guidance on the “most effective and appropriate technical safeguards” for compliance with the HIPAA security regulations (Security Rule).  Accordingly, HHS must release a series of guidance materials to assist organizations in identifying and implementing administrative, physical and technical safeguards to protect the confidentiality, integrity and availability of electronic protected health information (e-PHI) and must update these materials annually.

The first such materials, released on July 14, 2010, are entitled “HIPAA Security Standards: Guidance on Risk Analysis” (also called the HHS Draft Guidance).  The HHS Draft Guidance addresses the Security Rule’s risk analysis provision, which requires an organization to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of e-PHI held by the covered entity.  A risk analysis is the first step in Security Rule compliance, and the HHS Draft Guidance describes the outcome of the risk analysis process as “a critical factor in assessing whether an implementation specification or equivalent measure is reasonable and appropriate.”

While the HHS Draft Guidance does not mandate a one-size-fits-all method for conducting a risk analysis, it does set out the following elements that should be incorporated into any organization’s assessment of current security measures and potential risks to e-PHI. 

Considerations for a risk analysis after the break:

 

Continue Reading