Capability Statement

The CapabilityStatement describes what the Ignixa FHIR server can do. Access it at:

GET /metadata

Server Information

{
  "resourceType": "CapabilityStatement",
  "status": "active",
  "kind": "instance",
  "fhirVersion": "4.0.1",
  "format": ["json"],
  "software": {
    "name": "Ignixa FHIR Server",
    "version": "1.0.0"
  }
}

Supported Interactions

Instance Level

Interaction	Support	Notes
`read`	✅	Retrieve by ID
`vread`	✅	Retrieve specific version
`update`	✅	Full resource replacement
`patch`	✅	FHIRPath Patch, JSON Patch
`delete`	✅	Soft delete
`history-instance`	✅	Version history

Type Level

Interaction	Support	Notes
`create`	✅	Server-assigned ID
`search-type`	✅	Search with parameters
`history-type`	✅	Type history

System Level

Interaction	Support	Notes
`transaction`	✅	ACID bundles
`batch`	✅	Independent operations
`history-system`	✅	Full history
`search-system`	✅	Cross-resource search

REST Capabilities

{
  "rest": [{
    "mode": "server",
    "security": {
      "cors": true,
      "service": [{
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/restful-security-service",
          "code": "SMART-on-FHIR"
        }]
      }]
    },
    "resource": [
      // Per-resource capabilities
    ]
  }]
}

Package-Defined Resource Types

Concrete custom StructureDefinition specializations can contribute resource types without a server restart. Their snapshot root supplies the simple type name, while rest.resource.profile retains the actual package canonical. For the embedded ViewDefinition model this is https://sql-on-fhir.org/ig/StructureDefinition/ViewDefinition, not a core FHIR URL.

Profiles and abstract definitions do not create resource-type aliases. A package ID cannot replace a core type, and conflicting canonicals declaring the same custom type name do not receive an ambiguous alias. Capability enforcement remains active for all requests. Admitted custom types inherit universal Resource search parameters even when their package does not define any additional SearchParameters.

A successful package load or unload refreshes the affected tenant's schema and capability caches before returning, including when /metadata was already requested. Unsupported resource types remain rejected with HTTP 404 and a FHIR OperationOutcome, not an empty JSON object.

Operations

Operation	Level	Description
`$validate`	Type, Instance	Validate resource against specs/profiles
`$everything`	Instance	Retrieve all patient data
`$member-match`	Type	Match patients across payer systems
`$export`	System, Group	Async bulk data export
`$import`	System	Async bulk data import
`$summary`	Instance	Generate International Patient Summary
`$expand`	Type, Instance	Expand ValueSet to codes
`$translate`	Type	Translate codes via ConceptMap
`$subsumes`	Type	Test code subsumption
`$transform`	Type, Instance	Transform data via StructureMap

See Operations for detailed usage and examples.

Versioning

Ignixa supports resource versioning:

versionId auto-increments on each update
lastUpdated timestamp on every modification
Full version history accessible via /_history

Version identifiers in vread URLs are opaque FHIR id values: 1-64 ASCII letters, digits, hyphens or periods. SQL Server generates canonical positive integer versions, but a legal unavailable identifier (including a UUID) returns HTTP 404, not a malformed-input error. Alternate spellings such as 01 do not alias stored version 1. Invalid FHIR ID syntax returns HTTP 400.

A successful PUT-as-create, including conditional PUT creation, returns a version-specific Location ending in /{resourceType}/{id}/_history/{versionId}. This URL continues to identify that created version after later updates.

Version-Aware Updates

Use If-Match header for optimistic concurrency:

PUT /Patient/123
If-Match: W/"5"
Content-Type: application/fhir+json

{ ... }

Conditional Operations

Conditional Create

POST /Patient
If-None-Exist: identifier=12345

{ ... }

Conditional Update

PUT /Patient?identifier=12345

{ ... }

Conditional Delete

DELETE /Patient?identifier=12345

No matches is a successful no-op, not a search-not-found error. In default single mode, zero or one match returns HTTP 204 without a body; ambiguous multiple matches return HTTP 412, consistent with conditionalDelete: single.

Ignixa's optional _count deletion-limit extension returns HTTP 200 with an informational OperationOutcome, including when zero resources match. This partial-deletion limit is not an R4 requirement. Microsoft-specific hardDelete and _includesCount cascade semantics are not implemented by this contract.

Formats

Format	MIME Type	Support
JSON	`application/fhir+json`	✅ Primary
NDJSON	`application/fhir+ndjson`	✅ Bulk operations

:::note JSON Only Ignixa supports JSON format only. XML is not supported. :::

HTTP Headers

Request Headers

Prefer (RFC 7240)

Controls response behavior and validation level:

# Return full resource in response
Prefer: return=representation

# Return minimal response (headers only)
Prefer: return=minimal

# Return OperationOutcome
Prefer: return=OperationOutcome

# Control validation level (used with $validate operations)
Prefer: mode=minimal   # Structure only (fastest)
Prefer: mode=spec      # FHIR specification compliance (default)
Prefer: mode=full      # Full profile validation with terminology

# Combine preferences
Prefer: return=representation, mode=spec

Preference	Values	Description
`return`	`representation`, `minimal`, `OperationOutcome`	Response body content
`mode`	`minimal`, `spec`, `full`	Validation depth (for $validate operations)

X-Provenance

Submit provenance alongside create/update operations:

POST /Patient
Content-Type: application/fhir+json
X-Provenance: {"resourceType":"Provenance","recorded":"2024-01-15T10:30:00Z","agent":[{"who":{"reference":"Practitioner/123"}}]}

{ "resourceType": "Patient", ... }

The X-Provenance header:

MUST contain a valid Provenance resource
MUST NOT include target (server auto-fills with created resource)
Maximum size: 16KB

Conditional Headers

Header	Purpose	Example
`If-Match`	Optimistic concurrency	`If-Match: W/"5"`
`If-None-Match`	Conditional read (304)	`If-None-Match: W/"3"`
`If-Modified-Since`	Date-based conditional	`If-Modified-Since: Wed, 17 Oct 2025 14:30:00 GMT`
`If-None-Exist`	Conditional create	`If-None-Exist: identifier=12345`

Content Negotiation

Header	Supported Values
`Accept`	`application/fhir+json`, `application/json`, `/`
`Content-Type`	`application/fhir+json`, `application/json`

Response Headers

Header	Description	Example
`ETag`	Weak ETag for versioning	`W/"5"`
`Last-Modified`	Resource modification time	`Wed, 17 Oct 2025 14:30:00 GMT`
`Location`	Created/updated resource URL	`/Patient/123/_history/1`
`Preference-Applied`	Preferences honored	`return=representation, validation=spec`

Query Parameters

_pretty

Pretty-print JSON output for debugging:

GET /Patient/123?_pretty=true

# Presence implies true
GET /Patient/123?_pretty

_format

Specify response format (JSON only supported):

GET /Patient/123?_format=json
GET /Patient/123?_format=application/fhir+json

Server Information​

Supported Interactions​

Instance Level​

Type Level​

System Level​

REST Capabilities​

Package-Defined Resource Types​

Operations​

Versioning​

Version-Aware Updates​

Conditional Operations​

Conditional Create​

Conditional Update​

Conditional Delete​

Formats​

HTTP Headers​

Request Headers​

Prefer (RFC 7240)​

X-Provenance​

Conditional Headers​

Content Negotiation​

Response Headers​

Query Parameters​

_pretty​

_format​

Related Documentation​