Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Приложение персональной медицинской карты (PHR) с FHIR

Руководство: бэкенд подключенной PHR на FHIR R4 — данные от людей, лабораторий, документов и устройств, временная шкала, IPS для обмена, согласие. Проверенный код.

Приложение для ведения личной медицинской карты (PHR) хранит медицинскую информацию одного человека — результаты анализов, измерения, диагнозы, лекарства, документы — в записи, которую контролирует сам человек. Эти данные собираются из множества источников, а не из одной больницы. Сложности заключаются не в интерфейсах: они в получении данных из лабораторий, клиник и от устройств в удобном для использования виде, отслеживании происхождения каждого элемента и предоставлении человеку возможности делиться картой, не теряя над ней контроля. Данное руководство описывает бэкенд PHR на HL7 FHIR R4 с использованием Anpheros TypeScript SDK; приведенный ниже код был запущен локально на экземпляре платформы с использованием sandbox-ключа.

Привязанные, автономные и подключенные PHR

Тип	Где хранятся данные	Ограничение
Привязанные (портал пациента больницы)	EHR поставщика услуг	Отображает только данные этого поставщика; меняется при смене врача
Автономные (отдельное приложение или блокнот)	Собственная база данных приложения	Человек вводит все вручную; данные редко покидают приложение
Подключенные	Стандартная запись, которую приложения, лаборатории и клиники читают и записывают с согласия человека	Требует стандартов, согласия и происхождения данных

Подключенный PHR — это то, что стоит создавать сегодня. Это также то, к чему движется политика: в Соединенных Штатах сертифицированные EHR должны предоставлять пациентам доступ к своим данным через API на основе FHIR (US Core), а в Европейском Союзе Европейское пространство данных здравоохранения (European Health Data Space) дает людям право доступа к своим электронным медицинским данным и их передачи выбранным поставщикам услуг, поэтапно с 2029 года.

Откуда берутся данные PHR

Человек: домашние измерения, симптомы, принимаемые лекарства, известные заболевания. Отметьте их как сообщенные пациентом.
Лабораторные отчеты: большинство людей получают PDF-файлы; некоторые лаборатории могут отправлять HL7 v2 или CSV. Каждый результат должен стать кодированным наблюдением (Lab results API).
Документы: выписные письма, отчеты об исследованиях, рецепты. Сохраните исходный файл без изменений рядом со структурированными данными.
Устройства и носимые гаджеты: ежедневные шаги, частота сердечных сокращений, сон, артериальное давление из Apple Health или Health Connect (wearable data in FHIR).
Поставщики медицинских услуг: в США — FHIR API больниц и страховщиков с доступом для пациентов, к которым осуществляется доступ с помощью SMART on FHIR; в других странах — в основном документы и сводки, такие как International Patient Summary.

Каждый источник записывает данные в одну и ту же запись. Достоверность обеспечивается тем, что каждый элемент записывает, кто его создал и из какой системы (medical data provenance).

Архитектура

 person ──► your PHR app (mobile / web) ──► your backend ──► Anpheros: one FHIR R4 record per person
                                               │                 ├─ Observations, Conditions, Medications, Documents…
   lab report, PDF, device data ───────────────┘                 ├─ Provenance on every write
                                                                 ├─ access log the person can see
   other apps, doctors, AI assistants ◄── consent (OAuth) ───────┴─ $summary (IPS) to share

Ваш бэкенд хранит ключ проекта (sk_test_… в песочнице, никогда в приложении). Ваше приложение выполняет вход пользователей с помощью собственной аутентификации и взаимодействует с вашим бэкендом; бэкенд сопоставляет каждого пользователя с одной записью пациента.

Пошаговое руководство

Установите SDK (npm install @anpheros/sdk) и получите бесплатный ключ для песочницы на панели управления. В примере используется двухрезультатный HL7 v2 липидный профиль (lipid-panel.hl7) и любой PDF-файл (report.pdf).

import { readFile } from 'node:fs/promises';
import { Anpheros, apiKey } from '@anpheros/sdk';

const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

// 1. One record per person who signs up in your PHR app
const jane = await anpheros.patients.create({ given: 'Jane', family: 'Doe', birth_date: '1984-07-19', gender: 'female' });

// 2. Something the person measured at home
await anpheros.observations.create(jane.id, {
  code: '85354-9', category: 'vital-signs', effective_at: '2026-10-01T08:30:00-05:00', author_type: 'patient',
  components: [{ code: '8480-6', value: 128, unit: 'mm[Hg]' }, { code: '8462-4', value: 82, unit: 'mm[Hg]' }],
});

// 3. A diagnosis and a medication the person reports
await anpheros.conditions.create(jane.id, { code: 'E11.9', system: 'http://hl7.org/fhir/sid/icd-10',
  display: 'Type 2 diabetes mellitus without complications', clinical_status: 'active', onset: '2021-03-15', author_type: 'patient' });
await anpheros.medications.create(jane.id, { code: 'A10BA02', display: 'Metformin 500 mg', status: 'active',
  dosage: '500 mg twice a day', start: '2021-03-20', author_type: 'patient' });

// 4. A lab report the person received, as the lab sent it (HL7 v2)
const lab = await anpheros.labs.importHl7(jane.id, await readFile('lipid-panel.hl7', 'utf8'), { sourceSystem: 'springfield-lis' });

// 5. A PDF they want to keep with the record
const doc = await anpheros.documents.upload(jane.id,
  { title: 'Chest X-ray report', kind: 'imaging_report', content_type: 'application/pdf', date: '2026-10-03' },
  await readFile('report.pdf'));

// 6. One timeline for the home screen
const timeline = await anpheros.timeline.list(jane.id, { limit: 10 });

// 7. A summary to share with a new doctor: the International Patient Summary
const ips = await anpheros.fhir.summary(jane.id);

// 8. Who else can read this record (empty until the person consents to another app)
const grants = await anpheros.grants.of(jane.id);

Напечатано из этого запуска:

lab:       created 2, unmapped []
document:  final
timeline:  2026-10-03  document    Chest X-ray report
           2026-10-02  observation Cholesterol in HDL [Mass/volume] in Serum or Plasma
           2026-10-02  observation Cholesterol [Mass/volume] in Serum or Plasma
           2026-10-01  observation Blood pressure panel
           2021-03-20  medication  Metformin 500 mg
           2021-03-15  condition   Type 2 diabetes mellitus without complications
IPS:       Allergies, Medications, Problems, Results, Vital signs
grants:    0

Все вышеперечисленное хранится в формате FHIR R4 — Patient, Observation, Condition, MedicationStatement, DocumentReference — поэтому ту же запись можно прочитать с помощью любого FHIR-клиента (GET /fhir/R4/Patient/{id}/$everything) и переместить в другое место без изменений. Вызовы /v1 в SDK представляют собой упрощенное представление тех же ресурсов; Medical data API перечисляет их.

Совместное использование без потери контроля

PHR существует для того, чтобы им можно было делиться на условиях пользователя:

С врачом: International Patient Summary ($summary) — это документ FHIR, предназначенный для клиницистов — проблемы, лекарства, аллергии, результаты — который ваше приложение может отображать, печатать или отправлять. FHIR platform описывает $summary и $everything.
С другим приложением: другое приложение запрашивает согласие через OAuth 2.1 и SMART on FHIR; пользователь выбирает, какими данными (например, только лабораторными результатами) и на какой срок, и может отозвать его в любое время. How to implement patient consent with SMART on FHIR подробно описывает этот процесс.
С AI-ассистентом: POST /v1/context создает суммированный, помеченный источниками отчет для модели с указанием бюджета, и доступ к нему отображается в журнале доступа (How to build an AI healthcare app).
Прозрачность: каждое чтение и запись любым приложением регистрируется по каждому приложению, и пользователь может просматривать журнал и активные разрешения.

Семьи

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

Что создавать самостоятельно, а что нет

Вы создаете пользовательский опыт: онбординг, объяснение результатов, напоминания, графики, язык, на котором читает пользователь. Anpheros предоставляет запись, стандартные форматы, согласие, происхождение данных, журнал доступа, а также операции с лабораторными данными, документами и сводками.

Что Anpheros сегодня не делает для PHR: он не выполняет вход в больничные порталы пациентов или API доступа пациентов США от имени пользователя (ваше приложение может сделать это с помощью клиента SMART on FHIR и записать полученные данные), он не читает PDF-отчеты через API и не дает медицинских советов. Собственное PHR-приложение Anpheros, Anpheros Daily, построено на этом же API.

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

Что такое персональная медицинская карта (PHR)?

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

В чем разница между PHR и EHR?

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

Должна ли PHR использовать FHIR?

Если данные когда-либо будут передаваться врачу, другому приложению или AI-ассистенту, то да: FHIR R4 предоставляет кодированные, версионированные ресурсы, которые другие системы уже понимают, и это формат API для доступа пациентов в США, а также европейской сводки данных пациента.

Как приложение PHR получает данные из больниц?

В США — через API для доступа пациентов FHIR, которые предоставляют сертифицированные EHR и многие страховщики, используя SMART on FHIR, чтобы позволить человеку авторизовать приложение. В других странах это в основном документы и сводки, импортируемые и хранящиеся рядом со структурированными данными.

Где приложение PHR должно хранить API-ключи?

На вашем сервере. Ключ проекта может читать каждую запись, созданную вашим проектом, поэтому он никогда не должен передаваться внутри мобильного или веб-приложения; приложение взаимодействует с вашим бэкендом, а приложения других людей используют OAuth с согласия пользователя.

Связанные материалы

Создание медицинского приложения: общее руководство
Медицинская карта пациента: что содержит карта и кто имеет к ней доступ
Инфраструктура цифровых медицинских карт
Данные носимых устройств в FHIR: Apple Health, Health Connect и Samsung Health
API результатов лабораторных исследований
SDK

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card