Användningsfall

Tjänsten uppfyller följande användningsfall för att möta de arkitekturella kraven i referens [1]:

1. Tjänstekonsument anropar aggregerande tjänst
2. Engagemangsindex notifierar aggregerande tjänst
3. Automatisk rensning av cache
4. Manuell rensning av cache

Tjänstekonsument anropar aggregerande tjänst

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

Då en tjänstekonsument anropar den aggregerande tjänsten för tidbokningar så söker den först i cachen på angivet patientId och returnerar informationen från cachen om sådan finns. Annars anropar tjänsten engagemangsindexet för att få redan på var nuvarande bokningar för angivet patientId finns, dvs hos vilka mottagningar. Därefter anropas respektive källsystem parallellt (för att minimera svarstiden) och ett aggregerat svars sätts samman. Det aggregerade svaret sparas i cachen samt returneras till tjänstekonsumenten. Cachen uppdateras också i de fall anrop misslyckats med relevant fel-information.

Respons SOAP headern "ProcessingStatus"

Teknisk information om bearbetningen sammanställs i svaret tillbaka till tjänstekonsumenten i en SOAP header med namnet "ProcessingStatus".
SOAP headern "ProcessingStatus" innehåller en lista med en rad per anropat källsystem och ger per källsystem information huruvida anropet gick bra, svaret kom dirket från cache, hur gammal den cachade informationen är. Se interoperability_headers_1.0.xsd för detaljer.

Notera att SOAP headern "ProcessingStatus" inte beskrivs i de tjänsteinteraktioner (WSDL-filer) som en aggregerande tjänst följer, detta för att kunna använda samma tjänsteinteraktioner som de underliggande tjänsteproducenterna använder. Det innebär att SOAP headern "ProcessingStatus" behöver beskrivas vid sidan av tjänsteinteraktionerna, förslagsvis som ett appendix till gällande RIV-TA version.

Not: I sekvensdiagrammet nedan är NTjP's Virtualiseringplattform bortabstraherad i syfte att öka diagrammets läsbarhet men den används i samtliga externa samband, dvs i anrop mellan den aggregerande tjänsten och konsumenter, engagemangsindex och källsystem.

Engagemangsindex notifierar aggregerande tjänst

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

Då engagemangsindex notifierar den aggregerande tjänsten om uppdaterad eller borttagen bokningsinformation så söker tjänsten först i cachen på angivet patientId. Finns ingen information i cachen för angivet patientId så ignoreras notifieringen. Finns information i cachen för angivet patientId så hämtas bokningar för de mottagningar som anges i notifieringen. För att nå respektive mottagnings källsystem används en virtuell tjänst i NTjP. Cachen uppdateras därefter med denna information eller med fel-information om anropet misslyckats.

Bokningar hämtas asynkront, dvs notifieringen från engagemangsindex bearbetas inte direkt under anropat från engagemangsindex utan läggs på en kö. För att undvika att notifieringar tappas bort pga tillfällig problem att nå källsystem osv så implementeras bearbetningen på ett robust sätt mha persistenta köer och omsändningslogik.

Tjänstekontraktet GetSubjectOfCareSchedule används istället för GetBookingDetails för att hämta bokningar från källsystemet både i fallet uppdaterad och borttagen bokningsinformation. Detta för att dels få en enklare logik för att hålla cachen i synk med källsystemet och dels för att minimera antalet anrop till källsystemet i de fall flera bokningar för en patient är uppdaterade.

Not: I sekvensdiagrammet nedan är NTjP's Virtualiseringplattform bortabstraherad i syfte att öka diagrammets läsbarhet men den används i samtliga externa samband, dvs i anrop mellan den aggregerande tjänsten, engagemangsindex och källsystem.

Automatisk rensning av cache

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

Då information om en patient varken uppdaterats eller lästs under de senaste 30 dagarna så skall tjänsten automatiskt ta bort all information om patienten ur cachen.

Manuell rensning av cache

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

Vid behov kan en administratör manuellt rensa hela eller delar av cachen. Partiell rensning kan göras för ett patientId eller en vårdmottagnings logicalAddress.