RIV Tekniska Anvisningar Översikt
| RIV Tekniska Anvisningar Översikt
Version 3.0 ARK_0001 2024-09-18 |
Versionshistorik | |||
Utgåva | Revision Datum | Beskrivning | Ändringarna gjorda av |
A | 2009-10-06 | Revision A fastställd av Arkitekturledningens tekniska expertgrupp. | Magnus Larsson Johan Eltes |
B | 2011-10-19 | Fastställd revision Anpassat för uppgradering av Basic Profile 2.0 till Basic Profile 2.1 |
|
C | 2012-01-03 | Fastställd revision Uppdaterat dokumentet i och med byte av projektplats från Osor till Google code. |
|
D | 2013-05-27 | Uppdateringar… |
|
E | 2014-04-03 | Beskrivning av källsystemsbaserad adressering samt ändrad hantering av anropsbehörighet. Utvidgad och förändrad skrivning om adresseringsmodell (avsnitt 8.3) | Lars-Erik Röjerås |
2.0.1 | 2014-12-08 | Flyttade till Inera-mall | Lars-Erik Röjerås |
2.0.2 | 2015-12-17 | Tagit bort stycket ”Inledning till utgåva E”. | Mattias Nordvall |
2.0.3 | 2018-01-18 | Tagit bort kapitel 8.7 som handlade om PingForConfiguration funktionen inte längre kravställs | Björn Hedman |
2.0.4 | 2018-08-27 | Lagt till kapitel 8.6 HSA-baserat vägval och anropsbehörighet och 8.7 Standardval för vägval och anropsbehörighet. | Lars Erik Röjerås |
2.0.5 | 2021-09-09 | Tagit bort obsoleta mailadresser från revisionshistoriken. Ersatt dem med endast namn | Anders Malmros |
3.0
| 2024-09-18 | Generaliserat innehållet i översikt för att detta ska vara teknik- och standardoberoende och lämna utrymme för realiseringar baserat på flera standarder. Förtydligat ingress till kapitel 1. Inledning 1.5 Referenser har tagits bort och ersatts av länkar i löptext Skrivit om kapitel 2. Anvisningarna i sitt sammanhang. Flyttat kapitel 3. Styrande principer och kapitel 4. Tillämpade strategier till en Inera-intern förvaltningsvägledning Uppdaterat kapitel 5. Terminologi till att reflektera den terminologi som används i RIV Tekniska Anvisningar. Tagit bort kapitel 6. Anvisningarnas uppdelning Tagit bort kapitel 7. Relation till T-bokens referensarkitektur Förtydligat kapitel 8. Övergripande krav på informationsutbyte avseende logisk adressering och anropsbehörighet. Flyttat realiseringsdetaljer specifika för SOAP Webservices till dels den nya anvisningen RIV-TA SOAP Webservices, dels de existerande anvisningarna RIV-TA Livscykelhantering för tjänstekontrakt och RIV-TA Tjänsteplattform.
Uppdaterat kapitelnumrering efter ovanstående ändringar. Tagit bort kommentarer i versionshistoriken om preliminära releaser och flyttat in väsentligt material i huvudversionens beskrivning. Ändringar av övriga formuleringar som ej var formella regler
| Anders Malmros Björn Hedman |
1. Inledning
RIV står för Regelverk för Interoperabilitet inom Vård och omsorg och utgår från fastställda referensarkitekturer för interoperabel samverkan. RIV kompletteras med Tekniska Anvisningar (RIV-TA) som beskriver hur aktörer ska tillämpa referensarkitekturerna för att etablera interoperabel verksamhetsstödjande samverkan med hög säkerhet, god kvalitet och robusthet.
Detta dokument är en övergripande beskrivning för RIV Tekniska Anvisningar som koncept samt dess ingående delar.
RIV Tekniska Anvisningar publiceras på hemsidan http://www.rivta.se.
1.1 Målgrupp
Dokumentet riktar sig till aktörer som vill få en grundlig förståelse av RIV Tekniska anvisningar samt för motiven bakom dessa.
1.2 Syfte
Översikten syftar till att beskriva konceptuellt hur man realiserar utbytet av information mellan två parter och visar hur anvisningarna samverkar. Dessutom tydliggörs vad som kan förväntas av de tekniska profiler som utarbetas.
1.3 Tillgänglighet
Detta dokument är publicerat 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 Regioner anges, men inte på ett sätt som antyder att de godkänt eller rekommenderar din användning av verket.
1.4 Förvaltning
Utveckling och förvaltning av RIV-TA och dess delar/dokument sker genom att förändringsbehov och/eller förslag skickas in till Inera via e-post till kundservice@inera.se. Ange "RIVTA: Anvisningens namn"" i ämnesraden.
2. Anvisningarna i sitt sammanhang
RIV Tekniska Anvisningar (RIV-TA) är en samling dokument med regler, instruktioner och vägledning. Det är uppdelade för att beskriva en viss aspekt eller ett visst område av interoperabel samverkan.
RIV-TA beskriver hur nationell samverkan inom svensk kommunal och regional sektor realiseras enligt fastställda referensarkitekturer som till exempel Referensarkitektur för vård och omsorg - T-boken och Referensarkitektur för identitet och åtkomst.
RIV-TA bygger i stor utsträckning på etablerade öppna standarder.
Sveriges kommuners och regioners förvaltningsgemensamma och lokala realiseringar av infrastrukturella komponenter som möjliggör nationell samverkan enligt T-bokens mönster ska vara följsamma mot tillämpliga delar av RIV-TA.
RIV Tekniska Anvisningar | Beskrivning |
---|---|
RIV-TA Översikt (detta dokument) | Beskriver hur RIV-TA:s dokument är uppdelade samt beskriver olika samverkansaspekter på en konceptuell nivå. |
RIV-TA SOAP Webservices | Sammanhållande anvisning för Webservice/SOA och innefattar anvisningar för:
|
RIV-TA Säkerhet | RIV-TA Anvisning Binära bilagor - Regelverk för hur binära bilagor inbäddas i tjänstekontrakt baserade på RIV-profilen Basic Profile 2.1, samt vägledning kring hur bilagor kan refereras till från tjänstekontrakt. RIV-TA Anvisning Kryptering - Anvisning för kryptering gällande transport och lagring av information för tjänster som Inera tillhandahåller. RIV-TA Anvisning Autentisering - Principer och krav för autentisering till tjänster som Inera tillhandahåller och omfattar åtkomst till tjänster med eller utan patientinformation. RIV-TA Anvisning för Säkerhet i Drift - Anvisning för säkerhet i driftsmiljön anger hur säkerhetsaspekter ska hanteras gällande Inera AB:s tjänster och IT-drift. RIV-TA Tillämpningsanvisning PDL-loggning - Anvisning för hur ”PDL loggningen” ska ske i enlighet med tjänsterna för loggning inom nationell samverkan |
RIV-TA Utveckling | RIV-TA Anvisning Kryptering - Anvisning för kryptering gällande transport och lagring av information för tjänster som Inera tillhandahåller. RIV-TA Anvisning Binära bilagor - Regelverk för hur binära bilagor inbäddas i tjänstekontrakt baserade på RIV-profilen Basic Profile 2.1, samt vägledning kring hur bilagor kan refereras till från tjänstekontrakt. |
3. Terminologi
Detta avsnitt beskriver termer som används genomgående i RIV Tekniska Anvisningar.
Term | Förkortning | Beskrivning |
---|---|---|
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. Aggregerande tjänster agerar både Utförare och Initiativtagare eftersom de tar emot en begäran och sedan hämtar information från flera källor. Principerna för aggregerande tjänster är beskrivet i Referensarkitektur för vård och omsorg - T-boken |
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. Utformningen av ett engagemangsindex kan variera mellan olika standarder. |
Initiativtagare |
| Tjänstekomponent som initierar en tjänsteinteraktion. |
Interoperabilitetsspecifikation |
| Beskrivning över hur samverkan utformas. Nationella tjänstekontrakt och dess tjänstekontraktsbeskrivning är en form av interoperabilitetsspecifikation. |
Källsystem (KS) |
| Det verksamhetssystem där informationen ursprungligen skapats (t.ex. en driftsinstans av ett journalsystem). |
Källsystemsbaserad logisk adress |
| Logisk adress som baseras på IT-system (källsystem). Ofta används systemets HSA-id som adress. (se avsnitt om logisk adressering för vidare information om principer för logisk adressering) |
Logisk adress | LA | Adresseringsbegrepp i RIV-TA. En indirekt adressering bidrar till lös koppling mellan tjänstekonsumenter och tjänsteproducenter. Logisk adress används för att slå upp aktuell teknisk anslutningsadress. |
Teknisk anslutningsadress |
| Den tekniska adress där en tjänsteproducent publicerar tjänsten. Är normalt en URL vid användning av http-baserade protokoll. |
RIV-profil |
| Tilläggsprofil till de interoperabilitetsprofiler som definieras i olika standarder. |
SITHS HCC Funktionscertifikat |
| 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. HCC står för Health Care Certificate. Se SITHS för ytterligare information. http://www.inera.se/siths |
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. |
Tjänsteadresseringskatalog | TAK | Tjänsteadresseringskatalogen är en stödtjänst som erbjuder administration och åtkomst av information som ligger till grund för adressering. Hur TAK används kan variera mellan olika implementationer, i en trafikförmedlande komponent (tjänsteplattform) är den ofta integrerad men den kan också realiseras fristående så att tjänstekonsumenter anropar TAK direkt. |
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. |
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 e-tjänst, ett verksamhetssystem, en partneringång eller en tjänsteplattform. Tjänstekonsumenten agerar som initiativtagare i en interaktion. |
Tjänsteproducent | TjP | Tjänsteproducenter uppvisar ett tekniskt gränssnitt som möjliggör för tjänstekonsumenter att 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. |
Utförare |
| Tjänstekomponent som en initiativtagare interagerar med i en tjänsteinteraktion |
Verksamhetsbaserad logisk adress |
| Logisk adress som baseras på verksamhet eller organisation. Vanligen används verksamhetens HSA-id som adress. |
3.1 Termer för tjänsteinteraktioner
Följande uppställning beskriver de olika tjänsteinteraktionstyperna och hur de visualiseras i anvisningarna:
Fråga-Svar Initiativtagaren gör ett synkront anrop med en fråga till utföraren som utför uppdraget och returnerar resultatet i svaret. |
|
Informationsspridning Initiativtagaren gör ett anrop till utföraren som kvitterar anropet men inte returnerar något annat svar. | |
Uppdrag-Resultat Initiativtagaren gör ett anrop till utförarens tjänsteproducent med en begäran om uppdrag. Utföraren utför uppdraget och anropar därefter den ursprungliga initiativtagarens tjänsteproducent för att leverera resultatet. Notera att tekniskt sett så byter aktörerna roller eftersom den som utfört uppdraget blir tjänstekonsument för att leverera svaret. |
3.2 Termer för samverkansmönster
Figurerna nedan visar de mest centrala termerna för några olika samverkansmönster.
Direktsamverkan
Samverkan via tjänsteplattform
Samverkan via aggregerande tjänst
Aggregerande tjänster exekveras inom ramen för någon form av aggregeringsplattform. De använder sig av någon form av informationslokalisering, till exempel via ett engagemangsindex för att få information om vilka tjänsteproducenter som skall anropas. Anropen kan sedan ske via en tjänsteplattform eller direkt till tjänsteproducenten.
4. Övergripande krav på informationsutbyte
Här redovisas de övergripande kraven som gäller oavsett vilken teknisk standard som en viss realisering bygger på.
4.1 Logisk adressering
Vid behandling av logiska adresser ska dessa alltid tolkas skiftlägesokänsligt (utan skillnad på versala och gemena bokstäver). Detta gäller vid all behandling, inklusive åtgärder som dublettkontroll vid persistering och för sökning vid adressuppslag.
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. Logiska adresser översätts alltid till tekniska anslutningsadresser genom uppslag i en adresskälla.
Detta gäller i alla led - alltså även vid federerade arkitekturer där en virtuell tjänst i en tjänsteplattform dirigerar ett anrop till en tjänsteproducent som i själva verket visar sig vara en virtuell tjänst i en annan tjänsteplattform. Adresseringen i en tjänsteplattform riktas alltid till ”nästa” system nedströms, dvs tjänsteproducenten ur tjänsteplattformens perspektiv. Den logiska adressen vidarebefordras alltid för potentiell användning hos mottagande system.
Tjänster som produceras av en tjänsteplattform benämns “virtuella tjänster”. En virtuell tjänst besvarar inte anrop själv utan vidarebefordrar till bakomliggande tjänsteproducent.
Interoperabilitesspecifikationerna detaljerar reglerna för hur den logiska adressen ska deklareras i en tjänsteinteraktion. Antingen direkt eller genom att peka ut en basprofil.
I RIVTA Basic Profile 2.1 deklareras logisk adress i tjänsteinteraktionens WSDL i form av SOAP-header. Se separat anvisning för detaljer
Andra interoperabilitesspecifikationer eller basprofiler kan peka på annan användning.
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 många organisationer länkas samman med varandra, men var och en ansvarar för sin del.
Inom vård och omsorg finns en uppsättning typfall för hur man adresserar digitala tjänster. I samtliga fall är adresseringsmodellens syfte att bidra till lös koppling mellan tjänstekonsument och tjänsteproducent. Logisk adressering kan realiseras på olika sätt, till exempel inbyggt i en tjänsteplattform eller som en fristående tjänst för adressuppslag.
Adresseringsmodellen säkerställer tillsammans med tjänsteadresseringskatalogen att alla parter i arkitekturen kan uttrycka vem som är mottagare av ett meddelande utan att behöva ha kunskap om mottagarens realisering. Detta görs genom att man med hjälp av den logiska adressen hämtar tjänsteproducentens tekniska anslutningsadress via ett adressuppslag i tjänsteadresseringskatalogen. En verksamhet kan därmed förändra sin realisering utan att detta påverkar logiska adresser och därmed tjänstekonsumenter. Det enda som behöver uppdateras är den tekniska anslutningsadressen i tjänsteadresseringskatalogen.
Den logiska adressen kan representeras av en textsträng, OID eller liknande. Hur en logisk adress ska uttryckas bestäms i en interoperabilitetsspecifikation och kan därmed variera mellan olika standarder.
I den nuvarande SOAP-arkitekturen är tekniskt sett det enda kravet på en logisk adress att den är en sträng och att den i kombination med tjänstekontrakt, och dess version, är unikt representerad i den källa som används för att översätta den logiska adressen till en url. Detta gäller oavsett om det är verksamhets- eller källsystemsadressering som används.
I praktisk tillämpning finns det fördelar med att använda identifierare från en gemensam källa, som till exempel HSA-katalogen, som logisk adress både för att säkerställa unicitet men också för att göra det enklare att spåra organisatorisk tillhörighet för den logiska adressen. Vid verksamhetsadressering så kan användning av organisationsidentifierare på rätt nivå också underlätta samverkan med utbudskataloger och dylikt. Därför används HSA-id i nedanstående exempel.
Observera att användningen av HSA-id som logisk adress inte i sig ställer krav på att det finns ett funktionscertifikat enligt SITHS-modellen för att styrka producentens serveridentitet under adressering och anrop. System och organisationsenheter kan registreras i HSA-katalogen utan att det finns krav på att det skapas SITHS certifikat.
Den logiska adressen representerar normalt ett av dessa koncept:
Verksamhet/organisation
Ett källsystem
4.1.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. Vilka värden som används som logiska adresser definieras av en interoperabilitetsspecifikation. Den logiska adressen utgörs i denna modell av en organisatorisk identifierare. Typiskt används organisationens HSA-id som adress men även organisationsnummer kan användas då båda dessa uppfyller kraven på unicitet och spårbarhet.
Exempel på logisk adressering i en interaktion utformad enligt Basic Profile 2.1:
En tjänstekonsument vill boka en tid hos en viss vårdenhet och använder dess organisatoriska adress (SE1112) som logisk adress. Den logiska adressen används för att slå upp den tekniska anslutningsadressen (URL:en) för det källsystem (p1.region1.se) som betjänar den logiska adressen. Därefter anropas källsystemet med den tekniska adressen som URL. Den logiska adressen (SE1112) skickas med som en del i anropet via SOAP-headern LogicalAddress så att källsystemet vet vilken logisk adress som anropet avser.
Som framgår ovan så är p1.region1.se ett källsystem men adresseringen av anropet sker med den logiska adressen (HSA-id) för verksamheten eftersom det är denna som är känd utifrån ett verksamhetsperspektiv.
4.1.2 Källsystemsbaserad adressering
Den logiska adressen representerar ett källsystem. I exemplet nedan används det HSA-id som adresserar systemet som logisk adress. Att HSA-id används är dels för spårbarhet, dels för att underlätta att skapa unika adresser.
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 systemet skulle adresseras direkt med en URL eller IP-adress.
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 och utan att behöva ange verksamheternas identiteter explicit. Adresseringsmodellen har införts främst som ett sätt att avlasta källsystem och integrationsinfrastrukturen vid aggregering.
Tabellen nedan visar när källsystembaserad adressering kan användas, samt hur tjänstekonsumenten erhåller den logiska adressen.
Tabell 2 Exempel på användande av källsystemsbaserad adressering
Tjänstekonsument | Användningsfall | Förmedling av logisk adress |
---|---|---|
Aggregerande tjänst | Det vanliga adresseringsförfarandet när aggregerande tjänst anropar Tjänsteproducenter | Hämtas genom informationslokalisering, såsom till exempel engagemangsindex Detaljer kring informationsinnehåll och tjänstekontrakt i domänen engagemangsindex återfinns i dess tjänstekontraktsbeskrivning. |
Tjänstekonsument (av aggregerande tjänst) | Anrop av källsystem för att hämta kompletterande information | Tjänstekonsumenten erhåller logisk adress via svaret på ett tidigare anrop till en aggregerande tjänst |
Nationell kvalitetsregisterregistrering (NKRR) | Informationsförsörjning av kvalitetsregister via NKRR från specifika källsystem | Logisk adress hämtas från lokalt adressregister |
4.1.3 Val av adresseringsmetod
Den som ansvarar för utvecklingen av en interoperabilitetsspecifikation behöver fundera över vad som är den mest lämpade adresseringsmetoden vid olika situationer.
Det är tillämpningen och datalandskapet som är mest avgörande för valet så det kan inte uteslutas att olika tillämpningar kan behöva använda olika adresseringsmetoder även inom samma domän. Val av adresseringsmetod(er) framgår av interoperabilitetsspecifikationen.
Observera att samma tjänsteproducent kan adresseras på olika sätt vid olika tillfällen. En aggregerande tjänst som adresseras via en verksamhetsbaserad logisk adress kan i nästa steg adressera tjänsteproducenter via källsystemsadresser.
Rekommendation källsystemsadressering
Källsystemsadressering kan vara lämpligt i situationer där man behöver lokalisera och hämta information utan att man har kännedom på förhand om inom vilken/vilka organisationer som informationen existerar. I dessa situationer används ofta aggregerande tjänster som baserar sig på index för lokaliseringen och då kan källsystemsadressering underlätta både hanteringen av indexinformationen och anropsmönstret till källsystemen.
Motiv
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.
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 tioå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.
Om man skulle ha verksamhetsbaserad adressering för journalinformation innebär det att varje index-post i Engagemangsindex är märkt med vårdenhet. Kopplingen mellan vårdenhet och organisatorisk enhet ä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 Engagemangsindex som refererar patienter/informationsmängder som mappats om behöver uppdateras i en stor batch. Det är komplext och prestandamässigt svårt att hantera för journalsystemens Engagemangsindexanslutningar.
Antalet poster i Engagemangsindex blir mindre eftersom det endast blir en post per källsystem, patient och informationstyp i stället för en post per enhet, patient och informationstyp.
Konsekvenser för tjänsteproducenter
Om ett källsystem adresseras direkt, med källsystemsbaserad adressering, ska det kontrollera om det behöver avgränsa/filtrera svaret utifrån parametrar i begäran. Exempel på avgränsning är vårdenhet eller vårdgivare.
Om systemet stödjer flera logiska adresser så ska det alltid kontrollera vilken logiska adress som används vid anropet och anpassa svaret utifrån den logiska adressen.
Rekommendation verksamhetsadressering
Verksamhetsadressering lämpar sig väl för informationshantering där kontexten för anropet huvudsakligen utgörs av en viss verksamhet.
Motiv
Styrande princip IT4: Lös koppling i T-boken (Referensarkitektur för vård och omsorg - T-boken). Verksamhetsbaserade logiska adresser innebär en lösare koppling mellan tjänstekomponenterna. Tjänstekonsumenten får inget beroende till systemstrukturen hos anropad verksamhet.
Konsekvenser för tjänsteproducenter
Om den logiska adressen är en verksamhetsadress ska filtrering av returnerad information göras på information tillhörande den adresserade verksamheten. Filtrering ska alltid ske både baserat på den logiska adressen och på eventuella parametrar i anropets meddelande.
4.2 Anropsbehörighet
En tjänstekonsuments behörighet att anropa en tjänsteproducent kan regleras på flera nivåer, och på flera platser i infrastrukturen. Grunden är att en tjänstekonsuments möjlighet att använda en viss tjänst kräver att en grundläggande tillit etablerats till organisationen som ansvarar för tjänstekonsumenten.
4.2.1 Organisationstillit
Organisationstillit innebär att lita på att den samverkande parten är en relevant aktör samt har förmåga att hantera den information som delas enligt gällande lagar och informationsklassificering. Kraven på organisatoriska tillitsskapande förmågor regleras av lagar, avtal eller andra överenskommelser och regelverk. Detta benäms ofta som tillramverk.
Affärsmässiga - finns offentligt finansierat uppdrag? Är man registrerad vårdgivare hos IVO? Har man relevanta försäkringar (exempelvis patientförsäkring och ansvarsförsäkring)
Informationssäkerhetsmässiga - besitter organisationen adekvat nivå av tillitsskapande förmågor genom certifiering gentemot ISO27001 eller motsvarande?
Kvalitetsmässiga - Besitter organisationen förmågor inom kvalitetssäkringsområdet för att kunna uppfylla gemensamt överenskomna kvalitetskrav?
För ytterligare resonemang kring tillit mellan organisationer se T-Boken, IT6: Samverkan i federation. (kapitel 4.6 i revision D)
4.2.2 Delegerad åtkomsthantering baserad på organisationstillit
Organisationstillit innebär att man har tillit till andra parter och därför delegerar ansvar för behörighetsbeslut och spårbarhetsloggning för informationsbehandlingen till den part informationen delas med. Varje organisation ansvarar för att de egna systemen är korrekta i sin funktion och har adekvata skyddsmekanismer. Vid samverkan som baseras på organisationstillit förutsätter man att respektive part säkerställer att:
Överförd information är korrekt.
Information hanteras på ett säkert sätt och att obehöriga parter vare sig kan ta del av eller manipulera information.
Information endast behandlas i överenskommet syfte och följsamt mot gällande lagstiftning, ingångna avtal och policyer.
4.2.3 Etablerade tillitskedjor
Ett digitalt informationsutbyte kan involvera en kedja av aktörer och tillit till informationsutbytet i sin helhet kräver förtroende för varje enskild aktörs tillitsskapande förmågor. Tillit uppnås genom att tillitsramverket stipulerar regelverk för varje aktörstyp samt adekvata mekanismer för att säkerställa följsamhet och att dessa upprätthålls över tid.
Tilliten i samverkan är transitiv. Transitiv innebär i den här kontexten att beslutet om att vidarebefordra ett visst anrop från ett tjänstekonsumerande system till en viss logisk adressat inte tar hänsyn till vad som döljer sig bakom det tjänstekonsumerande systemet eller hur den logiska adressatens tjänsteproducerande system är realiserat.
Varje tjänstekonsumerande part i kedjan ansvarar för att säkerställa:
Att behörighetsgrundande information tillgängliggörs i anropet
Att kommunikation skyddas av TLS.
Att tjänsteproducerande är en part som man har tillit till.
Varje tjänsteproducerande part i kedjan ansvarar för att säkerställa:
Att tjänstekonsumentens identitet är giltig och utgiven av en betrodd identitetsutgivare.
Att tjänstekonsumerande part är en part som man har tillit till.
Att behörighetsgrundande information finns att tillgå.
Att beslut om åtkomst kan fattas följsamt mot gällande lag och ingångna avtal.
4.2.4 Realisering av åtkomsthantering
Tjänsteproducenten kan fastställa tjänstekonsumentens rätt att anropa baserat på ett flertal olika typer av åtkomststyrande information
Information i klientcertifikat.
Information i kuverteringens headrar enligt proprietärt format.
Åtkomstintyg, exempelvis enligt OAuth 2
http headrar
Olika standarder kan använda olika metoder och att det är interoperabilitetsspecifikationen som definierar vad som ska användas, antingen direkt, eller genom att peka ut en RIV-profil eller liknade.
Åtkomsthanteringen utförs för att kontrollera att tjänstekonsument har rätt att använda tjänsten samt vilka behörigheter som konsumenten har. Detta realiseras i regel genom att utvärdera tjänstekonsumentens behörighetsgrundande information mot tjänstens åtkomstpolicy.
Se Referensarkitektur - Identitet och åtkomst för detaljer.
4.2.5 Informationsbehörighet
Även om en tjänstekonsument har åtkomst till en tjänsteproducent betyder inte det att man är behörig att ta del av all information som matchar en förfrågan. Det kan finnas lokalt implementerade regelverk och policyer som begränsar vad som delas. Denna typ av filtrering som sker vid behandlingen av en förfrågan ska resultera i exkludering av informationsposter och avgör vilken information som returneras.