Så här går en migrering till
- 1 Producenter
- 2 Migrering av producenter
- 2.1 Kategori A - Producerande organisationer som synkar upp sin HSA-information från lokal katalog och inte använder HSA Admin/HAU för att administrera sin information
- 2.2 Kategori B - Producerande organisationer som synkar från lokal katalog och använder HSA Admin/HAU för att administrera sin information
- 2.3 Kategori C - Producerande organisationer som idag administrerar sin HSA-information fullt ut via HSA Admin/HAU
- 3 Konsumenter
- 4 Migrering av konsumenter
- 4.1 Kategori D - Konsumenter som hämtar HSA-information via HSA FileService
- 4.2 Kategori E - Konsumenter som hämtar HSA-information via tjänstekontrakt (över nationella tjänsteplattformen, NTjP, eller via direktanrop)
- 4.3 Kategori F - Tjänsten SITHS (som hanterar kort- och certifikatsinformation via SITHS REST API)
- 4.4 Kategori G - Tjänsten Hitta vård (avseende funktionaliteten Notify1177)
- 5 När är migreringen klar?
Inom ramen för projektet Ny teknisk plattform för grunddata och katalog (läs mer om projektet här) ska samtliga HSA-anslutna organisationer, deras HSA-information och deras anrop mot HSA, migreras från befintlig HSA-plattform till den nya plattformen för grunddata och katalog.
Producenter
De organisationer som synkar eller manuellt lägger in information i den nationella HSA-katalogen kallas producenter och ska vid migreringen styras om så deras information istället läggs in i den nya plattformen.
Eftersom vi inte kommer kunna migrera alla producenter samtidigt ligger det på projektet att säkerställa att migrerade organisationers HSA-information även finns tillgänglig i den befintliga HSA-katalogen så länge det behövs.
Migrering av producenter
Kategori A - Producerande organisationer som synkar upp sin HSA-information från lokal katalog och inte använder HSA Admin/HAU för att administrera sin information
I denna kategori hanterar producenten sina uppgifter fullt ut i den lokala katalogen och därefter synkas denna information löpande upp till den nationella HSA-plattformen hos Inera via producentens valda synklösning.
Då producenten ställt om sin synk så den går mot nya plattformen för grunddata och katalog kommer projektet i sin tur synka över den migrerade organisationens information så den även finns tillgänglig i befintliga HSA-plattformen så länge den behövs även där.
Test av producentens synklösning:
Producenten får behörighet till den nya HSA-testmiljön för att testa sin synklösning tillsammans med sin synkleverantör och projektets migreringsgrupp.
Producenten synkar först upp sina testdata till den befintliga HSA-testmiljön (totalsynk)
Producenten synkar sedan upp sina testdata till den nya plattformen och verifierar att informationen kommer över korrekt. Eftersom den nya plattformen har en indatakontroll kan vissa uppgifter stoppas och ska då presenteras i den avvikelselogg som är nåbar via inloggning till det nya användargränssnittet.
Producenten och migreringsgruppen jämför innehållet i de två katalogerna och analys görs av vad som eventuellt diffar.
Om inga fel eller oklarheter finns fortsätter migreringsresan till produktionsmiljön.
Producenter som saknar egen testmiljö kan tillsammans med projektet sätta upp en parallell synk i produktionsmiljön som går mot den nya plattformen för grunddata och katalog.
Denna parallella synk genomföras på samma sätt som beskrivs ovan. Den stora skillnaden är att det i denna synk används produktionsdata från producenten.
Då konsumenttjänsterna i detta skede inte migrerats till nya plattformen så kan denna parallellsynk köras mot den nya produktionsmiljön utan risk för störningar.
Migrering av produktionsdata till nya katalogplattformen:
Innan den tekniska migreringen av produktionsdata kan påbörjas ska producenten ha rättat eventuella avvikelser i den befintliga HSA-plattformen utifrån kontrollkörningarna.
Producenten får behörighet för att genomföra migrering av sitt data i produktionsmiljön. Ny synkanvändare och nytt lösenord förmedlas.
HSA-ansvarig och ställföreträdande HSA-ansvarig i producentens organisation läggs upp i ett administrativt medarbetaruppdrag som styr behörigheten i det nya gränssnittet. Därefter kan dessa användare logga in och kontrollera avvikelseloggen utifrån synkarna.
Producenter som kan sätta upp en parallell synk i produktionsmiljön kan på så sätt “produktionsvalidera” sin skarpa information och kontrollera kvaliten då den hanterats i den nya HSA plattformens indatakontroll.
Producenten stänger sedan av sin synk mot den befintliga HSA-katalogen och synkar mot den nya plattformen.
Projektet startar upp en återsynk av den migrerade organisationens information så den synkas från den nya plattformen till den befintliga HSA-plattformen. Denna synk kommer köras tills alla beroenden till befintliga plattformen är ersatta av den nya plattformen och kommer därefter stängas av.
Kategori B - Producerande organisationer som synkar från lokal katalog och använder HSA Admin/HAU för att administrera sin information
I denna kategori hanterar producenten viss information via synkning direkt mot nationella HSA men administrerar även information manuellt via Ineras HSA Admin/HAU gränssnitt.
Precis som för en producent i kategori A ska en kategori B testa sin synklösning mot nya katalogplattformen (Se beskrivning ovan för kategori A). Även producenter i kategori B måste säkerställa att alla avvikelser i kontrollkörningarna är åtgärdade innan migrering av produktionsdata kan göras.
Men den stora skillnaden för denna kategori jämfört med kategori A är att de också ska lära sig att jobba i det nya användargränssnittet som ersätter dagens webbapplikationer HSA Admin och HAU. Om organisationen har fler administratörer än HSA-ansvarig och ställföreträdande HSA-ansvarig ska organisationen också registrera deras behörigheter i administrativa medarbetaruppdrag.
Kategori C - Producerande organisationer som idag administrerar sin HSA-information fullt ut via HSA Admin/HAU
Producenter i denna kategori administrerar all sin HSA-information manuellt via webbapplikationerna HSA Admin och HAU och migreringen för denna kategori kommer framför allt handla om att lära sig det nya användargränssnittet. Om organisationen har fler administratörer än HSA-ansvarig och ställföreträdande HSA-ansvarig ska organisationen också registrera deras behörigheter i administrativa medarbetaruppdrag.
Även producenter i kategori C måste säkerställa att alla avvikelser i kontrollkörningarna är åtgärdade innan migrering av produktionsdata kan göras. Dessa organisationer har dock oftast färre avvikelser än producenter i kategori A och B, eftersom C-organisationerna hanterat sin information i de kontrollerade gränssnitten HSA Admin och HAU.
Projektet kommer att migrera över kategori C-producentens HSA-information från den befintliga plattformen till den nya katalogplattformen när det är dags att migrera.
Konsumenter
Informationen som publiceras i HSA-katalogen har flera användningsområden. De organisationer/tjänster som har fått godkänt av informationsägarna att hämta olika informationsmängder från HSA konsumenter.
Migreringen för konsumenterna går ut på att ändra hämtningen av HSA-information så den går mot den nya plattformen.
Migrering av konsumenter
Kategori D - Konsumenter som hämtar HSA-information via HSA FileService
I den befintliga HSA-plattformen skapas det löpande upp filer som innehåller HSA-information enligt ett förutbestämt format. Dessa filer hämtas upp av konsumenter som använder denna information i sina egna tjänster, till exempel 1177.se (tjänsten Hitta vård).
Migreringen för denna konsumentkategori handlar om att hämta dessa filer från en annan plats än idag.
Det är projektets ansvar att säkerställa att filerna ser ut på samma sätt som de som hämtas idag när de istället genereras i den nya plattformen för grunddata och katalog och att de innehåller samma information som tidigare (med undantag för att information som inte följer regelverket inte finns i den nya plattformen och därmed inte heller kan levereras i filen). Men konsumenten behöver också verifiera att det också fungerar i den egna tjänsten efter migreringen – först i den testmiljö som är kopplad mot HSA Integrationsmiljö och därefter i produktionsmiljö.
Kategori E - Konsumenter som hämtar HSA-information via tjänstekontrakt (över nationella tjänsteplattformen, NTjP, eller via direktanrop)
Konsumenter som anropar tjänstekontrakt över nationella tjänsteplattformen (NTjP) behöver inte göra några tekniska ändringar – dessa gör centralt i NTjP.
Även för denna kategori är det projektets ansvar att säkerställa att kontrakten levererar svar på samma format som idag när svaren istället genereras i den nya plattformen för grunddata och katalog och att de innehåller samma information som tidigare (med undantag för att information som inte följer regelverket inte finns i den nya plattformen och därmed inte heller kan levereras i svaret). Men konsumenten behöver också verifiera att det också fungerar i den egna tjänsten efter migreringen – först i tjänstens testmiljö som är kopplad mot NTjP QA (och HSA Integrationsmiljö) och därefter i tjänstens produktionsmiljö som är kopplad mot NTjP Prod (och HSA Produktionsmiljö).
Konsumenter som anropar tjänstekontrakten direkt mot HSA kommer behöva ändra anropsadressen för tjänsten.
Kategori F - Tjänsten SITHS (som hanterar kort- och certifikatsinformation via SITHS REST API)
Tjänsten SITHS kommer behöva ändra anropsadressen.
Även för denna kategori är det projektets ansvar att säkerställa att anropen levererar svar på samma format och utför ändringar på samma sätt som idag när anropen flyttas över till den nya plattformen för grunddata och katalog och att de innehåller samma information som tidigare (med undantag för att information som inte följer regelverket inte finns i den nya plattformen och därmed inte heller kan levereras i svaret). Men tjänsten SITHS behöver också verifiera att det också fungerar i den egna tjänsten efter migreringen – först i den testmiljö som är kopplad mot HSA Integrationsmiljö och därefter i produktionsmiljön.
Kategori G - Tjänsten Hitta vård (avseende funktionaliteten Notify1177)
Gränssnittet Notify1177 skickar notifieringar om att ändringar gjorts i HSA som är relevanta för tjänsten Hitta vård. Hitta vård gör utifrån notifieringen ett anrop med tjänstekontraktet GetUnit för att hämta den uppdaterade informationen.
Även för denna kategori är det projektets ansvar att säkerställa att notifieringarna levereras på samma format som idag när anropen flyttas över till den nya plattformen för grunddata och katalog och att de innehåller samma information som tidigare (med undantag för att information som inte följer regelverket inte finns i den nya plattformen och därmed inte heller kan generera en notifiering). Men tjänsten Hitta vård behöver också verifiera att det också fungerar i den egna tjänsten efter migreringen – först i den testmiljö som är kopplad mot HSA Integrationsmiljö och därefter i produktionsmiljön.
Tjänsten behöver inte ändra något tekniskt i tjänsten då Notify1177 levererar information till en adress som Hitta vård angivit.
När är migreringen klar?
När alla producenter och konsumenter har migrerats över till den nya plattformen för grunddata och katalog kan den befintliga HSA-katalogen avvecklas.