Home  |   Subscribe  |   Resources  |   Reprints  |   Writers' Guidelines

Winter 2022

Health Care’s Digital Health Balancing Act
By Selena Chavis
For The Record
Vol. 34 No. 1 P. 20

Experts weigh in on the vulnerabilities of patient data sharing via third-party apps and aggregators.

When it comes to advancing the progress of information sharing, there is a delicate balancing act underway in the health care industry. While current movements aim to give patients greater control and ownership of their health care data, the industry is still trying to identify the equilibrium between access and data security.

The 21st Century Cures Act is a critical catalyst of the current movement to expand patient access to personal health care data. As of January, the legislation opened the door for patients to share data with third parties through application programming interfaces (APIs)—a move that some experts believe will create new vulnerabilities for protected health information (PHI).

“There's a push toward making patient data available between institutions and with the patient. And I'm firmly in favor of doing that,” says Graham Grieve, inventor of and product director for HL7 Fast Healthcare Interoperability Resources (FHIR), a solution aimed at improving information sharing between health systems and other stakeholders via APIs. “But of course, that means you have to get the security right.”

For covered entities and their business associates, HIPAA provides a high-stakes framework for providing adequate protection of PHI. But now the question becomes: What standard of protection is expected of other third-party apps when patients choose to share information?

Consider the following hypothetical scenarios:

• A large employer wants to better understand the health of its employee base to inform wellness initiatives and health plan negotiations. To that end, employers are offered $100 to download health information into the company’s wellness act with the understanding that it will be deidentified for analytics purposes.

•  A patient engages with a company offering a health monitoring app for a particular condition and chooses to share health record information to optimize analysis.

•  A contract research organization offers patients an incentive to participate in a study that requires sharing information with a mobile application designed by the organization.

The hypotheticals are many, according to Robert Tennant, vice president of federal affairs with WEDI. And while the above scenarios seem benign on the surface, some industry experts fear that this expanded access will open doors to sensitive PHI getting into the wrong hands and producing devastating impacts.

“I think everybody in the industry agrees with the theory that patients getting access to their health information, being able to leverage their mobile technology, whether it be a phone or a tablet, is a tremendous leap forward in health care,” Tennant says. “The opportunities for increased patient engagement, for a more collaborative relationship between the provider and the patient, are certainly at the heart of why the government is promoting this patient-centric approach to health care, and certainly we as an organization completely support that. Having said that, I think there are some inherent issues that need to be dealt with if we are to move to this more patient-centric health care environment.”

Digging Deeper Into the API Conundrum
Even with HIPAA, Grieve points out that security remains a mixed bag in health care because attitudes about what’s important and what’s not vary widely. He offers an example of the variances in attendees at HL7’s FHIR Connectathons, events held routinely to help industry professionals identify best practices around interoperability.

One group of engineers may come to the event with two laptops—one synched with the corporate system and one air-gapped from the corporate system used for testing—to optimize security. In stark contrast, other organizations may show up with no security culture, openly accessing the web from corporate laptops without the right security framework in place and ultimately opening the door to bad actors.

Now that patient-directed sharing is added to the mix, some industry professionals fear that an already significant challenge will become much more complex. New regulations now require that health care providers, including physicians and hospitals, as well as health plans, make patient information available to the patient-designated app of their choice without blocking the data.

“I understand the theory—that it’s the patient who should be making the decision on whether or not the information flows to that third-party app, but the reality of health care is that patients may not be as informed as they should be regarding the potential inappropriate disclosure of their health information,” Tennant says, pointing out that PHI landing in the wrong hands is much different than other types of data breaches. “With health care, you're talking about some of the most sensitive data that we have as individuals, whether it be mental health information, substance abuse, cancer treatment, or fertility issues. These are at the core of who we are as individuals. If you get your credit card stolen, it's terrible, but you stop the card and get a new one. But if your information on substance abuse is out inappropriately, that could be tremendously harmful to the individual.”

While foundationally health care organizations should no longer be responsible for what happens to patient information once a request for sharing with a third party is honored, Grieve notes that there is some gray area that could pose problems. To that end, he provides another hypothetical: “If the institution or the vendor working on behalf of the institution offers the patient a convenient service to hook up an app to their record, how much responsibility does that institution and/or the vendor acquire for the behavior of the application? And is that related to how strongly they're recommended? At what point do they become accountable from a legal sense?”

Tennant poses an issue from another angle, suggesting that patients may not read the “fine print” associated with a third-party application. What if the vendor providing a particular app says in the terms and conditions that it reserves the right to use and sell the data?

“We hope that [vendors] will be good stewards of patient data, but absent strong federal regulations, I don't think that can be guaranteed,” Tennant says, pointing to multiple hearings in recent years associated with Big Data companies such as Facebook and Google. “We know that there is tremendous risk associated with Big Data. And here we're talking about what I call sort of micro data—the individual's health information.”

Basically, Tennant notes, the guidelines currently provided to covered entities are that they can educate and warn the patient, but they cannot prohibit the information from flowing.

How Can Providers Protect Themselves?
Protection for health care organizations starts with education, according to Tennant, who offers the following recommendations:

• Be proactive. For example, an organization dedicated to cancer treatment should gain an understanding of the types of apps available to patients in that specialty. This process could encompass learning which apps have accreditations or follow optimal security and privacy guidelines. “That provider will give you a prescription perhaps for a medication, and they can also give you a prescription for a health app that that they have found to be effective and secure,” Tennant says.

• Provide general education to patients about the dangers associated with downloading data to an app and the questions that should be asked when considering use.

• Document all education provided. “Make a note in the chart that you spoke to Robert on 12/16 and reminded him of the potential dangers of this or that,” Tennant says. “If that is a requirement or a recommendation from the government, then it's only valid if it's written down.”

Better definitions of the regulations in this space would go a long way to protecting providers and patients, Grieve says. That starts with clarity around who is accountable when data shared across an API are compromised—an area where the Office of the Inspector General falls short, he says.

Regulations around security and privacy should also extend to third-party app vendors and data aggregators in the same way that HIPAA applies to covered entities, Grieve says. “[Covered entities] are looking at the data aggregators on the patient side and saying, ‘they could do whatever if they wanted.’ If they got data from the patient, and then they published it on the web, they are not breaking the law,” he points out. “They might have broken their commercial contract with the patient, if they had one, but they haven’t broken any law. It's the Wild West—there's no laws—providing accountability to those services that aggregate data from the patient under the patient's choice.”

Tennant believes there has been some recent shift as it pertains to regulation, noting that the Federal Trade Commission (FTC) has started to be a little more aggressive in this area. In September of 2021, the FTC issued a policy statement affirming that health apps and connected devices that collect or use consumers’ health information must comply with the Health Breach Notification Rule. And while that’s a good first step, Tennant says that it’s a complex way forward because there are multiple federal agencies that oversee privacy and security.

“You have obviously FTC, you've got CMS [Centers for Medicare & Medicaid Services], you've got OCR [Office for Civil Rights] and you've got all of ONC [Office of the National Coordinator for Health Information Technology]. So, at a minimum, I think we have to have a unified federal approach to protecting the data,” he says. “I think that's one area where the federal government could act.”

Tennant says it's a question of when not if that the industry sees abuses associated with patients sharing their data with third-party apps. “We know that a health record itself is worth hundreds of dollars on the black market,” he says. “We know that there's a nefarious market for the information, so will this sort of be a pipeline for these folks? One solution is to require or to allow the covered entity, health plan, or provider to just say, ‘We restrict access to those apps that have been certified or accredited by third-party accreditors.’”

— Selena Chavis is a Florida-based health care writer.


While covered entities may not have control over patient choices when it comes to sharing information with third-party apps, providers can better understand and protect themselves through the Malicious Domain Blocking and Reporting (MDBR) service. The MDBR is available to state, local, tribal, and territorial government members of the Multi-State Information Sharing and Analysis Center (MS-ISAC) and the Elections Infrastructure Information Sharing and Analysis Center (EI-ISAC) in partnership with the Cybersecurity and Infrastructure Security Agency and Akamai.

MDBR technology prevents IT systems from connecting to harmful web domains, which helps limit infections related to known malware, ransomware, phishing, and other cyber threats. This capability can block most ransomware infections just by preventing the initial outreach to a ransomware delivery domain.

Once an organization points its domain name system (DNS) requests to the Akamai’s DNS server IP addresses, every DNS lookup is compared against a list of known and suspected malicious domains. Attempts to access known malicious domains such as those associated with malware, phishing, and ransomware, among other threats, are blocked and logged. CIS then provides reporting, including log information for all blocked requests, and assists in remediation if necessary.

The service is considered easy to implement and requires virtually no maintenance because CIS and the DNS vendor fully maintain the systems required to provide the service.

How to Sign Up
Existing MS-ISAC and EI-ISAC members can sign up for no-cost MDBR by registering at mdbr.cisecurity.org. Applicants will be asked to provide the following information:

• contact information;

• technical contacts for MDBR setup, troubleshooting, and general technical support;

• contacts for receiving reports on your MDBR service; and

• the public IP addresses or classless inter-domain routing netblocks from which your organization’s DNS queries are sent.

If your organization isn’t yet an MS-ISAC or EI-ISAC member, you’ll first be asked to join.

More information is available at cisecurity.org.

— SC