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äller 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.
...
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 sin testdata till den befintliga HSA-testmiljön (totalsynk)
Producenten synkar sedan upp sin 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 den nya användargränssnittet.
Producenten och migreringsgruppen jämför innehållet i de två katalogerna och analys görs vad som eventuellt diffar.
Om inga fel eller oklarheter finns fortsätter migreringsresan till produktionsmiljön.
Producenter som saknar egen testmiljö behöver istället göra en test av sin synklösning mot nya plattformens produktionsvalideringsmiljö.
Denna synktest kommer genomföras på samma sätt som beskrivs ovan. Den stora skillnaden är att det i denna test används produktionsdata från producenten.
Efter avslutad test rensas denna information från produktionsvalideringsmiljön.
Produktionssättning mot Migrering av produktionsdata till nya katalogplattformen:
...
Innan den tekniska migreringen av produktionsdata kan påbörjas ska producenten ha rättat eventuella fel 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.Användare
HSA-ansvarig och ställföreträdande HSA-ansvarig i producentens organisation som ska få åtkomst till det administrativa gränssnittet 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.
Producenten stänger av sin befintliga synk synk mot den befintliga HSA-katalogen och startar upp sin nya synk mot den nya plattformen.
Projektet startar upp en internsynk 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 fel i kontrollkörningarna är åtgärdade innan migrering av produktionsdata kan göras.
Men det stora migreringsaktiviteten för denna kategori är att 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 som idag administrerar sin HSA-information fullt ut via HSA Admin/HAU
I Producenter i denna kategori administrerar producenten 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 den 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 fel i kontrollkörningarna är åtgärdade innan migrering av produktionsdata kan göras. Dessa organisationer har dock oftast färre fel ä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 migrerasmigrera.
...
...
Migrering av konsumenter
Konsumenter
Informationen som publiceras i HSA-katalogen har flera användningsområden och de som behöver få tillgång till HSA informationen kallas konsumenter.. 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.
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 system t ex tjänster, till exempel 1177.se (tjänsten Hitta vård).
Migreringen för denna konsumentkategori handlar om att få dessa filer via eventuellt 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 eventuellt hämta dessa filer från en annan plats än idag.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 Ntjp eller via direktanrop
Migreringen för de som går via NTjP’s tjänstekontrakt kommer kunna fortsätta gör det utan att ändra något i sina egna system då det är projektets ansvar att säkerställa att tjänsten ställs om och hämtar sin HSA-information från nya plattformen.
Migreringen för de konsumenter som idag gör egna direktanrop mot befintliga HSA-plattformen kommer behöva ändra tjänsten på sin sida så den istället går mot nya plattformen för att hämta HSA-informationen. 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 den testmiljö som är kopplad mot NTjP QA (HSA Integrationsmiljö) och därefter i produktionsmiljön som är kopplad mot NTjP Prod (HSA Produktionsmiljö).
Konsumenter som anropar tjänstekontrakten direkt mot HSA kommer utöver ovanstående även sannolikt att behöva ändra anropsadressen för anropen.
Kategori F - Konsumenter som hanterar SITHS information via SITHS rest-api
De konsumenter som idag hanterar SITHS-uppgifterna som lagras i HSA ska ställa om sina anrop så de istället går mot motsvarande SITHS rest api-gränssnitt som den nya plattformen kommer erbjuda.Tjänsten SITHS kommer sannolikt att behöva ändra anropsadressen för anropen.
Ä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 - Notify1177 är en funktion som skickar ändringar av HSA information till 1177
Förutom att hämta in uppgifter via Fileservices så skickas ändringar direkt till konsumenten 1177.se via en tjänsten Notify1177.
Denna tjänst kommer byggas upp på samma sätt i nya plattformen så konsumenten 1177.se får samma information som tidigare och därmed blir migrerad. 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.
...