Manage Learn to apply best practices and optimize your operations.

How legal compliance with patient data can spur engagement

Legal compliance with patient data can improve patient engagement, if you can navigate the labyrinth of issues surrounding anti-kickback statutes, HIPAA and state laws.

BOSTON -- Patients are getting used to HIPAA-grade protections on the specific data points protected by the federal privacy and security rules, and they're coming to expect it for all the data a hospital might handle. It doesn't matter if the patient data in question is classified as personal health information (PHI), which is covered by HIPAA, or personally identifiable information (PII), which is protected by state and federal consumer identity-theft laws -- consumers expect their health data to be kept private and secure.

Ensuring legal compliance with electronic patient data

New HIPAA laws, new frontier for patient data security

Report offers PHI security guidance

Web traffic monitoring aids legal compliance, productivity

This, along with a complex patchwork of federal consumer data protections -- overlaid with individual state laws -- make legal compliance for handling patient data a difficult job among health care providers, said attorneys convened for a preconference panel at the Health 2.0 Spring Fling. The software developers creating the applications to handle electronic patient data are in just as much of a quandary.

On top of that, there's other user-generated content, like personal information submitted to a hospital's patient-facing website that falls outside of PHI and PII, said Daniel Orenstein, athenahealth attorney. Preventing breaches, he said, starts with data encryption for data in motion and at rest; de-identifying patient data whenever possible for analysis or other uses; and standard business-associate agreements that enumerate your permitted uses and disclosures of patient data.

The silver lining is that once a practice -- and its software developers -- set up the strong data protections that patients are demanding around their health information and associated data, it builds trust and goodwill between provider and patient.

"I've seen the issue come up where there is data that is not covered by this regulatory schema," said attorney and HealthBlawg author David Harlow. "But try explaining that to the patient, to the consumer, they say, 'You lost my data? That's covered by HIPAA.' and you say, 'No, it's not.' They don't care. I advise some clients who are dealing with data like that to act as if [it's all] covered by HIPAA. Despite the additional expense and headache, it is a tremendous improvement to customer relationships."

Apps handling patient data may run afoul of Stark laws

Some health care providers commission the development of software for use in their own health systems, and in some cases they end up selling it to other health care providers. Whether a hospital is the developer or the end user of a software application that handles patient data, it's important to understand anti-kickback laws (first enacted in 1972 and updated in the 1990s by Fortney "Pete" Stark, then-chairman of the U.S. House Ways and Means Health Subcommittee) and how they work.

I advise some clients who are dealing with data like that to act as if [it's all] covered by HIPAA. Despite the additional expense and headache, it is a tremendous improvement to customer relationships.

David Harlow, attorney

The main thrust of the law is to prevent rewards for patient or service referrals reimbursed by Medicare or Medicaid. The law hasn't really "kept up with the times," said Brian French, attorney for Nixon Peabody, because trends in health IT and accountable care organizations(ACOs) make at least one facet of almost every provider deal a potential Stark law violation. On top of that, a separate-but-related body of federal and state fee-splitting prohibitions further muddy the waters when it comes to the legalities of "shared savings" reimbursement models for ACOs.

The "kickback" part of the Stark laws' name is something of a misnomer, said Jack Eiferman, attorney for Goulston & Storrs, because it insinuates that corrupt players violate the laws with bribes. Well-meaning, honest vendors and health care providers could potentially get caught in the Stark snare. This is because incentives that could potentially be felony Stark violations -- providing discount coupons for patients, say, or vendor dinners out for physicians who might buy a product, donations for charitable foundations -- are common practice in other markets. Further complicating matters are individual states' anti-kickback rules such as one in Massachusetts that governs commercial insurance payers.

"Hospitals and health plans are really sensitive to this stuff," Eiferman said to the health IT software vendors that made up much of the audience. "People do go to jail for it, and the government is generally looking to make an easier case, not a harder case. You don't want to be an easy case."

Mobile health apps carry potential legal compliance risk

Stark laws can potentially come into play with a smartphone mHealth app, for example, if it can capture referrals for services ultimately reimbursed by Medicare and Medicaid -- or even commercial payers operating in states with rules like those in Massachusetts, French said.

"What's ultimately very important is to be able to look at what it is -- whatever service you are providing -- and determine 'What is the purpose of what I am doing here?' Is it just simply to generate business for somebody…or better patient care?" French said.

The good news? There are ways to keep in compliance with the Stark law, and the U.S. Department of Health & Human Services' Office of the Inspector General spells them out in its safe harbor guidance. The bad news is that the definition of the safe harbors and the OIG's enforcement of them sometimes make them seem almost too narrow to actually comply with, Eiferman said.

Dig Deeper on Electronic health records privacy compliance

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.