Modello Backend dell'App per il Registro Sanitario Personale (PHR)
Documenti medici di proprietà dell'utente, tracciamento degli allergeni e registrazioni delle vaccinazioni
Un backend per il Registro Sanitario Personale pronto per la produzione su Back4app con archiviazione dei documenti medici, storie di allergie e vaccinazioni, modelli di farmaci e laboratori, consenso/condivisione, registri di audit, diagramma ER e un prompt Agente AI per un rapido avvio.
Punti chiave
Questo modello ti offre un backend PHR incentrato sull'utente con archivio documentale, allergie, immunizzazioni, farmaci, risultati di laboratorio, oggetti di consenso e registri di audit per consentirti di fornire rapidamente app sanitarie con un focus sulla privacy.
- Dati sanitari controllati dall'utente — Metti i pazienti al primo posto: registri e consensi sono di proprietà e controllati dall'account dell'utente, consentendo la condivisione selettiva con Providers.
- Entità cliniche strutturate — Modella allergie, immunizzazioni, farmaci e risultati di laboratorio con campi tipizzati per query precise e visualizzazione UX.
- Caricamento dei documenti e versioning — Archivia PDF, immagini e documenti strutturati con metadati e cronologia dei caricamenti per supportare i flussi di lavoro clinici.
- Condivisione guidata dal consenso — Concedi accesso dettagliato a Provider con oggetti di consenso e permessi a tempo limitato.
- Pronto per il cross-platform — Fornisci portali mobili, web e Provider utilizzando API REST unify e GraphQL con Live Queries per aggiornamenti in tempo reale.
Cos'è il modello di backend dell'app PHR (Personal Health Record)?
Back4app è un backend-as-a-service (BaaS) per una consegna rapida dei prodotti. Il modello di backend dell'app PHR è uno schema pre-costruito per documenti medici, allergie, immunizzazioni, medicinali, risultati di laboratorio, Providers, consensi e log di audit. Collega il tuo frontend (React, Flutter, Next.js e altro) e accelera la consegna.
Ideale per:
Panoramica
Un prodotto PHR moderno ha bisogno di archiviazione sicura incentrata sull'utente per documenti, registri accurati di allergie e vaccinazioni, storia dei medicinali e un modello di consenso per condividere dati con Providers.
Questo modello definisce HealthDocument, Allergy, Immunization, Medication, LabResult, Provider, Consent e AuditLog con regole di proprietà e flussi di lavoro estensibili affinché i team possano implementare rapidamente e in modo conforme le app PHR.
Funzioni principali del PHR
Ogni scheda tecnologica in questo hub utilizza lo stesso schema di backend PHR con HealthDocument, Allergy, Immunization, Medication, LabResult, Provider, Consent e AuditLog.
Caveau di documenti medici
Carica e versiona PDF, immagini e registrazioni strutturate con metadati e puntatori al proprietario.
Tracciamento Allergie e Reactioni
Registra allergeni, Reactioni, gravità e data di insorgenza legati a un proprietario.
Storia di immunizzazione e vaccinazione
Cattura il nome del vaccino, la data di somministrazione, il lotto e il riferimento Provider.
Liste di farmaci e programmi
Memorizza farmaci attivi e storici con dose, frequenza e istruzioni.
Risultati di laboratorio
Memorizza i risultati di laboratorio con valori numerici, unità, intervalli di riferimento e allegati.
Controlli di consenso e condivisione
Concedi accesso specifico a Provider ai registri con scadenza e ambito.
Registri di audit centralized
Registra attore, azione, target e metadata del payload per la tracciabilità.
Perché costruire il tuo backend PHR con Back4app?
Back4app ti offre un'infrastruttura fondamentale per le app PHR in modo che il tuo team possa concentrarsi su UX, esperienze di consenso e integrazioni invece di preoccuparsi dell'infrastruttura backend.
- •Proprietà dei dati orientata all'utente: Implementa regole di proprietà e oggetti di consenso in modo che i pazienti possano mantenere il controllo su chi può visualizzare o scaricare i propri documenti.
- •Archiviazione sicura di documenti e metadati: Carica documenti clinici con metadati, versioni e collegamenti a dati strutturati come laboratori e vaccinazioni.
- •Auditabilità + flessibilità dell'API: Mantieni i registri di audit per eventi di condivisione e modifiche ai documenti, fornendo allo stesso tempo REST e GraphQL per client web e mobile.
Imposta rapidamente un backend PHR focalizzato sulla privacy con archiviazione scalabile, autenticazione e API su tutte le piattaforme.
Vantaggi principali
Un backend PHR che ti aiuta a offrire esperienze sanitarie incentrate sulla privacy mantenendo i dati strutturati e auditabili.
Velocità di immissione sul mercato
Inizia da uno schema PHR completo invece di progettare entità cliniche e flussi di consenso da zero.
Controllo degli accessi centrato sul paziente
Consenti ai pazienti di gestire i consensi e condividere selettivamente i registri con Provider e app.
Modelli di dati interoperabili
Utilizza modelli strutturati di immunizzazione, farmaci e laboratori per integrazioni e analisi.
Permessi dettagliati
Utilizza oggetti ACL/CLP e di consenso in modo che l'accesso sia esplicito e auditabile.
Traccia di audit affidabile
Registra eventi di accesso e condivisione per trasparenza e conformità.
Flusso di avvio assistito da AI
Genera rapidamente scaffolding backend e linee guida per integrazione con un prompt AI pre-costruito.
Pronto a costruire un Registro Personale della Salute incentrato sull'utente?
Lascia che l'AI Agent di Back4app crei lo scaffolding del tuo backend PHR e generi documenti, allergie, immunizzazioni, consensi e registri di audit da un unico prompt.
Gratuito per iniziare — 50 prompt AI Agent/mese, senza necessità di carta di credito
Stack Tecnico
Tutto incluso in questo modello di backend PHR.
Diagramma ER
Modello di relazione tra entità per lo schema di backend PHR.
Schema che copre documenti medici di proprietà dell'utente, allergie, immunizzazioni, farmaci, risultati di laboratorio, consensi e registrazione degli audit.
Visualizza sorgente del diagramma
erDiagram
Profile ||--o{ MedicalDocument : "owns"
Profile ||--o{ Allergy : "has"
Profile ||--o{ Vaccination : "has"
Profile ||--o{ SharedAccess : "grants"
Profile ||--o{ EmergencyContact : "links to"
MedicalDocument }o--|| Profile : "profile"
Vaccination }o--|| Profile : "profile"
Allergy }o--|| Profile : "profile"
SharedAccess }o--|| Profile : "profile"
SharedAccess }o--|| _User : "grantee"
Profile {
String objectId PK
Pointer user FK
String fullName
Date birthDate
String gender
String bloodType
String primaryCareProvider
String notes
Date createdAt
Date updatedAt
}
MedicalDocument {
String objectId PK
Pointer profile FK
File file
String documentType
String title
String description
Array<String> tags
Date uploadedAt
Boolean isShared
Date createdAt
Date updatedAt
}
Allergy {
String objectId PK
Pointer profile FK
String substance
String severity
String reaction
String notes
Date recordedAt
Boolean isActive
Date createdAt
Date updatedAt
}
Vaccination {
String objectId PK
Pointer profile FK
String vaccineName
Date dateAdministered
String dose
String lotNumber
String provider
Date nextDoseDate
Pointer proofDocument FK
Date createdAt
Date updatedAt
}
SharedAccess {
String objectId PK
Pointer profile FK
Pointer grantee FK
String accessLevel
Array<String> scope
Date expiresAt
Pointer createdBy FK
Date createdAt
Date updatedAt
}
EmergencyContact {
String objectId PK
Pointer profile FK
String name
String relationship
String phone
String notes
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
}
Flusso di integrazione
Flusso di runtime tipico per autenticazione, accesso ai record, caricamento dei documenti, concessione del consenso e registrazione degli audit.
Visualizza sorgente del diagramma
sequenceDiagram
participant User
participant App as Personal Health Record (PHR) App
participant Back4app as Back4app Cloud
User->>App: Login with email (patient) or OAuth (clinician)
App->>Back4app: POST /login
Back4app-->>App: Session token + user profile
User->>App: List my vaccinations and allergies
App->>Back4app: GET /classes/Vaccination?where={"profile":{"__type":"Pointer","className":"Profile","objectId":"profileId"}}
Back4app-->>App: Vaccination and Allergy records
User->>App: Upload lab result PDF
App->>Back4app: POST /files -> create MedicalDocument with file pointer
Back4app-->>App: File object + MedicalDocument.objectId
User->>App: Share record with Dr. Lee for 48h
App->>Back4app: POST /classes/SharedAccess with accessLevel and expiresAt
Back4app-->>App: SharedAccess.objectId + notification
Back4app-->>App: Live Query event: MedicalDocument updated by clinician
App-->>User: Notify patient in-app / refresh documents listDizionario dei dati
Riferimento completo a livello di campo per ogni classe nello schema PHR.
| Campo | Tipo | Descrizione | Richiesto |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Automatico |
| user | Pointer<_User> | Linked Back4app user account (patient or caregiver) | |
| fullName | String | Patient full name | |
| birthDate | Date | Date of birth | — |
| gender | String | Gender identity | — |
| bloodType | String | Blood type (e.g. A+, O-) | — |
| primaryCareProvider | String | Name or clinic of primary care provider | — |
| notes | String | Free-text health notes or summary | — |
| createdAt | Date | Auto-generated creation timestamp | Automatico |
| updatedAt | Date | Auto-generated last-update timestamp | Automatico |
10 campi in Profile
Sicurezza e Permessi
Come ACL, CLP, oggetti di consenso e Cloud Code proteggono i registri sanitari personali e la condivisione.
Registri di proprietà del paziente
Imposta la proprietà e ACL in modo che le voci di HealthDocument, Allergy, Immunization, Medication e LabResult siano leggibili e scrivibili solo dal proprietario del record e dai Provider autorizzati.
Condivisione basata sul consenso
Usa la classe Consent per concedere accesso a Provider con ambito ed scadenza espliciti; il Cloud Code applica controlli di consenso su endpoint di lettura/download.
Log di audit solo in aggiunta
Mantieni le voci di AuditLog solo in aggiunta per gli utenti standard; solo flussi di backend fidati o amministratori possono scrivere o gestire log storici.
Schema (JSON)
Definizione dello schema JSON grezzo pronta per essere copiata in Back4app o utilizzata come riferimento per l'implementazione.
{
"classes": [
{
"className": "Profile",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"user": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"fullName": {
"type": "String",
"required": true
},
"birthDate": {
"type": "Date",
"required": false
},
"gender": {
"type": "String",
"required": false
},
"bloodType": {
"type": "String",
"required": false
},
"primaryCareProvider": {
"type": "String",
"required": false
},
"notes": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "MedicalDocument",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"profile": {
"type": "Pointer",
"required": true,
"targetClass": "Profile"
},
"file": {
"type": "File",
"required": true
},
"documentType": {
"type": "String",
"required": true
},
"title": {
"type": "String",
"required": true
},
"description": {
"type": "String",
"required": false
},
"tags": {
"type": "Array",
"required": false
},
"uploadedAt": {
"type": "Date",
"required": true
},
"isShared": {
"type": "Boolean",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Allergy",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"profile": {
"type": "Pointer",
"required": true,
"targetClass": "Profile"
},
"substance": {
"type": "String",
"required": true
},
"severity": {
"type": "String",
"required": true
},
"reaction": {
"type": "String",
"required": true
},
"notes": {
"type": "String",
"required": false
},
"recordedAt": {
"type": "Date",
"required": true
},
"isActive": {
"type": "Boolean",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Vaccination",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"profile": {
"type": "Pointer",
"required": true,
"targetClass": "Profile"
},
"vaccineName": {
"type": "String",
"required": true
},
"dateAdministered": {
"type": "Date",
"required": true
},
"dose": {
"type": "String",
"required": false
},
"lotNumber": {
"type": "String",
"required": false
},
"provider": {
"type": "String",
"required": false
},
"nextDoseDate": {
"type": "Date",
"required": false
},
"proofDocument": {
"type": "Pointer",
"required": false,
"targetClass": "MedicalDocument"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "SharedAccess",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"profile": {
"type": "Pointer",
"required": true,
"targetClass": "Profile"
},
"grantee": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"accessLevel": {
"type": "String",
"required": true
},
"scope": {
"type": "Array",
"required": false
},
"expiresAt": {
"type": "Date",
"required": false
},
"createdBy": {
"type": "Pointer",
"required": true,
"targetClass": "_User"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "EmergencyContact",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"profile": {
"type": "Pointer",
"required": true,
"targetClass": "Profile"
},
"name": {
"type": "String",
"required": true
},
"relationship": {
"type": "String",
"required": true
},
"phone": {
"type": "String",
"required": true
},
"notes": {
"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
}
}
}
]
}Costruisci con AI Agent
Usa il Back4app AI Agent per generare un'app reale di Personal Health Record da questo template, inclusi frontend, backend, autenticazione e flussi di consenso.
Crea un backend per il Registro Sanitario Personale (PHR) su Back4app con questo schema e comportamento esatti. Schema: 1. HealthDocument: proprietario (Puntatore a Utente, richiesto), titolo (Stringa, richiesto), file (File, richiesto), tag (Array, facoltativo), versione (Numero, predefinita 1), createdAt, updatedAt (sistema). 2. Allergia: proprietario (Puntatore a Utente, richiesto), sostanza (Stringa, richiesta), Reactione (Stringa, facoltativa), gravità (Stringa: lieve, moderata, grave, richiesta), dataInizio (Data, facoltativa). 3. Immunizzazione: proprietario (Puntatore a Utente, richiesto), nomeVaccino (Stringa, richiesta), somministratoIl (Data, richiesta), numeroLotto (Stringa, facoltativa), Provider (Puntatore a Provider, facoltativa). 4. Farmaco: proprietario (Puntatore a Utente, richiesto), nome (Stringa, richiesta), dose (Stringa, facoltativa), frequenza (Stringa, facoltativa), istruzioni (Stringa, facoltativa), attivo (Booleano, predefinito true). 5. RisultatoDiLaboratorio: proprietario (Puntatore a Utente, richiesto), nomeTest (Stringa, richiesta), valore (Numero o Stringa), unità (Stringa, facoltativa), intervalloDiRiferimento (Stringa, facoltativa), data (Data, richiesta), allegato (Puntatore a HealthDocument, facoltativo). 6. Provider: nome (Stringa, richiesta), systemId (Stringa, facoltativa), contatto (Oggetto, facoltativo). 7. Consenso: proprietario (Puntatore a Utente, richiesto), Provider (Puntatore a Provider, richiesto), ambito (Array di Stringhe: [documenti, allergie, immunizzazioni, farmaci, laboratori]), scadeIl (Data, facoltativa), concessoDa (Puntatore a Utente o sistema). 8. AuditLog: attore (Puntatore a Utente, richiesto), azione (Stringa, richiesta), tipoEntità (Stringa, richiesta), idEntità (Stringa, richiesta), payload (Oggetto, facoltativo); createdAt, updatedAt (sistema). Sicurezza: - Utilizzare ACL/CLP in modo che solo i proprietari e i Provider consenzienti possano accedere ai record. Il Cloud Code valida il Consenso prima di consentire la lettura/scaricamento da parte di Provider. Le voci di AuditLog sono solo append-only per utenti standard. Autenticazione: - Registrazione, login, logout per gli account utente. Supporto per account Provider con privilegi limitati. Comportamento: - Autenticare, elencare i record utente, caricare HealthDocument, creare voci strutturate di Allergia/Immunizzazione/Farmaco/RisultatoDiLaboratorio, creare Consenso per condividere record selezionati con un Provider, e scrivere voci di AuditLog per eventi critici. Consegna: - App Back4app con schema, ACL, CLP; frontend per vault documenti sicuri, cronologie di allergie e immunizzazioni, elenchi di farmaci, visualizzazioni di risultati di laboratorio, flussi di consenso Provider, e storia audit.
Premi il pulsante qui sotto per aprire l'Agente con questo modello di prompt pre-compilato.
Questo è il prompt di base senza un suffisso tecnologico. Puoi adattare successivamente lo stack frontend generato.
API Playground
Prova gli endpoint REST e GraphQL contro lo schema PHR. Le risposte utilizzano dati fittizi e non richiedono un account Back4app.
Utilizza lo stesso schema di questo modello.
Scegli la tua tecnologia
Espandi ogni scheda per i passaggi di integrazione, i modelli di stato, esempi di modelli di dati e note offline.
Flutter PHR Backend
React PHR Backend
React Nativo PHR Backend
Next.js PHR Backend
JavaScript PHR Backend
Android PHR Backend
iOS PHR Backend
Vue PHR Backend
Angular PHR Backend
GraphQL PHR Backend
REST API PHR Backend
PHP PHR Backend
.NET PHR Backend
Cosa ottieni con ogni tecnologia
Ogni stack utilizza lo stesso schema backend PHR e contratti API.
Struttura dati unificata registrazione della salute personale
Uno schema predefinito per documenti e registri medici.
Condivisione sicura per registrazione della salute personale
Condividi facilmente informazioni sulla salute con Provider garantendo la privacy.
Log di audit completi per registrazione della salute personale
Monitora l'accesso e le modifiche ai dati sanitari sensibili.
REST/GraphQL API per registrazione della salute personale
Accesso API flessibile per integrarsi senza problemi con vari frontend.
Aggiornamenti in tempo reale per registrazione della salute personale
Notifiche istantanee su modifiche ai registri sanitari e allo stato.
Estensibilità per registrazione della salute personale
Aggiungi facilmente funzionalità e moduli personalizzati per soddisfare esigenze specifiche.
Confronto del framework per la registrazione della salute personale
Confronta la velocità di configurazione, lo stile SDK e il supporto AI tra tutte le tecnologie supportate.
| Framework | Tempo di Configurazione | Vantaggio della registrazione della salute personale | Tipo di SDK | Supporto AI |
|---|---|---|---|---|
| Meno di 5 minuti | Single codebase per la registrazione della salute personale su mobile e web. | Typed SDK | Completo | |
| ~3–7 min | Dashboard web veloce per la registrazione della salute personale. | Typed SDK | Completo | |
| Configurazione rapida (5 min) | App mobile cross-platform per la registrazione della salute personale. | Typed SDK | Completo | |
| ~5 min | App web renderizzata dal server per la registrazione della salute personale. | Typed SDK | Completo | |
| ~3 min | Integrazione web leggera per la registrazione della salute personale. | Typed SDK | Completo | |
| Meno di 5 minuti | App nativa Android per la registrazione della salute personale. | Typed SDK | Completo | |
| ~3–7 min | App nativa iOS per la registrazione della salute personale. | Typed SDK | Completo | |
| Configurazione rapida (5 min) | Interfaccia web Reactive per la registrazione della salute personale. | Typed SDK | Completo | |
| ~5 min | App web per le imprese per la registrazione della salute personale. | Typed SDK | Completo | |
| Configurazione rapida (2 min) | API flessibile GraphQL per la registrazione della salute personale. | GraphQL API | Completo | |
| ~2 min | Integrazione REST API per la registrazione della salute personale. | REST API | Completo | |
| Meno di 5 min | Backend PHP lato server per la registrazione della salute personale. | REST API | Completo | |
| Configurazione rapida (5 min) | Backend .NET per la registrazione della salute personale. | Typed SDK | Completo |
Il tempo di configurazione riflette la durata prevista dal bootstrap del progetto al primo caricamento del documento e al flusso di consenso utilizzando questo schema di template.
Domande Frequenti
Domande comuni sulla costruzione di un backend per il Personal Health Record con questo modello.
Pronto per costruire la tua app per la cartella sanitaria personale?
Inizia il tuo progetto di cartella sanitaria personale in pochi minuti. Nessuna carta di credito richiesta.