At a Glance
Healthcare software has long been defined by fragmented systems, inconsistent data models, and costly point-to-point integrations. FHIR-first healthcare products solve this by treating FHIR as the internal architecture standard, pairing it with SMART on FHIR authorization and HIPAA-aligned engineering controls from the start. The result is a more interoperable, regulation-ready healthcare platform that can scale across clinical workflows, enterprise integrations, and ecosystem expectations.
For decades, healthcare software has been defined by fragmentation. Clinical data lives in EHR systems that do not talk to each other, lab platforms that export flat files, imaging archives with proprietary APIs, and payer systems that communicate through fax. The patient record that should be a coherent clinical narrative is, in practice, scattered across systems that were never designed to interoperate.
FHIR — the Fast Healthcare Interoperability Resources standard published by HL7 — represents the most credible attempt to change this. The CMS Interoperability and Patient Access Rule, which mandated FHIR-based APIs for payers, and the ONC’s information blocking rules have moved FHIR from a technical aspiration to a regulatory requirement. For healthcare technology companies building products today, the question is no longer whether to support FHIR, but whether to treat it as an integration layer bolted onto an existing architecture or as the foundation the product is built on. The answer has consequences that reach into every layer of the system.
FHIR as Architecture, Not Integration
The most common mistake healthcare engineering teams make with FHIR is treating it as an output format — a translation layer that converts internal data representations into FHIR resources for external consumption. This approach produces FHIR compliance on paper while retaining all the interoperability problems underneath. The data model remains proprietary, the clinical semantics remain inconsistent, and every new integration requires a new translation effort.
A FHIR-first architecture inverts this. The FHIR resource model — Patient, Encounter, Observation, Condition, Medication, DiagnosticReport, and the rest of the specification’s defined resource types — becomes the internal data model. Clinical data is stored as FHIR resources or in a representation that maps cleanly and losslessly to them. The API layer exposes these resources directly through a FHIR RESTful API rather than translating to them on the way out.
Architectural implication: Designing around FHIR resources forces early resolution of the clinical data modelling questions that proprietary schemas defer until they become expensive — how is a diagnosis coded, what terminologies are used for medications, how are observations linked to the encounters that generated them.
The practical starting point for a FHIR-first data model is selecting the resource profiles that matter for the product’s clinical domain and implementing them with appropriate terminology bindings. SNOMED CT for clinical findings, LOINC for observations and lab results, RxNorm for medications, and ICD-10 for diagnoses are the standard vocabulary choices — and committing to them early is what makes the data meaningful across system boundaries, not just within the product.
SMART on FHIR: The Authorization Layer That Enables the Ecosystem
FHIR defines how clinical data is structured and accessed. SMART on FHIR defines how applications are authorized to access it — providing a standardised OAuth 2.0-based authorization framework that allows third-party applications to request scoped access to a patient’s or clinician’s FHIR data on a FHIR server.
For healthcare products that want to participate in the broader ecosystem — launching from within an EHR workflow, accessing patient data from multiple sources, or enabling third-party developers to build on the platform — SMART on FHIR is not optional. It is the authorization standard that health systems and EHR vendors expect, and building it correctly from the start is significantly less painful than retrofitting it when the first enterprise customer or app store submission requires it.
- SMART launch contexts — EHR launch, which embeds the app in a clinical workflow with pre-populated patient context, and standalone launch, which initiates from outside the EHR — have different authorization flows and UX requirements that must be handled separately
- Scope granularity matters for enterprise sales: a product that requests only the FHIR resource types it actually needs, rather than broad patient/* scopes, is a meaningfully easier conversation with a health system’s security team
- Token management and refresh handling must be robust — a clinical application that loses its session during active patient care because of a token expiry edge case creates patient safety risk, not just a UX problem
The Compliance Layer: HIPAA as Engineering Requirement
HIPAA compliance in a healthcare product is not a legal checkbox completed at the end of development. It is a set of engineering requirements that must be designed into the architecture from the beginning, because the cost of retrofitting them — encryption at rest and in transit, audit logging of PHI access, access control tied to minimum necessary use, breach detection and notification infrastructure — is prohibitive if deferred.
The minimum necessary standard is the HIPAA requirement with the most direct architectural consequence. Applications and users should have access only to the specific PHI required for their defined purpose — a billing application should not have access to clinical notes, and a clinician viewing records for one patient should not be able to query data for another without an explicit clinical relationship. Implementing this requires attribute-based access control at the data layer, not just role-based access control at the application layer.
Compliance principle: Audit logging for PHI access must be comprehensive and tamper-evident — every read of a patient record, every modification, and every export must be logged with the identity of the accessor, the time, and the clinical context. This is a HIPAA requirement and an enterprise procurement expectation.
- De-identification pipelines — for research, analytics, and AI training use cases — must implement either the Expert Determination method or the Safe Harbor method defined by HIPAA, not an ad hoc approach that approximates them
- Business Associate Agreements must be in place with every vendor that handles PHI on the platform’s behalf — cloud providers, analytics tools, logging infrastructure — and the architecture must reflect the data handling commitments made in those agreements
- Incident response infrastructure — the ability to detect a potential breach, assess its scope at the PHI level, and generate the notification content required by HIPAA’s Breach Notification Rule — must be built and tested before it is needed
Practical FHIR Implementation Decisions
Several implementation decisions consistently separate healthcare products that achieve genuine interoperability from those that achieve surface-level compliance. The choice of FHIR server — whether to build on an open-source server like HAPI FHIR or a managed service like Azure Health Data Services or Google Cloud Healthcare API — determines the starting point for the compliance and scaling posture. Managed services reduce the operational burden significantly for teams without deep FHIR server expertise, at the cost of some configuration flexibility.
Versioning is a practical challenge that FHIR-first teams encounter early. FHIR R4 is the current standard for most US regulatory requirements, but some EHR vendors still expose DSTU2 or STU3 endpoints. The integration layer must handle version negotiation and translation without degrading the internal data model to the lowest common denominator.
CDS Hooks — the complementary standard for surfacing clinical decision support within EHR workflows — is the natural extension of a FHIR-first architecture for products with a clinical decision support component. Building CDS Hooks services on a FHIR-native data model is significantly more tractable than retrofitting them onto a proprietary clinical data store, and it is the integration pattern that health systems increasingly expect from third-party clinical tools.
The healthcare technology companies that are building durable products in this environment have made a deliberate choice: treat the standards not as compliance overhead but as the shared language that makes the entire ecosystem more valuable. FHIR-first is not the easiest architectural path at the start. It is the one that compounds in the right direction.
At Nineleaps, we help healthcare technology companies build FHIR-native products from the ground up — designing the data models, compliance layers, and integration architectures that let teams move fast without accumulating regulatory debt.
