Health IT

Subscribe to Health IT

“Maybe” is the take-away from recent guidance posted on OCR’s mHealth Developer Portal, making me wonder whether the typical health app user will know when her health information is or is not subject to HIPAA protection.

The guidance is clear and straightforward and contains no real surprises to those of us familiar with HIPAA, but it highlights the reality that HIPAA, originally enacted close to 20 years ago, often becomes murky in the context of today’s constantly developing technology. Here’s an excerpt from the guidance that illustrates this point:

Consumer downloads to her smart phone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records. The app also contains the plan’s wellness tools for members, so they can track their progress in improving their health.  Health plan analyzes health information and data about app usage to understand the effectiveness of its health and wellness offerings.  App developer also offers a separate, direct-to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers.

Is the app developer a business associate under HIPAA, such that the app user’s information is subject to HIPAA protection?

Yes, with respect to the app offered by the health plan, and no, when offering the direct-to-consumer app. Developer is a business associate of the health plan, because it is creating, receiving, maintaining, or transmitting protected health information (PHI) on behalf of a covered entity.  Developer must comply with applicable HIPAA Rules requirements with respect to the PHI involved in its work on behalf of the health plan.  But its “direct-to-consumer” product is not provided on behalf of a covered entity or other business associate, and developer activities with respect to that product are not subject to the HIPAA Rules.  Therefore, as long as the developer keeps the health information attached to these two versions of the app separate, so that information from the direct-to-consumer version is not part of the product offering to the covered entity health plan, the developer does not need to apply HIPAA protections to the consumer information obtained through the “direct-to-consumer” app.

So if I download this app because my health plan offers it, my PHI should be HIPAA-protected, but what if I inadvertently download the “direct-to-consumer” version? Will it look different or warn me that my information is not protected by HIPAA?  Will the app developer have different security controls for the health plan-purchased app versus the direct-to-consumer app?

HIPAA only applies to (and protects) individually identifiable health information created, received, maintained or transmitted by a covered entity or business associate, so perhaps health app users should be given a “Notice of Non-(HIPAA) Privacy Practices” before inputting health information into an app that exists outside the realm of HIPAA protection.

Whether it was an apple or a quince, pomegranate, or some other more botanically-likely fruit growing in the Garden of Eden, God’s command in Genesis was clear: do not eat the fruit from the tree of the knowledge of good and evil.  When Adam and Eve ate the apple (or other fruit) anyway, they gained knowledge of evil (they already knew good).

Apple
Copyright: Spanishalex / 123RF Stock Photo

Many thousands of years later, the battle between Apple and the FBI over device encryption oddly echoes themes from this ancient biblical story.   Is the knowledge of evil potentially gained by unlocking an evildoer’s iPhone worth breaking society’s trust in the security of encryption?

Our law partner Amy Purcell recently posted the following on the Fox Rothschild “Privacy Compliance & Data Security” blog:

Fox Partner and Chair of the Privacy and Data Security Practice Scott L. Vernick was a guest on Fox Business’ “The O’Reilly Factor” and “After the Bell” on February 17, 2016, to discuss the controversy between Apple and the FBI over device encryption.

A federal court recently ordered Apple to write new software to unlock the iPhone used by one of the shooters in the San Bernardino attacks in December. Apple CEO Tim Cook has vowed to fight the court order.

The Federal Government vs. Apple (The O’Reilly Factor, 02/17/16)

Apple’s Privacy Battle With the Federal Government (After the Bell, 02/17/16)

I agree with Scott.

In January, I wrote here about the FTC’s announcement of a settlement with Henry Schein Practice Solutions, Inc. for falsely advertising that the software it marketed to dental practices provided the encryption necessary to protect patient data from breach. In reality, the software did not encrypt the data, but merely “camouflaged” or masked it from access by third parties.  The FTC’s action and settlement seemed to reflect the fact that encryption is viewed as the “gold standard” for protecting protected health information and other sensitive personal information, and advertising that a software product provides encryption when it really doesn’t is a problem.

If Apple is forced to create software that will break “gold standard” encryption so the FBI can gain knowledge of the evil that may lurk within a particular iPhone, this “gold standard” will be immediately devalued. In the HIPAA context, we will need another technology to render PHI “unusable, unreadable, or indecipherable to unauthorized persons” because, in essence, the biblical apple will have been bitten.

Our partner Elizabeth Litten and I had a recent conversation with our good friend Marla Durben Hirsch who quoted us in her Medical Practice Compliance Alert article, “Beware False Promises From Software Vendors Regarding HIPAA Compliance.” Full text can be found in the February, 2016, issue, but some excerpts regarding 6 tips to reduce the risk of obtaining unreliable HIPAA compliance and protection software from vendors are summarized below.

As the backdrop for her article, Marla used the $250,000 settlement of the Federal Trade Commission (the “FTC”) with Henry Schein Practice Solutions, Inc. (“Henry Schein”) for alleged false advertising that the software it marketed to dental practices provided “industry-standard encryption of sensitive patient information” and “would protect patient data” as required by HIPAA. Elizabeth has already posted a blog entry on aspects of the Henry Schein matter that may be found here.

During the course of our conversation with Marla, Elizabeth observed, “This type of problem [risk of using unreliable HIPAA software vendors] is going to increase as more physi­cians and health care professionals adopt EHR systems, practice management systems, patient portals and other health IT.”

The six tips listed by Marla are summarized as follows:

  1. Litten and Kline:

Vet the software vendor regarding the statements it’s making to secure and protect your data. If the vendor is claiming to provide NIST-standard encryption, ask for proof. See what it’s saying in its marketing brochures. Check references, Google the company for lawsuits or other bad press, and ask whether it suffered a security breach and if so, how the vendor responded.

 

  1. Kline: “Make sure that you have a valid business associate agreement that protects your interests when the software vendor is a business associate.” However, a provider must be cautious to determine first whether the vendor is actually a business associate before entering into a business associate agreement.

 

  1. Litten: “Check whether your cyberinsurance covers this type of contingency. It’s possible that it doesn’t cover misrepresentations, and you should know where you stand.”

 

  1. Litten and Kline: “See what protections a software vendor contract may provide you.”   For instance, if a problem occurs with the software or it’s not as advertised, if the vendor is not obligated to provide you with remedies, you might want to add such protections, using the Henry Schein settlement as leverage.

 

  1. Litten and Kline: “Don’t market or advertise that you provide a level of HIPAA protection or compliance on your web-site, Notice of Privacy Practices or elsewhere unless you’re absolutely sure that you do so.” The FTC is greatly increasing its enforcement activity.

 

  1. Kline: “Look at your legal options if you find yourself defrauded.” For instance, the dentists who purchased the software [from Henry Schein] under allegedly false pretenses have grounds for legal action.

The primary responsibility for compliance with healthcare data privacy and security standards rests with the covered entity. It must show reasonable due diligence in selecting, contracting with, and monitoring performance of, software vendors to avoid liability for the foibles of its vendors.

Health care vendors beware: if you tell customers that your product provides industry-standard encryption of protected health information in compliance with HIPAA, you’d better be sure it doesn’t simply “camouflage” the data.

The FTC recently announced a $250,000 settlement with Henry Schein Practice Solutions, Inc. (“Henry Schein”) for falsely advertising that the software it marketed to dental practices provided “industry-standard encryption of sensitive patient information” and “would protect patient data” as required by HIPAA.

In fact, according to the FTC’s Complaint, the software (called “Dentrix G5”) actually used a data protection tool Henry Schein knew was “less secure and more vulnerable than widely-used, industry-standard encryption algorithms, such as Advanced Encryption Standard (“AES”) encryption.” The Complaint states that Henry Schein was aware that the Department of Health and Human Services (“HHS”) directs health care providers to guidance promulgated by the National Institute of Standards and Technology (“NIST”), which recommends AES encryption to protect patient data.

The Complaint states that Henry Schein’s product did not use AES encryption, and alleges that Henry Schein was notified that its database engine vendor had agreed to re-brand the data protection used by Henry Schein as “Data Camouflage” so it would not be confused with standard encryption algorithms, like AES encryption. Still, Henry Schein allegedly continued to market its product as offering data encryption needed for HIPAA compliance.

In January of 2014, the Complaint concedes, Henry Schein published an announcement in the Spring 2014 issue of Dentrix Magazine stating:

“Available only in Dentrix G5, we previously referred to this data protection as encryption. Based on further review, we believe that referring to it as a data masking technique using cryptographic technology would be more appropriate.”

Alas, the admission that the product provided mere “data masking” or “camouflaging” rather than encryption was, apparently, too little and too late to avoid the FTC enforcement action and ensuing settlement payment and negative publicity. Though no data breach was alleged to have occurred, the damage had been done by the “false or misleading” claims already made by Henry Schein.

The lessons for covered entities and business associates using and marketing patient data tools? Simple:

(1) Encrypt, don’t camouflage (check NIST guidance and recommendations for current encryption standards).

(2) Don’t exaggerate your capabilities (don’t say you encrypt, when you merely camouflage, and if you only use some process like password protection, don’t suggest that you encrypt or even camouflage – potential misleading in this area can bring FTC sanctions).

(3) As we’ve said before on this blog, don’t forget that the FTC is watching – health care providers, payers, and vendors must remember that HHS isn’t the only sheriff in town when it comes to data protection, HIPAA isn’t the only law that governs patient data and privacy, and the States are also increasingly active in enforcing data privacy and security.

When and how should you email PHI, if at all?  The Office for Civil Rights (OCR) offers guidance as to the permissibility of sending PHI via email in this “Frequently Asked Question” answer, but doesn’t provide specifics as to how PHI can be safely emailed.  Whether you are a covered entity or a business associate (or the CIO or Privacy Officer for a covered entity or business associate), an attorney trying to navigate privacy and security compliance under HIPAA and other laws, or an individual whose PHI is at stake, you may wonder what tools and resources are available to protect PHI transmitted via email.

The National Institute of Standards and Technology (NIST) has provided many such tools and resources, including its 2007 “Guidelines on Electronic Mail Security”.  Now, though, NIST is accepting comments through November 30, 2015 on its most recent proposed set of email security guidelines, “Special Publication 800-177, Trustworthy Email”.  Though this Trustworthy Email draft (available with other NIST computer security and privacy publications here) comes with a disclaimer that it is “written for the enterprise email administrator, information security specialists and network managers”, it’s worth review (even by the less tech-savvy among us) because it breaks down and describes each component of email functionality and the protocols and technology currently available to improve privacy and security.

Emailing PHI has become extremely common, but before deciding to send or receive PHI via email, it’s a good idea to make sure the Trustworthy Email protocols and technologies have been considered.   And if you have suggestions or comments as to how these protocols and technologies specifically relate to or can be improved in the context of emails containing PHI, here’s your chance to speak up!  Finally, remember that whatever comes out as the final set of NIST guidelines can become obsolete quickly in this rapidly developing and expanding e-world.

I must thank Justice Scalia for injecting this delightfully descriptive term into the realm of health care.  Justice Scalia’s scathing dissent from the majority in the recent Supreme Court decision interpreting the Patient Protection and Affordable Care Act is rife with memorable expressions, but this is my favorite.

The Merriam Webster definition of jiggery-pokery is:

dishonest or suspicious activity:  underhanded manipulation or dealings; trickery.”

It’s not a term I’ve ever used before, but this old-fashioned, Dickensian-sounding term somehow practically begs for use in the context of a very modern and increasingly common context:  the HIPAA hacking incident.  A recent article in Becker’s Hospital Review lists the “50 biggest data breaches in healthcare” and the most common breach causes are far-and-away hacking and theft.   Notably, hacking incidents result in the highest number of affected individuals.  Here is the break-down:

*          18 hacking incidents (approximately 94 million affected individuals)

*          18 thefts (approximately 14 million affected individuals)

*          9 unauthorized accesses

*          3 missing equipment (1 storage disk, 1 hard drives, and 1 computer server)

*          1 improper disposal

*          1 “other”

In short, it seems that jiggery-pokery is involved far more often than mere carelessness when it comes to HIPAA breaches.  Covered entities and business associates should be alert to dishonest or suspicious activity generally, including from within, but should be especially alert when that activity involves the systems or equipment on which protected health information is created, received, maintained, or transmitted.

Part 2

Money talks.

In other words, offering financial incentives is one way to effect behavior change.  It seems to have worked in getting providers to adopt and use health IT in everyday practice, both in New Jersey and nationally.

HITECH and Meaningful Use Incentive Payments

As explained by ONC in its October 2014 “Report to Congress”:

“Prior to the HITECH Act, adoption of EHRs among physicians and hospitals was quite low. In 2009, roughly one-half (48 percent) of office-based physicians had any type of EHR system. When examining the adoption of EHRs containing functionalities, such as the ability to generate a comprehensive list of patients’ medications and allergies and the ability to view laboratory or imaging results electronically, only 22 percent of office-based physicians had a basic EHR system. U.S. hospitals had similar adoption rates. In 2009, only 12 percent of hospitals had adopted a basic EHR system.”

Stethoscope and currency
Copyright: / 123RF Stock Photo

According to ONC, as of June of 2014, more than 75% of the nation’s eligible physicians had received incentive payments, while 92% of eligible hospitals (including critical access hospitals) had received incentive payments. The areas evaluated by CSHP covered key meaningful use criteria eligible physicians must meet in order to receive these payments.

For the NJ evaluation, CSHP conducted and analyzed a physician mail survey, clinical laboratory and pharmacy mail surveys with telephone follow-up, and physician follow-up telephone interviews with fax and mail follow-up.  In addition, Health Information Organization (HIO) use metrics from each of New Jersey’s six regional HIOs were collected from the New Jersey Department of Health and analyzed by CSHP researchers.

New Jersey Health IT Adoption

The CSHP Report findings identified several key themes.  Among physicians responding, older physicians, those in smaller practices, and specialists were less likely to adopt health IT and more likely to report barriers to adoption (particularly start-up and maintenance costs) and were also more likely to report implementation of health IT as having had a negative impact on their practices.

Most physicians who reported use of health IT felt that use of health IT had a positive impact.  However, they frequently cited start-up and maintenance costs cited as barriers to health IT use.  For labs and pharmacies, those not using health IT reported more perceived barriers to health IT use and anticipated a more negative impact on their workflow and productivity.  Among physicians, labs, and pharmacies, the lack of uniform standards within the industry was cited as resulting in poor system compatibility and was a major issue across all types of health IT.

CSHP weighted the physician mail survey data by specialty to be representative of New Jersey’s office-based physicians. Key findings regarding specific health IT use among the state’s physicians responding to the physician mail survey included the following:

  • Nearly three-fourths (72.5%) of physicians reported use of health IT to transmit prescriptions to pharmacies electronically.
  • Nearly two-thirds (62.6%) of physicians reported use of health IT to view test results from clinical labs electronically. However, only 37.1% reported use of health IT to send lab test requests electronically.
  • Nearly half (48.9%) of physicians reported that they maintained 100% of patient records in their EHR systems.
  • More than half of physicians (57.3%) provided a clinical visit summary to at least 50% of their patients. Less than half of physicians (42.9%) provided electronic patient care summaries to other providers. About one-quarter of physicians (23.0%) accessed electronic patient care summaries created by other providers.

In (very general) comparison, the ONC Report found that in 2013, 57% of prescriptions sent by physicians were sent electronically.  ONC also reported that more than two-thirds (69%) of physicians reported having the capability to order lab tests electronically, while more than three-quarters (77%) reported having the ability to view the lab results electronically.

Perhaps statewide health IT interoperability through expansion of and connection among regional NJ HIOs can be achieved in the next decade, but it will require creation of the necessary health IT infrastructure, awareness of its existence by the providers who will use it, and, perhaps, financial or other incentives to effect its adoption and use.

 

When I need to travel from the southern part of NJ to northern NJ, I often rely on my car or phone GPS and the relative ease and simplicity of the NJ Turnpike.  If I needed my southern NJ physician to share information with my northern NJ physician, I might be surprised to learn that it’s not as easy to get my health data from point A to point B.  My physicians might be using electronic health records (EHR) and health IT, but the communications infrastructure in NJ needs to be further developed.  We need greater awareness and adoption of regional health information organizations (HIOs), a way to fund their maintenance (an EZ Pass system for the transmission of health data?), and development of a connected, statewide system.

In January of 2011, the Office of the National Coordinator for Health Information Technology (ONC) awarded New Jersey $11.4 million to be used for developing a strategic and operational plan for health information exchange, and required the state to conduct an independent evaluation of the state’s health IT program.  The Rutgers University Center for State Health Policy (CSHP) conducted the evaluation and published a Report (Brownlee, et al) last year showing where New Jersey physicians stand (or stood, during a survey period that ran from late 2013 to early 2014) in terms of adoption and use of health IT.

NJ Physician Engagement with Regional HIOs - Pie ChartWhen I read the Report, I was surprised to see that while physician use of health IT is increasing, the road to regional health data sharing (let alone statewide sharing) seems to be a long way off.  The Report found that awareness of the existence of a regional HIO by physicians was low (12.5%), and physician participation in a regional HIO was even lower (6.8%). The New Jersey Turnpike is gloriously accessible and functional as compared with this glimpse of the New Jersey health IT highway.

Where Are We Now? to be continued…

I received a disturbing robo-call over the weekend informing me that someone had attempted to use my credit card number fraudulently in a retail store in the next county. When I called back and verified these were not legitimate charges, my card issuer assured me that I would not be financially responsible, canceled my card and sent me a replacement. My imposter was prevented from accessing my account by the issuer’s tight security system. Victims of healthcare identity theft may not get off so easily, which may explain why smarter thieves are increasingly targeting health records.

The relative value of health records and financial data can vary greatly according to different sources. As the Pittsburgh Post-Gazette reported today,

“The value of personal financial and health records is two or three times [the value of financial information alone], because there’s so many more opportunities for fraud,” said David Dimond, chief technology officer of EMC Healthcare, a Massachusetts-based technology provider. Combine a Social Security number, birth date and some health history, and a thief can open credit accounts plus bill insurers or the government for fictitious medical care, he noted.

Reuters reports that medical information is worth 10 times more than credit card numbers on the black market.

Stolen health credentials can go for $10 each, about 10 or 20 times the value of a U.S. credit card number, according to Don Jackson, director of threat intelligence at PhishLabs, a cyber crime protection company. He obtained the data by monitoring underground exchanges where hackers sell the information.

Medscape reports that a stolen chart may be worth as much as $50, citing an FBI bulletin from April 2014:

Cyber criminals are selling the information on the black market at a rate of $50 for each partial EHR, compared to $1 for a stolen social security number or credit card number. EHR can then be used to file fraudulent insurance claims, obtain prescription medication, and advance identity theft. EHR theft is also more difficult to detect, taking almost twice as long as normal identity theft.

Criminals can monetize stolen health data in other creative ways. For example, some healthcare providers and their business associates have been victimized by so-called “ransomware,” which infects computers and encrypts files, then demands payment (often in untraceable Bitcoin) to unlock them. See the FBI’s January 20, 2015 alert entitled Ransomware on the Rise.

Willie Sutton was famously quoted as selecting banks for his robberies because “that’s where the money is.” Today’s healthcare scammers and hackers may be following his lead by focusing their efforts on the asset most valuable to illicit purchasers.

Perhaps the health care industry has a cybersecurity solution staring us in the face:  vaccines.  Perhaps we should be trying to vaccinate our data storage systems rather than relying on firewalls to quarantine them.  In an article posted on www.philly.com, Associated Press author Youkyung Lee says cybersecurity defense has traditionally been based “on the idea that computers could be protected by a digital quarantine.” Instead, posits Lee, experts need to focus on neutralizing attackers once they get inside a data system, rather than continuing the often-futile attempt to keep them out of the system.

Sounds like a digital vaccination to me.  According to the Centers for Disease Control, the United States is facing a multi-state measles outbreak associated primarily with unvaccinated individuals, and much has been written about parents who refuse to vaccinate their children and thereby unnecessarily and irresponsibly expose others to risk of infection.  When it comes to protecting the safety and wellbeing of protected health information and personal data maintained in a computer system, perhaps the vaccination approach is the way to go.

I turned to www.vaccines.gov for a quick description of how vaccines work in the human body.  Under “Mounting an Immune Response”, the site describes the skin in a way that makes it sound like a computer system’s firewall – it “provides an imposing barrier to invading microbes.  It is generally penetrable only through cuts or tiny abrasions.”  The digestive and respiratory tracts also work like firewalls, using acids and respiratory reflexes (coughs and sneezes) to destroy or expel invading microbes.  If the invading microbes succeed in crossing the body’s natural firewalls, the body’s immune system will kick in to thwart invading bacteria, viruses and parasites.  That’s where vaccines become helpful:

“Vaccines consist of killed or modified microbes, parts of microbes, or microbial DNA that trick the body into thinking an infection has occurred.  A vaccinated person’s immune system attacks the harmless vaccine and prepares for invasions against the kinds of microbe the vaccine contained.  In this way, the person becomes immunized against the microbe:  if re-exposure to the infectious microbe occurs, the immune system will quickly recognize how to stop the infection.”

The HIPAA Security Rule also seems to reflect a “digital quarantine” or firewall approach when it comes to implementing technical safeguards, describing implementation of access control, authentication procedures, and transmission security. (However, the requirement that covered entities and business associates implement audit controls that “record and examine activity in information systems that contain or use electronic protected health information” sounds a bit like the first step needed to develop an effective vaccine against hackers.)

So, since efforts to thwart hackers by using a “digital quarantine” (Lee’s description) or firewall type of barrier have been about as successful as relying on hand-washing and avoidance of theme parks to thwart measles, let’s hope cyber experts start to focus on developing digital vaccines.  These vaccines could not only train data systems to detect and stop a hacker after it has entered the system and before it can damage, remove, or copy the data, but also perhaps even trap the virus or other hacking mechanism for identification, analysis, and law enforcement purposes.