RIV Tekniska AnvisningarÖversiktVersion 2.0.25 ARK_0001 20182021-0109-1809 |
Innehållsförteckning
Utgåvehistorik
...
Utgåva | Revision Datum | Beskrivning | Ändringarna gjorda av | Definitiv revision fastställd av |
A | 2009-10-06 | Revision A fastställd av Arkitekturledningens tekniska expertgrupp. | magnus.larsson@callistaenterprise.se johan.eltes@callistaenterprise.seMagnus Larsson Johan Eltes | Arkitekturledningens tekniska expertgrupp |
PB1 | 2011-04-27 | Utkast för RIVTA 2.1. Omfattar följande ändringsbegäran från tracker på Osor: - 15114 | marcus.krantz@callistaenterprise.seMarcus Krantz | |
PB2 | 2011-10-18 | Korrektur | ||
B | 2011-10-19 | Fastställd revision | Arkitekturledningens tekniska expertgrupp | |
PC1 | 2011-12-14 | Uppdaterat dokumentet i och med byte av projektplats från Osor till Google code. | hans.thunberg@callistaenterprise.seHans Thunberg | |
C | 2012-01-03 | Fastställd revision | Arkitekturledningens tekniska expertgrupp | |
D | 2013-05-27 | Uppdateringar… | Arkitekturledningens tekniska expertgrupp | |
D1 | 2013-11-08 | Utvidgad och förändrad skrivning om adresseringsmodell (avsnitt 8.3)johan@eltesconsulting.se | Johan Eltes | |
D2 | 2013-11-11 | Uppdaterat enligt granskningskommentarer från CeHis | johan@eltesconsulting.seJohan Eltes | |
E | 2014-04-03 | Beskrivning av källsystemsbaserad adressering samt ändrad hantering av anropsbehörighet. Se även 1.1 Inledning till utgåva Elars.erik.rojeras@inera.se | lLars-Erik Röjerås | |
2.0.1 | 2014-12-08 | Flyttade till Inera-mall | lars.erik.rojeras@inera.seLars-Erik Röjerås | |
2.0.2 | 2015-12-17 | Tagit bort stycket ”Inledning till utgåva E”. | Mattias Nordvall, Inera | |
2.0.3 | 2018-01-18 | Tagit bort kapitel 8.7 som handlade om PingForConfiguration funktionen inte längre kravställs | Björn Hedman, Inera | Inera A&R |
1 Inledning
...
2.0.4 | 2018-08-27 | Lagt till kapitel 8.6 HSA-baserat vägval och anropsbehörighet och 8.7 Standardval för vägval och anropsbehörighet. | Lars Erik Röjerås, Inera | Inera A&R |
2.0.5 | 2021-09-09 | Tagit bort obsoleta mailadresser från revisionshistoriken. Ersatt dem med endast namn | Anders Malmros, Inera | Inera |
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.
...
Ref | Dokument | Beskrivning och ev. webbadress | Ansvarig |
[R1] | RIVTA | Sammanställning av det regelverk som är utgångspunkten för de nationella IT-lösningarna för vård och omsorg i Sverige. | Arkitektur och regelverk, Inera |
[R2] | T-Boken | Styrande tekniska principer och teknisk referensarkitektur för den nationella arkitekturen: Webblänk till PDF för REV B: | Arkitektur och regelverk, Inera |
[R3] | Gemensam tjänsteplattform | Beskriver den aktuella realisering av T-bokens referensarkitektur. Webblänk till plattformens applikations hemsida: Webblänk till plattformens förvaltning: | Inera |
[R4] | WS-I Hemsida | ”The OASIS Web Services Interoperability (WS-I) Member Section advances Best Practices for Web services standards across platforms, operating systems, and programming languages.” | OASIS WS-I |
[R5] | HCC spec. | SITHS HCC: Certifikat för svensk vård och omsorg. Webblänk till PDF för REV 2.35: http://www.inera.se/siths | Inera |
[R6] | SOAP 1.1 spec | Definierar ett XML-baserat protokoll för utbyte av information. Är grunden för den standardisering som går under benämningen ”web services”. Webblänk till specifikationens hemsida: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ | W3C |
[R7] | WSDL 1.1 spec | Beskrivningsspråk för web-services. Syftar till att stödja utvecklingsverktyg i design-time och web-service-konsumenter i run-time. Webbänk till specifikationens hemsida: | W3C |
[R8] | |||
[R9] | |||
[R10] | RIV TA hemsida | Projektplats för RIV Tekniska Anvisningar, dess referensapplikationer och tillämpningar (tjänstekontrakt). | Arkitektur och regelverk, Inera |
[R11] | W3C-rapport om utökningsbara XML-scheman | Beskriver problemställningar och strategier för design av meddelanden som ger bra stöd för versionshantering. Versioneringsstrategin som beskrivs i denna översikt och som tillämpas i RIV Teknisk Anvisning Tjänsteschema är baserad på strategi nr 2.5 i denna rapport. Webblänk till rapportens hemsida: http://www.w3.org/2001/tag/doc/versioning-xml | W3C |
[R12] | Unique Particle Attribution (XML Schema) hemsida | Detta avsnitt i specifikationen för XML Schema Language 1.0 beskriver en regel som har inverkan på (komplicerar) den strategi för versionshantering som valts för RIV Tekniska Anvisningar 2.0. Referens R11 beskriver konsekvenserna. Webblänk till avsnittet i specifikationen: | W3C |
[R13] | Anvisning Konfigurations-styrning av tjänstekontrakt | Anvisning för utveckling, förvaltning och konfigurationsstyrning av tjänstekontrakt med fokus på praktiska aktiviteter inom projektplatsen http://rivta.se/documents/ARK_0007 | Arkitektur och regelverk, Inera |
[R14] AAn | RIVTA Basic Profile – Valfria tillägg 2.1 | Anvisning som beskriver regler för hantering av aggregerande tjänster samt hantering av information om ursprunglig tjänstekonsument. | Arkitektur och regelverk, Inera |
...
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.
...
- Aktuellt tjänstekontrakt måste vara realiserat som virtuell tjänst i samtliga tjänsteplattformar som deltar i informationsflödet.
- 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).
- TAK i RTP-1 pekar ut NTP som tjänsteproducent för aktuell LA.
- TAK i NTP definierar RTP-1 som tjänstekonsument.
- TAK i NTjP NTP pekar RTP-2 som tjänsteproducent för aktuell LA.
- TAK i RTP-2 definierar NTP som tjänstekonsument.
- TAK i RTP-2 definierar Tjänsteproducent som tjänsteproducent för aktuell LA.
...
Den ursprungliga tjänstekonsumenten behöver på detta sätt enbart känna till sin lokala tjänsteplattform samt en logisk adress till vårdsystemet, även om det finns inom en annan organisation.
8.5 5 Anropsbehörighet
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:
- Tjänstekonsument
- TjänstekontraktLogisk Tjänstekontrakt
- 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, 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:
- Om den logiska adressen "X" finns explicit definierad i för ett vägval i TAK kommer detta att användas.
- Om det inte finns ett explicit vägval registrerat görs en HSA-baserad sökning efter vägval (enl 8.6 ovan)
- 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.
...
Utveckling och förvaltning av RIVTA och dess delar/dokument sker genom att förändringsbehov och/elleller förslag skickas in till Ineras Arkitektursektion via e-post till kundservice@inera.se. Ange "RIVTA: Anvisningens namn"" i ämnesraden.
...
[1] Detaljer kring informationsinnehåll och tjänstekontrakt i Engagemangsindex återfinns i dess Tjänstekontraktsbeskrivning.
...