...
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 avvikelser 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 organisationer som idag administrerar sin HSA-information fullt ut via HSA Admin/HAU
Producenter i denna kategori administrerar 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 fel avvikelser 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.
...
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 tjänster, till exempel 1177.se (tjänsten Hitta vård).
...
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.
...
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 -
...
Tjänsten SITHS (som hanterar
...
kort- och certifikats-information)
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 -
...
Tjänsten Hitta vård (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.
...