Bilaga 1 övergång till ny majorversion inom en tillämpning

Inledning

En viss tillämpning eller aktörer inom en informationsförsörjningstjänst kan behöva genomföra en övergång från en majorversion till en annan oavsett om det drivs av behov inom tillämpningen eller någon annans beslut att en viss versions ska avvecklas. Nedan föreslås en modell/process för att genomföra bytet gradvis över flera aktörer.

Enkla tillämpningar, med två eller få aktörer, kan såklart välja att koordinera uppgraderingen och göra den vid ett och samma tillfälle istället.

Hantering av uppgradering till ny majorversion

När beslut om avveckling av stöd för en majorversion av ett tjänstekontrakt tagits och det finns en senare majorversion (eller ett annat kontrakt eller API) som ska ersätta den behöver tillämpningens producenter och konsumenter anpassas till den nya versionen under en övergångsperiod.

Om det är möjligt att ansluta nya konsumenter och producenter enbart till den nya versionen eller ej beror främst på hur kommunikationsbehovet ser ut. För tillämpningar där konsumenten behöver kunna kommunicera med samtliga producenter, tex vid sammanhållen journalföring eller patientens egen åtkomst, så finns det inget egentligt val. Däremot för en tillämpning där en konsument inte måste kunna nå alla producenter så kan en aktörsanalys ge möjlighet att gå direkt på den nyare versionen om alla relevanta aktörer är på den nyare versionen (till exempel för elektronisk remiss )

Så en viktig utgångspunkt i planering för uppgradering är att ha en klar en uppfattning om aktörerna. För tillämpningar med få konsumenter och många producenter är det lämpligt att uppgradera alla konsumenter först. I situationer med många till många (men inte “alla till alla”) så kan det vara värt att försöka gruppera konsumenter och producenter utifrån behov av samverkan.

Producenter

Under en sådan övergångsperiod behöver producenterna fortsätta att stödja den tidigare versionen av tjänsten tills dess att alla konsumenter har utvecklat stöd för den nya majorversionen, eller tills dess att tjänstekontraktsversionens slutdatum, end of life, uppnåtts.

Nya producenter, som inte stödjer någon tidigare version, bör ofta kunna överväga att implementera enbart den nya versionen av kontraktet direkt men det är också beroende av hur konsumentsidan ser ut.

Följaktligen kan det under övergångsperioden finnas producenter som stödjer:

Den utgående majorversionen av kontraktet
Den utgående och den nya majorversionen av kontraktet
Den nya majorversionen av kontraktet

Givet att det kan finnas flera tillämpningar för kontraktet så kan det hända att producenter som ingår i flera tillämpningar kan fortsatt behöva stödja flera versionen tills dess att alla tillämpningar bytt version.

Konsumenter

Nya konsumenter bör under övergångsperioden eftersträva att i första hand implementera stöd för den nya majorversionen av kontraktet men det beror självklart på om informationstäckningen är tillräcklig för de producenter som man behöver kommunicera med.

För befintliga konsumenter bör de, om det inte finns särskilda krav, även fortsätta stödja den tidigare majorversionen eftersom det under övergångsperioden kan finnas producenter som ännu inte stödjer den nya majorversionen.

Konsumenter bör även i första hand prioritera att först anropa den senaste majorversionen av kontraktet för en logisk adressat (LA) och endast falla tillbaka på den tidigare majorversionen för de producenter som inte har stöd för den nya versionen, vilket indikeras med felkoden VP004 som returneras från tjänsteplattformen).

Om de olika majorversionerna skiljer sig så pass mycket åt att man inte på ett rimligt sätt kan stödja dem parallellt bör samverkande parter komma överens om ett brytdatum för byte mellan versionerna.

Vid utveckligen av nya majorversioner av tjänstekontrakt är det viktigt att utvärdera potentiella problem för producenterna att ha två samexisterande versioner och att överväga att undvika sådana ändringar för kontrakt där tillämpningar med många producenter ingår.

Exempel på avvecklingprocess

Principen kan illustreras med följande två exempel:

Båda exemplen har tekniskt samma förutsättningar i det att det inititalt finns två befintliga tjänsteproducenter och tjänstekonsumenter som har stöd för version 1 av tjänstekontraktet (TKv1).

I samband med att version 2 av tjänstekontraktet (TKv2) införs tillkommer en tredje tjänsteproducent.

Utgångsläge, samma för båda exemplen

En tillämpning har två tjänstekonsumenter och två tjänsteproducenter som alla har stöd för tjänstekontrakt version 1 (TKv1) och kommunicerar via NTJP.

Exempelscenario 1

Exempelscenario 2

I detta scenario behöver inte alla parter kunna kommunicera med varandra så viss inkompabilitet bland versionerna är acceptabelt och avgörs av parternas behov. I exemplet så tillkommer Tjänsteproducent 3 i samband med att TKv2 är tillgänglig men bedömer att man inte har behov av att kommunicera med Tjänstekonsument 1. Därför inför man bara stöd för TKv2 även fast Tjänstekonsument 1 bara har stöd för TKv1.

I detta scenario behöver alla konsumenter alltid informationsförsörjas från alla producenter. Därför behöver alla producenter införa även TKv1, tills dess att alla konsumenter uppgraderat, även fast TKv2 finns att tillgå när nya producenter gör sin första implementation.

Fas1 - exempel 1

I exemplet i bild har Tjänstekonsument 2 hunnit implementera Tjänstekontrakt v2 (TKv2) och konsumerar därmed bägge versioner.

Vid anrop mot Tjänsteproducent 1 som endast implementerat stöd för Tjänstekontrakt v1 (TKv1) så kommer Tjänstekonsument 2 att först försöka att göra anropet mot TKv2.

Efter ett misslyckat uppslag i TAK så kommer Tjänstekonsument 2 därefter att anropa TKv1 vilket kommer att lyckas.

Fas 2 - exempel 1

I fas 2 inför Tjänsteproducent 2 stöd för TKv2 och därigenom så kommer Tjänstkonsument kunna kommunicera enbart med TKv2 mot samtliga tjänsteproducenter.

Dessutom tillkommer tjänsteproducent 3 som bara inför stöd för TKv2. Tjänstekonsument 2 kan då kommunicera med alla tre producenterna men Tjänstekonsument 1 är avgränsad till producent 1 & 2

Fas 1 - exempel 2

Tjänstekonsument 1 har stöd för TKv1 och Tjänstekonsument 2 har stöd för både TKv1 och TKv2

Tjänsteproducent 2 skapa stöd för TKv2 men har fortsatt stöd för TKv1 eftersom Tjänstekonsument 1 bara har stöd för TKv1

Fas 2 - exempel 1

I fas 2 inför Tjänsteproducent 2 stöd för TKv2 Nu tillkommer även Tjänsteproducent 3, men trots att TKv2 finns tillgänglig så inför man även stöd för TKv1 eftersom Tjänstekonsument 1 ännu inte har stöd för den nya versionen.

Fas 3 , samma för båda exemplen

I fas 3 inför även tjänstekonsument 1 stöd för Tkv2 och därmed kan alla Tjänsteproducenter avveckla TKv1 för denna tillämpning, i exemplet så behåller Tjänsteproducent 1 och NTJP stödet för TKv1 för att stödja andra tillämpningar.

Konsumenterna avvecklar också stödet för TKv1.