RIV Tekniska Anvisningar Parallella huvudversioner av ett tjänstekontrakt
 | RIV Tekniska Anvisningar |
Revisionshistorik
Version | Datum | Författare | Kommentar |
1.0 | 2017-02-17 | Lars Erik Röjerås | Första publicerade versionen. |
1.1 | 2020-12-10 | Lars Erik Röjerås | Förtydligade rekommendationer |
Bakgrund
Det saknas en entydig mappning mellan en post i Engagemangsindex och vilken huvudversion, majorversion, av tjänstekontraktet som skall användas för att hämta den utpekade informationen . När en ny huvudversion av ett tjänstekontrakt tas i bruk finns det därför ett antal saker som respektive tjänstekonsument och tjänsteproducent måste förhålla sig till.
Nedan diskuteras fallet med en ny huvudversion av ett specifikt tjänstekontrakt. Samma resonemang behöver appliceras om tjänstedomänen byter namn. Eftersom tjänstedomänens namn ingår i tjänstekontraktets namnrymd kan det innebära att ett ”nytt kontrakt” skapas vars informationsinnehåll överlappar det ursprungliga tjänstekontraktet.
Nya huvudversioner av tjänstekontrakt
En ny majorversion av ett tjänstekontrakt framgår av att den första versionssiffran (före punkten) räknas upp .
Följande står att läsa om majoruppgraderingar i RIV-TA Översikt (ARK_001):
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.
Ett tjänstekontrakt som kommer ut i en ny majorversion kan praktiskt ses som ett nytt kontrakt. Det finns inga krav på bakåtkompatibilitet, och den nya versionen kan (och bör ofta) installeras och användas parallellt med den föregående.
För tjänstekontrakt som är aggregerande innebär detta att det skapas en [JE4] aggregerande tjänst för varje major-version av det underliggande tjänstekontraktet.
Engagemangsindex
En patientrelaterad informationsmängd i ett journalsystem kan ge upphov till en post i Engagemangsindex. För detaljer kring EI och dess informationsinnehåll hänvisas till Tjänstekontraktsbeskrivningen för EI. Följande element ingår som en del i en post:
Invånarens personnummer (eller samordningsnummer)
Den tjänstedomän som informationsförekomsten avser
Kategorisering enligt kodverk som är specifikt för tjänstedomänen. Representerar vilket tjänstekontrakt som skall användas för att hämta informationen ifråga.
Logisk adress att använda för att hämta informationsmängden i fråga. Dvs, logisk adress som Tjänsteplattformen använder för vägval och kontroll av anropsbehörighet till verksamhetssystemet i fråga.
Möjliga angreppssätt när en ny majorversion av tjänstekontrakt releasas.
Se bild ovan.
Ursprungsläge: Ett tjänstekontrakt (TK) finns i en version 1.0 (TKv1). Det finns en aggregerande tjänst (AgtTKv1) i tjänsteplattformen. Tjänstekonsumenterna A och B har stöd för kontraktet, och kan anropa den aggregerande tjänsten. Tjänsteproducenterna 1 och 2 stödjer kontraktet TKv1 och är anslutna till plattformen.
Version 2.0 av kontraktet releasas (TKv2). Det kan stödja andra informationsmängder eller funktionalitet jämfört med TKv1. Det kan även gälla andra regler för hur lång historik som skall tillhandahållas. Eftersom det är en ny major så skapas och produktionssätts en ny aggregerande tjänst, AgTv2.
Tjänsteproducent 1 avvaktar. Man har inte budget för att bygga stöd för TKv2 förrän om 12 månader.
Tjänsteproducent 2 realiserar TKv2. Eftersom det är en ny major behåller man (tills vidare) stödet även för TKv1.
Tjänsteproducent 3 realiserar TKv2. Eftersom det är en ny producent så väljer man att gå på TKv2, och beslutar att inte stödja TKv1.
Tjänstekonsument A avvaktar. Man anser sig inte behöva de nya förmågor/informationsmängder som TKv2 tillhandahåller.
Tjänstekonsument B implementerar stöd för TKv2. Man behöver information från Tjänsteproducent 3, och då finns enbart TKv2 att tillgå.
Tjänstekonsument C implementerar stöd för TKv2. Det är en ny tjänstekonsument, och man vill inte investera i TKv1 som man upplever är på väg att fasas ut.
Konsekvenser av angreppssätten ovan
Tjänstekonsument A. Den kommer endast att kunna anropa den aggregerande tjänsten AgTTKv1, och då få information från de producenter som stödjer tjänstekontraktet TKv1.
Tjänstekonsument C. Den kommer endast att kunna anropa den aggregerande tjänsten AgTTKv2, och då få information från de producenter som stödjer tjänstekontraktet TKv2.
Tjänstekonsument B. Om denna tjänstekonsument vill hämta information från alla tjänsteproducenter så måste den anropa de båda aggregerande tjänsterna AgTTKv1 och AgTTKv2. Dessa kommer båda att anropa tjänsteproducent 2. Det innebär att Tjänstekonsument B kommer att kunna få samma informationsmängder i de två anropen. Den kan inte bara lägga samman svaren, utan måste också rensa bort eventuella dubbletter.
Motsvarande hantering måste ske när ett system anropas av Engagemangsindex med ett ProcessNotification. Systemet får agera utifrån vilka huvudversioner den stödjer och anropa tjänsteproducenten en eller flera gånger. Sedan får man vid behov rensa bort dubbletter.
Rekommendationer
Begränsa tjänstekonsumentens anropsbehörighet
En aggregerad tjänst baserar sina anrop till tjänsteproducenter på den anropande tjänstekonsumentens behörighet. I många fall kan multipla anrop undvikas genom att tjänstekonsumenten enbart har anropsbehörighet till en version av tjänstekontraktet för varje tjänsteproducent. När en tjänstekonsument ges anropsbehörighet till en ny majorversion av ett tjänstekontrakt hos en specifik tjänsteproducent bör samtidigt anropsbehörigheten för den lägre versionen tas bort. Detta skulle lösa problemet för Tjänstekonsument B i exemplet ovan.
Tyvärr finns det fall, ex när anrop sker via en regional tjänsteplattform, när denna begränsning inte är möjlig.
Identifiera och tag bort dubbletter
Tjänstekonsumenter vars anrop går via aggregerande tjänster bör alltid förberedas för att kunna identifiera och hantera svarsdubbletter.
För att kunna identifiera dubbletter behöver ett antal fält i de olika majorversionerna av kontraktet jämföras med varandra. Ett fält är identifieraren för den huvudsakliga informationsmängden som tjänstekontraktet avser, t.ex. identifieraren för vårdkontakten eller identifieraren för undersökningsresultatet. Om denna identifierare inte är universellt unik så behövs även källsystemets identifierare för att identifiera dubbletter. Identifieraren för den huvudsakliga informationsmängden måste identifiera samma informationsmängd mellan de olika majorversionerna.
Vilka fält som behöver jämföras för att identifiera dubbletter framgår av respektive TKB.