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.

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

1.3     Avgränsningar

Ö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

Följande figur visar RIV Tekniska Anvisningars plats i den nationella arkitekturen:

Figur 1 Anvisningarna i sitt sammanhang

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

3       Styrande principer

Det är viktigt att anvisningarna har goda förutsättningar att förvaltas. En av förutsättningarna är att principerna som styrt framtagningen finns redovisade. Det ger möjlighet att hålla en linje i anvisningarnas utveckling över tiden. Följande principer gäller vid utveckling och förvaltning av RIV Tekniska Anvisningar:

1. Terminologi
   Anvisningarna ska bygga på för vården etablerad terminologibas inom teknisk interoperabilitet.
2. Kvalitetssäkring
   Anvisningar ska vara tekniskt kvalitetssäkrade.
3. Enkelhet
   Anvisningarna ska vara enkla att använda för tänkt målgrupp.
4. Lättviktighet
   Anvisningarna ska hållas så lättviktiga som möjligt genom att bygga på / referera befintliga (externa) profileringsarbeten som bedöms vederhäftiga, kvalitativa, ändamålsenliga och under en förtroendefull förvaltningsprocess (t.ex. Web-Service-profiler från WS-I, Web Service Interoperability Organization)
5. Breda lösningar
   Anvisningarna ska bygga på tekniker med bred förankring och tillämpning i utvecklingsverktyg och bland användare i ett internationellt perspektiv
6. Målgruppsanpassning
   Anvisningarna ska målgruppsanpassas. Detta kan t.ex. ske med grund i WS-I:s profiler och det arbete som gjorts inom Danska OIO. Syfte är att en användare ska kunna kliva in på ”rätt” nivå. Denna princip relaterar till Enkelhet.
7. Återanvändning
   Anvisningarna ska vara uppdelade med tanke på återanvändning. Det är t.ex. viktigt att kuverteringsstandards kan utvecklas parallellt med standards som relaterar till innehåll och att anvisningar för målgrupp med höga krav kan bygga på anvisningar för målgrupp med lägre krav. Anvisningarna ska hjälpa till att styra så att bindning mellan innehåll och kommunikationsteknik i run-time minimeras. Som ett exempel bör alla regler som avser tekniska aspekter på innehåll vara tillämpbara fristående från SOAP eller annan kuverteringsteknik.
8. Spårbarhet
   Anvisningarna ska redovisa syfte och krav för varje regel. Det ska finnas spårbarhet kring varje regel, så att en framtida revision kan utföras utan deltagande av författare till tidigare revision.
9. Öppenhet
   Anvisningarna ska förvaltas på ett sätt som prioriterar transparens, öppenhet, tillgänglighet och delaktighet av såväl förvaltningsorganisation, intressenter samt nationella och internationella remissinstanser.
10. Konsolidering
    Innehåll och förvaltningsprocesser ska utgå från att en gradvis konsolidering av tekniska anvisningar för interoperabilitet kommer att ske såväl nationellt som på EU-nivå.

4         Tillämpade strategier

För att kunna utveckla anvisningar som följer de styrande principerna, har ett antal strategier utarbetats. Syftet med strategierna är att ge konkreta ”tillsvidare”-riktlinjer som leder till resultat i linje med principerna.

1. Terminologi
   Anvisningarna baseras på terminologi från T-boken.
2. Kvalitetssäkring
   Varje version åtföljs av automatiserade testfall som verifierar att anvisningen kan följas. Testfallen beskriver tester för verifiering av specifikationen som sådan. De utgör därmed förvaltningens tolkning av hur specifikationen ska tillämpas. Automatiseringen av testfallen syftar till att verifiera specifikationens tekniska riktighet med avseende på konsistens samt krav rörande interoperabilitet, versionering och följsamhet mot t-bokens referensarkitektur. Dessa automatiserade tester är inte avsedda att verifiera tjänsters följsamhet mot anvisningen, utan att verifiera anvisningen som sådan. Detta är en förutsättning för ge specifikationen färdig-status. Tester som syftar till att verifiera tjänsters följsamhet mot den färdiga anvisningen, faller under rubriken Enkelhet.
3. Enkelhet
   Varje version åtföljs av exempelkod för aktuella plattformar, samt ev. andra hjälpmedel för att underlätta användningen. Idéer finns om verktyg för generering av korrekt WSDL, samt om valideringsverktyg. Utbildningsmaterial (kurs i RIV Tekniska Anvisningar).
4. Lättviktighet
   Anvisningarna byggs som tillägg till WS-I-profiler. De hålls kortfattade och fria från beskrivningar av allmänna sammanhang så som WS-I, SOA, tjänsteplattform, T-bok.
5. Breda lösningar
   Genom att basera anvisningarna på WS-I-profiler och profilering gjord hos andra länder minskas risker och vi kan då också återanvända annat arbete.

För att tillmötesgå krav på kontrollerad vidareutveckling av tjänstekontrakt behöver en vedertagen strategi för bevarande av framåt- och bakåtkompatibilitet integreras i anvisningarna. Här används W3C:s arbete som utgångspunkt. Motiv och krav för stöd för denna form av versionshantering beskrivs utförligt i separat avsnitt i detta dokument.

Exempel: Danska IT&Telestyrelsens riktlinjer för användande av Web Services:

Standarder for webservices

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:

-          Läsa fastställda releaseplaner

-          Lämna förslag på förändringar

-          Läsa inkomna förändringar och deras status i beslutsprocessen

-          Läsa mötesplanen för den grupp som beslutar om förändringar (påverkar status på inkomna förslag)

-          Läsa eller hämta anvisningar

-          Hämta och / eller interaktivt använda hjälpmedel i form av exempelapplikationer, generatorer m.m.

1. Konsolidering
   Genom att ha så få vårdspecifika detaljer i RIV Tekniska anvisningar som möjligt, understöds en framtida övergång till en förvaltningsövergripande interoperabilitetsstandard. Genom strategin som föreslagits för principen om breda lösningar, skapas förutsättningar för såväl kanonisering av RIV TA som för att ersätta RIV TA med en externt utvecklad motsvarighet.

5       Terminologi

Detta avsnitt beskriver termer som används genomgående i RIV Tekniska Anvisningar.

5.1     Termer och symboler för utbyte av meddelande

Följande termer används för att beskriva grundläggande utbyte av meddelanden:

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

5.2    Termer och symboler för tjänsteinteraktioner

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

Samverkan mellan två parter enligt någon av interaktionstyperna Fråga-Svar, Informationsspridning och Uppdrag-Resultat. Parterna är abstrakta och benämns generellt "Initiativtagare" och "Utförare" (jmfr WS-BPEL "Initiator", "Responder"). En tjänsteinteraktion beskriver de tjänstekontrakt som uttrycker meddelandeutbytet mellan parterna.

För interaktionstyperna Fråga-Svar och Informationsspridning beskrivs meddelandeutbytet av det tjänstekontrakt som realiseras av Utföraren.

Interaktionstypen Uppdrag-Resultat definierar ett bilateralt utbyte mellan parterna. Initiavitagaren ger utföraren ett uppdrag genom att anropa operationer i dess tjänstekontrakt. Utföraren avslutar interaktionen genom att anropa operation i initiativtagarens tjänstekontrakt i syfte att delge resultatet. I tjänsteinteraktioner av denna typ definierar initiativtagare och utförare bara en operation var.

Tekniskt sett beskrivs en tjänsteinteraktion som en WSDL med beroende till ett eller ett par tjänstescheman (beroende på typ).

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

5.2.4       Övriga termer

Tabell 1 Termer

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

Certifikatstyp för autentisering av tjänstekomponenter och för kryptering i syfte att åstadkomma insynsskydd vid meddelandeöverföring mellan tjänsteproducent och tjänstekonsument. Används t.ex. för autentisering och kryptering i samband med HTTPS mutual authentication. Se HCC v2.34 för referens.

6       Anvisningarnas uppdelning

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

7       Relation till T-bokens referensarkitektur

Anvisningen i T-boken beskriver en referensarkitektur för samverkan mellan vårdens IT-system. Merparten av de termer och begrepp som används i RIV Tekniska Anvisningar har där sin bakgrund och motivation. Strukturen i RIV Tekniska anvisningar speglar referensarkitekturen. Nedan illustreras hur dessa begrepp förhåller sig till tekniska artefakter och vilka anvisningar som styr utformningen av dem.

Sambanden redovisas för varje enskild typ av tjänsteinteraktion som definieras av T-bokens referensarkitektur: Fråga-svar, Informationsspridning och Uppdrag-resultat. För varje typ av tjänsteinteraktion används ett exempel baserat på EN13606-standarden. Tjänsteinteraktionerna återges i form av ett UML klassdiagram och visualiseras m.h.a. UML sekvensdiagram.

Tjänsteinteraktionen EHR.ExtractionInteraction är hämtad ur verkligheten. Enligt referensarkitekturen ska tjänsteinteraktioner klassificeras i tjänstedomäner.

För detaljer om regler för namnsättning hänvisas till RIV Tekniska Anvisningar för tjänsteschema och för profiler - framför allt anvisningen RIV TA Basic Profile.

7.1.1         Tjänsteinteraktionstyp Fråga-svar

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

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

Exemplet är baserat på en generisk begäran om bearbetning av patientinformation och önskan om ett resultatmeddelande när bearbetningen är klar. Notera att interaktionstypen uppdrag-resultat består av två tjänstekontrakt och därmed också två tjänstescheman. Initiativtagaren ger ett uppdrag till utföraren genom att anropa operation i utförarens tjänstekontrakt. Utföraren återvänder vid ett senare tillfälle till initiativtagaren för att leverera resultatet. Det sker genom att utföraren anropar operationen i initiativtagarens tjänstekontrakt. Tjänsteinteraktionen beskrivs av följande UML klassdiagram:

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

8      Övergripande krav på informationsutbyte

Här redovisas de övergripande kraven som gäller oavsett profil. De enskilda profilerna är i sin tur framtagna med utgångspunkt i specifika krav avseende säkerhet, robusthet och andra kvalitetsaspekter kring informationsutbyte.

8.1    Interoperabilitet

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

Anvisningen ska ta rimlig hänsyn till leverantörsspecifika konventioner och ev. brister i följsamhet mot WS-I:s profiler för att uppnå praktisk interoperabilitet. Detta gäller framför allt aktuella versioner av Microsoft Windows Communication Foundation och Java-plattformens motsvarighet JAX-WS.

8.2   Framåt/Bakåtkompatibilitet

Anvisning för Tjänsteschema definierar regler för uppbyggnad av meddelanden för tjänsternas operationer med syfte att styra in mot utbyggbarhet och interoperabilitet. Detta innebär design och namnrymdshantering för att klara krav på framåt- och bakåtkompatibilitet med utgångspunkt i hur XML hanteras i moderna utvecklingsverktyg (Java och .Net). Namnrymder ska också tydliggöra när ett nytt schema definierar en ny version (utan bakåtkompatibilitet) i förhållande till en tidigare version. Utgångspunkten är att det behövs strategier för att minska behovet av nya versioner (genom bakåt/framåt-kompatibilitet), men samtidigt tydliggöra regler för uttag av nya versioner då det inte är möjligt eller ändamålsenligt med bevarad kompatibilitet

Principlösningen är anpassad för att fungera med moderna utvecklingsverktyg för Microsoft (.Net WCF) och Java (JAX WS och JAXB) med ansatsen att generera källkod (C# eller Java) utgående från tjänstekontrakt beskrivna m.h.a. WSDL och XML Scheman.

Den valda strategin för versionshantering är baserad på ett arbete av W3C som beskriver och värderar en uppsättning strategier. Den strategi som tillämpas i RIV Tekniska Anvisningar beskrivs här: http://www.w3.org/2001/tag/doc/versioning-xml#versionid25.

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 nya kompatibla versioner av ett tjänstekontrakt behålls major-siffran medan minor-siffran stegas upp ett steg, t ex från 1.0 till 1.1.

För nya icke kompatibla versioner stegas major-siffran upp och minor-siffran sätts tillbaka till 0, t ex från 1.1 till 2.0.

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:

8.2.2      Bakåt och framåtkompatibilitet

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

I praktiken finns det i huvudsak en typ av förändring som uppfyller såväl bakåt- som framåtkompatibilitet: tillägg av nya, icke-obligatoriska element. Tekniskt sett handlar det om att säkerställa att ett meddelande alltid kan valideras mot den version av XML Schemat som befintliga avsändare och mottagare byggdes för. T ex genereras C#/Java-källkod för att tolka tjänstekontraktets in- och ut meddelanden. Över tiden kommer olika avsändare och mottagare ha källkod som är genererad utgående från olika minor-versioner av tjänstekontraktet.

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.

Utöka nya framåt och bakåtkompatibla versioner av XML Schemat endast med frivilliga element, d.v.s. element som har minOccurs satt till "0".

Se RIV Teknisk anvisning - Tjänsteschema för detaljerade riktlinjer.

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

8.2.4      Icke kompatibla ändringar

När det inte är möjligt eller ändamålsenligt för en ny version av ett tjänstekontrakt att vara kompatibelt med befintlig version måste mottagaren tillhandahålla ändpunkter för såväl den befintliga versionen som den nya icke kompatibla versionen av tjänstekontraktet. Den gamla versionen av tjänstekontraktet måste stödjas under en rimlig tidsrymd så att befintliga avsändare som använder den kan uppgraderas till att använda den nya versionen. Först då kan mottagaren ta bort ändpunkten för den gamla versionen.

Anm. Vad som är en rimlig tidsperiod för avsändare att gå över till en ny icke bakåtkompatibel version av en tjänst är något som inblandade avsändare och mottagare måste komma överens om per fall, alternativt följa riktlinjer i gällande kontrakt.

Följande bild illustrerar behov av två ändpunkter hos mottagaren vid införande av en ny icke kompatibel version, v2.0, av ett tjänstekontrakt:

Avsändare A använder initialt den gamla versionen, v1.0, och avsändare B använder den nya versionen, v2.0. När avsändare A uppdaterat till den nya versionen kan mottagaren ta bort ändpunkten för den gamla versionen. Slutresultatet ser då ut enligt följande:

8.2.5       Versionering och tjänsteinteraktionstyper

När det gäller tjänsteinteraktionstyperna informationsspridning och uppdrag-resultat är det generella resonemanget ovan gångbart, då dessa är baserade på enkelriktade in-operationer.

För tjänsteinteraktionstypen informationsspridning kan man i samtliga resonemang ovan ersätta avsändare med initiativtagare och mottagare med utförare samt ersätta anropspilen med en in-operation, t ex för bakåtkompatibilitet:

För tjänsteinteraktionstypen uppdrag-resultat byter initiativtagare och utförare roll då resultatsmeddelandet skickas men i övrigt är resonemanget samma som ovanstående.

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ör tjänsteinteraktionstypen Fråga-svar uppträder en initiativtagare som avsändare för request-meddelandet och som mottagare för response-meddelandet och vise versa för en utförare. Framåt- och bakåtkompatibilitet gäller med andra ord både in- och ut-meddelanden.

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.

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

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

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 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.3.2      Adressering av källsystem

Den logiska adressen representerar ett källsystem. I detta fall används systemets HSA-id som logisk adress.  Observera att det alltså är källsystemet som pekas ut i den logiska adressen, inte nödvändigtvis tjänsteproducenten (även om det kan vara samma system). På detta sätt uppnås en högre grad av lös koppling än om LA skulle vara en URL eller ip-adress.

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

Motiv: 

1)       Administrationen i TAK minskar eftersom adresseringsinformation enbart registreras per källsystem och tjänstekontrakt i stället för att registreras per vårdenhet (om vårdenhet är verksamhetsbegreppet) och tjänstekontrakt.

2)      Belastningen på tjänsteproducenten minskar eftersom aggregerande tjänster bara behöver göra ett anrop per källsystem istället för ett anrop per vårdenhet. För en kroniker kan det över en 10-årsperiod finnas information på 20-30 olika vårdenheter, varav många kan hanteras i samma system. Det blir då 1-2 anrop per informationsmängd istället för 20-30.

3)     Om man skulle ha verksamhetsbaserad adressering för journalinformation innebär det att varje index-post i EI är märkt med vårdenhet. Kopplingen mellan vårdenhet och organisationsenhet ändras löpande i journalsystemen. Vid varje sådan ändring påverkas ett stort antal befintliga patienter, i det att deras journaluppgifter byter vårdenhet. En konsekvens av det är att alla indexposter i EI som refererar patienter/infomängder som mappats om behöver uppdateras i en stor batch. Det är något som är komplext och prestandamässigt svårt att hantera för journalsystemens EI-anslutningar.

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.

8.4        Adressering av multipla tjänsteplattformar

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 samverkan på sidan 21 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 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

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

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.

9       Förvaltning

Utveckling och förvaltning av RIVTA och dess delar/dokument sker genom att förändringsbehov och/eller 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.

[2] Behov av undantag från detta skall framgå av Tjänstekontraktsbeskrivning och motiveras i form av ett Arkitekturellt beslut.