ITB - Online appointment booking service, published by Service Well AB. This guide is not an authorized publication; it is the continuous build for version 1.0.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

CapabilityStatement: WOF Portal Capability Statement

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

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.
• 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.

Theres currently two domains for our dev-api:

- **api.wellonfhir.se/{{tenant}}/1.0/R4**      - Swedish developmnent environment
- **api-no.wellonfhir.se/{{tenant}}/1.0/R4**   - Norwegian development environment

tenant is a stable identifier for the organization

Both Requires authentication

Client → WOF-PORTAL:

%%{init: {'theme':'neutral','securityLevel':'loose','fontFamily':'Inter, Arial, sans-serif','sequence': {'diagramMarginX': 30, 'diagramMarginY': 20, 'actorMargin': 220, 'width': 180, 'messageMargin': 32, 'mirrorActors': false, 'wrap': true}}}%%sequenceDiagram
    participant Client as Scheduling Client
    participant Auth as Auth Endpoint
    participant Portal as WOF Portal API

    Note over Client,Portal: base = {{baseUrl}}/{{tenant}}/{{apiVersion}}/R4

    %% System token (from DemoOris.rest)
    Client ->> Auth: POST {{base}}/auth/system-token
    Note over Client,Auth: Header: X-ApiKey {{apiKey}}
    Auth -->> Client: access_token (system)

    %% HealthcareService
    Client ->> Portal: GET {{base}}/fhir/HealthcareService
    Client ->> Portal: GET {{base}}/fhir/HealthcareService/{{healthcareServiceId}}
    Client ->> Portal: GET {{base}}/fhir/HealthcareService/{{healthcareServiceId}}/$get-offers-context<br/>?includeActivityDefinitionPortal={{boolean}}<br/>&includePractitionerRolePortal={{boolean}}

    %% Root operation
    Client ->> Portal: GET {{base}}/fhir/$get-offers-context<br/>?includeActivityDefinitionPortal={{boolean}}<br/>&includeHealthcareServicePortal={{boolean}}<br/>&includePractitionerRolePortal={{boolean}}

    %% ActivityDefinition
    Client ->> Portal: GET {{base}}/fhir/ActivityDefinition
    Client ->> Portal: GET {{base}}/fhir/ActivityDefinition/{{activityDefinitionId}}
    Client ->> Portal: GET {{base}}/fhir/ActivityDefinition/{{activityDefinitionId}}/$get-offers-context<br/>?includeActivityDefinitionPortal={{boolean}}<br/>&includeHealthcareServicePortal={{boolean}}<br/>&includePractitionerRolePortal={{boolean}}
    Client ->> Portal: GET {{base}}/fhir/ActivityDefinition/{{activityDefinitionId}}/$get-offers-context

    %% PractitionerRole
    Client ->> Portal: GET {{base}}/fhir/PractitionerRole
    Client ->> Portal: GET {{base}}/fhir/PractitionerRole/{{practitionerRoleId}}
    Client ->> Portal: GET {{base}}/fhir/PractitionerRole/{{practitionerRoleId}}/$get-offers-context<br/>?includeActivityDefinitionPortal={{boolean}}<br/>&includeHealthcareServicePortal={{boolean}}<br/>&includePractitionerRolePortal={{boolean}}

    %% Catalog resources
    Client ->> Portal: GET {{base}}/fhir/Location
    Client ->> Portal: GET {{base}}/fhir/Organization

    %% IHE Scheduling find 
    Client ->> Portal: GET {{base}}/fhir/Appointment/$find<br/>?start={{find_start}}&end={{find_end}}<br/>&visit-type={{visitTypeSystem}}|{{visitTypeCode}}<br/>&healthcareService=HealthcareService/{{healthcareServiceId}}<br/>&practitionerRole=PractitionerRole/{{practitionerRoleId}}

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