En vägledning för utformning av en interoperabilitetsspecifikation har tagits fram i en första revision
Vi har i Introduktion till samverkansarkitektur övergripande förklarat hur olika arkitekturella dokument relaterar till varandra och hur de kan användas när man tar fram en interoperabel lösning.
Vi har i denna revidering förtydligat många anvisningar, ändrat strukturen för anvisningar, samt hur vi presenterar anvisningar på denna site. Översikten har uppdaterats till att bli teknikoberoende. Vi har infört en ny anvisning för SOAP Web Services och reviderat Basic Profile 2.1, Tjänsteschema, Domänschema, Tjänsteplattform, samt gjort en mindre uppdatering av Livscykelhantering för tjänstekontrakt.
I respektive dokument kan du läsa mer i detalj vad som uppdaterats, men här följer en listning av de mest signifikanta förändringarna
Presentationen "Introduktion samverkansarkitekturen" och en inspelad dragning av den har publicerats.
Mallen har uppdaterats med datatyper för att följa iso-standarden.
Mallen har uppdaterats som del av löpande förvaltning.
Anvisningen har reviderats som del av löpande förvaltning.
Följande leverabler har fastställts i revision A:
Anvisningen har reviderats som del av löpande förvaltning.
Revision B har fokus på system-till-system-kommunikation men innehåller även andra uppdateringar
Anvisningen har avpublicerats då den inte längre förvaltas i sin nuvarande form
I denna uppdatering har man tagit bort information gällande byggskript så dessa ej kommer publiceras i domänpaketeringarna. Även bildtexter har tillförts i dokumentet.
Lagt till en del förtydligande i texten och kompletteringar för att öka läsbarheten och underlätta förståelsen.
Rättat stavfel på headern x-rivta-acting-on-behalf-of-hsaid i regel #24
I denna uppdatering har man utökat beskrivningar och genomfört förtydliganden. Man har även lagt till en bilaga med förslag till tillämpningar kring hantering av uppgradering till ny majorversion
I denna uppdatering har man gjort ett antal förtydliganden och kompletterat med exempel. Dessutom har man uppdaterat versioneringsvägledningen att linjera med de uppdaterade processer som gäller idag.
Då ARK_0031, PDL i praktiken, inte avspeglar nuvarande juridiska tolkningar av patientdatalagen, har dokumentet avpublicerats.
Enligt beslut från Ineras Arkitektursektion sker framöver Verksamhets-/Informatikgranskningar av tjänstekontraktsbeskrivningar (TKB), informationsspecifikationer (IS) och arkitekturella beslut (AB) i form av en självgranskning som tjänster och projekt själva är ansvariga för. I samband med detta har verksamhet- och informatikdelarna tagits bort ur ARK_0050. Detta dokument innehåller nu endast protokoll för säkerhetsgranskning.
Förtydligande gjort av organisationsomfång för administrativa medarbetaruppdrag
I slutet av 2021 upptäcktes en sårbarhet i komponenten Log4J. Log4J ingår som en komponent i SoapUI och ReadyAPI som använts för att ta fram de testsviter som ingår i de tjänstedomäner som Inera förvaltar. Ineras testsviter håller succesivt på att uppdateras och publiceras på rivta.se. De testsviter som ännu inte uppdaterats fungerar endast med äldre versioner SoapUI och ReadyAPI. Log4J har uppdaterats och inkluderats i version 5.6.1 av SoapUI och version 3.10.2 av ReadyAPI. I samband med detta har vissa funktioner tagits bort, vilket gör att de tidigare testsviterna inte längre är kompatibla med senaste versionerna av SoapUI och ReadyAPI.
Information om vilka releasepaket som är uppdaterade med nya testsviter finns på Log4J - Status uppdaterade testsviter
Ny VP-felkod VP015 definierad i RIV Tekniska Anvisningar Tjänsteplattform
Den behörighetsmodell för vård och omsorg som tidigare hittats endast via HSA-förvaltningens informationssidor publiceras nu på rivta.se
I publiceringen 2021-03-12 av anvisningen angav regel #12 felaktigt att VP013 skulle returneras vid rundgång. Detta var fel. Korrekt felkod är VP014.
Då denna anvisning innehåller tvingande anvisningar och namngivningen då varit otydlig avvecklas denna anvisning i syfte att göra det tydligare för läsare. Vi har flyttat generella delar till RIV Tekniska Anvisningar Basic Profile 2.1, version 2.1.6, och det som är specifikt för tjänsteplattformar till RIV Tekniska Anvisningar Tjänsteplattform, version 1.6.
Headern x-rivta-acting-on-behalf-of-hsaid introduceras. Den kan användas för att informera producenter om att ursprunglig konsument anropar görs på begäran av en bakomliggande part.
Förtydligande av hur VP-fel ska representeras avseende faultcode, faultstring och detail. Ny felkod VP013 införs när anrop förmedlats via icke betrodd tjänsteplattform. Alla headrar som inleds med ”x-rivta-” ska vidarebefordras till tjänsteproducenten. Headern x-rivta-routing-history introduceras i syfte att underlätta felsökning. Ny anvisning om ett stabilitetshöjande rundgångsskydd och en ny felkod VP014 för när rundgång inträffat.
T-boken är en arkitekturell beskrivning av hur man ska lösa interoperabilitetsbehov för informationsdelning inom svensk hälso- och sjukvård. Då hantering av källkod och val av licensmodell inte i huvudsak är en arkitekturell fråga utan ett lokalt beslut i de organisationer som realiserar tjänster enligt T-boken och dess anvisningsdokument har vi valt att förändra skrivningarna i kapitel 4.5 i T-boken.
Referensarkitektur för vård och omsorg - T-bokenAnvisningen har förtydligats då det i tidigare anvisning inte var tydliggjort vems ansvar det var att identifiera och ta bort dubbletter då man som konsument anropar flera huvudversioner av ett kontrakt.
RIV Tekniska Anvisningar - Parallella huvudversioner av ett tjänstekontraktI tidigare versioner av anvisningar för tjänsteschema, domänschema och konfigurationsstyrning har det varit otydligt exakt hur man ska hantera multipla minorversioner av tjänstekontrakt. Dessa anvisningar har nu förtydligats och kompletterats med exempel.
RIV Tekniska Anvisningar - Tjänsteschema 2.1
Tidigare version av anvisning för tjänsteschema beskrev best practice kring felhantering på ett sätt som lätt feltolkades. Vi har nu förtydligat hur felhantering ska ske.
Inera publicerar referensarkitektur för elektronisk underskrift och stämpel syftar till att ge stöd till utformning av IT-stöd för att skapa och validera e-underskrifter och e-stämplar. Referensarkitekturen kan i tillämpliga delar appliceras både inom en organisation, och vid samverkan mellan organisationer, till exempel vid delning av tjänster för elektronisk underskrift och hantering av interna och externa undertecknare. Referensarkitekturen är tänkt att användas som referensunderlag vid anskaffning och vidareutveckling av lösningar för elektronisk underskrift och stämpel samt tillhörande stödtjänster, vilket kan omfatta såväl upphandling av leverantörsprodukter, anpassning av befintlig IT-infrastruktur och kravställning på e-tjänster/IT-system för följsamhet till arkitekturen. Referensarkitekturen är tänkt att tillämpas av Inera, regioner och kommuner, men den kan även tillämpas av andra aktörer så som myndigheter och privata utförare. Läs mer på (http://rivta.se/documents/ARK_0060/)
Inera publicerar referensarkitektur för grunddata och kataloger. Grunddata, eller masterdata som det också kallas, är information om organisationer, personer, platser och tjänsteutbud, exempelvis roller, adress och kontaktuppgifter. Referensarkitekturen ska ge stöd till bland annat verksamhetsexperter och it-arkitekter när lösningar och tjänster som hanterar och använder grunddata och kataloger ska utvecklas. Referensarkitekturen bygger på både internationella och svenska ramverk, och tillämpning av standarder och etablerade metoder. Den ska stödja de som arbetar med hantering av grunddata om organisation, person, tjänst och kontaktuppgifter av olika slag. Den ska även att vara ett stöd vid kravställning, utveckling och upphandling av it-system som används för att utbyta sådan information, samt vid förvaltning och framtagande av kataloglösningar. Referensarkitekturen är inte specifik för en viss domän, som exempelvis hälso- och sjukvård, utan ska kunna användas av Ineras alla intressenter som utgångspunkt för utveckling av verksamhets- och domänspecifika lösningar. Läs mer på (http://rivta.se/documents/ARK_0059/)
Det är inte lätt att komma in som ny och börja jobba med nationella tjänster och integrationer. Det är många nya termer att sätta sig in i ("TAK-ning", "aggregerande tjänster"...), och annat betyder inte det man tror (ex att "en tjänstekonsument kan producera information"). För att underlätta introduktionen till området har vi tagit fram en liten text där de grundläggande begreppen sätts i ett sammanhang. Ni hittar den här (http://rivta.se/documents/ARK_0058/)
RIV-Tekniska anvisningar - Översikt 2.0 (http://rivta.se/documents/ARK_0001/) och RIV-Tekniska anvisningar - Tjänsteplattform (http://rivta.se/documents/ARK_0034/) har uppdaterats avseende vägval och anropsbehörighet. Beskrivningar av sk HSA-adressering (trädklättring) samt användning av standardval har lagts till.
Under perioden 15 juni till 13 augusti har Arkitektur och regelverk begränsade möjligheter att hantera inkomna ärenden. Det gäller framförallt ärenden som avser begäran om kvalitetssäkring, beslut om domännamn, begäran om paketering och publicering av release av tjänstedomän samt ansökan om behörighet i Bitbucket. Detta innebär att vi kommer att ta emot inkomna ärenden, men med utökade svarstider på grund av att bemanningen av personal är lägre än normalt.
Nya tjänstedomäntyper som visas nu under respektive tjänstedomän på rivta.se för att
tydliggöra ansvar och förvaltning av tjänstedomäner. Nedan beskrivs tjänstedomäntyper:
Nationell tjänstedomän
Tjänstedomänen utvecklas och/eller förvaltas av Inera. Inera A&R ansvarar för kvalité
inom teknik, informatik, arkitektur och testsviter/tjänsteproducenter, samt att domänen
passar in i och har en tydlig roll i den sammantagna portföljen av nationella
tjänstekontrakt. A&Rs kvalitetssäkringsprocess följs under utvecklings- och
förvaltningsfasen.
Applikationsspecifik tjänstedomän
Tjänstedomänen definierar ett applikations/lösningsspecifikt API till en
applikation/tjänst som ägs av Inera. Applikationsförvaltningen vill återanvända Ineras
anslutningsorganisation och infrastruktur (Tjänsteplattformen), men ha kvar full
kontroll över alla beslut som rör kontraktsdesign, versioner och releaser. Förvaltningen
har ett eget, lokalt ansvar för tjänstekontraktens arkitektur, informatik och teknik
inom ramen för det ansvar som projektet/förvaltningen har för applikationen/tjänsten i
sig. Tjänstekontrakten får bara användas när den specifika applikationen/tjänsten är en
av parterna i informationsutbytet.
Extern tjänstedomän
Annan part än Inera A&R utvecklar/förvaltar tjänstedomänen. Annan part ansvarar för
kvalité inom teknik, informatik och arkitektur. Tjänstekontrakten i tjänstedomänen
följer giltig RIV TA-profil (tjänstekontraktens tekniska utformning och paketering)
och kan därmed driftsättas och anslutningshanteras i NTJP om ICC.s infrastrukturkrav är
uppfyllda. Tjänstekontrakten tillämpas inte inom Ineras uppdrag. Inera A&R ansvarar inte
för namnsättning utöver vad som anges, men kan konsulteras om extern part önskar.
Tjänstekontraktet PingForConfiguration avvecklas
I dag finns det krav enligt regelverket i RIV-TA att tjänsteproducenter, som
tillhandahåller tjänster baserade på nationella tjänstekontrakt, också ska
tillhandahålla en tjänst för att kontrollera status för den informationsförsörjning de
hanterar. Av den anledningen tog vi en gång i tiden fram tjänstekontraktet
PingForConfiguration, som skulle användas för detta.
Det har dock visat sig att nästan ingen använder detta tjänstekontrakt. Antagligen beror
detta på att det varit otydligt hur funktionen i tjänstekontraktet skulle användas, och
vem som skulle använda funktionen. Vi har också fått en del kritik kring själva
strukturen.
Med anledning av detta föreslår vi på Inera att kravet om att använda tjänstekontraktet
PingForConfiguration, tas bort från RIV-TA. Det innebär också att vi slutar supportera
tjänstekontraktet, samt att vi avinstallerar tjänster från Nationella tjänsteplattformen
som är baserade på detta kontrakt.
TKB:n uppdateras
Vi kommer att uppdatera tjänstekontraktbeskrivningen (TKB:n), för att tydliggöra att
kontraktet inte längre behöver användas. I TKB:n kommer vi också att skriva att vi inte
kommer att ha någon nationell support kring kontraktets användning, samt att det heller
inte sker några tillägg eller rättningar av kontraktet.
Bör inte innebära några negativa konsekvenser
Förslaget om att avveckla tjänstekontraktet för nationellt bruk bör inte ha några
negativa konsekvenser för dem som använder nationella tjänstekontrakt, eller innebära
några extra kostnader. Visst arbete kan dock behöva göras av Inera med att uppdatera
domänens dokumentation samt dokumentationen i regelverket för RIV-TA.
Kan fortfarande användas för lokalt bruk
Om någon organisation vill fortsätta att använda tjänstekontraktet för lokalt bruk, så
finns det inget som hindrar detta. Men det kommer inte finnas någon nationell support
eller uppdatering av kontraktet.
Hör av dig om du har synpunkter
Om du inte tycker att vi ska avveckla tjänstekontraktet utan har synpunkter på detta,
vill vi att du hör av dig till oss senast den 8 januari 2018. Om vi inte får in någon
negativ respons på vårt förslag att avveckla kontraktet, så kommer detta att ske första
halvan av 2018. Du hör av dig till oss genom att skicka ett e-postmeddelande till
Kundservice, märk ditt meddelande med ”Avveckling PingForConfiguration”.
Vi har nu ändrat så att ärenden till Inera Arkitektur och regelverk går via Nationell kundservice Läs mer om de olika ärendena.
Tjänstekontraktsbeskrivningar har hittills haft ett avsnitt kallat "webbtext", där
den beskrivningstext som visas under respektive tjänstedomän på inera.se/rivta.se
visas. Vi har nu ändrat denna hantering och sköter istället hanteringen vid sidan om
TKB:er och domängranskningar, genom direkt kommunikation mellan Inera och
Tjänstedomänansvarig. Detta gör att webtextavsnittet nu bör tas bort ur TKB:er,
vilket Inera kommer att upplysa om vid kommande domängranskningar.
Inera kommer att initiera en översyn av respektive domäners webbtext i samband med
nya major-versioner. I övrigt hänvisas Tjänstedomänansvariga att ta kontakt med
arkitektur@inera.se för uppdateringar av webbtexten.
Innehållet från Alla dokument versionshanteras på bitbucket, ärenden och wiki-sidor är uppdelade efter vilken anvisning den tillhör.
Innehållet från Google Code är nu flyttat. Källkod, ärenden och wiki-sidor är numera uppdelade efter vilken tjänstedomän, anvisning eller mjukvara de tillhör.
På grund av Google Codes avveckling har vi har beslutat att migrera RIV TA Tjänstedomänsutveckling till Bitbucket. Ny adress blir http://bitbucket.org/rivta-domains och migreringen kommer till största delen att ske innan midsommar. För mer information om flytten, se här.
Som många vet så avvecklas Google Code under hösten. Vi är just nu i slutfasen av att utvärdera lämpliga kandidater till ersättare. Vi hoppas kunna informera om utgången under maj månad. Därefter är vårt mål att dokument och instruktioner är uppdaterade samt att en migreringsplan finns framtagen innan midsommar.
ARK_0034 anvisning Kryptografi och ARK_0036 Tjänsteplattform är upplagda på RIVTA siten.
Efter policy ändring på Google code så finns zip filer numera att nå via RIVTA.SE.
Scriptet för att verifiera innehåll i en tjänstedomän har uppdaterats till version 1.2.
En uppdatering av konfigurationsstyrningen har publicerats. De viktigaste förändringarna framgår av revisionshistoriken, och är:
En ny revision med fokus på källsystemsadressering och ändrade krav på hantering av anropsbehörighet har publicerats. Dokumentet återfinns via ARK_0001.