FHIR servers are wide open by default. Security measures rarely come built in.
They accept any valid data you send them and they send back any data you ask for in a search query.
When it comes to security, Smart-on-FHIR helps — but it’s only one tool in a very large toolset. You have to build most of the other tools yourself.
Here’s a key question you should be able to answer about every resource and every element in your FHIR server:
- Who did what, and when?
Who accessed a resource? Who updated a resource? When did they do it?
If you can’t answer that question, your toolset is missing some key pieces.
FHIR comes with two resource types that help here: AuditEvent and Provenance.
If you’re not populating these resource types (or their non-FHIR equivalents) each time a request comes in, you can’t answer the who, what and when question.
If you are, sit down with your technical architect and lead developers and ask them the following questions.
- Does the AuditEvent identify the individual who accessed a resource?
- Are you controlling access to AuditEvent resources?
- Are your audits in the same FHIR server as the rest of your data?
- Are all updates to resources accompanied by a Provenance?
- Does the Provenance correctly identify all the parties responsible for creating the data?
- Does it link to a specific historic version of the resource?
And here’s a question your devs do not want you to ask:
- Can I bypass the AuditEvent and Provenance creation using Postman?
There’s no one-size-fits-all solution here, but you need to be asking these questions.
We all do.
AuditEvent: http://hl7.org/fhir/R4/auditevent.html
Provenance: http://hl7.org/fhir/R4/provenance.html
---