Search correlationId for tracking audit events

Find the participant of an ActivityDefinition

Search by publisherId for an ActivityDefinition

Search requestId for tracking audit events

Search domain resources by resource-origin.

Search Tasks based on a (set of) ActivityDefinition which in turn can conform to a specific PublisherId

Search trace id for tracking audit events

The (FHIR) ActivityDefinition (resource) describes an eHealth activity that is available for assignment to a patient. When assigning an eHealth activity to a patient, an eHealth Task is created, in which sub-activities are included as contained resources that refer to the main task via Task.partOf.

The AuditEvent resource is used to consolidate and track logging information within the Koppeltaal ecosystem. It captures details about system activities, data access, and interactions between applications for security and compliance purposes.

The CareTeam resource represents a group of healthcare professionals and related persons who collaborate to provide coordinated care and treatment for a patient. It defines the roles and participants involved in delivering healthcare services within the Koppeltaal ecosystem.

The KT2_DeletePendingTask profile represents the announcement that a patient's data within the Koppeltaal service is scheduled for definitive deletion. When the grace period starts, the Koppeltaal service creates one Task per (Patient ?? participating application); the Task is server-owned but readable by participating applications and carries the server-owned kt2-delete-flow security label (meta.security). The target application responds through the native Task lifecycle: on-hold as a temporary emergency brake and accepted as green light. The Task resides in the Patient compartment and is removed together with the Patient. See the page Opschoning Patient-data.

The Device resource represents a software application or system that is used in the provision of healthcare services. Within the Koppeltaal context, this typically includes modules, portals, or eHealth applications that facilitate patient care and data exchange between healthcare systems.

The Endpoint resource represents the technical contact point for an application that provides eHealth services. It defines the network address, connection protocols, and communication parameters necessary for systems to connect and interact with healthcare applications within the Koppeltaal ecosystem.

The Organization resource represents a formally or informally recognized grouping of people or organizations that collectively provide healthcare services. This includes healthcare providers, departments, community groups, and healthcare practice groups operating within the Koppeltaal ecosystem. The profile extends the NlcoreHealthcareProviderOrganization profile with Koppeltaal-specific requirements.

The Patient resource represents a person receiving healthcare services within the Koppeltaal ecosystem. Patients can be assigned eHealth activities and are the primary focus of care coordination between different healthcare applications. This profile extends the NlcorePatient profile with Koppeltaal-specific requirements.

The Practitioner resource represents a healthcare professional who is directly or indirectly involved in the provision of patient care. This includes physicians, nurses, therapists, and other healthcare providers operating within the Koppeltaal ecosystem. The profile extends the NlcoreHealthProfessionalPractitioner profile, implementing Dutch Health Information Building Block (zib) standards.

The RelatedPerson resource represents an individual who has a personal or professional relationship with a patient and may be involved in their care. This includes family members, caregivers, legal guardians, and other support persons who assist in the patient's therapy and treatment. The profile extends the NlcoreContactPerson profile with Koppeltaal-specific requirements.

The Subscription resource defines push-based notifications between systems in the Koppeltaal ecosystem. It enables applications to receive real-time updates when resources matching specified criteria are created or modified. The subscription mechanism ensures timely data synchronization and event-driven communication between healthcare applications.

The Task resource represents an eHealth activity that has been assigned to a specific patient. It tracks the lifecycle of patient assignments, from initial creation through completion, and may include subtasks for complex multi-step interventions. Tasks are created based on ActivityDefinition resources and managed throughout their execution within the Koppeltaal ecosystem.

The correlation-id is an identifier related to the message and the workflow it's part of

Reference extension to the service application (endpoint) that provides the eHealth activity.

Extension added to a Task to refer to the ActivityDefinition which is instantiated by this Task

Identifier of the publisher (organization or individual). This extension is used as id in the ActivityDefinition.

ID of the request. Together with the trace-id it uniquely identifies a request in logging

Defines the author of the resource

The ID of the workflow. The traceId is intended to track a log entry across multiple logs.

Endpoint connection type ValueSet

High-level categorization of the definition, used for indicating special patient initialised activities

ValueSet for Task.statusReason on the KT2_DeletePendingTask (the emergency-brake reason)

ValueSet for Task.status on the KT2_DeletePendingTask. The deletion announcement only moves through these five of the twelve R4 task statuses; the Koppeltaal service validates every transition between them.

Optional expansions for Koppeltaal activities

ValueSet voor Practitioner rollen binnen een CareTeam.

Breidt de ZorgverlenerRolCodelijst uit met SNOMED CT codes voor Koppeltaal autorisatierollen. Zie Practitioner autorisaties.

De SNOMED codes zijn gereviewd door Nictiz.

ValueSet voor RelatedPerson relaties binnen een CareTeam.

Bevat SNOMED CT codes die de autorisaties bepalen voor naasten van de pati??nt. Zie RelatedPerson autorisaties.

De SNOMED codes zijn gereviewd door Nictiz.

ValueSet for Task.code

Usage context type values for Koppeltaal ActivityDefinitions - uses standard FHIR usage context types

ValueSet defining the allowed eventtypes for Koppeltaal

COD472-VEKT Soort relatie cli??nt — uitsluitend bedoeld voor testdoeleinden!!! Dit is geen volledige lijst noch een door Vektis goedgekeurd uittreksel. Deze lijst is uitsluitend bedoeld voor testen binnen Koppeltaal.

High-level categorization of the definition, used for indicating special patient initialised activities

Reasons a target application can give when it pauses the deletion of patient data by setting its KT2_DeletePendingTask to on-hold (Task.statusReason). The list is deliberately closed: the delete-pending Task is readable domain-wide, so the reason must not convey demographics. Task.statusReason.text is closed off to keep the reason from becoming a free-text field.

Type of endpoint connection as used in Koppeltaal

Optional expansions for Koppeltaal activities

Server-owned security labels (meta.security) specific to Koppeltaal. Only the Koppeltaal service assigns these labels; labels supplied by client applications are rejected. The Koppeltaal service interprets them as access-policy markers on top of the TOP-KT-005 authorization matrix.

Type of Task.code specifically used in Koppeltaal

Usage context type codes for Koppeltaal ActivityDefinitions, extending standard FHIR usage context types

Identifier system of the Devices as used within Koppeltaal

Example of an ActivityDefinition using standard FHIR useContext values (age and gender)

Example of an ActivityDefinition that defines the use of a journal

Vragenlijst ROM

Example of an ActivityDefinition that defines a questionnaire

Auditevent with OperationOutcome

Example of an AuditEvent with an OperationOutcome indicating an error in the update

Example of an Application User Authentication AuditEvent: the application authenticates the user outside the Koppeltaal authentication chain (subtype DCM#110126 Node Authentication), created by the application itself

Example of an AuditEvent about creating a Patient

Example of an AuditEvent about deleting a patient

Auditevent with error about invalid subscription

Example of AuditEvent on application launch

Example of AuditEvent on user authentication

Example of a User Authentication AuditEvent for a launch via SMART App Launch: the /authorize call (outcomeDesc prefix 'authorize')

Example of a User Authentication AuditEvent for the optional step from /authorize where the user is redirected to the external IdP (outcomeDesc prefix 'idp call')

Example of a User Authentication AuditEvent for the redirect back from the external IdP with the IdP decision: outcome 0 for success, outcome 8 for a denied login (outcomeDesc prefix 'idp login')

Example of a User Authentication AuditEvent for a launch via HTI: introspection of the HTI launch token (outcomeDesc prefix 'introspect')

Example of an aggregated deletion lifecycle AuditEvent: the Koppeltaal service announces the deletion by creating the delete-pending Task(s); the grace period starts (ISO 21089 type 'archive', action C)

Example of an aggregated deletion lifecycle AuditEvent: the definitive deletion has been executed (ISO 21089 type 'destroy', action D). This event survives the erase, contains no PII ??? only the technical Patient reference ??? and carries the post-delete signal to which applications can subscribe

Example of an aggregated deletion lifecycle AuditEvent: a hold was still present when the grace deadline passed, so the Koppeltaal service clears all holds and restarts the grace period with a new deadline (ISO 21089 type 'archive', action U ??? action C marks the initial announcement)

Example of an aggregated deletion lifecycle AuditEvent: the first application pulls the emergency brake (its Task goes to 'on-hold'), so the aggregated process state becomes blocked (ISO 21089 type 'hold', action U). A second hold does not produce another event. The per-application reason lives on the Task ('Task.statusReason'), not in this aggregated event

Example of an aggregated deletion lifecycle AuditEvent: the deletion is aborted because of renewed patient engagement; the delete-pending Task(s) go to 'cancelled' and the retention period restarts (ISO 21089 type 'reactivate', action U). This is the alternative ending of the process, instead of 'destroy'

Example of an aggregated deletion lifecycle AuditEvent: the last emergency brake is released while the process still continues to the grace deadline ??? not all Tasks are 'accepted' (ISO 21089 type 'unhold', action U). If that same release completes the process (all Tasks 'accepted'), a 'destroy' follows directly instead of an 'unhold'

Example of AuditEvent with create Operation resulting in outcome code 4

Example of Device indicating an authorisation server

Example of a Device

Example of CareTeam demonstrating all Koppeltaal Practitioner authorization roles

Example of CareTeam demonstrating all Koppeltaal RelatedPerson authorization roles

Example of CareTeam with a Practitioner in the 'behandelaar' authorization role

Example of CareTeam with multiple participants

Example of CareTeam with a RelatedPerson in the 'mantelzorger' authorization role

Example of bare minimum of CareTeam

Example of CareTeam that has a RelatedPerson as one of the participants

Example of CareTeam with a RelatedPerson as 'wettelijk vertegenwoordiger' (legal representative)

Example of a Device representing an external identity provider (IdP)

Example of a Device representing the Koppeltaal service (Koppeltaalvoorziening), producer of server-owned resources such as the deletion lifecycle AuditEvents

Example of a Device with all elements populated

Example of an Endpoint as used in Koppeltaal

Nictiz Example of RelatedPerson only to test validation

Example of an Organization department

Bare minimum definition of an Organization

Example of an Organization with a name and type

Bare minimum of Patient elements populated

Example of a Patient with a telephone number and managing organization

Example of Patient with resource origin extension populated

Example of Patient with full address

Example of Patient with full name and address

Example of Patient with full name and maiden name

Example of Patient with name and initials

Example of Practitioner

Example of Practitioner with all elements populated

The RelatedPerson is the contact person

RelatedPerson example

RelatedPerson multiple relationships

RelatedPerson with as much elements filled in as possible

Example of a RelatedPerson (neighbour) 2

RelatedPerson with multiple codes for relationship

Example of a RelatedPerson (neighbour)

Nictiz Example of RelatedPerson only to test validation

Example of a subscription

Example of a delete-pending Task announcing that a patient's data is scheduled for definitive deletion. The grace deadline (30 days after the announcement) is recorded in restriction.period.end and is managed by the server.

Example of a delete-pending Task on which the target application has pulled the emergency brake. The coded statusReason states why the deletion is paused; it comes from a closed list and text is closed off, so the reason itself is not a free-text field. The Koppeltaal service clears statusReason as soon as on-hold is left.

Example of a task in progress

Example of a sub task, part of another task

Task with view code set

Example of a Task

Example of an overarching task