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.
Travel Service List View
Purpose
Displays all configured Travel Services and provides a central entry point for managing them.
Table Fields
Field Description
Carrier Airline or operator responsible for the service
Service Code Unique identifier for the service
SPFT Service Process Flow Type assigned to the service
Name Display name of the service
Service Delivery Indicates how the service is delivered (port, segment, or partner)
Actions
Add New ➕
Creates a new travel service.
Search 🔍
Allows searching by:
•Service name
•Code
•Carrier
Edit ✏️
Opens the configuration of the selected service.
Delete 🗑️
Removes the service.
Deletion is restricted if:
•The service is used in workflows
•The service is referenced in automation rules
•The service is assigned to delivery partners
Travel Service Configuration
Each Travel Service is configured through three main sections:
1. Base Data
2. Service Tree Creation
3. Medical Approval
Base Data
Purpose
Defines the identity, classification, and availability logic of the travel service.
This section determines how the service integrates into the service ecosystem.
General Information
Code
Unique identifier for the service.
Example:STCR, POXY
Used by:
•backend systems
•automation rules
•integrations
Operating Carrier
Defines which airline or carrier the service belongs to.
Example:
•Lufthansa
•SWISS
•Discover Airlines
This enables carrier-specific configuration and rules.
Is Active
Defines whether the service is currently available.
Inactive services:
•Cannot be requested
•Remain stored for historical cases
Internal Name of Travel Service
The display name used in the system and PAX portal.
Example: Stretcher Transport, Passenger Oxygen Cylinder, Medical Escort
Supports multilingual entries.
Upload Icon
Assigns an icon that visually represents the service.
Icons appear in:
•Passenger portal
•Service selection screens
•Backend UI
Service Network Compatibility
Defines how the service integrates into the global service ecosystem.
Global Travel Service Bindings
Links the service to a global service definition.
This ensures:
•Standardized classification
•Consistent behavior across carriers
•Interoperability with network partners
Member of Service Group Key
Defines which service group this service belongs to.
Examples of groups:
•Medical services
•Assistance services
•Informational services
•Operational services
Service groups help:
•organize services
•apply shared logic
•simplify UI grouping
Service Availability Limitations
Defines restrictions on where and how the service can be used.
Limited Availability by Port
The service is only available at specific airports.
Example:
•Ambulance service only at FRA and MUC.
Limited Availability by Flight Number
Allows defining specific flights where the service is available.
Example:
•Special medical equipment only on certain aircraft.
Limited to Used Craft Type
Restricts the service based on aircraft type.
Example:
•Stretcher services only on widebody aircraft.
Vessel Manipulation Service
Indicates that the service requires physical work on the aircraft.
Examples:
•Stretcher mounting
•Equipment installation
These services trigger additional preparation workflows.
Member Service Requestability
Defines who can request the service.
Requested by Passenger
Service can be requested directly in the PAX portal.
Example:
•Escort
•Medical assistance
Requested by Travel Partner
Service can be requested by external partners.
Example:
•Medical agencies
•Assistance companies
Requested Internally
Service can only be added by internal staff.
Example:
•Technical handling services
•Mounting tasks
Service Process Flow Type (SPFT)
Assigns the service to a Service Process Flow Type.
Examples:
| Code | Description |
|---|---|
| PWD | Passenger with disabilities |
| MEDA | Passenger with medical conditions |
| INF | Informational services |
| ISS | Service delivery services |
| PPP | Pre/Post processing services |
SPFT controls:
approval workflows
service visibility
automation behaviour
regulatory requirements
Insecure Handling Advice Communication
Defines fallback communication channels.
Used when digital integration is unavailable.
Examples:
•email notifications
•telex messages
These recipients are always notified regardless of service delivery partner.
Service Tree Creation
Purpose
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 |
| Before rotation start | before aircraft operational rotation |
| After rotation end | after final segment |
Medical Approval
Purpose
Defines how medical professionals interact with service requests.
Used when the service requires medical evaluation.
Medical Approval Process
Options:
Force Freestyle Entry for Approval
Doctor must write an explanation when approving.
Allow Freestyle Request for More Information
Doctor can request additional documentation from the requester.
Force Freestyle Denial Reason
Doctor must provide reason when rejecting.
Typical Medical Actions
Defines predefined responses for doctors.
These responses appear as one-click options.
Examples:
| Action | Description |
|---|---|
| Condition approval | Approve with conditions |
| Request more info | Ask for more documentation |
| Reject | Deny the request |
These actions simplify decision making.
Operational Workflow Impact
Travel Services directly affect:
Passenger Portal
Determines which services passengers can request.
Task Automation
Triggers tasks for:
•operations teams
•medical teams
•service delivery partners
Ground Handling
Links services to ground providers.
Regulatory Compliance
Ensures proper documentation (e.g., MEDIF).
Service Dependencies
Automatically generates related services.