Nazwa projektu dokumentu: Elektroniczna Platforma Gromadzenia, Analizy I Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (P1) – faza 2



Pobieranie 155,2 Kb.
Data25.06.2018
Rozmiar155,2 Kb.




Nazwa projektu dokumentu: Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych" (P1) – faza 2

L.p.

Organ wnoszący uwagi

Jednostka redakcyjna, do której wnoszone są uwagi

Treść uwagi

Propozycja zmian zapisu

Stanowisko wnioskodawcy

Propozycja realizacji uwagi

1.

RA

(Błażej Adamczyk)

5.2

Dlaczego poziom usług dla obywatela to tylko 4?

Rozważyć dostarczenie usług poziomu 5-go lub wyjaśnić dlaczego to nie zostanie zrobione.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Występują co prawda usługi 5-go poziomu, ale z uwagi na stosunkowo wąski zakres wykorzystania oraz ogólność opisu nie były wykazane. Np. w przypadku gdy Usługodawca korzysta z aplikacji AUA wówczas część danych jest automatycznie uzupełniana w dokumencie recepty lub skierowania, natomiast z uwagi na charakter tych usług oraz fakt, że Usługodawcy będą w znaczącej większości korzystać z własnych systemów wskazano, że dostarczane usługi są na 4-poziomie.


2.

RA

(Błażej Adamczyk)

12.3

Jak szacunki przedstawione w rozdziale 12.3 mają się do szacunków/statystyk fazy I? Dalej w rozdziale 12.4 jest wskazanie, że zostanie wykorzystana infrastruktura z fazy I projektu. Czy ta infrastruktura jest wystarczająca? Czy zostało to dokładnie przeliczone?

Wyjaśnić jak planowane jest zapewnienie wydajności systemu w kontekście wzrostu szacunkowego obciążenia i rozmiaru/złożoności systemu.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

W trakcie I fazy przeprowadzono analizę i przygotowano architekturę w trzech domenach, na bazie której dokonano zakupu infrastruktury i licencji. Od tego czasu wymagania w zakresie wolumetrii dla wskazanych obiektów biznesowych nie uległy znaczącym zmianom, które wymagałyby modyfikacji wymagań wydajnościowych.

Jednakże uwzględniono potrzebę zmian w infrastrukturze i w związku ze:



  • zgłaszanym jeszcze w I Fazie zapotrzebowaniem na rozszerzenie ITS,

  • dostosowaniem zapotrzebowania na ITS wynikającego z realnych potrzeb (sukcesywny wzrost użytkowników oraz wymaganych zasobów do przetwarzania danych),

  • realizację uwag/rekomendacji audytorów,

  • koniecznością zmiany technologii, z których wycofują się producenci.

Dodatkowo należy zaznaczyć, że system będzie budowany w oparciu o poniższe wymagania, których egzekwowalność będzie zapewniona na poziomie architektury, projektu ITS lub testów:

  1. System musi zapewnić możliwość zbliżonego do liniowego skalowania poziomego, względem:

  • maksymalnego wolumenu obsługiwanych operacji w jednostce czasu,

  • ilości przetwarzanych i zgromadzonych danych,

  • liczby jednocześnie pracujących użytkowników.

  1. System musi zapewniać możliwość skalowalności poprzez dodawanie kolejnych węzłów w poszczególnych warstwach (scale out) wymagającą jedynie instalacji oprogramowania i zmiany parametrów konfiguracyjnych, bez konieczności zmian kodu oprogramowania.

  2. Architektura rozwiązania musi umożliwiać skalowanie rozwiązania poprzez tworzenie logicznych klastrów serwerów na poziomie:

  • serwerów WWW,

  • serwerów aplikacyjnych,

  • serwerów baz danych.

  1. Zasoby sprzętowe dostarczone w ramach systemu muszą umożliwiać rozbudowę poprzez dodawanie kolejnych elementów, np. dodatkowej pamięci, dodatkowych dysków, procesorów itp.

  2. Operacje rozszerzania systemu o kolejne serwery lub inne elementy nie mogą wymagać zatrzymania systemu lub spadku jego wydajności zauważalnego przez aktorów systemu.

  3. Architektura rozwiązania musi umożliwiać wykorzystanie mechanizmu równoważenia obciążenia (load balancing) przy zastosowaniu więcej niż 1 serwera.

  4. Mechanizmy bezpieczeństwa muszą zapewniać możliwość rozwoju i skalowania w przyszłości, wraz z rozwojem usług realizowanych przez System P1.

3.

RA

(Błażej Adamczyk)

13.1

W punkcie „Bezpieczeństwo danych” przedstawione są tylko metody zabezpieczenia danych przed nieautoryzowanym dostępem. Poza wzmianką RAID (i w dalszej części rozdziału dokumentach BCP i DRP) brakuje tam informacji o bezpieczeństwie danych w przypadku awarii, a także na temat mechanizmów dostarczenia wysokiej dostępności.

Należy uzupełnić dokument o bardziej szczegółowe informacje na temat zapewnienia wysokiej dostępności i bezpieczeństwa danych w przypadku awarii. Być może wykorzystane zostaną mechanizmy z fazy I – w takim przypadku należy to wskazać.

Dokument został uzupełniony

Dodano następującą treść do rozdziału

13.1:


  • W sekcji Bezpieczeństwo danych:

„Bezpieczeństwo danych w przypadku awarii zapewnione zostanie poprzez zastosowanie macierzy dyskowych z wbudowanymi mechanizmami zabezpieczania danych (typu RAID), poprzez synchronizację danych pomiędzy dwoma oddalonymi geograficznie ośrodkami pracującymi w trybie active-passive oraz poprzez wykonywanie kopii bezpieczeństwa danych wraz z  odmiejscowieniem ich przechowywania. Kopie zapasowe danych wykonywane będą w procedurach przewidzianych dla systemów o poziomie dostępności powyżej 99,9% w skali roku, z możliwie najkrótszymi czasami odtwarzania i przywracania danych.”

  • W sekcji Bezpieczeństwo aplikacji:

„Mechanizmy dostarczania wysokiej dostępności oparte zostaną o rozwiązania dostarczone w ramach fazy I oraz o nowe mechanizmy bazujące na otwartym oprogramowaniu.

Planuje się zastosowanie: dwóch ośrodków przetwarzania, w ramach ośrodka wykorzystywane będą klastry maszyn wirtualnych HA, redundacja poszczególnych istotnych elementów infrastruktury i wezłów przetwarzania, stałe monitorowanie zasobów i prowadzenie działań proaktywnych.”



4.

RA

(Błażej Adamczyk)

13.1

Czy wskazane w dokumencie konkretne oprogramowanie komercyjne (ESET, QRadar, DB2, HP SiteScope itd.) wynika z wykorzystania oprogramowania zakupionego w ramach etapu I?

Prośba o wyjaśnienie.

Dokument został uzupełniony

Wymienione z nazwy oprogramowanie zostało już pozyskane do realizacji projektu w I fazie. W dokumencie po pierwszym wystąpieniu nazw dodano treść: „(będącego w posiadaniu CSIOZ)”.

5.

RA

(Błażej Adamczyk)

13.1

Czym jest "System proaktywnego monitorowania pracy administratorów"? Czy jest jakaś klasa produktów znana na rynku? Czy będzie to zakupiony gotowy produkt czy też będzie to oprogramowanie wytworzone w ramch projektu?

Prośba o wyjaśnienie.

Dokument został uzupełniony

Poprzednia treść:

„System proaktywnego monitorowania pracy administratorów – podejmujący działania

w czasie rzeczywistym o wykrytych nadużyciach.”

zastąpiono następującą:

„System monitorowania pracy administratorów – CyberArk (będącego w posiadaniu CSIOZ).”


6.

RA

(Błażej Adamczyk)

13.1

Czy rozważono zastostosowanie rozwiązań analizy behawioralnej sieci lub użytkowników (NBA, UEBA)?

Prośba o wyjaśnienie.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Nie, nie rozważano wprowadzenia tego typu zabezpieczeń, ograniczono się jedynie do wykorzystania IPS oraz firewall. Dopuszczamy możliwość zastosowania rozwiązań opartych o analizy behawioralne jeżeli w trakcie prac projektowych i ocenę ryzyka zidentyfikowana zostanie potrzeba ich zastosowania.

7.

RA

(Błażej Adamczyk)

13.1

Czy przewidziana jest separacja danych wyjątkowo istotnych (osobowe, wrażliwe, personalizacyjne, audytowe itd.) od pozostałych danych? Jeśli tak to w jakiej konfiguracji (macierzy, serwerów, baz danych, instancji)?

Prośba o wyjaśnienie.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Zgodnie ze wskazanymi w sekcji bezpieczeństwo zabezpieczeniami przewidziana jest depersonalizacja (pseudonimizacja) danych, czyli oddzielenie danych identyfikujących od pozostałych danych, każdy z zestawów będzie przechowywany osobno, również fizycznie.



RA

(Błażej Adamczyk)

13.1

W punkcie dotyczącym testów bezpieczeństwa jest założona możliwość zlecenia wykonania testów bezpieczeństwa przez podmiot zewnętrzny. Wydaje się, że zewnętrzne testy bezpieczeństwa powinny być obligatoryjne jako uzupełnienie testów wykonanych przez wytwórcę.

Prośba o uwzględnienie obligatoryjności lub wyjaśnienie.

Dokument został uzupełniony

Testy bezpieczeństwa będą obligatoryjne. Treść została zmodyfikowana.

Poprzednia treść:

„Zakłada się również możliwość zlecenia wykonania dodatkowych testów bezpieczeństwa przez zewnętrzny względem wykonawcy Systemu P1 podmiot.”

zastąpiono następującą:

„Uzupełnieniem wyżej wskazanych testów bezpieczeństwa będą testy realizowane przez inny podmiot zewnętrzny.”




Roman Janczarek

12.1 Planowana architektura rozwiązania

W architekturze należy zaplanować budowę odpowiednio trzech rejestrów:

  • Rejestr Danych Medycznych – Recepty (SGR)

  • Rejestr Danych Medycznych – Skierowania (SGS)

  • Rejestr Danych Medycznych – Zdarzenia medyczne (SGZ) oraz zadeklarować jakie usługi udostępniania danych zostaną dostarczone w ramach budowanych systemów do zarządzania ich danymi.

Usługi udostępniania danych powinny być wykorzystywane zarówno przez komponenty wewnętrzne ale również pełnić rolę API dla systemów zewnętrznych.





Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

W architekturze przewidziano budowę trzech podsystemów odpowiedzialnych za gromadzenie i udostępnianie danych związanych z receptami, skierowaniami i zdarzeniami medycznymi (SGR, SGS, SGZ).

Dedykowane usługi dla systemów zewnętrznych i komponentów wewnętrznych w wymienionych podsystemach zostały zaplanowane, czego potwierdzeniem jest poniższa lista (w układzie identyfikator usługi – nazwa usługi):



  • ASI.TA.AS.SGR.001 - Obsługa zapisania recepty elektronicznej

  • ASI.TA.AS.SGR.002 - Generowanie danych identyfikacyjnych elektronicznej recepty

  • ASI.TA.AS.SGR.003 - Udostępnianie elektronicznej recepty

  • ASI.TA.AS.SGR.005 - Obsługa realizacji recept

  • ASI.TA.AS.SGR.006 - Zapisanie dokumentu realizacji recepty

  • ASI.TA.AS.SGR.007 - Udostępnianie recept elektronicznych na potrzeby analiz i statystyki

  • ASI.TA.AS.SGR.008 - Udostępnianie realizacji recept na potrzeby analiz i statystyki

  • ASI.TA.AS.SUS.002 - Zapis elektronicznej recepty w P1

  • ASI.TA.AS.SUS.003 - Udostępnienie elektronicznej recepty

  • ASI.TA.AS.SUS.004 - Udostępnienie elektronicznej recepty do realizacji

  • ASI.TA.AS.SUS.006 - Realizacja recept

  • ASI.TA.AS.SUS.093 - Weryfikacja poprawności recepty elektronicznej

  • ASI.TA.AS.SGS.001 - Obsługa realizacji skierowań

  • ASI.TA.AS.SGS.002 - Udostępnianie skierowań na potrzeby analiz i statystyki

  • ASI.TA.AS.SGS.003 - Udostępnianie skierowań

  • ASI.TA.AS.SGS.004 - Obsługa zapisania skierowania

  • ASI.TA.AS.SUS.040 - Realizacja skierowań

  • ASI.TA.AS.SUS.042 - Weryfikacja skierowań

  • ASI.TA.AS.SUS.053 - Udostępnienie elektronicznego skierowania

  • ASI.TA.AS.SUS.068 - Zapis elektronicznego skierowania w P1

  • ASI.TA.AS.SGZ.012 - Zapisanie informacji o zdarzeniu medycznym

  • ASI.TA.AS.SGZ.007 - Obsługa anulowania informacji o zdarzeniu medycznym

  • ASI.TA.AS.SGZ.006 - Obsługa anulowania indeksu dokumentacji medycznej

  • ASI.TA.AS.SGZ.003 - Udostępnianie informacji o zdarzeniach medycznych

  • ASI.TA.AS.SGZ.001 - Udostępnianie indeksów EDM

  • ASI.TA.AS.SGZ.004 - Udostępnianie zestawień zdarzeń medycznych

  • ASI.TA.AS.SUS.075 - Zapisanie informacji o zdarzeniu medycznym

  • ASI.TA.AS.SUS.007 - Anulowanie informacji o stworzonej dokumentacji medycznej

  • ASI.TA.AS.SUS.009 - Anulowanie zdarzenia medycznego

  • ASI.TA.AS.SUS.049 - Udostępnianie informacji o zdarzeniach medycznych

  • ASI.TA.AS.SUS.047 - Udostępnianie informacji o indeksach EDM

  • ASI.TA.AS.SUS.055 - Udostępnianie informacji o zdarzeniach medycznych

  • ASI.TA.AS.SUS.054 - Udostępnianie indeksów EDM



Roman Janczarek

12.1 Planowana architektura rozwiązania

W opisie architektury brakuje odniesienia się do usług identyfikacji elektronicznej.




Dokument został uzupełniony

W rozdziale 12.1 dodano następującą treść:

„W Projekcie P1 przewidziano uwzględnienie następujących metod identyfikacji elektronicznej Profilu Zaufanego i podpisu kwalifikowanego. W związku z metodą realizacji projektu przewidujemy również możliwość rozszerzenia o kolejne metody w momencie ich pojawiania się np. Karty Specjalisty Medycznego lub pieczęci elektronicznej.”





ZA MC

Ogólna

Brak jasnego wskazania zmian wprowadzanych w fazie II. Prośba o informację, gdzie w dokumencie opisany jest zakres, który zostanie dostarczony w ramach fazy II.




Dokument został uzupełniony

Rozdział 3.2 został uzupełniony o zakres projektu (II fazy), odniesienie do zmian względem I oraz informacji o re-użyciu lub budowie od nowa podsystemów.



ZA MC

1.6

Czy wymienione pojęcia słownikowe faktycznie dotyczą dziedziny projektu? (KPI, RWD)

W moim przekonaniu nie.



Usunąć te pojęcia ze słownika i wstawić nowe (np.: EDM, …).

Dokument został uzupełniony

Wskazane w uwadze terminy (KPI i RWD) pozostawiamy z uwagi na występowanie skrótów zastosowanych w tabelach szablonu wymaganych przez MC.

Sekcja 1.6 została rozszerzona przez dodanie terminów i skrótów wykorzystanych w dokumencie.





ZA MC

3.1

Autor powołuje się na „dyrektywy transgranicznej” nie określając jej nazwy.

Należy podać pełną nazwę dyrektywy i w szczególności wskazać te jej części do których odwołują się Autorzy projektu.

Dokument został uzupełniony

Dodano odniesienie do dyrektywy we wskazanym rozdziale (3.1) przez dodanie następującego odniesienia: „w ramach projektu epSOS, 2011/24/UE”.



ZA MC

5.2

Zaproponowane nazwy eUsług są błędne (np.:

  • Udostępnienie usługobiorcom (pacjentom) elektronicznej historii wykonanych: rozpoznań, usług, skierowań, recept

  • Udostępnienie informacji umożliwiającej bieżące monitorowanie i reagowanie na zagrożenia właściwym instytucjom.

  • Umożliwienie bieżącej analizy danych o zdarzeniach medycznych

Należy uspójnić reguły tworzenia nazw usług, ponieważ obecnie ich brak (np.: e-recepta, umożliwienie …, udostępnienie).

Dokument został uzupełniony

Nazwy zostały uspójnione. Obecnie nazwy usług tworzone wg schematu udostępnienie … lub umożliwienie …



ZA MC

5.2 i 7

Określono listę usług i ich miary, jednak nie przedstawiono oszacowania wymaganych zmian ITS.

Uzupełnić dokument o wymagane zmiany sprzętowe (w ITS).

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

W związku z faktem, że podczas I fazy zakupiono ITS, zakłada się jego wykorzystanie z uwzględnieniem wprowadzenia niezbędnych zmian. Oszacowanie tej wartości zostało ujęte w tabeli 7.2 pozycja koszty trwałe (sprzęt) i w pozycji koszty wartości niematerialne i prawne (licencje).

Wymagane zmiany zostały wskazane

Liczba serwerów została oszacowana na podstawie projektu ITS wytworzonego podczas fazy I projektu.

Na kwotę składa się m.in. uzupełnienie o zakup serwerów, narzędzia klasy SIEM, osprzętu sieciowego, infrastruktury backup.





ZA MC

5.3

Uproszczone procedury określone w dokumencie powielają zapisy określone dla I etapu projektu P1 (np: "zarządzanie kolejkami", "usuwanie pustych lub podwójnych zapisów")


Jawnie określić zakres zmian względem fazy 1 (I etapu)

Dokument został uzupełniony

Wskazana treść (rozdział 5.3, korzyści dla planowania i realizacji świadczeń) została zmodyfikowana w następujący sposób:

„Obniżenie kosztów. Gromadzenie informacji o udzielanych świadczeniach pozwoli na wiarygodne planowanie i dopasowanie świadczeń do potrzeb.

Udostępnienie katalogu usługodawców dla pacjentów wraz z możliwością zapisu na świadczenia. Obsługa e-skierowań, w tym brak możliwości wystawienia wielu skierowań na to samo świadczenie wpłynie także na brak możliwości zapisywania się pacjentów do dwóch kolejek przez co przyczyni się do ich skrócenia.”

Dodatkowo w rozdziale 3.2 dodano różnice pomiędzy fazami w zakresie funkcjonalnym.





ZA MC

12.1

Przedstawiony w model architektury nie zakłada re-użycia wcześniej odebranych produktów, np: P2 ("Platforma udostępniania on-line przedsiębiorcom usług i zasobów cyfrowych rejestrów medycznych").

Bezpośrednio w modelu architektury należy określić, które komponenty modelu architektury są "nowotworzone", a które re-użyte lub/i rozbudowywane.

Dokument został uzupełniony

Zakres zmian został uwzględniony w rozdziale 3.2, ponadto w rozdziale 12.1 w widoku architektury określono nowotworzone i rozbudowywane produkty.



ZA MC

12.1

Z dokumentu nie wynika jednoznacznie, które podsystemy zostały zrealizowane (i w jakiej części). Wyjątek w tym zakresie stanowi zapis: Obszar funkcjonalny hurtowni danych składa się z 3 Podsystemów działających w oparciu o zestaw narzędzi dostarczanych przez firmę SAS (i znajdujących się obecnie w posiadaniu Zamawiającego.

Należy jawnie określić, które moduły (podsystemy) są w posiadaniu Zamawiającego.

Dokument został uzupełniony

W rozdziale 3.2 (zakres projektu) oraz w 12.1 (widoku architektury dodano informację)



ZA MC

12.4

W rozdziale komplementarność projektu założono: "System P2 – System Administracji – w zakresie usług uwierzytelnienia oraz weryfikacji podpisu elektronicznego;" - jednak w modelu architektury nie wskazano tego podsystemu, a w jego miejsce określono nowy komponent SAZ (który powiela jego funkcjonalność).

Rozszerzyć model architektury systemu P1 o istotne podsystemy go tworzące, w tym o te, które bezpośrednio zostały wskazane w rozdziale 12.4: "System Obsługi Zgłoszeń"; "System Wsparcia Zarządzania Projektem"; "Platforma Rejestrów Medycznych", a brak ich w modelu architektury.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

System Obsługi Zgłoszeń – nie jest elementem Systemu P1, ale jest narzędziem wspierającym utrzymanie Systemu, stąd brak ujęcia w Architekturze Systemu P1.

System Wsparcia Zarządzania Projektem – to repozytorium dokumentacji projektowej oparte o SharePoint. Stanowiło także rejestr zmian, zagadnień czy komunikacji wymaganych w metodyce Prince2. Nie jest zatem elementem Architektury Systemu P1.

Platforma Rejestrów Medycznych – jest komponentem systemu P2, odpowiadającym za gromadzenie i udostępnianie rejestrów wymaganych do zasilenia Systemu P1 m.in. RPWDL, Wykazu Produktów Leczniczych, Rejestru Aptek. Zostały one ujęte w widoku prezentującym ogólną architekturę.




ZA MC

protokół z publicznej prezentacji

Co oznacza termin: "robocza certyfikacja poszczególnych systemów usługodawców".

Brak go w słowniku.



W przedstawionym opisie założeń projektu nie wykazano procesu „roboczej certyfikacji”, ani nie określono organu, który by go realizował.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Przywołane sformułowanie dotyczyło odpowiedzi na pytanie o wsparcie w zakresie podłączania się podmiotów leczniczych i aptek do systemu. Otóż przewidziano w projekcie środowisko ewaluacyjne i wsparcie użytkowników/wytwórców oprogramowania w zakresie podłączenia oraz oceny poprawności działania wykonanych usług. Nie jest planowana certyfikacja (w rozumieniu takim iż podłączymy tylko systemy, które uzyskają certyfikację) w związku z tym wystąpiła z przymiotem robocza. Niemniej rekomendowane będzie przeprowadzenie ewaluacji systemów, które chcą korzystać z usług P1.



A.M

3.2

Autor przedstawia realizacji projektu jako jedyny możliwy wariant. Nie ma żadnej próby znalezienia innego rozwiązania. Nie wygląda ta rozprawka rzetelnie, można by przynajmniej ocenić możliwość zastosowania zdecentralizowanego modelu bazującego na obecnie wypracowanych już lokalnych rozwiązaniach.




Dokument został uzupełniony

Rozdział 3.1 został uzupełniony o następującą treść:

„Innym możliwym rozwiązaniem byłoby wybranie modelu opartego systemy regionalne (16 systemów regionalnych zgodnie z podziałem administracyjnym kraju). Rozważania w tym zakresie związane były z następującymi kwestiami:



  • w części regionów systemy regionalne funkcjonują, w pozostałych są w budowie lub kwestii planów,

  • ograniczenie regionalnych platform jedynie do szpitali,

  • różny zakres funkcjonalny platform,

  • brak implementacji obsługi e-recepty w ramach platform,

  • zróżnicowane możliwości, kompetencje specjalistyczne poszczególnych regionów,

  • wysoki stopień trudności koordynacji realizacji takiego przedsięwzięcia w rozproszonej strukturze.”



AM

6.2

Harmonogram jest nieaktualny. Wybór wykonawców ma się odbyć w tym tygodniu.




Dokument został uzupełniony

Rozdział 6.2 – Harmonogram został zmodyfikowany. Uwzględniono dwa postępowania na kontynuację prac programistycznych oraz wprowadzono zależność rozpoczęcia prac od decyzji KRMC.



AM

7.1

Roczny koszt utrzymania trwałości projektu projektu na poziomie 40% wdrożenia. Czy jest jakieś inne uzasadnienie tak wysokiej kwoty utrzymania ?




Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Koszt projektu (245 mln) odnosi się do II fazy, natomiast całkowity koszt powinien uwzględniać I fazę, gdzie poczyniono nakłady na pozyskanie ITS oraz oprogramowania, zatem przywołany wskaźnik jest niższy (13%).

Na kwotę (95 mln) składa się odtworzenie sprzętu, wynagrodzenia i usługi obce. Kwota ta stanowi średni roczny koszt i została wyznaczona na podstawie kosztu utrzymania z tabelki 7.3.





AM

7.2

Budżet inwestycyjny jest na bardzo wysokim poziomie, nie widać jak środki przeznaczone na wytworzenie oprogramowania będą dysponowane, na jakie fazy i czy na zewnętrzne kontraktowe zasoby czy własne rozwojowe. Czy w ramach projektu zakłada się zakup nowych licencji?




Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Na pozycję inwestycji składa się koszt pozyskania zasobów zewnętrznych (realizujących prace programistyczne) oraz koszt zmian związanych z uzupełnieniem ITS (sprzęt/licencje).

Koszt związany z realizacją prac przez CSIOZ został ujęty w pozycji Wynagrodzenia (7.2).





AM

7.3

Czym się różnią roczne koszty z tabelki 7.1 vs koszty z tabelki 7.3. Skąd wynika wyskość estymowanych kosztów i dlaczego w piątym roku są 3krotne w stosunku do pozostałych lat ?




Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

W tabeli 7.1 ujęto koszty projektu z perspektywy jego realizacji i zakończenia w ramach POPC, natomiast w tabeli 7.3 wykazano koszty związane z jego utrzymaniem systemu finansowane z budżetu państwa.

Należy jednak zauważyć że ostania pozycja tabelki 7.1 stanowi średnią na podstawie kwot z tabelki 7.3, co wynika z konstrukcji szablonu dokumentu.





AM

12.1

Które komponenty w ramach pilota będą wykorzystane. Szczególnie dotyczy to poprzedniej zawieszonej fazy projektu P1.




Dokument został uzupełniony

Informacja o zmianach względem I fazy zawarto w rozdziale 3.2, dodatkowo na diagramie architektury wskazano, które podsystemy zostaną wykorzystane z I fazy, a które należy zbudować w całości w II fazie.

Na potrzeby pilota niezbędne jest uruchomienie następujących podsystemów: SUS, SAA, SAU, SAZ, IKP, SGR, SRR, SRS, ZDP, SWD.





AM

12.4

Brak informacji w jakim zakresie już przygotowane rozwiązanie z poprzedniej fazy będą wykorzystane jako podstawa w nowej architekturze. Czy elementy architektury z punktu 12.1 będą zbudowane od nowe czy re użyte. Czy szyna integracyjna będzie budowana od nowa.




Dokument został uzupełniony

Informacja o zmianach względem I fazy zawarto w rozdziale 3.2, dodatkowo na diagramie architektury wskazano, które podsystemy zostaną wykorzystane z I fazy, a które należy zbudować w całości w II fazie.

Nie jest planowane wykorzystanie Szyny Usług z I fazy projektu tj. produktu IBM Websphere ESB obecnie planowane jest wykorzystanie szyny typu open source - WSO2.









ogólne

Warto w projekcie przedstawić plan zarządzania projektem, strukturę organizacyjna przedstawiającą zaangażowanie interesariuszy oraz ich sposób pracy i wpływu na realizacje projektu. Szczególnie w zaleceniach powinno się zwrócić uwagę na strukturę organizacyjną, schematy komunikacji, ścieżki eskalacji oraz monitoringu projektu, tak aby nie powielić błędy z poprzedniej fazy. Konieczne także jest zwrócenie uwagi na kompetencje zamawiającego, który powinien przygotować odpowiednie zasoby projektowe niezbędne do zarzadzania wykonawcą i interesariuszami w projekcie.




Dokument został uzupełniony

Rozdział 11 został uzupełniony o strukturę organizacyjną (Rysunek 1).

Wszelkie kwestie związane z zależnościami pomiędzy poszczególnymi rolami czy sposób komunikacji znajdą ujście w dokumentacji inicjowania projektu i strategiach projektowych.





ZUS

Cały dokument

W dokumencie nie odniesiono się do fazy I. Nie wiadomo, co zostało wytworzone w fazie I, czy zakres przedstawiony w dokumencie dotyczy tylko fazy II, czy obydwu faz.

Wyróżnić elementy fazy II. Pokazać ciągłość pomiędzy fazą I a II.

Dokument został uzupełniony

Informacja o zmianach względem I fazy zawarto w rozdziale 3.2, dodatkowo na diagramie architektury wskazano, które podsystemy zostaną wykorzystane z I fazy, a które należy zbudować w całości w II fazie.




ZUS

11

Opis metody prowadzenia projektu nie określa trybu w jakim będą pozyskiwane wymagania, definiowany będzie zakres realizowanych wymagań. Pominięta została kwestia właściciela produktu.

Metoda nie określa też zasad współpracy z podmiotami, będącymi beneficjentami udostępnianych e-usług, co wydaje się istotne na etapie specyfikacji, testowania i wdrażania e-usług z punktu widzenia oczekiwanych rezultatów.



Uzupełnić opis metody o brakujące kwestie

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Zostaną wykorzystane wymagania opracowane w I fazie i dostosowane do zoptymalizowanych procesów biznesowych. Główne wymagania nie ulegają zmianie, a jedynie może zmienić się sposób ich obsługi.

Właściciele poszczególnych produktów zostaną wyznaczeni wraz z właścicielami obszarów biznesowych.

W projekcie uwzględniono potrzebę uruchomienia ewaluacji oraz konsultacji specyfikacji modeli transportowych.




ZUS

7

Brak możliwości odniesienia się do zaproponowanych kosztów, brak odniesienia do danych porównawczych, brak szacunków dotyczących złożoności oprogramowania

Określić sposób i podstawy szacowania kosztów.

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Koszty wytworzenia oprogramowania zostały opracowane na podstawie funkcjonalności systemu, koszty związane z pracami odbiorowymi, testami i utrzymaniem przygotowano na podstawie średniego wynagrodzenia osób na poszczególnych stanowiskach.



ZUS

3

Rozdział nie przedstawia faktycznych wariantów, a jedynie alternatywę: realizować P1 lub nie realizować P1. Rozdział nie jest więc przedstawieniem Wariantów biznesowych, jak sugeruje jego nazwa, ale uzasadnieniem projektu.

Nadmieniono, że pewnym rozwiązaniem byłyby regulacje, które unormowałyby rynek medyczny i częściowo rozwiązały problem, ale nie rozwinięto tematu.



Zmienić nazwę rozdziału lub rozwinąć analizę wariantów biznesowych

Dokument został uzupełniony

Nazwa rozdziału została określona przez szablon opracowany przez MC.

Rozdział 3.1 został uzupełniony o następującą treść:

„Innym możliwym rozwiązaniem byłoby wybranie modelu opartego systemy regionalne (16 systemów regionalnych zgodnie z podziałem administracyjnym kraju). Rozważania w tym zakresie związane były z następującymi kwestiami:


  • w części regionów systemy regionalne funkcjonują, w pozostałych są w budowie lub kwestii planów,

  • ograniczenie regionalnych platform jedynie do szpitali,

  • różny zakres funkcjonalny platform,

  • brak implementacji obsługi e-recepty w ramach platform,

  • zróżnicowane możliwości, kompetencje specjalistyczne poszczególnych regionów,

  • wysoki stopień trudności koordynacji realizacji takiego przedsięwzięcia w rozproszonej strukturze.”



ZUS

5.1

Cel – 2,

Cel – 3


Trzeba zwrócić uwagę, że sam dostęp do elektronicznych danych, a nawet korzystanie z nich, nie gwarantuje korzyści.

Kluczowe jest, aby personel medyczny mógł się na nich oprzeć w takim stopniu, aby nie musieć korzystać z innych tradycyjnych źródeł danych. Dopiero taki stan pozwoli na faktyczne usprawnienie pracy. Należałoby więc zdefiniować KPI, który np. odnosi się do odsetka przypadków (), w których potrzebuje korzystać poza udostępnianymi danymi medycznymi z innych uzupełniających źródeł (np. papierowych – przynoszonych przez pacjenta) danych medycznych.



Zdefiniować dodatkowe lub zredefiniować KPI

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

W rozdziale 5.1 CSIOZ przedstawił wszystkie zaktualizowane wskaźniki zgodne z wnioskiem do Komisji Europejskiej ws. fazowania projektu. Bazowały one na wskaźnikach z I fazy projektu i w związku z fazowaniem powinny pozostać.

Należy zauważyć, że wszystkie KPI uzyskały już akceptację KE.





ZUS

5.6

To raczej ryzyka, że projekt nie przyniesie rezultatów, niż negatywne rezultaty.

Jako negatywny rezultat, wstępnie można wskazać narażenie olbrzymiej ilości danych wrażliwych na wyciek, atak elektroniczny, nowe formy przestępczości elektronicznej.



Przenieść zapisy do rozdziału z ryzykami

Wprowadzić opis faktycznych negatywnych rezultatów



Dokument został uzupełniony

Treść została poprawiona. Zaproponowano nową treść dla rozdziału 5.6.



ZUS

6.2

„W pełni produkcyjny start systemu P1 po zakończonym okresie stabilizacji ”

Na czym będzie polegać ten „pełny start”. Czy dojdą jakieś funkcjonalności, czy dostęp będzie wcześniej ograniczony, na czym polega stabilizacja, na podstawie przedstawionego opisu można mieć wątpliwość, co do tego kamienia milowego, czy on jest w ogóle potrzebny?



Usunąć kamień milowy lub przedefiniować harmonogram

Dokument został uzupełniony

Poprzednie zadanie: „W pełni produkcyjny start systemu P1 po zakończonym okresie stabilizacji” zastąpiono następującym: „Okres stabilizacji system P1 w zakresie wcześniej wytworzonych i wdrożonych funkcjonalności.”



ZUS

12.3

Brak informacji o wprowadzeniu mechanizmów, które zapewniłyby skalowalność

Uzupełnić informacje

Dokument został uzupełniony

Wysoka dostępność zostanie zapewniona. W rozdziale 13.1 dodano odpowiednią treść, analogicznie do uwagi nr 3.



RA (Roman Janczarek)

5.2 Udostępnione e-usługi

Należy poprawić nazwę usługi

"4. Udostępnienie danych o zdarzeniach medycznych pacjentom w postaci elektroniczne."



4. Udostępnienie danych o zdarzeniach medycznych pacjentów w postaci elektroniczne."

Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

To usługa A2C tylko dla usługobiorców. Dla innych użytkowników mieści się w ramach innych usług.



RA (Roman Janczarek)

5.2 Udostępnione e-usługi

Dla prawidłowości skalowania warstwy infrastruktury technicznej należy podać szacowaną wolumetrię usług również na zakończenie projektu.




Przedstawiamy wyjaśnienie dot. uwagi, bez zmian w dokumentacji.

Przedstawiona szacowana wolumetria uwzględnia podłączenie wszystkich usługodawców i pełne wykorzystanie systemu. W związku z odraczanym obowiązkiem prowadzenia elektronicznej dokumentacji medycznej oraz elektronicznych recept i skierowań oraz mając na uwadze sukcesywne uruchamianie funkcjonalności systemu, wczesną publikację komunikatów, uruchomienie środowiska ewaluacyjnego, a także 6-miesięczny okres stabilizacji po uruchomieniu wszystkich funkcjonalności szacunki muszą oscylować wokół oczekiwanej wolumetrii.



RA (Roman Janczarek)

12.1 Planowana architektura rozwiązania

Należy skorygować zapis „W Projekcie P1 przewidziano uwzględnienie następujących metod identyfikacji elektronicznej Profilu Zaufanego i zaawansowanego podpisu kwalifikowanego. W związku z metodą realizacji projektu przewidujemy również możliwość rozszerzenia o kolejne metody w momencie ich pojawiania się np. Karty Specjalisty Medycznego lub pieczęci elektronicznej.”

Katalog przyszłych metody identyfikacji jest otwarty, uważam wymienianie koncepcji takich jak Karta Specjalisty Medycznego za co najmniej przedwczesne.



W Projekcie P1 przewidziano uwzględnienie następujących metod identyfikacji elektronicznej Profilu Zaufanego i kwalifikowanego zaawansowanego podpisu elektronicznego. W związku z metodą realizacji projektu przewidujemy również możliwość rozszerzenia o kolejne metody identyfikacji w momencie ich pojawiania się np. usług Krajowego węzła identyfikacji.

Dokument został uzupełniony

Uzupełniono zgodnie z uwagą.





©operacji.org 2019
wyślij wiadomość

    Strona główna