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

Személyes egészségügyi nyilvántartó (PHR) alkalmazás FHIR-rel

Oktatóanyag: egy csatlakoztatott PHR backendje FHIR R4-en – adatok emberektől, laboroktól, dokumentumoktól és eszközöktől, idővonal, megosztható IPS, beleegyezés. Tesztelt kód.

A személyes egészségügyi nyilvántartás (PHR) alkalmazás egy személy egészségügyi adatait — eredmények, mérések, diagnózisok, gyógyszerek, dokumentumok — tárolja egy olyan nyilvántartásban, amelyet az illető személy irányít, és amelyet sok forrásból gyűjtöttek össze, nem pedig egyetlen kórházból. A nehéz részek nem a képernyők: hanem az adatok laborokból, klinikákról és eszközökről való bevitele használható formában, annak nyomon követése, hogy az egyes tételek honnan származnak, és annak lehetővé tétele, hogy az illető megossza a nyilvántartást anélkül, hogy elveszítené felette az irányítást. Ez a tutorial egy PHR backendjét építi fel HL7 FHIR R4-en az Anpheros TypeScript SDK segítségével; az alábbi kódot egy helyi példányon futtatták a platformmal egy sandbox kulccsal.

Hozzáerősített, független és csatlakoztatott PHR-ek

A csatlakoztatott PHR az, amit ma érdemes megépíteni. Ez az, amerre a politika is halad: az Egyesült Államokban a tanúsított EHR-eknek FHIR-alapú API-hozzáférést kell biztosítaniuk a betegeknek az adataikhoz (US Core), az Európai Unióban pedig az Európai Egészségügyi Adattér (European Health Data Space) jogot ad az embereknek arra, hogy hozzáférjenek elektronikus egészségügyi adataikhoz, és megosszák azokat a választott szolgáltatókkal, fokozatosan bevezetve 2029-től.

A PHR adatai honnan származnak

1. A személy: otthoni mérések, tünetek, szedett gyógyszerek, ismert állapotok. Jelölje őket beteg által jelentettként.
2. Laboreredmények: a legtöbb ember PDF-et kap; néhány labor küldhet HL7 v2 vagy CSV formátumot. Minden eredménynek kódolt megfigyeléssé kell válnia (Lab results API).
3. Dokumentumok: zárójelentések, képalkotó leletek, vények. Tartsa meg az eredeti fájlt, változatlanul, a strukturált adatok mellett.
4. Eszközök és viselhető eszközök: napi lépésszám, pulzusszám, alvás, vérnyomás az Apple Health vagy a Health Connect szolgáltatásból (wearable data in FHIR).
5. Szolgáltatók: az Egyesült Államokban kórházak és biztosítók beteg-hozzáférésű FHIR API-jai, amelyek SMART on FHIR segítségével érhetők el; máshol főként dokumentumok és összefoglalók, mint például a Nemzetközi Betegösszefoglaló (International Patient Summary).

Minden forrás ugyanabba a rekordba ír. Ami megbízhatóvá teszi, az az, hogy minden elem rögzíti, ki írta és melyik rendszerből származik (medical data provenance).

Az architektúra

 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

A backend tárolja a projektkulcsot (sk_test_… a sandboxban, soha az alkalmazásban). Az Ön alkalmazása a saját hitelesítésével jelenteti be a felhasználókat, és a backenddel kommunikál; a backend minden felhasználót egy páciensrekordhoz rendel.

Lépésről lépésre

Telepítse az SDK-t (npm install @anpheros/sdk), és szerezzen ingyenes sandbox kulcsot a dashboardról. A minta egy két eredményes HL7 v2 lipid panelt (lipid-panel.hl7) és bármilyen PDF-et (report.pdf) használ.

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);

A futtatásból kinyomtatva:

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

A fenti minden elem FHIR R4 formátumban tárolódik – Patient, Observation, Condition, MedicationStatement, DocumentReference –, így ugyanaz a rekord bármilyen FHIR klienssel (GET /fhir/R4/Patient/{id}/$everything) olvasható, és sértetlenül áthelyezhető máshová. Az SDK-ban található /v1 hívások az erőforrások egyszerűbb nézetét kínálják; a Medical data API részletezi ezeket.

Megosztás kontrollvesztés nélkül

A PHR (Személyes Egészségügyi Nyilvántartás) megosztásra szolgál, a személy feltételei szerint:

• Orvossal: az International Patient Summary ($summary) egy FHIR dokumentum, amelyet klinikusoknak készítettek – problémák, gyógyszerek, allergiák, eredmények –, amelyet az Ön alkalmazása megjeleníthet, kinyomtathat vagy elküldhet. A FHIR platform leírja a $summary és a $everything.
• Egy másik alkalmazással: a másik alkalmazás hozzájárulást kér OAuth 2.1 és SMART on FHIR segítségével; a személy kiválasztja, mely adatokat (például csak laboratóriumi eredményeket) és mennyi időre, és bármikor visszavonhatja azt. A Hogyan implementáljuk a beteg hozzájárulását a SMART on FHIR segítségével részletesen bemutatja.
• AI asszisztenssel: a POST /v1/context egy költségvetésű, forrásmegjelöléssel ellátott összefoglalót készít a rekordról egy modell számára, és az olvasás megjelenik a hozzáférési naplóban (Hogyan készítsünk AI egészségügyi alkalmazást).
• Átláthatóság: minden olvasási és írási művelet, bármely alkalmazás által, alkalmazásonként naplózásra kerül, és a személy láthatja a naplót és az aktív engedélyeket.

Családok

Számos PHR-t egy személy tart fenn több személy számára: gyermekek, partner, idős szülő. Minden személynek adjon saját rekordot, és kapcsolja össze őket a gondozóval, ahelyett, hogy mindenki adatait egybe keverné. Az engedély ezután rekordonként adható meg. A Beteg kórtörténeti nyilvántartása leírja a modellt.

Mit érdemes saját magadnak megépíteni, és mit nem

Te építed meg a felhasználói élményt: az onboardingot, az eredmények magyarázatát, az emlékeztetőket, a diagramokat, a személy által olvasott nyelvet. Az Anpheros biztosítja a rekordot, a standard formátumokat, a hozzájárulást, a származást, a hozzáférési naplót, valamint a laboratóriumi, dokumentum és összefoglaló műveleteket.

Amit az Anpheros ma nem végez el egy PHR (Személyes Egészségügyi Rekord) számára: nem jelentkezik be kórházi betegportálokra vagy amerikai beteg-hozzáférésű API-kra a személy nevében (az alkalmazásod ezt megteheti egy SMART on FHIR klienssel és rögzítheti, amit kap), nem olvas PDF jelentéseket az API-n keresztül, és nem ad orvosi tanácsot. Az Anpheros saját PHR alkalmazása, az Anpheros Daily, ezen a ugyanazon az API-n alapul.

Gyakran ismételt kérdések

Mi az a személyes egészségügyi nyilvántartás (PHR)?

Egy személy egészségügyi információinak nyilvántartása, amelyet az illető vezet és ellenőriz, több forrásból gyűjtve – saját bejegyzések, laborok, klinikák, eszközök – ahelyett, hogy egyetlen szolgáltató tartaná nyilván.

Mi a különbség a PHR és az EHR között?

Az EHR-t egy egészségügyi szervezet vezeti, és az általa rögzített információkat tartalmazza. A PHR-t az illető vezeti, és az összes szolgáltatótól és eszköztől származó adatokat egyesítheti. A "tethered" PHR egy ablak egy szolgáltató EHR-jére; a "connected" PHR szabványokat használ több forrás összekapcsolására.

Használjon-e a PHR FHIR-t?

Ha az adatokat valaha is meg kell osztani egy orvossal, egy másik alkalmazással vagy egy AI asszisztenssel, akkor igen: az FHIR R4 kódolt, verziós erőforrásokat biztosít, amelyeket más rendszerek már ismernek, és ez a beteg-hozzáférésű API-k formátuma az Egyesült Államokban, valamint az európai betegösszefoglalóé.

Hogyan szerez be adatokat egy PHR alkalmazás a kórházakból?

Az Egyesült Államokban a FHIR beteg-hozzáférésű API-kon keresztül, amelyeket a tanúsított EHR-ek és sok biztosító kínál, a SMART on FHIR használatával engedélyezve az illető az alkalmazást. Másutt ez többnyire dokumentumok és összefoglalók, amelyeket strukturált adatok mellett importálnak és tárolnak.

Hol tárolja a PHR alkalmazás az API kulcsokat?

A szerverén. Egy projekt kulcs minden olyan rekordot képes olvasni, amelyet a projektje létrehozott, ezért soha nem szabad mobil- vagy webalkalmazásba beépíteni; az alkalmazás a backendjével kommunikál, és mások alkalmazásai OAuth-ot használnak a személy beleegyezésével.

Kapcsolódó

• Egészségügyi alkalmazás fejlesztése: általános útmutató
• Beteg kórtörténete: mit tartalmaz a rekord, és ki férhet hozzá
• Digitális orvosi nyilvántartási infrastruktúra
• Viselhető eszközök adatai FHIR formátumban: Apple Health, Health Connect és Samsung Health
• Laboreredmények API
• SDK-k

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