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

<p><b>IHE Scheduling:</b> This server instantiates IHE.Scheduling.server (v1.0.0).</p>

<p><b>Layering principle:</b></p> <ul> <li><b>WOF Connect</b> defines vendor-facing interoperability contracts.</li> <li><b>WOF Portal</b> builds on WOF Connect to provide a single, enriched, canonical API.</li> </ul>

<p><b>Domain separation principles:</b></p> <ul> <li><b>ActivityDefinition</b> represents a shared service concept and SHALL be identified by code, not by resource id.</li> <li><b>HealthcareService</b> represents where care is performed.</li> <li><b>BillingOrganization</b> represents financial responsibility and is independent of service location.</li> <li><b>PractitionerRole</b> represents a practitioner acting in a specific operational and financial context.</li> </ul>

<p><b>Many-to-many relationships are intentional:</b></p> <ul> <li>A HealthcareService MAY be associated with multiple BillingOrganizations.</li> <li>A BillingOrganization MAY provide services at multiple HealthcareServices.</li> <li>A Practitioner MAY have multiple PractitionerRoles across services and billing contexts.</li> </ul>

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

<p><b>Integration principle:</b></p> <ul> <li>External systems integrate with the platform by implementing <b>WOF Connect</b>.</li> <li>WOF Portal APIs MAY return enriched and aggregated views not available in WOF Connect.</li> </ul>

<p>This CapabilityStatement documents the canonical behavior of the WOF Portal API.</p>

<p><b>Client interaction overview:</b></p>

<p>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.</p>

<pre> WOF.Portal.Patient.Client.Frenda - Outbound API calls (Razor components → services)

Client → Proxy:

• GET portal/fhir/Organization

• GET portal/fhir/Organization/{id}?_summary={true

  false}

• GET portal/fhir/Organization?identifier={tenantIdentifier}&_summary={true

  false}

• GET {endpointId}/fhir/Patient

• GET portal/fhir/Appointment
• GET {endpointId}/fhir/Appointment/{id}

• GET {endpointId}/fhir/Appointment?actor=HealthcareService/{healthcareServiceId}

• GET {endpointId}/fhir/Appointment/$find

• POST {endpointId}/fhir/Appointment/$book

• GET portal/fhir/HealthcareService

• GET portal/fhir/HealthcareService/{id}

• GET portal/fhir/Location?physicalType={AreaLiteral}

• GET portal/fhir/PractitionerRole
• GET portal/fhir/PractitionerRole?service=HealthcareService/{healthcareServiceId}

• GET portal/fhir/PractitionerRole/{practitionerRoleId}

• GET portal/fhir/ActivityDefinition
• GET portal/fhir/ActivityDefinition/{id} </pre>

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

Read-oriented operation returning an enriched, profiled Bundle for fast content rendering. It may include ActivityDefinitionPortal, HealthcareServicePortal, PractitionerRolePortal and OfferPortal. It MUST NOT include Schedule, Slot, or bookable time slots.

<p><b>ActivityDefinition</b> represents what can be offered and booked as a service.</p>

<p>It answers the question: <i>“What service is the patient booking?”</i></p>

<ul> <li>Defines the <b>type of service</b> (e.g., examination, consultation, treatment).</li> <li>Contains a <b>booking activity code</b> that uniquely identifies the service concept.</li> <li>Provides stable metadata such as title and description for presentation and search.</li> </ul>

<p><b>Booking and interoperability principle:</b></p>

<ul> <li>Booking is performed using the <b>activity code</b>, not the resource id.</li> <li>This follows the approach used in IHE Scheduling profiles.</li> <li>The code represents a <b>shared service concept</b> that can be reused across installations and systems.</li> </ul>

<p><b>Important:</b> The resource <code>id</code> is a technical identifier local to a FHIR server. It MUST NOT be used as a booking key.</p>

<p>ActivityDefinitionPortal describes the service concept only. It does <b>not</b> define:</p> <ul> <li>which locations offer the service</li> <li>which practitioners perform it</li> <li>context-specific price or duration</li> <li>availability, schedules, or bookable time slots</li> </ul>

<p>Those context-specific details are provided through <b>Offer</b> and related context resources.</p>

<p><b>Current name in Backoffice:</b> Service</p>

<p><b>BillingOrganization</b> represents the entity that is financially responsible for healthcare services.</p>

<p>It answers the question: <i>“Who owns invoicing, customer accounts, and statutory reporting for a performed service?”</i></p>

<ul> <li>Owns the invoice number series used for billing.</li> <li>Owns the customer accounts (accounts receivable).</li> <li>Is responsible for statutory and reimbursement reporting to external authorities.</li> <li>Receives payment for performed services.</li> </ul>

<p>A BillingOrganization is <b>independent of service location</b>:</p>

<ul> <li>A BillingOrganization may offer its services at <b>multiple HealthcareServices</b>.</li> <li>A HealthcareService may be associated with <b>multiple BillingOrganizations</b>.</li> </ul>

<p>This supports scenarios where:</p> <ul> <li>Multiple practitioners with separate financial responsibility work at the same service location.</li> <li>A single practitioner or billing entity provides services at several locations.</li> </ul>

<p><b>Important:</b> BillingOrganization represents financial responsibility only. It does <b>not</b> describe where care is performed.</p>

<p><b>Current name in Backoffice:</b> OpusEconomy</p>

Response Bundle for $getOffersContext. Contains a subset of ActivityDefinitionPortal, HealthcareServicePortal, PractitionerRolePortal and OfferPortal. Intended for fast content rendering. Does not include scheduling or bookable time slots (no Schedule, no Slot).

<p><b>HealthcareServicePortal</b> represents the place and operational context where care is performed.</p>

<p>It answers the question: <i>“Where can the patient receive a service?”</i></p>

<ul> <li>Describes a service location or service unit (e.g., clinic, department, unit).</li> <li>Used to present booking options such as location/service, contact information, and where the service is delivered.</li> <li>Can be shared by multiple practitioners and roles.</li> <li>Does <b>not</b> represent financial ownership, invoicing responsibility, or statutory reporting responsibility.</li> </ul>

<p><b>Important:</b> HealthcareService is an operational concept. Financial and invoicing responsibility is modeled separately.</p>

<p><b>Current name in Backoffice:</b> Clinic</p>

An example profile of the Patient resource.

<p><b>OfferPortal</b> represents a bookable offering in a specific context.</p>

<p>It answers the question: <i>“Which service can be booked, by whom, and where — and what are the booking-facing settings in that context?”</i></p>

<ul> <li>Connects an <b>ActivityDefinitionPortal</b> (what) with a <b>HealthcareServicePortal</b> (where) and a <b>PractitionerRolePortal</b> (who).</li> <li>Represents the <b>context-specific</b> configuration for booking content.</li> <li>Is intended as a lightweight object for frontends to render booking options quickly.</li> </ul>

<p>An OfferPortal contains references to:</p> <ul> <li><b>activityDefinition</b> — Reference(ActivityDefinitionPortal)</li> <li><b>healthcareService</b> — Reference(HealthcareServicePortal)</li> <li><b>practitionerRole</b> — Reference(PractitionerRolePortal)</li> </ul>

<p>OfferPortal may include booking-facing settings such as:</p> <ul> <li><b>duration</b> — free-text (presentation value)</li> <li><b>price</b> — free-text (presentation value)</li> <li><b>bookingUrl</b> — deeplink for booking</li> </ul>

<p><b>Important:</b> OfferPortal does <b>not</b> represent real-time availability. It does not include schedules, working hours, or bookable time slots.</p>

<p>OfferPortal is a context/read model intended to support fast, “chatty” consumption. It is not a replacement for scheduling or billing workflows.</p>

<p><b>PractitionerRolePortal</b> represents a practitioner acting in a specific operational and financial context.</p>

<p>It answers the question: <i>“In which role, at which service location, and under which financial responsibility does this practitioner perform services?”</i></p>

<ul> <li>Links a <b>PractitionerPortal</b> (the individual person).</li> <li>Links a <b>HealthcareServicePortal</b> (where the service is performed).</li> <li>Links a <b>BillingOrganizationPortal</b> (who is financially responsible).</li> </ul>

<p>A PractitionerRole defines the <b>context</b> in which work is performed, not the person itself.</p>

<ul> <li>A Practitioner may have <b>multiple PractitionerRolePortals</b>.</li> <li>A Practitioner may work at <b>multiple HealthcareServicePortals</b>.</li> <li>A Practitioner may act under <b>different BillingOrganizationPortals</b> depending on context.</li> </ul>

<p>This makes PractitionerRole the central concept for:</p> <ul> <li>Booking and offers</li> <li>Pricing and duration rules</li> <li>Financial responsibility</li> <li>Service-specific configuration</li> </ul>

<p><b>Important:</b> PractitionerRolePortal is intentionally used to separate the person from the context in which services are delivered and billed.</p>

<p><b>Current name in Backoffice:</b> Practitioner</p>

<p><b>SchedulePortal</b> represents when a practitioner is planned to work during a given time period.</p>

<p>It answers the question: <i>“Who is working in the coming weeks, and who can potentially be shown as bookable?”</i></p>

<ul> <li>Provides <b>time-based context</b> for practitioners.</li> <li>Is used to filter which offers may proceed to availability checks.</li> <li>Supports planning and staffing views.</li> </ul>

<p><b>Relationship to Offer:</b></p> <ul> <li><b>Offer</b> defines what can be presented and selected (what/where/who).</li> <li><b>SchedulePortal</b> indicates when a practitioner is planned to work.</li> <li>A practitioner may have an <b>Offer without a SchedulePortal</b>.</li> </ul>

<p><b>Important:</b> A practitioner without SchedulePortal may still be included in offers for presentation and marketing purposes, but must be treated as <b>not currently bookable</b>.</p> <p><b>SchedulePortal is not availability:</b></p> <ul> <li>SchedulePortal does <b>not</b> represent bookable time slots.</li> <li>SchedulePortal does <b>not</b> guarantee that a booking can be made.</li> <li>Actual bookability requires downstream <b>Slot/availability</b> checks.</li> </ul>

<p><b>Design principle:</b> Offer determines eligibility. Schedule determines potential availability. Slot determines actual bookability.</p>

An example of a patient with a license to krill.