Prosím doplniť spôsob vysporiadania s vendr lockom, a to napr.:
Konkrétne v zmysle § 15 ods. 2 písm. d) zákona č. 95/2019 Z. z. informačných technológiách vo verejnej správe:
Vo fáze prípravy a obstarania projektu je správca povinný akceptovať také zmluvné podmienky, podľa ktorých:
zdrojový kód vytvorený počas projektu bude otvorený v súlade s licenčnými podmienkami verejnej softvérovej licencie Európskej únie podľa osobitného predpisu, a to v rozsahu, v akom zverejnenie tohto kódu nemôže byť zneužité na činnosť smerujúcu k narušeniu alebo k zničeniu informačného systému verejnej správy,
je jediným a výhradným disponentom so všetkými informáciami zhromaždenými alebo získanými počas projektu a prevádzky projektom vytvoreného riešenia vrátane jeho zmien a servisu a
3. pri zmene dodávateľa pôvodný dodávateľ poskytne správcovi úplnú súčinnosť pri prechode na nového dodávateľa, najmä v oblasti architektúry a integrácie informačných systémov.
V projekte nejde len o posilnenie IS MOU. Ide aj o zvýšenie kvality dát, aj o distribúciu a spracovanie zmien dát, štandardizáciu dátového modelu, a poskytovanie otvorených dát. Treba upresniť, o aké notifikácie sa jedná. Nemá ísť o notifikácie v zmysle komunikácie s klientom pri riešení konania ale v kontexte MOU ide o notifikácie o prístupe k dátam a o zmene dát dotknutej osoby.
Áno v projekte nejde len o notifikácie, a budú realizované aj iné oblasti v projekte, ti sú rozpísané v kapitolách nižšie. V kapitole „Realizovanie aktivít v projekte v zmysle výzvy sú popísané aj typy notifikácii
Z pohľadu tohto popisu MUSP mi nedáva zmysel dátová komunikácia v Obrázku 2 (prehľad IS dotknutých v projekte). Prečo nie je v znázornenej dátovej komunikácii nijako zapojený MUSP, keď podľa tohto popisu v proj. prístupe a popisu ISVS v METAIS by mal MUSP byť určený na výmenu údajov a centr. úložisko údajov? (Podľa METAIS je MUSP: "Informačný systém na správu údajov v prostredí SP. Riešenie MÚSP vychádza z konceptu správy kmeňových údajov, čo je súbor osvedčenejších skúseností zahŕňajúcich procesy, politiky, a nástroje, zabezpečujúce kmeňové údaje v celom informačnom prostredí SP. IS MUSP zjednotí dáta o klientovi, nakoľko v súčasných systémoch má každý systém svoje údaje, IS MUSP uvedené údaje zjednotí, aby boli komplexné údaje o klientoch SP"
Nemá SP priamu integráciu na RFO a teda nepoužíva CDPI/CSRÚ na získanie ref. údajov o FO? Nemá SP aj priamu integráciu na RPO? A teda neplatí to, čo je tu uvedené?
V projekte na lepšie údaje by nemali byť dohady o tom, čo pravdepodobne systém obsahuje. Predpokladám, že sa tu mal na mysli referenčný register dań. subjektov isvs_6113, ktorý je podmodulom Integrovaného informačného systému FS (isvs_4859), ktorý je integrovaný na CPDI. Alebo niečo iné?
V súlade s ďalším popisom a obrázkom 3 (resp. prílohou Aplikačné služby na integráciu TOBE.pdf) by malo byť hneď uvedené, že bude rozvíjaný Isvs_8729 (Manažment údajov SP) ako platforma manažmentu údajov Soc. poisťovne. V tomto prípae prívlastku nie je celkom na mieste, lebo to nie je a podľa popisu ani nemá ambíciu byť integ. platformou za rezort zahrňujúci všetky subjekty podieľajúce sa na soc. zabezpečení.
Súčasťou nie je riešiť komplexný pohľad SP, ale rozsah projektu je prispôsobený dopytovej výzve a teda rozsah v projekte bude napojenie ISVS (CIPS, IS JVP, IS NPaLPČ a DP) a teda tie systémy, ktoré poskytujú údaje pre IS MOU.
Treba starostlivo oddeliť na aký notifikačný účel bude slúžiť mobilná aplikácia SP a na aký účel mobilná aplikácia MOU (zamerané na notifikácie o prístupe iných osôb k údajom a zmene registrových údajov a vyžiadanie súhlasov na prístup 3. strán k dátam)
Nemala by integrácia isvs_8729 (MUSP) nahradiť čiastkové integrácie isvs_551 (SES) a isvs_8140 (CIPS) , ktoré by komunikáciu s CPDI realizovali cez MUSP?
Áno bude to IS MUSP. Tak ako je uvedené v tabuľke „Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE“ a súčasne aj v arch. v obrázku č. 3
Ako pripomienkujem vyššie skôr ide o Platformu manažmentu a integrácie údajov, bez prívlastku "rezortná". A keďže už veme že touto platformou má byť MUS, tak rovno treba písať, že s jeho využitím budú budované uvedené aplik. služby.
Zmenové dávky a notifikácie o zmenách dát by nemali byť len pre MOU. Aj iní konzumenti údajov by mohli využiť distribúciu zmien údajov SP cez CPDI, či už na aktualizáciu svojich agend. systémov alebo na spustenie nejakej proaktívnej služby.
Neboli tieto výstupy aktivity A7 už predmetom a výstupom projektu Efektívny manažment údajov v prostredí Sociálnej poisťovne (MUSP, Kód MetaIS=projekt_318)? A v tomto projekte Lepšie údaje by sa mali výstupy z projektu MUSP len rozšíriť? Čo bude teda tým rozšírením realizovaným v projekte Lepšie údaje? Aby nedošlo k tomu, že vznikne nielen podozrenie z duplicitného financovania toho istého výstupu.
Neboli. IS MUSP, bol zameraný na vytvorenie prevažne technologickej vrstvy a z časti aplikačnej. Z pohľadu riadenia procesov to nebolo predmetom projektu
Nemá zmysel dávať do projektového prístupu popis rozhraní systému. Zbytočne to rozširuje a zneprehľadňuje obsah. Na popis rozhraní slúži integ. manuál. Tu stačilo uviesť, aké dátové objekty bude treba zo SP poskytnúť cez existujúce rozhrania CPDia MOU.
Vyriešené: Nedôležitá úprava. Bolo by lepšie v názve podkapitoly podobne ako pre predchádzajúce aktivity a podkapitoly uviesť, že v texte ide o Aktivitu A11.
Táto veta protirečí predchádzajúcej. Pravdepodobne by mala väčšina systémov VS zaznamenávať do nejakého druhu logu údaje o prístupe k údajom z dôvodu auditu a bezpečnosti, ale tieto údaje z logov prístupov sa v lepšom prípade poskytujú len do nejakého systému bezpečnostného dohľadu v organizácii. Spôsob zberu týchto dát a ich štruktúra nie je pripravená na poskytovanie tejto informácie pre dotknutú osobu napr. cez špecializovaný portál a vôbec nie pre MOU v štruktúre potrebnej pre MOU.
Podstatou predmetnej vety bola presne informácia, že IS VS nie sú pripravené na poskytovanie osobných údajov, ale ani logov k nim dotknutej osobe, preto orgány verejnej moci riešia žiadosti o prístup k údajom v zmysle GDPR spôsobom, že uvedú dotknutej osobe iba metadáta k údajom, ktoré o nej vedú a nie hodnoty týchto údajov. Dotknutá veta bola preformulovaná.
nasledovne:
“V prostredí VS správy je častým javom, že ISVS nie sú prispôsobené na poskytovanie osobných údajov dotknutým osobám(napr. kvôli bezpečnosti), preto sa poskytujú iba sprievodné metaúdaje a nie hodnoty, ani logy súvisiace s týmito údajmi.”.
Nenašiel som zoznam otvorených údajov, ktoré budú publikované. Keď sú uvedené nižšie detaily dát pre MOU na úrovni atribútu, čo je pre účely dokumentu prístupu projektu zbytočný detail, tak by malo byť možné uviesť nejaký základný zoznam otvorených údajov, ktoré budú projektom zabezpečené.
V rámci projektu bude budovaný Lokálny katalóg otvorených údajov. V súčasnosti sme nevedeli vydefinovať presný zoznam, preto nie sú uvedené žiadne datasety. SP si bude riešiť publikovanie otvorených údajov dodatočne internými kapacitami.
Chýba obrázok architektúry To-Be.Je síce v prílohe ako PDF, ale ako príloha by mal byť nahratý model architektúry a nie jej obrázok, ak model nie je súčasťou repozitára architektúry VS. Soc. Poisťovňa má prístupy a repozitár v spoločnom modelovacom nástroji Horizzon/Bizzdesign, ale ani tam som model architektúry pre tento projekt nenašiel.
Otvorené údaje nie sú povinná aktivita výzvy. V súlade s odporučení nie je vylúčené, že počas realizačnej fázy projektu dôjde k publikovaniu publikačného minima pre štátnu správu zo strany SP.
Odporúčame zvážiť aj riešenie priameho generovanie datasetov vo formáte RDF/XML alebo JSON-LD priamo z informačného systému bez vytvárania transformačného modulu.
Bola upravená formulácia v textácií. Scenár pre konkrétny dataset bude predmetom Analýzy a dizajnu vzhľadom na prácnosť a realizovateľnosť agendového systému. Cieľom SP je mať čo najviac funkcionalít pod vlastnou správou
Katalóg požiadaviek: Požiadavky ID_8, 9, 112, 113 sú dúplicitné - vytvorenie a implementácia fyzického dátového modelu sú chápané 2 veci? Je potrebné bližšie špecifikovať - napr. úprava štruktúr v databáze a pod. - nie je však jasné prečo sú 4 požiadavky
Prosím doplniť spôsob vysporiadania s vendr lockom, a to napr.:
Konkrétne v zmysle § 15 ods. 2 písm. d) zákona č. 95/2019 Z. z. informačných technológiách vo verejnej správe:
Vo fáze prípravy a obstarania projektu je správca povinný akceptovať také zmluvné podmienky, podľa ktorých:
3. pri zmene dodávateľa pôvodný dodávateľ poskytne správcovi úplnú súčinnosť pri prechode na nového dodávateľa, najmä v oblasti architektúry a integrácie informačných systémov.
Doplnené v kapitole „zdrojové kódy“
OK
V projekte nejde len o posilnenie IS MOU. Ide aj o zvýšenie kvality dát, aj o distribúciu a spracovanie zmien dát, štandardizáciu dátového modelu, a poskytovanie otvorených dát. Treba upresniť, o aké notifikácie sa jedná. Nemá ísť o notifikácie v zmysle komunikácie s klientom pri riešení konania ale v kontexte MOU ide o notifikácie o prístupe k dátam a o zmene dát dotknutej osoby.
Áno v projekte nejde len o notifikácie, a budú realizované aj iné oblasti v projekte, ti sú rozpísané v kapitolách nižšie. V kapitole „Realizovanie aktivít v projekte v zmysle výzvy sú popísané aj typy notifikácii
Vyriešené: Áno. Je to popísané nižšie.
Nemal by medzi týmito dotknutými systémami aj systém isvs_8729 Manažment údajov SP?
Obrázok popisuje aktuálny stav. Systémy dotknuté touto výzvou ( CIPS, IS JVP, DP, NPaLPČ) momentálne nie sú integrované na IS MUSP.
Vyriešené: Vysvetlené komentárom
Z pohľadu tohto popisu MUSP mi nedáva zmysel dátová komunikácia v Obrázku 2 (prehľad IS dotknutých v projekte). Prečo nie je v znázornenej dátovej komunikácii nijako zapojený MUSP, keď podľa tohto popisu v proj. prístupe a popisu ISVS v METAIS by mal MUSP byť určený na výmenu údajov a centr. úložisko údajov? (Podľa METAIS je MUSP: "Informačný systém na správu údajov v prostredí SP. Riešenie MÚSP vychádza z konceptu správy kmeňových údajov, čo je súbor osvedčenejších skúseností zahŕňajúcich procesy, politiky, a nástroje, zabezpečujúce kmeňové údaje v celom informačnom prostredí SP. IS MUSP zjednotí dáta o klientovi, nakoľko v súčasných systémoch má každý systém svoje údaje, IS MUSP uvedené údaje zjednotí, aby boli komplexné údaje o klientoch SP"
OK. SP má priamu integráciu na RFO. Upravený obrázok.
Vyriešené: Obrázok doplnený
Nemá SP priamu integráciu na RFO a teda nepoužíva CDPI/CSRÚ na získanie ref. údajov o FO? Nemá SP aj priamu integráciu na RPO? A teda neplatí to, čo je tu uvedené?
SP má priamu integráciu na RFO. Upravený obrázok.
Vyriešené
V projekte na lepšie údaje by nemali byť dohady o tom, čo pravdepodobne systém obsahuje. Predpokladám, že sa tu mal na mysli referenčný register dań. subjektov isvs_6113, ktorý je podmodulom Integrovaného informačného systému FS (isvs_4859), ktorý je integrovaný na CPDI. Alebo niečo iné?
Upravená textácia.
Nejasné: Bolo to vyriešené zmazaním pripomienkovaného textu a využitia tohto registra? SP nepotrebuje údaje z registra daň. subjektov?
Plus zákl. číselníkoch.
Zapracované
Vyriešené
Znova: Prečo tu nie je IS MÚSP (isvs_8729)?
Doplnený IS MUSP
Nevyriešené: Nevidím v zozname doplnený IS MÚSP (isvs_8729)
V súlade s ďalším popisom a obrázkom 3 (resp. prílohou Aplikačné služby na integráciu TOBE.pdf) by malo byť hneď uvedené, že bude rozvíjaný Isvs_8729 (Manažment údajov SP) ako platforma manažmentu údajov Soc. poisťovne. V tomto prípae prívlastku nie je celkom na mieste, lebo to nie je a podľa popisu ani nemá ambíciu byť integ. platformou za rezort zahrňujúci všetky subjekty podieľajúce sa na soc. zabezpečení.
Súčasťou nie je riešiť komplexný pohľad SP, ale rozsah projektu je prispôsobený dopytovej výzve a teda rozsah v projekte bude napojenie ISVS (CIPS, IS JVP, IS NPaLPČ a DP) a teda tie systémy, ktoré poskytujú údaje pre IS MOU.
Vyriešené vysvetlením a úpravou textu.
V obrázku ToBe architektúry nie sú tmavomodré plné línie.
Pravdepodobne kvôli betaverzii MetaIS nebol vyexportovaný obrázok č. 3. Na obrázku sú uvedené tmavomodré línie.
Vyriešené
Treba starostlivo oddeliť na aký notifikačný účel bude slúžiť mobilná aplikácia SP a na aký účel mobilná aplikácia MOU (zamerané na notifikácie o prístupe iných osôb k údajom a zmene registrových údajov a vyžiadanie súhlasov na prístup 3. strán k dátam)
Áno evidujeme túto skutočnosť. Detailná analýza jednotlivých typov notifikácii bude predmetom realizačnej fázy počas Analýzy a dizajnu.
Vyriešené vysvetlením
Isvs_8729, Manažment údajov SP, nebol doteraz integrovaný na CPDI?
Nie nebol. V čase realizácie projekt dátová integrácia bol IS MUSP, len vo vývoji.
Vyriešené vysvetlením
Nemala by integrácia isvs_8729 (MUSP) nahradiť čiastkové integrácie isvs_551 (SES) a isvs_8140 (CIPS) , ktoré by komunikáciu s CPDI realizovali cez MUSP?
Áno bude to IS MUSP. Tak ako je uvedené v tabuľke „Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE“ a súčasne aj v arch. v obrázku č. 3
Vyriešené vysvetlením
Ako pripomienkujem vyššie skôr ide o Platformu manažmentu a integrácie údajov, bez prívlastku "rezortná". A keďže už veme že touto platformou má byť MUS, tak rovno treba písať, že s jeho využitím budú budované uvedené aplik. služby.
Áno. Upravená formulácia
Vyriešené
Zmenové dávky a notifikácie o zmenách dát by nemali byť len pre MOU. Aj iní konzumenti údajov by mohli využiť distribúciu zmien údajov SP cez CPDI, či už na aktualizáciu svojich agend. systémov alebo na spustenie nejakej proaktívnej služby.
Áno tieto notifikácie môžu využívať aj iné ISVS, avšak výzva je zameraná na rozvoj a podporu IS MOU.
Vyriešené vysvetlením
Nemyslí sa tu skôr poskytnutie zmien údajov?
Nie
Vyriešené vysvetlením.
SES (isvs_551 ) v tabuľke chýba. Bude teda zdrojom/konzumentom nejakých dát do CPDI cez MUSP?
V to be stave sa so systémom SES nepočíta. Jeho funkcionalita bude zabezpečená prostredníctvom IS MUSP
Vyriešené vysvtelením
Chýba sloveso v hlavnej vete. Nie je jasný význam tejto vety.
Upravená štylistika.
Vyriešené
Naozaj to bude rezortná dát. kancelária, alebo len dát. kancelária Soc. Poisťovne?
Upravená formulácia
Nevyriešené: Stále ostalo využívanie pojmu "rezortná dátová kancelária" aj v ďalšom texte.
Ktorým organizáciám v rezorte okrem pobočiek SP by mala dát. kancelária SP pomáhať?
Upravená formulácia „Dátová kancelária v rámci SP bude pomáhať kategorizovať a sprístupňovať...“
Nevyriešené: stále ostalo využívanie pojmu "rezortná dátová kancelária"
Neboli tieto výstupy aktivity A7 už predmetom a výstupom projektu Efektívny manažment údajov v prostredí Sociálnej poisťovne (MUSP, Kód MetaIS=projekt_318)? A v tomto projekte Lepšie údaje by sa mali výstupy z projektu MUSP len rozšíriť? Čo bude teda tým rozšírením realizovaným v projekte Lepšie údaje? Aby nedošlo k tomu, že vznikne nielen podozrenie z duplicitného financovania toho istého výstupu.
Neboli. IS MUSP, bol zameraný na vytvorenie prevažne technologickej vrstvy a z časti aplikačnej. Z pohľadu riadenia procesov to nebolo predmetom projektu
Vyriešené vysvetlením
Nemá zmysel dávať do projektového prístupu popis rozhraní systému. Zbytočne to rozširuje a zneprehľadňuje obsah. Na popis rozhraní slúži integ. manuál. Tu stačilo uviesť, aké dátové objekty bude treba zo SP poskytnúť cez existujúce rozhrania CPDia MOU.
Nesúhlasíme s tým, že to z nesprehľadňuje, ale naopak spresňuje rozsah projektu.
Vyriešené
Nemá tento výstup "komplex. dát.-právn. manažmentu" byť v aktivite A7. Zavedenie systematického manažmentu údajov? Prečo je tu v aktivite A5?
Nie. Je to samostatná podporovaná aktivita výzvy, aktivita č. 11 „Legislatívna analýza údajov inštitúcie verejnej správy“
Vyriešené: Nedôležitá úprava. Bolo by lepšie v názve podkapitoly podobne ako pre predchádzajúce aktivity a podkapitoly uviesť, že v texte ide o Aktivitu A11.
Táto veta protirečí predchádzajúcej. Pravdepodobne by mala väčšina systémov VS zaznamenávať do nejakého druhu logu údaje o prístupe k údajom z dôvodu auditu a bezpečnosti, ale tieto údaje z logov prístupov sa v lepšom prípade poskytujú len do nejakého systému bezpečnostného dohľadu v organizácii. Spôsob zberu týchto dát a ich štruktúra nie je pripravená na poskytovanie tejto informácie pre dotknutú osobu napr. cez špecializovaný portál a vôbec nie pre MOU v štruktúre potrebnej pre MOU.
Podstatou predmetnej vety bola presne informácia, že IS VS nie sú pripravené na poskytovanie osobných údajov, ale ani logov k nim dotknutej osobe, preto orgány verejnej moci riešia žiadosti o prístup k údajom v zmysle GDPR spôsobom, že uvedú dotknutej osobe iba metadáta k údajom, ktoré o nej vedú a nie hodnoty týchto údajov. Dotknutá veta bola preformulovaná.
nasledovne:
“V prostredí VS správy je častým javom, že ISVS nie sú prispôsobené na poskytovanie osobných údajov dotknutým osobám(napr. kvôli bezpečnosti), preto sa poskytujú iba sprievodné metaúdaje a nie hodnoty, ani logy súvisiace s týmito údajmi.”.
Vyriešené
Nenašiel som zoznam otvorených údajov, ktoré budú publikované. Keď sú uvedené nižšie detaily dát pre MOU na úrovni atribútu, čo je pre účely dokumentu prístupu projektu zbytočný detail, tak by malo byť možné uviesť nejaký základný zoznam otvorených údajov, ktoré budú projektom zabezpečené.
V rámci projektu bude budovaný Lokálny katalóg otvorených údajov. V súčasnosti sme nevedeli vydefinovať presný zoznam, preto nie sú uvedené žiadne datasety. SP si bude riešiť publikovanie otvorených údajov dodatočne internými kapacitami.
Vyriešené vysvetlením.
Chýba obrázok architektúry To-Be.Je síce v prílohe ako PDF, ale ako príloha by mal byť nahratý model architektúry a nie jej obrázok, ak model nie je súčasťou repozitára architektúry VS. Soc. Poisťovňa má prístupy a repozitár v spoločnom modelovacom nástroji Horizzon/Bizzdesign, ale ani tam som model architektúry pre tento projekt nenašiel.
Doplnený obrázok. Chyba pri importe dokumentácie do Xwiki. Achr. Komponenty boli dodané a sú nahraté v MetaIS
Vyriešené
So žiadneho z týchto objektov evidencie nebudú poskytované otvorené údaje? Prečo?
Predmetom výzvy je podpora konceptu mojich údajov. Otvorené údaje sú nepovinná aktivita. Predmetné OE majú charakter mojich údajov.
Vyriešené vysvetlením
Je potrebné definovať ktorý spôsob vytvárania lokálneho katalógu si zvolíte či cez SPARQL Endpoint alebo cez DCAT_dokument. Scenáre sprístupňovania otvorených údajov - Metodika pre otvorené údaje (opendata.gov.sk) - Confluence
Spôsob je uvedený v texte budovaný LKOD bude cez „Sparql endpoint“
OK.
Nie sú spomínané notifikácie občanovi, ktoré údaje boli komu zdieľané.
Funkčnosť, ktoré OVM aké údaje zdieľalo inému OVM je predmetom IS CPDI.
Vyriešené
Je potrebné doplniť rozsah publikovaných datasetov. odporúčame publikovať datasety publikačného minima pre štátnu správu. Ich zoznam nájdete tu: Publikačné minimum štátnej správy - Metodika pre otvorené údaje (opendata.gov.sk) - Confluence
Otvorené údaje nie sú povinná aktivita výzvy. V súlade s odporučení nie je vylúčené, že počas realizačnej fázy projektu dôjde k publikovaniu publikačného minima pre štátnu správu zo strany SP.
OK
Odporúčame zvážiť aj riešenie priameho generovanie datasetov vo formáte RDF/XML alebo JSON-LD priamo z informačného systému bez vytvárania transformačného modulu.
Bola upravená formulácia v textácií. Scenár pre konkrétny dataset bude predmetom Analýzy a dizajnu vzhľadom na prácnosť a realizovateľnosť agendového systému. Cieľom SP je mať čo najviac funkcionalít pod vlastnou správou
OK.
Katalóg požiadaviek: Požiadavky ID_8, 9, 112, 113 sú dúplicitné - vytvorenie a implementácia fyzického dátového modelu sú chápané 2 veci? Je potrebné bližšie špecifikovať - napr. úprava štruktúr v databáze a pod. - nie je však jasné prečo sú 4 požiadavky