Dev:LH MOC Admin-Travel services
The Travel Service Administration module is the central configuration area where all operational services that can be requested for a passenger are defined and managed.
A Travel Service represents a concrete operational action related to a passenger’s journey.
Examples include:
•Wheelchair assistance
•Stretcher transport (STCR)
•Oxygen on board (POXY)
•Escort services
•Ambulance transport to/from airport
•Medical device transport (CPAP/BIPAP)
•Additional seating
•Handling of medical baggage
These services may require:
•Medical approval
•Operational approval
•Ground handling coordination
•Service delivery partner involvement
•Task automation
•Capacity checks
The module defines how a service behaves in the system, including:
•Availability
•Dependencies
•Approval workflows
•Automation rules
•Service visibility
The Travel Service Administration module defines the operational backbone of passenger assistance and medical service handling.
It controls:
•how services appear
•who can request them
•how they trigger other services
•how approvals work
•how operational workflows are automated
Together with:
•SPFT
•Service Delivery Partners
•Travel Partners
this module forms the core system for managing passenger service operations.
Base data
The Base Data section defines the core behavior of a travel service and controls:
•where the service can be used (segment / port / flight / aircraft)
•who can request it
•how it behaves in workflows
•which additional configuration pages become available
A key part of this section is the Service Network Compatibility catalogue, which drives availability logic and UI behavior across the system.
Member Service Requestability
Defines who can request the service:
| Option | Effect |
|---|---|
| Passenger | Available in PAX portal |
| Travel partner | Available or external partners |
| Internal | Only internal users can add |
Service Network Compatibility (Catalogue-Driven Logic)
This section defines system-level characteristics of the service, based on a catalogue configuration.
These values are not manually editable, but are derived from the selected:
•Global Travel Service Binding
•Service Group Key
They determine:
•how the service behaves
•where it can be delivered
•which configuration options are available
Catalogue Flags
The following flags define service capabilities and restrictions:
On Segment Direct PAX Service Delivery
Value (example): No
Meaning:
Defines whether the service can be delivered directly to the passenger during a flight segment.
If Yes:
•Service can be delivered on board
•Enables:
•segment-level availability configuration
•segment-based automation
•Related pages enabled:
•Segment Availability
•Typical examples:
•onboard oxygen
•onboard assistance
If No:
•Service cannot be delivered onboard
•Segment-related configuration is restricted or irrelevant
At-Port Direct PAX Service Delivery
Value (example): Yes
Meaning:
Defines whether the service can be delivered at airport locations (departure, arrival, transfer).
If Yes:
•Service is available at:
•departure airport
•arrival airport
•transfer airport
•Enables:
•At Port Availability page
•port-based restrictions
•Typical examples:
•wheelchair assistance
•ambulance services
•escort services
If No:
•Service cannot be delivered at airport level
•Port configuration is disabled
Describes General Medical Condition
Value (example): No
Meaning:
Defines whether the service represents a medical condition classification rather than an operational service.
If Yes:
•Service is used for:
•classification (e.g., MEDA)
•Enables:
•medical workflows
•Does NOT represent a physical service
If No:
•Service is treated as an operational service
Trip Extra Service
Value (example): No
Meaning:
Defines whether the service applies to the entire journey (trip-level) rather than individual segments.
If Yes:
•Service applies to:
•whole itinerary
•Not tied to:
•specific segments
•Example:
•special handling across entire trip
If No:
•Service is applied per:
•segment or port
Segment Transport Type Service
Value (example): No
Meaning:
Defines whether the service is tied to transport type (air, rail, bus, etc.)
If Yes:
•Service depends on:
•transport type of segment
•Enables:
•transport-specific filtering
If No:
•Service is independent of transport type
Is Info Service
Value (example): No
Meaning:
Defines whether the service is informational only.
If Yes:
•Service:
•does NOT trigger delivery
•does NOT require execution
•Used for:
•displaying information
•No tasks or delivery partners triggered
If No:
•Service is operational and actionable
Service Availability Limitations
Defines where and under which conditions the service can be used.
These settings directly control:
•which configuration pages are visible
•how the service is filtered in workflows
Limited to Used Craft Type on Segment
If enabled:
•Service is restricted to specific aircraft types
•Enables:
•Craft Availability page
•Example:
•stretcher only available on widebody aircraft
If disabled:
•Service available for all aircraft types
Limited Availability by Port
If enabled:
•Service is restricted to selected airports
•Enables:
•At Port Availability page
•Requires:
•At-Port Direct PAX Service Delivery = Yes
If disabled:
•Service available at all ports
Limited Availability by Segment
If enabled:
•Service restricted to specific routes or segments
•Enables:
•Segment Availability page
If disabled:
•Service available across all segments
Limited Availability by Flight Number
If enabled:
•Service limited to specific flight numbers
•Enables:
•Flight Number Availability page
If disabled:
•Service not restricted by flight
Vessel Manipulation Travel Service
If enabled:
•Service involves physical aircraft manipulation
Examples:
•stretcher mounting
•seat removal
•equipment installation
Enables:
•timing logic in:
•Service Tree Creation
•operational preparation tasks
Enforce Mandatory Fields for this Service on Portal
If enabled:
•Passenger or agent must fill required fields before submitting request
Examples:
•medical details
•equipment requirements
If disabled:
•fields remain optional
Dependency Logic
The system behavior depends on combined conditions:
Example 1
At-Port Direct PAX Service Delivery = Yes
AND
Limited Availability by Port = Enabled
➡ Result:
•At Port Availability page becomes visible
•Service can be configured per airport
Example 2
On Segment Direct PAX Service Delivery = Yes
AND
Limited Availability by Segment = Enabled
➡ Result:
•Segment Availability page becomes visible
•Service can be configured per route
Example 3
Limited to Used Craft Type on Segment = Enabled
➡ Result:
•Craft Availability page becomes visible
•Service limited by aircraft
Example 4
Is Info Service = Yes
➡ Result:
•No:
•delivery partner assignment
•operational tasks
•Used only for:
•display / informational purposes
Example 5
Describes General Medical Condition = Yes
➡ Result:
•Service used in:
•medical classification
•Impacts:
•medical approval workflows
•Not treated as operational service
Internal Service Process Flow Type (SPFT)
Defines which workflow logic applies.
Take MEDA as example
Controls:
•approval flows
•task generation
•communication templates
Minimum Connection Times
Defines minimum required time between segments.
Used for:
•operational feasibility checks
•service validation
Insecure Handling Advice Communication
Defines fallback communication channels:
•email recipients
•telex recipients
Used when:
•digital delivery is not available
Service Tree Creation
Defines dependencies and relationships between services.
This allows services to automatically trigger or recommend other services.
Service Ordering
Defines which services should be suggested when another service is requested.
Example:
Requesting STCR (Stretcher) automatically suggests:
•Ambulance transport
•Escort service
•Medical oxygen
Force Option
If enabled, the suggested service is automatically added.
If disabled, the user can accept or reject the suggestion.
Backend Service Dependency
Defines automatic service creation in backend workflows.
Example:
When a Stretcher request is created:
Automatically add:
•Stretcher mounting
•Stretcher dismantling
These services are invisible to the passenger.
Vessel Manipulation Service
Defines services that require preparation work on the aircraft.
Examples:
•stretcher mounting
•equipment installation
•seat removal
Timing Options
Defines when preparation must occur:
| Option | Description |
| Before segment starts | preparation before flighr departure |
| After segment end | post-flight removal |
Port Delivery
The Port Delivery page defines where and how a service is delivered at airport level (ports) and which service delivery partners are responsible.
This page is only relevant when the service is:
•At-Port Direct PAX Service Delivery = Yes (from catalogue)
•AND optionally Limited availability by Port = enabled (from Base Data)
It allows administrators to:
•define at which ports the service is available
•assign responsible delivery partners
•define communication fallback (insecure communication)
•configure capacity restrictions per partner
This page is conditionally available based on Base Data settings
Direct PAX Service Deliverability at Port
Purpose
Defines when during the journey the service is delivered at port level.
Options
Deliverable during embarkation on first segment
•Service delivered at departure airport
•Example:
•wheelchair at check-in
•stretcher boarding preparation
Deliverable during transfer between segments
•Service delivered during transfer at connecting airports
•Example:
•escort during transfer
•medical assistance between flights
Deliverable during disembarkation from last segment
•Service delivered at arrival airport
•Example:
•wheelchair on arrival
•ambulance pick-up
Behavior
•Multiple options can be selected
•Defines when service delivery partners are triggered
•Directly impacts:
•task creation
•partner notifications
•workflow timing
Ports Where Service is Available to PAX
Defines where the service is operationally available and who delivers it.
Global Availability Toggle
Checkbox:
“This service is generally available at all ports”
If ENABLED
•Service is available globally
•Only exceptions (exclusions) are configured below
•Table acts as: restriction list not a whitelist
If DISABLED
•Service is available only at listed ports
Table acts as: explicit allow-list
Add Port Configuration
Fields
Add known port
Select airport (e.g., FRA, GVA)
Add known service delivery partner
Assign delivery partner responsible at that port
Examples: Swissport, Fraport, Handling agents
Unavailable at this port
Marks service as not available at selected port
Used when: global availability is enabled but specific ports must be excluded.
Port Configuration Table
| Column | Description |
|---|---|
| Available at port | Airport code |
| Authorized service delivery partner (defines who is allowed to deliver the service at that port and who will receive tasks and notifications) | Assigned partners |
| Insecure COM (defines fallback communication channel and is used when no digital integration exists or communication must still be ensured) | Fallback communication channels |
| Capacity resriction by partner (defines operational limits such as maximum concurrent services, partner-specific constraints) | Operational limits |
Segment Availability
The Segment Availability page defines on which flight segments a service can be delivered and under which routing conditions it is allowed or restricted.
This page is relevant when the service is:
✔ On Segment Direct PAX Service Delivery = Yes (from catalogue)
AND optionally
✔ Limited availability by Segment = enabled (from Base Data)
It allows administrators to:
define allowed or restricted route combinations (Departure → Destination)
control service availability per flight segment
override default behavior using inclusion/exclusion logic
Flight Number Availability
Defines availability of a service for specific flight numbers or flight plans.
This is the most granular restriction layer.
Dependency
Visible only if:
✔ Limited availability by flight number = enabled (Base Data)
Ruleset Table
Defines allowed or restricted flights.
allow-list OR exception list (same pattern as Segment)
Used when:
service differs per airline / route / regulation
Craft Type Availability
Defines on which aircraft types the service is possible.
Visible only if:
✔ Limited to used craft type on segment = enabled
General Availability
Checkbox This service is generally available to all crafts
Behavior
✔ Enabled
➡️ All aircraft allowed (exceptions possible)
❌ Disabled
➡️ Only listed aircraft allowed
Supported Craft Types
Fields
| Field | Description |
|---|---|
| Supported craft type | Aircraft (A350, A320, etc.) |
| Craft subgroup type | Category (Standard, etc.) |
Additional Option
Unavailable for this craft
➡️ Marks aircraft as excluded
Triggered by:
✔ SPFT = MEDA
Medical Approval
Defines how medical approval is handled for the service.
Used when:
service requires medical validation
passenger condition must be assessed
Medical Approval Process
Options
Force free text entry for approval
Force free text entry for approval
✔ When enabled:
Doctor MUST enter explanation when approving
❌ When disabled:
Approval can be done without comment
Allow free text for request of more information
✔ When enabled:
Doctor can send custom clarification request
❌ When disabled:
Only predefined actions can be used
Force free text info for denial reason
✔ When enabled:
Doctor MUST explain rejection
❌ When disabled:
Rejection can be done without explanation
Typical Medical Actions Defines predefined medical responses that doctors can use as one-click actions.
These actions:
standardize communication
reduce manual typing
speed up approval process
Add new default medical action
➡️ Opens form to create a predefined response
A Typical Medical Action (Creation Form) Defines a single reusable medical response used by doctors.
Typical reply (text input)
Whenever this service is requested with a doctor this shall be typical reply *
Main content of the response
Used in communication / decision
Action Type (radio buttons)
Defines how the response behaves in workflow:
Options
Is a conditional approval reason
➡️ Used when:
service is approved
BUT with conditions
Example:
“Approved if oxygen is provided”
Is a request for more information
➡️ Used when:
more medical data is required
Example:
“Please provide updated medical report”
Is a typical denial reason
➡️ Used when:
service is rejected
Example:
“Passenger not fit to fly”
