Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

...

Egenskap

Beskrivning

1. En per tjänstedomän

Typfallet är att det finns en aggregerande tjänst per tjänstedomän och att den aggregande tjänstens payload är definierad av ett befintligt tjänstekontrakt i tjänstedomänen. Ett exempel kan vara tjänstedomänen för invånarens tidbokning. Den aggregerande tjänstens resultatmeddelande består av en lista av poster vars struktur definieras av tjänstekontraktet GetSubjectOfCareShedule. Det är också det tjänstekontrakt som den aggregerande tjänsten använder för att hämta data från källsystemen.

2. Mellanlagrar sökresultat

Aggregerande tjänster ska skydda källsystemen från last och minimera svarstider genom att mellanlagra (t.ex. i primärminnet) sökresultat. Det gör att endast den första sökningen på ett patientid kommer att resultera i att data hämtas från källsystemet. Därefter ligger resultatet i minnet / mellanlager. Mellanlager hålls aktuellt genom att en aggregerande tjänst prenumererar på händelser från engagemangsindex. Vid notifiering från engagemangsindex aktualiseras data för patienter som redan finns i mellanlagret, från de logiska adressater som notifieringen refererade. När en patients data inte efterfrågats eller uppdaterats på 30 dagar tas patienten bort från mellanlagret (cache) i syfte att hålla nere mängden data som mellanlagras.

Om en viss tjänsteproducent inte är tillgänglig när notifiering inkommer, bör den aggregerande tjänsten hantera omförsök periodiskt tills aktuella bokningar kunnat hämtas in till mellanlagret.

 Cachen måste hållas per tjänstekonsument eftersom olika tjänstekonsumenter har olika rättigheter som gör att tjänsteproducenten kan filtrera svaret olika beroende på vem anroparen är samt att TAK begränsar antalet logiska adressater per tjänstekonsument.

3. Söker i Engagemangsindex

Aggregerande tjänster använder engagemangsindex för att veta vilka logiska adresser som håller data av aktuellt slag om patienten. När data om en patient/invånare efterfrågas och patienten inte finns i mellanlagret, konsulteras EI för information om vilka logiska adressater (vårdmottagningar) som håller information.

4. Nationell omfattning

Aggregerande tjänster syftar till att sammanställa data från alla källsystemen i Sverige som stödjer tjänstedomänen (genom att ha tjänsteproducenter enligt domänens tjänstekontrakt). Att stödja en tjänstedomän som har en aggregerande tjänst omfattar oftast även krav på att uppdatera engagemangsindex. Det är sådana aggregerande tjänster som kravställs här, även om lösningen också ska kunna tillämpas regionalt (i en regional tjänsteplattform).

5. Gemensamt tjänstekontrakt

Aggregerande tjänster stödjer samma tjänstekontrakt som en vanlig virtuell tjänst. Det gäller även tjänsteinteraktionen (WSDL:en). Skillnaden ur konsumentens perspektiv är hur man adresserar. Man adresserar med ineras eller regions HSA-id för att hitta nationell eller regional (för regionala konsumenter) aggregerande tjänst. För att “adressera sig förbi” aggregerande tjänst (dvs gå direkt mot en enskild tjänsteproducent) används som vanligt tjänstedomänens adresseringsvärde (ex. mottagningens HSA-id för tidbokningsdomänen). 

 Dock finns en skillnad i payload för responsen: En aggregerande tjänst tillför en aggregeringsrapport i form av en header-struktur som redovisar utfallet av aggregeringen (metadata om aggregeringen).

6. Patientidentitet är obligatorisk sökparameter

Aggregerande tjänster kan bara användas för att hämta information om en patient. Även om det finns en cache som täcker flera patienter, får tjänsten inte användas för sammanställningar av data för flera patienter.

7. Samtidig hämtning av data

Aggregerande tjänster hämtar data från flera logiska adresser (beroende av patientens engagemang). För att ge så bra svarstider som möjligt, måste logiska adressater anropas parallellt.

8. Redovisning av data om anropet

Tjänstekontraktet redovisar anropsstatus för varje logisk adressat. Anropsstatus anger om data kunnat levereras eller inte. Om anropet gått bra, redovisas om data kom från källan eller från cache. Om datat hämtades från mellanlager redovisas även tidpunkt då datat överfördes från källsystemet till mellanlagret.

Om anropet inte gick bra redovisas felorsak. Felorsaker anges som Timeout eller Serverfel (detaljer från servern rapporteras vid timeout).

9. Behörighetskontroll

Den aggregerande tjänsten ingår i Tjänsteplattformen. Därför ska den inte ses som en tjänstekonsument med avseende på behörighetskontroll. När den aggregerande tjänsten anropar vitruella virtuella tjänster för att hämta data från källsystemen, är det därför HSA-id från den aggregerande tjänstens tjänstekonsument som den virtuella tjänsten ska använda vid behörighetskontroll mot tjänsteadresseringskatalogen.

Förtydligande av vad krav #9 på behörighetskontroll leder till

När en aggregerande tjänst anropar Engagemangsindex tjänst findContent() för att få reda på var den eftersökta information finns så skall den göra det i rollen som en tjänsteplattformskomponent, dvs så att anropande konsument inte behöver etablera samverkan med Engagemangsindex. Detta illustreras av följande bild:

Image Added

När sedan den aggregerande tjänsten anropar de tjänsteproducenter som enligt Engagemangsindex har eftersökt information så skall den göra det i rollen som anropande konsument:

Image Added

Här är det dock viktigt att komma ihåg att (se...)

 

Image Added