Une seule plateforme SaaS de santé peut servir plusieurs organisations qui utilisent les mêmes flux de travail de base, tout en nécessitant une image de marque, une configuration et des données opérationnelles isolées propres à chaque locataire.
Les formulaires deviennent rapidement l'un des aspects les plus difficiles à gérer dans ce modèle.
Chaque organisation peut vouloir :
- sa propre image de marque et son identité visuelle
- des flux de travail et des configurations personnalisés
- des données patients isolées
La solution la plus répandue consiste à dupliquer les formulaires locataire par locataire.
Au début, cela semble gérable. Un nouveau client est intégré, les formulaires sont copiés, l'image de marque est ajustée et le flux de travail est configuré de façon indépendante.
Mais à mesure que le nombre d'organisations augmente, la complexité croît elle aussi.
Un petit changement dans un flux de travail partagé peut devoir être répliqué dans des dizaines de locataires. La logique des formulaires commence à diverger entre les organisations. Les mises à jour deviennent plus difficiles à coordonner. Finalement, la maintenance des formulaires devient plus ardue que leur création initiale.
Le problème n'est pas seulement opérationnel.
Il est architectural.
Lorsque le même formulaire est copié à répétition dans tous les locataires, les plateformes perdent une source de vérité centralisée. Les flux de travail partagés se fragmentent, la logique d'interopérabilité diverge et l'évolutivité en souffre.
Une approche plus durable consiste à centraliser la création des formulaires tout en maintenant les données opérationnelles isolées par organisation. Cela permet aux plateformes de réutiliser la même structure de formulaire dans tous les locataires sans sacrifier la personnalisation ni la séparation des données.
Création centralisée de formulaires avec isolation par locataire
Un modèle plus évolutif consiste à séparer les définitions de formulaires partagées des données opérationnelles propres à chaque locataire.
Plutôt que de copier les formulaires dans chaque organisation, les formulaires sont créés une seule fois au niveau racine de la plateforme, puis partagés entre les locataires.
Dans Formbox, cela est réalisé à l'aide des ressources system-shared. Le mode system-shared rend une ressource globalement visible pour toutes les organisations tout en maintenant les données opérationnelles isolées au sein de chaque locataire.
Une ressource partagée est marquée à l'aide d'une extension spéciale dans les métadonnées de la ressource.
Par exemple, un Questionnaire FHIR partagé peut être créé de la façon suivante :
PUT /fhir/Questionnaire/patient-intake-form
content-type: text/yaml
resourceType: Questionnaire
id: patient-intake-form
meta:
extension:
- url: https://aidbox.app/tenant-resource-mode
valueString: "system-shared"
url: https://platform.example.com/forms/patient-intake-form
version: 1.0.0
status: active
title: Patient Intake Form
item:
- linkId: first-name
text: First Name
type: string
- linkId: date-of-birth
text: Date of Birth
type: date
Ce Questionnaire devient une définition de formulaire partagé gérée de façon centralisée et accessible globalement dans toutes les organisations, sans duplication.
Dans ce modèle :
- la définition du Questionnaire demeure centralisée
- les organisations réutilisent la même structure de formulaire
- chaque locataire stocke et gère ses propres QuestionnaireResponses de façon indépendante
Cela crée une séparation nette entre :
- la création des formulaires
- la collecte des données opérationnelles
Le formulaire lui-même devient un actif partagé, tandis que les données collectées demeurent isolées au sein de chaque organisation.
Par exemple, une plateforme SaaS de santé peut maintenir un seul formulaire d'admission de patients utilisé dans des dizaines de cliniques. La structure, la logique de validation, les règles d'extraction et le comportement d'interopérabilité sont gérés de façon centralisée, tandis que chaque clinique collecte et stocke ses propres données patients de manière indépendante.
Cette approche simplifie considérablement la gestion du cycle de vie des formulaires.
Les mises à jour peuvent être appliquées une seule fois au niveau du formulaire partagé et deviennent immédiatement disponibles dans toutes les organisations, sans avoir à synchroniser manuellement de multiples copies du même formulaire.
En même temps, l'isolation des locataires demeure préservée, car les données opérationnelles sont toujours stockées dans le contexte propre à chaque organisation.
Personnalisation par locataire sans duplication des formulaires
L'une des principales préoccupations liées aux structures de formulaires partagées est la personnalisation.
Les organisations s'attendent toujours à avoir leur propre identité visuelle, leur image de marque et leur style. Une plateforme SaaS de santé peut soutenir de nombreuses organisations utilisant les mêmes formulaires sous-jacents, tandis que chaque organisation s'attend à une expérience qui reflète son propre environnement.
Le défi consiste à prendre en charge cette personnalisation sans fragmenter le formulaire lui-même.
Une approche plus évolutive consiste à séparer la structure du formulaire de sa présentation et de sa personnalisation visuelle.
Plutôt que de créer des copies de formulaires propres à chaque locataire, le même Questionnaire partagé peut être lancé pour une organisation spécifique avec un thème propre à cette organisation.
Par exemple, l'application peut appeler $populatelink dans le contexte de l'organisation et transmettre le thème en tant que paramètre :
POST /Organization/[org-id]/fhir/Questionnaire/[questionnaire-id]/$populatelink
Content-Type: text/yaml
Accept: text/yaml
resourceType: Parameters
parameter:
- name: theme
valueString: [theme-id]
Cela permet d'ouvrir le même formulaire partagé avec le thème visuel configuré pour une organisation spécifique.
Les organisations peuvent personnaliser l'apparence du formulaire — par exemple, les couleurs, la typographie, l'espacement et l'image de marque — sans modifier la définition du Questionnaire sous-jacent.
Par conséquent, la même structure de formulaire peut s'afficher différemment selon les organisations tout en préservant les mêmes règles de validation, la même logique d'extraction, le même comportement d'interopérabilité et le même processus de gestion du cycle de vie.
La distinction importante est que seule la couche de présentation change.
La structure du formulaire elle-même demeure centralisée et réutilisable dans toutes les organisations.
Isolation des données opérationnelles et stockage des QuestionnaireResponses
Bien que les définitions de formulaires soient partagées globalement, les données collectées demeurent isolées au sein de l'organisation où le formulaire est utilisé.
C'est l'un des aspects les plus importants des plateformes de santé multitenant.
Le même Questionnaire partagé peut être réutilisé dans de nombreuses organisations, mais chaque QuestionnaireResponse est stockée dans le contexte du locataire où elle a été créée. Ainsi, les organisations peuvent utiliser les mêmes formulaires en toute sécurité sans exposer leurs données opérationnelles ou patients aux autres locataires.
Par exemple, deux cliniques peuvent lancer le même formulaire d'admission de patients partagé :
Questionnaire/patient-intake-form
Mais les QuestionnaireResponses générées demeurent isolées par organisation.
Le Questionnaire partagé est globalement visible, mais la QuestionnaireResponse soumise est stockée dans le contexte du locataire. L'organisation est identifiée au moyen de l'extension tenant-organization-id dans meta.
resourceType: QuestionnaireResponse
questionnaire: Questionnaire/patient-intake-form
status: completed
subject:
reference: Patient/patient-123
item:
- linkId: first-name
answer:
- valueString: John
meta:
extension:
- url: https://aidbox.app/tenant-organization-id
valueReference:
reference: Organization/org-b
- url: ex:createdAt
valueInstant: '2024-10-03T15:02:09.039005Z'
lastUpdated: '2024-10-03T15:02:09.039005Z'
versionId: '336'
Ce modèle crée une séparation puissante :
- gestion centralisée du cycle de vie des formulaires
- données opérationnelles isolées
Par conséquent :
- les organisations demeurent opérationnellement indépendantes
- les données patients restent liées au locataire
- les mises à jour des formulaires peuvent toujours être gérées de façon centralisée
Cette architecture fonctionne particulièrement bien pour les plateformes SaaS de santé où la logique d'interopérabilité, les règles d'extraction et les flux de travail doivent demeurer cohérents dans toutes les organisations, tandis que les données opérationnelles restent sécurisées et isolées.
Conclusion
Les plateformes de santé les plus évolutives ne dupliquent pas les formulaires par client.
Elles centralisent plutôt la création des formulaires tout en isolant les données opérationnelles et en personnalisant la présentation de façon dynamique.
Cela crée une architecture beaucoup plus durable :
- les formulaires sont maintenus une seule fois
- les organisations demeurent indépendantes
- l'image de marque et les thèmes restent flexibles
- la logique d'interopérabilité demeure cohérente dans tous les locataires
Pour les plateformes SaaS de santé, il s'agit de bien plus qu'une optimisation d'infrastructure.
C'est ce qui permet aux flux de travail des formulaires de s'adapter à toutes les organisations sans perdre en cohérence, en maintenabilité ni en interopérabilité.
Pour en savoir plus sur la multilocation des formulaires dans Formbox : https://www.health-samurai.io/docs/formbox/aidbox-ui-builder-alpha/forms-multitenancy
Ou essayez de créer et de tester des formulaires par vous-même : https://form-builder.aidbox.app/
