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.

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.

Device that originally created the resource

Extension to specify a CareTeam as the sender/reply-to address for team-level messaging. This extension is needed because CommunicationRequest.sender does not allow CareTeam references in FHIR R4.

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 Practitioner accessing Communication resources

Example of an AuditEvent for Practitioner Mark Benson accessing Communication resources

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

Example of an AuditEvent for RelatedPerson accessing Communication resources

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 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). Thread participants are defined on CommunicationRequest.recipient.

Follow-up from a different practitioner at the pharmacy. This demonstrates that multiple team members can participate in the same thread. Note that the sender is a different practitioner from the original requester.

Example of a team-to-team CommunicationRequest where a pharmacy sends a message to a clinic. The senderCareTeam extension specifies the pharmacy team as the reply-to address for team-level authorization. The requester is the individual practitioner who initiated the thread for auditability.