Modèle de backend d'information en radiologie
Gérez les commandes d'imagerie, les métadonnées d'étude, les flux de travail de modalité et les rapports de radiologistes depuis un seul backend
Un backend d'information en radiologie prêt pour la production sur Back4app pour les demandes d'imagerie, les métadonnées d'étude DICOM, les flux de travail de lecture par des spécialistes et la livraison de rapports. Utilisez-le pour accélérer les portails de radiologie, les listes de travail et les intégrations hospitalières sur le web et mobile.
Points clés
Ce modèle vous offre un backend axé sur la radiologie pour les flux de travail de l'admission au rapport afin que votre équipe puisse expédier les logiciels d'opérations d'imagerie plus rapidement avec des contrats de données cohérents.
- Modèle de données axé sur l'imagerie — Modélisez les demandes, les études, les radiologues et les rapports dans une structure conviviale pour les flux de travail conçue pour les opérations de radiologie.
- Suivi des métadonnées DICOM — Stockez les métadonnées clés au niveau de l'étude telles que le numéro d'accés, la modalité, l'UID d'étude, la partie du corps et les horodatages d'acquisition pour l'indexation et la recherche.
- Support du cycle de vie du rapport — Gérez les brouillons, les rapports en révision, les rapports modifiés et les rapports finalisés avec suivi des affectations et des délais.
- Audit et traçabilité — Suivez qui a créé, mis à jour, examiné ou finalisé le contenu diagnostique pour soutenir la gouvernance et le dépannage.
- APIs multiplateformes — Servez des listes de travail en radiologie et des écrans de rapport via REST et GraphQL avec Live Queries optionnel pour les changements de statut.
Qu'est-ce que le modèle de backend de l'application d'information en radiologie ?
Back4app est un backend géré pour une livraison rapide des produits. Le modèle de backend de l'application d'information en radiologie modèle les demandes d'imagerie, les métadonnées des études DICOM, les affectations de radiologistes et les flux de travail de rapport afin que les équipes puissent livrer des systèmes de radiologie plus rapidement et avec moins de travail d'infrastructure.
Meilleur pour :
Aperçu
Les flux de travail en radiologie dépendent d'une coordination précise entre la réception des commandes, l'acquisition des études, l'indexation des métadonnées, l'attribution des spécialistes et le temps de retour des rapports.
Ce modèle définit ImagingRequest, Study, Radiologist, Report, et AuditEvent avec des règles de propriété et des Live Queries optionnels afin que les équipes puissent mettre en œuvre des flux de travail en radiologie rapidement et en toute sécurité.
Fonctionnalités clés de l'information en radiologie
Chaque carte technologique dans ce hub utilise le même schéma d'information en radiologie avec DemandeImagerie, Étude, Radiologue, Rapport et ÉvénementAudit.
Prise en charge des demandes d'imagerie
Suivez les demandes avec les références des patients, les détails du clinicien commandant, la priorité, l'indication et la modalité demandée.
Enregistrements d'études et métadonnées DICOM
Stockez les identifiants d'études, le numéro d'accès, la modalité, l'UID de l'étude, la partie du corps, la date réalisée et l'état.
Registre et affectation des radiologistes
Maintenir les profils de spécialistes, les sous-spécialités, les indicateurs de disponibilité et les liens vers les utilisateurs authentifiés.
Flux de travail des rapports diagnostiques
Gérer les états de projet, de révision, d'amendement et de rapport final avec des horodatages et le contexte des réviseurs.
Événements d'audit et suivi des délais
AuditEvent capture des actions opérationnelles telles que des changements d'affectation, la finalisation des rapports et des corrections de métadonnées.
Pourquoi construire votre backend d'information en radiologie avec Back4app ?
Back4app vous fournit un contrat de backend sécurisé pour les opérations d'imagerie afin que votre équipe puisse se concentrer sur les listes de travail, les expériences de lecture et la livraison des rapports au lieu de la plomberie de backend.
- •Entités prêtes pour le workflow: Des classes prédéfinies pour les demandes, les études, les radiologues et les rapports vous aident à mettre en œuvre des flux de travail en radiologie courants sans tout concevoir depuis zéro.
- •Métadonnées et gouvernance recherchables: Stockez des champs structurés liés au DICOM et des événements d'audit afin que les études soient plus faciles à trouver, à acheminer et à examiner entre les équipes.
- •Flexibilité en temps réel et API: Utilisez Live Queries pour les mises à jour de la file de lecture tout en exposant REST et GraphQL pour les intégrations hospitalières, adjacentes au PACS ou de notification.
Standardisez les workflows de demande d'imagerie et de reporting sur le web et mobile avec un seul contrat de backend et réduisez le time-to-market pour les produits de radiologie.
Avantages principaux
Un backend de flux de travail en radiologie qui vous aide à expédier plus rapidement tout en préservant la structure, la visibilité et le contrôle.
Déploiement de flux de travail d'imagerie plus rapide
Commencez à partir d'un modèle préconstruit de demande à rapport afin de pouvoir vous concentrer sur les portails des cliniciens, les files d'attente de lecture et l'UX diagnostique.
Métadonnées structurées dès le premier jour
Stockez les champs d'étude clés liés au DICOM dans un schéma canonique pour le filtrage, le routage et les intégrations en aval.
Flux de révision et d'approbation clairs
Modélisez explicitement les états du cycle de vie du rapport afin que l'ébauche, la révision, l'amendement et la finalisation soient faciles à gérer.
Visibilité de la liste de tâches en temps réel
Live Queries peut afficher immédiatement les études nouvellement attribuées, les changements de priorité ou les rapports finalisés sur les écrans pertinents.
Couche d'intégration extensible
Connectez-vous aux systèmes de planification, services de notification, portails ou flux de travail d'archivage via REST ou GraphQL.
Échafaudage assisté par l'IA
Utilisez l'invite de l'Agent IA pour structurer le backend, créer des enregistrements réalistes et accélérer les démonstrations ou pilotes.
Prêt à rationaliser les flux de travail en radiologie ?
Laissez l'Agent IA de Back4app structurer le backend d'informations en radiologie et semer des demandes d'exemples, des études, des spécialistes et des rapports à partir d'une seule invite.
Gratuit pour commencer — 50 invites d'agent IA/mois, aucune carte de crédit requise
Pile technique
Tout est inclus dans ce modèle backend d'information en radiologie.
Diagramme ER
Modèle de relation d'entité pour le schéma des informations en radiologie.
Schéma couvrant les demandes d'imagerie, les études, les radiologues, les rapports et les événements d'audit.
Voir la source du diagramme
erDiagram
ImagingCenter ||--o{ Modality : "operates"
ImagingCenter ||--o{ ImagingRequest : "receives"
User ||--o{ ImagingRequest : "orders"
Modality ||--o{ ImagingRequest : "scheduled_for"
ImagingRequest ||--o{ DicomStudy : "produces"
DicomStudy ||--o{ Report : "interpreted_as"
ImagingRequest ||--o{ WorklistItem : "creates"
User ||--o{ WorklistItem : "assigned"
User ||--o{ Report : "authors"
User ||--o{ AuditEvent : "actor_of"
User {
String objectId PK
String username
String email
String password
String role
String displayName
String specialty
Date createdAt
Date updatedAt
}
ImagingCenter {
String objectId PK
String name
String code
String location
String contactNumber
Date createdAt
Date updatedAt
}
Modality {
String objectId PK
Pointer imagingCenter FK
String name
String type
String dicomAETitle
String status
Date createdAt
Date updatedAt
}
ImagingRequest {
String objectId PK
String patientId
String patientName
String accessionNumber
String studyDescription
String priority
String status
Pointer requestedBy FK
Pointer imagingCenter FK
Pointer scheduledModality FK
Date scheduledAt
String clinicalIndication
Date createdAt
Date updatedAt
}
DicomStudy {
String objectId PK
Pointer imagingRequest FK
String studyInstanceUID
Number seriesCount
Number instanceCount
String modalityType
String bodyPartExamined
Date performedAt
String pacsLocation
String metadataStatus
Date createdAt
Date updatedAt
}
Report {
String objectId PK
Pointer dicomStudy FK
Pointer radiologist FK
String status
String findings
String impression
Boolean criticalFlag
Date signedAt
Number version
Date createdAt
Date updatedAt
}
WorklistItem {
String objectId PK
Pointer imagingRequest FK
Pointer assignedTo FK
String queueType
String status
Date dueAt
String notes
Date createdAt
Date updatedAt
}
AuditEvent {
String objectId PK
Pointer actor FK
String action
String targetClass
String targetId
String details
Date timestamp
}
Flux d'intégration
Flux Auth-to-CRUD pour la connexion en radiologie, la récupération des demandes d'imagerie, l'enregistrement des études et la finalisation des rapports.
Voir la source du diagramme
sequenceDiagram
participant User as Radiology Staff
participant App as Radiology Information App
participant Back4app as Back4app Cloud
User->>App: Sign in to worklist
App->>Back4app: POST /login (username, password)
Back4app-->>App: Session token + user role
User->>App: Open today's imaging queue
App->>Back4app: GET /classes/WorklistItem?include=imagingRequest,assignedTo
Back4app-->>App: Worklist items with request context
User->>App: Register completed scan and DICOM metadata
App->>Back4app: POST /classes/DicomStudy (imagingRequest, studyInstanceUID, seriesCount, modalityType, metadataStatus)
Back4app-->>App: DicomStudy object + objectId
App->>Back4app: PUT /classes/ImagingRequest/{id} (status: completed)
Back4app-->>App: Updated ImagingRequest
User->>App: Draft and sign specialist report
App->>Back4app: POST /classes/Report (dicomStudy, radiologist, findings, impression, status: signed, signedAt)
Back4app-->>App: Signed Report saved
App->>Back4app: POST /classes/AuditEvent (action: report_signed, targetClass: Report, targetId)
Back4app-->>App: AuditEvent saved
Back4app-->>App: Live Query events (new urgent requests, signed reports)
App-->>User: Real-time queue and report status updatesDictionnaire de données
Référence complète au niveau des champs pour chaque classe dans le schéma d'information en radiologie.
| Champ | Type | Description | Requis |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Auto |
| username | String | Login username for clinicians and radiology staff | |
| String | User email address | ||
| password | String | Hashed password (write-only) | |
| role | String | Role in the workflow (admin, scheduler, technologist, radiologist, referring_physician) | |
| displayName | String | Full name displayed in the radiology workspace | — |
| specialty | String | Clinical specialty such as neuroradiology or orthopedics | — |
| createdAt | Date | Auto-generated creation timestamp | Auto |
| updatedAt | Date | Auto-generated last-update timestamp | Auto |
9 champs dans User
Sécurité et autorisations
Comment les stratégies ACL, rôles et CLP sécurisent les demandes d'imagerie, les métadonnées d'études et les rapports de spécialistes.
Accès basé sur les rôles
Utilisez des rôles tels qu'administrateur, radiologue, technicien et coordinateur pour définir les actions CRUD et la visibilité des écrans.
Autorisations conscientes des affectations
Restreindre la rédaction de rapports et les mises à jour des études aux spécialistes ou au personnel opérationnel affectés tout en préservant des chemins de révision contrôlés.
Historique d'audit protégé
Les enregistrements AuditEvent doivent être en mode ajout uniquement et protégés contre la suppression côté client afin que l'historique de travail reste digne de confiance.
Schéma (JSON)
Définition de schéma JSON brute prête à être copiée dans Back4app ou 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
},
"displayName": {
"type": "String",
"required": false
},
"specialty": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "ImagingCenter",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"name": {
"type": "String",
"required": true
},
"code": {
"type": "String",
"required": true
},
"location": {
"type": "String",
"required": false
},
"contactNumber": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Modality",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"imagingCenter": {
"type": "Pointer",
"required": true,
"targetClass": "ImagingCenter"
},
"name": {
"type": "String",
"required": true
},
"type": {
"type": "String",
"required": true
},
"dicomAETitle": {
"type": "String",
"required": false
},
"status": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "ImagingRequest",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"patientId": {
"type": "String",
"required": true
},
"patientName": {
"type": "String",
"required": true
},
"accessionNumber": {
"type": "String",
"required": true
},
"studyDescription": {
"type": "String",
"required": true
},
"priority": {
"type": "String",
"required": true
},
"status": {
"type": "String",
"required": true
},
"requestedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"imagingCenter": {
"type": "Pointer",
"required": true,
"targetClass": "ImagingCenter"
},
"scheduledModality": {
"type": "Pointer",
"required": false,
"targetClass": "Modality"
},
"scheduledAt": {
"type": "Date",
"required": false
},
"clinicalIndication": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "DicomStudy",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"imagingRequest": {
"type": "Pointer",
"required": true,
"targetClass": "ImagingRequest"
},
"studyInstanceUID": {
"type": "String",
"required": true
},
"seriesCount": {
"type": "Number",
"required": false
},
"instanceCount": {
"type": "Number",
"required": false
},
"modalityType": {
"type": "String",
"required": true
},
"bodyPartExamined": {
"type": "String",
"required": false
},
"performedAt": {
"type": "Date",
"required": false
},
"pacsLocation": {
"type": "String",
"required": false
},
"metadataStatus": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Report",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"dicomStudy": {
"type": "Pointer",
"required": true,
"targetClass": "DicomStudy"
},
"radiologist": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"status": {
"type": "String",
"required": true
},
"findings": {
"type": "String",
"required": false
},
"impression": {
"type": "String",
"required": false
},
"criticalFlag": {
"type": "Boolean",
"required": false
},
"signedAt": {
"type": "Date",
"required": false
},
"version": {
"type": "Number",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "WorklistItem",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"imagingRequest": {
"type": "Pointer",
"required": true,
"targetClass": "ImagingRequest"
},
"assignedTo": {
"type": "Pointer",
"required": false,
"targetClass": "User"
},
"queueType": {
"type": "String",
"required": true
},
"status": {
"type": "String",
"required": true
},
"dueAt": {
"type": "Date",
"required": false
},
"notes": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "AuditEvent",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"actor": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"action": {
"type": "String",
"required": true
},
"targetClass": {
"type": "String",
"required": true
},
"targetId": {
"type": "String",
"required": true
},
"details": {
"type": "String",
"required": false
},
"timestamp": {
"type": "Date",
"required": true
}
}
}
]
}Construire avec l'agent AI
Utilisez l'Agent IA Back4app pour générer une application d'informations en radiologie complète à partir de ce modèle, y compris l'interface utilisateur, le backend, l'authentification, les listes de travail et les écrans de flux de rapports.
Créez un backend d'informations en radiologie sur Back4app avec ce schéma et ce comportement exacts. Schéma: 1. ImagingRequest : requestNumber (String, requis), patientId (String, requis), patientName (String), orderingClinician (String), priority (String : routine, urgent, stat), modalityRequested (String), clinicalIndication (String), status (String : requested, scheduled, performed, cancelled), objectId, createdAt, updatedAt. 2. Study : imagingRequest (Pointer to ImagingRequest, requis), accessionNumber (String, requis), studyInstanceUID (String, requis), modality (String), bodyPart (String), performedAt (Date), dicomMetadata (JSON), status (String : queued, acquired, reading, reported), objectId, createdAt, updatedAt. 3. Radiologist : user (Pointer to built-in User, requis), fullName (String), subspecialties (Array), active (Boolean), contact (JSON), objectId, createdAt, updatedAt. 4. Report : study (Pointer to Study, requis), author (Pointer to Radiologist), reviewer (Pointer to Radiologist, optionnel), status (String : draft, in_review, amended, final), findings (String), impression (String), finalizedAt (Date, optionnel), objectId, createdAt, updatedAt. 5. AuditEvent : actor (Pointer to User), targetClass (String), targetId (String), action (String), details (JSON), timestamp (Date) — uniquement en ajout. Sécurité: - CLP et ACL basés sur les rôles : seuls les coordinateurs et les administrateurs peuvent créer ou mettre à jour les champs de planification ImagingRequest ; seuls les radiologues affectés ou les administrateurs peuvent éditer des rapports en brouillon ; seuls les réviseurs ou les administrateurs peuvent finaliser les rapports. AuditEvent est en ajout uniquement et en lecture restreinte. Auth: - Les utilisateurs s'inscrivent et se connectent via l'User intégré ; rôles attribués par l'administrateur. Comportement: - Authentifier l'utilisateur, charger les demandes d'imagerie, créer ou mettre à jour une étude avec des métadonnées DICOM, rédiger un rapport, et écrire une entrée AuditEvent pour chaque opération significative. Livrer: - application Back4app avec schéma, ACL, CLP, validations de Cloud Code, données d'exemple préremplies et un squelette frontend par technologie choisie.
Appuyez sur le bouton ci-dessous pour ouvrir l'Agent avec cette invite de modèle pré-remplie.
Cette invite de base décrit le schéma et les comportements en radiologie ; vous pouvez sélectionner des suffixes spécifiques à la technologie par la suite.
Terrain de jeu API
Essayez les points de terminaison REST et GraphQL contre le schéma d'informations en radiologie. Les réponses utilisent des données fictives et ne nécessitent pas un 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 Backend d'information en radiologie
React Backend d'information en radiologie
React Natif Backend d'information en radiologie
Next.js Backend d'information en radiologie
JavaScript Backend d'information en radiologie
Android Backend d'information en radiologie
iOS Backend d'information en radiologie
Vue Backend d'information en radiologie
Angular Backend d'information en radiologie
GraphQL Backend d'information en radiologie
REST API Backend d'information en radiologie
PHP Backend d'information en radiologie
.NET Backend d'information en radiologie
Ce que vous obtenez avec chaque technologie
Chaque pile utilise le même schéma de backend d'information en radiologie et les contrats API.
Structure de données unifiée en radiologie
Modèles de données standardisés pour les demandes d'imagerie et les études DICOM.
Suivi des rapports en temps réel pour la radiologie
Surveillez le statut des rapports et des demandes d'imagerie en temps réel.
Partage sécurisé pour les flux de travail en radiologie
Partagez en toute sécurité des données d'imagerie sensibles et des rapports avec des utilisateurs autorisés.
REST/GraphQL APIs pour la radiologie
Accédez et gérez vos données efficacement avec des APIs flexibles.
Gestion des affectations de radiologues
Rationalisez l'affectation des tâches aux radiologues pour améliorer l'efficacité.
Cadre extensible pour la radiologie
Personnalisez et étendez facilement le backend pour répondre aux besoins spécifiques de la radiologie.
Comparaison du cadre d'informations en radiologie
Comparez la vitesse de configuration, le style SDK et le support AI à travers toutes les technologies prises en charge.
| Framework | Temps de configuration | Avantage des informations en radiologie | Type SDK | Support AI |
|---|---|---|---|---|
| Environ 5 min | Base de code unique pour les informations en radiologie sur mobile et web. | Typed SDK | Complet | |
| Moins de 5 minutes | Tableau de bord web rapide pour les informations en radiologie. | Typed SDK | Complet | |
| ~3–7 min | Application mobile multiplateforme pour les informations en radiologie. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Application web rendue par serveur pour les informations en radiologie. | Typed SDK | Complet | |
| ~3–5 min | Intégration web légère pour les informations en radiologie. | Typed SDK | Complet | |
| Environ 5 min | Application native Android pour les informations en radiologie. | Typed SDK | Complet | |
| Moins de 5 minutes | Application native iOS pour les informations en radiologie. | Typed SDK | Complet | |
| ~3–7 min | Interface utilisateur web Reactive pour les informations en radiologie. | Typed SDK | Complet | |
| Configuration rapide (5 min) | Application web d'entreprise pour les informations en radiologie. | Typed SDK | Complet | |
| Moins de 2 min | API GraphQL flexible pour les informations en radiologie. | GraphQL API | Complet | |
| Configuration rapide (2 min) | Intégration REST API pour les informations en radiologie. | REST API | Complet | |
| ~3 min | Backend PHP côté serveur pour les informations en radiologie. | REST API | Complet | |
| ~3–7 min | Backend .NET pour les informations en radiologie. | Typed SDK | Complet |
Le temps de configuration reflète la durée attendue depuis le démarrage du projet jusqu'à la première liste de travail en radiologie peuplée avec des données ImagingRequest et Study.
Questions Fréquemment Posées
Questions courantes sur la création d'un backend d'information en radiologie avec ce modèle.
Prêt à créer votre application d'information en radiologie ?
Commencez votre projet de flux de travail en radiologie en quelques minutes. Aucune carte de crédit requise.