Бэкенд портала пациента

Шаблон бэкенда приложения портала пациента
Доставляйте результаты лабораторных исследований, управляйте планами лечения и обеспечивайте безопасный обмен сообщениями между врачом и пациентом

Q: Что такое бэкенд Patient Portal?

Бэкенд Портала Пациента — это структурированная BaaS схема и API для функций, ориентированных на пациентов, таких как профили, результаты анализов, планы лечения, безопасные сообщения, записи на прием и ведение аудита.

Q: Что включает в себя шаблон Портала Пациента?

Он включает в себя классы PatientProfile, ProviderProfile, LabResult, TreatmentPlan, Message, Appointment и AuditLog, а также ER-диаграмму, API-песочницу, JSON-схему и подсказку AI Agent.

Q: Почему стоит использовать Back4app для портала пациента?

Back4app предоставляет управляемуюpersistents, аутентификацию, генерацию API, варианты в реальном времени и Cloud Code, позволяя командам сосредоточиться на UX и соблюдении норм вместо инфраструктуры.

Q: Как мне получить последний результат анализа и его Provider в одном запросе?

Используйте GraphQL с вложенным выбором или REST-запрос, который включает параметры расширения указателя, чтобы получить LabResult с его Provider указателем за один вызов.

Q: Как мне отметить сообщение как прочитанное?

Обновите поле Message.status на 'прочитано' с проверкой на стороне сервера, чтобы убедиться, что обновляющий — это получатель; при желании создайте совпадающую запись в AuditLog для отслеживаемости.

Q: Может ли React Native кешировать планы лечения для оффлайн-использования?

Да. Включите локальное хранилище данных и закрепите снимки TreatmentPlan. Реализуйте логику согласования для объединения обновлений, когда связь восстанавливается.

Q: Как мне предотвратить несанкционированное распространение PDF-файлов лаборатории?

Используйте подписанные URL с коротким временем жизни, ограничьте доступ через ACL/CLP и избегайте встраивания полной PHI в логи, доступные для более широких ролей.

Q: Как лучше всего представить контекст записи на прием на мобильных устройствах?

Запрашивайте Appointment вместе с указателями Message и LabResult и отображайте их в виде временной шкалы; используйте локальное закрепление для предстоящих встреч, чтобы обеспечить доступность в оффлайне.

Q: Как работает процесс регистрации аудита от начала до конца?

Хуки Cloud Code записывают записи AuditLog, когда происходят чувствительные действия (публикация результата лаборатории, утверждение плана лечения, отправка сообщения). AuditLog хранит актера, действие, контекст сущности и полезную нагрузку для последующего рассмотрения.

Q: Как я могу поддержать подтверждение пациентом плана лечения?

Добавьте запись подтверждения или поле в TreatmentPlan (acknowledgedBy, acknowledgedAt) и ограничьте, кто может его установить; запишите запись AuditLog, чтобы зафиксировать событие.

Готовый к эксплуатации бэкенд портала пациента на Back4app с безопасной доставкой результатов лабораторных исследований, управлением планами лечения, обменом сообщениями с врачами, связыванием встреч и централизованными журналами аудита. Включает диаграмму ER, словарь данных, схему JSON, API-площадку и запрос AI Agent для быстрого запуска.

Создать с AI-агентом Выберите вашу технологию

Основные выводы

Создайте бэкенд для пациентов с безопасными контрольными доступами, контролем версий лабораторных исследований, историей планов лечения, ветвистыми сообщениями и следами аудита, чтобы ваша продуктовая команда могла сосредоточиться на пользовательском опыте и соблюдении требований.

Модель данных, ориентированная на пациента — Храните идентичность пациента, результаты анализов, лечения и сообщения по отдельности, но связывая их для ясного происхождения и авторизации.
Безопасные сообщения — Ветвистые сообщения с вложениями между пациентами и Provider с явными уведомлениями о прочтении и контрольными сроками хранения.
Версионированные результаты анализов — Храните результаты анализов с данными о происхождении и метаданными версий, чтобы обновленные отчеты и дополнительные материалы отслеживались.
Цикл жизни плана лечения — Управляйте черновиками плана лечения, утверждениями от Provider, подтверждением пациентом и историей версий.
Логирование, соответствующее требованиям — Централизованный класс AuditLog записывает чувствительные события для проверки, мониторинга и соблюдения норм.

Что такое шаблон бекенда приложения портала для пациентов?

Back4app — это бекенд как сервис (BaaS) для быстрой доставки. Шаблон бекенда приложения портала для пациентов — это готовая к работе схема для профилей пациентов, лабораторных результатов, планов лечения, безопасного обмена сообщениями, записей на прием и журналов аудита. Подключите предпочитаемый фронтенд (React, Flutter, Next.js и другие) и сделайте доставку быстрее.

Лучше всего для:

Порталы для пациентовТелемедицинские сообщенияsecure доставка результатов лабораторных исследованийУправление планом леченияКоммуникация между клиницистом и пациентомКоманды по созданию прототипов, соответствующих требованиям HIPAA

Обзор

Пациентские порталы требуют строгих границ данных, подлежащих аудиту изменений и надежной доставки чувствительных элементов, таких как лабораторные результаты и планы лечения.

Этот шаблон определяет PatientProfile, LabResult, TreatmentPlan, Message, ProviderProfile, Appointment и AuditLog с правилами собственности и ролей, чтобы команды могли быстро и безопасно реализовывать пациентские порталы.

Основные функции портала пациентов

Каждая карточка технологии в этом центре использует одну и ту же схему бэкенда портала пациента с PatientProfile, LabResult, TreatmentPlan, Message, ProviderProfile, Appointment и AuditLog.

Профиль пациента и аутентификация

PatientProfile хранит информацию о личности, контактные данные и предпочтения с указанием аутентифицированного пользователя.

Версия результатов лабораторных исследований

LabResult хранит тип теста, исходные данные результата, дату отчета, версию и происхождение Provider.

Жизненный цикл плана лечения

TreatmentPlan хранит содержимое плана, одобрителя Provider, статус (черновик, активный, завершенный) и эффективное окно.

Безопасные сообщения между врачом и пациентом

Сообщение поддерживает темы, вложения, указатели отправителя/получателя и статус доставки/чтения.

Связывание назначений

Связь назначений с пациентом, Provider, запланированным временем и статусом для контекста визита.

Централизованные журналы аудита

AuditLog фиксирует личность актера, тип действия, контекст сущности и метаданные полезной нагрузки для соблюдения норм.

Почему строить бэкенд вашего приложения для портала пациентов с Back4app?

Back4app обрабатывает основные аспекты бэкенда — безопасность, сохранность данных, API и реальное время — так что вы можете сосредоточиться на опыте пациентов, конфиденциальности и клинической интеграции.

•Безопасная доставка клинических данных: Встроенная аутентификация и шаблоны ACL/CLP позволяют вам контролировать, какие пользователи могут видеть каждый результат анализа, план лечения или сообщение.
•Аудит и происхождение: AuditLog фиксирует, кто просматривал, публиковал или изменял конфиденциальные записи, чтобы вы могли поддерживать соответствие требованиям и отладку.
•Сообщения и уведомления: Потоковые сообщения, вложения и необязательные обновления в реальном времени делают разговоры между клиницистами и пациентами гладкими и своевременными.

Быстро создайте безопасный бэкенд портала пациентов и итеративно улучшайте клинические рабочие процессы, а не инфраструктуру бэкенда.

Основные преимущества

Бэкенд портала пациента, который подчеркивает конфиденциальность, происхождение и быструю доставку.

Ускоренные впечатления пациентов

Доставляйте просмотры лабораторных результатов, планы лечения и безопасные сообщения быстрее, повторно используя проверенный контракт бэкенда.

Сильное происхождение данных

Версионирование лабораторных результатов и планов лечения, чтобы клинические изменения были проверяемыми и отслеживаемыми.

Тонкие настройки разрешений

Защитите чувствительные элементы с помощью ACL/CLP и проверок ролей, чтобы только разрешенные клиницисты и пациенты могли к ним получить доступ.

Интегрированное сообщение

Потоковые сообщения с вложениями и необязательными обновлениями в реальном времени улучшают сотрудничество между клиницистами и пациентами.

Логирование, готовое к соблюдению норм

Централизованный AuditLog поддерживает проверки, расследование инцидентов и отчетность по соблюдению норм.

AI-помощник для начальной настройки

Начните разработку с хорошо подобранного промпта AI-Agent, который структурирует схему, ACL и базовый код интеграции.

Готовы создать безопасный портал для пациентов?

Позвольте AI-агенту Back4app создать бэкенд вашего портала для пациентов и сгенерировать профили пациентов, результаты лабораторных исследований, планы лечения, сообщения и журналы аудита из одного запроса.

Строить с AI-агентом Попробуйте API Playground

Бесплатно для начала — 50 запросов к AI-агенту в месяц, без необходимости в кредитной карте

Технический стек

Все включено в этот шаблон бэкенда портала для пациентов.

Фронтенд

13+ технологий

Бэкенд

Back4app

База данных

MongoDB

Аутентификация

Встроенная аутентификация + сессии

API

REST и GraphQL

В реальном времени

Live Queries

ER диаграмма

Модель связи сущностей для схемы бэкенда Портала Пациента.

common.erDiagramPlaceholder

Просмотреть источник диаграммы

Mermaid

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
    }

Поток интеграции

Типичный поток выполнения для аутентификации, доставки результатов лабораторных исследований, обновлений плана лечения и обмена сообщениями.

common.erDiagramPlaceholder

Просмотреть источник диаграммы

Mermaid

sequenceDiagram
  participant Patient
  participant App as Patient Portal 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 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)

  Patient->>App: View active Treatment Plan
  App->>Back4app: GET /classes/TreatmentPlan?where={"patient":Pointer("PatientProfile","p123"),"status":"active"}
  Back4app-->>App: TreatmentPlan object

  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 LabResult update
  App-->>Patient: Real-time notification (new message / result available)

  Clinician->>Back4app: Update LabResult (finalize)
  Back4app-->>App: LiveQuery event -> App fetches updated LabResult
  App-->>Patient: Alert: "New lab result available"

Словарь данных

Полная справка по полям для каждого класса в схеме Портала Пациента.

Поле	Тип	Описание	Обязательно
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 и шифрования защищают результаты лабораторных исследований, планы лечения, сообщения и журналы аудита.

Доступ и право собственности на основе ролей

Применяйте ACL, чтобы пациенты могли видеть свои собственные записи, а Provider могли видеть назначенные данные пациентов; CLP предотвращают несанкционированные операции с классами.

Зашифрованные полезные нагрузки и вложения

Храните чувствительные блобы (вложения лабораторий, PDF-файлы) за подписанными URL и используйте шифрование на уровне хранения для защиты данных в покое.

Только добавляемые журналы аудита

Записывайте записи AuditLog с серверного кода Cloud Code, чтобы гарантировать, что пользователи не могут подделать исторические записи соответствия.

Схема (JSON)

Готовое определение схемы JSON для копирования в Back4app или использования в качестве справки по реализации.

JSON

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

{
  "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-агента

Используйте AI-агента Back4app, чтобы сгенерировать приложение Портала Пациента из этого шаблона, включая схемы бэкенда, ACL и стартовую интеграцию фронтенда.

AI-агент Back4app

Готов к сборке

Создайте бэкенд Портала Пациента на Back4app с этой точной схемой и поведением.

Схема:
1. PatientProfile: user (указатель на пользователя, обязательное), fullName (строка, обязательное), dob (дата, необязательное), contact (объект), medicalRecordNumber (строка, обязательное, уникальное); objectId, createdAt, updatedAt.
2. ProviderProfile: user (указатель на пользователя, обязательное), specialty (строка), clinic (строка), contact (объект); objectId, createdAt, updatedAt.
3. LabResult: patient (указатель на PatientProfile, обязательное), Provider (указатель на ProviderProfile, обязательное), reportType (строка), resultData (объект), reportedAt (дата, обязательное), version (число, по умолчанию 1), attachments (массив файлов), visibility (строка: только для пациента, только для Provider, общий); objectId, createdAt, updatedAt.
4. TreatmentPlan: patient (указатель на PatientProfile, обязательное), Provider (указатель на ProviderProfile, обязательное), summary (строка), details (объект), status (строка: черновик, активный, завершенный), effectiveFrom (дата), effectiveTo (дата), version (число); objectId, createdAt, updatedAt.
5. Message: sender (указатель на пользователя, обязательное), recipient (указатель на пользователя, обязательное), threadId (строка, обязательное), body (строка), attachments (массив файлов), status (строка: отправлено, доставлено, прочитано), sentAt (дата); objectId, createdAt, updatedAt.
6. Appointment: patient (указатель на PatientProfile, обязательное), Provider (указатель на ProviderProfile, обязательное), scheduledAt (дата, обязательное), status (строка: запланировано, отменено, завершено), location (строка); objectId, createdAt, updatedAt.
7. AuditLog: actor (указатель на пользователя, обязательное), action (строка, обязательное), entityType (строка, обязательное), entityId (строка, обязательное), payload (объект, необязательное), createdAt (дата); objectId, createdAt, updatedAt.

Безопасность:
- Принудительное соблюдение ACL, чтобы пациенты могли только читать свои записи LabResult и TreatmentPlan. Provider видит назначенных пациентов. Используйте Cloud Code для чувствительных переходов и для записи записей AuditLog на стороне сервера. Защитите вложения подписанными URL и шифрованием хранения.

Аутентификация:
- Поддержка регистрации для пациентов и Provider; назначение ролей; безопасный вход и управление сессиями.

Поведение:
- Пациент входит в систему, получает последние версии LabResult и TreatmentPlans, отправляет сообщения в Provider потоки и получает уведомления. Provider публикует результаты лабораторных исследований и планы лечения; система записывает записи AuditLog для действий публикации.

Доставка:
- Приложение Back4app с схемой, CLP, ACL, хуками Cloud Code для публикации и аудита, а также стартовой интеграцией фронтенда для просмотра пациентами и Provider.

Нажмите кнопку ниже, чтобы открыть агента с заранее заполненным шаблоном.

Это базовый запрос без суффикса технологии. Вы можете адаптировать сгенерированный фронтенд-стек позже.

Развертывание за считанные минуты50 бесплатных подсказок / месяцКарта не требуется

API Playground

Попробуйте REST и GraphQL конечные точки против схемы Портала Пациента. Ответы используют фиктивные данные и не требуют аккаунта Back4app.

common.loadingPlayground

Использует ту же схему, что и этот шаблон.

Выберите вашу технологию

Разверните каждую карточку для шагов интеграции, паттернов состояния, примеров модели данных и заметок для оффлайна.

Что вы получаете с каждой технологией

Каждый стек использует одну и ту же схему бэкенда Patient Portal и API контракты.

Унифицированная структура данных пациента

Управляйте и получайте доступ ко всей информации о пациентах в одной схеме.

Безопасная связь для портал для пациентов

Обеспечьте безопасное общение между пациентами и представителями здравоохранения Provider.

Запись на прием в реальном времени

Позвольте пациентам без усилий записываться на прием и управлять им.

Комплексное отслеживание результатов лабораторных анализов

Позвольте пациентам безопасно просматривать и отслеживать свои результаты анализов.

Контроль доступа к конфиденциальным данным

Убедитесь, что только уполномоченные лица могут просматривать записи пациентов.

REST/GraphQL API для портал для пациентов

Легко интегрируйтесь с различными фронтендами, используя гибкие API.

Сравнение фреймворков портала для пациентов

Сравните скорость настройки, стиль SDK и поддержку ИИ для всех поддерживаемых технологий.

Фреймворк	Время настройки	Преимущество портала для пациентов	Тип SDK	Поддержка ИИ
Flutter	Быстрая (5 мин) настройка	Единая кодовая база для портала пациентов на мобильных устройствах и в вебе.	Typed SDK	Полный
React	~5 мин	Быстрая веб-панель для портала пациентов.	Typed SDK	Полный
React Native	Около 5 мин	Кросс-платформенное мобильное приложение для портала пациентов.	Typed SDK	Полный
Next.js	Менее 5 минут	Серверное веб-приложение для портала пациентов.	Typed SDK	Полный
JavaScript	~3 мин	Легкая веб-интеграция для портала пациентов.	Typed SDK	Полный
Android	Быстрая (5 мин) настройка	Нативное приложение Android для портала пациентов.	Typed SDK	Полный
iOS	~5 мин	Нативное приложение iOS для портала пациентов.	Typed SDK	Полный
Vue	Около 5 мин	React-интерфейс для портала пациентов.	Typed SDK	Полный
Angular	Менее 5 минут	Корпоративное веб-приложение для портала пациентов.	Typed SDK	Полный
GraphQL	Быстрая (2 мин) настройка	Гибкий API GraphQL для портала пациентов.	GraphQL API	Полный
REST API	~2 мин	REST API интеграция для портала пациентов.	REST API	Полный
PHP	Менее 5 мин	Серверный PHP бэкенд для портала пациентов.	REST API	Полный
.NET	Около 5 мин	.NET бэкенд для портала пациентов.	Typed SDK	Полный

Время настройки отражает ожидаемую продолжительность от начала проекта до первого входа пациента и запроса лабораторного результата с использованием этой схемы шаблона.

Часто задаваемые вопросы

Общие вопросы о создании бэкенда портала пациента с помощью этого шаблона.

Что такое бэкенд Patient Portal?

Что включает в себя шаблон Портала Пациента?

Почему стоит использовать Back4app для портала пациента?

Как мне получить последний результат анализа и его Provider в одном запросе?

Как мне отметить сообщение как прочитанное?

Может ли React Native кешировать планы лечения для оффлайн-использования?

Как мне предотвратить несанкционированное распространение PDF-файлов лаборатории?

Как лучше всего представить контекст записи на прием на мобильных устройствах?

Как работает процесс регистрации аудита от начала до конца?

Как я могу поддержать подтверждение пациентом плана лечения?

Доверие разработчиков по всему миру

Присоединяйтесь к командам, которые быстрее создают безопасные пациентские порталы с шаблонами Back4app

Готовы создать приложение для своего пациентского портала?

Начните свой проект пациентского портала за считанные минуты. Кредитная карта не требуется.

Выберите технологию