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

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.

ActivityDefinition represents what can be offered and booked as a service.

It answers the question: “What service is the patient booking?”

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

Booking and interoperability principle:

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

Important: The resource id is a technical identifier local to a FHIR server. It MUST NOT be used as a booking key.

ActivityDefinitionPortal describes the service concept only. It does not define:

• which locations offer the service
• which practitioners perform it
• context-specific price or duration
• availability, schedules, or bookable time slots

Those context-specific details are provided through Offer and related context resources.

Current name in Backoffice: Service

BillingOrganization represents the entity that is financially responsible for healthcare services.

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>

ServiceProvider represents the top-level owning organization within the platform.

It answers the question: “Which organization owns the configuration, endpoints, and service structure for a customer?”

A ServiceProvider:

• Represents the highest-level customer context (tenant) in the platform
• Owns all HealthcareService resources within its scope
• Owns all technical endpoints exposed for the customer
• Owns all PractitionerRole resources associated with its services
• Owns top-level configuration and settings for the customer

A ServiceProvider is modeled as an Organization but is intentionally separated from clinical and financial roles such as HealthcareService and BillingOrganization.

An example of a patient with a license to krill.