Integration til Fordelingskomponenten sf2900

[gBarlach]

Opsummering af udviklingsønske:

Der ønskes en integration mellem OS2forms (som anvendes af Aarhus Kommune samt andre OS2forms-kommuner) og KOMBITs Fordelingskomponent (SF2900). Formålet er at automatisere indsendelsen af specifikke KL-blanketter (såsom ansøgninger om helbredstillæg og personligt tillæg) direkte fra OS2forms til Kommunernes Pensionssystem (KP).
Løsningen skal eliminere de nuværende manuelle processer forbundet med disse blanketter, hvilket vil reducere fejl, forkorte sagsbehandlingstiden, mindske de administrative udgifter og forbedre sagsbehandlernes arbejdsmiljø. Den nye integration vil sikre, at OS2forms-kommuner kan håndtere disse ansøgninger fra borgerne effektivt og på lige fod med andre leverandørers løsninger.
Funktionaliteten skal inkludere robust fejlhåndtering via errorlogs samt fleksibel konfiguration (på samme måde som eksisterende Core-handlers i OS2forms).

Arbejdet udføres i 3 faser:

1. Indledende afklaring og løsningsdesign
2. Udvikling af handler og advanced queue
3. Testimplementering af workflow

Bestiller: MSB i Aarhus Kommune sammen med øvrige interesserede kommuner i OS2forms. Godkendt af OS2forms fællesskabets Styregruppe. 

Beskrivelse:

Fordelingskomponenten, https://digitaliseringskataloget.dk/integration/sf2900,  er vejen ind til flere systemer under KOMBIT’s paraply, men i casen her er der særligt fokus på at kunne aflevere fra OS2forms til ydelsessystemet KP (Kommunernes Pensionssystem)  
Integrationen sikrer at borgernes ansøgninger om hjælp til udgifter forbundet med deres helbred, fordi de er dårligt stillet økonomisk af den ene eller den anden grund. 

Alle kommuner der benytter sig af OS2forms som selvbetjeningssystem, har behov for at kunne levere følgende KL-blanketter ind i KP, på lige fod med EG og Visma’s løsninger. Vi har brug for integration til sf2900 til at kunne levere på denne opgave på lige fod med de andre leverandører på markedet. Vi kan ikke komme af med EG selvbetjening, før de udfordringer løst. 

De understøttede selvbetjeningsløsninger er som udgangspunkt følgende:  

• SP 241 Ansøgning om helbredstillæg (Helbredskort) 
• SP 242 Ansøgning om Udvidet helbredstillæg 
• SP 501 Ansøgning om Personligt tillæg 
• SP 246 Specificeret overslag fra optiker-øjenlæge 
• Anmodning om refusion i forbindelse med udgifter til behandling

På nuværende tidspunkt er de fleste arbejdsgange forbundet med de blanketter som i første omgang understøttes af KOMBIT’s fordelingskomponent, udført manuelt. Det medfører flere fejl og længere behandlingstider. De bruger mange ressourcer på medarbejdere der modtager og indtaster data. Der er risiko for at enkelte ansøgninger glemmes eller ”falder mellem to stole” da processerne ikke overvåges 

User stories:

1. Som Siteadmin ønsker jeg at selvbetjeningsløsningen SP 242 Ansøgning om Udvidet helbredstillæg i OS2forms via Fordelingskomponenten kan aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem), så sagsbehandler ikke skal journalisere manuelt. 

2. Som Siteadmin ønsker jeg at selvbetjeningsløsningen SP 241 Ansøgning om helbredstillæg (Helbredskort)  i OS2forms via Fordelingskomponenten kan aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem), så sagsbehandler ikke skal journalisere manuelt. 

3. Som Siteadmin ønsker jeg at selvbetjeningsløsningen SP 501 Ansøgning om Personligt tillæg  i OS2forms via Fordelingskomponenten kan aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem), så sagsbehandler ikke skal journalisere manuelt. 

4. Som Siteadmin ønsker jeg at selvbetjeningsløsningen SP 246 Specificeret overslag fra optiker-øjenlæge  i OS2forms via Fordelingskomponenten kan aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem), så sagsbehandler ikke skal journalisere manuelt. 

5. Som Siteadmin ønsker jeg at selvbetjeningsløsningen Anmodning om refusion i forbindelse med udgifter til behandling  i OS2forms via Fordelingskomponenten kan aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem), så sagsbehandler ikke skal journalisere manuelt. 

6. Som siteadmin ønsker jeg at eventuelle fejl fra Fordelingskomponent handler fremgår af errorlog, så jeg kan få overblik og mulighed for at håndtere dem. 

7. Som Siteadmin ønsker jeg at kunne konfigurere Fordelingskomponent handler kan konfigureres på samme vis som øvrige Core handlers, så jeg eksempelvis kan bestemme om den skal trigges på kladder eller ej.

8. Som Siteadmin ønsker jeg at de formularer, jeg bygger med Fordelingskomponent handleren, valideres den op mod relevant xsd fil, så jeg med det samme ved, om formularen er korrekt / ukorrekt ift. de krav, Fordelingskomponent stiller. 

Acceptkriterier samt test stories (Hvad skal fungere for at leverancen er færdig.):

Acceptkriterie 1: Selvbetjeningsløsningen SP 242 Ansøgning om Udvidet helbredstillæg i OS2forms  kan via Fordelingskomponenten aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem)

Acceptkriterie 2: Selvbetjeningsløsningen SP 241 Ansøgning om helbredstillæg (Helbredskort) i OS2forms  kan via Fordelingskomponenten aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem)

Acceptkriterie 3: Selvbetjeningsløsningen SP 501 Ansøgning om Personligt tillæg i OS2forms  kan via Fordelingskomponenten aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem)

Acceptkriterie 4: Selvbetjeningsløsningen SP 246 Specificeret overslag fra optiker-øjenlæge kan via Fordelingskomponenten aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem)

Acceptkriterie 5: Selvbetjeningsløsningen Anmodning om refusion i forbindelse med udgifter til behandling i OS2forms  kan via Fordelingskomponenten aflevere til  ydelsessystemet KP (Kommunernes Pensionssystem)

Acceptkriterie 6
E2E test (TC-01-TC-10) skal være gennemført og bestået (se bilag testaftale os2forms) 

Acceptkriterie 7:. Fordelingskomponent handler anvender advanced queue, og fejl fremgår af errorlog, så siteadmin kan få overblik over fejl, og mulighed for at håndtere dem. 

Acceptkriterie 8. Fordelingskomponent handler kan konfigureres på samme vis som øvrige Core handlers, så siteadmin eksempelvis kan bestemme, om den skal trigges på kladder eller ej.

Acceptkriterie 9: de formularer, der bygges med Fordelingskomponent handleren, valideres den op mod relevant xsd fil. når formularen bygges, rettes og gemmes, så formularen enten godkendes som korrekt eller kommer ud med en fejl ift. de krav, Fordelingskomponent stiller. 

Acceptkriterie 10:
— Teknisk dokumentation godkendt af Core maintainer
— PR til Core er fremsat 
— Code review er bestået

Hvem kan bruge denne funktionalitet
Interessenter vil være de ansvarlige for de centre i kommunerne der afholder udgifter til manuel journalisering og manuelle arbejdsgange forbundet med ovenstående blanketter. De vil kunne se frem til væsentlige administrative besparelser, der er så attraktive at man allerede nu har indgået kontrakt med eksisterende leverandører på KL-blanketter i de enkelte kommuner, uanset leverandør. 

Beskriv gevinsten ved funktionen:

• Kortere sagsbehandlingstid på ansøgning om ydelser for den borgergruppe der bruger blanketterne i denne case, og for alle borgere der bruger blanketter der ender i KOMBIT’s systemer i fremtiden.
• Reducere udgifter til manuelle administrative opgaver
• Procesunderstøttelsen og sagsbehandlingen vil fremover foregå i fagsystemet i stedet for på mail, og andre til formålet opfundet værktøjer.
• Mindre vedligehold af lappeløsninger i form af scanning af mail, sorteringspolitiker og små robotter der hjælper med dele af den manuelle arbejdsgang

Hvad er funktionen til
Integration til Fordelingskomponenten mhp at journalisere journalnotater og dokumenter i relevante fagsystemer. Udvalgt case er fagsystemet KP - Kommunernes Pensionssystem

Udfyldes af OS2forms Product Owner:

Krav til dokumentation. Hvilke( n) type(r) dokumentation skal der laves:
Integrationsoverblik (tekst/diagrammer) JA
Teknisk implementeringsguide/installationsvejledning JA
Superbrugerguide JA såfremt der er særlige forhold der gør sig gældende
Skærmbilleder af det udviklede JA
Kodekommentarer JA
PR og commit beskeder JA

Opsætning / konfiguration af testmiljø
JA

ITK Development opsætter lokalt for Aarhus (stg. eller dev.server)
Bellcom opsætter på det fælles OS2forms testmiljø

Overførsel af formularer til testmiljø
JA
ITK Development overfører formularerne lokalt for Aarhus (stg. eller dev.server)
Bellcom overfører formularerne på det fælles OS2forms testmiljø

Oprettelse af testbrugere på testmiljø:
JA/NEJ

Tilbagelevering til OS2forms fællesskabet incl dokumentation
JA
Forinden skal afklares hvad dokumentationen helt præcist skal indeholde. Se under "Skal afklare".

Udfyldes af leverandøren forud for opgavestart:

Estimat:
Leverance- og procesplan:

Ved aflevering af det udviklede:

Beskrivelse af det leverede:
Hvilket miljø testes på:
Opmærksomhedspunkter ift. testbrugere og testmiljø funktionalitet: 
Test forretningen skal være opmærksom på:
PR:
Vedligehold fremadrettet:

Bilag:

Dokumentation / teknisk hjælpepakke fremsendt af KOMBIT:
https://boks.os2.eu/s/jkN5byAd8pgSeyH

[ds-bellcom]

Hej @gBarlach.

Vi hjælper gerne med et scope på de dele af opgaven, som du/I mener, at vi kan eller skal hjælpe med. Vi vil i den forbindelse meget gerne vide, hvad du/I konkret ser os bidrage med – helt lavpraktisk. Det må gerne være så detaljeret som muligt, så vi undgår eventuelle misforståelser.

Hvad er tidshorisonten på projektet? Gerne opdelt i de forskellige steps, hvor du/I ser os involveret.

Når vi kender mere til ovenstående, vil det også være muligt for os at komme med et estimat.

CC: @ChatBotBerg @skifter

[ds-bellcom]

Som aftalt på dagens møde, så er her det overblik jeg lavede.

[Anna-itk]

Som jeg ser det skal user story 8 i ovenstående rettes da det er ikke Fordelingskomponenten, der stiller krav i form af xsd'en - det er KP.

[Anna-itk]

Vi skal vælge én af to følgende scenarier ift. strukturering af denne opgave:

1. Fordele acceptkriterier og user stories på subissues og slette dem på denne parent-opgave
2. Fordele acceptkriterier og user stories på subissues og lade dem stå på denne parent-opgave

@ds-bellcom og @ChatBotBerg hvad synes I?

[ds-bellcom]

Vi skal vælge én af to følgende scenarier ift. strukturering af denne opgave:

1. Fordele acceptkriterier og user stories på subissues og slette dem på denne parent-opgave
2. Fordele acceptkriterier og user stories på subissues og lade dem stå på denne parent-opgave

@ds-bellcom og @ChatBotBerg hvad synes I?

Vi synes klart at scenarie nr. 2 er bedst. Så har man acceptkriterierne og user stories ved hånden på subissues, og det samme gælder, når der skal laves en sluttest, hvor man ikke nødvendigvis går ned gennem alle subissues for at se acceptkriterier og user stories.

@Anna-itk @ChatBotBerg

[ChatBotBerg]

@Anna-itk @ds-bellcom : min holdning er at vi skal have dem i overskrift på både parent og under opgaver, men at userstories skal være tilgængelige i detaljeret form i et selvstændigt issues - og at acceptkriterier skal være understøttet af verifikationsmetode og testcases ( nok i seperat issue).