Projekts

LDVC e-nosūtījumu projekts nodrošina specifikāciju, uz tās bāzētu FHIR RESTful API projektējumu¹ un vadlīnijas nosūtījumu datu apmaiņai. Specifikācijas pamatā ir HL7 FHIR R5 versija un darbaplūsmas pārvaldības principi.

Projekta ietvaros ir realizēta speciālistu tīmekļa vietne, kurā ĀP un ĀAP ir iespēja savu pilnvaru ietvaros:

• veidot,
• labot,
• apskatīt,
• rezervēt nosūtījumus,
• kā arī veikt atzīmes par ĀP pieprasītā pakalpojuma sniegšanas statusu.

---

Tvērums

Pirmā izstrādes kārta paredz nosūtījumu datu apmaiņu tikai ambulatoriem pacientiem, t.i., nosūtījums tiek izveidots ambulatorās aprūpes epizodes ietvaros.

Pakalpojums nosūtījumā tiek pieprasīts tikai vienam pacientam (fiziskai personai). Nav iespējams pieprasīt pakalpojumu pacientu grupai, dabas objektiem, dzīvniekiem utml.

Nosūtījumā ĀP var pieprasīt ambulatorā, stacionārā un dienas stacionāra pakalpojuma sniegšanu pacientam.

Pirmajā kārtā nav iespējams izveidot nosūtījumu uz VDEĀVK, aprūpi mājās un citus specifiskus nosūtījumus, kā arī nav iespējams izveidot nosūtījumu dinamiskai novērošanai.

Digitalizētie pamata procesi:

• Nosūtījuma izveidošanas process
  ĀP un ĀAP var izveidot, labot, anulēt un atcelt nosūtījumus. Var apskatīt pacienta nosūtījumus vai sevis veidotos nosūtījumus.

• Nosūtījuma rezervācijas process
  Reģistrators var apskatīt pacienta nosūtījumu sarakstu un mainīt pieprasījuma izpildes statusu, piemēram, kad pacients tiek pierakstīts pakalpojuma saņemšanai vai atsakās no pieraksta.

• Nosūtījuma izpildes process
  Pacientam ierodoties pakalpojuma saņemšanai, reģistrators var mainīt pieprasījuma izpildes statusu, norādot, ka pakalpojums ir sniegts un/vai pabeigts.

Detalizēti ĀP, ĀAP un reģistratoru darbības ar nosūtījumiem tiek aprakstītas sadaļā Lietojumi.

---

Procesa dalībnieki

Nosūtījumu procesi paredz divus galvenos dalībnieku veidus:

• Pakalpojuma pieprasījuma veicējs (Placer)
• Pakalpojuma sniedzējs jeb pieprasījuma izpildītājs (Filler)

Abas šīs lomas nosūtījumu izveidošanā un izpildē spēlē ĀP.

Nosūtījumu rezervācijā piedalās ĀI reģistratori un pacienti, bet pirmās kārtas tvērumā pacients var rezervēt nosūtījumu tikai sazinoties ar ĀI pieraksta veikšanai.

FHIR serveris ir trešais procesa dalībnieks, kas nodrošina pieprasītāja un sniedzēja mijiedarbību.

---

Mijiedarbība

Shēma atspoguļo pakalpojuma pieprasītāja mijiedarbību ar pakalpojuma sniedzēju, izmantojot FHIR serveri kā starpnieku.

 

Vienkāršots dalībnieku mijiedarbības process:

1. Pakalpojuma pieprasījuma izveide
   Ārstniecības persona izveido nosūtījumu, un ĀP sistēma to iesniedz FHIR serverī.

2. Jauna pieprasījuma saņemšana
   FHIR serveris uzrauga ienākošos nosūtījumus un saņem ziņu par jaunu pieprasījumu.

3. Izpildes uzdevuma izveide
   Serveris izskata pieprasījumu un izveido atbilstošu izpildes uzdevumu.

4. Nosūtījumu un uzdevumu izgūšana pierakstam
   Pacientam pieprasot pierakstu pakalpojuma sniedzēja iestādē, reģistrators izgūst nosūtījumus ar tiem saistītajiem izpildes uzdevumiem.

5. Pieraksta apstiprināšana
   Ja tiek identificēts nosūtījums pieraksta veikšanai, reģistrators iesniedz pieraksta informāciju un atjauno izpildes uzdevuma statusu.

6. Pieraksta maiņa vai atcelšana
   Ja pacients pieprasa citu pieraksta laiku vai atsakās no pieraksta, reģistrators iesniedz esošā pieraksta atcelšanu un atjauno izpildes uzdevuma informāciju. Ja pacients vēlas jaunu pierakstu, reģistrators atceļ esošo pierakstu, iesniedz jaunu pierakstu un atjauno izpildes uzdevuma informāciju.

7. Pakalpojuma sniegšana
   Pacientam ierodoties, pakalpojums tiek sniegts.

8. Pieraksta un uzdevuma atjaunošana pēc pakalpojuma
   Pēc pakalpojuma sniegšanas ĀP vai reģistrators atjauno pieraksta informāciju, norādot, ka tas ir veiksmīgi izmantots, un atjauno izpildes uzdevuma statusu kā izpildītu.

9. Izpildes uzdevuma izmaiņu uzraudzība
   Serveris uzrauga izpildes uzdevuma izmaiņas un saņem ziņu, ka uzdevums ir izpildīts.

10. Nosūtījuma statusa atjaunošana
    Serveris atjauno nosūtījuma informāciju, norādot, ka pieprasījums ir izpildīts.

11. Pieprasījuma veicēja sistēmas informēšana
    Pieprasījuma veicēja sistēma uzrauga nosūtījuma izmaiņas un saņem ziņu, ka pieprasījums ir izpildīts.

---

Pieņēmumi

Lai sāktu nosūtījumu datu apmaiņu, FHIR serverī jābūt pieejamiem:

• ĀP un to darbavietu dati,
• pacientu ieraksti,
• klasifikatoru dati.

Turklāt ĀI sistēmām jānodrošina šādu apgabalu integrācija ar LDVC FHIR R5 serveri:

• pacienta datu izgūšana;
• jauna pacienta datu reģistrācija;
• pacienta datu labošana;
• ĀP datu meklēšana un izgūšana;
• ĀI datu meklēšana un izgūšana;
• ĀP darbavietu datu meklēšana un izgūšana;
• kodēšanas sistēmu un klasifikatoru datu izgūšana.

---

Drošības apsvērumi

Pacientu, ĀP un ĀAP datu drošības nodrošināšanai FHIR serverī tiek izmantota drošā lietotāju autentifikācija un autorizācija.

FHIR API pieprasījumi tiek autorizēti tikai lietotājiem ar derīgu VVIS STS izsniegtu JWT drošības talonu, kas ir izsniegts FHIR5 apgabalam. Vadlīnijas JWT iegūšanai no VVIS STS pieejamas šeit.

---

⚠️ Svarīgi: No STS izgūtais JWT ir jālieto visā tā derīguma perioda laikā, neveicot jaunus drošības talona pieprasījumus!

---

🔒 Drošības prasība: LDVC testa un produkcijas vidē biznesa datu iesniegšanai un nolasīšanai var autorizēties tikai ar drošo ĀP vai ĀAP drošības talonu, t.i., autentificēta ārsta talonu, nevis tehnisko lietotāju.

---

🚫 Integrāciju ierobežojums: Integratori, kuri ir integrējušies ar Covid API, Vivat IS vai citu LDVC RESTful API, nevar pārizmantot JWT, kas tiek izmantots autorizācijai minētajās sistēmās, lai autorizētos FHIR API.

---

Attīstības vīzija

Projekta attīstības kārtās ir paredzēts uzlabot pakalpojumu klasifikāciju, pakāpeniski pārejot uz SNOMED CT kodēšanas sistēmu gan pakalpojumu klasifikācijai, gan arī citos klasificētajos datos, kā arī realizēt specifiskus nosūtījumu veidus.

Tāpat plānots papildināt funkcionalitāti ar:

• pakalpojumu saņemšanas instrukciju iesniegšanu,
• papildu pacienta mērījumu un izmeklējumu iesniegšanu.

Pēc rezultātu datu apmaiņas projektu īstenošanas kļūs iespējams uzlabot arī apmaksas talonu iesniegšanas procesu, to maksimāli automatizējot, izmantojot rezultātu iesniegšanu kā pamatu talona automātiskai veidošanai un nosūtījumu kā pamatojumu NVD veikšanai.