HL7 statement responds to security worries about FHIR
The organization notes that a white paper highlights the need for re-evaluating protection concerns involving data aggregators and intermediaries.
HL7 International is taking steps to counter concerns that the Fast Healthcare Interoperability Resource (FHIR) standard and application programming interfaces that use it are a security weak link.
The standards organization leading the development and promulgation of FHIR standards and implementation guides, issued a statement late last month to push back on concerns raised by a white paper based on research looking at shortcomings in basic protections in FHIR API implementations.
While the white paper by Alissa Valentina Knight at Las Vegas-based Knight Ink focuses on security challenges of data aggregators and intermediaries using FHIR to enable their access to data, the research has led to some carry over concerns about whether FHIR itself has security flaws.
HL7’s statement highlights that Knight’s white paper “represents a continuation of a project that previously pointed out vulnerabilities in mHealth and telemedicine in the United States, a topic that should concern us all.”
The summary of Knight’s latest research contends that the lack of basic protection in FHIR-based API implementations can result in unauthorized access “to an innumerable of patient records,” enabled by vulnerabilities unearthed through her work.
HL7 executives noted that “The white paper’s eye-catching title, ‘Payling with FHIR: Hacking and Securing FHIR APIs,’ has led some casual readers to infer that FHIR and FHIR APIs are being faulted.” But that’s not the case, the standards organization asserts. “The author (of the white paper) makes clear in the opening paragraphs and throughout that no vulnerabilities were found in the HL7 FHIR standard itself, nor were any found in FHIR-based APIs from the EHRs that she tested.”
The standards group’s statement emphasizes that the vulnerabilities identified by the research “lie with the implementation of apps and by third-party FHIR aggregators.” Misinterpretation of the original title of the white paper caused Knight to rename it to “Playing with FHIR: Hacking and Securing FHIR API Implementations.”
Knight’s findings show that “five FHIR APIs I tested (two of which were EHR vendors with no vulnerabilities), which represented 48 total FHIR mobile/web clients, who aggregated EHR data from over 25,000 healthcare providers and payers, contained pervasive server-side authentication and authorization vulnerabilities that allowed me access to over 4 million patient and clinician records with my own patient log-in.”
Vulnerabilities at server endpoints constitute weak links in protection of healthcare data is of concern because FHIR enables easy, often automated access to records. Protections are important to ensure the identities of those accessing data. Knight writes that she hopes her research draws “public discourse around the ubiquitous problem across healthcare in a systemic failure by aggregators and app developers to implement FHIR APIs securely, despite industry-accepted guidance by Health Level 7 International and the Office of the National Coordinator for Health Information Technology.”
Knight contends that vulnerability rises as “data moves from higher security levels (in healthcare organizations’ systems) to third-party aggregators, where security has been found to be flagrantly lacking.”
Such easy access to data for patients is being encouraged by federal regulations that encourage information sharing with patients. However, there is risk involved, as patients who access information through third-party apps lose HIPAA protection for that data once they do so.
The HL7 statement says Knight’s research “makes a strong case for the new HL7 Standards Implementation Division, which is being created specifically to address concerns like these, as well as providing testing capabilities, reference servers and other resources for implementers. HL7 indicated that it will continue to address findings in the white paper, “the concerns it raises, and what can be done to implement safe and secure APIs.”