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”

Related articles

Translations