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.

1.1           Målgrupp

Dokumentet riktar sig till förvaltare av RIV tekniska anvisningar, tekniska arkitekter och systemutvecklare som vill få en grundlig förståelse för motiven bakom RIV Tekniska anvisningar och därigenom vad som kan förväntas av de tekniska profiler som utarbetas. Detta dokument innehåller inga regelverk. Dessa finns i de enskilda anvisningarna. Det är ett uttalat syfte att anvisningar för enskilda profiler ska kunna tillämpas utan att översikten har lästs.

1.2     Syfte

RIV Tekniska Anvisningar (RIV TA) syftar till att beskriva hur man realiserar utbytet av information mellan två parter med hjälp av web services.

...

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.

1.1           Målgrupp

Dokumentet riktar sig till förvaltare av RIV tekniska anvisningar, tekniska arkitekter och systemutvecklare som vill få en grundlig förståelse för motiven bakom RIV Tekniska anvisningar och därigenom vad som kan förväntas av de tekniska profiler som utarbetas. Detta dokument innehåller inga regelverk. Dessa finns i de enskilda anvisningarna. Det är ett uttalat syfte att anvisningar för enskilda profiler ska kunna tillämpas utan att översikten har lästs.

1.2     Syfte

RIV Tekniska Anvisningar (RIV TA) syftar till att beskriva hur man realiserar utbytet av information mellan två parter med hjälp av web services.

RIV TA bygger på ett antal befintliga standarder, specifikationer och rekommendationer från erkända standardiseringsorgan/motsvarande som exempelvis IETF (Internet Engineering Task Force), W3C (World Wide Web Consortium) och OASIS (Organization for the Advancement of Structured Information Standards). För att försäkra sig om att olika standarder fungerar tillsammans förlitar sig RIV TA på de profiler som getts ut av WS-I (Web Services Interoperability Organization).

...

Översikten beskriver inte processen för utveckling och förvaltning av nationella tjänstekontrakt. Det beskrivs istället av anvisning för konfigurationsstyrning [R13].

1.4     Tillgänglighet

RIV Tekniska Anvisningar är publicerade under licensen Creative Commons CC-BY-SA (http://creativecommons.org/licenses/by-sa/2.5/se/). Det betyder att du fritt får kopiera, distribuera och skapa bearbetningar av anvisningarna, under förutsättning att upphovsmannen (Sveriges Kommuner och Landsting) anges (men inte på ett sätt som antyder att de godkänt eller rekommenderar din användning av verket).

RIV Tekniska Anvisningar verifieras genom exempelapplikationer. Källkoden för dessa distribueras under öppen-källkodslicensen Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0)

1.5     Referenser

...

2         Anvisningarna i sitt sammanhang

...

Figur 1 Anvisningarna i sitt sammanhang 

För information om relaterade regelverk och anvisningar, se referenslistan.

...

OWSA Model T - sikker direkte transport

1. Målgruppsanpassning
   Genom att dela upp profilerna efter WS-I:s uppdelning (Basic, Basic Security, Reliable Conversation etc) får vi en uppställning som är anpassad efter olika målgruppers behov av funktionalitet.
2. Återanvändning
   Vi delar upp anvisningarna enligt vad som beskrivs för målgruppsanpassning. Dessa fokuserar på teknisk kuverteringen och transportprotokoll. Regler rörande tekniska aspekter på innehåll läggs i separat anvisning (versionering, namnrymdsättning, namnstandards m.m.) för Tjänstekontrakt.
   
   Tekniska anvisningar för profiler byggs upp stegvis med bas i WS I Basic Profile. Påbyggnadsprofil följer, baserat på WS-I Basic Security Profile och i efterföljande steg på WS-I Secure Reliable Conversation Profile.
   
   Vidare definieras tekniskt regelverk som gäller generellt för innehåll i en separat anvisning som gäller oberoende av profil. Denna anvisning kallas RIVTA - Tjänsteschema.
3. Spårbarhet
   För varje regel i en anvisning dokumenteras bakomliggande krav.
4. Öppenhet
   Förvaltningsprocessen bedrivs på publik infrastruktur för öppen källkod som tillhandahålls av Google [R10].
   
   Följande möjligheter finns för alla intressenter. Intressenter kan tillgängliggöra sig dessa möjligheter utan administrativ börda på förvaltningsorganisationen för RIV Tekniska Anvisningar:

...

Figur 2 Avsändare och mottagare

5.1.1         Meddelande

Informationsmängd som förpackats av en avsändare i syfte att överföra strukturerad information till en mottagare. Meddelandets tekniska inramning benämns meddelandekuvert. Kuvertet omsluter ett meddelandehuvud och ett meddelandeinnehåll. Inom ramen för RIV tekniska anvisningar tillämpas standarden SOAP 1.1, vars motsvarande begrepp är Envelope, Header och Body. I anvisningen används de svenska termerna och motsvarande termer ur SOAP-standarden växelvis beroende på sammanhang. Följande figur illustrerar den generella uppbyggnaden av ett meddelande:

...

Figur 3 Strukturen i ett meddelande 

5.1.2        Avsändare

Tjänstekomponent som sänder ett meddelande till en mottagare 

5.1.3        Mottagare

Tjänstekomponent som tar emot ett meddelande från en avsändare

...

Följande termer definierar tjänsteinteraktioner och deras byggstenar:

5.2.1        InUt-operation

Ett synkront anrop med ett inmeddelande som resulterar i ett svarsmeddelande eller ett av tjänsteimplementationen producerat felmeddelande. En InUt-operation visualiseras med en heldragen pil: 

5.2.2       In-operation

Ett asynkront meddelande med robust leverans. Operationen har ett inmeddelande men inget returmeddelande. En In-operation visualiseras med en streckad pil.:

...

Not: I UML ligger skillnaden i notation mellan synkron och asynkron operation i huruvida pilhuvudet är fyllt eller inte. Vi har här valt att avvika från UML för ökad tydlighet. I de UML-diagram som förekommer i dokumentet används UML:s representation. 

5.2.3       Tjänsteinteraktion

...

Följande uppställning beskriver hur de olika tjänsteinteraktionstyperna visualiseras i anvisningarna:

...

5.2.4       Övriga termer

...

Tabell 1 Termer

Term	För-kort-ning	Beskrivning
Tjänstekontrakt

 

		Kontrakt som beskriver ett nationellt standardiserat gränssnitt som förekommer mellan tjänstekomponenter i en tjänsteorienterad arkitektur. Tjänstekontraktet är oberoende av transport och kuvertering. Tekniskt sett realiseras detta i form av ett tjänsteschema samt en porttyp i en WSDL. Ett tjänstekontrakt beskriver en Utförare (Responder) eller en Initiativtagare (Initiator) i en Tjänsteinteraktion. Ex: Tjänstekontraktet för utförar-rollen i tjänsteinteraktionen GetCareContacts heter "GetCareContactsResponder ".
Tjänsteschema

 

		Ett XML-Schema (tjänsteschema) med element för tjänstekontraktets in- och ut meddelanden. Ett tjänstekontrakt identifieras i runtime av tjänsteschemats namnrymd, dvs schemats target namespace. T.ex. "urn:riv: clinicalprocess:logistics:logistics:GetCareContacts :1".
Tjänstedomän

 

		En övergripande, verksamhetsbaserad indelningsgrund för nationellt standardiserade tjänsteinteraktioner. I Riv Tekniska Anvisningar ingår tjänstedomän som en del i uppbyggnaden av namnrymder. Arkitektur och regelverk förvaltar en domänstruktur som baseras på VIFO-kartan.
Tjänstekomponent

 

	Avgränsad mängd programvara som kan utvecklas, integreras, testas, driftsättas och förvaltas fristående. Tjänstekomponenter kan vara såväl tjänstekonsumenter som tjänsteproducenter.
Initiativtagare

 

	Tjänstekomponent som initierar en tjänsteinteraktion. Om tjänsteinteraktionen är av typen Uppdrag-Resultat exponerar initiativtagaren ett tjänstekontrakt för att möjliggöra mottagandet av resultat som sänds av Utföraren i tjänsteinteraktionen.
Utförare

 

	Tjänstekomponent som en initiativtagare interagerar med i en tjänsteinteraktion
Tjänstekonsument	TjK	Informationssystem där aktörens agerande leder till automatiskt informationsutbyte med andra system (tjänsteproducenter). En tjänstekonsument kan t ex vara en eTjänst, ett verksamhetssystem, en partneringång eller en tjänsteplattform. Tjänstekonsumenten agerar som initiativtagare i en interaktion.
Ursprunglig tjänstekonsument

 

		Den tjänstekonsument som är den ursprungliga initiativtagaren till en interaktion. Distinktionen är betydelsefull t ex när flera tjänsteplattformar är involverade i ett meddelandeutbyte.  Information om vilket system som är ursprunglig tjänstekonsument tillhandahålls i http-headern ”x-rivta-original-serviceconsumer-hsaid”, se referens [R14]
Tjänsteproducent	TjP	Tjänsteproducenter uppvisar ett tekniskt gränssnitt som möjliggör för tjänstekonsumenter att genom frågemeddelanden förändra eller begära information. En tjänsteproducent kan t ex vara ett verksamhetssystem, partnerutgång, en  tjänsteplattform, en aggregerande tjänst eller en stödtjänst. Tjänsteproducenten agerar som utförare i en interaktion gentemot tjänstekonsumenten. Den kan i sin tur skicka meddelanden vidare till andra utförare.
Tjänsteplattform Gemensam instans Regional instans	TP NTP

 

RTP	Tjänsteplattform är ett samlingsnamn för de komponenter som utgör plattform för tjänstebaserad integration över huvudmannagränser. Tjänsteplattformen finns i en nationell gemensam instans (NTP), och i ett flertal regionala (sk regional tjänsteplattform, RTP).
Stödtjänst

 

	Stödtjänster är tjänsteproducenter som tillhör den tekniska domänen, eller hanterar information som inte är bunden till någon specifik verksamhetsprocess.
Virtualiseringsplattform	VP	Komponent inom en tjänsteplattform som ansvarar för att exekvera virtuella tjänster.
Tjänsteadresseringskatalog	TAK	Tjänsteadresseringskatalogen är en stödtjänst som erbjuder administration och åtkomst av information som ligger till grund för den adressering och behörighetskontroll som utförs i en virtualiseringsplattform. Det finns i normalfallet en instans av en TAK inom ramen för varje tjänsteplattform.
Källsystem (KS)

 

		Det verksamhetssystem där originalinformationen skapas (t.ex. en driftsinstans av ett  journalsystem).  Agerar adressat för viss typ av logisk adressering.
Aggregerande tjänst	AgT	En aggregerande tjänst är en integrationstjänst som för en viss individ/patient sammanställer en nationell eller regional vy av informationen av den typ som är aktuell för tjänsten i fråga. Principerna för aggregerande tjänster är beskrivet i T-boken ([R2]). För information om realisering av en aggregerande tjänst på en specifik tjänsteplattform hänvisas till respektive tjänsteplattformsförvaltning.
Aggregeringsplattform	AgP	Komponent inom en tjänsteplattform som ansvarar för att exekvera aggregerande tjänster.
Engagemangsindex	EI	En stödtjänst där det finns uppdaterade nationella index över vilka informationsägare som har information av vilket slag kring en viss invånare/patient. På så sätt erhåller aggregerande tjänster information om vilka verksamheter eller källsystem som behöver adresseras för att samla in information. Engagemangsindex har även en tjänstedomän som innehåller de tjänstekontrakt som används för att nå informationen. Engagemangsindex är utförligt beskrivet i T-boken ([R2]). För detaljer, se även aktuell Tjänstekontraktsbeskrivning för EI.
Virtuell tjänst

 

		Integrationstjänst i en tjänsteplattform som är i en nationell ställföreträdare för alla lokala tjänsteproducenter som uppfyller ett tjänstekontrakt. Den uppträder som om det fanns en gemensam tjänsteproducent, men dirigerar vidare frågemeddelanden till respektive informationsägares tjänsteproducent och förmedlar svarsmeddelandet i retur. Det sker med hjälp av en logisk adress som tjänstekonsumenten bifogar frågemeddelandet.
Logisk adress	LA	Adresseringsbegrepp i RIV-TA. Genom en indirekt adressering åstadkoms lös koppling mellan tjänstekonsumenter och tjänsteproducenter.
Verksamhetsbaserad logisk adress

 

		Logisk adress som baseras på verksamhet eller organisation. Vanligen används verksamhetens HSA-id som adress.
Källsystemsbaserad logisk adress

 

Logisk adress som baseras på IT-system (källsystem). Det aktuella systemets HSA-id används som adress.

...

Figurerna nedan visar begreppen i sammanhang. 

Figur 4 Tjänstekontrakt och virtuella tjänster 

 

Tjänstekontrakt i en tjänstedomän realiseras i form av virtuella tjänster i en tjänsteplattform, och i form av tjänster i en tjänsteproducent. Källsystem syftar alltid på källan som ansvarar för originalinformationen, oavsett om information i praktiken hämtas från annan plats vid utväxlingsögonblicket (t.ex. via mellanlager eller regionala tjänsteplattformar).

 

 

Figur 5 Komponenter i en tjänsteplattform 

Aggregerande tjänster exekveras inom ramen för aggregeringsplattformen inom en TP. De använder sig av Engagemangsindex för att få information om vilka adresser som skall anropas.

...

Figur 6 Regionala och gemensamma tjänstekomponenter i samverkan

 

Tjänsteplattformar kan kopplas samman i serie. De kommer då att i vissa lägen att agera tjänstekonsumenter respektive tjänsteproducenter visavi varandra. Observera att den första tjänstekonsumenten i en kedja benämns ”ursprunglig”. 

5.3    Terminologi för säkerhet

Följande termer definierar vård-specifika termer som är centrala för att uttrycka regler relaterade till säkerhet. 

5.3.1        HCC Funktion för autentisering och kryptering

...

Regler rörande tekniska aspekter på XML-schema som beskriver innehåll (för SOAP Body i fallet Basic Profile) läggs i separat anvisning för Tjänstekontrakt (versionering, namnrymdsättning, namnstandards m.m.). Följande figur visar strukturen med en anvisning för tjänstescheman och en anvisning per teknisk profil. De tekniska profilerna bygger på varandra med bas i RIV TA Basic Profile. Varje teknisk profil syftar till att tillmötesgå specifika kvalitetskrav på informationsöverföring. Basic Profile uppfyller grundläggande krav på insynsskydd och interoperabilitet. 

Figur 7 Anvisningarnas uppdelning

...

Exemplet är baserat på fråga-svar vid utbyte av journalinformation. Tjänsteinteraktionen beskrivs av följande UML klassdiagram: 

Figur 8 Fråga-svar – struktur 

Interaktionen mellan parterna beskrivs av följande UML sekvensdiagram där initiativtagaren gör ett synkront anrop med en fråga till utföraren som returnerar ett svar:

...

Figur 9 Fråga-svar – sekvensdiagram

AnmAnm.: En fylld pil i ett UML sekvensdiagram betyder ett synkront anrop

7.1.2        Tjänsteinteraktionstyp Informationsspridning

Exemplet är baserat på informationsspridning för uppdatering av information om en patient. Tjänsteinteraktionen beskrivs av följande UML klassdiagram:

Figur 10 Informationsspridning – struktur

Interaktionen mellan parterna beskrivs av följande UML sekvensdiagram där initiativtagaren (dvs informationsspridaren) gör ett asynkront anrop till utföraren (mottagaren av informationen): 

Figur 11 Informationsspridning – sekvensdiagram

Anm.: En ofylld pil i ett UML sekvensdiagram betyder ett asynkront anrop

7.1.3        Tjänsteinteraktionstyp Uppdrag-resultat

...

Figur 12 Uppdrag-resultat – struktur 

Interaktionen mellan parterna beskrivs av följande UML sekvensdiagram där initiativtagaren (dvs beställaren) gör ett asynkront anrop till utföraren och utföraren så småningom återkommer genom att göra ett asynkront anrop till initiativtagaren (beställaren) : 

Figur 13 Uppdrag-resultat – sekvensdiagram 

Anm.: En ofylld pil i ett UML sekvensdiagram betyder ett asynkront anrop

...

RIV Tekniska anvisningar konstrueras som tilläggsprofiler till de interoperabilitetsprofiler för web-services som definieras av Web Services Interoperability Organization (WS-I). 

RIV TA-profilerna bygger på varandra. RIV TA Basic Profile med Intygspropagering är baserad på RIV TA Basic Profile. 

För mer information om WS-I profiler och deras ingående specifikationer hänvisas till http://www.ws-i.org/deliverables/matrix.aspx 

8.1.1        Leverantörsspecifika avvikelser och konventioner

...

Konsekvensen av strategin är en uppsättning detaljerade krav. Dessa beskrivs nedan.     

8.2.1       Definitioner

Versionsnummer sätts på ett tjänstekontrakt enligt formatet: major.minor

...

För att beskriva att ett meddelande innehåller element från en viss version av ett tjänstekontrakt (v1.0 i exemplet nedan) används följande notation:

Anm. "e1.0" anger element från v1.0 av tjänsteschemat

För att beskriva att ett meddelande som innehåller element från flera olika versioner av ett tjänstekontrakt (v1.0 och v1.1 i exemplet nedan) används följande notation:

...

Anm. I bilden förstärks att element från v1.1 av tjänstekontraktet har tillförts meddelandet 

En initiativtagare byggd för v1.0 av ett tjänstekontrakt visualiseras enligt:

En utförare byggd för v1.0 av ett tjänsteschema visualiseras enligt:

...

Bakåtkompatibilitet innebär att en avsändare kan skicka meddelande till en mottagare där meddelandet följer en äldre version av tjänstekontraktet än vad mottagare är baserad på. Detta kräver att mottagaren kan behandla meddelanden av den äldre versionen trots att dessa saknar de nya elementen. Bakåtkompatibilitet illustreras med hjälp av följande bild:

Framåtkompatibilitet innebär att en avsändare kan skicka meddelande till en mottagare där meddelandet följer en nyare version av tjänstekontraktet än vad mottagaren är baserad på. Detta kräver att mottagaren kan bortse från informationen som tillförts i den nyare versionen av meddelandet.

8.2.3      Teknisk realisation av framåt och bakåtkompatibilitet

...

En försvårande omständighet är i detta sammanhang att många verktyg för tolkning och validering av XML tagit fasta på ett krav i specifikationen för XML Schema som benämns "Unique Particle Attribution". Den av W3C beskrivna strategin för versionering tar delvis hänsyn till denna restriktion. Det är en erfarenhetsmässigt påvisad metod för att tekniskt realisera krav på bakåt- och framåtkompatibilitet som bl.a. tillämpas inom OASIS (WS-Policy, WS-Topic m.fl). Valet av strategi medför följande krav på tjänstescheman: 

• Versionsdeklaration: Target-namespace skall innehålla major-versionen.
• Namespaces behöver anges för element i instans-dokument: Schema-attributet elementFormDefault skall vara satt till 'qualified' i alla scheman.
• Platshållare för framåtkompatibilitet: Ett xsd:any-element ska finnas som "platshållare" för framtida, icke-obligatoriska element: <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##other"/>. Element som introduceras i en ny minor-version läggs i ett separat XML Schema med target-namespace som skiljer sig från major-versionens. Detta är en konsekvens av any-elements deklaration enligt ovan, som tvingar att dessa element ska vara i annan namnrymd.

...

Se RIV Teknisk anvisning: Referensapplikation för exempel på tjänsteschema som realiserar beskriven strategi för versionshantering. 

8.2.4      Icke kompatibla ändringar

...

För tjänsteinteraktionstypen fråga-svar blir det dock lite mer komplext extersom tjänsteinteraktionstypen är baserad på en inUt-operation, dvs utföraren skickar ett svarsmeddelande (synkront) tillbaka till mottagaren. 

8.2.6      Bakåt och framåtkompatibilitet för tjänsteinteraktionstypen Fråga-svar

...

Följande bild illustrerar behov av bakåt och framåtkompatiblitet i fallet med en gammal initiativtagare och en ny utförare: 

I detta exempel måste utföraren (v1.1) kunna behandla request-meddelanden av den äldre versionen (v1.0) trots att dessa saknar de nya elementen samt initiativtagaren (v1.0) måste ignorera nya element som kommer i v1.1-response-meddelanden.

...

andla response-meddelanden av den äldre versionen (v1.0) trots att dessa saknar de nya elementen. 

8.2.7       Införande av ny version av RIVTA

Koppling via tjänsteplattformen möjliggör också utrullning av nya versioner av RIVTA utan att alla parter som samverkar behöver uppgradera samtidigt. Virtuella tjänster översätter mellan RIVTA-versioner. Det handlar oftast om förändrade namn på headrar, byte av protokoll eller växling mellen säkerhetsmodeller, då något av dessa troligen förändras mellan RIVTA-versioner även om tjänsteschemat är oförändrat

8.3        Stöd för referensarkitekturens adresseringsmodell

T-boken beskriver en abstrakt modell för adressering där tjänstekonsumenten i ett meddelandeutbyte ska adressera en tjänsteproducent med en logisk adress (LA). När begäran från konsumenten når en virtuell tjänst i tjänsteplattformen tar tjänsteplattformen hjälp av tjänsteadresseringskatalogen för att…

• validera att aktuell tjänstekonsument har rätt att anropa den virtuella tjänsten
• erhålla den tekniska adressen (URL) till mottagande tjänsteproducent

...

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. 

Anvisningen för basprofilen detaljerar reglerna för hur den logiska adressen ska deklareras i en tjänsteinteraktion. I RIVTA Basic Profile 2.1 deklareras logisk adress i tjänsteinteraktionens WSDL i form av SOAP-header. Det görs på ett sätt som får header-elementet att uppträda som en parameter i den metodsignatur som utvecklingsverktyg (Java, -Net) genererar från WSDL-filen. 

T-bokens adresseringsmodell är kärnan i den nationella referensarkitekturen. Det är därför viktigt att ha grundlig förståelse för dess ändamål. Den är designad med utgångspunkt i att systemstrukturen inom vård och omsorg är distribuerad, med federativt ägarskap. Det betyder att det finns många likheter med s.k. business-to-business, där många organisationer länkas samman med varandra.

Inom vård- och omsorg finns en uppsättning typfall. I samtliga fall är adresseringsmodellens syfte att ge lös koppling mellan tjänstekonsument och tjänsteproducent. Här har förstås också den gemensamma tjänsteplattformen en viktig uppgift att fylla i dess roll som gemensam anslutningspunkt. Lös koppling på semantisk nivå skapas genom att alla parter är överens om ett tjänstekontrakt för informationsutbyte. På teknisk nivå sker det genom att alla parter enats om ett tekniskt protokoll, en adresseringsmodell samt att meddelandeutbytet sker via tjänsteplattformen. Det tekniska protokollet säkerställer att olika parter är överens om hur kommunikationen ska upprättas och skyddas. Adresseringsmodellen säkerställer tillsammans med tjänsteplattformen att alla parter i arkitekturen kan uttrycka vem som är mottagare av ett meddelande utan beroende till hur mottagaren organiserar sitt IT-stöd.

Den logiska adressen pekar ut en tjänsteproducents URL via information i TAK. På detta sätt döljs system- och ip-adresser från tjänstekonsumenten. En verksamhet kan därför förändra sin systemstruktur utan att påverka logiska adresser och tjänstekonsumenter. Det enda som behöver uppdateras är adresseringsinformationen i TAK.

Den logiska adressen representerar ett av två olika koncept:

...

• Verksamhet/organisation
• Ett källsystem

...

8.3.1       Verksamhetsbaserad adressering

Vid verksamhetsbaserad adressering representerar den logiska adressen en organisation eller verksamhet. Det är vanligen en vårdgivare eller vårdenhet, men även andra, som t ex myndigheter, förekommer. Varje tjänstedomän definierar vilka värden för logisk adress som kan användas tillsammans med domänens tjänstekontrakt. Typiskt används organisationens HSA-id som adress. 

Figur 14 Verksamhetsbaserad adressering

I figuren ovan används HSA-id till vårdenheten VE11 som logisk adress. Baserat på information i TAK översätter VP den logiska adressen till en URL. Denna pekar ut den tjänsteproducent, TjP1, som hanterar information associerad medVE11 i enlighet med ett visst tjänstekontrakt. 

Även aggregerande tjänster adresseras via logiska adresser som representerar en organisation eller verksamhet. Ur tjänstekonsumentens perspektiv uppträder en AgT som en tjänsteproducent. Den exekverar på komponenten Aggregeringsplattform inom ramen för en tjänsteplattform. Principerna för aggregerande tjänster beskriv T-boken ([R2]). 

Figur 15 Adressering av aggregerande tjänst 

Det kan inte finnas mer än en instans av en aggregerande tjänst per tjänstekontrakt och tjänsteplattform. Adresseringen kan därför förenklas enligt: 

• En AgT som finns på den gemensamma tjänsteplattformen adresseras med Ineras HSA-id som LA.
• Den logiska adressen till en AgT som driftsatts på en regional plattform är regionens HSA-id som LA.  

Observera att i figuren ovan framgår att den logiska adressen enbart pekar ut den aggregerande tjänsten (inringad i rött). Den aggregerande tjänsten kommer dock i sin tur att, baserat på EI, anropa ett antal system (symboliserat med en streckad cirkel).

8.8.3.2      Adressering av källsystem

...

Källsystemet kan också vara representerat av ett mellanlager som de facto är komponenten som besvarar förfrågan från tjänstekonsumenten.

Ett källsystem innehåller i normalfallet information som härrör från många verksamheter. Denna adresseringsmodell ger därför möjlighet att hämta information som härrör från flera verksamheter i en interaktion.

Figur 16 Adressering av källsystem 

Figuren visar hur en aggregerande tjänst agerar tjänstekonsument och skickar ett meddelande adresserat till ett källsystem. Källsystemets HSA-id används som LA. VP översätter LA till URL till den tjänsteproducent som kan tillhandahålla information enligt aktuellt kontrakt och med ursprung i angivet.

Denna adresseringsmekanism innebär, en icke önskvärd, hårdare koppling mellan initiativtagare och utförare än vid verksamhetsbaserad adressering. Denna nackdel motverkas av att Tjänstkonsumenter inte skall spara dessa adresser. I stället lagras och underhålls dessa i EI av källsystemen själva. Tabellen nedan visar när källsystembaserad adressering skall användas, samt hur tjänstekonsumenten erhåller den logiska adressen.

Tabell 2 Användningsfall för källsystemsbaserad adressering

...

Denna adresseringsmodell har införts som ett sätt att avlasta källsystem och integrationsinfrastrukturen. 

8.3.3    Konsekvenser av adresseringsmetoderna

Samma tjänstekontrakt kan adresseras på olika sätt vid olika tillfällen. Ett kontrakt som realiseras som en aggregerande tjänst (och då adresseras via en verksamhetsbaserad logisk adress) kan i nästa steg vara realiserat i producenter som anropas via källsystemsadresser. 

8.3.3.1      Konsekvenser för tjänstekontrakten

Om ett tjänstekontrakt som anropas källsystemsadresserat behöver göra utsökning eller filtrering baserat på verksamhet måste det ingå som en parameter i request-meddelandet (eftersom den inte går att utläsa ur den logiska adressen). 

Tjänstekontrakt som realiseras i form av aggregerande tjänster måste definiera ett svarsmeddelande i form av en lista; 0..n. 

8.3.3.2     Konsekvenser för tjänstekonsumenter

...

Vid verksamhetsbaserad adressering känner tjänstekonsumenten till vilken verksamhet som skall adresseras och använder t ex organisationens HSA-id som logisk adress i anropet. 

Tjänstekonsumenter skall aldrig själva lagra logiska adresser som refererar till källsystem. Dessa skall erhållas via notifiering från EI eller via svar från en aggregerande tjänst.

 

Aggregerande tjänster (när de agerar som tjänstekonsument) hämtar adressen från EI.  

 

8.3.3.3     Konsekvenser för tjänsteplattformar

...

Tjänsteplattformen, inklusive dess VP och TAK, är omedveten om vilket adresseringskoncept som används. Den använder den logiska adressen som nyckel i TAK för att hämta ut URL till tjänsteproducenten. Det sker på samma sätt oberoende av vad adressetiketten betyder.  

8.3.3.4     Konsekvenser för tjänsteproducenter

En och samma tjänst (tjänstekontrakt) i en tjänsteproducent kan teoretiskt adresseras både via verksamhets- och källssystemsadresser. Om logiken i tjänsteproducenten är beroende av adresseringsmekanism, t ex för att göra filtrering eller behörighetskontroll, måste den själv analysera den aktuella adressen för att se om det är en av den själv känd källsystemsadress. 

Den skall vid behov genomföra en kontroll av att ursprunglig tjänstekonsument har behörighet att anropa den logiska adressen. Den skickar vid behov meddelandet vidare till det källsystem som innehåller adresserad information. 

8.3.3.5     Konsekvenser för källsystem

...

När ett källsystem adresseras direkt (dvs källsystemsbaserad adressering) kan det behöva genomföra en filtrering av information baserat på verksamhet. 

Om ett mellanlager används för att försörja en källsystemadresserad tjänsteproducent med journalinformation måste posterna i mellanlagret ha spårbarhet till källsystemets HSA-id. I annat fall har inte tjänsteproducenten möjlighet att avgränsa sökresultatet till information som härrör från adresserat källsystem. 

8.3.4      Val av adresseringsmetod

Den som ansvarar för utvecklingen av en tjänstedomän behöver fundera över vad som är det mest lämpade adresseringsbegreppet vid olika situationer. 

Rekommendationer: 

Tjänster som anropas av aggregerande tjänster samt de övriga användningsfallen i Tabell 2 bör vara källsystemsadresserade[2].

...

4)      Antalet poster i minskar EI eftersom det endast blir en post per källsystem, patient och informationstyp i stället för en post per enhet, patient och informationstyp.

Övriga integrationer, som inte är relaterade till aggregering av information, bör använda verksamhetsbaserad adressering².

Motiv:

Styrande princip IT4: Lös koppling i T-boken ([R2]). Verksamhetsbaserade logiska adresser innebär en lösare koppling mellan tjänstekomponenterna. Tjänstekonsumenten får inget beroende till systemstrukturen hos anropad verksamhet.

...

När meddelanden skickas mellan tjänsteplattformar tar dessa rollen som tjänstekonsument och/eller tjänsteproducent gentemot varandra och övriga tjänstekonsumenter.

Se Figur 6 Regionala och gemensamma tjänstekomponenter i samverkanpå sidan21 som exempel. 

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.

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         Anropsbehörighet

...

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: 

1. TjänstekonsumentTjänstekonsument
2. Tjänstekontrakt
3. TjänstekontraktLogisk 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:

1. Kontroll av anropsbehörighet skall ske i tjänsteplattformen för varje tjänstekonsument (dagens situation).
2. Tillåta att alla tjänstekonsumenter som har behörighet till tjänstekontraktet får anropa den logiska adressen.

...

Observera att 1 ovan i praktiken är verkningslös vid källsystemsbaserad adressering, samt vid användning av aggregerande tjänster över flera tjänsteplattformar. 

Valet 2 ovan innebär att kontroll av anropsbehörighet kan behöva ske i tjänsteproducenterna. För att möjliggöra detta har stöd införts i Tjänsteplattformarna för att förmedla ursprunglig tjänstekonsuments HSA-id hela vägen till slutlig tjänsteproducent i form av http-headern ”x-rivta-original-serviceconsumer-hsaid”, se RIVTA Basic Profile – Valfria tillägg ([R14]). 

Tjänsteproducenten ansvarar för att information endast lämnas ut till de tjänstekonsumenter som informationsägaren godkänt. Om informationsägaren (vårdenhet) har behov av att reglera åtkomst per tjänstekonsument, ska tjänsteproducenten erbjuda denna möjlighet och filtrera svaret enligt informationsägarens önskemål. Observera att det kan vara regionala policyer snarare än lagar och förordningar som styr i vilken grad tjänsteproducenten ska begränsa åtkomst för en viss tjänstekonsument. Kunskapen om tjänstekonsumentens (tjänstens) identitet (d.v.s. ursprunglig tjänstekonsument i anropskedjan) får bara användas för teknisk åtkomstbegränsning på så sätt att svaret på begäran blir som om de vårdenheter vars verksamhetschef inte godkänner aktuell tjänstekonsument varit exkluderade i begäran. Den kan inte användas för att filtrera svaret inom vårdenhet olika för olika tjänstekonsumenter.

 Image Removed

Figur 17 Anropsbehörighet

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.

...

aktuell tjänstekonsument varit exkluderade i begäran. Den kan inte användas för att filtrera svaret inom vårdenhet olika för olika tjänstekonsumenter.

 Image Added

Figur 17 Anropsbehörighet

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.

8.7    Publicering av övervaknings-tjänst

För varje RIVTA-tjänst som publiceras skall även en övervaknings-tjänst (itintegration:monitoring) publiceras. Den här tjänsten kan användas för att extrahera information om den producent som exponerar tjänsten, tex version av mjukvaran. Ett tjänstekontrakt (PingForConfiguration) för övervaknings-tjänsten har tagits fram som finns i namnrymden: urn:riv:itintegration:PingForConfigurationResponder och skall exponeras tillsammans med RIVTA-tjänsten.

Referera till tjänstekontraktbeskrivningen för itintegration:monitoring för mera information hur detta kontrakt skall realiseras i tjänsteproducenten.

9       Förvaltning

 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.

9       Förvaltning

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.

...