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

Aplicație de dosar personal de sănătate (PHR) cu FHIR

Tutorial: backend-ul unui PHR conectat pe FHIR R4 — date de la persoane, laboratoare, documente și dispozitive, o cronologie, un IPS de partajat, consimțământ. Cod testat.

O aplicație de dosar personal de sănătate (PHR) păstrează informațiile de sănătate ale unei persoane — rezultate, măsurători, diagnostice, medicamente, documente — într-un dosar pe care persoana îl controlează, colectate din multiple surse, nu dintr-un singur spital. Părțile dificile nu sunt ecranele: acestea sunt obținerea datelor de la laboratoare, clinici și dispozitive într-o formă utilizabilă, urmărirea originii fiecărui element și permiterea persoanei să partajeze dosarul fără a pierde controlul asupra acestuia. Acest tutorial construiește backend-ul unui PHR pe HL7 FHIR R4 cu SDK-ul TypeScript Anpheros; codul de mai jos a fost rulat pe o instanță locală a platformei cu o cheie sandbox.

PHR-uri legate, nelegate și conectate

Tip	Unde trăiesc datele	Limitare
Legat (portalul pacientului unui spital)	EHR-ul furnizorului	Afișează doar datele acelui furnizor; se schimbă când persoana își schimbă medicul
Nelegat (aplicație sau carnet independent)	Baza de date proprie a aplicației	Persoana tastează totul; datele rareori părăsesc aplicația
Conectat	Un registru standard pe care aplicațiile, laboratoarele și clinicile îl citesc și scriu cu consimțământul persoanei	Necesită standarde, consimțământ și proveniență dedesubt

Un PHR conectat este cel care merită construit astăzi. Este, de asemenea, direcția către care se îndreaptă politicile: în Statele Unite, EHR-urile certificate trebuie să ofere pacienților acces API bazat pe FHIR la datele lor (US Core), iar în Uniunea Europeană, Spațiul European pentru Datele din Sănătate oferă persoanelor dreptul de a accesa datele lor electronice de sănătate și de a le partaja cu furnizorii aleși de ei, implementat treptat începând cu 2029.

De unde provin datele unui PHR

Persoana: măsurători de acasă, simptome, medicamente pe care le ia, afecțiuni despre care știe. Marcați-le ca fiind raportate de pacient.
Rapoarte de laborator: majoritatea oamenilor primesc PDF-uri; unele laboratoare pot trimite HL7 v2 sau CSV. Fiecare rezultat ar trebui să devină o observație codificată (API pentru rezultate de laborator).
Documente: scrisori de externare, rapoarte imagistice, rețete. Păstrați fișierul original, neschimbat, alături de datele structurate.
Dispozitive și dispozitive purtabile: pași zilnici, ritm cardiac, somn, tensiune arterială de la Apple Health sau Health Connect (date de la dispozitive purtabile în FHIR).
Furnizori: în SUA, API-uri FHIR de acces pentru pacienți ale spitalelor și asigurătorilor, accesate cu SMART on FHIR; în alte părți, în principal documente și rezumate, cum ar fi International Patient Summary.

Fiecare sursă scrie în același registru. Ceea ce îl face de încredere este faptul că fiecare element înregistrează cine l-a scris și din ce sistem (proveniența datelor medicale).

Arhitectura

 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

Backend-ul tău deține cheia proiectului (sk_test_… în sandbox, niciodată în aplicație). Aplicația ta autentifică utilizatorii cu propria ta autentificare și comunică cu backend-ul tău; backend-ul mapează fiecare utilizator la un singur înregistrare de pacient.

Pas cu pas

Instalați SDK-ul (npm install @anpheros/sdk) și obțineți o cheie gratuită de sandbox din dashboard. Exemplul folosește un panou lipidic HL7 v2 cu două rezultate (lipid-panel.hl7) și orice fișier 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);

Tipărit din acea rulare:

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

Tot ce este mai sus este stocat ca FHIR R4 — Patient, Observation, Condition, MedicationStatement, DocumentReference — astfel încât același fișier poate fi citit cu orice client FHIR (GET /fhir/R4/Patient/{id}/$everything) și mutat în altă parte intact. Apelurile /v1 din SDK sunt o vizualizare mai simplă a acelorași resurse; API-ul de date medicale le listează.

Partajare fără a pierde controlul

Un PHR există pentru a fi partajat, în termenii persoanei:

Cu un medic: International Patient Summary ($summary) este un document FHIR creat pentru clinicieni — probleme, medicamente, alergii, rezultate — pe care aplicația dvs. îl poate afișa, imprima sau trimite. Platforma FHIR descrie $summary și $everything.
Cu o altă aplicație: cealaltă aplicație solicită consimțământul prin OAuth 2.1 și SMART on FHIR; persoana alege ce date (de exemplu, doar rezultatele de laborator) și pentru cât timp, și le poate revoca oricând. Cum să implementați consimțământul pacientului cu SMART on FHIR detaliază acest proces.
Cu un asistent AI: POST /v1/context creează un rezumat bugetat, etichetat sursa, al dosarului pentru un model, iar citirea apare în jurnalul de acces (Cum să construiți o aplicație AI pentru sănătate).
Transparență: fiecare citire și scriere, de către orice aplicație, este înregistrată per aplicație, iar persoana poate vedea jurnalul și permisiunile active.

Familii

Multe dosare medicale personale (PHR) sunt gestionate de o singură persoană pentru mai mulți indivizi: copii, un partener, un părinte în vârstă. Acordați fiecărei persoane propriul dosar și legați-l de tutore, în loc să amestecați datele tuturor într-unul singur. Consimțământul este apoi acordat per dosar. Dosarul medical al pacientului descrie modelul.

Ce să construiți singur și ce nu

Dumneavoastră construiți experiența: onboarding, modul în care sunt explicate rezultatele, memento-uri, grafice, limbajul pe care îl citește persoana. Anpheros oferă înregistrarea, formatele standard, consimțământul, proveniența, jurnalul de acces și operațiunile pentru laboratoare, documente și rezumate.

Ce nu face Anpheros astăzi pentru un PHR: nu se autentifică în portalurile pacienților spitalicești sau în API-urile de acces pentru pacienți din SUA în numele persoanei (aplicația dvs. poate face acest lucru cu un client SMART on FHIR și poate scrie ceea ce primește), nu citește rapoarte PDF prin API și nu oferă sfaturi medicale. Aplicația PHR proprie a Anpheros, Anpheros Daily, este construită pe același API.

Întrebări frecvente

Ce este un dosar medical personal (PHR)?

Un dosar al informațiilor de sănătate ale unei persoane pe care persoana respectivă îl păstrează și îl controlează, adunat din mai multe surse — propriile înregistrări, laboratoare, clinici, dispozitive — în loc să fie păstrat de un singur furnizor.

Care este diferența dintre un PHR și un EHR?

Un EHR este păstrat de o organizație de sănătate și acoperă ceea ce au înregistrat furnizorii săi. Un PHR este păstrat de persoană și poate combina date de la toți furnizorii și dispozitivele sale. Un PHR legat (tethered PHR) este o fereastră către EHR-ul unui furnizor; un PHR conectat (connected PHR) utilizează standarde pentru a aduce împreună mai multe surse.

Ar trebui un PHR să folosească FHIR?

Dacă datele vor fi vreodată partajate cu un medic, o altă aplicație sau un asistent AI, da: FHIR R4 oferă resurse codificate și versionate pe care alte sisteme le înțeleg deja și este formatul API-urilor de acces la pacienți în SUA și al rezumatului european al pacientului.

Cum obține o aplicație PHR date de la spitale?

În SUA, prin API-urile de acces la pacienți FHIR pe care EHR-urile certificate și mulți asigurători le expun, utilizând SMART on FHIR pentru a permite persoanei să autorizeze aplicația. În alte părți, sunt în mare parte documente și rezumate, importate și stocate alături de date structurate.

Unde ar trebui o aplicație PHR să păstreze cheile API?

Pe serverul dumneavoastră. O cheie de proiect poate citi fiecare înregistrare creată de proiectul dumneavoastră, deci nu trebuie niciodată trimisă într-o aplicație mobilă sau web; aplicația comunică cu backend-ul dumneavoastră, iar aplicațiile altor persoane utilizează OAuth cu consimțământul persoanei.

Conexe

Construiți o aplicație de sănătate: ghidul general
Fișa medicală a pacientului: ce conține fișa și cine îi poate accesa
Infrastructura fișelor medicale digitale
Date de la dispozitive purtabile în FHIR: Apple Health, Health Connect și Samsung Health
API pentru rezultate de laborator
SDK-uri

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