2-cents on “ Playing with FHIR” recommendations
Not “Playing with FIRE.” Not “Playing with FIRE.” This is “Playing with FHIR: Hacking and Securing FHIR APIs.”
Now, I know I’m playing right into the sponsoring company’s hands by further promoting their content marketing / inbound marketing material, but I just cannot help myself.
Grahame Grieve, John Moehrke and Keith Boone have weighed in better than I ever could.
The TL;DR from Moehrke
The things that Alissa found were very remedial cyber security issues.
My two issues with the report
- The mixing of technical (academic) white paper, blog post and inbound marketing undermines the credibility of the work.
- Some of the recommendations are well intentioned; but, because of the particular politics of large enterprises subject to the ONC Final Rule (EHR vendors) and CMS Final Rule (payers, state medicaid agencies), could be used to circumvent information blocking rules.
Well-intentioned recommendations that are too broad
Require that FHIR app developers and data aggregators perform regular penetration testing that includes static and dynamic code analysis of their apps before connecting into production EHR systems.
Likely too broad.
- Example of excessive use case: I, the patient, want to connect a script to pull my own data.
- Example of where this might make sense: An aggregator used by 100k people
Clarify that the Security Exception to the Information Blocking Rule allows EHR vendors to require specific controls be implemented by any system that connects to their APIs.
Reasonable intent, but too easily abused. This would allows EHRs carte blanche to disallow connections based on any (potentially arbitrary) control they impose. This would end-run around 5 years of ONC work crafting the information blocking rule.
Regulatory bodies, standards authors, and health IT developers should focus on ensuring these APIs are securely developed and implemented. Right now, the focus is nearly 100% on near-free access to the data.
The first sentence is fine; the second is demonstrably false. ONC, CMS (and HHS OCR when they publish their final rule) are balancing the right of access with privacy/security, within the constraints of their regulatory authority and APA (Administrative Procedures Act). They are coordinating so there aren’t major holes (e.g. ONC and CMS rules came out same day). Overall, they’re doing as well as can be expected.
Put in place app and device attestation checks in your API endpoints and require any apps connecting to your endpoint to implement this control. The Approov solution effectively prevented my malicious traffic from reaching API endpoints that I tested.
Not to beat a deadhorse, but the sponsor plug undermines an otherwise reasonable statement. This is a concrete example of where the blurring of technical white paper (what I wish the report was) and inbound marketing (what the report is presented as) undermines the credibility of the recommendation.
Government mandated exposure of FHIR services creates a “killing field” of FHIR APIs when used by unaffiliated patient-facing app developers whom the EHR vendors have no influence over selecting.
Let’s replace “creates a killing field” with the less loaded term “enables an ecosystem,” and you’ll find the entire point of the ONC Information Blocking provisions. EHR vendors (ONC rule) and Payers (CMS rule) should not be able to unilaterally block access to a patients information.
When creating different apps for different healthcare providers, don’t use the same database to store the patient records for each provider. This creates the potential for all your EHR data to be leaked as a result of a vulnerability in just one of the apps. Each microservice should have its own isolated database.
Comes from a good place, but again too broad. Imagine using the same database with different interfaces for each app (where the interface then connects to various microservices and those microservices hit the same database). Yep, the first part (app → interface → microservice) is the API gateway pattern, and it’s perfectly valid.
