Шаблон бэкенда приложения для удаленного мониторинга пациентов
Обеспечьте безопасный доступ к данным пациентов с домашних IoT-медицинских устройств для эффективного мониторинга
Готовый к производству бэкенд приложения RPM на Back4app для безопасного доступа к данным пациентов с IoT-устройств, включая журналы мониторинга и сообщения пользователей, с централизованным журналом аудита. В нем есть ER-диаграмма, словарь данных, JSON-схема, API-песочница и AI Agent запрос для быстрой настройке.
Ключевые выводы
Создайте бэкенд для удаленного мониторинга пациентов с безопасными контрольными доступами, извлечением данных IoT и журналами мониторинга, чтобы ваша команда по продукту могла сосредоточиться на пользовательском опыте и соблюдении требований.
- Модель данных с приоритетом IoT — Сохраняйте идентификацию пациентов, данные об устройствах и журналы мониторинга отдельно, но связаны для аутентификации и авторизации.
- Безопасные сообщения — Ненарушенные сообщения между пациентами и клиницистами с четкими уведомлениями о прочтении и контролем хранения.
- Версионированные данные об устройствах — Храните данные об устройствах с метаданными версии, обеспечивая эффективное отслеживание обновленных показаний и уведомлений.
- Мониторинг жизненного цикла журналов — Эффективное управление журналами мониторинга, документирование взаимодействия с пользователями и состояния устройств с течением времени.
- Аудит журналирования, соответствующий стандартам соблюдения — Централизованный AuditLog фиксирует чувствительные события для проверки и соблюдения норм здравоохранения.
Что такое шаблон бэкенда приложения RPM?
Back4app является бэкендом как услугой (BaaS) для быстрой доставки. Шаблон бэкенда приложения RPM предлагает готовую схему для профилей пациентов, данных IoT устройств, журналов мониторинга, безопасных сообщений и аудит-логов. Подключите свой любимый фронтенд (React, Flutter, Next.js и другие) и обеспечьте более быструю доставку.
Лучше всего для:
Обзор
Приложения RPM требуют строгих границ данных, аудитируемых транзакций и надежной доставки чувствительной информации о пациентах, собранной с устройств IoT.
Этот шаблон определяет классы PatientProfile, DeviceData, MonitoringLog, UserMessage и AuditLog с правилами собственности и ролевыми правилами, чтобы команды могли быстро и безопасно реализовать приложения RPM.
Основные функции приложения RPM
Каждая технология в этом хабе использует одну и ту же схему бэкенда приложения RPM, в которой есть PatientProfile, DeviceData, MonitoringLog, UserMessage и AuditLog.
Профиль пациента и аутентификация
ПрофильПациента хранит личность, контактные данные и предпочтения с ссылкой на аутентифицированного пользователя.
Данные устройства с версионированием
ДанныеУстройства хранят тип устройства, сырые данные, записанноНа, версия и происхождение пользователя.
Управление журналом мониторинга
Мониторинг логов отслеживает взаимодействия пациентов, документированные в хронологическом порядке с указанными статусами.
Безопасные сообщения между врачами и пациентами
UserMessage облегчает обмен сообщениями между Provider и пациентами с поддержкой вложений и статусом доставки/чтения.
Централизованные журналы аудита
AuditLog фиксирует информацию о действиях, предпринятых пользователями, обеспечивая четкую ответственность.
Почему стоит создать бэкенд вашего RPM-приложения с Back4app?
Back4app управляет основами бэкенда — безопасностью, хранением данных, API и обновлениями в реальном времени — позволяя вам сосредоточиться на пользовательском опыте, конфиденциальности и клинической интеграции.
- •Безопасная передача данных пациентов: Встроенные механизмы аутентификации и контроля доступа позволяют ограничивать видимость для конкретных пользователей для каждого чтения устройства, журнала мониторинга или сообщения.
- •Отслеживание аудита и происхождения: AuditLog записывает, кто получил доступ, опубликовал или изменил чувствительные данные, обеспечивая соблюдение нормативных требований.
- •Сообщения и уведомления в реальном времени: Потоковые сообщения, вложения и опциональные обновления в реальном времени способствуют свободной коммуникации между пациентами и медицинскими Providers.
Быстро разверните безопасный бэкенд приложения RPM и сосредоточьтесь на итерации клинических рабочих процессов, а не на сложностях бэкенда.
Основные преимущества
Бэкенд приложения RPM, который приоритизирует конфиденциальность данных, происхождение и быструю доставку.
Ускоренный опыт пациентов
Быстрый выпуск представлений данных устройства, функциональности мониторинга и безопасных сообщений, используя предварительно проверенную структуру бэкенда.
Сильное происхождение данных
Поддерживайте версионирование данных устройств и логирования, чтобы клинические действия могли быть проверены.
Детализированные разрешения
Защитите чувствительные записи с помощью контроля доступа на основе ролей, обеспечивая, что только авторизованный персонал может просматривать определенные данные.
Интегрированные сообщения
Поточная связь и обновления в реальном времени улучшают коммуникацию между пациентами и медицинскими работниками.
Логирование, готовое к соответствию требованиям
Централизованный AuditLog сохраняет детализированные записи для соблюдения медицинских норм и бизнес-аналитики.
Первоначальная настройка с помощью ИИ
Запустите разработку с помощью тщательно подобранного запроса к AI Agent для создания схемы, разрешений и базового кода интеграции.
Готовы создать безопасное приложение RPM?
Позвольте AI Agent от Back4app создать бэкенд вашего приложения RPM, генерируя профили пациентов, данные устройств, журналы мониторинга и журналы аудита из одного запроса.
Бесплатно для начала — 50 запросов AI агента в месяц, без необходимости ввода кредитной карты
Технический стек
Все включено в этот шаблон бэкенда приложения RPM.
ER диаграмма
Модель взаимосвязей сущностей для схемы бэкенда приложения RPM.
Схема, охватывающая профили пациентов, данные IoT-устройств, журналы мониторинга, сообщения и записи аудита.
Просмотреть источник диаграммы
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
}
Поток интеграции
Типичный поток выполнения для аутентификации, извлечения данных, обновлений мониторинга и обмена сообщениями.
Просмотреть источник диаграммы
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"Словарь данных
Полное поле уровня справки для каждого класса в схеме приложения RPM.
| Поле | Тип | Описание | Обязательно |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Авто |
| 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 | Авто |
| updatedAt | Date | Auto-generated last-update timestamp | Авто |
9 поля в PatientProfile
Безопасность и разрешения
Как стратегии ACL, CLP и шифрования защищают данные пациентов, данные IoT, сообщения и журналы аудита.
Доступ и право собственности на основе ролей
Примените ACL, чтобы пациенты могли просматривать данные своих устройств и журналы мониторинга, в то время как клиницисты могут видеть данные, относящиеся к их назначенным пациентам; CLP предотвращают несанкционированные действия с классами.
Шифрованные полезные нагрузки и вложения
Храните чувствительные данные безопасно с помощью шифрования и используйте подписанные URL-адреса для безопасного доступа к большим файлам.
Аудит-трейлы только для добавления
Записывайте события AuditLog из серверных функций, чтобы защитить исторические данные о соответствии от подделки.
Схема (JSON)
Определение схемы JSON в сыром виде, готовое для копирования в Back4app или использования в качестве справочника по реализации.
{
"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
}
}
}
]
}Создавать с помощью AI Agent
Используйте AI Agent Back4app для генерации приложения RPM из этого шаблона, включая серверную схему, средства управления доступом и интеграцию с начальным фронтендом.
Создайте бэкенд приложения RPM на Back4app с этой схемой и поведением. Схема: 1. PatientProfile: user (Ссылка на пользователя, обязательный), fullName (Строка, обязательный), dob (Дата, необязательный), contact (Объект), medicalRecordNumber (Строка, обязательный, уникальный); objectId, createdAt, updatedAt. 2. DeviceData: patient (Ссылка на PatientProfile, обязательный), deviceType (Строка), dataPayload (Объект), recordedAt (Дата, обязательный), version (Число, по умолчанию 1); objectId, createdAt, updatedAt. 3. MonitoringLog: patient (Ссылка на PatientProfile, обязательный), data (Ссылка на DeviceData, обязательный), timestamp (Дата, обязательный), status (Строка, обязательный); objectId, createdAt, updatedAt. 4. UserMessage: sender (Ссылка на пользователя, обязательный), recipient (Ссылка на пользователя, обязательный), threadId (Строка, обязательный), body (Строка), attachments (Массив файлов), status (Строка: отправлено, доставлено, прочитано), sentAt (Дата); objectId, createdAt, updatedAt. 5. AuditLog: actor (Ссылка на пользователя, обязательный), action (Строка, обязательный), entityType (Строка, обязательный), entityId (Строка, обязательный), payload (Объект, необязательный), createdAt (Дата); objectId, createdAt, updatedAt. Безопасность: - Применяйте ACL, чтобы пациенты могли читать только свои записи DeviceData и MonitoringLog. Врачи видят назначенных пациентов. Используйте Cloud Code для чувствительных переходов и для записи записей AuditLog на серверной стороне. Защитите свои данные с помощью шифрования. Аутентификация: - Поддерживайте регистрацию для пациентов и врачей; назначение ролей; безопасный вход и управление сессиями. Поведение: - Пациент входит в систему, получает последние данные устройств и журналы мониторинга, отправляет сообщения врача в потоках и получает уведомления. Врачи публикуют данные устройств и журналы мониторинга; система записывает записи AuditLog для действий публикации. Доставка: - Приложение Back4app с схемой, CLP, ACL, хуками Cloud Code для публикации и аудита, а также интеграцией стартового фронтенда для просмотра пациентами и врачами.
Нажмите кнопку ниже, чтобы открыть Агент с предварительно заполненным шаблоном запроса.
Это базовый запрос без суффикса технологии. Вы можете адаптировать сгенерированный фронтенд-стек позже.
API Площадка
Попробуйте REST и GraphQL конечные точки с схемой приложения RPM. Ответы используют тестовые данные и не требуют учетной записи Back4app.
Использует ту же схему, что и этот шаблон.
Выберите вашу технологию
Разверните каждую карточку для шагов интеграции, состояния шаблонов, примеров модели данных и офлайн заметок.
Flutter RPM App Backend
React RPM App Backend
React Native RPM App Backend
Next.js RPM App Backend
JavaScript RPM App Backend
Android RPM App Backend
iOS RPM App Backend
Vue RPM App Backend
Angular RPM App Backend
GraphQL RPM App Backend
REST API RPM App Backend
PHP RPM App Backend
.NET RPM App Backend
Что вы получаете с каждой технологией
Каждый стек использует одну и ту же схему бэкенда приложения RPM и правила API.
Предварительно созданная схема профиля пациента
Легко управляйте и получите доступ к данным пациента с единой структурой rpm dashboard.
Интеграция данных IoT-устройств
Бесшовно подключайте и отслеживайте IoT-устройства для получения данных в реальном времени rpm dashboard.
Безопасные сообщения для rpm dashboard
Безопасно общайтесь с пациентами и Provider через зашифрованные сообщения.
Комплексные журналы мониторинга
Отслеживайте действия пациентов и показатели здоровья с подробными журналами для rpm dashboard.
Поддержка REST/GraphQL API
Гибкие варианты API для эффективного взаимодействия с вашим rpm dashboard бэкендом.
Журналы аудита для соблюдения требований
Соблюдайте требования с помощью подробных журналов аудита для всех действий rpm dashboard.
Сравнение фреймов Rpm Dashboard
Оцените скорость настройки, стили SDK и поддержку ИИ для всех поддерживаемых технологических стеков.
| Фреймворк | Время настройки | Преимущества Rpm Dashboard | Тип SDK | Поддержка ИИ |
|---|---|---|---|---|
| ~3–7 мин | Единая кодовая база для rpm dashboard на мобильных устройствах и в вебе. | Typed SDK | Полный | |
| Быстрая (5 мин) настройка | Быстрый веб-дэшборд для rpm dashboard. | Typed SDK | Полный | |
| ~5 мин | Кроссплатформенное мобильное приложение для rpm dashboard. | Typed SDK | Полный | |
| Около 5 мин | Веб-приложение с серверной отрисовкой для rpm dashboard. | Typed SDK | Полный | |
| ~3 мин | Легкая веб-интеграция для rpm dashboard. | Typed SDK | Полный | |
| ~3–7 мин | Native Android приложение для rpm dashboard. | Typed SDK | Полный | |
| Быстрая (5 мин) настройка | Native iOS приложение для rpm dashboard. | Typed SDK | Полный | |
| ~5 мин | React интерфейс веба для rpm dashboard. | Typed SDK | Полный | |
| Около 5 мин | Корпоративное веб-приложение для rpm dashboard. | Typed SDK | Полный | |
| Быстрая (2 мин) настройка | Гибкий GraphQL API для rpm dashboard. | GraphQL API | Полный | |
| ~2 мин | REST API интеграция для rpm dashboard. | REST API | Полный | |
| Менее 5 мин | Серверная часть PHP бэкенда для rpm dashboard. | REST API | Полный | |
| ~5 мин | .NET бэкенд для rpm dashboard. | Typed SDK | Полный |
Время настройки указывает ожидаемую продолжительность от инициализации проекта до первого входа пациента и запроса данных устройства с использованием этой шаблонной схемы.
Часто задаваемые вопросы
Общие запросы по созданию бэкенда приложения RPM с использованием этого шаблона.
Готовы создать свое RPM приложение?
Запустите свой проект RPM приложения всего за несколько минут. Кредитная карта не нужна.