Modèle Backend CRM pour sujets d'essais cliniques __PH0__
Suivi des utilisateurs, études, sujets, sélection, visites, et événements indésirables
Un backend CRM pour sujets d'essais cliniques prêt pour la production sur Back4app avec des flux de travail Étude, Sujet, Sélection, Visite, ÉvénementIndésirable, et NoteSujet. Comprend un diagramme ER, un dictionnaire de données, un schéma JSON, un espace de jeu API, et un prompt Agent AI pour un démarrage rapide.
Points à retenir du test
Ce modèle vous donne un backend CRM pour les sujets d'essai clinique avec des classes Utilisateur, Étude, Sujet, Dépistage, Visite, Événement indésirable et Note de sujet afin que les coordinateurs puissent effectuer des opérations sur les sujets avec moins de suivi manuel.
- Suivi de l'état de dépistage — Modélisez chaque sujet et enregistrement de dépistage afin que les coordinateurs puissent voir les états en attente, réussi, échoué ou de nouveau dépistage avec screeningDate et notes.
- Visibilité du calendrier des visites — Utilisez Visit.visitType, scheduledAt, visitStatus, location et coordinator pour garder les visites planifiées et les reprogrammations interrogeables.
- Journalisation des événements indésirables — Capturez AdverseEvent.eventTerm, severity, serious, onsetDate, status et reportedBy pour un examen de sécurité.
- Flux de travail adapté aux coordinateurs — Soutenir le personnel d'étude avec les attributions Subject.coordinator, Screening.completedBy, Visit.coordinator et SubjectNote.author dans un seul backend.
- Opérations d'essai multiplateforme — Servir des tableaux de bord web, mobile et clinique via une API REST et GraphQL pour les sujets, les visites, les notes de sécurité et les événements indésirables.
Qu'est-ce que le modèle CRM des sujets d'essai clinique ?
Les rapports dans le CRM des sujets d'essai clinique doivent répondre aux questions de direction sans une recherche manuelle à travers des dossiers et des fils de messages. Ce n'est rarement un seul bogue — c'est une dérive. Back4app ancre les entités clés pour les pratiques CRM des sujets d'essai clinique qui ont besoin de délais, de documents et de communications dans un espace de travail autorisé. Le schéma couvre les enregistrements User, Study, Subject, Screening, Visit, AdverseEvent et SubjectNote avec des flux de travail intégrés tenus compte de l'authentification et de la sécurité. Connectez votre frontend préféré et expédiez plus rapidement.
Meilleur pour :
Aperçu du backend CRM pour les sujets d'essai clinique
Les équipes CRM des sujets d'essai clinique réussissent lorsque le travail routinier est ennuyeux : des dossiers prévisibles, une propriété évidente et des alertes avant que de petits problèmes ne deviennent des incidents.
Examinez d'abord le suivi des attributions d'études, le registre des sujets, le flux de travail de dépistage, puis ouvrez une carte de pile pour voir des notes spécifiques au SDK et des modèles d'intégration.
Fonctions principales de l'essai clinique
Chaque fiche technologique dans ce hub utilise le même schéma backend des essais cliniques avec Utilisateur, Étude, Sujet, Screening, Visite, ÉvénementIndésirable et NoteSurSujet.
Suivi de l'attribution de l'étude
L'étude stocke protocolId, titre, statut, chercheur principal et siteName.
Registre des sujets
Le sujet stocke subjectId, nomComplet, statutDeDépistage, étude, coordinateur, dateDeNaissance, sexeÀLaNaissance, et consentementSignéÀ.
Flux de travail de dépistage
Le dépistage relie un sujet, une étude, le statut de dépistage, la date de dépistage, la personne ayant complété et des notes.
Planification des visites
La visite capture le sujet, l'étude, le type de visite, la date prévue, le statut de la visite, l'emplacement et le coordinateur.
Journalisation des événements de sécurité
AdverseEvent stocke le sujet, l'étude, le terme d'événement, la gravité, le caractère sérieux, la date d'apparition, le statut et le rapporté par.
Pourquoi construire votre backend CRM pour sujets d'essai clinique avec Back4app ?
Back4app vous fournit des primitives User, Study, Subject, Screening, Visit, AdverseEvent et SubjectNote afin que les coordonnateurs puissent se concentrer sur les opérations de l'essai plutôt que sur l'infrastructure.
- •Dépistage et flux de sujets dans un seul schéma: Les classes Subject et Screening conservent subjectId, fullName, screeningStatus, screeningDate et completedBy au même endroit.
- •Les horaires de visite restent interrogeables: Les champs Visit et SubjectNote facilitent l'examen des rendez-vous prévus, des reports et des suivis du personnel.
- •La journalisation de la sécurité est explicite: Les entrées AdverseEvent avec eventTerm, severity, serious, onsetDate, status et reportedBy supportent des chronologies d'événements vérifiables.
Construisez un backend pour essais cliniques qui maintient les dépistages, les visites, les notes et les événements indésirables alignés entre les équipes.
Avantages des essais
Un backend d'essai clinique qui aide les coordinateurs à travailler plus rapidement tout en gardant les opérations des sujets structurées.
Démarrage rapide des essais
Commencez à partir d'un schéma complet d'Utilisateur, Étude, Sujet, Screening, Visite, ÉvénementIndésirable et NoteSurSujet au lieu de mapper les tables d'essai depuis zéro.
État de screening clair
Utilisez Subject.screeningStatus et Screening.screeningStatus pour séparer les cas en attente, réussis, échoués et à revoir.
Coordination des visites sans deviner
Planifiez et replanifiez les enregistrements de visite avec visitType, scheduledAt, visitStatus et location afin que le personnel sache ce qui vient ensuite.
Examen de sécurité
AdverseEvent.severity, serious, onsetDate, status, and reportedBy fournissent aux équipes de sécurité un historique d'événements lisible.
Les notes de sujet restent liées au dossier
SubjectNote.noteType, noteText, author, et subject maintiennent les notes d'appel, de visite, et de dépistage attachées au bon participant.
Workflow de démarrage assisté par IA
Générez rapidement des structures de backend et des conseils d'intégration avec une seule invite structurée.
Prêt à lancer votre CRM de Sujet d'Essai Clinique ?
Laissez l'Agent IA Back4app structurer votre backend CRM de Sujet d'Essai Clinique et générer des workflows Utilisateur, Étude, Sujet, Dépistage, Visite, AdverseEvent, et SubjectNote à partir d'une seule invite.
Gratuit pour commencer — 50 invites d'agent IA/mois, pas de carte de crédit requise
Pile technologique des essais cliniques
Tout est inclus dans ce modèle de backend d'essai clinique.
Carte du schéma clinique
Modèle de relation d'entité pour le schéma backend CRM du sujet d'essai clinique.
Schéma couvrant les utilisateurs, les études, les sujets, les enregistrements de dépistage, les visites, les événements indésirables et les notes de sujet.
Voir la source du diagramme
erDiagram
User ||--o{ Study : "principalInvestigator"
User ||--o{ Subject : "coordinator"
User ||--o{ Screening : "completedBy"
User ||--o{ Visit : "coordinator"
User ||--o{ AdverseEvent : "reportedBy"
User ||--o{ SubjectNote : "author"
Study ||--o{ Subject : "study"
Study ||--o{ Screening : "study"
Study ||--o{ Visit : "study"
Study ||--o{ AdverseEvent : "study"
Subject ||--o{ Screening : "subject"
Subject ||--o{ Visit : "subject"
Subject ||--o{ AdverseEvent : "subject"
Subject ||--o{ SubjectNote : "subject"
User {
String objectId PK
String username
String email
String password
String role
String siteName
Date createdAt
Date updatedAt
}
Study {
String objectId PK
String protocolId
String title
String status
String principalInvestigatorId FK
String siteName
Date createdAt
Date updatedAt
}
Subject {
String objectId PK
String subjectId
String fullName
String screeningStatus
String studyId FK
String coordinatorId FK
Date dob
String sexAtBirth
Date consentSignedAt
Date createdAt
Date updatedAt
}
Screening {
String objectId PK
String subjectId FK
String studyId FK
String screeningStatus
Date screeningDate
String completedById FK
String notes
Date createdAt
Date updatedAt
}
Visit {
String objectId PK
String subjectId FK
String studyId FK
String visitType
Date scheduledAt
String visitStatus
String location
String coordinatorId FK
Date createdAt
Date updatedAt
}
AdverseEvent {
String objectId PK
String subjectId FK
String studyId FK
String eventTerm
String severity
Boolean serious
Date onsetDate
String status
String reportedById FK
Date createdAt
Date updatedAt
}
SubjectNote {
String objectId PK
String subjectId FK
String authorId FK
String noteType
String noteText
Date createdAt
Date updatedAt
}
Flux d'intégration clinique
Flux d'exécution typique pour la connexion de l'utilisateur, le dépistage du sujet, la planification des visites, la saisie de la note de sujet et l'enregistrement de l'événement indésirable.
Voir la source du diagramme
sequenceDiagram
participant User
participant App as Clinical Trial Subject CRM App
participant Back4app as Back4app Cloud
User->>App: Sign in
App->>Back4app: POST /login
Back4app-->>App: Session token
User->>App: Open screening queue
App->>Back4app: GET /classes/Screening?include=subject,study&order=-screeningDate
Back4app-->>App: Screening rows with subjectId and screeningStatus
User->>App: Add a visit schedule
App->>Back4app: POST /classes/Visit
Back4app-->>App: Visit objectId and scheduledAt
User->>App: Log an adverse event
App->>Back4app: POST /classes/AdverseEvent
Back4app-->>App: AdverseEvent objectId and status
App->>Back4app: Subscribe to live updates for Visit and AdverseEvent
Back4app-->>App: Real-time subject activityGuide de terrain
Référence complète au niveau des champs pour chaque classe dans le schéma d'essai clinique.
| Champ | Type | Description | Requis |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Automatique |
| username | String | User login name | |
| String | User email address | ||
| password | String | Hashed password (write-only) | |
| role | String | Role of the user, such as coordinator, investigator, or sponsor | |
| siteName | String | Clinical site or clinic name | — |
| createdAt | Date | Auto-generated creation timestamp | Automatique |
| updatedAt | Date | Auto-generated last-update timestamp | Automatique |
8 champs dans User
Contrôles d'accès cliniques
Comment la stratégie ACL et CLP sécurise les études, les sujets, les visites, les notes de sujet et les journaux des événements indésirables.
Accès limité au coordinateur
Seul le personnel d'essai approuvé peut créer ou modifier des enregistrements de Sujet, de Dépistage, de Visite, d'Événement indésirable et de Note de sujet.
Séparation des données au niveau du site
Utilisez la propriété de l'étude et des requêtes basées sur des pointeurs afin que les équipes ne voient que les sujets assignés à leur site.
Intégrité du journal de sécurité
Les entrées d'Événement indésirable doivent être soumises à des restrictions d'écriture et validées dans le Cloud Code avant d'atteindre l'examen.
Schéma JSON
Définition brute du schéma JSON prête à être copiée dans Back4app ou à être utilisée comme référence d'implémentation.
{
"classes": [
{
"className": "User",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"username": {
"type": "String",
"required": true
},
"email": {
"type": "String",
"required": true
},
"password": {
"type": "String",
"required": true
},
"role": {
"type": "String",
"required": true
},
"siteName": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Study",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"protocolId": {
"type": "String",
"required": true
},
"title": {
"type": "String",
"required": true
},
"status": {
"type": "String",
"required": true
},
"principalInvestigator": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"siteName": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Subject",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"subjectId": {
"type": "String",
"required": true
},
"fullName": {
"type": "String",
"required": true
},
"screeningStatus": {
"type": "String",
"required": true
},
"study": {
"type": "Pointer",
"required": true,
"targetClass": "Study"
},
"coordinator": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"dob": {
"type": "Date",
"required": false
},
"sexAtBirth": {
"type": "String",
"required": false
},
"consentSignedAt": {
"type": "Date",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Screening",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"subject": {
"type": "Pointer",
"required": true,
"targetClass": "Subject"
},
"study": {
"type": "Pointer",
"required": true,
"targetClass": "Study"
},
"screeningStatus": {
"type": "String",
"required": true
},
"screeningDate": {
"type": "Date",
"required": true
},
"completedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"notes": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Visit",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"subject": {
"type": "Pointer",
"required": true,
"targetClass": "Subject"
},
"study": {
"type": "Pointer",
"required": true,
"targetClass": "Study"
},
"visitType": {
"type": "String",
"required": true
},
"scheduledAt": {
"type": "Date",
"required": true
},
"visitStatus": {
"type": "String",
"required": true
},
"location": {
"type": "String",
"required": false
},
"coordinator": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "AdverseEvent",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"subject": {
"type": "Pointer",
"required": true,
"targetClass": "Subject"
},
"study": {
"type": "Pointer",
"required": true,
"targetClass": "Study"
},
"eventTerm": {
"type": "String",
"required": true
},
"severity": {
"type": "String",
"required": true
},
"serious": {
"type": "Boolean",
"required": true
},
"onsetDate": {
"type": "Date",
"required": true
},
"status": {
"type": "String",
"required": true
},
"reportedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "SubjectNote",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"subject": {
"type": "Pointer",
"required": true,
"targetClass": "Subject"
},
"author": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"noteType": {
"type": "String",
"required": true
},
"noteText": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
}
]
}Construire avec l'Agent AI
Utilisez l'agent IA Back4app pour générer une application CRM pour les Sujets d'Essai Clinique à partir de ce modèle, y compris le frontend, le backend, l'authentification et les flux de dépistage, de visite, de note et de sécurité.
Créez un backend CRM pour les Sujets d'Essai Clinique sécurisé sur Back4app avec ce schéma et ce comportement exacts. Schéma: 1. Utilisateur (utiliser Back4app intégré) : nom d'utilisateur, e-mail, mot de passe, rôle, siteName ; objectId, createdAt, updatedAt (système). 2. Étude : protocolId (String, requis), titre (String, requis), statut (String, requis), investigateur principal (Pointeur vers Utilisateur, requis), siteName (String, requis) ; objectId, createdAt, updatedAt (système). 3. Sujet : subjectId (String, requis), nomComplet (String, requis), statutDépistage (String, requis), étude (Pointeur vers Étude, requis), coordonnateur (Pointeur vers Utilisateur, requis), dob, sexeÀLaNaissance, consentementSignéÀ ; objectId, createdAt, updatedAt (système). 4. Dépistage : sujet (Pointeur vers Sujet, requis), étude (Pointeur vers Étude, requis), statutDépistage (String, requis), dateDépistage (Date, requis), complétéPar (Pointeur vers Utilisateur, requis), notes (String) ; objectId, createdAt, updatedAt (système). 5. Visite : sujet (Pointeur vers Sujet, requis), étude (Pointeur vers Étude, requis), typeVisite (String, requis), planifiéÀ (Date, requis), statutVisite (String, requis), emplacement (String), coordonnateur (Pointeur vers Utilisateur, requis) ; objectId, createdAt, updatedAt (système). 6. ÉvénementIndésirable : sujet (Pointeur vers Sujet, requis), étude (Pointeur vers Étude, requis), termeÉvénement (String, requis), sévérité (String, requis), sérieux (Boolean, requis), dateD'apparition (Date, requis), statut (String, requis), rapportéPar (Pointeur vers Utilisateur, requis) ; objectId, createdAt, updatedAt (système). 7. NoteSujet : sujet (Pointeur vers Sujet, requis), auteur (Pointeur vers Utilisateur, requis), typeNote (String, requis), texteNote (String) ; objectId, createdAt, updatedAt (système). Sécurité: - Gardez les listes de sujets limitées au personnel authentifié. - Permettez aux coordonnateurs de modifier les Sujets et Visites pour leur site. - Restreignez l'entrée d'ÉvénementIndésirable aux utilisateurs authentifiés avec des rôles de coordonnateur ou d'investigateur. - Utilisez des ACL et CLP afin que le statut de dépistage, les plannings de visite, les notes de sujets et les journaux d'événements indésirables soient protégés de l'accès public. Auth: - Inscription, connexion, déconnexion. Comportement: - Suivez la file d'attente de dépistage, l'attribution de sujets, les plannings de visite, les journaux d'événements indésirables et les notes de sujets. - Supportez les requêtes filtrées par étude, statutDépistage, statutVisite et événements indésirables sérieux. Livraison: - Application Back4app avec schéma, ACL, CLP ; frontend pour les tableaux de bord de dépistage, la planification des visites, le rapport d'événements indésirables et les notes de sujets.
Appuyez sur le bouton ci-dessous pour ouvrir l'Agent avec ce modèle de prompt pré-rempli.
Ceci est le prompt de base sans suffixe technologique. Vous pouvez adapter la pile frontend générée par la suite.
API Sandbox
Essayez les points de terminaison REST et GraphQL contre le schéma de l'essai clinique. Les réponses utilisent des données fictives et ne nécessitent pas de compte Back4app.
Utilise le même schéma que ce modèle.
Choisissez votre pile
Développez chaque carte pour voir comment intégrer l'Étude, le Sujet et le Dépistage avec votre pile choisie.
Flutter CRM pour les sujets d'essai clinique
React CRM pour les sujets d'essai clinique
React Natif CRM pour les sujets d'essai clinique
Next.js CRM pour les sujets d'essai clinique
JavaScript CRM pour les sujets d'essai clinique
Android CRM pour les sujets d'essai clinique
iOS CRM pour les sujets d'essai clinique
Vue CRM pour les sujets d'essai clinique
Angular CRM pour les sujets d'essai clinique
GraphQL CRM pour les sujets d'essai clinique
REST API CRM pour les sujets d'essai clinique
PHP CRM pour les sujets d'essai clinique
.NET CRM pour les sujets d'essai clinique
Ce que vous obtenez avec chaque technologie
Chaque pile utilise le même schéma backend d'essai clinique et les contrats API.
Structure de données unifiée pour les opérations d'essai
Gérez facilement les enregistrements d'Utilisateur, d'Étude, de Sujet, de Dépistage, de Visite, d'ÉvénementIndésirable et de NoteDeSujet avec un schéma cohérent.
Contrôle de l'état de dépistage pour les équipes d'essai
Suivez les jalons d'éligibilité et d'inscription avec des champs de Sujet explicites.
Planification des visites pour les coordinateurs
Coordonnez les visites programmées, terminées, manquées ou annulées en un seul endroit.
Journalisation des événements de sécurité pour les workflows cliniques
Enregistrez les événements indésirables avec gravité et statut de suivi.
Comparaison de la pile clinique
Comparaison de la vitesse de configuration, du style SDK et du support AI entre toutes les technologies prises en charge.
| Framework | Temps de configuration | Avantage des essais cliniques | Type de SDK | Support AI |
|---|---|---|---|---|
| Environ 5 minutes | Code unique pour les applications de coordinateur sur mobile et web. | SDK typé | Complet | |
| Moins de 5 minutes | Tableau de bord web rapide pour le dépistage et la planification des visites. | SDK typé | Complet | |
| ~3–7 min | Application mobile multiplateforme pour le personnel de site. | SDK typé | Complet | |
| Configuration rapide (5 min) | Tableau de bord des opérations cliniques rendu par le serveur. | SDK typé | Complet | |
| ~3–5 min | Intégration web légère pour les opérations d'essai. | SDK Typé | Complet | |
| Environ 5 min | Application Android native pour les coordinateurs. | SDK Typé | Complet | |
| Moins de 5 minutes | Application iOS native pour l'examen des visites et de la sécurité. | SDK Typé | Complet | |
| ~3–7 min | Interface web React pour le suivi des sujets. | SDK tapé | Complet | |
| Configuration rapide (5 min) | Tableau de bord d'entreprise pour les équipes cliniques. | SDK tapé | Complet | |
| Moins de 2 min | API GraphQL flexible pour les requêtes d'essai imbriquées. | API GraphQL | Complet | |
| Configuration rapide (2 min) | Intégration REST API pour les opérations cliniques. | REST API | Complet | |
| ~3 min | Intégration PHP côté serveur pour les outils de coordinateur. | REST API | Complet | |
| ~3–7 min | Backend .NET pour des applications de flux de travail réglementées. | SDK tapé | Complet |
Le temps de configuration reflète la durée prévue depuis le démarrage du projet jusqu'à la première requête de sujet ou de visite utilisant ce schéma de modèle.
Questions Fréquemment Posées sur les Essais Cliniques
Questions courantes sur la création d'un backend CRM pour les sujets d'essai clinique avec ce modèle.
Prêt à créer votre application CRM pour sujets d'essais cliniques ?
Démarrez votre projet d'essai clinique en quelques minutes. Aucune carte de crédit requise.