Track 1 — FHIR Fundamentals

What is a Profile

Base FHIR is intentionally loose — almost everything is optional. A Profile is a StructureDefinition that constrains a base resource for a specific use case, country, or institution.

Why profiles exist

A base FHIR Patient has almost no required fields. name, gender, and birthDate are all optional. This makes the base spec flexible enough for every country and every clinical scenario — but too flexible for any specific implementation.

A hospital admissions system needs a patient name. An e-prescription system needs a national identifier. A cross-border EU exchange needs a specific identifier format and mandatory language preference. None of that is enforceable by base FHIR alone.

Profiles solve this. They layer additional constraints on top of base FHIR without changing the spec. A resource valid against a profile is automatically valid base FHIR R4 — profiles can only restrict, never expand.

StructureDefinition

A Profile is expressed as a StructureDefinition resource. The key fields:

urlGlobally unique identifier for the profile. Used in meta.profile[] to declare that a resource conforms to this profile.

baseDefinitionThe resource or profile being constrained — e.g. http://hl7.org/fhir/StructureDefinition/Patient.

derivationconstraint (restricts an existing type) or specialization (creates a new type — rare).

differentialOnly the elements that differ from the base. Shorter and easier to read — this is where you write constraints.

snapshotThe full element list after merging differential with the base. Generated by tooling, not written by hand.

StructureDefinition skeleton

{
  "resourceType": "StructureDefinition",
  "url": "https://fhir.sk/fhir/StructureDefinition/fhirsk-patient",
  "name": "FhirSkPatient",
  "status": "draft",
  "fhirVersion": "4.0.1",
  "kind": "resource",
  "type": "Patient",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Patient",
  "derivation": "constraint",
  "differential": {
    "element": [ ... ]
  }
}

What a profile can constrain

Cardinality

Patient.gender: 0..1 → 1..1

Make optional elements required, or restrict repeating elements. You can only increase the minimum or decrease the maximum — never the other way.

mustSupport

Patient.address: mustSupport = true

Does not change cardinality. Means: systems claiming conformance to this profile must store and return this element if it is present. The profile author defines what 'support' means in their context.

fixedValue / patternValue

identifier.system: fixed = urn:oid:2.16...

Lock an element to a specific value. fixedValue requires exact match. patternValue allows the value to be a superset (used for complex types).

Binding

gender: required binding to AdministrativeGender

Restrict a CodeableConcept or code element to a specific ValueSet. Binding strength: required (must use), extensible (should use), preferred (recommended), example (illustrative only).

Slicing

identifier sliced by system value

Split a repeating element into named sub-types with their own constraints. Discriminator defines how entries are assigned to slices. rules: open allows unrecognised entries; rules: closed rejects them.

Extension

Adding birthPlace extension

Add new data elements not present in the base spec. Extensions are defined as separate StructureDefinitions and referenced by URL. Every FHIR element can have extensions.

FhirSk Patient — our profile

We built FhirSkPatient to constrain the base Patient to the minimum set of fields a Slovak healthcare system would need:

Element	Base	Profile
identifier	0..*	1..*
name	0..*	1..*
name.family	0..1	1..1
name.given	0..*	1..*
gender	0..1	1..1
birthDate	0..1	1..1
address	0..*	0..* (mustSupport)
communication	0..*	0..* (mustSupport)

Profile file: examples/profiles/fhirsk-patient.json. Try it in the Validator.

Real-world profiles

International Patient Summary (IPS)

HL7 global standard for a minimal patient summary. Defines profiles for Patient, AllergyIntolerance, Medication, Condition, and a Composition that bundles them. Used as the basis for EHDS.

US Core

The US national FHIR profile set, required by the ONC 21st Century Cures Act. Defines must-support elements and US-specific value sets for all major resources.

EHDS EHRxF

European Health Data Space exchange format. Being developed by the EU as the mandatory cross-border exchange standard. Based on IPS, extended for EU context.

Da Vinci / CARIN

US payer/provider interoperability IGs for prior authorization, coverage, and claims. Industry-specific profiles built on US Core.