Transakcijas

FHIR transakciju nodrošinājums

FHIR transakcijas sniedz divas būtiskas iespējas:

  • Lietotājs var izmantot vienu pieprasījumu, kurā apvienotas vairākas darbības, ko citādi vajadzētu veikt ar atsevišķiem pieprasījumiem.
  • Transakcija nodrošina datu izmaiņu atomaritāti - darbības nekad neizpildīsies daļēji.

Tā vietā, lai izpildītu atsevišķus pieprasījumus, dati par šiem virtuālajiem pieprasījumiem (metode, atsevišķi galvenes lauki, ķermenis) jāievieto transaction tipa Bundle resursā, ko ar vienu FHIR API pieprasījumu lietotājs iesniedz sistēmai izpildē.

Sistēma atbalsta transakcijas ar POST un PUT darbībām.
Sistēma neatbalsta darbības ar Binary tipa resursiem.
Katras transakcijas Bundle resursam jāatbilst kādam specializētam profilam.
Sistēma transakcijas apstrādā asinhroni ().

Transakcijas iesniegšana izpildei

HTTP metode: POST
URL: [base]/
Galvenes lauki: analogi POST, PUT pieprasījumiem
Ķermenis: transaction tipa Bundle resurss (aprakstīts nākamajā sadaļā)

Bundle resursa izveide

Struktūra

Lietotājs izpildāmo darbību definēšanai izveido Bundle resursu, ievērojot sekojošo:

  1. Bundle.type = transaction: Šī vērtība nosaka Bundle resursa tipu.
  2. Bundle.entry masīva elementos tiek definētas darbības ar resursiem, norādot datus par darbību un resursa jauno versiju.
  3. Bundle.entry.request: Jānorāda dati par darbību - virtuālo pieprasījumu.
  4. Bundle.entry.resource: Resurss, kas atbilst virtuālā pieprasījuma ķermenim.
  5. Bundle.entry.fullUrl: Lokālais identifikators

Bundle.entry.request jānorāda sekojoša informācija par virtuālo pieprasījumu:

entry.request apakšelements vērtības obligāts
method POST, PUT: virtuālā pieprasījuma metode jā
url virtuālā pieprasījuma relatīvais URL jā
ifMatch PUT pieprasījuma galvenes lauka If-Match analogs nē

Lokālais identifikators Bundle.entry.fullUrl ir domāts, lai lokāli, Bundle ietvaros identificētu Bundle.entry - darbību vai tieši jauno resursu. Tam jāatbilst šādiem noteikumiem:

  • Jābūt unikālam UUID vai absolūtam URL.
  • PUT gadījumā jābūt obligāti, turklāt tam jābūt URL un tā noslēgumam jāsakrīt ar šī resursa pieejas relatīvo URL bez norādes uz versiju (/_history/[vid]).
  • POST gadījumā parasti lieto UUID (urn:uuid:[UUID]), taču var lietot arī absolūto URL, ar pereizi norādītu resursa tipu, bet fiktīvu ID (piem. https://musu.cels/Observation/jauns).
  • Ja tas ir URL, tam nav jāsākas ar konkrētās sistēmas FHIR API bāzes ceļu (arī tad, ja resurss eksistē sistēmā). Tādējādi transakcijas Bundle var atkārtoti izmantot vairākās testa vidēs.

References

Ja resursi, kas ietverti transakcijas Bundle resursā satur references viens uz otru, referencē jānorāda fullUrl vērtība.
Tādējādi, ja tiek lietota kaut viena reference uz jaunradāmu resursu (POST metode), šim resursam ir jānorāda fullUrl (citādi tas nav obligāti).
Jaunas resursa versijas izveides gadījumā (PUT metode) refrence uz šo resursu var būt kā parasta reference ar relatīvo URL vai kā lokālā reference (resursa fullUrl vērtība).

Tā kā sistēma uztur arī versiju bāzētas references, ir iespējams izveidot lokālu referenci uz iekļauta resursa jauno versiju (jauna resursa gadījumā versija būs "1", bet atjaunināta resursa gadījumā mēs versijas numuru ne vienmēr varam zināt):

  1. Referencētajam resursam kā fullUrl ir jālieto absolūtais URL.
  2. Referencē jālieto šī fullUrl vērtība, kas papildināta ar /_history/[versija], kur versija var būt jebkurš string - sistēma pati to nomainīs uz izveidotās versijas id (piem., https://musu.cels/Observation/jauns/_history/labs).

Izpildes rezultāts

Izpildes rezultāts iegūstams kā aprakstīts nodaļā Asinhronie datu izmaiņu pieprasījumi.

Atbildes ziņojums

  • sekmīgas izpildes gadījumā ir transaction-response tipa Bundle resurss,
  • nesekmīgas izpildes gadījumā ir OperationOutcome resurss.

Ja transakcija beigusies veiksmīgi, rezultāts satur ziņojumu par katru operāciju (Bundle.entry.response saraksts), kas sarindoti tādā pat secībā, kādā operācijas tika norādītas transakcijā.
📌 Tieši atbilžu (Bundle.entry elementu) secība ir tas, kas nosaka atbilžu piederību virtuālajiem pieprasījumiem.

Sekmīgas transakcijas izpildes gadījumā katras operācijas rezultāts (Bundle.entry.response) satur informāciju, kas būtu atgriezta parasta pieprasījuma gadījumā:

  • status: HTTP kods, kas tiktu atgriezts pieprasījuma atbildē;
  • location: relatīvais ceļš uz jauno resursa versiju, kas tiktu atgriezts pieprasījuma atbildes galvenes laukā Location;
  • etag: jaunizveidotās versijas ID, kas tiktu atgriezts pieprasījuma atbildes galvenes laukā ETag;
  • lastModified: jaunās resursa versijas izveides laiks, kas tiktu atgriezts pieprasījuma atbildes galvenes laukā Last-Modified.