Modèle de Backend d'Application de Surveillance à Distance des Patients
Fournir un accès sécurisé aux données des patients à partir de dispositifs médicaux IoT à domicile pour une surveillance efficace
Un backend d'application RPM prêt pour la production sur Back4app pour un accès sécurisé aux données des patients depuis des dispositifs IoT, y compris les journaux de surveillance et les messages des utilisateurs, avec un journal d'audit centralisé. Il comprend un diagramme ER, un dictionnaire de données, un schéma JSON, un espace de jeu API, et une invite AI Agent pour un démarrage rapide.
Points clés
Livrez un backend pour la surveillance à distance des patients avec des contrôles d'accès sécurisés, la récupération de données IoT et des journaux de surveillance afin que votre équipe produit puisse se concentrer sur l'expérience utilisateur et la conformité.
- Modèle de données IoT d'abord — Conservez l'identité du patient, les données des appareils et les journaux de surveillance modélisés de manière distincte mais liés pour l'authentification et l'autorisation.
- Messagerie sécurisée — Messages en fil entre patients et cliniciens avec des accusés de lecture clairs et des contrôles de conservation.
- Données d'appareil versionnées — Stockez les données des appareils avec des métadonnées de version, garantissant que les lectures et notifications mises à jour sont suivies de manière efficace.
- Suivi du cycle de vie des journaux — Gérez les journaux de surveillance de manière efficace, en documentant les interactions des utilisateurs et l'état des dispositifs au fil du temps.
- Journalisation d'audit conforme — AuditLog centralisé capture les événements sensibles pour révision et conformité aux réglementations sanitaires.
Qu'est-ce que le modèle de backend d'application RPM ?
Back4app est un backend en tant que service (BaaS) pour une livraison rapide. Le modèle de backend d'application RPM fournit un schéma préconçu pour les profils de patients, les données des dispositifs IoT, les journaux de surveillance, la messagerie sécurisée et les journaux d'audit. Connectez votre frontend préféré (React, Flutter, Next.js, et plus) et livrez plus rapidement.
Meilleur pour :
Aperçu
Les applications RPM nécessitent des frontières de données solides, des transactions auditées et une livraison fiable d'informations sensibles sur les patients collectées à partir de dispositifs IoT.
Ce modèle définit les classes PatientProfile, DeviceData, MonitoringLog, UserMessage et AuditLog avec des règles de propriété et basées sur les rôles afin que les équipes puissent mettre en œuvre des applications RPM rapidement et en toute sécurité.
Fonctionnalités principales de l'application RPM
Chaque carte technologique dans ce hub utilise le même schéma backend d'application RPM comprenant PatientProfile, DeviceData, MonitoringLog, UserMessage et AuditLog.
Profil du patient et authentification
PatientProfile stocke l'identité, les coordonnées et les préférences avec un lien vers l'utilisateur authentifié.
Données d'appareil versionnées
DeviceData stocke le type d'appareil, les données brutes, l'enregistréÀ, la version et la provenance de l'utilisateur.
Gestion des journaux de surveillance
Le journal de surveillance suit les interactions des patients documentées chronologiquement avec des statuts.
Messagerie sécurisée entre cliniciens et patients
UserMessage facilite les échanges entre les Provider et les patients avec support d'attachement et statut de livraison/lecture.
Journaux d'audit centralisés
AuditLog capture des informations sur les actions effectuées par les utilisateurs, garantissant une responsabilité claire.
Pourquoi construire votre backend d'application RPM avec Back4app?
Back4app gère les éléments essentiels du backend—sécurité, persistance des données, APIs et mises à jour en temps réel—vous permettant de prioriser l'expérience utilisateur, la confidentialité et l'intégration clinique.
- •Transfert sécurisé des données des patients: L'authentification intégrée et les contrôles d'accès vous permettent de limiter la visibilité à des utilisateurs spécifiques pour chaque lecture de dispositif, journal de surveillance ou message.
- •Suivi des audits et de la provenance: AuditLog enregistre qui a accédé, publié ou modifié des données sensibles, garantissant la conformité réglementaire.
- •Messagerie et notifications en temps réel: Des messages en fil, des pièces jointes et des mises à jour en direct facultatives facilitent une communication fluide entre les patients et les Providers de santé.
Déployez rapidement un backend d'application RPM sécurisé et concentrez-vous sur l'itération des flux de travail cliniques plutôt que sur les complexités du backend.
Avantages principaux
Un backend d'application RPM qui priorise la confidentialité des données, la provenance et la livraison agile.
Expérience patient plus rapide
Expédiez rapidement les vues de données des dispositifs, les fonctionnalités de surveillance et les messages sécurisés en utilisant une structure backend pré-validée.
Forte provenance des données
Maintenez la version des données des dispositifs et des journaux afin que les actions cliniques soient vérifiables.
Permissions granulaires
Protégez les dossiers sensibles avec un contrôle d'accès basé sur les rôles, garantissant que seules les personnes autorisées peuvent consulter des données spécifiques.
Messagerie intégrée
La messagerie en fil et les mises à jour en temps réel améliorent la communication entre les patients et les professionnels de la santé.
Journalisation conforme aux exigences?
L'AuditLog centralisé préserve des enregistrements détaillés pour la conformité en santé et l'intelligence d'affaires.
Configuration initiale assistée par IA
Démarrez le développement avec une invite de l'agent IA sélectionnée pour structurer le schéma, les autorisations et le code d'intégration de base.
Prêt à créer une application RPM sécurisée?
Permettez à l'agent IA Back4app de structurer l'arrière-plan de votre application RPM, en générant des profils de patients, des données d'appareils, des journaux de surveillance et des journaux d'audit à partir d'une seule invite.
Gratuit pour commencer — 50 invites d'agent IA/mois, aucune carte de crédit requise
Technologie
Tout inclus dans ce modèle de backend d'application RPM.
Diagramme ER
Modèle de relation d'entité pour le schéma backend de l'application RPM.
Schéma couvrant les profils de patients, les données des appareils IoT, les journaux de surveillance, les messages et les enregistrements de journal d'audit.
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 récupération de données, les mises à jour de surveillance et la messagerie.
Voir la source du diagramme
sequenceDiagram
participant User as Patient
participant App as RPM Dashboard App
participant Clinician
participant Back4app as Back4app Cloud
User->>App: Sign in with email or SSO
App->>Back4app: POST /login (credentials/SSO token)
Back4app-->>App: Return Session Token + Patient context
User->>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)
User->>App: View active Treatment Plan
App->>Back4app: GET /classes/TreatmentPlan?where={"patient":Pointer("PatientProfile","p123"),"status":"active"}
Back4app-->>App: TreatmentPlan object
User->>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-->>User: Real-time notification (new message / result available)
Clinician->>Back4app: Update LabResult (finalize)
Back4app-->>App: LiveQuery event -> App fetches updated LabResult
App-->>User: 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 de l'application RPM.
| 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 protègent les données des patients, les données IoT, les messages et les journaux d'audit.
Accès et propriété basés sur les rôles
Appliquez des ACL afin que les patients puissent consulter leurs propres données de dispositif et journaux de surveillance, tandis que les cliniciens peuvent voir des données pertinentes pour leurs patients assignés ; les CLP empêchent les actions non autorisées sur les classes.
Chargements et pièces jointes cryptés
Stockez des données sensibles en toute sécurité avec le cryptage et utilisez des URL signées pour un accès sécurisé à de gros fichiers.
Trails d'audit en ajout uniquement
Enregistrez des événements AuditLog à partir de fonctions côté serveur pour protéger les données de conformité historiques contre la falsification.
Schéma (JSON)
Définition de schéma JSON brute prête à être copiée dans Back4app ou utilisée comme référence de mise en œuvre.
{
"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 RPM à partir de ce modèle, y compris le schéma backend, les contrôles d'accès et l'intégration du frontend de démarrage.
Créez un backend d'application RPM sur Back4app avec ce schéma et ce comportement. Schéma : 1. PatientProfile : utilisateur (Pointeur vers Utilisateur, requis), nomComplet (Chaîne, requis), dateNaissance (Date, optionnel), contact (Objet), numéroDossierMédical (Chaîne, requis, unique) ; objectId, createdAt, updatedAt. 2. DeviceData : patient (Pointeur vers PatientProfile, requis), typeAppareil (Chaîne), donnéesPayload (Objet), enregistréLe (Date, requis), version (Nombre, par défaut 1) ; objectId, createdAt, updatedAt. 3. MonitoringLog : patient (Pointeur vers PatientProfile, requis), données (Pointeur vers DeviceData, requis), horodatage (Date, requis), statut (Chaîne, requis) ; objectId, createdAt, updatedAt. 4. UserMessage : expéditeur (Pointeur vers Utilisateur, requis), destinataire (Pointeur vers Utilisateur, requis), threadId (Chaîne, requis), corps (Chaîne), piècesJointes (Tableau de Fichiers), statut (Chaîne : envoyé, livré, lu), envoyéLe (Date) ; objectId, createdAt, updatedAt. 5. 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 des ACL afin que les patients ne puissent lire que leurs enregistrements DeviceData et MonitoringLog. Les cliniciens voient les patients qui leur sont assignés. Utilisez le Cloud Code pour les transitions sensibles et pour écrire des entrées AuditLog côté serveur. Sécurisez vos données par chiffrement. Auth : - Supportez l'inscription pour les patients et les cliniciens ; attribution de rôles ; connexion sécurisée et gestion des sessions. Comportement : - Le patient se connecte, récupère les dernières DeviceData et MonitoringLogs, envoie des messages aux fils de discussion des cliniciens et reçoit des notifications. Les cliniciens publient des données de dispositif et des journaux de surveillance ; le système écrit des entrées AuditLog pour les actions de publication. Livraison : - Application Back4app avec schéma, CLPs, ACLs, crochets Cloud Code pour la publication et l'audit, et intégration frontend de démarrage pour les vues patient et clinicien.
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 points de terminaison REST et GraphQL contre le schéma de l'application RPM. 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èle de données et les notes hors ligne.
Flutter RPM Application Backend
React RPM Application Backend
React Natif RPM Application Backend
Next.js RPM Application Backend
JavaScript RPM Application Backend
Android RPM Application Backend
iOS RPM Application Backend
Vue RPM Application Backend
Angular RPM Application Backend
GraphQL RPM Application Backend
REST API RPM Application Backend
PHP RPM Application Backend
.NET RPM Application Backend
Ce que vous obtenez avec chaque technologie
Chaque pile utilise le même schéma de backend d'application RPM et les mêmes règles d'API.
Schéma de profil patient pré-construit
Gérez et accédez facilement aux données des patients avec une structure tableau de bord rpm unifiée.
Intégration des données des appareils IoT
Connectez et surveillez sans effort les appareils IoT pour des insights tableau de bord rpm en temps réel.
Messagerie sécurisée pour tableau de bord rpm
Communiquez en toute sécurité avec les patients et Provider via une messagerie cryptée.
Journaux de surveillance complets
Suivez les activités des patients et les métriques de santé avec des journaux détaillés pour tableau de bord rpm.
Support des API REST/GraphQL
Options d'API flexibles pour interagir efficacement avec votre backend tableau de bord rpm.
Journaux d'audit pour conformité
Maintenez la conformité avec des traces d'audit détaillées pour toutes les activités tableau de bord rpm.
Comparaison du cadre Rpm Dashboard
Évaluez la vitesse de configuration, les styles SDK et le support AI dans toutes les technologies prises en charge.
| Framework | Temps de configuration | Avantage du Rpm Dashboard | Type de SDK | Support IA |
|---|---|---|---|---|
| ~3–7 min | Code source unique pour le tableau de bord rpm sur mobile et web. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Tableau de bord web rapide pour le tableau de bord rpm. | Typed SDK | Complet | |
| ~5 min | Application mobile multiplateforme pour le tableau de bord rpm. | Typed SDK | Complet | |
| Environ 5 min | Application web rendue par le serveur pour le tableau de bord rpm. | Typed SDK | Complet | |
| ~3 min | Intégration web légère pour le tableau de bord rpm. | Typed SDK | Complet | |
| ~3–7 min | Application Android native pour le tableau de bord rpm. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Application iOS native pour le tableau de bord rpm. | Typed SDK | Complet | |
| ~5 min | Interface web Reactive pour le tableau de bord rpm. | Typed SDK | Complet | |
| Environ 5 min | Application web d’entreprise pour le tableau de bord rpm. | Typed SDK | Complet | |
| Configuration rapide (2 min) | API GraphQL flexible pour le tableau de bord rpm. | GraphQL API | Complet | |
| ~2 min | Intégration REST API pour le tableau de bord rpm. | REST API | Complet | |
| Moins de 5 min | Backend PHP côté serveur pour le tableau de bord rpm. | REST API | Complet | |
| ~5 min | Backend .NET pour le tableau de bord rpm. | Typed SDK | Complet |
Le temps de configuration indique la durée estimée entre l'initialisation du projet et la première connexion patient et la requête des données de périphérique utilisant ce schéma de modèle.
Questions Fréquemment Posées
Demandes courantes concernant la création d'un backend d'application RPM avec ce modèle.
Prêt à construire votre application RPM ?
Lancez votre projet d'application RPM en seulement quelques minutes. Pas de carte de crédit nécessaire.