WofPortalIG, published by Service Well AB. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/servicewell/servicewell.fhir.wof-portal/ and changes regularly. See the Directory of published versions

• Narrative Content
• XML
• JSON
• TTL

CapabilityStatement: WOF Portal Capability Statement

Official URL: https://canonical.fhir.link/servicewell/wof-portal/CapabilityStatement/WOFPortalCapabilityStatement				Version: 0.1.0
Active as of 2026-02-02				Computable Name: WOFPortalCapabilityStatement

This CapabilityStatement defines the canonical domain model and API principles of the WOF Portal

This CapabilityStatement defines the canonical domain model and API principles of the WOF Portal, owned and operated by Service Well.

IHE Scheduling: This server instantiates IHE.Scheduling.server (v1.0.0).

Layering principle

• WOF Connect defines vendor-facing interoperability contracts.
• WOF Portal builds on WOF Connect to provide a single, enriched, canonical API.

Domain separation principles

• ActivityDefinition represents a shared service concept and SHALL be identified by code, not by resource id.
• HealthcareService represents where care is performed.
• BillingOrganization represents financial responsibility and is independent of service location.
• PractitionerRole represents a practitioner acting in a specific operational and financial context.

Many-to-many relationships are intentional

• A HealthcareService MAY be associated with multiple BillingOrganizations.
• A BillingOrganization MAY provide services at multiple HealthcareServices.
• A Practitioner MAY have multiple PractitionerRoles across services and billing contexts.

Offer and availability principles

• Offer represents a computed, context-specific view combining ActivityDefinition, HealthcareService, and PractitionerRole.
• Offer is intended for presentation and selection, not for scheduling.
• Schedule represents planned working time and SHALL NOT be treated as bookable availability.
• Actual bookability requires downstream slot or availability checks.

Integration principle

• External systems integrate with the platform by implementing WOF Connect.
• WOF Portal APIs MAY return enriched and aggregated views not available in WOF Connect.

This CapabilityStatement documents the canonical behavior of the WOF Portal API.

Client interaction overview

The following diagram illustrates outbound API calls from a patient-facing client to the WOF Portal Proxy. It represents actual usage patterns and supported interactions.

Client → WOF-PORTAL:

sequenceDiagram
    participant Client as Patient Client
    participant Portal as WOF Portal Proxy
    participant Endpoint as Tenant Endpoint

    %% Organization (ServiceProvider / Care context)
    Client ->> Portal: GET portal/fhir/Organization
    Client ->> Portal: GET portal/fhir/Organization/{id}?_summary={true|false}
    Client ->> Portal: GET portal/fhir/Organization?identifier={tenantIdentifier}&_summary={true|false}

    %% Patient (endpoint-scoped)
    Client ->> Endpoint: GET {endpointId}/fhir/Patient

    %% Appointment (portal + endpoint)
    Client ->> Portal: GET portal/fhir/Appointment
    Client ->> Endpoint: GET {endpointId}/fhir/Appointment/{id}
    Client ->> Endpoint: GET {endpointId}/fhir/Appointment?actor=HealthcareService/{healthcareServiceId}

    %% IHE Scheduling
    Client ->> Endpoint: GET {endpointId}/fhir/Appointment/$find
    Client ->> Endpoint: POST {endpointId}/fhir/Appointment/$book

    %% HealthcareService (portal-scoped)
    Client ->> Portal: GET portal/fhir/HealthcareService
    Client ->> Portal: GET portal/fhir/HealthcareService/{id}

    %% Location (Areas)
    Client ->> Portal: GET portal/fhir/Location?physicalType={AreaLiteral}

    %% PractitionerRole (portal-scoped)
    Client ->> Portal: GET portal/fhir/PractitionerRole
    Client ->> Portal: GET portal/fhir/PractitionerRole?service=HealthcareService/{healthcareServiceId}
    Client ->> Portal: GET portal/fhir/PractitionerRole/{practitionerRoleId}

    %% ActivityDefinition (portal-scoped)
    Client ->> Portal: GET portal/fhir/ActivityDefinition
    Client ->> Portal: GET portal/fhir/ActivityDefinition/{id}

This diagram is informational and documents expected client usage. It does not expand or modify the formal FHIR conformance rules.

Raw OpenAPI-Swagger Definition file | Download