In modern healthcare IT, systems are becoming increasingly digitised, distributed, mobile, cloud-based, and heterogeneous. For meaningful value to emerge - for example in care coordination, population health, mobile health, cloud analytics, and patient‐centric applications - healthcare data must flow seamlessly across organisational, vendor, device and geographic boundaries. This is the aim of interoperability.
In this blog we will:
FHIR was created by HL7 to address the challenges of previous healthcare interoperability standards (for example HL7 v2.x, HL7 v3, CDA) which had significant complexity, vendor-lock-in, heavy document-centric models, and slower adoption.
FHIR's core idea: define discrete "resources" (representing concepts such as Patient, Observation, Medication) and expose them via modern web‐standards APIs. This helps reduce the barrier to implementation and fosters real-time, modular, lightweight exchange.
The design goals included:
These fit your original summary, which I’ll restate and elaborate:
In this section we dive into the architecture, key building blocks, how the spec is organised (referring to the latest published release of FHIR), and give concrete examples of the resource/endpoint/structure.
Patient resource may look like (in JSON):{
"resourceType": "Patient",
"id": "12345",
"identifier": [ { "system": "...", "value": "P-12345" } ],
"name": [ { "family": "Smith", "given": ["John"] } ],
"birthDate": "1980-05-12",
"gender": "male"
}
Patient may be referenced by Observation.subject). This enables composition of data.meta, text, id, implicitRules, language).
Identifier, CodeableConcept, Reference, Quantity).meta element that tracks versionId, lastUpdated, profiles, security labels, tags.extension elements at specified extension points. That enables use-case specific fields without modifying the core spec.
While the most commonly used mechanism is RESTful API, FHIR supports other modalities as well.
GET /Patient/12345 → retrieve resourcePOST /Patient → create new PatientPUT /Patient/12345 → update (replace) PatientPATCH /Patient/12345 → partial updateDELETE /Patient/12345 → delete (or mark inactive)GET /Patient?identifier=xyzBundle resource groups multiple resources into a single transaction, batch, message or overall collection. For example, a bundle could contain a new Patient resource, some associated Observations and a Condition.
Here is a more concrete walkthrough of how the spec presents itself and how you, as an implementer or security reviewer, might navigate it.
From the spec you might see something like:
resourceType (constant = "Patient")id (Logical id of this resource)meta (metadata about the resource)implicitRules, languagetext (narrative)identifier (0..*, identifiers for the patient)active (boolean)name (0..*, HumanName datatype)telecom (0..*, ContactPoint datatype)gender (AdministrativeGender)birthDate (date)deceased[x] (boolean or dateTime)address (0..*, Address datatype)contact (0..*, Patient.Contact)managingOrganization (Reference(Organization))And so forth. The element definitions include cardinalities, types, binding (if applicable), and description of each. The spec also provides example JSON and XML serialisations.
Suppose you want to find all patients with last name "Smith". Using a FHIR server you might send:
GET https://fhirserver.com/Patient?family=Smith
Accept: application/fhir+json
The server returns a JSON bundle of Patient resources matching that criterion. Sorting, paging, filtering by other parameters is also supported. The spec includes details on search parameter names, resource names, interactions (read, vread, update, delete, history, etc).
Resources can reference each other. For example, an Observation may have a field subject referencing Patient/12345. Server implementations must enforce the references (or at least resolve them). Bundles may contain multiple resources: for example, a bundle may contain a Patient, then one or more Observations for that patient, possibly with Condition or Medication resources. The server may treat this as a transaction (atomic) or batch (non-atomic) depending on the bundle type.
The specification includes a section for security & privacy, which covers: authentication/authorization, transport security (TLS), user identity, role or scope‐based access, audit logging, confidentiality, consent, provenance, security labels, usage of SMART on FHIR, OAuth2 and OpenID Connect for app and user authorisation flows.
CapabilityStatement that declares what resources, interactions, profiles, versions, search parameters, and security mechanisms are supported. This helps clients discover capabilities.
In short: The spec gives you everything you need to implement and secure a FHIR server or client: data models (resources, datatypes), API mechanics (REST endpoints, interactions, transactions), versioning/compatibility rules, resource references, search capability, profiling & extensions, and security/privacy guidance. As you move into production, you move from base spec (generic) into implementation details (profiles, IGs) for your domain/regional needs.
When implementing or deploying a FHIR‐based system (server, client, middleware, apps), it is tempting to focus only on the "data" - e.g., "Does the patient record content follow the schema? Are the code values valid? Is the data encrypted in transit?" These are of course necessary. But they are not sufficient. Security testing must also target the exchange surface, the API semantics, the protocol logic, the linkage among resources, the extensions, the search interface, and the workflow/authorization context. Here is why.
A FHIR system exposes multiple attack surfaces:
Here are several specific reasons why one must test the protocol thoroughly, beyond just payload validation:
CapabilityStatement incorrectly advertises allowed operations, clients may assume more capabilities than intended.POST /Patient and create new records or modify sensitive data. Or a user allowed only "read" can perform "update".Bundle transactions to perform unintended operations.GET /Observation?code=XYZ&date>=2020-01‐01) that may return unexpected volumes of data or include sensitive fields.Observation.subject referencing a Patient) create a graph. An attacker might traverse references to gather information indirectly.$export. If mis-configured this can become an attack vector for mass data exfiltration.
Here is a structured checklist for security testing a FHIR implementation (beyond data payload checks):
Authentication & Authorization
Endpoint coverage & versioning
CapabilityStatement./Patient vs /R4/Patient) is handled safely.
Resource operations (CRUD, search)
Bundle & transaction logic
Resource relationships & graph traversal
Extensions and custom profiles
Error/Exception handling
Transport / network layer
Audit, provenance, logging
Finite resource limits, DoS prevention
Data lifecycle and versioning
/Patient/12345/_history returns previous versions. Check that deleted resources behave correctly.
Third-party app integration (SMART on FHIR, mobile apps)
Terminology & code system binding
GET /Patient?family=Smith and retrieves all patients with last name “Smith”.POST with a bundle that deletes resources (via transaction) and the server executes it./v2/Patient remains open and lacks proper authorization.$export with no filtering allows the attacker to extract all patients and their associated resources.
In this section I will describe how the fuzzing / security testing platform Penzzer can be used to evaluate FHIR-based systems: what capabilities Penzzer brings, how to configure for FHIR, what scenarios to cover, what to watch for, and how to interpret results.
Penzzer is a fuzzing and security testing solution designed for APIs, microservices, and modern system interfaces. It enables security teams, QA engineers, and developer teams to drive automated exploration of interface behaviours, inject malformed or unexpected inputs, identify logic flaws, access control weaknesses, and protocol mis-implementations. The platform is capable of integrating protocol definitions, generating test sequences, capturing logs/traces, and producing actionable findings.
In the FHIR context, Penzzer can be used to test the API layer (REST endpoints), to replay standard interactions, inject malformed requests (resources, bundles, search parameters), test search behaviour, transactions, versioning, references, and assess compliance with security/authorization policies.
CapabilityStatement of the target server to determine supported resources, interactions, search parameters, versions, profiles.
meta.versionId, meta.lastUpdated).
Using Penzzer, configure fuzzing / mutation campaigns along these axes:
/Patient/invalidID, /Patient/12345a), missing mandatory elements in created resources, invalid datatypes, invalid JSON/XML structure.If-Match headers).resourceType or invalid “type” attribute.$export, attempt with highest useful dataset size, minimal filtering. Assess if authorization is enforced and if rate limits apply./R4/Patient) if supported; test if they have weaker security or unintended access.
When fuzzing a FHIR implementation you often find issues such as:
GET /Patient?family=Smith and retrieved 1047 patient records including full demographics; expected only patients under the clinician’s care").
CapabilityStatement provided by the server.
In summary:
Identify security flaws before attackers do, automatically and at scale with Penzzer's intelligent fuzzing engine.
Unified Automotive and IoT Security Testing Tool
Accelerate Vulnerability Detection with Pen Testing and Dynamic Fuzzing
Find and fix vulnerabilities fast, only Penzzer unifies pen testing and dynamic fuzzing to meet compliance standards
Uncover hidden vulnerabilities in your IoT/automotive systems 5x faster than manual testing.
