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          Inledning utgåva E

Utgåva E syftar till att beskriva de förändringar av adresseringsmodellen som genomförs i samband med aggregerande tjänster. Dessutom införs en förändring av hanteringen av anropsbehörighet, där tjänsteproducenten kan välja huruvida behörighetskontroll skall ske i TP eller inte.

För att på ett entydigt sätt kunna behandla ovanstående har även terminologikapitlet utökats.

Det finns ett stort behov av att gå igenom och revidera hela dokumentet. Många exempel är inte lägre relevanta, ibland till och med felaktiga. Referenserna är inte längre giltiga. Dock har de nya beskrivningarna av adressering och behörighet ansetts så viktiga att utgåva E publiceras utan denna totala översyn. Det får i stället ske i en utgåva F som kommer att tas fram omgående.

...

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:

Image Added

Figur 1 Anvisningarna i sitt sammanhang

...

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

 Image Added

Figur 2 Avsändare och mottagare

...

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:

Image Added

Figur 3 Strukturen i ett meddelande

...

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

5.2.4       Övriga termer

...

Figurerna nedan visar begreppen i sammanhang.

Image Added

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

Image Added

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.

Image Added

Figur 6 Regionala och gemensamma tjänstekomponenter i samverkan

...

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.

Image Added

Figur 7 Anvisningarnas uppdelning

...

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

Image Added

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:

Image Added

Figur 9 Fråga-svar – sekvensdiagram

...

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

Image Added

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

Image Added

Figur 11 Informationsspridning – sekvensdiagram

...

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:

Image Added

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

Image Added

Figur 13 Uppdrag-resultat – sekvensdiagram

...

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ångspunkti 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 än anpassade ä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.

...

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:

Image Added

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:

Image Added

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:

Image Added

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

 Image Added

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:

Image Added

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.

 Image Added

8.2.3      Teknisk realisation av framåt och bakåtkompatibilitet

...

• 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ålareplatshå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.

...

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:

 Image Added

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:

 Image Added

8.2.5       Versionering och tjänsteinteraktionstyper

...

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:

 Image Added

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öljande bild illustrerar behov av bakåt och framåtkompatiblitet i fallet med en gammal initiativtagare och en ny utförare:

Image Added

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:

 Image Added

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.

...

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 19se figur 6 ovan. Adresseringen i en tjänsteplattform riktas alltid till ”nästa” system nedströms, dvs tjänsteproducenten ur tjänsteplattformens perspektiv.

...

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.

Image Added

Figur 14 Verksamhetsbaserad adressering

...

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

Image Added

Figur 15 Adressering av aggregerande tjänst

...

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.

Image Added

Figur 16 Adressering av källsystem

...

Se Figur 6 Regionala och gemensamma tjänstekomponenter i samverkanpå sidan19 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 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        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. 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:

...

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

...

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änsteproducentenfö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.

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