Filefax, Inc., a defunct Illinois medical records storage and management company, has been fined $100,000 for improperly handling medical data under an agreement with the court-appointed receiver managing the company’s assets on behalf of its creditors.  This settlement has implications for both service providers and their covered entity clients.  Fox Rothschild partners Elizabeth Litten and Michael Kline were quoted in an article by Marla Durben Hirsch entitled “Be prepared for HIPAA Issues if a business associate shuts down” in the August issue of Medical Practice Compliance Alert.

As the HHS press release stated, the consequences for HIPAA violations don’t stop when a business closes.  In this case, Filefax had been under investigation by state and federal authorities since 2015 for careless handling of medical records which had been abandoned at a shredding facility.   Medical Practice Compliance Alert notes:

This settlement shows that  a provider or business associate that has violated HIPAA can’t avoid the consequences by shutting down.  “OCR is saying that you’re still responsible if you close your doors.” Says attorney Elizabeth Litten with Fox Rothschild in Princeton, NJ.

But it also provides a cautionary tale for providers who work with business associates that go under because providers are ultimately responsible for their patients’ records.

The article suggests the following tips for a covered entity to reduce its risks when a business associate may be in shaky financial shape:

  1. Keep an inventory of your business associate relationships.
  2. Choose business associates carefully.
  3. Monitor your business associates’ compliance with HIPAA.
  4. Expect increased scrutiny if a business associate is already on the government’s radar.
  5. Watch for signs that the business associate may be running into financial trouble.
  6. Don’t sit idly if the business associate files for bankruptcy.

What should a covered entity do when it learns that a business associate may have violated its HIPAA responsibilities?  For starters, see our previous post entitled Ten Tips for Actions by a Covered Entity after a HIPAA Breach by a Business Associate.  And if that BA has ceased operations, be prepared to take control of the situation even if the BA may not have enough resources left to reimburse you for its mistakes. Remember, the buck always stops with the Covered Entity.

Harry S. Truman Library & Museum 2017

The European Union’s General Data Protection Regulation (GDPR) went into effect on May 25, 2018. Whereas HIPAA applies to particular types or classes of data creators, recipients, maintainers or transmitters (U.S. covered entities and their business associates and subcontractors), GDPR applies much more generally – it applies to personal data itself. Granted, it doesn’t apply to personal data that has absolutely no nexus to the EU, but assuming it doesn’t apply to your U.S.-based entity simply because you don’t have a physical location in the EU is a mistake.

So when does GDPR apply to a U.S.-based covered entity, business associate, or subcontractor? As with HIPAA, the devil is in the definitions, so I’ve capitalized certain GDPR-defined terms below. GDPR is comprised of 99 articles set forth in 11 chapters, and 173 “Recitals” explain the rationales for adoption. Similar to the way regulatory preambles and guidance published by the U.S. Department of Health and Human Services (HHS) can be helpful to understanding HIPAA compliance, the Recitals offer insight into GDPR applicability and scope.

Under Article 3, GDPR applies:

(1) To the Processing of Personal Data in the context of the activities of an establishment of a Controller or Processor in the EU, regardless of whether the Processing takes place in the EU;

(2) To the Processing of Personal Data of data subjects who are in the EU by a Controller or Processor not established in the EU, where the Processing activities are related to:

(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the EU; or

(b) the monitoring of their behavior as far as their behavior takes place within the EU; and

(3) To the Processing of Personal Data by a Controller not established in the EU, but in a place where EU member state law applies by virtue of public international law.

It is paragraph (2) that seems most likely to capture unwitting U.S.-based covered entities, business associates, and subcontractors that are not established in the EU (though Recital 22 offers further explanation of what it means to be Processing data in the context of the activities of an establishment).

Notably, paragraph (2) makes it clear that while the entity need not be located within the EU for GDPR to apply, the data subject must be. If the U.S. entity offers goods or services to, or monitors the behavior of, data subjects who are “in” the EU, GDPR likely applies. It is the location of the data subject, not his or her citizenship, residency or nationality, that matters. GDPR does not follow the data subject outside the EU, but it does follow the data subject (even an American) into the EU – so long as the Processing of the Personal Data takes place in the EU.

So what does this mean for the U.S.-based covered entity, business associate, or subcontractor not established in the EU? It should carefully review its website, marketing activities, discharge or post-service follow-up procedures, and any other activities that might involve the offering goods or services to, or monitoring the behavior of, individuals in EU. If GDPR applies, the company will need to analyze how its HIPAA privacy and data security policies are inconsistent with and fall short of GDPR requirements. The company, whether a covered entity, business associate, or subcontractor, should also make sure that none of its vendors process data on its behalf in the EU.

In addition to understanding where data subjects are located and where Processing takes place in order to determine GDPR applicability, covered entities, business associates and subcontractors must determine whether they are acting as Controllers or Processors in order to understand their GDPR compliance obligations.

This can create particular challenges for a business associate.  If a covered entity is subject to GDPR, a business associate that creates, receives, maintains or transmits Personal Data on behalf of the covered entity will either be acting as a Processor (for example, where the covered entity simply uses the business associates tools or services to conduct its business), or a Controller (for example, where the business associate reaches out directly to plan members or patients, such as by an email campaign).  If the business associate’s services agreement or business associate agreement makes no mention of the fact that the covered entity is subject to GDPR, the business associate may not know whether it is also subject to GDPR, let alone whether it is a Controller or Processor.

The bottom line is that focusing on compliance with HIPAA and other federal and state laws pertaining to privacy and security of personal information is not enough, even for companies that view themselves as operating solely within the U.S.  A thorough risk assessment should include not only careful consideration of HIPAA requirements, but of the potential applicability and compliance requirements of GDPR.

You may be surprised to learn that those “extra” benefits your company offers to its employees such as your employee assistance program (“EAP”) and wellness program likely are subject to the HIPAA privacy, security and breach notification rules (collectively, “HIPAA Rules”). Part 1 covers why most EAPs are subject to the HIPAA Rules. Part 2 will discuss wellness programs. In both cases, EAPs and wellness programs must comply with the HIPAA Rules to the extent that they are “group health plans” that provide medical care.

As background, the HIPAA Rules apply to “covered entities” and their “business associates.” Health plans and most healthcare providers are “covered entities.” Employers, in their capacity as employers, are not subject to the HIPAA Rules. However, the HIPAA Rules do apply to any “protected health information” (“PHI”) an employer/plan administrator holds on a health plan’s behalf when the employer designs or administers the plan.

Plan administrators and some EAP vendors may not consider EAPs to be group health plans because they do not think of EAPs as providing medical care. Most EAPs, however, do provide medical care. They are staffed by health care providers, such as licensed counselors, and assist employees who are struggling with family or personal problems that rise to the level of a medical condition, including substance abuse and mental health issues. In contrast, an EAP that provides only referrals on the basis of generally available public information, and that is not staffed by health care providers, such as counselors, does not provide medical care and is not subject to the HIPAA Rules.

A self-insured EAP that provides medical care is subject to the HIPAA Rules, and the employer that sponsors and administers the EAP remains responsible for compliance with the HIPAA Rules because it acts on behalf of the plan.   On the other hand, for an EAP that is fully-insured or embedded in a fully-insured policy, such as long-term disability coverage, the insurer will have the primary obligations for compliance with the HIPAA Rules for the EAP. The employer will not be responsible for overall compliance with the HIPAA Rules for an insured EAP even though it provides medical care, but only if the employer does not receive PHI from the insurer or only receives summary health information or enrollment/disenrollment information. Even then, the employer needs to ensure it doesn’t retaliate against a participant for exercising their rights under the HIPAA Rules or require waiver of rights under the HIPAA Rules with respect to the EAP.

An EAP that qualifies as an “excepted benefit” for purposes of HIPAA portability and the Affordable Care Act (as is most often the case because the EAP is offered at no cost, eligibility is not conditioned on participation in another plan (such as a major medical plan), benefits aren’t coordinated with another plan, and the EAP does not provide “significant benefits in the nature of medical care”) can be subject to the HIPAA Rules. In other words, just because you’ve determined that your EAP is a HIPAA excepted benefit doesn’t mean the EAP avoids the HIPAA Rules. Most EAPs are HIPAA excepted benefits, yet subject to full compliance with the HIPAA Rules.

Employers/plan administrators facing unexpected compliance obligations under the HIPAA Rules because of a self-insured EAP that provides medical care will need to enter into a HIPAA business associate agreement with the EAP vendor, amend the EAP plan document to include language required by the HIPAA Rules and develop and implement other compliance documents and policies and procedures under the HIPAA Rules. One option is to amend any existing compliance documents and policies and procedures under the HIPAA Rules for another self-insured group health plan to make them apply to the EAP as well. If the EAP is the plan administrator’s only group health plan for which it has compliance responsibility under the HIPAA Rules, the plan administrator should consult with legal counsel to develop and implement all necessary documentation for compliance with the HIPAA Rules.

 

This blog recently discussed tips for a covered entity (CE) in dealing with a HIPAA business associate (BA). Now, even though you have adopted all of the tips and more, in this dangerous and ever more complex data security world, one of your BAs suffers a breach and it becomes your responsibility as the victim CE to respond. What should you do?

Our partner Elizabeth Litten and I discussed aspects of this issue with our good friend Marla Durben Hirsch who included some of our discussion in her article in the June 2017 issue of Medical Practice Compliance Alert entitled “6 ways practices can reduce the risk of delegating breach-notification duties.” Full text of the article can be found in the June, 2017 issue, but a number of the items included below are drawn from the article.

  1. Locate the most recent Business Associate Agreement (BAA) with the BA who experienced the breach, and see what it says about the post-breach obligations of the CE and the BA. Two important threshold issues are whether the BA complied with the time period for reporting breaches to the CE contained in the BAA and the remaining time, if any, available to the CE for complying with any reporting requirements under HIPAA and state law, remediation and limitation of loss requirements, and notification requirements to affected individuals (collectively, the Requirements).
  2. Determine promptly what are the time deadlines for notification to insurance carriers if cybersecurity or general liability insurance may be available to the BA and/or the CE for payment of expenses of the breach and its remediation.
  3. Spell out any circumstances where the BA will handle the consequences of a breach that occurred on its watch, and the scope of its responsibilities vs. that of the CE. These can range from delegating to the BA the entire range of Requirements to assumption by the CE of complying with the Requirements with payment by the BA of the costs thereof.
  4.  Make sure that the required reporting and notification Requirements are sent on CE stationery or, if such Requirements are being delegated to the BA (especially where the breach affected a number of different CEs), the notifications make it clear that the breach was attributable to the acts of the BA and not the CE. As CE, insist that the final wording of the required reporting and notification documents be subject to your approval.
  5.  Ensure that your staff is familiar with the circumstances of the breach so that they will be able to answer questions from affected individuals and the media intelligently. It may be advisable to designate a single trained and articulate person to be referred all inquiries, so that the responses are uniform, accurate and clear.
  6.  Assess whether the BA handled the breach adequately and whether you want to retain your relationship with the BA. Did the BA comply with HIPAA and the BAA in the post-breach period? Did the BA cooperate with the CE? What is the likelihood of a repeat breach by the BA? Is the CE assuming the risk of potential repeat HIPAA breaches if the BA relationship is continued?
  7. If you determine as CE that you will continue your relationship with the breaching BA, consider whether the BAA with the BA requires changes based upon the experience of the breach and its aftermath.
  8. As CE, consider modifying, updating and/or strengthening all of your BAAs as a result of your experience.
  9. As CE, you may require improving and/or changing your cybersecurity insurance coverage as a result of experience with the breach.
  10.  As CE, document all activities and decisions respecting HIPAA made in the post-breach period to defend your actions as reasonable and to provide concrete planning steps for future HIPAA compliance.

While all the precautions in the universe by a CE cannot eliminate a HIPAA breach by a BA, a CE that is victimized by such a HIPAA breach can do many things to reduce its liability and image damage and strengthen its own HIPAA compliance and risk avoidance efforts for the future by adopting the steps described above.

According to the latest HIPAA-related guidance (Guidance) published by the U.S. Department of Health and Human Services (HHS), a cloud service provider (CSP) maintaining a client’s protected health information (PHI) is a business associate even when the CSP can’t access or view the PHI. In other words, even where the PHI is encrypted and the CSP lacks the decryption key, the CSP is a business associate because it maintains the PHI and, therefore, has HIPAA-related obligations with respect to the PHI.

HHS explains:

While encryption protects ePHI by significantly reducing the risk of the information being viewed by unauthorized persons, such protections alone cannot adequately safeguard the confidentiality, integrity and availability of the ePHI, such as ensuring that the information is not corrupted by malware, or ensuring through contingency planning that the data remains available to authorized persons even during emergency or disaster situations. Further, encryption does not address other safeguards that are also important to maintaining confidentiality, such as administrative safeguards to analyze the risks to the ePHI or physical safeguards for systems and services that may house the ePHI.”

It makes sense to treat a CSP as a business associate if it holds PHI, even if it cannot view or access that PHI. After all, a business associate is a person or entity that performs a function or service on behalf of a covered entity (or another business associate) that requires it to create, receive, maintain, or transmit PHI.

Still, HHS’s explanation is less than satisfying, perhaps because it rather crudely mixes together very distinct HIPAA obligations:  protecting the confidentiality of PHI, on one hand, and protecting the integrity and availability of PHI, on the other.

Under the HIPAA regulations, a business associate is only required to provide notice to the covered entity following the discovery of a breach of unsecured PHI. “Unsecured” PHI is defined as PHI that is “not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary [of HHS]…” – in other words, PHI that is not encrypted at a level that meets HHS’s standards. The HIPAA regulations also say that a breach excludes a “disclosure of PHI where a covered entity or business associate has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.” Obviously, a disclosure of PHI that cannot be viewed will also not be able to be retained.

HHS contends that encryption “alone cannot adequately safeguard the confidentiality” of the PHI, but, later in the Guidance, concedes that if the PHI is encrypted at a level that meets HHS’s standards, an unauthorized incident would fall within the breach “safe harbor” and would not need to be reported to the CSP’s customer. In such a case, the confidentiality of the PHI would be adequately safeguarded by encryption alone and the CSP arguably would not have an obligation to do anything else under HIPAA to protect the confidentiality of the PHI.  The CSP would have an ongoing obligations, however, to protect the integrity and accessibility of the encrypted PHI under HIPAA. The encryption “blindfold” will simplify the CSP’s obligations under HIPAA.

A CSP is in a tricky position if it holds encrypted PHI for a customer, but does not know that it holds it. The Guidance emphasizes that if a CSP maintains PHI for a customer that is a covered entity or business associate, it must execute a business associate agreement with the customer, and risks enforcement action (such as reported here) by the Office of Civil Rights (OCR) within HHS if it doesn’t have one.

“OCR recognizes that there may, however, be circumstances where a CSP may not have actual or constructive knowledge that a covered entity or another business associate is using its services to create, receive, maintain, or transmit ePHI.  The HIPAA Rules provide an affirmative defense in cases where a CSP takes action to correct any non-compliance within 30 days … of the time that it knew or should have known of the violation… This affirmative defense does not, however, apply in cases where the CSP was not aware of the violation due to its own willful neglect.”

Two key takeaways from the Guidance for a CSP? If you are blindfolded from viewing the data you maintain or transmit on behalf of a customer, or otherwise do not know whether the data might bring HIPAA obligations along with it, take reasonable steps to find out if the customer is a covered entity or business associate and whether the data includes PHI.  If so, execute a business associate agreement. Then, make sure the blindfold (i.e., encryption level) meets HHS’s standards and do NOT accept or have access to the decryption key.  This way, you can focus your HIPAA compliance efforts on protecting the integrity and accessibility of the data, not on protecting its confidentiality.

Jessica Forbes Olson and T.J. Lang write:

In Part 1, we noted that on March 21, 2016, the Office of Civil Rights (“OCR”) announced it will launch a second round of HIPAA audits this year. As with the first round of audits, in round two OCR will be reviewing compliance with HIPAA Privacy, Security and Breach Notification rules. New for this round, the 2016 audits will focus on covered entities, including health care providers and health insurers, and their business associates.

A HIPAA compliance checklist for health care providers and insurers follows:

  • Determine whether for HIPAA purposes you are a hybrid entity, an affiliated covered entity or part of an organized health care arrangement. Document that status.
  • Appoint a HIPAA privacy official.
  • Appoint a HIPAA security official.
  • Appoint a HIPAA privacy contact person who will handle complaints and respond to the exercise of patient or participant rights.
  • Determine where PHI is located, whether hard copy, electronic, or spoken.
  • Determine the reasons why PHI is used or disclosed (e.g., treatment, payment, health care operations, public health reasons, public policy reasons, to government agencies or officials).
  • Determine which departments and workforce members have access to PHI, why they have such access and the level of access needed.
  • Identify and document the routine requests, uses and disclosures of PHI and the minimum necessary for those requests, uses and disclosures.
  • Identify all business associates: vendors that create, maintain, use or disclose PHI when performing services for your entity.
  • Have executed business associate agreements with all business associates.
  • Have and follow written HIPAA privacy, security and breach notification policies and procedures.
  • Train all workforce members who have access to PHI on the policies and procedures and document the training.
  • Have and use a HIPAA-compliant authorization form.
  • Have and follow process for verifying the status of personal representatives.
  • Distribute a notice of privacy practices and providers must attempt to obtain acknowledgment of receipt of notice from patients and post one in each facility where patients can view it.
  • Establish and document reasonable administrative, technical and physical safeguards for all PHI, including hard copy and spoken PHI.
  • Conduct and document a HIPAA security risk analysis for all electronic PHI (e.g., PHI on desktops, laptops, mobile phones, iPads and other electronic notebooks, copy machines, printers, discs and thumb drives).
  • Address risks to ePHI that are identified in the HIPAA security risk analysis.
  • Update your HIPAA security risk analysis periodically or when there is a material change in your environment that does or could impact PHI or if there are changes in the law impacting PHI.
  • Encrypt PHI to fall within the breach safe harbor.
  • Have written disaster recovery and contingency plans.
  • Prepare for and respond to security incidents and breaches.
  • Comply with HIPAA standard transactions and code set rules related to electronic billing and payment.
  • Although it will not be covered by the audits, comply with more stringent state privacy and security laws (e.g., document retention; patient consent; breach reporting).
  • Maintain HIPAA compliance documentation in written or electronic form for at least 6 years from the date the document was created or last in effect.

For more information about OCR audits or assistance in conducting a HIPAA compliance review, please contact any member of the Fox Rothschild Health Law practice group.


Jessica Forbes Olson is a partner and TJ Lang is an associate, both resident in the firm’s Minneapolis office.

Jessica Forbes Olson and T.J. Lang write:

HIPAA and Health Records
Copyright: zimmytws / 123RF Stock Photo

On March 21, 2016, the Office of Civil Rights (“OCR”) announced it will launch a second round of HIPAA audits during 2016. As with the first round of audits, in round two OCR will be reviewing compliance with HIPAA Privacy, Security and Breach Notification rules. New for this round, the 2016 audits will focus on covered entities, including health care providers and health insurers, and their business associates.

The round two audits will occur in three phases: desk audits of covered entities, desk audits of business associates, and finally, follow-up onsite reviews. It is reported OCR will conduct about 200 total audits; the majority of which will be desk audits.

OCR has already begun the process of identifying the audit pool by contacting covered entities and business associates via email.  Health care providers,   insurers and their business associates should be on the lookout for automated emails from OCR which are being sent to confirm contact information. A response to the OCR email is required within 14 days. OCR instructed covered entities and business associates to check their spam or junk email folders to verify that emails from OCR are not erroneously identified as spam.

After the initial email, OCR will send a pre-audit questionnaire to entities it may choose to audit. Receiving a pre-audit questionnaire does not guarantee your entity will be audited. The purpose of the questionnaire is to gather information about entities and their operations, e.g., number of employees, level of revenue, etc. The questionnaire will also require covered entities to identify all of their business associates. Health care providers and insurers who have not inventoried business associates should do so now.

Entities who fail to respond to the initial OCR email or questionnaire will still be eligible for audit. OCR will use publicly available information for unresponsive entities to create its audit pool.

OCR will then, in the “coming months,” randomly select entities to audit and notify them via email that they have been selected for audit.

Health care providers, health insurers and business associates should check their HIPAA compliance status before they are contacted by OCR. Once selected for an audit, entities will only have 10 business days to provide the requested information to OCR.

Recent OCR enforcement activity has shown that noncompliance with HIPAA can be costly:

  • A Minnesota-based hospital entered into a $1.55 million settlement for failure to implement one business associate agreement and failure to conduct a HIPAA security risk analysis;
  • A teaching hospital of a university in Washington entered into a $750,000 settlement for failure to conduct an enterprise-wide HIPAA security risk analysis;
  • An insurance holding company based in Puerto Rico entered into a $3.5 million settlement for failure to implement a business associate agreement, conduct a HIPAA security risk analysis, implement security safeguards and for an improper disclosure of protected health information (“PHI”);
  • A radiation oncology physician practice in Indiana entered into a $750,000 settlement for failure to conduct a HIPAA security risk analysis and implement security policies and procedures.

If you receive any communications from OCR, please contact a member of the Fox Rothschild Health Law practice group immediately. A proactive review of your HIPAA compliance status can identify potential gaps and minimize the risk of potential penalties.

In Part 2, we’ll provide a HIPAA compliance checklist for healthcare providers and insurers. Stay tuned!


Jessica Forbes Olson is a partner and TJ Lang is an associate, both resident in the firm’s Minneapolis office.

I’m sure fellow bloggers Bill Maruca and Michael Kline join me in giving three cheers for the recent growth in our firm’s health care practice (welcome, Minneapolis!) and ever-deepening pool of attorneys dealing with clients’ privacy and data security issues. But one recent addition to our team, Margaret (“Margie”) Davino, gets a fourth cheer for jumping into her new position as a partner practicing out of our New York City and Princeton, NJ offices and immediately leading a HIPAA webinar for HFMA’s Region 2 (metro NY) entitled “HIPAA: What to Expect in 2016”.

Margie covered a wide range of HIPAA topics, discussing how OCR investigations arise, preparing for Phase 2 of OCR’s audits, and how HIPAA might overlap or interplay with other laws (the FTC Act, state law causes of action, and the Telephone Consumer Protection Act, to name a few). For HIPAA nerds like me, it was a satisfying smorgasbord of HIPAA tidbits, past, present and future.  But several of Margie’s take-aways are particularly useful additions to the 2016 HIPAA compliance “To-Do” list:

  1. Make sure your security risk analysis encompasses all entities within your “family” – in other words, don’t just analyze your electronic health record, but focus on each entity and location from which protected health information (PHI) might be stolen or lost.
  2. If you are a small entity, make use of HHS’s Security Risk Assessment Tool to identify whether corrective action should be taken in a particular area. (In other words, there’s no excuse for ignoring item #1 on this list!)
  3. Encrypt data, if at all possible (and make sure it’s up to NIST encryption standards).
  4. Check that you have updated Business Associate (BA) Agreements in place for all BA relationships (and check first to make sure it’s really a BA relationship).
  5. Have a mobile device policy – and include mobile devices in your security risk analysis.

I like this short “To-Do” list because it helps prioritize HIPAA compliance tasks for 2016 based on what we have learned from breaches and enforcement actions in 2015 and prior years.

I posed a question in Part 1 of this post which I will summarize here:  is personal health information provided to a Patient Assistance Program (PAP) in order to help with covering the cost of prescription drugs protected as “protected health information” (PHI) under HIPAA?

Let’s use two examples.  Say Patient A, who knows he can’t afford the out-of-pocket costs for a branded drug prescribed by his doctor, goes to the pharmaceutical manufacturer’s website where he sees that the company has a PAP and on-line application form into which he enters his personal information to see if he qualifies for assistance.  Patient B is also concerned about the cost of a non-formulary drug prescribed for her, but the hospital where Patient B’s physician works has an arrangement with the PAP whereby the PAP will work with a patient’s insurance carrier to get coverage for drugs not included on the carrier’s formulary.  What happens if the PAP’s system is hacked and the personal health information of both Patient A and Patient B is compromised?  Does HIPAA apply and will the PAP notify Patient A and Patient B of the breach?

The answer is a qualified “yes”, because HIPAA would be applicable only if the PAP is functioning as a covered entity or business associate as those terms are defined under HIPAA when it receives and maintains the personal health information.  It’s the role the PAP plays with respect to the patient (and his or her information) that matters when trying to figure out whether the patient’s information is HIPAA-protected as PHI, rather than just the type of information the PAP receives and maintains.

Generally speaking, a pharmaceutical manufacturer (and its PAP) will be a “covered entity” under the HIPAA regulations if it is a “health care provider who transmits any health information in electronic form in connection with a transaction . . . .” (italics added).  The term “health care provider” is defined very broadly under the HIPAA regulations, and a “transaction” is defined (in relevant part) as “the transmission of information … to carry out financial or administrative activities related to health care.”  The manufacturer (and its PAP) is a “business associate” if it performs functions on behalf of a covered entity that require it to create, receive, maintain or transmit PHI.

The same mini-analysis can be applied to other business entities that “create, receive, maintain or transmit” PHI as a useful first step to understanding whether and how the personal health information may be protected.

Health-related technology has developed light-years faster than health information privacy and security protection laws and policies, and consumers can find new mobile health applications for a wide range of purposes ranging from diabetes management to mole or rash evaluation to fitness tracking.  Smart mobile app developers wondering when and how HIPAA privacy and security requirements affect their products need to take a step back and ask that most basic of HIPAA questions:  What am I?

The question one that has been posed on this blog in the past, and one worth returning to on a regular basis because the answer is not always obvious, but is critical for HIPAA compliance.

The Secretary of Health and Human Services (HHS) recently released a letter written to U.S. Representative Peter DeFazio regarding development and use of mobile health apps and HIPAA compliance reminding him (and anyone reading the letter) that:

“The first question for any entity … is whether it is a covered entity or a business associate within the meaning of the HIPAA rules.” 

The Secretary then helpfully provides links to the Office for Civil Rights (OCR) website’s “frequently asked questions” tools (see here for examples of “Who are Business Associates” and here for information on Covered Entities) and points out that OCR works closely with the Office of the National Coordinator for Health Information Technology (ONC) developing guidance and tools (a tool specific to mobile device privacy and security is available here) for securing health information technology.   However, there’s no quick and easy way to figure out whether HIPAA applies to a specific mobile health application.  The inquiry must always go back to the beginning:  are you a Business Associate (or subcontractor of a Business Associate) or a Covered Entity?  If not, while there may be other state and federal laws that require you protect individually identifiable information (of which protected health information, or PHI, is a subset), HIPAA does not apply.

Bear in mind that your HIPAA identity will change depending on who is using you and for what purpose.  If you develop a mobile health app allowing an individual to create, receive, maintain or transmit information about herself, it is likely the app is not covered by HIPAA because the individual is not acting as a Business Associate or Covered Entity when using the app.  Even if the individual uses the app to send her PHI to her health care provider, the app most likely will not be subject to HIPAA, just as the patient herself is not subject to HIPAA with respect to information about herself she chooses to share with her provider. However, if you develop the app for use by the health care provider, you very well may be a Business Associate to the Covered Entity health care provider.  In this scenario, if you are providing a service on behalf of the provider that involves your access to PHI (whether sent by the individual patient herself or not), you must comply with HIPAA.

So while the basic “What am I?” question sounds simple, the answer requires consideration of who is downloading and using the mobile health app you create, and the purpose for which it is being used.