Ievads
Mūsdienās digitalizācija veselības aprūpē kļūst arvien nozīmīgāka, veicinot pacientu ērtības un efektīvāku pakalpojumu sniegšanu. Vienotais elektroniskais pieraksts nodrošinās pacientiem iespēju attālināti pārvaldīt savus pierakstus pie ārstiem dažādās veselības aprūpes iestādēs, tādējādi samazinot administratīvo slogu gan pacientiem, gan medicīnas iestādēm.
Sistēmai ir jānodrošina pacientiem vienkāršu, drošu un pieejamu veidu, kā rezervēt, mainīt vai atcelt pierakstus, kā arī pievienot elektroniskos nosūtījumus. Tāpat pacientiem būs iespēja apskatīt savu pierakstu vēsturi un saņemt paziņojumus par gaidāmajām vizītēm. Elektroniskās pierakstu sistēmas ieviešana palīdzēs uzlabot pakalpojumu plānošanu, mazinās rindas un nodrošinās efektīvāku veselības aprūpes resursu izmantošanu un plānošanu.
Realizācijai tiek izmantots FHIR Api, versija R5.
Galvenie iemesli, lai izmantotu FHIR R5 datu apmaiņu
Vienkāršota datu struktūra: FHIR izmanto vienkāršotu un viegli izprotamu datu struktūru. Dati ir strukturēti loģiskās vienībās (Resources): pacienti, vizītes, pakalpojumi, pieraksti, nosūtījumi utt. Katru resursu var apstrādāt, validēt un paplašināt neatkarīgi.
RESTful API: HL7 FHIR specifikācija ietver RESTful API (piekļuves programmēšanas saskarni), kas nodrošina vieglāku un elastīgāku piekļuvi datiem. RESTful API darbībām ar datiem ļauj izmantot standarta HTTP protokola metodes, piemēram, GET, POST, PUT un DELETE. Tas padara FHIR integrāciju vienkāršu un ātru.
JSON un XML formāti: FHIR atbalsta gan JSON, gan XML datu formātus, kas padara to piemērotu dažādām tehnoloģijām un platformām. JSON formāts ir vieglāk lasāms un kompakti strukturēts, kas atvieglo datu apstrādi, kamēr XML formāts piedāvā iespējas sarežģītākai datu apmaiņai un validācijai, balstoties uz kompleksu datu struktūru atbalstu, izmantojot pielāgotus tagus, atribūtus un hierarhisku datu strukturējumu.
Modulāra pieeja: FHIR piedāvā modulāru pieeju, izmantojot resursus, kas ir mazākas, neatkarīgas informācijas vienības. Tas ļauj organizācijām izvēlēties un integrēt tikai tos resursus, kas ir nepieciešami konkrētām vajadzībām, tādējādi samazinot integrācijas kompleksitāti.
Atbalsts nozares standartiem: FHIR tiek aktīvi atbalstīts un izstrādāts nozares ekspertu vadībā, kā arī tiek plaši pieņemts un izmantots veselības aprūpes nozarē. Tas nodrošina, ka FHIR būs uzticams ilgtermiņa risinājums veselības aprūpes datu apmaiņai.
Tvērums
Biznesa procesi, kuriem priekšanalīzes gaitā tiek veidots apraksts.
No integratoru puses: B1.0 Biznesa process: Jauna darba laika iesūtīšanas process; B1.1 Biznesa process: Eksistējoša darba laika atcelšanas process; B1.2 Biznesa process: Eksistējoša darba laika rezervēšanas process; B1.3 Biznesa process: Jauna pieraksta iesūtīšanas process (ja nav nosūtījuma) B1.4 Biznesa process: Jauna pieraksta iesūtīšanas process uz valsts apmaksātu pakalpojumu ar e-nosūtījumu; B1.5 Biznesa process: Jauna pieraksta iesūtīšanas process ar papīra nosūtījumu B1.6 Biznesa process: Esoša pieraksta labošanas process B1.7 Biznesa process: Jauna pieraksta dzēšanas/atcelšanas process B1.8 Biznesa process: Apstiprinājuma saņemšana par pacienta ierašanos un neierašanās fakta fiksēšana
No portāla puses: B2.0 Biznesa process: Eksistējoša darba laika rezervēšanas process; B2.1 Biznesa process: Jauna pieraksta izveides process no portāla puses; B2.2 Biznesa process: Pieraksta atcelšanas process no portāla puses, ja nav nosūtījuma; B2.3 Biznesa process: Jauna pieraksta izveides process no portāla puses, ja pacientam ir nosūtījums; B2.4 Biznesa process: Jauna pieraksta atcelšanas process no portāla puses, ja pieraksts ir saistīts ar nosūtījumu; B2.5 Biznesa process: Esoša pieraksta maiņa uz nosūtījuma pamata, mainot iestādi, ārstu vai laiku (MVP pieeja); B2.6 Biznesa process: Pieraksts uz valsts apmaksātu laiku pie tiešās pieejamības speciālista (TPS), bez nosūtījuma; B2.7 Biznesa process: Pieraksts uz valsts apmaksātu laiku ar papīra nosūtījumu; B2.8 Biznesa process: Papīra nosūtījuma datu dzēšana pēc pieraksta atcelšanas; B3.0 Pieraksta veidošana delegātiem.
Arhitektūra
Iedzīvotājs autentificējas caur STS, izmantojot eParakstu vai Smart-ID. Pēc autentifikācijas viņš nonāk E-veselības portālā, kur frontend daļa “e-pieraksts” strādā caur BFF un OpenAPI, piekļūstot datiem no kešatmiņas un datubāzes. Pierakstu dati tiek saņemti un apstrādāti caur FHIR API, kas savienots ar servisiem – kalendāra datu apmaiņai un pierakstu datu apmaiņai. Šie servisi nodrošina to ka portāls un ārstniecības iestāde reālā laikā apmainās ar pierakstu datiem, brīvo vietu datiem, rezervācijām un citu nepieciešamo informāciju. Papildu tam, klasifikatori tiek apstrādāti atsevišķā servisā, ar datu apmaiņu caur SFTP.
Integrācijas principi
Sistēmas integrācija izstrādātajam jārealizē tādā veidā, lai integrēta sistēma turpina darboties bez traucējumiem, ja NVD FHIR resursu struktūras tiek papildinātas ar jaunajiem laukiem.
Par šāda veida izmaiņām integratori tiks bridināti, bet laiks veikt pielāgojumus netiks paredzēts.
Piemēram, ja FHIR API attīstoties, pacienta struktūrai tiks pievienota delegātu informācija (kas salīdzinājumā ar esošo struktūru ir jauns lauks jeb CDA valodā - jauna sekcija), integrātori saņems informatīvo vēstuli, bet izmaiņas tiks ieviestas, izejot no apsvēruma, ka integratoriem izmaiņas nav jāveic, lai integrēta sistēma turpinātu darboties.
Nākamo kārtu prasības
Ieteicamie attīstības virzieni nākamajās izstrādes kārtās:
- Paplašināts pakalpojumu klāsts, uz kuriem ļaut piedzīvotājiem pierakstīties:
2.kārta: Ambulatorie izmeklējumi. Ņemot vērā, ka otru lielāko daļu pakalpojumu veido dažādi ambulatorie izmeklējumi, tad to izstrāde ir paredzēta otrajā kārtā un vispārīgi aprakstīta priekšanalīzes dokumentā. Veicot šīs kārtas izstrādes pasūtīšanu, ir jāveic papildus analīze noteiktos aspektos un jāpieņem lēmumi par izvēlēto pieeju (piemēram, dokumentā aprakstītais princips: viens nosūtījums – viens pakalpojums – viens pieraksts) izvēlētais risinājums. Kā arī citi lēmumi par piemērotāko risinājumu, ja šāda lēmuma pieņemšana ir minēta priekšanalīzes dokumentā.
3.kārta: Citi ambulatori pakalpojumi. Par kuru prioritāti attiecībā uz ieviešanu jāvienojas uzsākto darbs pie nākamajām kārtām. - Atgādinājumu un informatīvo paziņojumu sistēma: Izstrādāt mehānismus paziņojumu nosūtīšanai pacientiem par gaidāmajiem, atceltajiem pierakstiem.
- Pieraksta labošana: Iespējot pacientam labot jau izveidotu pierakstu (piemēram, mainīt datumu vai laiku), ievērojot noteiktos ierobežojumus (piemēram, ne vēlāk kā 24h pirms vizītes).
- Kalendāra sinhronizācija: Nodrošināt iespēju pacientam lejuplādēt pierakstu kā standarta kalendāra notikumu (.ics formātā) vai sinhronizēt ar personīgo kalendāru (Google Calendar, Outlook u.c.).
- Pieraksta vēlmes un gaidīšanas rindas funkcionalitāte: Ieviešama iespēja pacientiem izteikt vēlmi pierakstīties, ja konkrētā brīdī nav pieejami brīvi laiki. Izstrādāt risinājumu gaidīšanas rindas uzturēšanai, ar iespēju ārstniecības iestādei piesaistīt pacientu, kad atbrīvojas pieraksta laiks.
- Objektīva pieraksta datu reģistrācija: Nodrošināt strukturētu informāciju par to, kad pacients ir veicis pierakstu un kad pakalpojums ir saņemts. Šādi dati nepieciešami ārstniecības programmu (piemēram, zaļā vai dzeltenā koridora) efektivitātes izvērtēšanai.
- Nosūtījumu digitalizācija pacienta iniciatīvā (izvērtēšanai): Izvērtēt iespēju nodrošināt pacientam nosūtījuma digitalizāciju pieraksta brīdī, ievērojot drošības, datu kvalitātes un pārejas perioda nosacījumus.
- Profesionāļu portāla pilnvērtīga pieraksta funkcionalitāte: Šobrīd profesionāļu portālā iespējams tikai rezervēt nosūtījumu pierakstam. Nākotnē jānodrošina iespēja ārstam no profesionāļu portāla veikt reālu pierakstu konkrētā laikā uz konkrētu pakalpojumu.
- Automatizēta rindu pārvaldība: Izstrādāt funkcionalitāti, kas ļauj automātiski pārvaldīt rindas, piemēram, analizēt pieejamos laikus un nosūtīt ieteikumus vai pieraksta uzaicinājumus pacientiem.
- Saziņas mehānismi: Nodrošināt iespēju ārstiem un iestādēm nosūtīt pacientiem informatīvus materiālus, atgādinājumus, uzaicinājumus vai citus nozīmīgus ziņojumus, balstoties uz konkrētām veselības situācijām vai programmām.
- Pieraksta atcelšana: Ja pacients atcēlis vizīti vairākas reizes un nav ieradies, šīs reizes uzskaitīt un brīdināt ĀI ar kādu pazīmi, ka šis pacients mēdz bieži vizītes neapmeklēt.
- Pakalpojumu apraksta pievienošana: Informācija par to kā sagatavoties pakalpojumam, redzams pacientam pirms ierašanās uz vizīti. Piemēram: kas ir mamogrāfijas izmeklējumam un ko tādā izmeklējumā veic un ar ko pacientam rēķināties. E-bibliotēka, no Digitālās veselības stratēģija līdz 2029. gadam.
- Liegumi"Liegums citiem redzēt pacienta pierakstus.
- Apmeklējuma tips: Saņemt no integratora apmeklējuma tipu – pirmreizēja, atkārtota vizīte un citi tipi, kas aprakstīti https://terminology.hl7.org/5.1.0/ValueSet-v2-0276.html. Lietošanas gadījumi jāapraksta.
- Automatizēta validācija pēc pacienta vecuma: Sistēmā jāievieš automatizēta validācijas funkcionalitāte, kas pārbauda pacienta vecumu attiecībā pret konkrētā pakalpojuma vai speciālista prasībām. Piemēram, pieraksts pie bērnu ārsta būs pieejams tikai pacientiem līdz noteiktam vecumam, savukārt noteikti pakalpojumi būs pieejami tikai pieaugušajiem vai senioriem. Validācija jāveic reāllaikā pieraksta izveides brīdī gan portālā, gan caur API, nodrošinot, ka lietotājs nevar pabeigt pierakstu, ja pacienta vecums neatbilst pakalpojuma prasībām.
- Automātiska mirušu pacientu pierakstu apstrāde: Sistēmai jānodrošina automātiska pacientu pierakstu apstrāde gadījumos, kad pacientam tiek saņemta informācija par miršanu. Pēc miršanas fakta saņemšanas sistēma automātiski atceļ visus aktīvos pierakstus, neradot papildu paziņojumus pacientam vai viņa delegātiem. Tāpat jānosūta atbilstošs paziņojums attiecīgajai ārstniecības iestādei (ĀI), informējot, ka pacients ir miris un šī pacienta pierakstu dati jāapstrādā atbilstoši noteiktajām datu aizsardzības prasībām. Nepieciešams nodrošināt, ka mirušo pacientu dati tiek pārvaldīti droši, ar iespēju auditēt izmaiņas, kā arī izstrādāt detalizētus scenārijus, ja nāves fakts tiek saņemts pēc vizītes vai tās laikā.
- Pieraksta veidošana personai, kas nav delegātu sarakstā: Persona (lietotājs) vēlas pierakstīt citu personu (pacientu), kura nav viņa pārstāvēto personu (delegātu) sarakstā un nav devusi elektronisku deleģējumu. Šāda situācija var rasties, piemēram, ja persona mutiski ir lūgusi palīdzību (piemēram, kaimiņš, radinieks), bet pats objektīvu iemeslu dēļ nevar izmantot Iedzīvotāju portālu.