MRN-formaatin fragmentaatio-ongelma
Yhdysvalloissa on noin 6 100 sairaalaa, joista jokainen käyttää omaa sähköistä potilastietojärjestelmäänsä, jossa on oma Potilastunnusformaattinsa. Kansallista MRN-standardia ei ole. Yhteinen komissio, joka akkreditoi terveydenhuoltojärjestöjä, määrittelee, että MRN:ien on yksilöitävä potilaat järjestelmän sisällä — mutta ei määrittele formaattia.
Seurauksena: MRN-formaatit luonnossa sisältävät 7-numeron kokonaislukuja, 8-numeron kokonaislukuja, vaihtelevan pituisia alfanumeerisia merkkijonoja, muotoiltuja merkkijonoja etuliitekoodeilla (HOSP-, MRN-, PT-, PAT-), instituutioiden koodeja eteenpäin liitettynä (SVHS-, CHOP-, MDACC-) ja päivämäärä-koodattuja formaatteja, joissa rekisteröintivuosi on upotettu numeroon.
HIPAA:n Safe Harbor -de-identifiointimenetelmä luettelee Potilastunnukset 18 tunnisteen kategoriassa 8, jotka on poistettava (45 CFR Section 164.514(b)(2)). Vaatimus ei ole sidottu formaattiin — kaikkien organisaation käyttämien MRN-formaattien on oltava havaittavissa ja poistettavissa. Organisaatio, joka käsittelee kliinisiä muistiinpanoja ilman, että se havaitsee niiden erityistä MRN-formaattia, ei saavuta HIPAA Safe Harbor -de-identifiointia riippumatta siitä, mitä muita tunnisteita poistetaan.
Koodauseste
Tavanomainen lähestymistapa mukautetun MRN-formaatin lisäämiseksi de-identifiointiputkeen edellyttää formaatin toteuttamista Presidion mukautetussa tunnistajakehyksessä. Tämä sisältää:
Python-luokan kirjoittamisen, joka laajentaa EntityRecognizeria, määrittelee regex-kaavan erityiselle MRN-formaatille, toteuttaa analyze()-menetelmän, joka soveltaa kaavaa, lisää tunnistajan Presidio-rekisteriin, testaa toteutuksen edustavilla näytteillä ja ylläpitää toteutusta, kun formaatti kehittyy.
Kliinisten informatiikan tiimeille, joilla ei ole Python-osaamista — mikä kuvaa suurinta osaa terveydenhuollon vaatimustenmukaisuus- ja tietosuojahenkilöstöstä — tämä luo riippuvuuden insinööritiimistä jokaisessa formaattimuutoksessa. Terveydenhuollon organisaatioissa insinöörivaroja kohdennetaan tyypillisesti EHR-integraatioon ja kliiniseen päätöksentukeen, ei vaatimustenmukaisuusvälineiden konfigurointiin.
AI-kaavojen apuri
AI-avusteinen kaavojen luontimenetelmä korvasi koodausprosessin ohjatulla käyttöliittymällä:
Kliininen informatiikan tiimi avaa Mukautetun Entiteetin Luojan verkkosovelluksessa. He antavat 5 näytearvoa MRN:stä järjestelmästään (SVHS-0012345, SVHS-0987654, SVHS-1122334, SVHS-4455667, SVHS-8899001). He napsauttavat "Generoi kaava." AI analysoi näyte-rakenteen ja palauttaa: kaava SVHS-d{7} vastaa annettuja esimerkkejä; luottamustaso korkea; ehdotettu entiteettinimi: HOSPITAL-MRN; ehdotettu korvaus: [MRN]; testaa lisänäytteillä validointia varten.
Tiimi antaa 5 lisätestinäytettä. Kaava validoituu oikein. Mukautettu entiteetti tallennetaan HIPAA-vaatimustenmukaisuuden esiasetukseen. Kaikki seuraavat de-identifiointisessiot — verkkosovellus, Office-lisäosa, työpöytäsovellus ja API — havaitsevat SVHS-formaatin MRN:ät automaattisesti osana standardia PHI-havaitsemisprosessia.
GDPR:n tutkimuspoikkeus artiklan 89 mukaan vaatii pseudonymisointia ja tietojen minimointia tutkimusdatan osalta. Mukautettu entiteetin luonti varmistaa, että instituutioiden erityiset tunnisteet sisältyvät pseudonymisoinnin piiriin — sulkien kattavuusaukot, jotka yleiset työkalut jättävät auki omille formaateille.
Lähteet: