CapabilityStatement for authenticated client access to the OZO FHIR API. Covers Practitioner, RelatedPerson, and Patient roles. All three roles have the same resource types and interactions available ??? the AAA proxy scopes access differently per role by automatically applying search filters based on the caller's credentials. See the CapabilityStatements documentation page for per-role filtering details.

Base CapabilityStatement for the OZO FHIR API. Returned by the unauthenticated /metadata endpoint. Describes server identity, security requirements, and supported profiles. Authenticate to receive a role-specific CapabilityStatement with detailed interactions.

CapabilityStatement for OZO system-level access (server-to-server). Full CRUD access to all resources without access filters. Requires OzoSystemCredential via the Nuts protocol.

Search parameter over the thread parties of a CommunicationRequest: the addressed parties in recipient and the initiating team in extension[senderCareTeam]. Used by the AAA proxy to scope access to threads and, through part-of:CommunicationRequest.participant, to messages.

Search parameter on CommunicationRequest.extension[senderCareTeam]: find the threads initiated by a given CareTeam.

AuditEvent profile for OZO AAA Proxy to comply with NEN7510 standards

CareTeam profile for patient care networks in OZO. Represents a care network of healthcare professionals and informal caregivers coordinating care for a specific patient. For organizational teams (departments, shared inboxes), use OZOOrganizationalCareTeam instead.

Communication profile for the OZO platform. Represents messages exchanged within the care network, linking to threads via CommunicationRequest.

CommunicationRequest profile for the OZO platform. Represents a message thread or conversation within the care network. Individual messages are Communication resources that reference this thread via partOf.

Device profile for the OZO platform. Represents system components such as the AAA proxy that appear as source observers in AuditEvents.

Organization profile for the OZO platform. Represents healthcare organizations (hospitals, pharmacies, general practices) that employ practitioners in the care network.

CareTeam profile for organizational teams in OZO. Represents a department or organizational unit (e.g., pharmacy team, clinic team) used for team-to-team messaging via shared inbox. Not bound to a specific patient.

Patient profile for the OZO platform. Represents the client/patient who is the subject of care coordination between healthcare professionals and informal caregivers.

Practitioner profile for the OZO platform. Represents healthcare professionals who are part of the patient's care team.

RelatedPerson profile for the OZO platform. Represents informal caregivers (family members, friends) who are part of the patient's care network.

Task profile for the OZO platform. Represents work assignments, referrals, or action items within the care network. Tasks can be linked to message threads via basedOn.

The organizational CareTeam on whose behalf an AuditEvent agent acted. Used on read receipts in team threads: it names the team whose Task the OZO FHIR Api completes, instead of inferring the team from the agent's memberships. FHIR R4 AuditEvent.agent.who does not allow CareTeam references (R5 does), and entity describes what was accessed rather than who acted, so the team is carried as an extension on agent.

Device that originally created the resource

Extension to name the organizational CareTeam on whose behalf a thread is started (CommunicationRequest) or a message is sent (Communication). FHIR R4 CommunicationRequest.sender and Communication.sender do not allow CareTeam references, and the OZO model keeps sender an individual for auditability; this extension carries the team.

W3C Trace Context span-id for distributed tracing

W3C Trace Context trace-id for distributed tracing

Types of agents in OZO audit events

Types of entities in OZO audit events

Types of sources in OZO audit events

Subtypes of audit events for OZO

Types of audit events for OZO

Example of an AuditEvent for a successful REST create operation through OZO AAA Proxy

Example of an AuditEvent for a REST search operation through OZO AAA Proxy

Example of an AuditEvent for a failed REST update operation through OZO AAA Proxy

Read receipt in a team thread. Practitioner Manu van Weel opens the Pharmacy-to-Clinic thread in the OZO platform. agent.who is the individual who read (NEN7510 attribution); agent.extension[careTeam] names the organizational team on whose behalf the message was read, Clinic B. The OZO FHIR Api completes the Task owned by Clinic B. The thread has no Communication yet (the initial message is the CommunicationRequest payload), so the receipt carries the CommunicationRequest entity only.

Read receipt in a team thread. Practitioner Pieter de Vries reads the clinic's reply in the Pharmacy-to-Clinic thread. agent.who is the individual who read; agent.extension[careTeam] names Pharmacy A, the team on whose behalf the message was read. The receipt carries two entity entries: the CommunicationRequest (required, the OZO FHIR Api finds the team Task through it) and the Communication that was viewed (optional but recommended; the Task is only completed when this is the newest message in the thread). The OZO FHIR Api completes the Task owned by Pharmacy A.

Example of an AuditEvent for a system-to-system access through OZO AAA Proxy

Example of a clinic team used for team-level messaging. This CareTeam represents the clinic as a whole for shared inbox functionality.

Example of a pharmacy team used for team-level messaging. This CareTeam represents the pharmacy as a whole for shared inbox functionality.

Device representing the OZO AAA Proxy instance. Referenced by AuditEvent.source.observer via logical identifier.

Practitioner Manu van Weel replies to Kees Groot's initial message in the Thread-Example thread.

Subscription for detecting new Communication messages. This is the primary mechanism for new-message notification. Uses the notify-then-pull pattern: the notification payload is empty, and the subscriber must fetch the Communication resource separately. This is required in the Netherlands where healthcare data must not be pushed in notifications.

Subscription for detecting new threads and thread status changes. Fires when a CommunicationRequest is created or its status changes (e.g. DRAFT to ACTIVE). Uses the notify-then-pull pattern: the notification payload is empty, and the subscriber must fetch the CommunicationRequest resource separately.

Subscription for tracking unread message status via Task resources. Fires when a Task status changes to 'requested' (unread). Not suitable for new-message detection ??? use the Communication subscription for that. The AAA proxy automatically scopes this subscription to the current user's ownership. Uses the notify-then-pull pattern: the notification payload is empty.

Task holding the read state of the organizational team Clinic B in the Pharmacy-to-Clinic thread. The OZO FHIR Api creates one Task per organizational team that is a party of a team thread, with owner set to the CareTeam. Status is 'requested' (unread for the team) when the thread is created by the other team. It changes to 'completed' when a member of Clinic B sends a read receipt or a reply that names Clinic B in the agent or sender extension. Every member of Clinic B sees this Task; a member of two teams in the same thread sees two Tasks.

Task holding the read state of the organizational team Pharmacy A in the Pharmacy-to-Clinic thread. Pharmacy A is the initiating team (extension[senderCareTeam] of the CommunicationRequest), so its Task starts 'completed': the requester wrote the message and the team has nothing unread. It changes to 'requested' with focus set to the new Communication when the clinic team replies.

Task tracking unread message status for RelatedPerson Kees Groot in the Thread-Example thread. Status is 'requested' (unread) when created by the OZO FHIR Api after a new message arrives. Changes to 'completed' when the message is read (via AuditEvent).

Task tracking unread message status for Practitioner Manu van Weel in the Thread-Example thread. Status is 'requested' (unread) when created by the OZO FHIR Api after a new message arrives. Changes to 'completed' when the message is read.

Task tracking unread message status for Practitioner Mark Benson in the Thread-Example thread. Status is 'requested' (unread) when created by the OZO FHIR Api after a new message arrives. Changes to 'completed' when the message is read.

First reply in the team thread. A practitioner from the clinic responds to the pharmacy's CommunicationRequest. The sender is the individual (for auditability); extension[senderCareTeam] names the clinic team on whose behalf the reply is sent, so the OZO FHIR Api completes the clinic team's Task and sets the pharmacy team's Task to requested. Thread parties are defined on the CommunicationRequest.

Follow-up from a different practitioner at the pharmacy. This demonstrates that multiple team members can participate in the same thread. The sender is a different practitioner from the original requester; extension[senderCareTeam] names the pharmacy team, the same team as in the CommunicationRequest.

Example of a team-to-team CommunicationRequest where a pharmacy sends a message to a clinic. The senderCareTeam extension names the pharmacy team as the initiating team (reply-to address); recipient lists the addressed clinic team only. Both teams are thread parties: the participant search parameter matches either element, so the thread is in the access scope of both teams. The requester is the individual practitioner who initiated the thread for auditability.