Organizations new to FHIR often assume all FHIR decisions are technical.
They’re not. Implementation is technical. But in most cases a business decision has to be made first.
If your developers have full responsibility for any of the below, you have a problem.
1. Choosing FHIR
Exposing data via a FHIR API is often a regulatory or legal requirement.
– Not a technical decision: https://www.healthit.gov/topic/oncs-cures-act-final-rule
2. Which FHIR version to use
The Cures Act in the US mandates version R4. Other countries and regions have different requirements.
– Not a technical decision: https://www.healthit.gov/sites/default/files/page2/2020-03/APICertificationCriterion.pdf
3. Implementation Guides and Profiles
There are lots of IGs out there. You can even build your own. But in many jurisdictions and fields, specific IGs and Profiles are mandated.
– Not a technical decision: https://build.fhir.org/ig/HL7/US-Core/
4. Which FHIR resources to use
There are 140+ resources in FHIR. But it’s not a “pick n mix.” Their use cases are well defined and documented.
– Not a technical decision. Example: https://hl7.org/fhir/R4/financial-module.html
5. Data Retention and Privacy
PI and PII data should not be retained once their use case is fulfilled. GDPR is the most well known example of where this is legally enforced. ‘Use case’ in the medical context varies.
– Not a technical decision.
6. FHIR Architecture — façade, hybrid or repository
The outlier in the list. Once the decision to share data using FHIR is made, the next decision is how to do it.
– A technical AND a business decision: https://www.smiledigitalhealth.com/fhir-facade-or-repository
The lesson here is that your organization needs to understand FHIR at all levels. Decisions around implementing FHIR are seldom purely technical.
---
Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.