Drupal 11 as the Governance Layer for an Open Health Platform

Two Sides to the Session

I think there are two sides to this session.

For attendees interested in the business case, we are going to explain the challenge of building an open platform in a fragmented healthcare ecosystem, the role of the application marketplace, and why Drupal was selected as the backend for governing the registration, homologation and publication of digital health assets.

For attendees interested in the technical implementation, we will explain what it takes to build a fully headless Drupal platform that must work with many external systems and specialist teams. We will share how Drupal was integrated with identity and cybersecurity services, a process management platform, Kafka, DevOps infrastructure and observability tooling.

So, for those people interested in digital health and public platforms or in the engineering behind a complex headless Drupal project, the session offers a real example of how business requirements and technical decisions come together.

Key Takeaways for Attendees

From the business side, people will understand how a public healthcare platform can use a marketplace model to register, develop, homologate and publish digital assets in a governed way.

The session will also show why Drupal Commerce was selected and configured as the foundation for modelling those assets: not as a traditional e-commerce solution, but as a flexible framework for products, flows, versions, publication states and catalog visibility.

From the technical side, I will go deeper into how that was implemented with Drupal 11. So, I will explain:

• How external identity and JWT roles are consumed from the IAM system, while Drupal applies endpoint-level and domain-level authorization.
• How personal identifiers are pseudonymised and represented locally through a lightweight entity, without turning Drupal into the master user directory.
• How a shared HTTP security layer handles service-to-service authentication, token caching, allowed targets and outbound calls to protected services.
• How BPMN process instances, tasks, incidents and validations are translated into a Drupal-friendly and multilingual API model.
• How a persistent Kafka listener receives BPMN status changes in the background, while the outbox pattern is used to publish reliable outbound events.
• How labels and FHIR CodeSystem terminology are imported into translatable Drupal taxonomies and exposed to the frontend through APIs.
• How OpenTelemetry captures request metrics, outbound-call metrics, traces and domain events without affecting the main business flow.
• How a custom Views field plugin generates structured JSON from entity references, reducing the need for one-off serializers and controllers.

The main technical lesson is that Drupal can provide the business model, APIs and governance layer of a complex platform while specialized systems remain responsible for identity, workflows, messaging, observability and the frontend, without making Drupal responsible for every concern in the architecture.

What I Am Most Excited About at the Event

I am especially excited because this will be my first time speaking at an event outside my country. Presenting in English, which is not my native language, is definitely a challenge, but it also makes the opportunity even more meaningful.

You May Like

Article

AI Integration - ECA 1.0.0 Reaches Stable Release, Replaces Earlier Integrations

Article

AI Integration - ECA 1.0.0 Reaches Stable Release, Replaces Earlier Integrations

DrupalCon Europe brings together people with a great deal of experience across development, architecture, product, public sector and open source. I am looking forward to sharing what we have learned from this project, but even more to listening to how other teams are solving similar problems and learning from their approaches. For me, the most valuable part will be meeting people who care about building better open platforms, exchanging ideas beyond the session itself, and creating professional connections that can continue after the event.

Why Digital Sovereignty Will Become Increasingly Relevant

For me, digital sovereignty is about having real control over the systems that support public services: control over data, identity, business rules, standards, integrations and the ability to evolve the platform over time.

It does not mean building everything alone or avoiding every external provider. It means avoiding a situation where an institution cannot understand, change or replace a critical part of its own digital infrastructure.

This is particularly important in healthcare. Digital health services need to work across many organisations, remain available for years and handle information that is both sensitive and essential. Open standards, interoperable contracts and open-source technologies help public institutions avoid isolated systems and reduce dependency on a single vendor or proprietary platform.

It will become increasingly relevant as public services depend more on cloud platforms, AI services, external identity providers and interconnected data ecosystems.

The question, I guess, is no longer only who provides the technology, but who controls the data model, the rules, the interfaces and the future of the service.

In this project, digital sovereignty is reflected in the architecture because Drupal provides an open and extensible layer for governing digital assets and their lifecycle, while BPMN, FHIR and observability tools are connected through explicit contracts. The goal is not to make one system do everything, but to build a platform where each component can evolve without losing control of the whole.