Primary Care Coding Alert

 Let our experts help you understand these complex confidentiality concepts.

How well do you know the Health Insurance Portability and Accountability Act, or HIPAA? Enough to bust these myths?

Take a look at these three common misunderstandings about this important component of your job as a coder, learn how to protect your patients’ protected health information (PHI), and stay compliant.

Myth 1: Only information about a patient’s health is protected by HIPAA.

“PHI by definition is protected health information, notes Barbara Hays, CPC, CPCO, CPMA, CRC, CPC-I, CEMC, CFPC, medical review supervisor, special investigations, GEHA in Lee’s Summit, Missouri. “If a record is completely de-identified in a such a manner that it cannot possibly be connected to an individual, then no, that would not be protected. Technically, it is no longer PHI,”” Hays further explains.

So, PHI is demographic information as well as information about a patient’s health, and when health information can be linked to a specific individual via one of 18 different identifiers, it is regarded as protected. Those identifiers include such things as a person’s name, Social Security number, physical and electronic mail addresses, telephone numbers, license plate numbers, and account numbers. (For the full list, go to: www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/coveredentities/De-identification/hhs_deid_guidance.pdf.)

But remember this (1): “If there are unlisted identifiers, PHI still needs to be protected. So, for example, if the information identifies a man who just returned to a small town from being overseas in the Marines, though that itself is not PHI, townspeople would easily be able to identify this person and thus, the information needs to be protected,” notes Suzan Hauptman, MPM, CPC, CEMC, CEDC, director, compliance audit, Cancer Treatment Centers of America

Myth 2: In order to release a patient’s PHI to another provider, you must have a patient’s written authorization.

“Unfortunately, this myth does not have a clear yes or no answer — it depends on the situation,” says Hays. For the release of “protected health information for treatment, payment, and healthcare operations” the “Privacy Rule permits, but does not require, a covered entity voluntarily to obtain patient consent” according to the U.S. Department of Health & Human Services (HHS) (Source: www.hhs.gov/hipaa/for-professionals/faq/264/what-is-the-difference-between-consent-and-authorization/index.html).

But remember this (2): Consent must be accompanied by verification of the patient’s identity. If the patient cannot give consent in person, then you must obtain it through verifying such patient information as the patient’s date of birth or the last four digits of the patient’s Social Security number, via a phone call or a secure email through a patient portal.

For release of PHI for purposes other than treatment, payment, and healthcare operations, however, you will need an authorization, which the Privacy Rule defines as “a detailed document that gives covered entities permission to use protected health information … to disclose protected health information to a third party specified by the individual.” The document must specify and include, where appropriate, “a description of the protected health information to be used and disclosed, the person authorized to make the use or disclosure, the person to whom the covered entity may make the disclosure, an expiration date, and, in some cases, the purpose for which the information may be used or disclosed,” according to the Privacy Rule.

Myth 3: Electronic PHI must be encrypted to be HIPAA compliant.

Believe it or not, this is a myth, though it is certainly in the interests of any covered entity to take this, and every possible, precaution to safeguard electronic PHI (ePHI).

The myth is busted in the HHS paper, “Security Standards: Technical Safeguards,” where HHS outlines four implementation specifications for “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.” Of the four, only two — unique user identification and an emergency access procedure — are required. The two others — encryption and decryption, along with an automatic logoff — are not (Source: www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf).

Why? Clearly, an institution has to do something to safeguard the computers, phones, or other technology that it uses to store and transmit ePHI, and encryption is ideally suited for that purpose. But if after a risk analysis an institution decides that encryption will not help them protect ePHI from “anticipated threats and hazards” in a “reasonable and appropriate way,” then the entity must “implement an equivalent alternative measure,” according to another HHS document, “Security 101 for Covered Entities” (www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/security101.pdf).

In other words, encryption is not required to protect ePHI, but it is more than just a pretty good idea. Simply put, PHI “should not be sent to insecure emails or personal email addresses your healthcare organization [uses to] communicate with patients via email; you should develop a process that includes authorization and encryption protocols. Having a patient portal is a much more secure environment,” Hauptman notes.