Dacă ai căutat vreodată o aplicație pentru dosarul medical, ai dat peste acronimul FHIR. Apare în descrieri, în pagini de „securitate și conformitate”, în anunțuri despre spitale și ministere. Rareori e explicat. Ghidul acesta o face, fără să te transforme în programator: ce este FHIR, ce problemă rezolvă, ce înseamnă concret pentru tine și cum îți dai seama dacă o aplicație îl folosește cu adevărat sau doar îl scrie pe site.
Problema: fiecare sistem vorbește altă limbă
O analiză de sânge făcută într-un laborator ajunge la tine ca PDF. Aceeași analiză, în sistemul spitalului, e un rând într-o bază de date cu un format propriu. La medicul de familie e, poate, o notă liberă. Trei locuri, trei formate, nicio legătură între ele. Când vrei să le pui laolaltă, singura unealtă e omul care le citește și le rescrie.
Timp de decenii, sistemele medicale au fost construite exact așa: fiecare cu formatul lui, fiecare schimbând date cu altele doar prin „punți” scrise special, scump și fragil. Standardele mai vechi (HL7 versiunea 2, din anii '80, sau CDA) au rezolvat parțial problema pentru spitale, dar sunt greu de folosit de aplicații moderne și aproape imposibil de folosit de un om.
Ce este FHIR
FHIR (se pronunță „fire”) înseamnă Fast Healthcare Interoperability Resources. Este un standard publicat de HL7 International, organizația care de peste 35 de ani definește cum se schimbă datele medicale între sisteme. Versiunea folosită pe scară largă azi este R4 (4.0.1), publicată în 2019; o versiune nouă, R5, există din 2023, dar majoritatea sistemelor din lume, inclusiv cerințele legale din UE și SUA, se bazează pe R4.
Ideea centrală e simplă: orice informație medicală se descrie ca o resursă cu o structură cunoscută. Există o resursă pentru pacient (Patient), una pentru o analiză sau o măsurătoare (Observation), una pentru un diagnostic (Condition), una pentru un medicament prescris (MedicationRequest), una pentru o alergie (AllergyIntolerance), una pentru un vaccin (Immunization), una pentru un document (DocumentReference) și așa mai departe, în jur de 150 în total. Fiecare resursă are câmpuri definite: o Observation are un cod pentru ce s-a măsurat, o valoare, o unitate, data, cine a măsurat, pentru cine.
Resursele se scriu în JSON sau XML, formate pe care orice limbaj de programare le citește, și se transmit prin internet exact ca paginile web, prin adrese și cereri HTTP. Asta e diferența față de standardele vechi: FHIR folosește uneltele pe care orice programator le știe deja, așa că e ieftin de implementat și greu de implementat greșit.
Codurile: ca toată lumea să înțeleagă același lucru
Structura nu e de ajuns. Dacă un sistem scrie „glicemie” și altul „glucoză serică”, tot nu se înțeleg. FHIR rezolvă asta cerând coduri standard pentru conținut:
- LOINC pentru analize și măsurători: glicemia à jeun are codul 1558-6, oriunde în lume.
- SNOMED CT și ICD-10 pentru diagnostice și proceduri.
- ATC (clasificarea OMS) pentru medicamente, pe substanță activă.
- UCUM pentru unități de măsură: mg/dL și mmol/L sunt scrise identic peste tot, iar conversia e automată.
Cu structură și coduri, o resursă FHIR produsă de un laborator din Sibiu e citită corect de un spital din Viena sau de o aplicație din California, fără ca nimeni să fi scris o „punte” între ele.
Ce înseamnă pentru tine, concret
Patru lucruri, de la cel mai vizibil la cel mai important.
Datele tale pot fi mutate. Dacă dosarul tău e stocat ca FHIR, poate fi exportat complet și importat în orice alt sistem compatibil. Nu depinzi de o singură aplicație și nu ești ostaticul unui format pe care îl înțelege doar ea. „Al tău” înseamnă, în practică, „exportabil în format standard”.
Datele tale pot fi înțelese de medici. Un medic nou, un spital din altă țară, un serviciu de urgență: toate pot primi un rezumat FHIR (de obicei sub forma unui Rezumat internațional al pacientului) și îl citesc în sistemul lor, cu codurile lor, în limba lor. Nu un PDF de 40 de pagini, ci date pe care le pot căuta, filtra și compara.
Datele tale pot fi adunate. Analizele din laboratoare diferite, măsurătorile de pe ceas, medicamentele din rețete, documentele scanate: când toate sunt resurse FHIR cu coduri LOINC și date, se pot pune pe aceeași linie de timp și compara. O aplicație bună face asta automat.
Datele tale sunt protejate de un standard, nu de o promisiune. FHIR descrie și cum se dă acces la date: prin SMART on FHIR, un cadru bazat pe OAuth 2, în care tu aprobi explicit ce aplicație vede ce parte a dosarului, pentru cât timp, și poți retrage accesul. E același mecanism pe care îl folosești când „intri cu Google” într-un site, aplicat la date medicale, cu permisiuni fine (doar analizele, doar medicamentele, doar citire).
Unde e folosit deja FHIR
FHIR nu e un standard „de viitor”. E deja obligatoriu sau în uz în locuri pe care le cunoști:
- Statele Unite cer, prin lege (21st Century Cures Act, regulile ONC din 2020), ca orice sistem medical certificat să expună datele pacientului prin API FHIR R4, iar pacientul să își poată lua datele printr-o aplicație la alegere.
- Apple Health Records aduce dosarul de la sute de spitale în aplicația Sănătate de pe iPhone, prin FHIR.
- Uniunea Europeană a ales FHIR pentru formatul european de schimb al dosarului electronic (EEHRxF), pe care regulamentul EHDS îl impune statelor membre; rezumatele pacientului schimbate între țări prin MyHealth@EU sunt construite pe el.
- Marea Britanie, Olanda, Germania, țările nordice folosesc FHIR în infrastructurile naționale: de la rețeta electronică germană la dosarul olandez.
- Organizația Mondială a Sănătății a ales Rezumatul internațional al pacientului, bazat pe FHIR, pentru rețeaua globală de certificate digitale de sănătate.
Pentru tine, asta înseamnă că o aplicație care îți ține dosarul ca FHIR R4 nu e o insulă: vorbește limba în care vorbesc deja spitalele și autoritățile, acum și în următorul deceniu.
Cum recunoști o aplicație care folosește FHIR cu adevărat
Oricine poate scrie „FHIR” pe site. Întrebările de mai jos despart cuvântul de realitate.
- Pot exporta tot dosarul ca FHIR? Nu „un raport PDF”, ci un fișier cu resursele (un Bundle) pe care alt sistem îl poate importa. Dacă răspunsul e „nu” sau „doar la cerere, prin e-mail”, datele nu sunt cu adevărat ale tale.
- Au analizele coduri LOINC și unități UCUM? O aplicație care reține doar „Colesterol: 210” ca text nu poate compara cu valoarea de anul trecut din alt laborator. Una care reține codul și unitatea, poate.
- Pot da acces altcuiva, limitat și revocabil? Un medic, o clinică, o altă aplicație: cu SMART on FHIR, tu alegi ce văd și cât timp, și vezi cine a citit ce.
- Pot genera un rezumat IPS? E testul practic al „interoperabilității”: dacă aplicația poate produce rezumatul standard pe care îl citește orice spital european, structura din spate e reală.
- Au o documentație publică pentru dezvoltatori? Un API FHIR documentat, cu o declarație de capabilități (
CapabilityStatement) publică, înseamnă că alte sisteme chiar se pot conecta. Dacă nu există, „interoperabil” e doar un adjectiv.
Ce nu rezolvă FHIR
E corect să spunem și limitele. FHIR descrie formatul și transportul datelor, nu calitatea lor: o analiză greșit introdusă rămâne greșită, doar că într-un format frumos. FHIR nu îți garantează confidențialitatea; aceea vine din cine găzduiește datele, în ce țară și cu ce reguli de acces. Și FHIR nu face sistemele să vrea să schimbe date: multe spitale au API FHIR și nu îl deschid nimănui, iar legislația (în SUA, în UE prin EHDS) există tocmai ca să le oblige.
Cum folosește Anpheros FHIR
Anpheros stochează dosarul fiecărei persoane ca resurse HL7 FHIR R4 (26 de tipuri de resurse, de la Patient și Observation la DocumentReference și Consent), cu coduri LOINC, ICD-10, ATC și UCUM, în Uniunea Europeană. Aplicația Anpheros Daily este un client al aceluiași API public pe care îl folosesc clinicile și dezvoltatorii; nu există un format „intern” separat. Poți exporta oricând dosarul complet sau un rezumat IPS, validat cu validatorul oficial HL7. Accesul altor aplicații se dă prin SMART on FHIR, cu consimțământ pe o perioadă limitată, revocabil, și cu un jurnal pe care îl vezi. Documentația API și declarația de capabilități sunt publice, pe developers.anpheros.com.
Întrebări frecvente
Trebuie să știu FHIR ca să-mi folosesc dosarul?
Nu. FHIR e sub capotă. Tu vezi analize, medicamente și documente; standardul face ca ele să poată fi mutate, comparate și citite de medici. Merită să știi că există doar ca să alegi bine unde îți ții datele.
FHIR e același lucru cu dosarul electronic național?
Nu. FHIR e un format și un mod de transport; dosarul național e un sistem. Multe sisteme naționale folosesc sau adoptă FHIR, dar faptul că o țară are dosar electronic nu înseamnă că îți poți lua datele ca FHIR de acolo. În UE, EHDS va cere exact asta.
Ce diferență e între FHIR R4 și R5?
R5 (2023) aduce rafinări, dar nu e încă cerut de legislație și puține sisteme îl folosesc. R4 (2019) este baza cerințelor din SUA și UE și a implementărilor existente. O aplicație pe R4 e alegerea sigură azi; trecerea la R5 se va face gradual, cu compatibilitate.
Dacă exportul meu e FHIR, chiar pot să-l import în altă aplicație?
Dacă aplicația cealaltă acceptă import FHIR, da, cu o condiție: coduri standard. Resursele cu LOINC, ICD-10 și UCUM se mapează curat; cele cu texte libere ajung ca note. De aceea contează ca aplicația sursă să fi codificat datele de la început.
E FHIR sigur?
FHIR în sine nu e nici sigur, nici nesigur; e un format. Siguranța vine din implementare: criptare, găzduire, autentificare, consimțământ. SMART on FHIR oferă un cadru bun pentru acces controlat, dar tot trebuie să te uiți cine ține datele și unde.
Ține-ți dosarul medical la tine
Anpheros Daily păstrează simptomele, analizele, medicamentele și documentele într-un singur loc, în format standard, sub controlul tău. Planul Basic e gratuit.