Skip to main content
DELETE
Delete Resource
Marks a resource as deleted. Most servers use soft delete, preserving the resource in history.

Endpoint

string
required
The FHIR resource type (e.g., Patient, Observation, Encounter)
string
required
The logical ID of the resource to delete

Headers

string
Response style:
  • return=representation - Return OperationOutcome
  • return=minimal (default) - No response body
  • return=OperationOutcome - Return OperationOutcome

Query Parameters

string
For conditional delete. Delete the resource matching these search parameters.Example: ?identifier=http://hospital.example/mrn|12345

Response

204 No Content

Resource deleted successfully. No response body.

200 OK

Resource deleted successfully with OperationOutcome (when using Prefer: return=OperationOutcome).

404 Not Found

Resource doesn’t exist (some servers return 204 for idempotency).

409 Conflict

Resource cannot be deleted due to referential integrity or business rules.

412 Precondition Failed

Conditional delete matched multiple resources (ambiguous).

Examples

Delete Behavior

Soft Delete (Typical)

Most FHIR servers use soft delete:
  • Resource marked as deleted in database
  • History preserved and accessible
  • GET /Patient/123 returns 410 Gone
  • GET /Patient/123/_history/5 still works (returns version 5)

Hard Delete (Rare)

Complete removal from database:
  • Resource and all history permanently deleted
  • Cannot be recovered
  • Usually restricted by policy or disabled entirely
Check Server Behavior: Review the server’s CapabilityStatement or documentation to understand its delete behavior.

Idempotent Delete

DELETE is idempotent - deleting an already-deleted resource succeeds:

Conditional Delete

Delete by search criteria instead of ID:
Behavior:
  • 0 matches: No-op, returns 204 No Content
  • 1 match: Deletes that resource → 204 No Content
  • 2+ matches: Rejects as ambiguous → 412 Precondition Failed
Example: Delete patient by identifier

Accessing Deleted Resources

After soft delete, use history endpoints to access deleted resources:

Referential Integrity

Some servers check if other resources reference the resource being deleted: Protected Resources (common scenarios):
  • Patient referenced by Observations, Encounters
  • Practitioner referenced by many resources
  • Organization referenced by locations, departments
Server Behavior:
  • Allow deletion regardless (most permissive)
  • Return 409 Conflict if references exist (most cautious)
  • Cascade delete (rare - delete referencing resources too)

Common Use Cases

Delete Test Data

Soft Delete with Verification

Conditional Delete by Identifier

Delete with Audit Trail

Best Practices

Cannot Undo: Even with soft delete, most UIs don’t provide “undelete” functionality. Ensure deletion is intended before proceeding.
Check References First: Before deleting, search for resources that reference it to avoid breaking referential integrity:
If any exist, consider whether deletion is appropriate.
Empty Body: DELETE requests should have an empty body per FHIR specification. Don’t send a resource in the body.

See Also

Resource History

View deleted resource versions

Search

Find resources before deleting

Update Resource

Modify instead of deleting

Learn FHIR CRUD

Understand FHIR delete semantics

Authorizations

Authorization
string
header
required

Bearer token authentication

Path Parameters

resourceType
string
required

The FHIR resource type (e.g., Patient, Observation, Encounter)

id
string
required

The logical ID of the resource

Response

Resource deleted

A FHIR resource. All resources have resourceType, id, and meta fields.

resourceType
string
required

The type of resource

id
string

Logical id of this artifact

meta
object

Metadata about a resource