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. 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.

3. 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).

4. 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).

5. Patientidentitet är obligatorisk sökparameter

Aggregerande tjänster skall bara användas för att hämta information om en patient.

6. 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.

7. Redovisning av data om anropet

Tjänstekontraktet redovisar anropsstatus för varje logisk adressat. Anropsstatus anger om data kunnat levereras eller inte.

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

8. 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 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.

När det finns flera versioner av kontrakt med aggregering uppstår ett “randfall” som det är viktigt att logiken i aggregerande tjänster kan hantera. 
Beskrivning av “randfall”: 

• Det finns två (eller fler) huvudversioner av ett kontrakt i bruk 
• Kontraktet har aggregering i tjänsteplattformen 
• Det finns tjänsteproducenter som stödjer båda versionerna av kontraktet eftersom det finns tjänstekonsumenter som förlitar sig på gamla versionen samtidigt som det finns tjänstekonsumenter som förlitar sig på den nya versionen (eller på båda för att få med alla producenter oavsett version) 
• Posterna i Engagemangsindex anger inte version (detta vill vi inte ändra på) av kontrakt 

Krav vid randfall enligt ovan: 

• En tjänstekonsument som anropar en aggregerande tjänst ska INTE få fel-rapporter (i aggregeringsheadern) från de källsystem som bara har stöd för den andra versionen. 
• En tjänstekonsument som anropar en aggregerande tjänst ska INTE orsaka att anrop förmedlas vidare till tjänsteproducenter som bara stödjer den andra versionen. 

Tankar kring lösning: 
Att Aggregerande tjänster - efter svar från EI - via TAK-info matchar källsystemet OCH kontraktsversion innan anrop sker, så att EI-poster som logiskt pekar ut producent som - enligt TAK - saknar stöd för den version som aggregerande tjänsten är.