The “FHIR for Technical Architects” book does not exist.
It should, because the documentation is less than ideal when it comes to addressing the needs of architects.
In its absence, here are some insights I’ve picked up the hard way that might help.
- Security labels should never be ignored.
- FHIR servers do not all validate resources automatically.
- Don’t assume you’re allowed to store data in your FHIR server for as long as you like.
- Regulations govern the use of specific Implementation Guides in specific countries.
- The Meta.source element sometimes tells you the source of the data.
- The Provenance resource may also tell you the source of the data.
- On many FHIR servers a DELETE request is only a soft delete. The data is still there.
- A hard delete or a $purge-history is another step in the process.
- Regulations govern the version of FHIR that should be used in certain countries.
- Loading Implementation Guides into a FHIR server is not always easy.
- Conditional updates (PUT requests) can help prevent duplicate resources.
- Running real-time analytics using FHIR queries is not a good idea.
- _include and _revinclude can cause performance issues on some FHIR servers.
- All FHIR servers allow non-conforming data in — it’s a matter of degree.
- Validating against profiles and Implementation Guides is hard.
- Most FHIR servers allow you to create custom search parameters — even on extensions.
- Smart-on-FHIR is rarely as easy to implement at the server level as articles suggest.
- The “resolve-as-version-specific” extension lets you enforce versions in resource references — where implemented.
- The country the FHIR server resides in matters. Regulations again.
- Many FHIR servers truncate included resources.
---