Polnor.
Pour les laboratoires & la biotech

Vos données cliniques, prêtes pour la cohorte et la preuve réglementaire.

Testez la faisabilité d'une cohorte avant d'ouvrir un essai, produisez une Real-World Evidence de qualité « niveau essai », croisez labo, clinique et omique. Dé-identification RGPD par colonne, standards ouverts FHIR/OMOP, traçabilité prête pour l'audit, et la donnée patient qui ne quitte jamais votre cloud certifié HDS.

Vos enjeux

Ce qui vous freine aujourd'hui.

Constituer une cohorte prend des mois

Tester la faisabilité d'une cohorte sur une base réelle avant d'ouvrir des centres élimine une grande part du risque de recrutement, à condition d'avoir une donnée unifiée et interrogeable sur place.

Des données en silos, non interopérables

CTMS, EDC, dossiers cliniques, résultats de labo, données réelles : la réconciliation manuelle ralentit chaque décision. Il vous faut un socle unique clinique, labo et omique, sans copier la donnée hors de votre périmètre.

Une RWE « niveau essai » désormais attendue

EMA, FDA et PMDA demandent de plus en plus de Real-World Evidence pour confirmer efficacité et sécurité en vie réelle. Cela suppose un protocole pré-spécifié, un audit trail et une provenance traçable : une pipeline gouvernée, pas un export ponctuel.

Dé-identifier à l'échelle, et le prouver

La minimisation et la limitation de finalité du RGPD imposent une dé-identification reproductible et auditable, avec la garantie que la donnée patient ne sort jamais du périmètre certifié HDS.

Croiser labo, clinique et omique

La stratification de patients et la découverte de biomarqueurs exigent d'intégrer génomique, protéomique et clinique. L'intégration multimodale comble les angles morts du « une mutation, un test », mais bute sur l'harmonisation des données.

Tendances 2025-2026

Ce qui bouge dans votre monde.

La RWE dé-identifiée entre dans la décision réglementaire

La FDA a finalisé fin 2025 sa guidance Real-World Evidence pour les dispositifs et accepte la RWE sans exiger les données individuelles identifiables. La donnée de vie réelle dé-identifiée devient recevable pour un dossier, exactement ce que produit une pipeline FHIR vers OMOP.

L'EHDS ouvre l'usage secondaire des données

Le règlement EHDS (UE) 2025/327 est entré en vigueur en mars 2025 ; l'usage secondaire (recherche, entraînement d'IA) s'appliquera par étapes, sur permis et sous pseudonymisation. Structurer dès maintenant en OMOP dé-identifié est un avantage réglementaire.

Federated learning : collaborer sans centraliser

Le consortium pharma MELLODDY (10 laboratoires concurrents) a démontré la découverte de médicaments par apprentissage fédéré, chacun gardant ses données derrière son pare-feu. C'est la logique health-blind : entraîner sur plus de patients sans jamais déplacer la donnée.

Modèles de fondation en pathologie numérique

Les foundation models sur lames entières (ex. Virchow, Paige/MSKCC, publiés dans Nature Medicine) offrent un backbone réutilisable à fine-tuner pour un biomarqueur ou un cancer rare, là où les données annotées manquent. Encore faut-il croiser lames, omique et clinique à l'échelle.

Ce que vous pouvez faire

Concrètement, avec Polnor.

Tester une cohorte avant d'ouvrir un essai

Ingérez le FHIR de vos établissements partenaires, aplatissez-le, puis interrogez « combien de patients diabète T2, HbA1c > 8 %, sans insuline, sur 24 mois » pour cadrer vos critères d'inclusion, sans exporter la donnée.

Entraîner et servir un modèle de risque

De la cohorte au feature store, jusqu'à un modèle de risque de complication (suivi MLflow) déployé en endpoint de scoring, dans votre périmètre HDS et sans que le plan de contrôle voie les données.

Produire une RWE « niveau essai »

Pipeline reproductible : dé-id par colonne, contrôles qualité LOINC, conversion OMOP, journal d'accès et audit trail. Le dossier de traçabilité qu'attendent l'EMA et la FDA, rejouable au prochain signal de sécurité.

Croiser labo, clinique et omique

Unifiez résultats de laboratoire (LOINC), données cliniques et tables omiques dans un même lakehouse pour identifier sous-populations et candidats biomarqueurs, sans réconciliation manuelle.

Bâtir un bras de contrôle externe

Utilisez une cohorte réelle curée et versionnée comme comparateur externe pour un essai à bras unique, puis générez un manifeste d'export conforme EHDS, dé-identifié et tracé de bout en bout.

Réconcilier un patient entre CHU (EMPI/INS)

Rapprochez les dossiers d'un même patient vu dans plusieurs établissements via l'EMPI/INS pour dédoublonner une cohorte multi-sites, sans jamais exposer l'identité au plan de contrôle.

Un exemple concret

D'un signal de sécurité à une étude RWE réglementaire.

Un laboratoire commercialise un antidiabétique ; l'autorité demande de documenter le risque cardiovasculaire en vie réelle. Voici le déroulé, sans qu'aucune donnée patient ne sorte de son cloud.

1

Connexion & ingestion

Les serveurs FHIR des CHU partenaires sont connectés ; un pull $export Bulk alimente le bucket S3 du labo, chez l'hébergeur certifié HDS. Rien ne sort.

2

Qualité & structuration

Le FHIR est aplati en tables typées ; le contrôle qualité vérifie que HbA1c, LDL et créatinine sont en unités LOINC cohérentes et signale les valeurs aberrantes avant analyse.

3

Dé-identification & identité

Dé-identification par colonne (identifiants masqués, dates décalées). L'EMPI/INS réconcilie un même patient vu dans plusieurs établissements sans exposer son identité au plan de contrôle.

4

Cohorte & OMOP

Construction de la cohorte (patients exposés et comparateur externe), puis conversion au modèle OMOP CDM, directement lisible par les épidémiologistes réglementaires.

5

Analyse, modèle & preuve

Un notebook calcule l'incidence des événements cardiovasculaires ; un modèle de risque est suivi dans MLflow. Chaque accès PHI est journalisé, le pipeline versionné en Git, et un manifeste d'export EHDS est généré.

Résultat. Une étude RWE reproductible et auditable : l'audit trail exigé par l'EMA et la FDA existe par construction, le manifeste EHDS est prêt. La donnée patient n'a jamais quitté le cloud souverain du labo ; Polnor n'a orchestré que du SQL et des modèles.

Demander une démo →