AnpherosAnpheros PlatformDevelopers

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

App di cartella sanitaria personale (PHR) con FHIR

Tutorial: il backend di una PHR connessa su FHIR R4 — dati da persone, laboratori, documenti e dispositivi, una cronologia, un IPS da condividere, consenso. Codice testato.

Un'app di cartella clinica personale (PHR) conserva le informazioni sanitarie di una persona — risultati, misurazioni, diagnosi, farmaci, documenti — in un registro che la persona controlla, raccolti da molteplici fonti anziché da un singolo ospedale. Le parti difficili non sono le schermate: sono l'acquisizione dei dati da laboratori, cliniche e dispositivi in una forma utilizzabile, il tracciamento della provenienza di ogni elemento e il consentire alla persona di condividere il registro senza perderne il controllo. Questo tutorial costruisce il backend di una PHR su HL7 FHIR R4 con l'SDK TypeScript Anpheros; il codice seguente è stato eseguito su un'istanza locale della piattaforma con una chiave sandbox.

PHR collegati, non collegati e connessi

Tipo Dove risiedono i dati Limitazione
Collegato (il portale pazienti di un ospedale) L'EHR del fornitore Mostra solo i dati di quel fornitore; cambia quando la persona cambia medico
Non collegato (un'app autonoma o un quaderno) Il database dell'app La persona digita tutto; i dati raramente escono dall'app
Connesso Un record standard che app, laboratori e cliniche leggono e scrivono con il consenso della persona Richiede standard, consenso e provenienza sottostanti

Un PHR connesso è quello che vale la pena costruire oggi. È anche ciò verso cui si sta muovendo la politica: negli Stati Uniti, gli EHR certificati devono offrire ai pazienti l'accesso tramite API basate su FHIR ai propri dati (US Core), e nell'Unione Europea lo Spazio Europeo dei Dati Sanitari (EHDS) conferisce alle persone il diritto di accedere ai propri dati sanitari elettronici e di condividerli con i fornitori di loro scelta, con attuazione graduale a partire dal 2029.

Da dove provengono i dati di un PHR

  1. La persona: misurazioni domestiche, sintomi, farmaci assunti, condizioni note. Marcarli come segnalati dal paziente.
  2. Referti di laboratorio: la maggior parte delle persone riceve PDF; alcuni laboratori possono inviare HL7 v2 o CSV. Ogni risultato dovrebbe diventare un'Osservazione codificata (API referti di laboratorio).
  3. Documenti: lettere di dimissione, referti di imaging, prescrizioni. Conservare il file originale, invariato, accanto ai dati strutturati.
  4. Dispositivi e wearable: passi giornalieri, frequenza cardiaca, sonno, pressione sanguigna da Apple Health o Health Connect (dati wearable in FHIR).
  5. Provider: negli Stati Uniti, API FHIR di accesso ai pazienti di ospedali e assicuratori, raggiunte con SMART on FHIR; altrove, principalmente documenti e riepiloghi come l'International Patient Summary.

Ogni sorgente scrive nello stesso record. Ciò che lo rende affidabile è che ogni elemento registra chi l'ha scritto e da quale sistema (provenienza dei dati medici).

L'architettura

 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

Il tuo backend detiene la chiave del progetto (sk_test_… nella sandbox, mai nell'app). La tua app effettua l'accesso delle persone con la tua autenticazione e parla con il tuo backend; il backend mappa ciascun utente a un record paziente.

Passaggi

Installa l'SDK (npm install @anpheros/sdk) e ottieni una chiave sandbox gratuita dalla dashboard. L'esempio utilizza un pannello lipidico HL7 v2 a due risultati (lipid-panel.hl7) e un PDF qualsiasi (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);

Stampato da quella esecuzione:

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

Tutto quanto sopra è memorizzato come FHIR R4 — Patient, Observation, Condition, MedicationStatement, DocumentReference — quindi lo stesso record può essere letto con qualsiasi client FHIR (GET /fhir/R4/Patient/{id}/$everything) e spostato altrove intatto. Le chiamate /v1 nell'SDK sono una vista semplificata delle stesse risorse; API dati medici le elenca.

Condivisione senza perdere il controllo

Un PHR esiste per essere condiviso, secondo i termini della persona:

Famiglie

Molti PHR sono gestiti da una persona per più individui: figli, un partner, un genitore anziano. Assegna a ciascuna persona il proprio record e collegalo al tutore, anziché mescolare i dati di tutti in uno solo. Il consenso viene quindi concesso per record. Cartella clinica del paziente descrive il modello.

Cosa costruire da soli e cosa no

Costruisci l'esperienza: onboarding, come vengono spiegati i risultati, promemoria, grafici, la lingua che la persona legge. Anpheros fornisce il record, i formati standard, il consenso, la provenienza, il log di accesso e le operazioni di laboratorio, documenti e riepilogo.

Ciò che Anpheros non fa oggi per un PHR: non accede ai portali pazienti ospedalieri o alle API di accesso ai pazienti statunitensi per conto della persona (la tua app può farlo con un client SMART on FHIR e scrivere ciò che riceve), non legge report PDF tramite l'API e non fornisce consulenza medica. L'app PHR di Anpheros, Anpheros Daily, è costruita sulla stessa API.

Domande frequenti

Cos'è un Personal Health Record (PHR)?

Un registro delle informazioni sanitarie di una persona che la persona stessa conserva e controlla, raccolto da diverse fonti — i propri inserimenti, laboratori, cliniche, dispositivi — piuttosto che essere conservato da un singolo fornitore.

Qual è la differenza tra un PHR e un EHR?

Un EHR è conservato da un'organizzazione sanitaria e copre ciò che i suoi fornitori hanno registrato. Un PHR è conservato dalla persona e può combinare dati da tutti i suoi fornitori e dispositivi. Un PHR "tethered" (collegato) è una finestra sull'EHR di un singolo fornitore; un PHR "connected" (connesso) utilizza standard per unire diverse fonti.

Un PHR dovrebbe usare FHIR?

Se i dati devono essere condivisi con un medico, un'altra app o un assistente AI, sì: FHIR R4 fornisce risorse codificate e versionate che altri sistemi già comprendono, ed è il formato delle API di accesso al paziente negli Stati Uniti e del European patient summary.

Come fa un'app PHR a ottenere dati dagli ospedali?

Negli Stati Uniti, tramite le API di accesso al paziente FHIR che gli EHR certificati e molti assicuratori espongono, utilizzando SMART on FHIR per consentire alla persona di autorizzare l'app. Altrove si tratta principalmente di documenti e riassunti, importati e archiviati accanto ai dati strutturati.

Dove dovrebbe un'app PHR conservare le chiavi API?

Sul tuo server. Una chiave di progetto può leggere ogni record creato dal tuo progetto, quindi non deve mai essere inclusa in un'app mobile o web; l'app comunica con il tuo backend e le app di altre persone utilizzano OAuth con il consenso della persona.

Correlati

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