Saltar al contenido principal

Script — Video 4: Cross-Plugin Integration

Duration target: ~7 minutes
Audience: Developers, CTOs, technical evaluators
Recording: Screen share of docs.obeliomed.com architecture diagrams + code snippets

Pre-roll checklist​

  • docs.obeliomed.com open on architecture section
  • VS Code open with a plugin's contracts/ folder (ObelioScheduling example)
  • Terminal ready with gh CLI logged in
  • OBS: screen share + webcam PiP

Intro (0:00 – 0:30)​

[On camera]

"This video is for developers. We're going to look at how the 17 obeliOmed plugins talk to each other — the cross-plugin contract system that keeps the ecosystem decoupled but connected."

"If you're evaluating obeliOmed for integration, or you want to build a new plugin on top of the ecosystem, this is the architecture you need to understand."

Chapter 1 — The problem: coupling vs isolation (0:30 – 1:30)​

[Screen: architecture diagram on docs.obeliomed.com]

"When you build a system from 17 separate plugins, you have a fundamental tension:"

"On one side, coupling — plugins call each other's code directly. Fast to develop, but a change in one plugin breaks five others."

"On the other side, isolation — plugins know nothing about each other. Safe, but then how do you trigger a WhatsApp reminder when an appointment is created?"

"obeliOmed solves this with a contracts pattern: each plugin publishes a versioned PHP interface describing what it provides. Other plugins depend on the interface, not the implementation."

Chapter 2 — The contracts folder (1:30 – 3:00)​

[VS Code: ObelioScheduling/contracts/]

"Every plugin that exposes functionality to other plugins has a contracts/ folder. Let me show you ObelioScheduling."

// contracts/AppointmentEventInterface.php
interface AppointmentEventInterface
{
    public function onAppointmentCreated(int $appointmentId, array $data): void;
    public function onAppointmentStatusChanged(int $appointmentId, string $newStatus): void;
    public function onPatientCheckedIn(int $appointmentId): void;
}

"This interface lives in ObelioScheduling. When an appointment is created, the plugin fires onAppointmentCreated. Any plugin that implements this interface receives the event."

"ObelioComms implements it — that's how it sends the confirmation WhatsApp."

"ObelioAudit implements it — that's how it records the audit event."

"ObelioOphthalmology listens for onPatientCheckedIn to prepare the clinical form."

"None of these plugins import code from each other. They all depend on the interface, which is the only contract."

Chapter 3 — FacturaScripts extension points (3:00 – 4:30)​

[Screen: FacturaScripts extension system documentation]

"The underlying mechanism is FacturaScripts' native extension system. When ObelioScheduling creates an appointment, it calls:"

$this->toolBox()->events()->trigger('AppointmentCreated', $appointmentId, $data);

"Every plugin that has registered a listener for AppointmentCreated receives the call. The registration happens in the plugin's init() method:"

// In ObelioComms/Init.php
public function init(): void
{
    $this->toolBox()->events()->addListener(
        'AppointmentCreated',
        [$this, 'handleAppointmentCreated']
    );
}

"The event system is synchronous within the same request, so it's fast. For long-running operations like sending WhatsApp messages, the listener queues the job and returns immediately."

Chapter 4 — Multi-tenant isolation (4:30 – 5:30)​

[Screen: docs.obeliomed.com/docs/architecture/multi-tenant]

"One more architecture point that matters for integrators: multi-tenant isolation."

"Every database table in obeliOmed has an idEmpresa column — the company ID. Every query is scoped to the authenticated company automatically by the base model."

"If you're building a plugin on top of obeliOmed, you never need to remember to filter by company. The framework does it. You just call $this->getModelList() and you get only records for the current company."

"Clinic centers add another layer: codalmacen is the FacturaScripts native warehouse code, extended by AdminClinicCenter to represent physical clinic locations. Appointments, patients, documents — all carry this code for center-level filtering."

Chapter 5 — Auto-generated API reference (5:30 – 6:30)​

[Screen: docs.obeliomed.com/docs/api]

"For external integrations — connecting your lab system, your billing platform, or building the ObelioPortalWeb patient portal — obeliOmed exposes a REST API."

"The API reference on this site is generated automatically from the swagger-php annotations in each plugin's controllers. Every time a developer merges a change to develop, the CI pipeline regenerates this page."

[Navigate to a specific endpoint like GET /patients]

"Here you can see the full spec for the patients endpoint: request parameters, response schema, authentication, status codes. All interactive — you can send a test request directly from this page."

Outro (6:30 – 7:00)​

[On camera]

"If you want to build on top of obeliOmed — a new clinical module, a custom report, an external integration — the contracts pattern and the REST API are your two entry points. Full documentation at docs.obeliomed.com."

"Next video: how to install and deploy obeliOmed in your clinic. Subscribe and I'll see you there."

Description (YouTube)​

How obeliOmed's 17 plugins stay decoupled but connected:

• The contracts pattern — PHP interfaces as versioned API between plugins
• FacturaScripts event system — how plugins listen without importing each other
• Multi-tenant isolation — idEmpresa + codalmacen scoping explained
• REST API auto-generated from swagger-php annotations

For developers, CTOs, and integrators evaluating obeliOmed.

🔗 Architecture docs: https://docs.obeliomed.com/docs/architecture
🔗 API reference: https://docs.obeliomed.com/docs/api

Chapters:
0:00 Intro
0:30 The coupling vs isolation problem
1:30 The contracts folder
3:00 FacturaScripts extension points
4:30 Multi-tenant isolation
5:30 Auto-generated API reference
6:30 What's next

Thumbnail spec​

  • Architecture diagram from docs (plugin dependency graph Mermaid)
  • Dark background, obeliOmed teal accent
  • Text: "Cross-Plugin Architecture"
  • Sub: "Contracts · Events · Multi-tenant"
  • "For Developers" badge top-right