Dev:LH MOC Admin-Travel services: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
← Older editNewer edit →
VisualWikitext
Mionamilosevic (talk | contribs)
Bureaucrats, dev-team, developer, Administrators
852 edits
No edit summary
Mionamilosevic (talk | contribs)
Bureaucrats, dev-team, developer, Administrators
852 edits
No edit summary
Line 1: Line 1:
The Travel Service Administration module is the operational brain behind how special travel and medical services behave across the entire ecosystem.
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.


It does not just store service names.
A Travel Service represents a concrete operational action related to a passenger’s journey.


It controls:
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:


•When a service can be requested
•Availability


•Where it can be delivered (port or segment)
•Dependencies


•On which aircraft it is allowed
•Approval workflows


•Whether medical approval is required
•Automation rules


•Which partners must perform work
•Service visibility


•When mounting/dismantling happens


•Which tasks are automatically created
The '''Travel Service Administration module''' defines the operational backbone of passenger assistance and medical service handling.


•Who is responsible at every stage
It controls:


•How operational centers (MOC/OC) are notified
•how services appear


•How backend workflow behaves after approval/rejection
•who can request them


In short:
•how they trigger other services


It defines the operational logic of special service handling from request → approval → execution → automation.
•how approvals work


'''Core Role in the System'''
•how operational workflows are automated


Every time:
Together with:


•A passenger requests a medical or special service
•'''SPFT'''


•A partner adds a service to a booking
•'''Service Delivery Partners'''


•A MOC approves or rejects a case
•'''Travel Partners'''


•A flight segment is created
this module forms the core system for managing passenger service operations.


•A mounting/dismantling is required
== '''Travel Service List View''' ==
'''Purpose'''


•A service delivery partner must be notified
Displays all configured Travel Services and provides a central entry point for managing them.


The system reads the rules configured here.


This module determines:
'''Table Fields'''


•Whether the request is even allowed
'''Field''' '''Description'''


•Who must act
Carrier Airline or operator responsible for the service


•What tasks are generated
Service Code Unique identifier for the service


•What timing logic applies
SPFT Service Process Flow Type assigned to the service


•Which ports and segments are involved
Name Display name of the service


Without this configuration, no operational automation works.
Service Delivery Indicates how the service is delivered (port, segment, or partner)


=== '''Actions''' ===
'''Add New ➕'''


'''Service Behavior Definition'''
Creates a new travel service.


Each service configured here defines:
'''Search 🔍'''


'''Identity'''
Allows searching by:
 
•Service name


•Code
•Code


•Carrier ownership
•Carrier
 
'''Edit ✏️'''
 
Opens the configuration of the selected service.
 
'''Delete 🗑️'''
 
Removes the service.


•Internal name
Deletion is restricted if:


•Visual representation (icon + color tag)
•The service is used in workflows


This determines how it appears:
•The service is referenced in automation rules


•In booking flows
•The service is assigned to delivery partners
[[File:Travel services.png|none|thumb]]


•In OC/MOC dashboards
== '''Travel Service Configuration''' ==
Each Travel Service is configured through three main sections:


•In backend operations
1. Base Data


2. Service Tree Creation


'''Medical Approval Logic'''
3. Medical Approval


If a service is categorized as requiring medical approval:
== '''Base Data''' ==
'''Purpose'''


The system will:
Defines the identity, classification, and availability logic of the travel service.


•Block automatic confirmation
This section determines '''how the service integrates into the service ecosystem'''.


•Route the request to MOC
=== '''General Information''' ===
'''Code'''


•Apply defined approval actions
Unique identifier for the service.


•Enforce freetext if configured
Example:STCR, POXY


•Trigger automation after approval/rejection


It defines:
Used by:


•Whether doctor must enter comments
•backend systems


•Whether denial must include reason
•automation rules


•What predefined replies are available
•integrations


This ensures regulatory and medical compliance.
==== '''Operating Carrier''' ====
Defines which airline or carrier the service belongs to.


Example:


'''Service Availability Engine'''
•Lufthansa


This is one of the most critical parts.
•SWISS


The module defines whether a service:
•Discover Airlines


•Is globally available
This enables carrier-specific configuration and rules.


•Is restricted by port
==== '''Is Active''' ====
Defines whether the service is currently available.


•Is restricted by segment
Inactive services:


•Is restricted by aircraft
•Cannot be requested


•Is restricted by flight number
•Remain stored for historical cases


'''Port-Based Availability'''
==== '''Internal Name of Travel Service''' ====
The display name used in the system and PAX portal.


If delivery point = port:
Example: Stretcher Transport, Passenger Oxygen Cylinder, Medical Escort


System checks:
''Supports multilingual entries.''


•Is the service allowed at this port?
==== '''Upload Icon''' ====
Assigns an icon that visually represents the service.


•Is it for embarkation/disembarkation?
Icons appear in:


•Is there a delivery partner at this port?
•Passenger portal


If no partner exists → service cannot be delivered.
•Service selection screens


•Backend UI


'''Segment-Based Availability'''
=== '''Service Network Compatibility''' ===
Defines how the service integrates into the global service ecosystem.


If delivery point = segment:
==== '''Global Travel Service Bindings''' ====
Links the service to a '''global service definition'''.


System checks:
This ensures:


•Is aircraft type allowed?
•Standardized classification


•Is this specific segment allowed?
•Consistent behavior across carriers


•Is this service supported for this transport type?
•Interoperability with network partners


For example:
==== '''Member of Service Group Key''' ====
Defines which service group this service belongs to.


•STRETCHER may only be allowed on specific aircraft types.
Examples of groups:


•POC may only be allowed on certain long-haul aircraft.
•Medical services


This ensures operational feasibility.
•Assistance services


•Informational services


'''Craft Type Control'''
•Operational services


The service can:
Service groups help:


•Be available for all craft types
•organize services


•Be limited to selected aircraft
•apply shared logic


•Be explicitly unavailable for certain craft subtypes
•simplify UI grouping


This ensures:
=== '''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.


•Technical compatibility
Example:


•Weight/balance safety
•Ambulance service only at FRA and MUC.


•Cabin configuration compliance
==== '''Limited Availability by Flight Number''' ====
Allows defining specific flights where the service is available.


Example:
Example:


•Extra seats may be allowed only on wide-body aircraft.
•Special medical equipment only on certain aircraft.


•STCR may not be supported on narrow-body configurations.
==== '''Limited to Used Craft Type''' ====
Restricts the service based on aircraft type.


Example:


'''Mounting / Dismantling Automation'''
•Stretcher services only on widebody aircraft.


If a service requires physical aircraft modification:
=== '''Vessel Manipulation Service''' ===
Indicates that the service requires physical work on the aircraft.


Examples:
Examples:


•STRETCHER
•Stretcher mounting


•Special seating devices
•Equipment installation


•Medical installations
These services trigger '''additional preparation workflows'''.


The system must:
=== '''Member Service Requestability''' ===
Defines who can request the service.


•Know which ports can perform mounting
==== '''Requested by Passenger''' ====
Service can be requested directly in the PAX portal.


•Know which partner performs it
Example:


•Know when it must happen
•Escort


The configuration defines:
•Medical assistance


•Mounting ports
==== '''Requested by Travel Partner''' ====
Service can be requested by external partners.


•Dismantling ports
Example:


•Responsible service delivery partner
•Medical agencies


•Time-to-delivery rules
•Assistance companies


The system automatically creates:
==== '''Requested Internally''' ====
Service can only be added by internal staff.
 
Example:
 
•Technical handling services


•Mounting tasks
•Mounting tasks


•Dismantling tasks
=== '''Service Process Flow Type (SPFT)''' ===
Assigns the service to a '''Service Process Flow Type'''.
 
Examples:
{| class="wikitable"
|+
!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.
 
[[File:TS base data.png|none|thumb]]
 
 
== '''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:
{| class="wikitable"
|+
!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
|}
[[File:TS service tree creation.png|none|thumb]]
 
== '''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:
{| class="wikitable"
!Action
!Description
|-
|Condition approval
|Approve with conditions
|-
|Request more info
|Ask for more documentation
|-
|Reject
|Deny the request
|}
''These actions simplify decision making.''
[[File:TS medical approval.png|none|thumb]]
 
== '''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).
 


•Follow-up verification tasks
'''Service Dependencies'''


This prevents operational gaps.
Automatically generates related services.

Revision as of 11:13, 4 March 2026

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.

Retrieved from "https://wiki.kordeus.com/index.php?title=Dev:LH_MOC_Admin-Travel_services&oldid=3153"