...

Utgåvehistorik

...

1          Inledning

Detta dokument är en övergripande beskrivning för RIV Tekniska Anvisningar. Det beskriver principerna som styr utveckling av de tekniska anvisningar, vilka strategier som valts för att tillmötesgå principerna, samt övriga krav på innehållet i enskilda anvisningar.

...

...

Detta gäller i alla led - alltså även vid federerade arkitekturer där en virtuell tjänst i tjänsteplattformen dirigerar en tjänstebegäran till en tjänsteproducent som i själva verket visar sig vara en virtuell tjänst i en regional tjänsteplattform, se Error! Reference source not found. Figur 6 på sidan 21se figur 6 ovan. Adresseringen i en tjänsteplattform riktas alltid till ”nästa” system nedströms, dvs tjänsteproducenten ur tjänsteplattformens perspektiv.

...

1. Aktuellt tjänstekontrakt måste vara realiserat som virtuell tjänst i samtliga tjänsteplattformar som deltar i informationsflödet.
2. Den ursprungliga tjänstekonsumenten anropar sin lokala plattform, RTP-1 på vanligt sätt. Den logiska adressen är HSA-id för en verksamhet som finns i vårdsystem (verksamhetsbaserad adressering), eller HSA-id till vårdsystemet självt (källsystemsbaserad adressering). 
3. TAK i RTP-1 pekar ut NTP som tjänsteproducent för aktuell LA.
4. TAK i NTP definierar RTP-1 som tjänstekonsument.
5. TAK i NTjP NTP pekar RTP-2 som tjänsteproducent för aktuell LA.
6. TAK i RTP-2 definierar NTP som tjänstekonsument.
7. TAK i RTP-2 definierar Tjänsteproducent som tjänsteproducent för aktuell LA.

...

I T-boken rev B [R2] beskrivs att en Tjänsteplattform skall utföra behörighetskontroll baserat på information i TAK. Behörighetskontrollen är baserad på en kombination av tre entiteter:

1. Tjänstekonsument
2. TjänstekontraktLogisk Tjänstekontrakt
3. Logisk adress

På detta sätt kan en informationsägare på en verksamhet (som representeras av en logisk adress)  styra vilka tjänstekonsumenter som skall få adressera deras tjänster. 

...

Det är en stor administrativ börda att hantera informationsunderlaget för behörighetskontrollen. Kontrollen blir i praktiken verkningslös i kombination med källsystemsadressering, eftersom en LA då representerar ett helt källsystem. Den genomförs dessutom ofta redan hos tjänsteproducenterna, vilket i praktiken innebär en dubbel administration. Det har därför beslutats att central behörighetskontroll blir frivillig för tjänsteproducenterna. De kan nu tillåta att alla tjänstekonsumenter (som har behörighet till tjänstekontraktet) får anropa den logiska adressen.Tjänsteproducenten, egentligen ägare av en logisk adress 

Tjänsteproducenten, egentligen ägare av en logisk adress, behöver göra följande val:

...

I figuren ovan har man valt att låta tjänsteproducenten TjP1 genomföra kontrollen för de logiska adresserna KS1, VE10 och VE11. Det innebär att tjänsteplattformen har öppnat upp för alla tjänstedomänens tjänstekonsumenter att fritt få adressera dessa adresser (det gäller även TjK3 vilket inte framgår av bilden). För TjP2 låter man istället TP ansvara för kontrollen. Där har behörighetsinformation lagts in i TAK för att tillåta att TjK2 och TjK3 kan adressera VE20 och VE21. Anrop från TjK1 och den aggregerande tjänsten kommer inte att släppas fram till tjänsteproducent TjP2.

8.

...

6        HSA-baserat vägval och anropsbehörighet

De logiska adresserna består i de flesta fall av ett HSA-id som representerar en verksamhet eller organisation. Genom att tillföra information till tjänsteplattformen om det hierarkiska sambanden mellan logiska adresser skapas möjligheten att utföra åtkomstkontroll och vägval via en överliggande adress i hierarkin. Underlaget består vanligen av en organisationsfil som exporterats från HSA.

När tjänsteplattformen skall söka fram ett vägval i tjänsteadresseringskatalogen utgår den från den logiska adress som återfinns i det aktuella meddelandet. Om inget sådant vägval finns explicit definierat i tjänsteadresseringskatalogen kommer tjänsteplattformen att söka uppåt i organisationshierarkin som beskrivs av organisationsfilen, från angiven adress. Om någon av de överliggande logiska adresserna återfinns i ett vägval för aktuellt tjänstekontrakt så kommer det vägvalet att användas för meddelandet.

När tjänsteplattformen skall söka fram en anropsbehörighet utgår den från den logiska adress som återfinns i det aktuella meddelandet. Om ingen sådan behörighetspost finns definierad i tjänsteadresseringskatalogen kommer tjänsteplattformen att söka uppåt iorganisationshierarkin som beskrivs av organisationsfilen, från aktuell adress. Om någon av de överliggande logiska adresserna återfinns i en anropsbehörighetspost för aktuellt tjänstekontrakt så kommer meddelandet att passera behörighetskontrollen och kunna skickas till tjänsteproducenten.

8.7        Standardval för vägval och anropsbehörighet

Tjänstekonsumenter och tjänsteproducenter använder logiska adresser på det sätt som är beskrivet ovan. I en tjänsteplattforms tjänsteadresseringskatalog kan dock som alternativ en logisk adress med värde asterisk ("*") anges. Denna adress kan användas för att ange ett standardvärde för vägval (för specifikt tjänstekontrakt) alternativt för att deaktivera kontroll av anropsbehörighet (för specifikt tjänstekontrakt och tjänstekonsument). 

Följande sker när en begäran, för ett specifikt tjänstekontrakt, med logisk adress "X" anländer till tjänsteplattformen.

Vägval:

1. Om den logiska adressen "X" finns explicit definierad i för ett vägval i TAK kommer detta att användas.
2. Om det inte finns ett explicit vägval registrerat görs en HSA-baserad sökning efter vägval  (enl 8.6 ovan)
   
3. Om varken 1. eller 2. identifierar ett vägval så kommer istället vägvalet definierat av "*" att användas. 

Detta är bl a användbart om det enbart finns en (1) tjänsteproducent kopplat till ett verksamhetsadresserat tjänstekontrakt. Denna mekanism är också mycket användbar när en regional tjänsteplattform ska definiera vägval till den nationella tjänsteplattformen. Endast ett sådant vägval behöver TAK-as per tjänstekontrakt, i stället för ett vägval för varje logisk adress. 

Anropsbehörighet:

Om den logiska adressen "*" återfinns i en anropsbehörighet för ett tjänstekontrakt och en specifik tjänstekonsument så kommer denna tjänstekonsument att ha anropsbehörighet till samtliga logiska adresser för det tjänstekontraktet. Det innebär i praktiken att kontrollen av anropsbehörighet är deaktiverad för kombinationen av aktuellt tjänstekontrakt och tjänstekonsument. En nationell tjänstekonsument som ska nå alla logiska adresser för ett tjänstekontrakt (t.ex. alla hundratals vårdgivare i Sverige) behöver på detta sätt endast en behörighets-takning istället för hundratals. Detta är också mycket användbart för att ge tjänsteplattformar anropsbehörighet till varandra.

8.8        Namnstandards

RIV Tekniska anvisningar ska underlätta utveckling och tolkning av WSDL och tjänstescheman genom att föreslå en namnstandard. Namnstandarden ska bäras av de begrepp som ligger till grund för denna anvisning. Namnstandarden ska uttryckas som regler i de enskilda anvisningarna. I och med att profilerna bygger på varandra, finns de flesta namngivningsregler för WSDL i bas-profilen. Även anvisningen för tjänsteschema definierar namngivningsregler.

...