plik pdf - bip.kujawsko

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
Historia wizyt pacjenta w regionie (HL7 ADT)
o
Lista problemów zdrowotnych pacjenta (HL7 PPR)
•
o
Alergie pacjenta (HL7 ADT)
o
Wyniki laboratoryjne (HL7 ORU)
o
Epikryza z karty informacyjnej z leczenia szpitalnego (HL7 MDM)
25 podłączonych systemów PACS
o
maksymalnie 1 million badań DICOM rocznie
o
maksymalnie 10 millionów obrazów DICOM rocznie
o
maksymalnie 20 TB danych DICOM rocznie w formacie DICOM LEI
o
maksymalnie 30 000 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.
System musi spełniać następujące warunki obligatoryjne:
Lp
Zapis
Do prezentacji
[TAK/NIE]
Scenariusz prezentacji
próbki
oprogramowania
TAK
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
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)
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.
Zademonstrować
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.
Zademonstrować
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
TAK
1.3. Szyna integracyjna EHR ma spełniać profil IHE Patient Identifier Crossreferencing jako aktor Consumer. Załączyć certyfikat IHE.
Zaprezentować opisany
workflow:
Dodatkowo, system EHR ma spełnić wymagania następującego workflow’:
1. Wysłać badanie nr. 1
z ID nr.1 do systemu
EHR
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.
2. Wysłać badanie nr. 2
z ID nr.2 do systemu
EHR
TAK
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
1. Integracja z zewnętrznymi systemami HIS
Lp
Zapis
Do
prezentacji
[TAK/NIE]
Scenariusz prezentacji
TAK
Zademonstrować 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
TAK
Zademonstrować 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
TAK
Zademonstrować 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
2.1.System EHR musi odebrać, archiwizować i udostępniać historię wizyt oraz
hospitalizacji pacjenta dla placówek medycznych w regionie KujawskoPomorskim.
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
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 KujawskoPomorskim
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
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 KujawskoPomorskim
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
używając do odczytywania tych informacji segmentu AL1.
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
TAK
Zademonstrować 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
TAK
Zademonstrować 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
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.
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.
a.
b.
System HIS jest odpowiedzialny za weryfikację uprawnień
dostępu do portalu EHR dla konta lekarza żądającego
wyświetlenia portalu EHR
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.
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 2.0.
2.
Zademonstrować 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.
Zademonstrować
stworzenie
wydarzenia w
repozytorium
wydarzeń audytu z
danymi dostępu
danych
(wymienionymi w
podpunkcie 2.6.e)
TAK
2. Integracja z zewnętrznymi systemami PACS
L
p
Zapis
Do
prezen
tacji
[TAK/N
IE]
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.
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
TAK
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”
TAK
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
TAK
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)
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 CMOVE 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
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 CMOVE) do
wybranego węzła
DICOM,
zaprezentować
wstrzymanie
wysłania i zapisanie
dla administratora
systemu EHR
informacji o błędzie
TAK
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
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
1.2.840.10008.1.1
Transfer danych
Computed Radiography Image Storage
1.2.840.0008.5.1.4.1.1.1
Digital X-Ray Image Storage – Fo Presentatio
1.2.840.10008.5.14.1.1.1.1
Digital X-Ray Image Storage – For Processing
1.2.840.10008.5.1.4.1.1.1.1.1
Digital Mammography X-Ray Image Storage – For
Presentation
1.2.840.10008.5.1.4.1.1.1.2
Digital Mammography X-Ray Image Storage – For Processing
1.2.840.10008.5.1.4.1.1.1.2.1
Digital Intra-oral X-Ray Image Storage – For Presentation
1.2.840.10008.5.1.4.1.1.1.3
Digital Intra-oral X-Ray Image Storage – For Processing
1.2.840.10008.5.1.4.1.1.1.3.1
CT Image Storage
1.2.840.10008.5.1.4.1.1.2
Enhanced CT Image Storage
1.2.840.10008.5.1.4.1.1.2.1
Ultrasound Multi-frame Image Storage
1.2.840.10008.5.1.4.1.1.3.1
MR Image Storage
1.2.840.10008.5.1.4.1.1.4
Enhanced MR Image Storage
1.2.840.10008.5.1.4.1.1.4.1
Enhanced MR Color Image Storage
1.2.840.10008.5.1.4.1.1.4.3
MR Spectroscopy Storage
1.2.840.10008.5.1.4.1.1.4.2
Ultrasound Image Storage
1.2.840.10008.5.1.4.1.1.6.1
Enhanced US Volume Storage
1.2.840.10008.5.1.4.1.1.6.2
Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7
Multi-frame Single Bit Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7.1
Multi-frame Grayscale Byte Secondary Capture Image
Storage
1.2.840.10008.5.1.4.1.1.7.2
Multi-frame Grayscale Word Secondary Capture Image
Storage
1.2.840.10008.5.1.4.1.1.7.3
Multi-frame True Color Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7.4
12-lead ECG Waveform Storage
1.2.840.10008.5.1.4.1.1.9.1.1
General ECG Waveform Storage
1.2.840.10008.5.1.4.1.1.9.1.2
Ambulatory ECG Waveform Storage
1.2.840.10008.5.1.4.1.1.9.1.3
Hemodynamic Waveform Storage
1.2.840.10008.5.1.4.1.1.9.2.1
Cardiac Electrophysiology Waveform Storage
1.2.840.10008.5.1.4.1.1.9.3.1
Basic Voice Audio Waveform Storage
1.2.840.10008.5.1.4.1.1.9.4.1
General Audio Waveform Storage
1.2.840.10008.5.1.4.1.1.9.4.2
Arterial Pulse Waveform Storage
1.2.840.10008.5.1.4.1.1.9.5.1
Respiratory Waveform Storage
1.2.840.10008.5.1.4.1.1.9.6.1
Grayscale Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.1
Color Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.2
Pseudo-Color Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.3
Blending Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.4
XA / XRF Grayscale Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.5
X-Ray Angiographic Image Storage
1.2.840.10008.5.1.4.1.1.12.1
Enhanced XA Image Storage
1.2.840.10008.5.1.4.1.1.12.1.1
X-Ray Radiofluoroscopic Image Storage
1.2.840.10008.5.1.4.1.1.12.2
Enhanced XRF Image Storage
1.2.840.10008.5.1.4.1.1.12.2.1
X-Ray 3D Angiographic Image Storage
1.2.840.10008.5.1.4.1.1.13.1.1
X-Ray 3D Craniofacial Image Storage
1.2.840.10008.5.1.4.1.1.13.1.2
Breast Tomosynthesis Image Storage
1.2.840.10008.5.1.4.1.1.13.1.3
Nuclear Medicine Image Storage
1.2.840.10008.5.1.4.1.1.20
Raw Data Storage
1.2.840.10008.5.1.4.1.1.66
Spatial Registration Storage
1.2.840.10008.5.1.4.1.1.66.1
Spatial Fiducials Storage
1.2.840.10008.5.1.4.1.1.66.2
Deformable Spatial Registration Storage
1.2.840.10008.5.1.4.1.1.66.3
Segmentation Storage
1.2.840.10008.5.1.4.1.1.66.4 TAK
Real World Value Mapping Storage
1.2.840.10008.5.1.4.1.1.67
VL Endoscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.1
Video Endoscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.1.1
VL Microscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.2
Video Microscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.2.1
VL Slide-Coordinates Microscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.3
VL Photographic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.4
1.
Zademonstrować
odebranie,
archiwizację i
wysyłania
następujących klas
DICOM:
Voice Audio
Waveform Storage
1.2.840.10008.5.1.4.
1.1.9.4.1,
Grayscale Softcopy
Presentation State
Storage
1.2.840.10008.5.1.4.
1.1.11.1
Encapsulated PDF
Storage
1.2.840.10008.5.1.4.
1.1.104.1
Key Object Selection
Document
1.2.840.10008.5.1.4.
1.1.88.59
Basic Text SR
1.2.840.10008.5.1.4.
1.1.88.11
Comprehensive SR
1.2.840.10008.5.1.4.
1.1.88.33
Video Photographic
Image Storage
1.2.840.10008.5.1.4.
1.1.77.1.4.1
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 Endian1
1.2.840.10008.1.2.1
Nie obiekty
wideo
JPEG Proces 1, baseline, lossy (8 bit)
1.2.840.10008.1.2.4.50
Tylko obrazy
JPEG Process 2,4, extended lossy (12
bit)
1.2.840.10008.1.2.4.51
Tylko obrazy
JPEG Process 14, lossless, NonHierarchical
1.2.840.10008.1.2.4.57
Tylko obrazy
JPEG Process 14, selection value 1,
lossless, Non-Hierarchical, First-Order
Prediction
1.2.840.10008.1.2.4.70
Tylko obrazy
JPEG 2000 Image Compression
(Lossless Only)
1.2.840.10008.1.2.4.90
Tylko obrazy
JPEG 2000 Image Compression
1.2.840.10008.1.2.4.91
Tylko obrazy
RLE Lossless
1.2.840.10008.1.2.5
Tylko obrazy
MPEG2 Main Profile @ Main Level
1.2.840.10008.1.2.4.100
Tylko obiekty
wideo
MPEG-4 AVC/H.264 High Profile / Level
4.1
1.2.840.10008.1.2.4.102
Tylko obiekty
wideo
MPEG-4 AVC/H.264 BD compatible
High Profile / Level 4.1
1.2.840.10008.1.2.4.103
Tylko obiekty
wideo
1.
Wysłać
przykładowe
badanie DICOM,
używając DICOM
transfer syntaxu
JPEG 2000
Image
Compression
(1.2.840.10008.1
.2.4.90 lub
1.2.840.10008.1.
2.4.91) oraz
MPEG-2
(1.2.840.10008.1
.2.4.100 ) i
MPEG-4
(1.2.840.10008.1
.2.4.103)
2.
Przedstawić
odbieranie,
archiwizację i
wysyłanie tych
obiektów DICOM
TAK
5. Kontrola dostępu do portalu dla lekarza
Lp
Zapis
Do
prezentacji
[TAK/NIE]
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ł)
Scenariusz
prezentacji
Zademonstrować
przykładową
konfigurację i
działanie:
- wymuszania
wygasania hasła po
skonfigurowanej
ilości dni
TAK
- 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
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
TAK
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 email
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? ")
TAK
Zademonstrować
przykładową
konfigurację i
działanie możliwości
konfiguracji
wymaganej siły
hasła, uwzględniając
wymagane
parametry
Zademonstrować
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
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
TAK
Zademonstrować
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
TAK
Zademonstrować
przykładową
konfigurację i
działanie
automatycznego
blokowania konta
po ustawionym
czasie nieaktywności
konta
TAK
Zademonstrować
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
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.)
6. Kontrola dostępu do rekordu EHR pacjenta (dokumentów,
wyników, informacji)
Lp
Zapis
Do
prezentacji
[TAK/NIE]
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)
TAK
Scenariusz prezentacji
Zademonstrować
przykładową konfigurację i
działanie kontroli dostępu do
rekordu EHR poprzez portal
dla lekarza uwzględniającą
skonfigurowaną rolę lekarza
w systemie.
Zademonstrować działanie
odebrania i przyznania
dostępu do dokumentów,
wyników, informacji pacjenta
na podstawie wymaganych
kryteriów
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)
TAK
Zademonstrować
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)
Zademonstrować działanie
odebrania i przyznania
dostępu do dokumentów,
wyników, informacji pacjenta
na podstawie wymaganych
kryteriów
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.
TAK
Zademonstrować
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.
Zademonstrować działanie
odebrania i przyznania
dostępu do dokumentów,
wyników, informacji pacjenta
na podstawie wymaganych
kryteriów
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)
Zademonstrować
przykładową konfigurację i
działanie kontroli dostępu do
rekordu EHR uwzględniające
miejsce zalogowania się
użytkownika (na podstawie
adresu IP)
TAK
Zademonstrować 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.
Zademonstrować
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.
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 5.7
TAK
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)
Zademonstrować działanie
odebrania i przyznania
dostępu do dokumentów,
wyników, informacji pacjenta
na podstawie wymaganych
kryteriów
5.6. 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.
Zademonstrować
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.).
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
TAK
Zademonstrować oznaczanie
odebranego pojedynczego
wyniku z systemu HIS
wieloma znacznikami.
Zademonstrować działanie
odebrania i przyznania
dostępu do dokumentów,
wyników, informacji pacjenta
na podstawie wymaganych
kryteriów
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:
Zademonstrować
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:
- 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)
TAK
- 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)
7. Funkcjonalności portalu dla lekarza
L
p
Zapis
Do
prezenta
cji
[TAK/NI
E]
Scenariusz
prezentacji
TAK
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)
TAK
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
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
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
TAK
- 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
Informacje te mają być zagregowane razem, bez względu z którego systemu HIS z którego zostały
wysłane.
Zademonstro
wać
spełnienie
wymogu
wyświetlenia
pojedynczej
strony z
podsumowani
em informacji
klinicznych o
pacjencie,
które zawiera
wymagane
informacje
Dotyczy funkcjonalności z punktu 6.3 - 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
TAK
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
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
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
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
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
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
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)
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
TAK
Zademonstro
wać
spełnienie
wymogu
zgodnie z
zapisami
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
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
1.2.840.10008.5.1.4.1.1.1
Digital X-Ray Image Storage – For Presentation
1.2.840.10008.5.1.4.1.1.1.1
Digital X-Ray Image Storage – For Processing
1.2.840.10008.5.1.4.1.1.1.1.1
Digital Mammography X-Ray Image Storage – For Presentation
1.2.840.10008.5.1.4.1.1.1.2
Digital Mammography X-Ray Image Storage – For Processing
1.2.840.10008.5.1.4.1.1.1.2.1
Digital Intra-oral X-Ray Image Storage – For Presentation
1.2.840.10008.5.1.4.1.1.1.3
Digital Intra-oral X-Ray Image Storage – For Processing
1.2.840.10008.5.1.4.1.1.1.3.1
CT Image Storage
1.2.840.10008.5.1.4.1.1.2
Enhanced CT Image Storage
1.2.840.10008.5.1.4.1.1.2.1
Ultrasound Multi-frame Image Storage
1.2.840.10008.5.1.4.1.1.3.1
MR Image Storage
1.2.840.10008.5.1.4.1.1.4
Enhanced MR Image Storage
1.2.840.10008.5.1.4.1.1.4.1
MR Spectroscopy Storage
1.2.840.10008.5.1.4.1.1.4.2
Enhanced MR Color Image Storage
1.2.840.10008.5.1.4.1.1.4.3
Ultrasound Image Storage
1.2.840.10008.5.1.4.1.1.6.1
Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7
Multi-frame Single Bit Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7.1
Multi-frame Grayscale Byte Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7.2
Multi-frame Grayscale Word Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7.3
Multi-frame True Color Secondary Capture Image Storage
1.2.840.10008.5.1.4.1.1.7.4
Breast Tomosynthesis Image Storage
1.2.840.10008.5.1.4.1.1.13.1.3
Basic Voice Audio Waveform Storage
Grayscale Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.9.4.1
1.2.840.10008.5.1.4.1.1.11.1 TAK
Color Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.2
Pseudo-Color Softcopy Presentation State Storage
1.2.840.10008.5.1.4.1.1.11.3
X-Ray Angiographic Image Storage
1.2.840.10008.5.1.4.1.1.12.1
Enhanced XA Image Storage
1.2.840.10008.5.1.4.1.1.12.1.1
X-Ray Radiofluoroscopic Image Storage
1.2.840.10008.5.1.4.1.1.12.2
Enhanced XRF Image Storage
1.2.840.10008.5.1.4.1.1.12.2.1
Breast Tomosynthesis Image Storage
1.2.840.10008.5.1.4.1.1.13.1.3
Intravascular Optical Coherence Tomography Image Storage - For
Presentation
1.2.840.10008.5.1.4.1.1.14.1
Nuclear Medicine Image Storage
1.2.840.10008.5.1.4.1.1.20
VL Endoscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.1
Video Endoscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.1.1
VL Microscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.2
Video Microscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.2.1
VL Slide-Coordinates Microscopic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.3
VL Photographic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.4
Video Photographic Image Storage
1.2.840.10008.5.1.4.1.1.77.1.4.1
Ophthalmic Photography 8 Bit Image Storage
1.2.840.10008.5.1.4.1.1.77.1.5.1
Ophthalmic Photography 16 Bit Image Storage
1.2.840.10008.5.1.4.1.1.77.1.5.2
Basic Text SR
1.2.840.10008.5.1.4.1.1.88.11
Enhanced SR
1.2.840.10008.5.1.4.1.1.88.22
Comprehensive SR
1.2.840.10008.5.1.4.1.1.88.33
Key Object Selection Document
1.2.840.10008.5.1.4.1.1.88.59
X-Ray Radiation Dose SR
1.2.840.10008.5.1.4.1.1.88.67
Encapsulated PDF Storage
1.2.840.10008.5.1.4.1.1.104.1
Positron Emission Tomography Image Storage
1.2.840.10008.5.1.4.1.1.128
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
Portal dla lekarza, moduł wyświetlający wyniki obrazowe, spełnia następujące profile integracji IHE,
min. Scheduled Workflow, Consistent Presentation of Images, Key Image Note, Consistent Time,
Evidence Documents, Simple Image and Numeric Report, Access to Radiology Information, Audit Trail
and Node Authentication, Patient Identifier Cross-referencing, Patient Demographics Query, CrossEnterprise Document Sharing, Cross-Enterprise Document Sharing for Imaging, Cross-Enterprise Sharing
of Scanned Documents
Załączyć certyfikat IHE
NIE
8. Dostępność, architektura i wydajność systemu EHR
Lp
Zapis
Do
prezentacji
[TAK/NIE]
Scenariusz
prezentacji
7.1. System EHR musi być zainstalowany w trzech instancjach, w konfiguracji active-passive,
które mają replikować w czasie rzeczywistym odebrane dane, co w celu umożliwienia
administratorom systemu EHR przełączenie użytkowników oraz zintegrowanych
systemów HIS i PACS na instancję passive w momencie potrzeby rekonfiguracji instacji
active lub jej awarii.
Po wykonaniu rekonfiguracji lub naprawy instalacji active systemu EHR,
administratorzy systemu EHR muszą być w stanie zsynchronizować platformę active z
platformą passive.
Załączyć rysunek architektury systemu, ich modułów oraz metody replikacji danych w
czasie rzeczywistym pomiędzy instalacjami active oraz passive oraz instrukcję
przełączenia instancji active na passive (tzw. failover) oraz z instalacji passive na active
(tzw. failback) oraz resynchronizacji instalacji active z instancją passive. Dodatkowo
zamawiający wymaga dostarczenia instancji testowej, która będzie wykorzystywana do
testów i szkoleń.
7.2. System EHR musi być zainstalowany w środowisku zwirtualizowanym, w konfiguracji
High Availablity, w celu uniezależnienia platformy na awarie serwerów fizycznych na
których jest zainstalowana
7.3. Ze względu na ilość odbieranych danych obrazowych, w celu zapewnienia
bezpieczeństwa i spójności danych, system EHR ma zapisać wraz ze zarchiwizowanymi
obrazami radiologicznymi DICOM sumę kontrolną MD5 obieranego obiektu DICOM.
NIE
NIE
1.Wysłać obiekty
DICOM do Systemu
EHR
2.Potwierdzić
kalkulację i zapisanie
sumy kontrolnej
obiektów
3.Wysłać obiekty do
archiwum
długoterminowego
w platformie EHR
TAK
4.Uszkodzić obiekty
DICOM, wykonać
operację pobrania
obiektów z
archiwum
długoterminowego
systemu EHR
5.Potwiedzić błąd
wydobycia i
informację o
niezgodności CRC w
plikach wydarzeń
7.4. Platforma EHR musi obejmować dwa środowiska – produkcyjne i testowe. Celem
środowiska testowego będzie:
•
dostarczenie środowiska do przeprowadzenia testów akceptacyjnych dla
użytkowników, w celu weryfikacji funkcjonalności które zostaną dostarczone
do w środowisku produkcyjnym
•
dostarczenia środowiska do weryfikacji procesów instalacji poprawek
oprogramowania, testów rekonfiguracji oraz upgrade’ów oprogramowania
przez ich dostarczeniem do środowiska produkcyjnego
NIE
7.5. Architektura systemu EHR musi być tak zaplanowana, aby wydajnie była w stanie
obsłużyć następujące ilości danych i użytkowników:
7500 kont zarejestrowanych użytkowników
750 równocześnie zalogowanych użytkowników
15 000 wiadomości HL7 w ciągu 24 godzin, gdzie 10 000 wiadomości HL7 będzie
odbieranych w szczycie 12 godzinnym (06:00 – 18:00)
Dane populacji 2 milionów pacjentów województwa Kujawsko-Pomorskiego
25 podłączonych systemów HIS
25 podłączonych systemów PACS
1 milion badań DICOM rocznie,
10 milionów obrazów DICOM rocznie,
20 TB badań DICOM rocznie w formacie DICOM LEI
30 000 obrazów DICOM w ciągu godzin szczytu pracy zakładów radiologii (07:00 –
13:00)
NIE
9. Audyty wydarzeń platformy EHR
Lp
Zapis
Do
prezentacji
[TAK/NIE]
Scenariusz
prezentacji
System EHR musi zapisywać wszystkie wydarzenia dotyczące działalności użytkownika
do dedykowanego repozytorium wydarzeń użytkownika:
a.
b.
c.
d.
1.Zademonstrować
repozytorium
wydarzeń do
rekordu EHR
logowania, wylogowania i błędnego logowania użytkownika
informacje które dokumenty i kiedy je wyświetlał
informacje którego pacjenta i kiedy go wyświetlał
informacje kiedy i które elementy systemu EHR konfigurował (jeżeli
użytkownik jest administratorem systemu EHR)
Wyświetlane mają być następujące dane:
8.1.
a.
b.
c.
d.
Data i czas wydarzenia
Typ wydarzenia
ID użytkownika
ID Pacjenta, Imię I nazwisko pacjenta
TAK
3.Dla każdego
wydarzenia
przedstawić
wyświetlenie
wymaganych danych
System EHR musi umożliwiać wyszukiwanie wymienionych wydarzeń za pomocą
następujących filtrów:
a.
b.
c.
d.
Daty wydarzenia
ID użytkownika
ID Pacjenta , Imię I nazwisko pacjenta
Typ wydarzenia (zalogowanie, wylogowanie, wyszukiwanie danych, wgląd w
dokument itp.)
4. Przedstawić
użycie wymaganych
filtrów
System EHR musi zapisywać wszystkie wydarzenia dotyczące tymczasowego uchylenia
polityki dostępu do rekordu pacjenta przez użytkownika (punkt 5.7) – odsłonięcia i
wyświetlenia informacji z rekordu EHR tylko po podaniu predefiniowanego przez
administratora portalu powodu próby dostępu do zaplombowanego rekordu EHR.
Zapisane wydarzenia są umieszczane w dedykowanym repozytorium wydarzeń
dostępu do rekordu EHR.
1.Zademonstrować
repozytorium
wydarzeń do
rekordu EHR
Wyświetlane mają być następujące dane:
8.2.
a.
b.
c.
d.
Data i czas wydarzenia
ID użytkownika
ID Pacjenta, imię i nazwisko pacjenta
ID sesji użytkownika
System EHR musi umożliwiać wyszukiwanie wymienionych wydarzeń za pomocą
następujących filtrów:
a.
b.
c.
d.
Data i czas wydarzenia
ID użytkownika
ID Pacjenta
ID sesji użytkownika
2.Wykonać
wymagane czynności
użytkownika, które
mają stworzyć zapis
do repozytorium
wydarzeń
TAK
2.Wykonać
wymagane czynności
użytkownika, które
mają stworzyć zapis
do repozytorium
wydarzeń
3.Dla każdego
wydarzenia
przedstawić
wyświetlenie
wymaganych danych
4. Przedstawić
użycie wymaganych
filtrów
System EHR musi zapisywać wszystkie wydarzenia dotyczące serwera portalu dla
lekarza (np. wyłączenie, włączenia serwera, czynności użytkownika związane z
połączeniem do bazy danych systemu EHR) do dedykowanego repozytorium wydarzeń
systemu.
1.Zademonstrować
repozytorium
wydarzeń do
rekordu EHR
Wyświetlane mają być następujące dane:
a.
b.
8.3.
c.
d.
e.
Data i czas wydarzenia
ID użytkownika, jeżeli wydarzenie jest związane z czynnością wykonaną z
działalnością użytkownika
Typ wydarzenia
ID sesji użytkownika
Adres IP modułu, na którym doszło do wydarzenia
TAK
3.Dla każdego
wydarzenia
przedstawić
wyświetlenie
wymaganych danych
System EHR musi umożliwiać wyszukiwanie wymienionych wydarzeń za pomocą
następujących filtrów:
a.
b.
c.
8.4.
Data i czas wydarzenia
ID użytkownika, jeżeli wydarzenie jest związane z czynnością wykonaną z
działalnością użytkownika
Typ wydarzenia
Wszystkie wiadomości z repozytoriów wydarzeń audytu mogą być skopiowane lub
zarchiwizowane zanim zostaną usunięte
2.Wykonać
wymagane czynności
systemu, które mają
stworzyć zapis do
repozytorium
wydarzeń
4. Przedstawić
użycie wymaganych
filtrów
NIE
Repozytorium obrazowe musi spełniać profil IHE ATNA - Audit Trail and Node jako
aktor Audit Record Repository. Załączyć certyfikat IHE
Zademonstrować
repozytorium
wydarzeń, min.
następujące
wydarzenia:
- wgląd do badania
obrazowego
- zapytanie o
badania obrazowe
pacjenta
8.5.
TAK
- usunięcie badania z
repozytorium
obrazowego
- odebranie badania
przez repozytorium
obrazowe
- dodanie nowych
źródeł DICOM do
repozytorium
obrazowego przez
użytkownika
10.
Monitorowanie szyny integracyjnej systemu EHR
Lp
Zapis
Do
prezentacji
[TAK/NIE]
Scenariusz
prezentacji
TAK
Zademonstrować
działanie portalu na
urządzeniu
mobilnym z OS
Android oraz iOS
TAK
Zademonstrować
konfigurację
certyfikatu SSL na
urządzeniu
mobilnym
TAK
Zademonstrować
wymagane
funkcjonalności na
urządzeniu
mobilnym z OS
Android oraz iOS
9.1. System EHR musi pozwalać monitorować i zarządzać działaniem szyny integracyjnej
przez urządzenia mobile z OS Android oraz iOS oraz przeglądarkę WWW
9.2.
Działania programu do zarządzania i monitoringu musi być możliwe:
- po uprzednim wgraniu certyfikatu SSL do szyfrowania połączenia
- ustanowieniu użytkownikowi odpowiednich uprawnień do szyny integracyjnej
9.3.
Aplikacja musi umożliwiać wgląd w:
- Eskalacje systemu EHR – poprzez eskalację rozumie się alarm systemu EHR, który nie
jest rozwiązany przez zdefiniowany okres czasu
- Alarmy systemu EHR - poprzez alarm rozumie się informację o problemie dla
użytkownika, wyświetlaną jeżeli wcześniej zostały spełnione zdefiniowane kryteria dla
komponentu EHR (np. określona utylizacja CPU)
- Ostrzeżenia systemu EHR - poprzez ostrzeżenie rozumie się informację o problemie dla
użytkownika, wyświetlaną jeżeli wcześniej zostały spełnione zdefiniowane kryteria dla
komponentu EHR (np. określona utylizacja CPU)
- Kolejkę błędów systemu EHR – rozumianą jako listę wszystkich wiadomości, które
informują o zaistniałych błędach w platformie EHR. Kolejka błędów ma wyświetlać min.
informacje którego komponentu dotyczy oraz czasu kiedy wiadomość zaistniała
9.4.
Zademonstrować
wymagane
funkcjonalności na
urządzeniu
mobilnym z OS
Android oraz iOS.
Aplikacja musi umożliwiać wykonanie czynności startu, zatrzymania I restartu
komponentów, minimum:
- punktów komunikacyjnych HL7
- innych usług systemu EHR, np. usług web service
Aplikacja dla każdego komponentu ma raportować status komponentu, min.
- uruchomiony
- zatrzymany
- restartowany (w trakcie uruchamiania/inicjalizacji)
- zatrzymany z powodu błędu
TAK
Potwierdzić startu,
zatrzymanie I
restartu
komponentu z
urządzenia
mobilnego na
panelu
administratora
szyny integracyjnej
WWW na
komputerze
stacjonarnym.
9.5. Aplikacja musi umożliwiać wykonanie następujących czynności:
- oznaczyć alerty jako przeczytane
- anulować lub aktywować ponownie alarmy
- otworzyć alarmy w konsoli zarządzającej platformą EHR przez przeglądarkę WWW po
wcześniejszym podaniu nazwy użytkownika i hasła
- zmiana częstotliwości monitorowania
TAK
Zademonstrować
wymagane
funkcjonalności na
urządzeniu
mobilnym z OS
Android oraz iOS
11.
Funkcjonalności szyny integracyjnej platformy EHR
Lp
Zapis
10.1.System EHR musi posiadać szynę integracyjną do budowania kolejnych punktów
integracji HL7 (dla danych przychodzący, jak i dla wysyłania wiadomości HL7 z szyny
integracyjnej) w szynie integracyjnej za pomocą dedykowanego narzędzia dla
administratora EHR, bez potrzeby programowania interfejsu przez administratorów EHR
10.2.System EHR musi posiadać narzędzia które pozwalają śledzić kto stworzył, zobaczył,
zmienił/zmodyfikował lub usunął wiadomość HL7 w szynie integracyjnej systemu EHR
10.3.Szyna integracyjna musi pozwalać przetestować nowy interfej si i komunikację punktpunkt bez potrzeby programowania oraz wizualizować obieg wiadomości HL7
przechodzące przez interfejsy
10.4.Szyna integracyjna musi pozwalać automatycznie generować specyfikację nowego
stworzonego interfejsu dla dawców nowych systemów w formacie pliku PDF
Do
prezentacji
[TAK/NIE]
Scenariusz
prezentacji
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
TAK
Zademonstrować
wymagane
funkcjonalności
10.5.System EHR musi posiadać narzędzia, które umożliwiają odszukanie wiadomości HL7
odebranej od systemu HIS, która przeszła przez system na podstawie:
•
•
•
•
Zakresu dat
Danych pacjenta
Typu wydarzenia HL7
Systemu źródłowego
10.6.Szyna integracyjna musi pozwalać administratorom systemu EHR przetwarzać odebrane
wiadomości HL7, min.
- rozdzielanie wiadomości HL7 na części
- łączenie wiadomości HL7
- prefixowanie identyfikatorów, modyfikacja wybranych pól wiadomości HL7
- szyfrowanie / deszyforwanie wiadomości HL7
10.7.W celu utylizacji dostępnych zasobów CPU i RAM, szyna integracyjna musi pozwalać
administratorom systemu EHR planować działanie poszczególnych interfejsów
(włączać/wyłączać w określonych godzinach i dniach)
Administratorzy systemu EHR muszą mieć możliwość ustawienia przetwarzania
odebranych wiadomości HL7, min. w czasie rzeczywistym, wszystkie odebrane raz na
tydzień, wszystkie odebrane raz na dzień
10.8.Szyna integracyjna musi mieć możliwość konfiguracji alarmów związanych min z :
- brak miejsca na bazę danych
- zatrzymana usługa lub interfejs HL7
- błąd wiadomości HL7
- zbyt duża kolejka wiadomości
Dla powstałych alarmów, szyna integracyjna musi mieć możliwość wysyłania
powiadomień mailowych na wybrany adres główny. Dla alarmów powstałych po
godzinach pracy, szyna integracyjna musi mieć możliwość wysyłania powiadomień
mailowych na wybrany adres drugorzędny (np. administatora pełniącego dyżur 24/7)
12.
Inne cechy integracyjne systemu EHR
Lp
Zapis
11.1. System EHR musi mieć możliwość integracji z kontami kontrolera LDAP (MS Active
Directory, OpenLDAP itp.)
11.2.
System EHR musi mieć funkcję anonimizacji danych pacjentów na potrzeby integracji z
systemami audytu klinicznego i programami badawczymi i analizy populacji przez
Departament Zdrowia UM
Do
prezentacji
[TAK/NIE]
Scenariusz
prezentacji
NIE
NIE
11.3. System EHR musi możliwość budowania i zarządzania słownikami procedur
regionalnych, nazw wyników laboratoryjnych, alergii oraz semantyki danych (np. format
adresu, jednostki miar itd.) w oparciu o tabele krzyżowe (tzw. ang. lookup tables) i
normalizacyjne (w oparciu o kody ICD), które pozwalają zunifikować na poziomie
regionalnym odebrane dane z systemów źródłowych
Administrator systemu EHR musi mieć możliwość dodawania i usuwania wartości do
tabel krzyżowych i normalizacyjnych poprzez panel administratora WWW.
TAK
Zademonstrować
wymagane
funkcjonalności
Administrator systemu EHR musi mieć monitorowania i wyświetlenia danych z
systemów źródłowych, które nie znajdują odzwierciedlenia w aktualnie wprowadzonych
danych w tabelach krzyżowych i normalizacyjnych
Administrator systemu EHR musi mieć eksportowania danych z tabel krzyżowych i
normalizacyjnych do formatu CSV poprzez panel administratora WWW.
13.
Skalowalność
Usługa EHR musi być przygotowana w taki sposób, aby mogła sprostać następującym wymaganiom wydajnościowym i
pojemnościowym:
•
•
•
•
•
•
•
•
•
Obsługa maksymalnie 7500 kont użytkowników (średnio 300 per szpital)
maksymalnie 750 równoczasowych, zalogowanych użytkowników (średnio 30 per szpital)
maksymalnie populacja 2 millionów pacjentów regionu Kujawsko-Pomorskiego
25 podłączonych systemów HIS,
25 podłączonych systemów PACS
maksymalnie 1 million badań DICOM rocznie
maksymalnie 10 millionów obrazów DICOM rocznie
maksymalnie 20 TB danych DICOM rocznie w formacie DICOM LEI
maksymalnie 30 000 obrazów DICOM per godzina w szczycie 07:00 – 13:00 dziennie
14.
Bezpieczeństwo systemu
W związku z tym, że wykonawca musi zapewnić funkcjonowanie usługi jest on w pełni odpowiedzialny za implementację
stosownych zabezpieczeń gwarantujących bezpieczeństwo przechowywanych i przetwarzanych w systemie EHR danych
pacjentów. Musi on również spełnić wszelkie wymagane warunki umożliwiające zgodne z prawem posługiwanie się danymi
wrażliwymi. Przede wszystkim wykonawca jest zobowiązany do opublikowania i przekazania Zamawiającemu oraz
podłączanym do systemu szpitalom dokumentu zawierającego opis zastosowanej polityki bezpieczeństwa oraz procedur,
których wdrożenie umożliwi wymianę danych pacjentów pomiędzy szpitalami. . Odpowiedzialność Wykonawcy skupiać się
będzie na zapewnieniu bezpieczeństwa fizycznego, wdrożeniu polityki bezpieczeństwa oraz procedur zarządzania usługą
EHR z uwzględnieniem szczególnego znaczenia danych wrażliwych, które będą przetwarzane w systemie a także
wprowadzeniu odpowiednich zabezpieczeń zapewniających bezpieczne przesyłanie danych w formie zaszyfrowanej
pomiędzy serwerownią wykonawcy a sieciami lokalnymi (LAN) szpitali podłączonych do systemu EHR. Przy czym
finansowanie usługi telekomunikacyjnej, łącza do sieci WAN lub usługi transmisji danych po stronie szpitali, będzie
zapewnione przez szpitale i nie jest przedmiotem niniejszego zamówienia. Wykonawca musi zapewnić bezpieczeństwo
fizyczne poprzez umieszczenie usługi EHR w serwerowni charakteryzującej się następującymi standardami:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Wymaga się, aby oferowane Data Center spełniało wszystkie wymagania bezpieczeństwa fizycznego,
technicznego oraz logicznego, właściwe dla profesjonalnych obiektów przeznaczonych do przechowywania
oraz przetwarzania danych, w tym także danych osobowych, wrażliwych oraz objętych klauzulą poufności.
Wymaga się, aby Data Center położone było na terenie umożliwiającym pełną kontrolę i nadzór obszarów
przyległych do serwerowni oraz budynku.
Wymaga się, aby obszar Data Center posiadał strefy bezpieczeństwa, tj. strefy objęte kontrolą dostępu, które
oddzielają pomieszczenia Data Center od reszty budynku lub terenu przylegającego.
Wymaga się, aby Data Center było oddalone od zbiorników wodnych co najmniej 150 metrów w linii prostej lub
(w przypadku mniejszej odległości) różnica poziomu między powierzchnią zbiornika wodnego a najniższym
poziomem Data Center wynosiła co najmniej 2 metry,.
Wymaga się, aby komory Data Center zlokalizowane były w dedykowanej przestrzeni, która nie pełni innych
funkcji, w szczególności związanych z dostępem osób postronnych.
Wymaga się, aby cały obszar Data Center, w tym jego otoczenie zewnętrzne i poszczególne, wewnętrzne strefy
bezpieczeństwa, podlegały stałemu nadzorowi kamer telewizji przemysłowej CCTV z rejestracją ciągłą, a
dodatkowo podlegały fizycznemu patrolowaniu
i kontroli w trybie 24h/dobę, realizowanym przez
koncesjonowaną Agencję Ochrony.
Wymaga się, aby podział na poszczególne strefy bezpieczeństwa wyznaczony został przez granice stałe, tj. ściany
z osobnymi wejściami, zabezpieczone systemem dostępu, a całość obiektu Data Center posiadała konstrukcję
ścian zewnętrznych, zabezpieczających obiekt przed próbą wtargnięcia do wewnątrz.
Wymaga się, aby wszelkie urządzania administratorskie, takie jak konsole do zarządzania oraz monitorowania
pracy systemów, zostały umieszczone w osobnych pomieszczeniach, tak, aby maksymalnie ograniczyć dostęp do
głównej serwerowni Data Center,
Wymaga się, aby wszystkie drzwi – zewnętrzne prowadzące do Data Center oraz wewnętrzne drzwi oddzielające
strefy zostały wyposażone w zamki patentowe i elektroniczny system kontroli dostępu.
Wymaga się, aby wejście do serwerowni głównej Data Center zabezpieczone zostało co najmniej dwoma strefami
systemu elektronicznej kontroli dostępu oraz automatycznej rejestracji wizyjnej .
Wymaga się, aby dostęp do Data Center był możliwy jedynie dla uprawnionych osób, a każde wejście i wyjście
podlegało rejestracji.
Wymaga się, aby wszystkie przypadki dostępu były autoryzowane i sprawdzane za pomocą zabezpieczeń
uwierzytelniających, takich jak karta uwierzytelniająca z czytnikiem linii papilarnych.
Wymaga się, aby Data Center posiadało przyłącza do sieci Internet od co najmniej dwóch niezależnych dostawców
realizowane za pomocą niezależnych łącz światłowodowych.
Wymaga się, aby Data Center i wszystkie pomieszczenia związane ze świadczeniem usług na rzecz Zamawiającego,
były wykonane zgodnie z:
o przepisami prawa budowlanego,
o przepisami odpowiednimi dla każdej z instalacji,
o przepisami BHP,
o przepisami p.-poż.
Wymaga się, aby Data Center było zaprojektowane w sposób zapewniający zgodność z wymaganiami norm lub
ich odpowiednikami obowiązujących na terenie Europejskiego Obszaru Gospodarczego:
Wymaga się, aby budynek Data Center posiadał co najmniej dwa, niezależne źródła zasilania (z dwóch stacji
transformatorowych). Zasilanie awaryjne musi gwarantować automatyczne podtrzymanie zasilania dla Systemu
Informatycznego Zamawiającego oraz wszelkich systemów i infrastruktury Data Center, zapewniających
podtrzymanie prawidłowego środowiska pracy Systemu.
Wymaga się, aby Data Center dysponowało systemem Samoczynnego Załączania Rezerwy.
Wymaga się, aby Data Center posiadało własny generator prądu, gwarantujący podtrzymanie zasilania w Data
Center przy pełnej mocy przez minimum 12 godz. bez potrzeby tankowania, a w razie dalszej potrzeby gwarantujący możliwość tankowania bez przerywania pracy.
Wymaga się, aby oferowane Data Center było wyposażone w automatyczny system wykrywania dymu i
sygnalizacji pożaru.
•
•
•
•
•
•
•
•
Wymaga się, aby oferowane Data Center było wyposażone w automatyczny system gaszenia gazowego,
neutralnego dla sprzętu komputerowego.
Wymaga się, aby system gaszenia, w szczególności jego główne sterowanie oraz pojemniki z gazem, zostały
zlokalizowane poza pomieszczeniem serwerowni głównej, w której zostanie umieszczony System, a dostęp
do nich był możliwy bez wchodzenia do serwerowni głównej.
Wymaga się, aby oferowane Data Center było wyposażony w nadmiarowy system klimatyzacji precyzyjnej co
najmniej na poziomie N+1.
Wymaga się, aby Wykonawca zapewnił stałe – 24h/dobę – monitorowanie warunków pracy Systemów w Data
Center za pomocą systemu monitorującego Wykonawcy.
Monitorowaniu podlegać będą co najmniej:, dostępność oraz wysycenie pasma dostępowego do Internetu,
warunki pracy Systemów pod kątem kontroli jakości usług SLA.
Wymaga się, aby Wykonawca zapewnił przechowywanie taśm backupowych z danymi Zamawiającego przez cały
okres trwania Umowy, w takich warunkach, które będą gwarantowały bezpieczeństwo i poufność danych
Zamawiającego, a zarazem zabezpieczą dane przed zniszczeniem lub utratą na wypadek awarii lub katastrofy
Data Center.
Wymaga się, aby oferowane rozwiązanie LAN / WAN zapewniało pełną redundancję połączeń na wypadek
pojedynczej awarii.
Wymaga się, aby Wykonawca zapewnił ochronę danych Zamawiającego w warstwie
logicznej na
udostępnionym przyłączu.
Wykonawca zaproponuje i podpisze z podłączanymi do systemu szpitalami oraz z Zamawiającym stosowne umowy o
zachowaniu poufności oraz przetwarzaniu danych osobowych i wrażliwych.
15.
Przygotowanie próbki oprogramowania oraz demonstracja
Próbka oprogramowania jest częścią oferty i Wykonawca jest zobowiązany do jej dostarczenia wraz z ofertą. Próbkę
należy dostarczyć w dwóch identycznych kopiach (właściwa i zapasowa), zapisanych na dwóch niezależnych nośnikach
(dopuszcza się dyski zewnętrzne z interfejsem USB). Na nośnikach należy umieścić pliki maszyny lub maszyn wirtualnych
zgodne z formatem akceptowanym przez VMWare vSphere w wersji 5.5 lub nowsze. Na dostarczonych dyskach(nośnikach)
należy umieścić plik tekstowy z wygenerowanymi sumami kontrolnymi MD5 plików maszyn wirtualnych składających się na
próbkę oprogramowania. Zawartość pliku testowego z sumami kontrolnymi MD5 należy wydrukować i dołączyć w formie
papierowej do składanej oferty. Do oferty należy dołączyć również szczegółową instrukcję obsługi próbki oprogramowania
opisującej sposób jej konfiguracji oraz wszystkie kroki, które należy wykonać w celu przejścia scenariusza testowania
poszczególnych funkcjonalności. Zamawiający, na etapie badania ofert, zorganizuje demonstrację próbki w siedzibie
Zamawiającego. Celem demonstracji jest prezentacja wybranych funkcjonalności systemu EHR w celu udowodnienia przez
dostawcę, że posiada produkt spełniający wymagania techniczne określone przez zamawiającego w specyfikacji.
1. Zasady przygotowania do demonstracji
Dostawca musi dostarczyć całe środowisko testowe – serwer, sieć komputerową, stacje robocze, itd.
Zamawiający udostępnia tylko pomieszczenie oraz zasilanie na potrzeby demonstracji
Dostawca ma 2 godziny na rozpakowanie i uruchomienie środowiska testowego po otrzymaniu dostarczonych
przez niego próbek oprogramowania.
2.
Zasady demonstracji
Demonstracja będzie opisywana i przedstawiana przez osoby mówiące w języku polskim
Demonstracja może być wykonywana równolegle przez dwie osoby Dostawcy. W przypadku deklaracji
demonstracji przez dwie osoby przez Wykonawcę, Zamawiający deklaruje obecność dwóch osób jednocześnie
odbierających demonstracje funkcjonalności wykonywane przez te osoby (pozwalając demonstrować i odbierać
demonstrację funkcjonalności równolegle)
Łączna liczba osób obecnych ze strony Wykonawcy to maksimum cztery osoby
Nie zliczenie warunku demonstracji funkcjonalności określonej jako warunek graniczny w ramach dostępnego
limitu czasowego powoduje odrzucenie oferty
Łączny dostępny czas demonstracji dla wykonawcy to 8 godzin od momentu zakończenia rozstawienia
środowiska testowego.
W przypadku problemów technicznych środowiska testowego podczas demonstracji, Dostawca ma możliwość
naprawy i ponownego rozpoczęcia demonstracji, w ramach łącznego czasu demonstracji
W przypadku zaistnienia siły wyższej (długotrwałe przerwy w dostawie energii elektrycznej) Zamawiający
wyznaczy inny termin kolejnej prezentacji
Środowisko testowe nie może mieć dostępu do Internetu. Połączenie do Internetu może być wykorzystywane tylko
podczas zadeklarowanej naprawy i tylko na jednej stacji wskazanej wcześniej przez Dostawcę. Podczas demonstracji,
połączenie do Internetu powinno zostać wyłączone.