Migrarea datelor din software-ul medical vechi sau din Excel

Migrarea dintr-un software medical vechi sau din Excel se face în șase etape: inventarul datelor, exportul, maparea și curățarea, o migrare de test, o perioadă scurtă de lucru în paralel și ziua trecerii, urmată de verificare. Partea tehnică este rareori problema; datele incomplete sau duplicate și lipsa unei verificări făcute de oamenii care lucrează zilnic cu ele sunt cauzele obișnuite ale problemelor. Mai jos descriem cum arată fiecare etapă în proiectele noastre și ce să cereți furnizorului nou.

Inventarul: ce date aveți și unde sunt

Înainte de orice export, faceți o listă cu toate locurile în care clinica ține date despre pacienți. De multe ori lista este mai lungă decât pare: programul principal, o agendă online separată, foi de calcul ținute de recepție, un dosar partajat cu PDF-uri, e-mailuri cu analize trimise de pacienți.

Pentru fiecare sursă, notați:

• Pacienți: câți sunt, ce câmpuri există (nume, CNP, telefon, e-mail, adresă, data nașterii), câți au CNP completat.
• Programări: cele viitoare sunt obligatorii; cele trecute sunt utile pentru istoric și statistici.
• Istoric medical: este structurat pe câmpuri sau text liber? Este legat de pacient printr-un identificator sau doar prin nume?
• Documente generate: rapoarte, scrisori medicale, consimțăminte. Există ca fișiere sau doar ca date din care se generează la cerere?
• Fișiere încărcate: analize, imagini, scanări. Cât spațiu ocupă și cum sunt legate de pacient?
• Configurarea: medici, servicii, prețuri, programul de lucru. Acestea se refac de obicei manual în noul sistem, dar trebuie listate.

Stabiliți și cine poate face exportul. Unii furnizori oferă export din interfață, alții îl fac doar la cerere, iar uneori contractul prevede costuri sau termene pentru asta. Aflați înainte să anunțați data trecerii.

Formate de export

Formatul în care primiți datele influențează mult efortul. În ordinea preferinței noastre:

• Copie a bazei de date (de exemplu un dump SQL): cea mai completă, păstrează legăturile dintre tabele, dar cere ca structura să fie înțeleasă.
• CSV sau Excel pe entități: un fișier pentru pacienți, unul pentru programări, unul pentru consultații, cu un identificator comun. Este formatul cel mai des întâlnit și funcționează bine.
• Export prin API, dacă sistemul vechi îl oferă.
• PDF-uri per pacient: utile pentru istoric, dar greu de transformat în date structurate. De obicei le atașăm ca documente în dosarul pacientului.

Dacă veniți din Excel, cereți fișierul exact așa cum îl folosește recepția, nu o versiune „curățată” de mână. Vrem să vedem și problemele, nu doar datele bune.

Maparea și curățarea datelor

Maparea înseamnă să stabiliți pentru fiecare câmp din sistemul vechi unde ajunge în cel nou și cum se transformă. Curățarea înseamnă să rezolvați datele care nu se potrivesc. Aici se duce cea mai mare parte a timpului.

Duplicate

Același pacient apare de mai multe ori: o dată cu diacritice, o dată fără, o dată cu numărul vechi de telefon. Regula de potrivire trebuie stabilită împreună cu clinica. CNP-ul identic este un semnal sigur; numele plus data nașterii plus telefonul este un semnal bun; doar numele nu este suficient. Duplicatele nesigure nu se unesc automat, ci intră pe o listă de verificare pentru recepție.

CNP

CNP-ul românesc are o cifră de control, așa că se poate valida automat. În exporturi găsim frecvent CNP-uri cu cifre lipsă, cu spații, salvate de Excel ca număr și afișate în format științific sau completate cu valori fictive. CNP-urile invalide nu se aruncă; se importă pacientul fără CNP și se marchează pentru completare la următoarea vizită.

Telefoane și e-mailuri

Numerele apar ca 0722..., +40722..., 0040 722... sau cu puncte și spații. Le aducem la un format unic, altfel reminderele SMS nu pleacă. Adresele de e-mail se verifică pentru format și pentru greșeli evidente.

Diacritice

O problemă specifică românei. Sistemele mai vechi folosesc adesea alte codificări decât UTF-8 și literele ş și ţ cu sedilă în loc de ș și ț cu virgulă. Rezultatul: nume ca „Ştefan” și „Ștefan” par a fi persoane diferite la căutare, iar unele exporturi arată „È™” în loc de „ș”. Conversia corectă a codificării și unificarea ș/ț se fac înainte de detectarea duplicatelor, nu după.

Migrarea de test

Prima migrare nu ar trebui să fie cea finală. Facem o migrare de test pe un export complet și real, într-un mediu separat, apoi verificăm rezultatul cu un set de controale:

• Numărul de pacienți, programări și documente din sursă versus destinație, cu explicație pentru fiecare diferență.
• Un eșantion de pacienți aleși de clinică, verificați câmp cu câmp.
• Programările viitoare pe următoarele două săptămâni, comparate zi cu zi.
• Pacienți cu situații speciale: minori, nume compuse, fără CNP, cu multe vizite.

Dacă testul scoate la iveală probleme, corectăm regulile de transformare și repetăm. Este normal să fie nevoie de două sau trei runde.

Lucrul în paralel și ziua trecerii

Lucrul în paralel înseamnă că o perioadă scurtă echipa folosește noul sistem, dar cel vechi rămâne disponibil pentru consultare. Recomandăm să nu introduceți date noi în ambele sisteme: dubla introducere obosește echipa și creează diferențe. Mai sigur este așa:

1. Înghețarea. Stabiliți momentul după care nu se mai fac modificări în sistemul vechi, de obicei la finalul unei zile de lucru sau într-un weekend.
2. Exportul final imediat după înghețare.
3. Importul final, cu aceleași reguli validate la test.
4. Verificarea rapidă a numărătorilor și a programărilor din primele zile.
5. Pornirea: din acest moment, programările se fac doar în noul sistem, iar formularul de pe site trimite în noul calendar.
6. Sistemul vechi rămâne accesibil doar pentru citire, o perioadă stabilită, apoi se închide conform contractului și politicii de păstrare.

Nu uitați de site: dacă pacienții se programează online, butonul de programare trebuie mutat pe noul sistem exact în momentul trecerii. Pentru clinicile mici, Sanostory Pro include deja site-ul conectat la programări, așa că acest pas dispare.

Verificarea cu recepția și medicii

Numărătorile arată că datele au ajuns; doar oamenii care lucrează cu ele pot spune dacă sunt corecte. Rugați recepția să caute zece pacienți pe care îi cunoaște bine și să verifice datele de contact și programările. Rugați fiecare medic să deschidă dosarele câtorva pacienți recurenți și să confirme că istoricul și documentele sunt la locul lor.

Stabiliți un canal simplu pentru raportarea problemelor în primele săptămâni și o persoană din clinică responsabilă cu centralizarea lor. Majoritatea neregulilor apar în primele zile, când fiecare pacient real pune la încercare datele importate.

Ce merge de obicei prost

• Exportul vine târziu. Furnizorul vechi răspunde greu, iar data trecerii se amână. Cereți exportul de test cât mai devreme.
• Istoricul este text liber. Consultațiile vechi nu se pot împărți pe câmpuri. Soluția practică: se importă ca note sau documente atașate, lizibile, dar nestructurate.
• Fișierele nu sunt legate de pacient. Un dosar cu mii de PDF-uri numite după dată nu poate fi atribuit automat. Uneori numele pacientului este în conținut și poate fi extras, alteori nu.
• Programările recurente sau blocajele din calendar nu se exportă și trebuie refăcute manual.
• Acordurile de marketing lipsesc sau nu se pot dovedi. Pacienții fără acord documentat nu ar trebui incluși în campanii după migrare.
• Echipa nu a fost instruită înainte de ziua trecerii și revine la agenda pe hârtie.

GDPR în timpul migrării

Migrarea este o prelucrare de date de sănătate, iar clinica rămâne operatorul. Câteva reguli de bază:

• Contract de prelucrare (DPA) cu noul furnizor, semnat înainte ca acesta să primească vreun export. Verificați și ce prevede contractul cu furnizorul vechi despre export și ștergerea datelor după încheiere.
• Transfer securizat: spațiu de transfer criptat, cu acces limitat și expirare, nu atașamente pe e-mail sau stick-uri USB.
• Acces minim: doar persoanele care lucrează efectiv la migrare văd datele brute.
• Mediul de test se tratează la fel de strict ca producția, pentru că folosește date reale. După finalizare, copiile intermediare se șterg.
• Consimțămintele existente se migrează cu data și textul semnat; vedeți și ghidul nostru despre consimțământul GDPR în clinica medicală.

Detalii despre unde sunt găzduite datele după migrare și cum se face backupul găsiți pe pagina de securitate.

Pasul următor

Dacă vă gândiți să schimbați sistemul, cereți chiar de acum un export de test de la furnizorul actual. Chiar dacă decizia vine peste câteva luni, veți ști ce date puteți lua cu voi. Mai multe întrebări pentru furnizorul nou găsiți în ghidul despre cum alegeți software pentru clinica medicală.

Dacă vreți să discutăm despre migrarea clinicii voastre, programați un demo. Ne uităm împreună la sursa de date și vă spunem ce se poate muta și cât de structurat.