Developer Guide
This guide gives a brief overview of the core Koppeltaal 2.0 concepts and how to integrate with its services
Last updated
This guide gives a brief overview of the core Koppeltaal 2.0 concepts and how to integrate with its services
Last updated
This document is released under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
This document is in draft.
By using the (FHIR) RESTful API exchange there is a single source of truth. Koppeltaal 1.x acted as a message broker, giving each participant the responsibility to keep all data up-to-date.
Another big advantage is that Koppeltaal 2.0 works with small messages. So no self-contained bundles. This saves a lot of data being transferred over the line and the chance of 409 Conflicts are considerably reduced.
Previously, a separate service could be used to check whether the content of a Bundle is valid. However, this validation was not enforced by the Koppeltaal server.
Koppeltaal 2.0 uses profiles. A profile indicates exactly what the rules are per Resource. The Koppeltaal server can enforce profiles by validating that the Resources adhere to the profile.
Applications connect to the Koppeltaal server. Within "Domeinbeheer" (Domain Management), roles are assigned to the applications. A role can contain multiple CRUD permissions per Resource. With Koppeltaal 2.0, you are only allowed to work with resources to which you are entitled. With Koppeltaal 1.x, applications can see everything that they are subscribed to within a Domain.
Note: Resources are managed at application level Koppeltaal 2.0.
The golden rule is that the application itself determines which resources are accessible at user level within the application.
Concept
KT 1.3.x
KT 2.0
FHIR Exchange
Messaging
RESTful API
Content Validation
Separate service
Built-in
Authorisation
None - application has access to everything
On resource & CRUD-level
