Uzupełnienie informacji na temat planowanego systemu EHR rozwiniecie odpowiedzi na pytania zgłoszone odwołaniu firmy Pixel Technology

Transkrypt

1 Uzupełnienie informacji na temat planowanego systemu EHR rozwiniecie odpowiedzi na pytania zgłoszone odwołaniu firmy Pixel Technology Odwołujący zarzuca Zamawiającemu, że nie podał podstawowych informacji o systemie EHR, który nie jest przedmiotem zamówienia a w szczególności żąda informacji na temat: Ilości i rodzajów baz danych (proste, złożone, relacyjne czy obiektowe itp..) Struktury poszczególnych baz danych (rodzaje i ilość tabel..) Rozmiaru baz danych zamieszczanych w repozytorium EHR, Sposobu migracji ze wskazaniem na dane, które mają pierwszeństwo... Dokładnego zakresu danych, które podlegają integracji Trzeba nadmienić, że tego typu informacje dotyczące architektury systemu EHR nie są potrzebne do realizacji przedmiotu zamówienia. Integracja z EHR nie wymaga znajomości jego struktur baz danych ponieważ zakres zamówienia nie obejmuje integracji na poziomie baz danych. Byłoby to niedopuszczalne ze względu m.in. na konieczność zapewnienia bezpieczeństwa i integralności struktur baz danych EHR z którym integrować się będą nie tylko systemy PACS/RIS znajdujące się w szpitalach, ale również systemy HIS oraz inne systemy dziedzinowe, które powstaną w przyszłości. Dlatego stosowana będzie tylko i wyłączne komunikacja poprzez szynę integracyjną, zapewnianą przez EHR. Szyna będzie przyjmowała komunikaty określone w ogólnie przyjętych standardach i protokołach komunikacyjnych (takich jak istotny w niniejszym zamówieniu protokół DICOM, ale i również i innych standardach takich jak m.in. HL7CDA, HL7V2, XDS, XML). Ponadto architektura i struktury baz danych są indywidualne dla każdego wykonawcy, który może w przyszłości realizować system EHR i są one zazwyczaj tajemnicą przedsiębiorstwa. Ze względu na to, ze nie mają one bezpośredniego wpływu na funkcjonalność systemu a stanowią element szczegółowego projektu technicznego nie będą one specyfikowane przez zamawiającego na etapie zamawiania EHR. Do zadań wykonawcy w niniejszym postępowaniu nie będzie należała integracja z EHR na poziomie baz danych a jedynie zapewnienie interfejsu wysyłającego dane na poziomie protokołu DICOM oraz HL7. Ponadto w dalszej części odwołujący pyta o informacje dotyczące ogólnego sposobu działania EHR w tym, czy dane będą przechowywane w modelu centralnym. Zamawiający informuje, że zamierza rozwijać koncepcję centralnego systemu EHR ze względu na większą niezawodność takiego rozwiązania w porównaniu do modelu federacyjnego. Będzie to zatem z pozycji odwołującego centralny PACS do którego będą podłączone lokalne systemy PACS, które są przedmiotem niniejszego zamówienia. Zamawiający uważa, że ze względu na to, że DICOM jako protokół jest dobrze udokumentowany, wykonawcy mogą z powodzeniem wycenić koszt takiego zamówienia na podstawie specyfikacji oraz informacji udzielanych przez Zamawiającego. Zakres integracji będzie dotyczył obiektów DICOM oraz danych umożliwiających identyfikację pacjenta na poziomie regionalnym. Zamawiający przyjął, że na potrzeby systemu EHR identyfikatorem pacjenta na poziomie regionalnym będzie numer PESEL. Jest to rozwiązanie ułomne jednak ze względu na trudności integracyjne związane z brakiem innego MPI

2 oraz założeniami platform rządowych, które też wykorzystują ten identyfikator, Zamawiający przyjął je jako obowiązujące na obecnym etapie realizacji projektu. Ze względu na to, że jakakolwiek integracja systemów jest związana z realizacją prac po obu stronach (PACS/RIS, EHR) również odpowiedzialność za nią jest obustronna. Wykonawca systemu lokalnego, który jest zamawiany nie będzie odpowiedzialny bezpieczeństwo fizyczne danych, związane z przesłaniem ich bezpieczną siecią czy też przetwarzaniem danych na poziomie EHR. Wszystkie kwestie związane z bezpieczeństwem oraz uprawnieniami dostępu do danych wysyłanych na poziom regionalny będą rozwiązywane na poziomie EHR i wykonawca niniejszego postępowanie nie będzie za nie odpowiedzialny i nie będzie też zobowiązany do skonstruowania i konfiguracji mechanizmów zarządzania uprawnieniami używanymi na potrzeby EHR, co wynika ze specyfikacji niniejszego zamówienia, która tych tematów nie opisuje.. Wykonawca będzie zobowiązany do wprowadzenia wymaganych specyfikacją funkcjonalności i mechanizmów, w tym związanych z zabezpieczeniami tylko i wyłącznie na poziomie lokalnym (szpitalnym). Zamawiający nie przewiduje na tym etapie realizacji możliwości udostępniania danych z EHR pacjentom oraz innym jednostkom. Dostęp do danych będą miały tylko i wyłącznie szpitale uczestniczące w projekcie. Za prawa dostępu do danych ich przetwarzanie, prowadzenie logów, przechowywanie bazy użytkowników, udzielanie i cofanie uprawnień, agregację danych oraz ich prezentację będzie odpowiedzialny system EHR. Baza użytkowników EHR będzie odrębna i nie będzie synchronizowana z HIS/RIS. Systemy PACS/RIS oraz w przyszłości również HIS będą jedynie odpowiedzialne za dostarczenie danych w formacie zgodnym ze specyfikacją wraz z identyfikatorem pacjenta (PESEL). W przypadku braku takiego identyfikatora, platforma EHR będzie również obsługiwała i klasyfikowała dane opisane poprzez lokalne ID Pacjenta (DICOM Issuer Of Patient ID) na podstawie tagów oraz pól DICOM odbieranych obiektów / komunikacji DICOM - Issuer Of Patient ID,Requesting Service, Calling AE Title. Platforma EHR będzie miała możliwość równoległego wyszukiwania badań w wielu źródłach DICOM, tzn. w przypadku, gdy użytkownik będzie wyszukiwał badanie o wybranym numerze DICOM Patient ID, platforma EHR wyśle zapytania DICOM Query do wszystkich skonfigurowanych węzłów DICOM. Ważna jest również możliwość konfiguracji ograniczania widoczności wybranych pacjentów, pochodzących z danego źródła DICOM, na podstawie wartości DICOM Issuer Of Patient ID. tzn. wybrany, skonfigurowany węzeł DICOM może otrzymywać na zapytania DICOM Query (C-FIND) tylko pacjentów o wybranych przez administratora platformy EHR wartościach Issuer Of Patient ID. Platforma EHR będzie wspierać m.in. odbieranie i wysyłanie oraz archiwizację następujących klas DICOM oraz dodatkowych klas SOP: Wymagany jest minimum standard DICOM Wymagane usługi DICOM Nazwa klasy SOP UID klasy SOP SCU SCP Verification Verification Tak Tak Transfer Zgodnie z SIWZ na poziomie PACS z określonego pakietu, w którym będzie partycypował Dostawca Query/Retrieve Patient Root Query/Retrieve Information Model FIND Tak Tak Patient Root Query/Retrieve Information Model MOVE Tak Tak Study Root Query/Retrieve Information Model FIND Tak Tak Study Root Query/Retrieve Information Model MOVE Tak Tak Workflow Management Storage Commitment Push Model Tak

3 Wymagany domyślnie wspierany Transfer Syntax Transfer Syntax UID Implicit VR Little Endian Wymagane dodatkowe wspierane wersje Transfer Syntax dla usługi zapisu (ang. storage) oraz pobierania danych (ang. retreival) Transfer Syntax UID Explicit VR Little Endian lub Explicit VR Big Endian JPEG Process 1, baseline, lossy (8 bit) lub JPEG Process 2,4, extended lossy (12 bit) JPEG Process 14, lossless, Non-Hierarchical lub JPEG Process 14, selection value 1, lossless, Non- Hierarchical, First-Order Prediction lub lub lub RLE Lossless Wymagane wspierane strony kodowe Character Set Description Defined Term Basic G0 Set ISO-IR 6 (domyślne) ISO Latin Alphabet No. 1 ISO-IR 100 Wszystkie pozostałe parametry zgodnie ze standardem DICOM Odwołujący w p. 7 podkreślił, że w odróżnieniu od protokołu DICOM standard HL7 nie jest wystarczająco dokreślony. Zamawiający uważa, że opisując zawartość informacyjną, która może być wymieniana przy pomocy HL7, przekazał wystarczające informacje, aby można było dokonać wyceny przedmiotu zamówienia, dodatkowo Zamawiający dołączył załącznik do pisma o częściowym uznaniu odwołania w którym opisuje interfejs HL7. Z treści pytania nr 8 Zamawiający wnioskuje, że chodzi o wymianę pomiędzy RIS a EHR, zamawiający przedstawił opis HL7. Podstawowym identyfikatorem jest PESEL w przypadku jego braku system lokalny przesyła inny (wewnętrzny identyfikator). System EHR będzie odpowiedzialny za integrację rekordu pacjenta i zarządzanie jego identyfikatorami w różnych systemach. Odnosząc się do pytania nr 9 Zamawiający wskazuje, że integracja i łączenie danych EHR nie jest przedmiotem zamówienia w niniejszym postępowaniu. Odnosząc się do pytania nr 10, Zamawiający informuje, że standard WADO nie będzie wykorzystywany. Odnosząc się do pytania nr 11 Zamawiający informuje, że przedstawił wymagania odnośnie interfejsu DICOM a sieć VPN nie jest elementem niniejszego postępowania i będzie realizowana odrębnie. Odnosząc się do pytania nr 12 Zamawiający informuje, że w powyższej odpowiedzi przekazał informację o scentralizowanej postaci systemu EHR.

4 Odnosząc się do pytania nr. 13 Zamawiający uważa, że sposób generowania raportów EHR nie jest przedmiotem niniejszego postępowania. Pozostałe informacje są zawarte w załączniku nr 3 do pisma o częściowym uznaniu odwołania. Odnosząc się do pytania nr 14, Polityki odnośnie usuwania i archiwizacji danych będą określone na późniejszym etapie i żadne funkcjonalności PACS/RIS w tym względzie nie są wymagane w niniejszym postępowaniu i nie dotyczą tego zamówienia. Odnosząc się do pytania nr 15, Zamawiający informuje, że należy się kierować informacjami zawartymi w opisach poszczególnych pakietów. Odnosząc się do pytania nr 16, Zamawiający informuje, że dane powinny być usunięte w źródłowym systemie PACS. Odnosząc się do pytania nr 17, Zamawiający informuje, że należy się kierować informacjami zawartymi w opisach poszczególnych pakietów. Odnosząc się do pytania nr 18 jest ono w opinii Zamawiającego niezrozumiałe ponieważ nie wiadomo do jakiego modułu raportowania się ono odnosi i o jakie konkretnie sposoby i rozbieżne typy i formaty danych Odwołujący pyta. Zamawiający prosi odwołującego o wyjaśnienie treści odwołania w tym względzie. Odnosząc się do pytania nr 19 dotyczącego odpowiedzialności względem systemu EHR, wykonawca, zgodnie ze zasadami integracji odpowiada za wystawienie minimalnie wymaganych danych przez system PACS i RIS do interfejsu platformy EHR zgodnie ze specyfikacją standardu DICOM i HL7 i informacjami znajdującymi się w opisach poszczególnych pakietów. Zamawiający załączył dodatkowe informacje dotyczące integracji DICOM i HL7 Odwołujący podkreśla, że Zamawiający odniósł się do ogólnie obowiązujących przepisów prawa przytaczając akty prawne, które w opinii odwołującego są zbyt ogólne. Zamawiający podkreśla, że jest to częsta praktyka i uważa, że przytaczanie przepisów prawa ma dodatkową wartość informacyjną i zabezpiecza Zamawiającego przed możliwością zaoferowania oprogramowania, które nie będzie zgodne z obowiązującym prawem. Ponadto, Odwołujący podkreślił, że ze względu na ogólność przepisów nie są znane m.in.: 1.lista podmiotów uprawnionych do dostępu do danych medycznych., Zamawiający odnosił się już do tego pytania powyżej informując, że są to tylko i wyłącznie szpitale uczestniczące w projekcie. Na tym etapie Zamawiający nie przewiduje udziału innych podmiotów 2. schemat uprawnień do poszczególnych badań... Schematy uprawnień do danych przesyłanych na poziom regionalny będą zarządzane z poziomu systemu EHR i wykonawca nie jest zobowiązany do implementacji tych schematów na poziomie lokalnym. Zatem nie dotyczy to zakresu przedmiotu zamówienia 3. zasady logowania użytkowników... Schematy i zasady o raz odpowiednie polityki odnośnie zasad logowania i haseł będą wprowadzone i przechowywane na poziomie EHR. Jeżeli chodzi natomiast o komunikację międzysystemową (na linii EHR-systemy PACS/RIS oraz HIS w szpitalu) to będzie ona bazowała na relacji zaufania pomiędzy jednostkami tj. pomiędzy szpitalem a operatorem systemu EHR (samorządem województwa). Jest to możliwe ze względu na obecnie niewielką liczbę jednostek, która będzie miała dostęp do tych danych.

5 Komunikacja pomiędzy węzłami a EHR będzie zabezpieczona poprzez bezpieczną sieć VPN funkcjonującą w topologii gwiazdy. Sieć VPN będzie realizowana w ramach odrębnego zamówienia. 4. Kwestia standardów wymiany danych pomiędzy lokalnymi systemami a systemem centralnym. Standardy wymiany danych zostały określone dla systemu PACS w specyfikacji i odpowiedzi na niniejsze odwołanie. Inne zakresy o które pyta Zamawiający, a w szczególności dotyczące modyfikacji części danych identyfikujących pacjenta należą do obszaru integracji EHR z systemem HIS i nie dotyczą bezpośrednio obszaru niniejszego zamówienia. Niemniej Zamawiający deklaruje, że będzie odpowiadać na szczegółowe pytania wykonawców w tym zakresie, jeżeli dodatkowe informacje będą niezbędne do stworzenia oferty. Ze względu na zawiłą i specjalistyczną tematykę oraz związaną z tym konieczność doprecyzowywania odpowiedzi w drodze dialogu, Zamawiający proponuje zorganizowanie zebrania, na którym będzie mógł odpowiedzieć na szczegółowe pytania wykonawców. 5. Kwestia integracji danych w przypadku konsultacji radiologicznych pomiędzy szpitalami Za wszelkie kwestie związane z integracją, przechowywaniem danych do tych celów będzie odpowiadał system EHR. 6. Czy pacjent powinien mieć możliwość stwierdzenia jaki podmiot i w jakim systemie będzie przetwarzał dane medyczne? Tak, jednak taka funkcja będzie realizowana centralnie poprzez system EHR, który będzie zapisywał informację dotyczące udostępniania danych pacjentów. Nie jest to funkcja wymagana na poziomie oprogramowania zamawianego w niniejszym postępowaniu. 7 i 8. Kwestia podmiotu odpowiedzialnego za bezpieczeństwo danych oraz monitorowanie zagrożeń. Podmiot zarządzający systemem EHR będzie wyznaczony na etapie eksploatacji. Odpowiednie procedury będą obowiązywały na poziomie centralnym. Zasady będą określone w polityce bezpieczeństwa dla systemu EHR, która będzie dostarczana razem z tym systemem. Nie jest to przedmiotem ani składnikiem związanym z realizacją niniejszego zamówienia.