Dev:LH MOC Admin-Travel services

The Travel Service Administration module is the operational brain behind how special travel and medical services behave across the entire ecosystem.

It does not just store service names.

It controls:

•When a service can be requested

•Where it can be delivered (port or segment)

•On which aircraft it is allowed

•Whether medical approval is required

•Which partners must perform work

•When mounting/dismantling happens

•Which tasks are automatically created

•Who is responsible at every stage

•How operational centers (MOC/OC) are notified

•How backend workflow behaves after approval/rejection

In short:

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

Core Role in the System

Every time:

•A passenger requests a medical or special service

•A partner adds a service to a booking

•A MOC approves or rejects a case

•A flight segment is created

•A mounting/dismantling is required

•A service delivery partner must be notified

The system reads the rules configured here.

This module determines:

•Whether the request is even allowed

•Who must act

•What tasks are generated

•What timing logic applies

•Which ports and segments are involved

Without this configuration, no operational automation works.

Service Behavior Definition

Each service configured here defines:

Identity

•Code

•Carrier ownership

•Internal name

•Visual representation (icon + color tag)

This determines how it appears:

•In booking flows

•In OC/MOC dashboards

•In backend operations

Medical Approval Logic

If a service is categorized as requiring medical approval:

The system will:

•Block automatic confirmation

•Route the request to MOC

•Apply defined approval actions

•Enforce freetext if configured

•Trigger automation after approval/rejection

It defines:

•Whether doctor must enter comments

•Whether denial must include reason

•What predefined replies are available

This ensures regulatory and medical compliance.

Service Availability Engine

This is one of the most critical parts.

The module defines whether a service:

•Is globally available

•Is restricted by port

•Is restricted by segment

•Is restricted by aircraft

•Is restricted by flight number

Port-Based Availability

If delivery point = port:

System checks:

•Is the service allowed at this port?

•Is it for embarkation/disembarkation?

•Is there a delivery partner at this port?

If no partner exists → service cannot be delivered.

Segment-Based Availability

If delivery point = segment:

System checks:

•Is aircraft type allowed?

•Is this specific segment allowed?

•Is this service supported for this transport type?

For example:

•STRETCHER may only be allowed on specific aircraft types.

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

This ensures operational feasibility.

Craft Type Control

The service can:

•Be available for all craft types

•Be limited to selected aircraft

•Be explicitly unavailable for certain craft subtypes

This ensures:

•Technical compatibility

•Weight/balance safety

•Cabin configuration compliance

Example:

•Extra seats may be allowed only on wide-body aircraft.

•STCR may not be supported on narrow-body configurations.

Mounting / Dismantling Automation

If a service requires physical aircraft modification:

Examples:

•STRETCHER

•Special seating devices

•Medical installations

The system must:

•Know which ports can perform mounting

•Know which partner performs it

•Know when it must happen

The configuration defines:

•Mounting ports

•Dismantling ports

•Responsible service delivery partner

•Time-to-delivery rules

The system automatically creates:

•Mounting tasks

•Dismantling tasks

•Follow-up verification tasks

This prevents operational gaps.