Frågor och svar

Kommer T2 - välfärden ersätta T-boken?

Nej, T2 - välfärden kan tillämpas för att erbjuda digitala tjänster som inte kan erbjudas i dagens tjänsteplattformsinfrastruktur med dess begränsningar till SOAP och XML.

Det finns i dagsläget inga planer på att migrera dagens samverkan via RIVTA-tjänstekontrakt till nya mönster och ny infrastruktur.

Eventuell migrering av en specifik samverkan kan planeras in i tjänstens roadmap när en infrastruktur som tillåter detta har etablerats.

Kommer T2 - välfärden att kompletteras med nya tekniska anvisningar?

Många tekniska anvisningar som idag finns publicerade under RIV-TA kommer att vara giltiga även i framtiden.

T2 - välfärden kommer i sig inte innehålla anvisningar utan detta kommer att tas fram i specialiserade arkitekturer kopplat till olika verksamhetsområden. Till exempel T2 - vård och omsorg där nya anvisningar kopplat till nya samverkansmönster och nya interoperabilitetsspecifikationer kan komma att växa fram.

Kommer NTjP att ersättas eller kommer tjänsteplattformen existera parallellt med framtida infrastruktur?

Det finns ingen intention att avveckla befintlig användning av NTjP. Dock är det tänkt att samverkan inom T2 - välfärden ska ske direkt mellan organisationer och inte genom en nationell proxy.

Nationella tjänster som realiseras inom T2 - välfärden kommer att ha behov av vissa förmågor som idag erbjuds genom NTjP. Dessa kan enligt T2 -välfärden realiseras fristående. Till exempel tjänstesökning, aggregering och informationslokalisering.

Vad menas med begreppet “välfärd” i T2 - välfärden?

I NE definieras välfärden som: ”I Sverige är välfärd ett samlingsbegrepp för socialförsäkringssystemet och välfärdstjänsterna vård, skola och omsorg…”

Arkitekturen är framtagen med fokus på de kommunala och regional välfärdsområdena (vård, skola och omsorg samt socialförsäkring). Arkitekturen är dock så pass generell att den kan användas inom andra regional och kommunala verksamhetsområden än inom välfärdsområdet varför några av våra exempel även belyser dessa användningsområden.

Ni skriver "T2 är inte en översättning av EIRA, varpå skillnader mellan hur EIRA beskriver byggblock och relationer kan komma att skilja sig från hur T2 beskriver motsvarigheterna i T2-arkitekturen." Finns det någonstans dokumenterat motiven till dessa ev skillnader eller är det bara ett faktum? 

Det finns inte dokumenterat, men kontextskillnaderna mellan T2 och EIRA har gjort att vi valt att anpassa T2:s modell efter de kontext där T2 är tänkt att användas.

T2 refererar specifikt till EIRA version 3.1.0. Finns något motiv till just detta versionsval eller råkar det ha varit den senaste rådande version vid tiden för utformning av T2? Senaste version idag är 5.0.0. Finns någon strategi för hur T2 ska takta med DIGG och EIRA?

Det var den version som var tillgänglig när arbetet startades. T2 kommer att förvaltas och uppdateras i enlighet med övriga artefakter relaterade till T-boken

Bör inte även åtkomsthanteringen separeras från applikationsvyn likt identitetshantering?

Gränserna mellan vyerna kommer från referensarkitekturen EIRA (European Interoperability Reference Architecture), vilken T2 - välfärden har använt som intellektuellt kapital.

Gällande åtkomsthantering så är detta inget infrastrukturellt byggblock ur ett interoperabilitetsperspektiv på samma sätt som identitetshantering.

Lokalt hanteras ofta åtkomsthantering av en central komponent inom tjänsteproducentorganisationen, men samma komponent kan normalt inte delas av flera tjänsteproducenter då det legala ansvaret för åtkomstbeslut ligger på respektive tjänsteproducent.

Identitetshantering måste bygga på en gemensamt överenskommen tillitsmodell för att fungera och realiseras ofta i en identitetsfederation.

I EIRA benämns byggblocken ofta som antingen “component” eller “service” men i T2 saknas denna del av benämningen, varför då?

Eftersom T2 är en referensarkitektur så är det byggblockets abstrakta tillämpning som avses och därför utelämnas “service” och “component”. I en lösningsarkitetktur som bygger på T2 specificeras om realiseringen är i form av en tjänst eller en komponent.

Vilka konsekvenser får det att parter ska ha direkt kommunikation med varandra utan att gå via en central plattform? Hur påverkas till exempel loggning och förutsättningar för uppföljning?

Vi har identifierat tre huvudsakliga konsekvenser, men det kan finnas fler.

1. Man kan inte sammanställa statistik för allt informationsutbyte över regiongränser.

   Detta allena ser vi inte motiverar en gemensam proxyserver utan kan lösas på annat sätt.

2. Man kan inte få stöd av Ineras tjänsteplattformsförvaltning för felsökning vid informationsutbyte över regiongränser.

   Vi ser det som en fördel att direkt veta var felet till källan är och inte längre behöva stöd i detta.

3. För att möjliggöra direkt kommunikation behöver varje aktör exponera sin lokala API-gateway så att samverkansparter kan nå den nätverksmässigt. Idag kan man låsa extern åtkomst till tjänsteplattformens IP adress.

   Vi ser inte denna säkerhetsmekanism med IP-filter som tillräckligt skydd utan ser att detta redan idag borde kompletteras med annat skydd (DDOS, IDS/IPS, MTLS, IAM, mm) i dagens it-miljö med cyberkriminalitet. Det har därför inte setts som en allvarlig konsekvens.

Vad blir konsekvenserna/skillnaden för anslutning jämfört med dagsläget där parter ansluter till NTJP och hur påverkar det logisk adressering samt eventuell felsökning? 

T2 bygger på att parter som ska utbyta information med varandra kommunicerar direkt med varandra snarare än att gå via en förmedlande part som NTJP.

För att stödja logisk adressering används stödtjänster som tjänstesökning som den anropande parten använder sig av för att hitta aktuell anslutningsadress (baserat på logisk adress, se exempel i T2 vård och omsorg, teknisk vy). Tjänstesökningen kan då ses som en fristående version av NTJP TAK, men endast för adressinformation.

Därefter sker anropet direkt till den part man vill nå. En konsekvens av direkt kommunikation är att man behöver säkra att alla parter som behöver ansluta kan göra det utan föregående explicit konfiguration av brandväggar och liknande för att tillåta trafik till respektive organisations anslutningspunkt (liknande koncept som "Säker Digital Kommunikation").

När det gäller felsökning så bör denna underlättas eftersom fel som returneras i ett visst anrop bara har två tänkbara parter som ursprung och det bör vara lättare att tolka meddelandet.

Hur ska rekommendationen att inte bryta krypteringskedjor hanteras i fall där man använder agenter på producent eller konsumentsidan?

Rekommendationen kring obruten transportkryptering avser kommunikationen mellan de huvudsakliga parterna. Om en part på sin sida anlitar en agent så anses det ur T2 perspektiv vara en del av den lokala lösningen och hantering av krypteringen därmed en “intern” fråga för respektive part.

Varför beskriver inte T2 en enhetlig mall eller struktur för interoperabilitetsspecifikationer?

Givet att T2 inte låser sig vid en viss standard för informationsutbyte så är det svårt att definiera en generisk struktur för hur det ska beskrivas.

Inom till exempel HL7 FHIR så kan mycket av det som ska finnas i en interoperablitetsspecifikation beskrivas via en eller flera implementationsguider och dess referenser till resurser, utökningar och profileringar.

Andra standarder kan ha andra sätt att beskriva detta. så syftet med interoperabilitetsspecifikationen på "T2-nivå" är att tala om vad som behöver beskrivas, sen får man inom till exempel informationsfederationer bestämma hur det beskrivs.

Är huvudsyftet med T2 den tekniska interoperabiliteten eller skall även den semantiska detaljeras (T2 vs RIV TA)?

T2 beskriver just nu mest mönster för teknisk samverkan semantiken är mer realiseringsnära men samtidigt mer övergripande. En samverkan enligt T2 kan till exempel utformas med befintliga tjänstekontrakt och då är ju semantiken redan "klar"

DIGG skriver i sin Grundläggande principer för digital samverkan under pkt 3 att ett av huvudsyftet är att öppna upp. Detta blir lite paradoxalt för vården då det inte är vårt primära fokus utan det är  att dokumentera om patienten för patienten. Kan detta anses i fallande vikt så att inom vård och omsorg är detta inte ett primärfokus?

Det ska väl tolkas att det som kan öppnas upp ska göra det, till exempel organisationsinformation men det innebär inte nödvändigtvis att allt ska vara öppet

Varför är så många principer av typen "BÖR" istället för "SKA"

Dels är principerna inte utformade specifikt i arbete med T2 utan det är DIGGs principer som vi applicerar och anledningen till att T2s förtydligande rekommendationer oftast använder "BÖR" har sin grund i att det är en referensarkitektur så syftet är att man i en lösningsarkitektur beaktar rekommendationen och beslutar om den är tillämplig i det aktuella fallet.

I T2-5 Designa semantisk interoperabilitet oberoende av teknik,  står "Den semantiska interoperabilitetsspecifikationen ska designas….." hur tänker man att strukturen för detta  skall gå till, är det en nationell samverkansgrupp som tar fram specifikationen eller?

Beror på situation, antingen tas den fram av den som huvudsakligen bär information eller av en sammanslutning av aktörer som vill samverka