Koppeltaal 2.0 Dev Guide
  • Developer Guide
  • POC (Walking Skeleton)
    • Proof Of Concept
      • Koppeltaal Server
      • Domain Management
      • Auth Server
      • Koppeltaal IdP
      • Domain Access Test Suite
      • Koppeltaal Test Tooling
  • Domain access
    • Joining a domain
    • Role-based access control
      • Autorisation model
      • Creating a role
      • Search Narrowing
      • Revoke Permission
  • Technical HOW-TO
    • Koppeltaal Test Tooling
    • Request Koppeltaal server metadata
    • Connecting to Koppeltaal
      • Requirements
        • Create a key pair
        • Signing the JWT
        • JWKS setup
      • Access to Koppeltaal
    • Managing resources
      • Versioning
      • CRUD Operations
        • Retrieve all Resources
        • Retrieve specific Resource
        • Create a Resource
        • Update a Resource
        • Delete a Resource
      • Subscribing to changes
    • Launching
      • HTI Flow
      • SHOF Flow
      • Compose a launch
      • Initiating a launch
      • Receiving a HTI launch
        • Token introspection
      • Receiving a SHOF launch
    • Detailed technical guidance
  • Hackathon Use Cases
    • Requirements
      • Install and configure Yivi
    • Use-Cases
      • Use-Case 1: Create a Task
        • Create an ActivityDefinition
      • Use-Case 2: HTI Launch
      • Use-case 3: SHOF Launch
      • Use-case 4: Subscribing to changes
  • Useful Links
    • Simplifier Profiles
    • FHIR Docs
    • HTI documentation
    • GitHub
    • Koppeltaal 2.0 Specifications & Architecture
    • Koppeltaal 2.0 Implementation Guide
    • Koppeltaal 2.0 OpenAPI Specs
Powered by GitBook
On this page
  • Concurrency
  • Update a complete resource
  • Delen van een Resource Updaten
  • Patch a Resource
  • Topics

Was this helpful?

  1. Technical HOW-TO
  2. Managing resources
  3. CRUD Operations

Update a Resource

PreviousCreate a ResourceNextDelete a Resource

Last updated 8 months ago

Was this helpful?

See the for more information.

Concurrency

To avoid overwriting data, an application must always indicate which version of a Resource the update is based on. This is done using the If-Match header. If this header is missing, the Koppeltaal server will reject the request. If the update is not based on the latest version, the server will respond with a 409 Conflict or a 412 Precondition Failed.

The If-Match value must match the latest ETag value. The ETag value is provided via a response header sent by the Koppeltaal server after a , or .

Update a complete resource

PUT https://fhir-server.koppeltaal.headease.nl/fhir/DEFAULT/<Resource>/<:id>

Note: the

id

property has to be set in the body as well

Path Parameters

Name
Type
Description

id*

string

The "logical id" of the

Resource

Headers

Name
Type
Description

If-Match*

string

A

to the version the update is based on, e.g: W/"3"

Authorization*

string

Bearer token obtained from the Auth Server

Request Body

Name
Type
Description

*

string

The

Resource

Resource is modified. The resource with resource-origin extension and logical id is returned

The resource cannot be parsed or does not conform to the basic FHIR validation rules

Unauthenticated

Unauthorized

Resource type not supported, or not a FHIR end-point

The Resource did not exist prior to the update, and the server does not allow client defined ids

Version conflict, update is based on an old version

Precondition Failed Version conflict, update is based on an old version

Does not meet FHIR profiles or Koppeltaal business rules

Delen van een Resource Updaten

To update a Resource via a small payload, the Koppeltaal server may support PATCH requests. The payload of the PATCH must be one of the following:

This is what the payload looks like from a JSON Patch to update the status of a Task

[{
    "op": "replace",
    "path": "/status",
    "value": "completed"
}]

Patch a Resource

PATCH https://hapi-fhir-server.koppeltaal.headease.nl/fhir/<Resource>/<:id>

As an alternative to updating an entire resource, clients can perform a patch operation. This can be useful when a client is seeking to minimize its bandwidth utilization.

Path Parameters

Name
Type
Description

*

String

The "logical id" of the

Resource

Headers

Name
Type
Description

If-Match*

string

A

to the version the update is based on, e.g: W/"3"

Authorization*

string

Bearer token obtained from the Auth Server

Request Body

Name
Type
Description

*

object

The Patch

Patch is applied. The complete Resource will be returned

Unauthenticated

Unauthorized

Not Found Resource type not supported, or not a FHIR end-point
Method Not Allowed 
Precondition Failed Version conflict, update is based on an old version

Topics

(see )

PATCH requests are optional. See the to find out if the server supports this.

A (Content-Type application/json-patch+json).

An (Content-Type application/xml-patch+xml)

A parameters Resource (Content-Type ).

More examples of patches can be downloaded .

(see )

JSON Patch
XML Patch
FHIRPath Patch
FHIR Content Type
here
TOP-KT-002a - FHIR Resource Service interacties
TOP-KT-005a - Rollen en rechten voor applicatie-instanties
TOP-KT-009 - Overzicht gebruikte FHIR Resources
"weak" ETag
Connecting to Koppeltaal
"weak" ETag
Connecting to Koppeltaal
FHIR documentation
Create
Update
Conformance
Get