> For the complete documentation index, see [llms.txt](https://php-fhir-tools.ardenexal.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://php-fhir-tools.ardenexal.net/code-generation/implementation-guides.md).

# Generating Implementation Guides

Generate typed extension and profile classes for FHIR Implementation Guides.

Generate typed extension and profile classes for an Implementation Guide (IG), such as US Core or AU Core, including multi-level profile inheritance chains.

The `fhir:generate-ig` command targets the IG-specific layer: StructureDefinitions with `derivation: constraint` that are intentionally skipped by the base `fhir:generate` pipeline.

## Command

```bash
php bin/console fhir:generate-ig --package=hl7.fhir.us.core
```

For the full option list, version pinning syntax, and offline mode, see the [command reference](/reference/commands.md#fhir-generate-ig). IG packages can also be configured declaratively under `ig.packages` — see the [configuration reference](/reference/configuration.md#ig).

## What gets generated

The command produces two kinds of class:

| Source StructureDefinition                                                | Generated class                                                                                                | Generator                |
| ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------ |
| `type: Extension`, `derivation: constraint`                               | Typed subclass of `Extension` with the URL baked in and `value[x]` / sub-extensions narrowed to concrete types | `FHIRExtensionGenerator` |
| `kind: resource`/`complex-type`, `derivation: constraint` (non-extension) | Thin subclass of the base resource/type with a `PROFILE_URL` constant and `#[FHIRProfile]` attribute           | `FHIRProfileGenerator`   |

### Generated extension

```php
#[FHIRExtensionDefinition(url: 'http://hl7.org/fhir/StructureDefinition/patient-birthPlace', fhirVersion: 'R4')]
class PatientBirthPlaceExtension extends Extension
{
    public function __construct(
        public ?Address $valueAddress = null,
        ?string $id = null,
        array $extension = [],
    ) {
        parent::__construct(id: $id, extension: $extension, url: '...', value: $this->valueAddress);
    }
}
```

In FHIR, `value[x]` is an extension's polymorphic value element: it can hold one of several types (`valueString`, `valueAddress`, and so on). A *slice* is a named constraint that pins one entry of a repeating element to a specific shape.

`FHIRExtensionGenerator` detects simple vs. complex extensions automatically: simple extensions narrow the `value[x]` type to a concrete PHP type, complex extensions map sub-extension slices to typed properties.

### Generated profile

```php
#[FHIRProfile(profileUrl: 'http://hl7.org.au/fhir/core/StructureDefinition/au-core-patient', baseType: 'Patient', fhirVersion: 'R4')]
class AUCorePatientProfile extends AUBasePatientProfile
{
    public const string PROFILE_URL = 'http://hl7.org.au/fhir/core/StructureDefinition/au-core-patient';
}
```

## Profile inheritance

`FHIRProfileGenerator` resolves each profile's parent from the `BuilderContext`. If the StructureDefinition's `baseDefinition` URL resolves to an IG profile already registered (rather than a base FHIR resource), the generated class extends that profile instead — enabling multi-level chains:

```
PatientResource
└── AUBasePatientProfile      (hl7.fhir.au.base)
      └── AUCorePatientProfile  (hl7.fhir.au.core)
```

Specify packages in dependency order so each package's classes are registered before the packages that extend them:

```bash
php bin/console fhir:generate-ig --package=hl7.fhir.au.base#1.0.0 --package=hl7.fhir.au.core#1.0.0
```

## Isolated output namespace

IG classes are written to a separate `IG/{version}/{slug}/` tree that never overlaps the base models. The `slug` (e.g. `AuCore`, `AuBase`) becomes the namespace segment under `IG/{version}/`:

```
Models/src/
├── R4/               ← canonical base types (fhir:generate)
└── IG/
    └── R4/
        ├── AuBase/
        │   ├── Extension/   ← AU Base extensions
        │   └── Profile/     ← AU Base profiles (e.g. AUBasePatientProfile)
        └── AuCore/
            ├── Extension/
            └── Profile/     ← AUCorePatientProfile extends AUBasePatientProfile
```

{% hint style="info" %}
IG-generated classes live in an isolated namespace tree so they never overlap with the base models. Serializing them requires an IG-aware service — see [IG-Aware Serialization](/serialization/ig-aware.md).
{% endhint %}

## Not generated: OperationDefinitions

`fhir:generate-ig` emits extensions, profiles and constrained complex types. It does **not** emit typed [operation classes](/code-generation/operations.md), so an `OperationDefinition` published by an IG — or authored locally — produces nothing today. Operation generation runs only under [`fhir:generate`](/code-generation/base-models.md), over the core packages.

The obstacle is wiring rather than design: the operation generator needs a type index built from the full `BuilderContext` to classify parameter types and resolve allowed-type variants, and this command does not build one. Until that changes, the workable path for your own operations is to include the `OperationDefinition` in a package that `fhir:generate` loads.

See also [Generated Output Structure](/code-generation/output-structure.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://php-fhir-tools.ardenexal.net/code-generation/implementation-guides.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.