Organizations new to FHIR often assume all FHIR decisions are technical.
They’re not. Implementation is technical. But in most cases business decisions need 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 requirement.
– Not a technical decision.
2. Which FHIR version to use
US regulations mandate R4. Other countries and regions have different requirements.
– Not a technical decision.
3. Which FHIR resources to use
There are 140+ resource types in FHIR. But it’s not a “pick n mix.” Their use cases are well defined and documented.
– Not a technical decision.
4. Cloud or “on-prem”
Managed cloud servers fit neatly into a modern dev’s toolkit but they’re not always the right answer. What do your customers expect?
– Not a technical decision.
5. Implementation Guides and Profiles
There are lots of IGs out there. You can even build your own. But in many jurisdictions and domains, specific IGs and Profiles are mandated and expected.
– Not a technical decision.
6. Data Retention and Privacy
You can’t store and keep patient data just because you want to. ‘Use cases’ when it comes to patient and clinical data varies. GDPR and other regulations have teeth.
– Not a technical decision.
7. FHIR Architecture — façade, hybrid or “FHIR Native”
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
The lesson here is that your organization needs to understand FHIR at all levels. Decisions around implementing FHIR are rarely technical.
---