You’re a technical architect starting work on a new FHIR project.
You have questions but you’re not finding answers anywhere online.
I speak to companies using FHIR every week. Most of those companies asked the same questions starting out and eventually came to the same or similar conclusions and solutions.
Here are some examples.
Q. When data flows into the FHIR server, how do we track who sent it?
A. Look for a Provenance resource in the incoming bundle. Look also at a resource’s Tags, Security Labels and Meta.source elements.
Q. How do we ensure duplicate records are not created?
A. Consider using or enforcing Conditional update and Conditional create requests for incoming data.
Q. Should we intercept data flowing into or out of our FHIR server?
A. Probably. Maybe not on Day 1, but by the time you get to production you will likely have written an intercept layer that sits in front of your FHIR server.
Q. Can the server handle heavy analytical queries?
A. This is beyond the capabilities of every FHIR API I’ve encountered. All the cloud providers encourage some form of FHIR to Data Warehouse syncing for this purpose.
Q. Do we really need to handle Smart on FHIR?
A. Yes, even if it seems like you don’t. In some countries it’s a regulatory requirement; in all countries it’s an industry standard.
Q. Everyone else is using FHIR R4, but should we consider using R5?
A. Which FHIR version to use is not a technical decision. In the US R4 is mandated by regulation. This is a business decision.
Q. Do we need a Terminology server?
A. Almost certainly yes, although you may not think you do. Getting terminology wrong is a right of passage for new teams building new products in the healthcare space.
There is decades of knowledge to draw upon here. If you try to re-invent the wheel when it comes to terminology, yours will be the only car on the road you built.
Do you have a FHIR related question you can’t find the answer to?
Post a comment below — someone is bound to know the answer.
---