Template Backend Application Portail Patient
Fournir des résultats de laboratoire, gérer les plans de traitement et permettre une messagerie sécurisée entre le médecin et le patient
Un backend de portail patient prêt pour la production sur Back4app avec livraison sécurisée des résultats de laboratoire, gestion des plans de traitement, messagerie clinique, liaison de rendez-vous et journaux d'audit centralisés. Comprend un diagramme ER, un dictionnaire de données, un schéma JSON, un playground API, et un prompt Agent IA pour un démarrage rapide.
Principaux points à retenir
Expédiez un backend orienté patient avec des contrôles d'accès sécurisés, la gestion des versions de laboratoire, l'historique des plans de traitement, la messagerie en fil et des pistes d'audit afin que votre équipe produit puisse se concentrer sur l'expérience utilisateur et la conformité.
- Modèle de données centré sur le patient — Conservez l'identité du patient, les résultats de laboratoire, les traitements et les messages modélisés séparément mais liés pour une provenance et une autorisation claires.
- Messagerie sécurisée — Messages en fil, compatibles avec les pièces jointes entre patients et Provider avec des accusés de lecture clairs et des contrôles de conservation.
- Résultats de laboratoire versionnés — Stockez les résultats de laboratoire avec des métadonnées de provenance et de version afin que les rapports et addenda mis à jour soient suivis.
- Cycle de vie du plan de traitement — Gérer les brouillons de plans de traitement, les approbations par les Provider, la reconnaissance des patients et l'historique des versions.
- Journalisation compatible avec la conformité — La classe AuditLog centralisée enregistre les événements sensibles pour révision, surveillance et conformité.
Qu'est-ce que le modèle backend de l'application Patient Portal ?
Back4app est un backend-as-a-service (BaaS) pour une livraison rapide. Le modèle backend de l'application Patient Portal est un schéma préconstruit pour les profils de patients, les résultats de laboratoire, les plans de traitement, la messagerie sécurisée, les rendez-vous et les journaux d'audit. Connectez votre frontend préféré (React, Flutter, Next.js, et plus) et livrez plus vite.
Meilleur pour :
Aperçu
Les portails pour patients nécessitent des limites de données solides, des modifications auditées et une livraison fiable d'éléments sensibles tels que les résultats de laboratoire et les plans de traitement.
Ce modèle définit PatientProfile, LabResult, TreatmentPlan, Message, ProviderProfile, Appointment et AuditLog avec des règles de propriété et basées sur des rôles afin que les équipes puissent mettre en œuvre des portails pour patients rapidement et en toute sécurité.
Fonctionnalités principales du portail patient
Chaque carte technologique dans ce hub utilise le même schéma backend du portail patient avec PatientProfile, LabResult, TreatmentPlan, Message, ProviderProfile, Appointment et AuditLog.
Profil et authentification du patient
PatientProfile stocke l'identité, les coordonnées et les préférences avec une référence à l'utilisateur authentifié.
Résultats de laboratoire versionnés
LabResult stocke le type de test, la charge utile du résultat brut, la date de rapport, la version et la provenance Provider.
Cycle de vie du plan de traitement
TreatmentPlan stocke le contenu du plan, approbateur Provider, statut (brouillon, actif, terminé) et fenêtre effective.
Messagerie sécurisée entre le médecin et le patient
Le message prend en charge les fils de discussion, les pièces jointes, les pointeurs expéditeur/récipient et le statut de livraison/lecture.
Lien de rendez-vous
Le lien de rendez-vous relie le patient, Provider, l'heure prévue et le statut pour le contexte de la visite.
Journaux d'audit centralisés
AuditLog capture l'identité de l'acteur, le type d'action, le contexte de l'entité et les métadonnées de payload pour la conformité.
Pourquoi construire votre application de portail patient avec Back4app ?
Back4app gère les fondamentaux du backend—sécurité, persistance, API et temps réel—pour que vous puissiez vous concentrer sur l'expérience patient, les flux de travail de confidentialité et l'intégration clinique.
- •Livraison sécurisée des données cliniques: Les schémas d'authentification et d'ACL/CLP intégrés vous permettent de contrôler exactement quels utilisateurs peuvent voir chaque résultat de laboratoire, plan de traitement ou message.
- •Audit et provenance: AuditLog capture qui a consulté, publié ou modifié des dossiers sensibles afin que vous puissiez soutenir la conformité et le débogage.
- •Messagerie et notifications: Des messages en fil, des pièces jointes et des mises à jour en direct facultatives rendent les conversations entre cliniciens et patients fluides et opportunes.
Déployez rapidement un backend de portail patient sécurisé et itérez sur les flux de travail cliniques au lieu de la plomberie backend.
Avantages principaux
Un backend de portail patient qui met l'accent sur la confidentialité, la provenance et la livraison rapide.
Expériences patient accélérées
Expédier plus rapidement les vues des résultats de laboratoire, la livraison du plan de traitement et la messagerie sécurisée en réutilisant un contrat backend validé.
Provenance des données solide
Version des résultats de laboratoire et des plans de traitement afin que les changements cliniques soient audités et traçables.
Autorisations granulaires
Protéger les éléments sensibles avec des vérifications ACL/CLP et de rôle afin que seuls les cliniciens et les patients autorisés puissent y accéder.
Messagerie intégrée
Des messages filaires avec des pièces jointes et des mises à jour en temps réel optionnelles améliorent la collaboration entre cliniciens et patients.
Log des conformités
L'AuditLog centralisé prend en charge les revues, l'investigation d'incidents et le reporting de conformité.
Démarrage assisté par IA
Accélérez le développement avec un prompt d'Agent IA soigneusement sélectionné qui structure schéma, ACL et code d'intégration de base.
Prêt à créer un portail patient sécurisé ?
Laissez l'agent IA de Back4app structurer le backend de votre portail patient et générer des profils de patients, des résultats de laboratoire, des plans de traitement, des messages et des journaux d'audit à partir d'une seule invite.
Gratuit pour commencer — 50 invites d'agent IA/mois, sans carte de crédit requise
Stack technique
Tout est inclus dans ce modèle de backend de portail patient.
Diagramme ER
Modèle de relation d'entité pour le schéma backend du portail patient.
Schéma couvrant les profils patients, Providers, résultats de laboratoire, plans de traitement, messagerie, rendez-vous et journalisation des audits.
Voir la source du diagramme
erDiagram
PatientProfile ||--o{ LabResult : "has"
PatientProfile ||--o{ TreatmentPlan : "receives"
PatientProfile ||--o{ Message : "context for"
PatientProfile ||--o{ Appointment : "scheduled in"
_User ||--o{ Message : "sends/receives"
_User ||--o{ TreatmentPlan : "authors"
_User ||--o{ Appointment : "provides"
PatientProfile {
String objectId PK
Pointer user FK
String medicalRecordNumber
String displayName
Date dateOfBirth
String primaryClinic
Boolean isActive
Date createdAt
Date updatedAt
}
LabResult {
String objectId PK
Pointer patient FK
Pointer orderedBy FK
String testCode
String testName
String resultValue
String units
String referenceRange
String status
Date publishedAt
Array attachments
Date createdAt
Date updatedAt
}
TreatmentPlan {
String objectId PK
Pointer patient FK
Pointer createdBy FK
String summary
String details
String status
Date startDate
Date endDate
Date createdAt
Date updatedAt
}
Message {
String objectId PK
String conversationId
Pointer from FK
Pointer to FK
Pointer patient FK
String body
Array attachments
Boolean isRead
Date sentAt
Date createdAt
Date updatedAt
}
Appointment {
String objectId PK
Pointer patient FK
Pointer provider FK
Date startAt
Date endAt
String location
String status
String reason
Date createdAt
Date updatedAt
}
AuditLog {
String objectId PK
Pointer actor FK
String entityType
String entityId
String action
String summary
Object metadata
Date createdAt
Date updatedAt
}
Flux d'intégration
Flux d'exécution typique pour l'authentification, la livraison des résultats de laboratoire, les mises à jour du plan de traitement et la messagerie.
Voir la source du diagramme
sequenceDiagram
participant Patient
participant App as Patient Portal App
participant Clinician
participant Back4app as Back4app Cloud
Patient->>App: Sign in with email or SSO
App->>Back4app: POST /login (credentials/SSO token)
Back4app-->>App: Return Session Token + Patient context
Patient->>App: Open Dashboard (profile & recent labs)
App->>Back4app: GET /classes/PatientProfile?where={"user":Pointer("_User", "u123")}
Back4app-->>App: PatientProfile object
App->>Back4app: GET /classes/LabResult?where={"patient":Pointer("PatientProfile","p123")}&order=-publishedAt
Back4app-->>App: List of LabResult (latest first)
Patient->>App: View active Treatment Plan
App->>Back4app: GET /classes/TreatmentPlan?where={"patient":Pointer("PatientProfile","p123"),"status":"active"}
Back4app-->>App: TreatmentPlan object
Patient->>App: Send secure message to clinician
App->>Back4app: POST /classes/Message (conversationId, body, to: Pointer(_User, clinicianId))
Back4app-->>App: Message objectId
Back4app-->>App: LiveQuery -> new Message or LabResult update
App-->>Patient: Real-time notification (new message / result available)
Clinician->>Back4app: Update LabResult (finalize)
Back4app-->>App: LiveQuery event -> App fetches updated LabResult
App-->>Patient: Alert: "New lab result available"Dictionnaire de données
Référence complète au niveau des champs pour chaque classe dans le schéma du Portail Patient.
| Champ | Type | Description | Requis |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Auto |
| user | Pointer<_User> | Linked Back4app user account | |
| medicalRecordNumber | String | Unique MRN for the patient | |
| displayName | String | Patient full name shown in UI | |
| dateOfBirth | Date | Patient date of birth | — |
| primaryClinic | String | Primary clinic or provider group | — |
| isActive | Boolean | Active portal access flag | |
| createdAt | Date | Auto-generated creation timestamp | Auto |
| updatedAt | Date | Auto-generated last-update timestamp | Auto |
9 champs dans PatientProfile
Sécurité et autorisations
Comment les stratégies ACL, CLP et de cryptage sécurisent les résultats de laboratoire, les plans de traitement, les messages et les journaux d'audit.
Accès et propriété basés sur les rôles
Appliquer des ACL pour que les patients puissent voir leurs propres dossiers et que les Provider voient les données des patients qui leur sont assignées ; les CLP empêchent les opérations de classe non autorisées.
Charges utiles et pièces jointes chiffrées
Stocker des blobs sensibles (pièces jointes de laboratoire, PDFs) derrière des URL signées et utiliser le cryptage au niveau du stockage pour une protection au repos.
Journaux d'audit en ajout uniquement
Écrire des entrées AuditLog depuis le Cloud Code côté serveur pour s'assurer que les utilisateurs ne peuvent pas falsifier les enregistrements de conformité historiques.
Schéma (JSON)
Définition du schéma JSON brute prête à être copiée dans Back4app ou utilisée comme référence d'implémentation.
{
"classes": [
{
"className": "PatientProfile",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"user": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"medicalRecordNumber": {
"type": "String",
"required": true
},
"displayName": {
"type": "String",
"required": true
},
"dateOfBirth": {
"type": "Date",
"required": false
},
"primaryClinic": {
"type": "String",
"required": false
},
"isActive": {
"type": "Boolean",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "LabResult",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"patient": {
"type": "Pointer",
"required": true,
"targetClass": "PatientProfile"
},
"orderedBy": {
"type": "Pointer",
"required": false,
"targetClass": "_User"
},
"testCode": {
"type": "String",
"required": false
},
"testName": {
"type": "String",
"required": true
},
"resultValue": {
"type": "String",
"required": false
},
"units": {
"type": "String",
"required": false
},
"referenceRange": {
"type": "String",
"required": false
},
"status": {
"type": "String",
"required": true
},
"publishedAt": {
"type": "Date",
"required": false
},
"attachments": {
"type": "Array",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "TreatmentPlan",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"patient": {
"type": "Pointer",
"required": true,
"targetClass": "PatientProfile"
},
"createdBy": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"summary": {
"type": "String",
"required": true
},
"details": {
"type": "String",
"required": false
},
"status": {
"type": "String",
"required": true
},
"startDate": {
"type": "Date",
"required": false
},
"endDate": {
"type": "Date",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Message",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"conversationId": {
"type": "String",
"required": true
},
"from": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"to": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"patient": {
"type": "Pointer",
"required": true,
"targetClass": "PatientProfile"
},
"body": {
"type": "String",
"required": true
},
"attachments": {
"type": "Array",
"required": false
},
"isRead": {
"type": "Boolean",
"required": true
},
"sentAt": {
"type": "Date",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Appointment",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"patient": {
"type": "Pointer",
"required": true,
"targetClass": "PatientProfile"
},
"provider": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"startAt": {
"type": "Date",
"required": true
},
"endAt": {
"type": "Date",
"required": true
},
"location": {
"type": "String",
"required": false
},
"status": {
"type": "String",
"required": true
},
"reason": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "AuditLog",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"actor": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"entityType": {
"type": "String",
"required": true
},
"entityId": {
"type": "String",
"required": true
},
"action": {
"type": "String",
"required": true
},
"summary": {
"type": "String",
"required": true
},
"metadata": {
"type": "Object",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
}
]
}Construire avec l'Agent IA
Utilisez l'Agent IA Back4app pour générer une application de Portail Patient à partir de ce modèle, y compris le schéma backend, les ACL et l'intégration frontend de départ.
Créez un backend de Portail Patient sur Back4app avec ce schéma et ce comportement exacts. Schéma: 1. PatientProfile : utilisateur (Pointeur vers Utilisateur, requis), nomComplet (Chaîne, requis), dateDeNaissance (Date, optionnel), contact (Objet), numéroDossierMedical (Chaîne, requis, unique); objectId, createdAt, updatedAt. 2. ProviderProfile : utilisateur (Pointeur vers Utilisateur, requis), spécialité (Chaîne), clinique (Chaîne), contact (Objet); objectId, createdAt, updatedAt. 3. LabResult : patient (Pointeur vers PatientProfile, requis), Provider (Pointeur vers ProviderProfile, requis), typeRapport (Chaîne), donnéesResultat (Objet), déclaréÀ (Date, requis), version (Nombre, par défaut 1), piècesJointes (Array de Fichier), visibilité (Chaîne : uniquement patient, Provider-uniquement, partagé); objectId, createdAt, updatedAt. 4. TreatmentPlan : patient (Pointeur vers PatientProfile, requis), Provider (Pointeur vers ProviderProfile, requis), résumé (Chaîne), détails (Objet), statut (Chaîne : brouillon, actif, terminé), efficaceÀPartirDe (Date), efficaceJusquÀ (Date), version (Nombre); objectId, createdAt, updatedAt. 5. Message : expéditeur (Pointeur vers Utilisateur, requis), destinataire (Pointeur vers Utilisateur, requis), threadId (Chaîne, requis), corps (Chaîne), piècesJointes (Array de Fichier), statut (Chaîne : envoyé, livré, lu), envoyéÀ (Date); objectId, createdAt, updatedAt. 6. Appointment : patient (Pointeur vers PatientProfile, requis), Provider (Pointeur vers ProviderProfile, requis), prévuÀ (Date, requis), statut (Chaîne : prévu, annulé, terminé), emplacement (Chaîne); objectId, createdAt, updatedAt. 7. AuditLog : acteur (Pointeur vers Utilisateur, requis), action (Chaîne, requis), typeEntité (Chaîne, requis), idEntité (Chaîne, requis), payload (Objet, optionnel), createdAt (Date); objectId, createdAt, updatedAt. Sécurité : - Appliquez les ACL pour que les patients ne lisent que leurs enregistrements LabResult et TreatmentPlan. Providers voient les patients assignés. Utilisez le Cloud Code pour des transitions sensibles et pour écrire des entrées AuditLog côté serveur. Protégez les pièces jointes avec des URL signées et un cryptage de stockage. Auth : - Supportez l'inscription pour les patients et Providers ; assignation de rôle ; connexion sécurisée et gestion de session. Comportement : - Le patient se connecte, récupère les dernières versions des LabResult et TreatmentPlans, envoie des messages aux threads Provider, et reçoit des notifications. Les Providers publient des résultats de laboratoire et des plans de traitement ; le système écrit des entrées AuditLog pour les actions de publication. Livrer : - Application Back4app avec schéma, CLPs, ACLs, hooks Cloud Code pour la publication et la journalisation des audits, et intégration frontend de départ pour les vues patient et Provider.
Appuyez sur le bouton ci-dessous pour ouvrir l'Agent avec cette invite de modèle pré-remplie.
Ceci est l'invite de base sans suffixe technologique. Vous pouvez adapter la pile frontend générée par la suite.
Terrain de jeu API
Essayez les endpoints REST et GraphQL contre le schéma du portail patient. 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 technologie
Développez chaque carte pour les étapes d'intégration, les modèles d'état, les exemples de modèles de données et les notes hors ligne.
Flutter Backend du portail patient
React Backend du portail patient
React Natif Backend du portail patient
Next.js Backend du portail patient
JavaScript Backend du portail patient
Android Backend du portail patient
iOS Backend du portail patient
Vue Backend du portail patient
Angular Backend du portail patient
GraphQL Backend du portail patient
REST API Backend du portail patient
PHP Backend du portail patient
.NET Backend du portail patient
Ce que vous obtenez avec chaque technologie
Chaque stack utilise le même schéma de backend et les mêmes contrats API pour le portail patient.
Structure de données patient unifiée
Gérez et accédez facilement à toutes les informations des patients dans un seul schéma.
Messagerie sécurisée pour portail patient
Facilitez la communication sûre entre les patients et les Providers de santé.
Planification de rendez-vous en temps réel
Permettez aux patients de réserver et de gérer leurs rendez-vous en toute transparence.
Suivi complet des résultats de laboratoire
Permettez aux patients de consulter et de suivre leurs résultats de laboratoire en toute sécurité.
Contrôle d'accès pour les données sensibles
Assurez-vous que seules les personnes autorisées peuvent voir les dossiers des patients.
REST/GraphQL APIs pour portail patient
Intégrez facilement avec divers frontends en utilisant des APIs flexibles.
Comparaison des cadres de portail patient
Comparez la vitesse de configuration, le style SDK et le support AI à travers toutes les technologies supportées.
| Framework | Temps de configuration | Avantage du portail patient | Type de SDK | Support AI |
|---|---|---|---|---|
| Configuration rapide (5 min) | Code source unique pour le portail patient sur mobile et web. | Typed SDK | Complet | |
| ~5 min | Tableau de bord web rapide pour le portail patient. | Typed SDK | Complet | |
| Environ 5 min | Application mobile multiplateforme pour le portail patient. | Typed SDK | Complet | |
| Moins de 5 minutes | Application web rendue côté serveur pour le portail patient. | Typed SDK | Complet | |
| ~3 min | Intégration web légère pour le portail patient. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Application native Android pour le portail patient. | Typed SDK | Complet | |
| ~5 min | Application native iOS pour le portail patient. | Typed SDK | Complet | |
| Environ 5 min | Interface web Reactive pour le portail patient. | Typed SDK | Complet | |
| Moins de 5 minutes | Application web entreprise pour le portail patient. | Typed SDK | Complet | |
| Configuration rapide (2 min) | API GraphQL flexible pour le portail patient. | GraphQL API | Complet | |
| ~2 min | Intégration REST API pour le portail patient. | REST API | Complet | |
| Moins de 5 min | Backend PHP côté serveur pour le portail patient. | REST API | Complet | |
| Environ 5 min | Backend .NET pour le portail patient. | Typed SDK | Complet |
Le temps de configuration reflète la durée attendue depuis le démarrage du projet jusqu'à la première connexion du patient et la requête de résultats de laboratoire en utilisant ce schéma de modèle.
Questions Fréquemment Posées
Questions courantes sur la création d'un backend de portail patient avec ce modèle.
Prêt à construire votre application de portail patient ?
Démarrez votre projet de portail patient en quelques minutes. Aucune carte de crédit requise.