AnpherosAnpheros PlatformDevelopers

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

Aplikacja osobistego rekordu zdrowia (PHR) z FHIR

Samouczek: backend połączonego PHR na FHIR R4 — dane od osób, laboratoriów, dokumentów i urządzeń, oś czasu, IPS do udostępnienia, zgoda. Przetestowany kod.

Aplikacja osobistego rekordu zdrowia (PHR) przechowuje informacje o zdrowiu jednej osoby — wyniki, pomiary, diagnozy, leki, dokumenty — w rekordzie kontrolowanym przez tę osobę, zebranym z wielu źródeł, a nie z jednego szpitala. Najtrudniejsze nie są ekrany: trudnością jest pozyskanie danych z laboratoriów, klinik i urządzeń w użytecznej formie, śledzenie pochodzenia każdego elementu oraz umożliwienie osobie udostępniania rekordu bez utraty nad nim kontroli. Ten samouczek buduje backend aplikacji PHR opartej na HL7 FHIR R4 przy użyciu Anpheros TypeScript SDK; poniższy kod został uruchomiony na lokalnej instancji platformy z kluczem sandbox.

Powiązane, niezależne i połączone PHR

Rodzaj Gdzie dane mieszkają Ograniczenie
Powiązane (portal pacjenta szpitala) EHR dostawcy Pokazuje tylko dane tego dostawcy; zmienia się, gdy osoba zmienia lekarza
Niezależne (samodzielna aplikacja lub notatnik) Własna baza danych aplikacji Osoba wpisuje wszystko; dane rzadko opuszczają aplikację
Połączone Standardowy rekord, do którego aplikacje, laboratoria i kliniki odczytują i zapisują za zgodą osoby Wymaga standardów, zgody i pochodzenia danych

Połączony PHR jest tym, wartym budowania dzisiaj. Jest to również kierunek, w którym zmierza polityka: w Stanach Zjednoczonych certyfikowane EHR muszą oferować pacjentom dostęp do ich danych za pośrednictwem API opartych na FHIR (US Core), a w Unii Europejskiej Europejska Przestrzeń Danych Zdrowotnych daje ludziom prawo do dostępu do ich elektronicznych danych zdrowotnych i udostępniania ich wybranym dostawcom, wprowadzane etapami od 2029 roku.

Skąd pochodzą dane w PHR

  1. Osoba: pomiary domowe, objawy, przyjmowane leki, znane schorzenia. Oznacz je jako zgłoszone przez pacjenta.
  2. Wyniki badań laboratoryjnych: większość osób otrzymuje pliki PDF; niektóre laboratoria mogą wysyłać dane w formacie HL7 v2 lub CSV. Każdy wynik powinien zostać przekształcony w zakodowaną Obserwację (API wyników laboratoryjnych).
  3. Dokumenty: listy wypisowe, raporty z badań obrazowych, recepty. Zachowaj oryginalny plik, niezmieniony, obok danych strukturalnych.
  4. Urządzenia i urządzenia noszone: codzienne kroki, tętno, sen, ciśnienie krwi z Apple Health lub Health Connect (dane z urządzeń noszonych w FHIR).
  5. Dostawcy usług medycznych: w USA, dostępne dla pacjentów API FHIR szpitali i ubezpieczycieli, dostępne za pomocą SMART on FHIR; w innych miejscach, głównie dokumenty i podsumowania, takie jak International Patient Summary.

Każde źródło zapisuje dane do tego samego rekordu. O wiarygodności decyduje to, że każdy element rejestruje, kto go zapisał i z jakiego systemu pochodzi (pochodzenie danych medycznych).

Architektura

 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

Twój backend przechowuje klucz projektu (sk_test_… w piaskownicy, nigdy w aplikacji). Twoja aplikacja loguje użytkowników za pomocą własnego uwierzytelniania i komunikuje się z Twoim backendem; backend mapuje każdego użytkownika do jednego rekordu pacjenta.

Krok po kroku

Zainstaluj SDK (npm install @anpheros/sdk) i uzyskaj darmowy klucz do piaskownicy z panelu administracyjnego. Przykładowe użycie obejmuje dwuwartościowy panel lipidowy HL7 v2 (lipid-panel.hl7) i dowolny plik 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);

Wydrukowane z tego uruchomienia:

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

Wszystko powyższe jest przechowywane jako FHIR R4 — Patient, Observation, Condition, MedicationStatement, DocumentReference — dzięki czemu ten sam rekord można odczytać za pomocą dowolnego klienta FHIR (GET /fhir/R4/Patient/{id}/$everything) i przenieść w inne miejsce w nienaruszonym stanie. Wywołania /v1 w SDK stanowią uproszczony widok tych samych zasobów; API danych medycznych je wymienia.

Udostępnianie bez utraty kontroli

PHR istnieje po to, aby można go było udostępniać, na warunkach danej osoby:

Rodziny

Wiele systemów PHR jest prowadzonych przez jedną osobę dla kilku członków rodziny: dzieci, partnera, starszego rodzica. Każdej osobie należy przypisać własny rekord i połączyć go z opiekunem, zamiast mieszać dane wszystkich w jednym rekordzie. Zgoda jest następnie udzielana dla każdego rekordu indywidualnie. Model ten opisano w sekcji Dokumentacja medyczna pacjenta.

Co zbudować samodzielnie, a czego nie

Budujesz doświadczenie użytkownika: onboarding, sposób wyjaśniania wyników, przypomnienia, wykresy, język, w którym czyta dana osoba. Anpheros zapewnia rekord, standardowe formaty, zgodę, pochodzenie danych, dziennik dostępu oraz operacje laboratoryjne, dokumentowe i podsumowujące.

Czego Anpheros dzisiaj nie robi dla PHR: nie loguje się do portali pacjenta szpitala ani do amerykańskich API dostępu pacjenta w imieniu danej osoby (Twoja aplikacja może to zrobić za pomocą klienta SMART on FHIR i zapisać to, co otrzyma), nie odczytuje raportów PDF przez API i nie udziela porad medycznych. Własna aplikacja PHR firmy Anpheros, Anpheros Daily, jest zbudowana na tym samym API.

Często zadawane pytania

Czym jest osobista dokumentacja medyczna (PHR)?

Dokumentacja informacji o zdrowiu osoby, którą osoba ta przechowuje i kontroluje, zebrana z kilku źródeł — własnych wpisów, laboratoriów, klinik, urządzeń — zamiast przechowywanej przez jednego dostawcę.

Jaka jest różnica między PHR a EHR?

EHR jest przechowywany przez organizację opieki zdrowotnej i obejmuje to, co zarejestrowali jej dostawcy. PHR jest przechowywany przez osobę i może łączyć dane od wszystkich jej dostawców i urządzeń. Powiązany PHR jest oknem do EHR jednego dostawcy; połączony PHR wykorzystuje standardy do łączenia kilku źródeł.

Czy PHR powinien używać FHIR?

Jeśli dane mają być kiedykolwiek udostępniane lekarzowi, innej aplikacji lub asystentowi AI, tak: FHIR R4 udostępnia zakodowane, wersjonowane zasoby, które inne systemy już rozumieją, i jest to format interfejsów API dostępu do pacjenta w USA oraz europejskiego podsumowania pacjenta.

Jak aplikacja PHR pobiera dane ze szpitali?

W USA za pośrednictwem interfejsów API dostępu do pacjenta FHIR, które udostępniają certyfikowane EHR i wielu ubezpieczycieli, przy użyciu SMART on FHIR, aby umożliwić osobie autoryzację aplikacji. Gdzie indziej są to głównie dokumenty i podsumowania, importowane i przechowywane obok danych strukturalnych.

Gdzie aplikacja PHR powinna przechowywać klucze API?

Na swoim serwerze. Klucz projektu może odczytywać każdy rekord utworzony przez projekt, dlatego nigdy nie powinien być dostarczany w aplikacji mobilnej ani internetowej; aplikacja komunikuje się z Twoim zapleczem, a aplikacje innych osób używają OAuth za zgodą osoby.

Powiązane tematy

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

Product updates by email

New features, guides and the end of the beta. One email a month at most.

Send me occasional Anpheros Platform updates by email (new features, API changes, guides). I'll confirm by email and can unsubscribe in one click from any email. Privacy