The “Guide to Architecting a Production FHIR Application” doesn’t exist. I learned this the hard way.
So here are a few notes that might help other architects looking to make their FHIR applications “production ready”.
Today I’m talking about the data flow. Over the next few weeks I’ll touch on other areas.
1. Middleware — Intercept FHIR queries
You may need to intercept FHIR bundles and resources as they go in and out of your server. You might not realize this until your project is 70% complete. Take a look at Azure’s Health Data Services Toolkit for a working example of how to do this.
https://github.com/microsoft/azure-health-data-services-toolkit
2. Security Labels
It’s likely for a host of different reasons (think access control, resource usage and management) that you will want to ‘tag’ resources as they go into your FHIR server. Security labels are a good way to do this and the ds4p Implementation Guide is a great starting point.
Security labels: https://build.fhir.org/security-labels.html
The dsp4 IG: https://build.fhir.org/ig/HL7/fhir-security-label-ds4p/toc.html
3. Running Data Analytics on FHIR
FHIR is NOT a relational database. You cannot easily run calculations on your FHIR data using query parameters alone. Yet the business may want to run heavy duty analytics as the data stored in FHIR accumulates. Here is how other applications achieve this.
https://darrendevitt.com/how-do-you-run-labor-intensive-queries-on-your-fhir-server-in-real-time/
4. Smart on FHIR
In classroom projects Smart on FHIR looks easy. In real-world production environments it’s not. Depending on your use case you may decide not to use Smart on FHIR at all, especially if you’re building a B2B app with no consumer use.
Smart on FHIR video from Josh Mandel: https://www.youtube.com/watch?v=AgIZBKNqQ4I
---
Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.