Modèle de backend d'application de gestion des plaies
Gérer les profils de plaies, les plans de traitement et permettre la messagerie sécurisée entre cliniciens et patients
Un backend de gestion des plaies prêt pour la production sur Back4app avec une livraison sécurisée des profils de plaies, la gestion des plans de traitement, la messagerie entre cliniciens, la liaison des rendez-vous et des journaux d'audit centralisés. Inclut un diagramme ER, un dictionnaire de données, un schéma JSON, un terrain de jeu API et un prompt Agent IA pour un démarrage rapide.
Principaux enseignements
Expédiez un backend destiné aux cliniciens avec des contrôles d'accès sécurisés, des profils de plaies versionnés, des historiques de plans de traitement, une messagerie en fil et des pistes de vérification, 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 — Gardez l'identité du patient, les profils de plaies, les plans de traitement 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 les patients et les Provider avec des accusés de réception clairs et des contrôles de conservation.
- Profils de plaies versionnés — Stockez les profils de plaies avec des métadonnées de provenance et de version afin que les informations et les plans de traitement mis à jour soient suivis.
- Cycle de vie du plan de traitement — Gérez les brouillons de plan de traitement, les approbations par les Provider, la reconnaissance par le patient et l'historique des versions.
- Journalisation prête pour la conformité — La classe AuditLog centralisée enregistre les événements sensibles pour examen, suivi et conformité.
Qu'est-ce que le modèle de backend de l'application de gestion des soins des plaies ?
Back4app est un backend en tant que service (BaaS) pour une livraison rapide. Le modèle de backend de l'application de gestion des soins des plaies est un schéma préconstruit pour les profils de patients, les profils de plaies, 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 expédiez plus rapidement.
Meilleur pour :
Aperçu
La gestion des soins des plaies nécessite de fortes limites de données, des modifications auditées et une livraison fiable d'éléments sensibles tels que les profils de plaies et les plans de traitement.
Ce modèle définit PatientProfile, WoundProfile, TreatmentPlan, Message, ProviderProfile, Appointment et AuditLog avec des règles de propriété et basées sur les rôles afin que les équipes puissent mettre en œuvre rapidement et en toute sécurité des applications de gestion des soins des plaies.
Fonctionnalités principales de gestion des soins des blessures
Chaque carte technologique dans ce hub utilise le même schéma de gestion des soins des blessures avec PatientProfile, WoundProfile, TreatmentPlan, Message, ProviderProfile, Appointment et AuditLog.
Profil du patient & authentification
PatientProfile stocke l'identité, les coordonnées et les préférences avec un lien vers l'utilisateur authentifié.
Profils de blessures détaillés
WoundProfile stocke le patient, les détails de la blessure, le statut et les évaluations pour une gestion continue.
Cycle de vie du plan de traitement
TreatmentPlan stocke le contenu du plan, l'approbateur Provider, le statut (brouillon, actif, terminé) et la fenêtre de validité.
Messagerie sécurisée entre clinicien et patient
Le message prend en charge les fils de discussion, les pièces jointes, les pointeurs d'expéditeur/récepteur 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 visite.
Journaux d'audit centralisés
AuditLog capture l'identité de l'acteur, le type d'action, le contexte d'entité et les métadonnées des charges utiles pour la conformité.
Pourquoi construire votre application de gestion des soins des blessures avec Back4app ?
Back4app gère les fondamentaux du backend—sécurité, persistance, APIs et temps réel—vous permettant ainsi de vous concentrer sur l'expérience des cliniciens, les workflows de confidentialité et l'intégration clinique.
- •Livraison sécurisée des données cliniques: Les modèles d'authentification intégrés et ACL/CLP vous permettent de contrôler exactement quels utilisateurs peuvent voir chaque profil de blessure, 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 thread, des pièces jointes et des mises à jour en direct optionnelles rendent les conversations entre cliniciens et patients fluides et opportunes.
Déployez rapidement un backend sécurisé de gestion des soins des blessures et itérez sur les workflows cliniques au lieu de vous soucier de la plomberie backend.
Avantages principaux
Un backend de gestion des soins des blessures qui met l'accent sur la confidentialité, la provenance et la livraison rapide.
Expériences des cliniciens accélérées
Expédiez plus rapidement les visualiseurs de profil de blessure, la livraison de plan de traitement et la messagerie sécurisée en réutilisant un contrat backend validé.
Provenance des données solide
Versionner les profils de blessure et les plans de traitement afin que les modifications cliniques soient auditables et traçables.
Permissions granulaires
Protéger les éléments sensibles avec des contrôles 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 en fil et des pièces jointes avec des mises à jour en temps réel facultatives améliorent la collaboration entre cliniciens et patients.
Journalisation prête pour la conformité
AuditLog centralisé prend en charge les revues, les enquêtes sur les incidents et les rapports de conformité.
Bootstrap assisté par IA
Démarrer le développement avec une invite d'Agent IA sélectionnée qui structure le schéma, les ACL et le code d'intégration de base.
Prêt à créer une application de gestion des soins des plaies sécurisée ?
Laissez l'Agent IA de Back4app structurer votre backend de gestion des soins des plaies et générer des profils de patients, des profils de plaies, 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
Pile technique
Tout est inclus dans ce modèle de backend de gestion des soins des plaies.
Diagramme ER
Modèle de relation d'entité pour le schéma backend de gestion des plaies.
Schéma couvrant les profils de patients, les profils de plaies, les plans de traitement, la messagerie, les rendez-vous et la journalisation des audits.
Voir la source du diagramme
erDiagram
PatientProfile ||--o{ WoundAssessment : "assesses"
PatientProfile ||--o{ TreatmentPlan : "receives"
PatientProfile ||--o{ Message : "context for"
PatientProfile ||--o{ Appointment : "scheduled in"
WoundAssessment ||--o{ TreatmentPlan : "applies to"
_User ||--o{ Message : "sends/receives"
_User ||--o{ TreatmentPlan : "authors"
_User ||--o{ Appointment : "provides"
_User ||--o{ WoundAssessment : "performs"
PatientProfile {
String objectId PK
Pointer user FK
String medicalRecordNumber
String displayName
Date dateOfBirth
String primaryClinic
Boolean isActive
Date createdAt
Date updatedAt
}
WoundAssessment {
String objectId PK
Pointer patient FK
Pointer assessedBy FK
String location
String woundType
String size
String status
String notes
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 de profil de plaies, les mises à jour de plan de traitement et la messagerie.
Voir la source du diagramme
sequenceDiagram
participant Patient
participant App as Wound Care Management 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 Wound Assessment Dashboard
App->>Back4app: GET /classes/PatientProfile?where={"user":Pointer("_User", "u123")}
Back4app-->>App: PatientProfile object
App->>Back4app: GET /classes/WoundAssessment?where={"patient":Pointer("PatientProfile","p123")}
Back4app-->>App: List of WoundAssessment
Patient->>App: Create new Wound Assessment
App->>Back4app: POST /classes/WoundAssessment (location, woundType, size, status)
Back4app-->>App: WoundAssessment objectId
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 WoundAssessment update
App-->>Patient: Real-time notification (new message / assessment update)
Clinician->>Back4app: Update Wound Assessment
Back4app-->>App: LiveQuery event -> App fetches updated WoundAssessment
App-->>Patient: Alert: "Wound assessment updated"Dictionnaire des données
Référence complète au niveau des champs pour chaque classe dans le schéma de gestion des soins des plaies.
| 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 chiffrement protègent les profils de blessures, 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 afin que les patients puissent voir leurs propres profils de blessures 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 d'enregistrements de blessures, PDF) derrière des URL signées et utiliser le chiffrement au niveau du stockage pour une protection au repos.
Journaux d'audit uniquement appendables
Écrire les entrées d'AuditLog depuis le Cloud Code côté serveur pour garantir 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": "WoundAssessment",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"patient": {
"type": "Pointer",
"required": true,
"targetClass": "PatientProfile"
},
"assessedBy": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"location": {
"type": "String",
"required": true
},
"woundType": {
"type": "String",
"required": true
},
"size": {
"type": "String",
"required": true
},
"status": {
"type": "String",
"required": true
},
"notes": {
"type": "String",
"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 AI
Utilisez l'agent AI de Back4app pour générer une application de gestion des soins des plaies à partir de ce modèle, y compris le schéma backend, les ACL et l'intégration frontend de démarrage.
Créez un backend de gestion des soins des plaies sur Back4app avec ce schéma et ce comportement exact. Schéma: 1. PatientProfile : utilisateur (Pointeur vers User, requis), nomComplet (String, requis), dob (Date, optionnel), contact (Objet), numeroDossierMedical (String, requis, unique); objectId, createdAt, updatedAt. 2. WoundProfile : patient (Pointeur vers PatientProfile, requis), detailsPlaie (Objet), statut (String), évaluation (Objet); objectId, createdAt, updatedAt. 3. TreatmentPlan : patient (Pointeur vers PatientProfile, requis), Provider (Pointeur vers ProviderProfile, requis), résumé (String), détails (Objet), statut (String : draft, active, completed), effectifÀ (Date), effectifJusqu'à (Date), version (Number); objectId, createdAt, updatedAt. 4. Message : expéditeur (Pointeur vers User, requis), destinataire (Pointeur vers User, requis), threadId (String, requis), corps (String), piècesJointes (Tableau de Fichier), statut (String : envoyé, livré, lu), envoyéÀ (Date); objectId, createdAt, updatedAt. 5. ProviderProfile : utilisateur (Pointeur vers User, requis), spécialité (String), clinique (String), contact (Objet); objectId, createdAt, updatedAt. 6. Appointment : patient (Pointeur vers PatientProfile, requis), Provider (Pointeur vers ProviderProfile, requis), prévuÀ (Date, requis), statut (String : prévu, annulé, terminé), emplacement (String); objectId, createdAt, updatedAt. 7. AuditLog : acteur (Pointeur vers User, requis), action (String, requis), typeEntité (String, requis), idEntité (String, requis), chargeUtile (Objet, optionnel), createdAt (Date); objectId, createdAt, updatedAt. Sécurité : - Appliquer les ACL afin que les patients ne lisent que leurs profils de plaie et leurs plans de traitement. Providers voient les patients assignés. Utilisez le code cloud pour les transitions sensibles et pour écrire des entrées de journal d'audit côté serveur. Protégez les pièces jointes avec des URL signées et le chiffrement de stockage. Authentification : - Supporter l'inscription pour les patients et Providers ; attribution des rôles ; connexion sécurisée et gestion des sessions. Comportement : - Le patient se connecte, récupère les derniers profils de plaie et plans de traitement, envoie des messages aux fils Provider, et reçoit des notifications. Providers publient des profils de plaie et des plans de traitement ; le système écrit des entrées de journal d'audit pour les actions de publication. Livrer : - Application Back4app avec schéma, CLPs, ACLs, crochets de code cloud pour la publication et l'audit, et intégration frontend de démarrage 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.
API Playground
Essayez les méthodes REST et GraphQL contre le schéma de gestion des plaies. 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 motifs d'état, les exemples de modèle de données et les notes hors ligne.
Flutter Gestion des soins des plaies Backend
React Gestion des soins des plaies Backend
React Natif Gestion des soins des plaies Backend
Next.js Gestion des soins des plaies Backend
JavaScript Gestion des soins des plaies Backend
Android Gestion des soins des plaies Backend
iOS Gestion des soins des plaies Backend
Vue Gestion des soins des plaies Backend
Angular Gestion des soins des plaies Backend
GraphQL Gestion des soins des plaies Backend
REST API Gestion des soins des plaies Backend
PHP Gestion des soins des plaies Backend
.NET Gestion des soins des plaies Backend
Ce que vous obtenez avec chaque technologie
Chaque stack utilise le même schéma de gestion des plaies et les mêmes contrats API.
Profils de patients unifiés soins des plaies
Profils de patients complets pour une gestion efficace des plaies.
Messagerie sécurisée pour soins des plaies
Communication confidentielle entre les patients et les Providers de santé.
Plans de traitement personnalisables pour soins des plaies
Créez et modifiez facilement des plans de traitement adaptés à chaque patient.
Planification de rendez-vous pour soins des plaies
Réservation de rendez-vous simplifiée pour améliorer les soins aux patients.
Journaux d'audit pour soins des plaies
Journaux détaillés pour suivre les interactions avec les patients et l'historique des traitements.
REST/GraphQL APIs pour soins des plaies
APIs flexibles pour s'intégrer à n'importe quelle technologie frontend.
Comparaison du cadre de soins des plaies
Comparez la vitesse de configuration, le style SDK et le support AI dans toutes les technologies prises en charge.
| Framework | Temps de configuration | Avantage des soins des plaies | Type de SDK | Support AI |
|---|---|---|---|---|
| Moins de 5 minutes | Base de code unique pour les soins des plaies sur mobile et web. | Typed SDK | Complet | |
| ~3–7 min | Tableau de bord web rapide pour les soins des plaies. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Application mobile multiplateforme pour les soins des plaies. | Typed SDK | Complet | |
| ~5 min | Application web renderisée par serveur pour les soins des plaies. | Typed SDK | Complet | |
| ~3–5 min | Intégration web légère pour les soins des plaies. | Typed SDK | Complet | |
| Moins de 5 minutes | Application native Android pour les soins des plaies. | Typed SDK | Complet | |
| ~3–7 min | Application native iOS pour les soins des plaies. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Interface utilisateur web Reactive pour les soins des plaies. | Typed SDK | Complet | |
| ~5 min | Application web d'entreprise pour les soins des plaies. | Typed SDK | Complet | |
| Moins de 2 min | API GraphQL flexible pour les soins des plaies. | GraphQL API | Complet | |
| Configuration rapide (2 min) | Intégration REST API pour les soins des plaies. | REST API | Complet | |
| ~3 min | Backend PHP côté serveur pour les soins des plaies. | REST API | Complet | |
| Configuration rapide (5 min) | Backend .NET pour les soins des plaies. | Typed SDK | Complet |
Le temps de configuration reflète la durée attendue depuis le démarrage du projet jusqu'à la première connexion patient et la requête de profil de plaie en utilisant ce schéma de modèle.
Questions Fréquemment Posées
Questions courantes sur la création d'un backend de gestion des soins des plaies avec ce modèle.
Prêt à construire votre application de gestion des soins des plaies ?
Démarrez votre projet de gestion des soins des plaies en quelques minutes. Aucune carte de crédit requise.