Opis przedmiotu zamówienia

Transkrypt

1 Opis przedmiotu zamówienia Wstęp Przedmiotem zamówienia jest dostarczenie Systemu Elektronicznego Rekordu pacjenta EHR w formie usługi SAAS (Software as a service) oraz integracja systemu EHR z systemami HIS PACS w trzech wymienionych w umowie szpitalach oraz opcjonalnie w dwóch dodatkowych szpitalach wybranych z listy stanowiącej załącznik nr 1 do OPZ. Zamawiający wyklucza federacyjny model architektury systemu i wymaga wdrożenia modelu centralnego w którym dane ze szpitali są gromadzone w jednym węźle. Aplikacja EHR w formie usługi SAAS musi zostać udostępniona przez wykonawcę wszystkim partnerom projektu wymienionym w załączniku nr 1 do umowy. Aplikacja EHR udostępniona użytkownikom będzie funkcjonować w modelu trójwarstwowym umożliwiającym dostęp do niej poprzez przeglądarkę internetową. Minimalnie wymagana jest obsługa trzech przeglądarek tj. Mozilla Firefox v.40 lub wyższa, MS Internet Explorer v.11 lub wyższa oraz Google Chrome. Wykonawca zapewnia i zobowiązuje się, że korzystanie przez Zamawiającego z dostarczonych produktów nie będzie stanowić naruszenia majątkowych praw autorskich osób trzecich. Zamawiający wymaga Zamawiający wymaga, by oferowane oprogramowanie było oprogramowaniem w wersji aktualnej na dzień poprzedzający dzień składania ofert. Wykonawca w czasie udostępniania usługi i okresie gwarancji jest zobowiązany do wprowadzania uaktualnień oprogramowania o ile takowe się ukażą i dostosowywania systemu do przepisów prawa. Licencja Zamawiający wymaga udzielenia przez wykonawcę licencji niewyłącznej, nieograniczonej czasowo obejmującej wszystkie komponenty systemu EHR a w szczególności: Repozytorium danych klinicznych Portal dla Lekarza Repozytorium danych obrazowych Wizualizację danych obrazowych w ramach portalu lekarza. Licencja na system musi zostać udzielona na czas nieokreślony i gwarantować możliwość użytkowania oprogramowania wszystkim szpitalom uczestniczącym w projekcie oraz Zamawiającemu wraz z uwzględnieniem możliwości migracji na inne środowisko przewidzianej w umowie. Licencja musi gwarantować pięcioletni czas dostępności do usługi EHR liczony od momentu podpisania protokołu odbioru Licencja obejmować będzie wszystkie kluczowe komponenty systemu EHR z uwzględnieniem szyny integracyjnej (ESB) oraz niezbędnego do uruchomienia usługi middleware-u. Wykonawca nie musi dostarczyć licencji na bazy danych, licencji na systemy operacyjne oraz na oprogramowanie warstwy wirtualizacji i backup-u. Zamawiający wymaga, dostarczenia systemu w trzech instancjach tj. produkcyjnej aktywnej oraz jej repliki synchronizowanej w czasie rzeczywistym (pasive) a także instancji testowej. Parametry usługi SAAS EHR oraz licencja instancji produkcyjnej muszą zostać wyskalowane wg następujących parametrów: maksymalnie 7500 kont użytkowników, maksymalnie 750 równoczasowych, zalogowanych użytkowników, maksymalnie populacja 2 millionów pacjentów regionu Kujawsko-Pomorskiego, 25 podłączonych systemów HIS, z uwzględnieniem typu odbieranych informacji HL7 zgodnie z standardem interfejsu HL7 dla HIS określonym w specyfikacji: o o Historia wizyt pacjenta w regionie (HL7 ADT) Lista problemów zdrowotnych pacjenta (HL7 PPR)

2 o o o Alergie pacjenta (HL7 ADT) Wyniki laboratoryjne (HL7 ORU) Epikryza z karty informacyjnej z leczenia szpitalnego (HL7 MDM) 25 podłączonych systemów PACS o o o maksymalnie 1 million badań DICOM rocznie maksymalnie 10 millionów obrazów DICOM rocznie maksymalnie 20 TB danych DICOM rocznie w formacie DICOM LEI o maksymalnie obrazów DICOM per godzina w szczycie 07:00 13:00 dziennie Wykonawca udzieli na system minimum 5lat gwarancji z warunkami SLA opisanymi w załączniku do umowy. W ramach wdrożenia realizowanego we wskazanych w umowie szpitalach Wykonawca przeszkoli maksymalnie 30 osób w dwóch grupach, w formie warsztatów przy stanowiskach komputerowych. Tematyka szkolenia obejmować będzie zagadnienia związane z obsługą systemu EHR. Wykonawca zapewni organizację szkolenia w wymiarze minimum 4 godzin z zapewnieniem minimum jednej przerwy kawowej. Wykonawca dostarczy zamawiającemu oraz wszystkim przeszkolonym osobom materiały w postaci szczegółowej instrukcji obsługi systemu w formie papierowej oraz elektronicznej.

3 System musi spełniać następujące warunki obligatoryjne: Lp Zapis 1.1. Dla wszystkich obieranych wiadomości HL7, szyna integracyjna EHR musi przeprowadzać dwustopniową weryfikację numeru PESEL. Wymaganym pierwszym stopniem jest weryfikacja sumy kontrolnej numeru PESEL, zaś wymaganym drugim stopniem jest weryfikacja poprawności numeru PESEL względem zapisanych w polach wiadomości HL7 danych dotyczących płci oraz daty urodzenia pacjenta. Nie przejście testu nie pozwoli zapisać informacji w repozytorium danych klinicznych systemu EHR i zostanie zapisana do weryfikacji przez administratora EHR w panelu administracyjnym WWW Numer PESEL ma być traktowana przez platformę jako Master Patient Index (zgodnie ze standardem IHE) Do prezentacji [/NIE] Scenariusz prezentacji próbki oprogramowania 1. Wysłać HL7 z prawidłowym numerem PESEL, zademonstrować przejście weryfikacji 2. Wysłać HL7 z nieprawidłowym numerem PESEL, zademonstrować brak możliwości przejścia weryfikacji CRC i powiadomienie administratora EHR w panelu administracyjnym WWW o błędnej weryfikacji 3. Wysłać HL7 z nieprawidłowym numerem PESEL, zademonstrować brak możliwości przejścia weryfikacji płci i daty urodzenia pacjenta z pól HL7 względem wartości z numeru PESEL i powiadomienie administratora EHR w panelu administracyjnym WWW o błędnej weryfikacji

4 1.2. Dla wszystkich obieranych obrazów DICOM, szyna integracyjna EHR musi mieć możliwość dla każdego podłączonego węzła DICOM, konfiguracji lokalizacji tagu DICOM, z którego ma być odczytywany numer PESEL i traktowany przez platformę jako Master Patient Index (zgodnie ze standardem IHE) 1.3. Szyna integracyjna EHR ma spełniać profil IHE Patient Identifier Crossreferencing jako aktor Consumer. Załączyć certyfikat IHE. Dodatkowo, system EHR ma spełnić wymagania następującego workflow : Dla danych DICOM wymagane jest budowanie tabeli identyfikatorów lokalnych pacjenta oraz powiązanego z nim numeru PESEL, tak aby w momencie zapytania DICOM Query (C-FIND) do systemu EHR przez lokalny system PACS z użyciem lokalnego ID pacjenta, aby system EHR mógł odpowiedzieć listą badań danego pacjenta z innych szpitali, gdzie pacjent miał nadane inne lokalne ID pacjenta. W momencie wysyłania kopii badania DICOM Retreive (C-MOVE) z systemu EHR, w ramach odpowiedzi na zapytanie DICOM Query (C-FIND), system EHR ma zamieniać DICOM Tag ID pacjenta na ID pacjenta w danym lokalnym systemie, tak aby umożliwić lokalnemu systemowi PACS podłączenia badania do historii badań pacjenta. 1. wysłanie badania DICOM węzła DICOM nr. 1 z numerem PESEL zapisanym w prywatnym tagu DICOM nr.1. Przedstawić konfigurację i odbiór numeru PESEL jako MPI identyfikatora pacjenta 2. wysłanie badania DICOM węzła DICOM nr.2 z numerem PESEL zapisanym w prywatnym tagu DICOM nr.2. Przedstawić konfigurację i odbiór numeru PESEL jako MPI identyfikatora pacjenta Zaprezentować opisany workflow: 1. Wysłać badanie nr. 1 z ID nr.1 do systemu EHR 2. Wysłać badanie nr. 2 z ID nr.2 do systemu EHR 3. Wykonać zapytanie DICOM Query o badania pacjenta o ID nr.1 odpowiedź powinna zawierać 2 badania (z pkt.1 i 2.) 4. Wykonać DICOM Retreive badania nr. 2, po odebraniu badania zaprezentować zmianę ID pacjenta w badanie nr 2 na ID nr.1

5 1. Integracja z zewnętrznymi systemami HIS Lp Zapis 2.1.System EHR musi odebrać, archiwizować i udostępniać historię wizyt oraz hospitalizacji pacjenta dla placówek medycznych w regionie Kujawsko- Pomorskim. Do prezentacji [/NIE] Scenariusz prezentacji Poprzez standard HL7 v2.4, odbierane mają być następujące wiadomości : ADT^A01 Admit / Visit Notification ADT^A02 Transfer a Patient ADT^A03 Discharge / End Visit ADT^A04 Register Patient ADT^A05 Pre-Admit a Patient ADT^A06 Change an Outpatient to an Inpatient ADT^A07 Change an Inpatient to an Outpatient ADT^A08 Update Patient Information ADT^A11 Cancel Admit / Cancel Visit Notification ADT^A12 Cancel Transfer ADT^A13 Cancel Discharge / Cancel End Visit ADT^A28 Add Person or Patient Information ADT^A31 Update Person Information ADT^A38 Cancel Pre-admit ADT^A50 Change Visit Number wysłanie każdej z wymienionych wiadomości HL7 do systemu EHR oraz oczekiwaną zmianę w Portalu EHR dla Lekarza, zgodnie z opisem wiadomości HL7 zawartym w dokumentacji standardu HL7 używając do odczytywania tych informacji segmentów PV1,ZPV1,PV2 oraz DG1 2.2.System EHR musi odebrać, archiwizować i i udostępniać listę aktualnych i przeszłych problemów zdrowotnych pacjenta, odebranych w kodowaniu ICD-10 od systemów HIS, dla placówek medycznych w regionie Kujawsko- Pomorskim Poprzez standard HL7 v2.4, odbierane mają być następujące wiadomości : PPR^PC1 Add Problems PPR^PC2 Update Problems PPR^PC3 Delete Problems wysłanie każdej z wymienionych wiadomości HL7 do systemu EHR oraz oczekiwaną zmianę w Portalu EHR dla Lekarza, zgodnie z opisem wiadomości HL7 zawartym w dokumentacji standardu HL7 używając do odczytywania tych informacji segmentu PRB. 2.3.System EHR musi odebrać, archiwizować i i udostępniać listę aktualnych i przeszłych alergii pacjenta dla placówek medycznych w regionie Kujawsko- Pomorskim Poprzez standard HL7 v2.4, odbierane mają być następujące wiadomości : ADT^A01 Admit / Visit Notification ADT^A04 Register Patient ADT^A05 Pre-Admit a Patient ADT^A06 Change an Outpatient to an Inpatient ADT^A07 Change an Inpatient to an Outpatient ADT^A08 Update Patient Information ADT^A13 Cancel Discharge / Cancel End Visit ADT^A28 Add Person or Patient Information ADT^A31 Update Person Information wysłanie każdej z wymienionych wiadomości HL7 do systemu EHR oraz oczekiwaną zmianę w Portalu EHR dla Lekarza, zgodnie z opisem wiadomości HL7 zawartym w dokumentacji standardu HL7 używając do odczytywania tych informacji segmentu AL1.

6 2.4.System EHR musi odebrać, archiwizować i i udostępniać wyniki laboratoryjne pacjenta dla placówek medycznych w regionie Kujawsko-Pomorskim. Wyniki laboratoryjne w integracji HIS-LIS są zazwyczaj wymieniane w formie wyników numerycznych (np. wyniki hematologiczne / biochemiczna). Dane te są danymi ustrukturyzowanymi I mogą być wizualizowane w formacie tabeli oraz wykresów. Inne wyniki laboratoryjne, takie jak wyniki mikrobiologiczne / patologii komórkowej mogą być firmie tekstowej. Dlatego też wymaga się, aby integracja wyników laboratoryjnych uwzględniała następujące kategorie: - Hematologię - Biochemię - Immunologię - Mikrobiologię - Patologię komórek Kategoria do jakiej będzie należał odebrany przez platformę EHR wynik laboratoryjny wynik będzie wskazana w wiadomości HL7 ORU zgodnie z lokalnym słownikiem interfejsu dostawcy systemu LIS lub HIS. Poprzez standard HL7 v2.4,, odbierane mają być następujące wiadomości : ORU^R01 Unsolicited Observation używając do odczytywania tych informacji segmentów ORC,OBR,ZOBR,NTE,OBX,ZOBX,NTE oraz SPM. 2.5.System EHR musi odebrać, archiwizować i i udostępniać epikryzę z karty informacyjnej z leczenia szpitalnego pacjenta dla placówek medycznych w regionie Kujawsko-Pomorskim Poprzez standard HL7 v2.4, odbierane mają być następujące wiadomości : MDM^T02 Original document notification MDM^T06 Document Addendum notification MDM^T10 Document replacement notification używając do odczytywania tych informacji segmentów MSH,EVN,PID,PV1,TXA oraz OBX. wysłanie każdej z wymienionych wiadomości HL7 do systemu EHR oraz oczekiwaną zmianę w Portalu EHR dla Lekarza, zgodnie z opisem wiadomości HL7 zawartym w dokumentacji standardu HL7 wysłanie każdej w wymienionych wiadomości HL7 do systemu EHR oraz oczekiwaną zmianę w Portalu EHR dla Lekarza, zgodnie z opisem wiadomości HL7 zawartym w dokumentacji standardu HL7

7 2.6.Portal dla lekarza EHR ma mieć możliwość integracji SAML 2.0 z podłączonymi systemami HIS, w celu możliwości wywoływania portalu EHR, widoku regionalnego rekordu EHR wybranego w systemie HIS pacjenta, bezpośrednio z klienta systemu HIS. Założenia integracji SAML a. System HIS jest odpowiedzialny za weryfikację uprawnień dostępu do portalu EHR dla konta lekarza żądającego wyświetlenia portalu EHR a. System HIS jest odpowiedzialny za komunikację i wystawianie wiadomości SAML, tzw. SAML Assertions do portalu EHR za pomocą protokołu SAML 2.0 przez połączenie HTTPS. Szczegółowe pola wiadomości będą uzgodnione pomiędzy firmą HIS a dostawcą rozwiązania EHR. Jako minimum przyjmuje się odbieranie numeru PESEL pacjenta do wyświetlenia, Imię i nazwisko lekarza żądającego, Numer zawodu lekarza żądającego. b. Dostawca systemu EHR dostarczy wymagane klucze dla dostawcy systemu HIS w celu integracji i szyfrowania połączenia i wiadomości. Będzie to klucz o długości minimum 2048 bitów dla pary kluczy publicznego/prywatnego RSA używanego do podpisania odpowiedzi SAML (ang. SAML Response) c. Otrzymany klucz prywatny będzie przetrzymywany w bezpiecznej lokalizacji w systemie HIS, po stronie serwera, nie klienta systemu HIS w celu izolacji od użytkowników. d. Klucz prywatny będzie używany do podpisywania wiadomości SAML przed wysłaniem żądania z systemu HIS do usługi SSO Portalu EHR e. Klient systemu HIS w celu audyty bezpieczeństwa będzie jednoznacznie wskazywał użytkownika i jego konto żądające otworzenia Portalu EHR (nie będzie tzw. systemu współdzielenia tego samego konta pomiędzy wieloma osobami). System EHR odłoży dane numeru PESEL pacjenta do wyświetlenia, Imię i nazwisko lekarza żądającego, Numer zawodu lekarza żądającego, Nazwę hosta i adres IP klienta HIS do repozytorium audytu w celu kontroli i administracji dostępem do danych osobowych. f. Wiadomości SAML będą szyfrowane do formatu base64 przed wysłaniem do usługi SSO Portalu EHR. 1. Przedstawić strukturę wiadomości SAML jej wysłanie do systemu EHR w celu demonstracji automatycznego otworzenia portalu EHR bez potrzeby logowania się i wyświetlenia regionalnego rekordu EHR pacjenta. 3. stworzenie wydarzenia w repozytorium wydarzeń audytu z danymi dostępu danych (wymienionymi w podpunkcie 2.6.e)

8 2. Integracja z zewnętrznymi systemami PACS L p Zapis System EHR musi mieć możliwość równoległego wyszukiwania badań w wielu źródłach DICOM, tzn. w przypadku, gdy użytkownik poprzez portal dla lekarza będzie wyszukiwał badanie o wybranym numerze DICOM Patient ID, system EHR wyśle zapytania DICOM Query do wszystkich skonfigurowanych węzłów DICOM i wyniki tych zapytań przedstawi jako jedną zbiorczą listę dla użytkownika. Wybranie jednego z wyników zapoczątkuje pobranie i wyświetlenie badania. Do prezen tacji [/N IE] Scenariusz prezentacji 1. Skonfigurować jedno źródło badań repozytorium obrazowe systemu EHR 2. Wykonać zapytanie o dostępne badania i zaprezentowa ć wyniki tylko z repozytorium obrazowego platfromy EHR dla wybranego pacjenta 3. Skonfigurować dwa źródła badań - repozytorium obrazowe plaftromy EHR oraz testowy system PACS 4. Wykonać zapytanie o dostępne badania i zaprezentowa ć wyniki tylko z repozytorium obrazowego platformy EHR oraz z testowego systemu PACS dla wybranego pacjenta. Pobrać i wyświetlić badania z testowego systemu PACS

9 Platforma EHR musi posiadać możliwość konfiguracji przez administratora systemu źródła pochodzenia lokalnego ID Pacjenta (DICOM Issuer Of Patient ID) na podstawie poniższych tagów oraz pól DICOM odbieranych obiektów / komunikacji DICOM - Issuer Of Patient ID, Requesting Service, Calling AE Title 1. Skonfigurować dla pól Issuer Of Patient ID,Requesting Service oraz Calling AE Title docelową wartość sekcji Issuer Of Patient dla pacjenta Test Issuer 2. Wysłać badanie z ustawioną przykładową, skonfigurowan ą wcześniej w pkt. 1, wartością pola DICOM Issuer Of Patient ID. Jako wynik oczekiwane jest zakwalifikowa ne badania i jego pacjenta do źródła ID Pacjenta o wartości Test Issuer 3. Wysłać badanie z ustawioną przykładową, skonfigurowan ą wcześniej w pkt. 1, wartością pola DICOM Requesting Service. Jako wynik oczekiwane jest zakwalifikowa ne badania i jego pacjenta do źródła ID Pacjenta o wartości Test Issuer 4. Wysłać badanie z przykładoweg o węzła DICOM o wybranym DICOM Calling AET. Jako wynik oczekiwane jest zakwalifikowa ne badania i jego pacjenta do źródła ID Pacjenta o wartości TestIssuer

10 System EHR musi mieć 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 systemu EHR wartościach Issuer Of Patient ID 1. Skonfigurować dla testowego węzła DICOM, wykonującego zapytanie DICOM Query (C-FIND) do systemu EHR, widoczność wszystkich pacjentów z badaniami obrazowymi w platformie EHR 2. Skonfigurować dla testowego węzła DICOM, wykonującego zapytanie DICOM Query (C-FIND) do systemu EHR, widoczność wszystkich pacjentów tylko o wartości DICOM Issuer of patient ID równej TestIssuer (patrz punkt 3.2)

11 Ze względu na objętość odbieranych danych oraz politykę bezpieczeństwa danych pacjenta, system EHR musi zapewniać spójność odbieranych danych DICOM z systemów PACS i niezaprzeczalność ich modyfikacji poprzez monitorowanie spójności plików z archiwum online (gdzie dane są zapisywane w momencie odbioru) i z archiwum nearline (gdzie dane są zapisywane do archiwizacji długoterminowej). W tym celu wymagane jest: a) generowanie i zapisywanie sumy kontrolnej MD5 każdego obieranego obrazu DICOM w momencie jego odbierania z węzła DICOM (podłączonego systemu PACS) b) w momencie przenoszenia badania do archiwum nearline, system EHR ma ponownie liczyć sumę kontrolną każdego obrazu DICOM do archiwizacji i porównywać je z sumą kontrolną MD5 zapisaną w momencie jego odbioru. Jeżeli wartości się nie zgadzają (plik został uszkodzony lub zmieniony), zadanie archiwizacji danego badania ma zostać wstrzymane i przekazane go kolejki błędów. c) w momencie zapisywania plików DICOM do archiwum nearline, razem z plikami DICOM ma zostać zapisany na dysku twardym plik zawierający nazwę pliku DICOM i jego sumę kontrolną. d) w momencie pobierania badania z archiwum nearline, poprzez żądanie DICOM C- MOVE z zewnętrznego węzła DICOM, system EHR ma ponownie liczyć sumę kontrolną każdego obrazu DICOM z archiwum nearline i porównywać je z sumą kontrolną MD5 zapisaną w momencie jego archiwizacji. Jeżeli wartości się nie zgadzają (plik został uszkodzony lub zmieniony), zadanie DICOM C-MOVE danego badania ma zostać wstrzymane i informacja ma zostać zapisana dla administratora systemu EHR Odbierane przez platformę EHR pliki DICOM mają być zapisywane do archiwum online oraz nearline poprzez protokół NFS. System EHR nie może ograniczać ilość volumenów nealine oraz i ich powierzchni. NIE 1. Wysłać badanie DICOM do systemu EHR, przedstawić kalkulację i zapis sumy kontrolnej pojedynczych obiektów DICOM 2. Uszkodzić wybrany plik DICOM, wysłać do archiwum nearline, zaprezentować wstrzymanie zadania i jego odłożenie do kolejki błędów 3. Uszkodzić pojedynczy plik DICOM w archiwum nearline, zasymulować próbę wysłania (DICOM C- MOVE) do wybranego węzła DICOM, zaprezentować wstrzymanie wysłania i zapisanie dla administratora systemu EHR informacji o błędzie

12 System EHR ma wspierać odbieranie i wysyłanie oraz archiwizację następujących klas DICOM oraz dodatkowych klas SOP. Załączyć DICOM Conformance Statement. Typ klasy DICOM UID Klasy DICOM Verification Computed Radiography Image Storage Digital X-Ray Image Storage Fo Presentatio Transfer danych Digital X-Ray Image Storage For Processing Digital Mammography X-Ray Image Storage For Presentation Digital Mammography X-Ray Image Storage For Processing Digital Intra-oral X-Ray Image Storage For Presentation Digital Intra-oral X-Ray Image Storage For Processing CT Image Storage Enhanced CT Image Storage Ultrasound Multi-frame Image Storage MR Image Storage Enhanced MR Image Storage Enhanced MR Color Image Storage MR Spectroscopy Storage Ultrasound Image Storage Enhanced US Volume Storage Secondary Capture Image Storage Multi-frame Single Bit Secondary Capture Image Storage Multi-frame Grayscale Byte Secondary Capture Image Storage Multi-frame Grayscale Word Secondary Capture Image Storage Multi-frame True Color Secondary Capture Image Storage lead ECG Waveform Storage General ECG Waveform Storage Ambulatory ECG Waveform Storage Hemodynamic Waveform Storage Cardiac Electrophysiology Waveform Storage Basic Voice Audio Waveform Storage General Audio Waveform Storage Arterial Pulse Waveform Storage Respiratory Waveform Storage Grayscale Softcopy Presentation State Storage Color Softcopy Presentation State Storage Pseudo-Color Softcopy Presentation State Storage Blending Softcopy Presentation State Storage XA / XRF Grayscale Softcopy Presentation State Storage X-Ray Angiographic Image Storage Enhanced XA Image Storage X-Ray Radiofluoroscopic Image Storage Enhanced XRF Image Storage X-Ray 3D Angiographic Image Storage X-Ray 3D Craniofacial Image Storage Breast Tomosynthesis Image Storage Nuclear Medicine Image Storage Raw Data Storage Spatial Registration Storage Spatial Fiducials Storage Deformable Spatial Registration Storage Segmentation Storage Real World Value Mapping Storage VL Endoscopic Image Storage Video Endoscopic Image Storage VL Microscopic Image Storage Video Microscopic Image Storage VL Slide-Coordinates Microscopic Image Storage VL Photographic Image Storage odebranie, archiwizację i wysyłania następujących klas DICOM: Voice Audio Waveform Storage , Grayscale Softcopy Presentation State Storage Encapsulated PDF Storage Key Object Selection Document Basic Text SR Comprehensive SR Video Photographic Image Storage

13 System EHR ma wspierać odbieranie i wysyłanie oraz archiwizację następujących typów kodowania obiektów DICOM (tzw. DICOM Transfer Syntax): Wymagany Transfer Syntax UID Typy klas SOP Explicit VR Little Endian Nie obiekty wideo JPEG Proces 1, baseline, lossy (8 bit) Tylko obrazy JPEG Process 2,4, extended lossy (12 bit) JPEG Process 14, lossless, Non- Hierarchical JPEG Process 14, selection value 1, lossless, Non-Hierarchical, First-Order Prediction JPEG 2000 Image Compression (Lossless Only) Tylko obrazy Tylko obrazy Tylko obrazy Tylko obrazy JPEG 2000 Image Compression Tylko obrazy RLE Lossless Tylko obrazy MPEG2 Main Main Level MPEG-4 AVC/H.264 High Profile / Level 4.1 MPEG-4 AVC/H.264 BD compatible High Profile / Level Tylko obiekty wideo Tylko obiekty wideo Tylko obiekty wideo 1. Wysłać przykładowe badanie DICOM, używając DICOM transfer syntaxu JPEG 2000 Image Compression ( lub ) oraz MPEG-2 ( ) i MPEG-4 ( ) 2. Przedstawić odbieranie, archiwizację i wysyłanie tych obiektów DICOM

14 5. Kontrola dostępu do portalu dla lekarza Lp Zapis 4.1. Administrator portalu dla lekarza musi mieć możliwość konfiguracji polityki haseł, uwzględniając minimum następujące parametry: - wymuszanie wygasania hasła po skonfigurowanej ilości dni (np. po 90 dniach) - umożliwienie zmiany hasła po upłynięciu skonfigurowanej ilości dni (np. zmiana hasła możliwa po 90 dniach od jest ustawienia) - wymuszanie minimalnej ilości znaków - wymuszanie przetrzymywania historii poprzednich haseł użytkownika (np. uniemożliwienie ustawienia nowego hasła identycznego jak jedno z ostatnich 6 użytych haseł) 4.2. Administrator portalu dla lekarza musi mieć możliwość konfiguracji wymaganej siły hasła, uwzględniając minimum następujące parametry: - minimalna długość hasła to 50% punktów za siłę hasła - kolejne 50% punktów jest przyznawane na podstawie: Każdego dodatkowego znaku powyżej minimalnej ilości znaków Weryfikacji czy są równocześnie użyte znaki liczbowe oraz tekstowej Weryfikacji czy są równocześnie użyte znaki specjalne (włączają spację) - punkty są odejmowane, jeżeli hasło istnieje w predefiniowanym słowniku haseł - hasło jest odrzucane, jeżeli hasłem jest nazwa użytkownika Poprzez znaki specjalne Zamawiający rozumie następujące symbole: ^ = ;@ )], ` & {" #- > ~ *[ ' $ _\?! (} < % + :/ 4.3. Administrator portalu dla lekarza musi mieć możliwość konfiguracji aktywacji funkcjonalności resetu hasła dla użytkowników portalu, który będzie aktywowany w przypadku: - podany login użytkownika w portalu istnieje - użytkownik podał podczas konfiguracji swojego konta odpowiedź na sekretne pytanie - użytkownik podał podczas konfiguracji swojego konta swój adres Administrator musi mieć możliwość tworzenia własnej listy predefiniowanych sekretnych pytań dla użytkowników (np. W jakim mieście urodziła się Twoja matka? ") Do prezentacji [/NIE] Scenariusz prezentacji przykładową konfigurację i działanie: - wymuszania wygasania hasła po skonfigurowanej ilości dni - umożliwienia zmiany hasła po upłynięciu skonfigurowanej ilości dni - wymuszania minimalnej ilości znaków - wymuszanie przetrzymywania historii poprzednich haseł użytkownika przykładową konfigurację i działanie możliwości konfiguracji wymaganej siły hasła, uwzględniając wymagane parametry przykładową konfigurację i działanie aktywacji funkcjonalności resetu hasła dla użytkowników portalu, który będzie aktywowany w wymaganych przypadkach oraz tworzenia własnej listy predefiniowanych sekretnych pytań dla użytkowników

15 4.4. Administrator portalu dla lekarza musi mieć możliwość konfiguracji automatycznego blokowania konta na podstawie ilości nieudanych prób zalogowań (np. po 5 nieudanych próbach zalogowania). Inne możliwe do skonfigurowania parametry blokady to: - reset licznika nieudanych prób zalogowania po skonfigurowanym czasie (np. po 30 minutach) - w przypadku blokady konta, skonfigurowanie czasu trwania blokady (np. na 30 min) - w przypadku blokady konta, ustawienia stałej blokady konta, możliwej do usunięcia tylko po interwencji administratora portalu 4.5. Administrator portalu dla lekarza musi mieć możliwość konfiguracji automatycznego blokowania konta po ustawionym czasie nieaktywności konta (np. po upłynięciu 45 dni od czasu ostatniego zalogowania) 4.6. Administrator portalu dla lekarza musi mieć możliwość konfiguracji zakresu czasu, kiedy użytkownicy mogą się zalogować, z podziałem na dni tygodnia (Poniedziałek, Wtorek itd.) i godziny (cały dzień, od 6 rano do 1 w nocy itp.) przykładową konfigurację i działanie automatycznego blokowania konta na podstawie ilości nieudanych prób zalogowań oraz innych wymaganych do skonfigurowania parametrów blokady przykładową konfigurację i działanie automatycznego blokowania konta po ustawionym czasie nieaktywności konta przykładową konfigurację i działanie konfiguracji zakresu czasu, kiedy użytkownicy mogą się zalogować, z podziałem na dni tygodnia i godziny, zgodnie wymaganiem

16 6. Kontrola dostępu do rekordu EHR pacjenta (dokumentów, wyników, informacji) Lp Zapis 5.1.System EHR musi umożliwiać kontrolę dostępu do rekordu EHR pacjenta (dokumentów, wyników, informacji) poprzez portal dla lekarza uwzględniając skonfigurowaną rolę użytkownika w systemie. (np. lekarz klinicysta, lekarz rodzinny, lekarz prowadzący) 5.2.System EHR musi umożliwiać kontrolę dostępu do danych pacjenta (dokumentów, wyników, informacji) poprzez portal dla lekarza uwzględniając typ dokumentu EHR (np. wynik laboratoryjny, opis radiologiczny, epikryza, wynik badania psychologicznego) 5.3.System EHR musi umożliwiać kontrolę dostępu do pacjenta poprzez portal dla lekarza uwzględniając politykę zakresu czasu informacji, min. odblokowanie dostępu do pacjenta na jeden dzień przed i jeden dzień po planowanej wizycie pacjenta. Do prezentacji [/NIE] Scenariusz prezentacji przykładową konfigurację i działanie kontroli dostępu do rekordu EHR poprzez portal dla lekarza uwzględniającą skonfigurowaną rolę lekarza w systemie. działanie odebrania i przyznania dostępu do dokumentów, wyników, informacji pacjenta na podstawie wymaganych kryteriów przykładową konfigurację i działanie kontroli dostępu do rekordu EHR poprzez portal dla lekarza uwzględniając typ dokumentu EHR (np. wynik laboratoryjny, opis radiologiczny, epikryza, wynik badania psychologicznego) działanie odebrania i przyznania dostępu do dokumentów, wyników, informacji pacjenta na podstawie wymaganych kryteriów przykładową konfigurację i działanie kontroli dostępu do rekordu EHR poprzez portal dla lekarza uwzględniając zakres czasu przed i po wizycie. działanie odebrania i przyznania dostępu do dokumentów, wyników, informacji pacjenta na podstawie wymaganych kryteriów

17 5.4.System EHR musi umożliwiać kontrolę dostępu do rekordu EHR pacjenta (dokumentów, wyników, informacji) poprzez portal dla lekarza uwzględniając miejsce zalogowania się użytkownika (na podstawie adres u IP) przykładową konfigurację i działanie kontroli dostępu do rekordu EHR uwzględniające miejsce zalogowania się użytkownika (na podstawie adresu IP) działanie odebrania i przyznania dostępu do dokumentów, wyników, informacji pacjenta na podstawie wymaganych kryteriów 5.5.System EHR musi umożliwiać kontrolę dostępu do rekordu EHR pacjenta (dokumentów, wyników, informacji) poprzez portal dla lekarza uwzględniając określoną przez administratora portalu relację użytkownika (lekarza) z pacjentem (np. lekarz klinicysta, lekarz rodzinny, lekarz prowadzący), wraz z podaniem daty rozpoczęcia i zakończenia obowiązywania tej relacji. Administrator portalu może też pozwolić podać relację z pacjentem przez użytkownika (lekarza) podczas odblokowywania dostępu do zaplombowanego rekordu EHR patrz wymóg System EHR musi umożliwiać oznaczanie odebranych wyników z systemów HIS znacznikami typu informacji dowolnie definiowanymi (np. "Pacjent VIP", "Alergie","Diabetyk","Zdrowie psychiczne", "Zdrowie seksualne","wynik HIV" itp.). Platfroma EHR musi umożliwiać oznaczanie odebranego pojedyńczego wyniku z systemu HIS wieloma znacznikami. Na podstawie typu informacji, system EHR musi umożliwiać tworzenie zasady dostępu do zdefiniowanego typu informacji na poziomach określonych w punkcie 5.7 przykładową konfigurację i działanie kontroli dostępu do rekordu EHR poprzez portal dla lekarza uwzględniającą określoną relację użytkownika z pacjentem przez administratora w systemie. Przedstawić przykładową konfigurację i działanie zezwolenia na podanie relacji z pacjentem przez użytkownika (lekarza) podczas odblokowywania dostępu do zaplombowanego rekordu EHR (wymóg z pkt. 5.7) działanie odebrania i przyznania dostępu do dokumentów, wyników, informacji pacjenta na podstawie wymaganych kryteriów przykładową konfigurację i działanie oznaczania odebranych wyników z systemów HIS znacznikami typu informacji dowolnie definiowanymi (np. "Pacjent VIP", "Alergie","Diabetyk","Zdrowie psychiczne", "Zdrowie seksualne","wynik HIV" itp.). oznaczanie odebranego pojedynczego wyniku z systemu HIS wieloma znacznikami. działanie odebrania i przyznania dostępu do dokumentów, wyników, informacji pacjenta na podstawie wymaganych kryteriów

18 5.7.System EHR musi umożliwiać definiowanie minimum następujących poziomów dostępu do odebranego typu informacji oraz do zdefiniowanego pacjenta (np. pacjent VIP) dla użytkowników portalu dla lekarza: - Brak dostępu - dana informacja nie będzie widoczna w liście dokumentów /wyników oraz w wynikach wyszukiwania w portalu dla lekarza. Użytkownik portalu nie będzie miał informacji, że rekord EHR jest ukryty - Zablokowany - dana informacja będzie widoczna w liście dokumentów /wyników oraz w wynikach wyszukiwania w portalu dla lekarza. Użytkownik portalu nie będzie mógł wyświetlić informacji z rekordu EHR. - Zaplombowany - dana informacja będzie widoczna w liście dokumentów /wyników oraz w wynikach wyszukiwania w portalu dla lekarza. Użytkownik portalu będzie mógł wyświetlić informacji z rekordu EHR tylko po podaniu predefiniowanego przez administratora portalu powodu próby dostępu do zaplombowanego rekordu EHR - Pełny dostęp - dana informacja będzie widoczna w liście dokumentów /wyników oraz w wynikach wyszukiwania w portalu dla lekarza. Użytkownik portalu będzie mógł wyświetlić informacje z rekordu EHR - Odsłoń zaplombowane - dana informacja nie będzie widoczna w liście dokumentów /wyników oraz w wynikach wyszukiwania w portalu dla lekarza. Użytkownik portalu otrzyma informację, że do części wyszukanych wyników nie ma dostępu i będzie mógł je odsłonić i wyświetlić informacje z rekordu EHR tylko po podaniu predefiniowanego przez administratora portalu powodu próby dostępu do zaplombowanego rekordu EHR Administrator portalu dla lekarza musi mieć możliwość konfiguracji zakresu czasu w którym odplombowane przez użytkownika portalu rekordy EHR są dostępne, nim będzie ponownie wymagane podanie powodu dostępu (np. 15 minut) przykładową konfigurację i działanie wymaganych poziomów dostępu do odebranego typu informacji oraz do zdefiniowanego pacjenta (np. pacjent VIP) dla użytkowników portalu dla lekarza: - braku dostępu - zablokowania dostępu - zaplombowania dostępu - odsłonięcia zaplombowanego dostępu - pełnego dostępu Oraz działania konfiguracji zakresu czasu w którym odplombowane przez użytkownika portalu rekordy EHR są dostępne, nim będzie ponownie wymagane podanie powodu dostępu (np. 15 minut)

19 7. Funkcjonalności portalu dla lekarza L p Zapis Portal musi działać na minimum następujących przeglądarkach WWW dla stacji typu desktop: - Google Chrome, aktualna wersja - Internet Explorer, minimum od wersji 7 - Mozilla Firefox, aktualna wersja - Safari, minimum wersja 5.x Portal w celu wyświetlania danych klinicznych (wyniki tekstowe, laboratoryjne, wykresy wyników laboratoryjnych, dokumenty) oraz danych obrazowych (obrazy TK, MR, video endoskopia itd) nie wymaga instalacji lub pobierania żadnych plug-inów i dodatkowych aplikacji na stacji klienckiej (np. ActiveX, Java Framework,.NET itd.) Portal musi działać na minimum następujących przeglądarkach WWW dla urządzeń mobilnych (tablety, smartfony): - Google Chrome lub FireFox, aktualna wersja dla urządzeń z OS Google Android - Safari, minimum wersja 5.x dla urządzeń z OS Apple ios Portal w celu wyświetlania danych klinicznych (tekst, wyniki laboratoryjne, wykresy wyników laboratoryjnych, dokumenty) oraz danych obrazowych (obrazy TK, MR, video endoskopia itd) nie wymaga instalacji lub pobierania żadnych plug-inów i dodatkowych aplikacji dla urządzeń mobilnych Do prezenta cji [/NI E] Scenariusz prezentacji Zademonstro wać działanie portalu na przeglądarce Google Chrome, IE oraz FireFox wraz z wyświetlenie m badań TK, MR i filmu video z endoskopii) Zademonstro wać działanie portalu na tablecie z OS Android oraz ios wraz z wyświetlenie m badań TK, MR i filmu video z endoskopii, tekstu, wyników laboratoryjny ch, wykresów wyników laboratoryjny ch, dokumentów pacjenta Użytkownik ma mieć możliwość wyświetlenia pojedyńczej strony z podsumowaniem informacji klinicznych o pacjencie, które zawiera minimum następujące informacje: - Dane demograficzne pacjenta: Inne identyfikatory pacjenta, dane demograficzne, osoby kontaktowe - Listę rozpoznanych alergii pacjenta: Typ alergii (alergia na leki, czynniki środowiskowe, jedzenie), reakcja alergiczna, data kiedy alergia została wykryta - Historia wizyt pacjenta w placówkach w regionie: Data przyjęcia i wypisu, Diagnoza w momencie przyjęcia, Typ wizyty (ambulatoryjna, pacjenta hospitalizowany, SOR), dane lekarza przyjmującego, miejsce przyjęcia pacjenta - Listę rozpoznanych problemów medycznych pacjenta: Diagnoza w momencie wypisu lub podczas wizyty ambulatoryjnej z odpowiadającym kodem ICD-10 Zademonstro wać spełnienie wymogu wyświetlenia pojedynczej strony z podsumowani em informacji klinicznych o pacjencie, które zawiera wymagane informacje Informacje te mają być zagregowane razem, bez względu z którego systemu HIS z którego zostały wysłane.

20 Dotyczy funkcjonalności z punktu Użytkownik ma mieć możliwość eksportowania podsumowania informacji klinicznych o pacjencie w formacie PDF lub XML lub wydruku na drukarce papierowej. Użytkownik ma mieć możliwość wyboru, które dane mają zostać załączone do podsumowania (Lista alergii, historia wizyt, lisy rozpoznanych problemów medycznych) i z jakiego zakresu czasu W przypadku eksportowania pliku do formatu PDF lub wydruku na drukarce papierowej, użytkownik musi mieć możliwość wydruku podsumowania informacji klinicznych o pacjencie z konfigurowalnymi nagłówkami, stopkami oraz znacznikami (ang. watermark) oraz z informacjami: data i czas wydruku, źródło wydruku, informacje o użytkowniku oraz informacje o oraz zdefiniowaną przez administratorów EHR informację o wymaganej procedurze zachowania poufności danych medycznych Użytkownik ma mieć możliwość wyświetlenia pojedynczej strony z widokiem historii EHR w funkcji czasu. Tzn.: - w osi X musi być dostępna skala czasowa data wydarzenia, wyniku lub stworzenia dokumentu - w osi Y musi być dostępna kategoria dokumentu, min: wizyta w placówce w rozbiciu na wizytę ambulatoryjną, hospitalizację, SOR wynik laboratoryjny w rozbiciu na typ, np. wynik badania biochemicznego, hematologicznego, mikrobiologicznego itd. epikryza z karty informacyjnej z leczenia szpitalnego opisy badań radiologicznych oraz inne kategorię dokumentów, załączonych przez użytkowników Na wykresie, jako punkty wykresu mają być umieszczone poszczególne wyniki. Po najechaniu na dany punkt, portal ma wyświetlić szczegółową datę stworzenia dokumentu, jego kategorię oraz imię i nazwisko autora oraz link do otworzenia dokumentu w portalu. Wykres ma mieć możliwość automatycznej zmiany skali czasowej przez użytkownika, min. cały zakres historii EHR pacjenta, ostatnie 3 lata, rok, kwartał, miesiąc, tydzień, 3 dni. Wykres ma mieć możliwość płynnej zmiany skali czasowej przez użytkownika. Po płynnej lub automatycznej zmianie skali czasowej przez użytkownika i wybraniu i wyświetleniu wybranego wyniku lub dokumentu, po powrocie przez użytkownika do widoku historii EHR w funkcji czasu, ostatnio wybrana płynnie lub automatycznie zmiana skali czasu ma być zachowana (ustawiona). Portal musi umożliwiać wydruk wymaganego wykresu, po wcześniejszym nadaniu uprawnienia użytkownikowi przez administratora portalu EHR Zademonstro wać spełnienie wymogu zgodnie z zapisami oraz konfigurację nagłówków, stopek oraz znaczników (ang. watermark) oraz zdefiniowaną przez administrator ów EHR informację o wymaganej procedurze zachowania pounfności danych medycznych Zademonstro wać spełnienie wymogu zgodnie z zapisami

21 Użytkownik ma mieć możliwość wyświetlenia rozwijalnego drzewka z widokiem historii EHR w funkcji kategorii. Tzn.: - jako główne gałęzie drzewka musi być dostępna kategoria dokumentu, min: wynik laboratoryjny w rozbiciu na typ, np. wynik badania biochemicznego, hematologicznego, mikrobiologicznego itd. epikryza z karty informacyjnej z leczenia szpitalnego opisy badań radiologicznych oraz inne kategorię dokumentów, załączonych przez użytkowników Jako podgałęzie, mają być umieszczone poszczególne wyniki w formacie - datę stworzenia dokumentu - nazwa dokumentu. Wybranie danego tytułu dokumentu ma otwierać dokument w portalu. Portal ma zapamiętywać wyświetlone już wcześniej wyświetlone przez użytkownika w.w wyniki pacjenta. Jeżeli pojawił się nowy wynik dla pacjenta w danej kategorii, portal musi w czytelny sposób wskazywać który wynik nie był nigdy przeglądany przez aktualnie zalogowanego użytkownika Użytkownik musi mieć możliwość następującej prezentacji wyników laboratoryjnych w formie tabelarycznej, zawierającej: - w wierszach badany parametr (WBC, RBC, Hb itp.), zaś jako kolumny wartości z badań. Każda kolumna musi być oznaczona datą wyniku oraz źródłem wyniku (placówką) oraz numerem badania w czasie (1 dla najstarszego, największa wartość dla najnowszego wyniku). - wybranie danego wyniku wyświetla zakres referencyjny wyniku - zaznaczenie jednego lub wielu parametrów wyniku laboratoryjnego (np. WBC i RBC) pozwala wybrać opcję rysowania wykresu wyników w czasie, opisanych w punkcie 6.8 Użytkownik musi mieć możliwość następującej prezentacji wyników laboratoryjnych w formie wykresu, zawierającego: - w osi X musi być dostępna skala czasowa zakres dat - w osi Y musi być dostępna typ parametru (np. WBC oraz RBC), min: Na wykresie, jako punkty wykresu mają być umieszczone poszczególne wyniki. Po najechaniu na dany punkt, portal ma wyświetlić szczegóły wyniku jak datę i godzinę stworzenia wyniku, nazwę źródła wyniku (placówki) oraz zakres referencyjny wyniku. Wykres ma również przedstawiać zakres referencyjny rysowanych wyników. Użytkownik musi mieć możliwość załączania dokumentów (plików ) do historii badań pacjenta, określając jego: - autora - datę stworzenia - ID wydarzenia - typ specjalizacji (np. kardiologia, pulmonologia, neurologia) - podkategorię (np. notatka, skan) - tytuł dokumentu Administrator portalu EHR ma mieć możliwość konfiguracji, które z w.w. atrybutów dokumentu są wymagane oraz jaki maja format (swobodnego tekstu, daty, predefiniowanej listy) Załączone dokumenty są prezentowane zarówno w drzewku dokumentów EHR pacjenta (pkt. 6.6) jak i historii EHR w czasie (pkt. 6.5) Portalu dla lekarza musi umożliwiać użytkownikowi wyszukanie pacjenta za pomocą: - imienia i nazwiska pacjenta - lokalnego ID w systemie HIS - za pomocą numeru PESEL - płci pacjenta Administrator portalu EHR ma mieć możliwość konfiguracji jaka jest maksymalna ilość zwracanych wyników Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami

22 Portalu dla lekarza musi zapamiętywać historię ostatnio wyszukanych pacjentów z rozbiciem na zakres czasu min. wyszukani dzisiaj, w ostatnich 7 dniach, ostatnie 4 tygodnie. Przy historii wyświetlonych pacjentów mają bezpośrednio znajdować się skróty do wyświetlenia podsumowania pacjenta (pkt 6.3) lub wyświetlenia wykresu historii EHR pacjenta w czasie (punkt 6.5) Portal udostępnia następujące podstawowe narzędzia dla wyników obrazowych: - pozwala wyświetlić jednocześnie min. 1, 2, 4, serii badania - pozwala wyświetlić jednocześnie min. 2 różne serie tego samego badania - pozwala wyświetlić jednocześnie min. różne badania tego samego pacjenta (np badanie TK i badanie MR obok siebie) - posiada funkcję powiększania stopniowego (obsługa pokrętłem scroll myszy), lupy, powiększenie na cały dostępny ekran obszaru wyświetlania - pomiar kątów - pomiar odległości pomiędzy dwoma punktami na obrazie Portal udostępnia następujące zaawansowane narzędzia dla wyników obrazowych - Pomiar czasu w badaniach USG pomiędzy dwoma punktami na wykresie badania - Funkcja wyświetlenia/ukrycia adnotacji wprowadzonych do obrazów badania w systemie PACS - Funkcja jednoczesnego przewijania obrazów wielu wyświetlanych serii badania pacjenta - Funkcja wyświetlania linii referencyjnych na innych płaszczyznach podczas przewijania obrazów z wybranej serii badania - Funkcja wyświetlenia topogramu dla badań TK i MR - Automatyczne łączenie dwóch lub więcej serii badania na podstawie unikatowej referencji ramki obrazu - Funkcja obrotu obrazu 90 - Funkcja odbicia obrazu (strona prawa / strona lewa) - Inwersja pozytyw/nagatyw w obrazie badania - Funkcja powrotu do oryginalnej (dostępnej w systemie PACS) postaci obrazu Portal udostępnia funkcję przeglądarki animacji dla wyników obrazowych, funkcje min.: - ustawienia prędkości animacji, - ustawienie zakresu obrazów do animacji, - możliwość ustawienia biegu animacji w pętli od pierwszej do ostatniej klatki oraz od pierwszej poprzez ostatnią do pierwszej klatki (w wybranym zakresie klatek) Portal udostępnia funkcję wyłączenia by wyświetlane były wyłącznie obrazy oznaczone w systemie PACS jako kluczowe" przez lekarza radiologa (zawierające zmiany chorobowe) Portal ma funkcję wykonywanie rekonstrukcji MIP/MPR/CPR/3D bez braku konieczności instalowania na komputerze klienta jakichkolwiek aplikacji lub dodatków (np. plugin) do obsługiwanych przeglądarek internetowych (renderowanie po stronie serwera) Minimalne narzędzia dla lekarza to: Reformatowanie do widoków typu Axial, Coronal, Sagittal Reformatted oraz wolumetrycznego widoku 3D Możliwość ustawienia grubości warstw rekonstrukcji, z opcjami projekcji Maximum, Minimum, Average Image Projection (MIP, MINIP,AVGIP) Podstawowe pomiary wybranego punktu z jednostkami Hounsfield'a dla badań TK lub intensywnością sygnały dla badań MR. Miarka odległości pomiędzy dwoma punktami oraz pomiar wybranego obszaru (eliptycznego lub dowolnie narysowanego) z informacjami o polu powierzchni i średniej wartości jednostek HU dla badań TK Możliwość zapisania zrzutu ekranu wykonanej rekonstrukcji do pliku graficznego (np. JPEG) Możliwość zmiany funkcji transferu (prezentacji) rekonstrukcji 3D: Minimum MIP, Skóra, Płuca, Kości, Aorta Zmiana obszaru rekonstrukcji oraz kąta w rzutach Axial, Coronal, Sagittal powoduje zmianę obszaru rekonstrukcji 3D NIE Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami Zademonstro wać spełnienie wymogu zgodnie z zapisami

23 Portal wyświetla (w przypadku audio odtwarza) następujące, zaawansowane obiekty DICOM nie wymagając instalacji lub pobierania żadnych plug-inów i dodatkowych aplikacji na stacji klienckiej (np. ActiveX, Java Framework,.NET itd.): Typ klasy DICOM UID Klasy DICOM Computed Radiography Image Storage Digital X-Ray Image Storage For Presentation Digital X-Ray Image Storage For Processing Digital Mammography X-Ray Image Storage For Presentation Digital Mammography X-Ray Image Storage For Processing Digital Intra-oral X-Ray Image Storage For Presentation Digital Intra-oral X-Ray Image Storage For Processing CT Image Storage Enhanced CT Image Storage Ultrasound Multi-frame Image Storage MR Image Storage Enhanced MR Image Storage MR Spectroscopy Storage Enhanced MR Color Image Storage Ultrasound Image Storage Secondary Capture Image Storage Multi-frame Single Bit Secondary Capture Image Storage Multi-frame Grayscale Byte Secondary Capture Image Storage Multi-frame Grayscale Word Secondary Capture Image Storage Multi-frame True Color Secondary Capture Image Storage Breast Tomosynthesis Image Storage Basic Voice Audio Waveform Storage Grayscale Softcopy Presentation State Storage Color Softcopy Presentation State Storage Pseudo-Color Softcopy Presentation State Storage X-Ray Angiographic Image Storage Enhanced XA Image Storage X-Ray Radiofluoroscopic Image Storage Enhanced XRF Image Storage Breast Tomosynthesis Image Storage Intravascular Optical Coherence Tomography Image Storage - For Presentation Nuclear Medicine Image Storage VL Endoscopic Image Storage Video Endoscopic Image Storage VL Microscopic Image Storage Video Microscopic Image Storage VL Slide-Coordinates Microscopic Image Storage VL Photographic Image Storage Video Photographic Image Storage Ophthalmic Photography 8 Bit Image Storage Ophthalmic Photography 16 Bit Image Storage Basic Text SR Enhanced SR Comprehensive SR Key Object Selection Document X-Ray Radiation Dose SR Encapsulated PDF Storage Positron Emission Tomography Image Storage Zademonstro wać wyświetlanie: 1 Multi-frame True Color lub Grayscale Byte / Word Secondary Capture Image Storage 2 Breast Tomosynthesi s Image Storage 3 Basic Voice Audio Waveform Storage 4 Basic Text SR Enhanced SR 5 Key Object Selection Document 6 Encapsulated PDF Storage 7 Video Endoscopic Image Storage