$$\rightleftharpoonup{xx}$$
$$\longleftharp{xx}$$,
$$\longrightharp{xx}$$,
Motywacja do zintegrowanej elektronicznej bazy danych medycznych i badań
Badania kliniczne opierają się na dostępności wysokiej jakości danych, niezależnie od tego, czy do analizy wykorzystywane są klasyczne metody statystyczne, czy techniki uczenia maszynowego (ML)1,2. Oprócz rutynowych danych (np. danych demograficznych, laboratoryjnych i leków) wymagane są dane specyficzne dla danej dziedziny (np. dane istotne dla transplantacji) o wysokiej szczegółowości3,4. Jednak rutynowa opieka w wielu szpitalach uniwersyteckich jest wykonywana za pomocą szpitalnych systemów informatycznych (HIS), które nie pozwalają ani na systematyczne gromadzenie danych specyficznych dla badań, ani na łatwą ekstrakcję danych rutynowych5,6,7. W rezultacie badacze kliniczni tworzą specyficzne bazy danych badawczych, które mają różne problemy, w tym złożony proces tworzenia bazy danych, ręczne wprowadzanie danych, problemy z ochroną danych i długoterminową konserwację (Tabela 1). Ograniczona ilość danych, brakujące dane i niespójności stanowią poważny problem dla badań klinicznych w ogóle i utrudniają korzystanie z technologii ML8,9,10,11,12,13. Te samodzielne bazy danych badawczych zwykle koncentrują się na określonych aspektach choroby lub pacjenta, nie są połączone z innymi bazami danych i często są wycofywane po pewnym czasie, co skutkuje niedostępnymi "silosami danych". Ostatecznie wysokiej jakości, długoterminowe dane dotyczące różnych aspektów choroby są nieliczne. W erze medycyny cyfrowej rośnie zapotrzebowanie na kompleksową elektroniczną dokumentację medyczną (EHR)7,14,15, która umożliwia łatwe dokumentowanie danych specyficznych dla danej dziedziny i automatyczne gromadzenie rutynowych danych z systemów opieki szpitalnej i ambulatoryjnej.
Te ogólne rozważania dotyczą również medycyny transplantacyjnej16. W związku z tym do skutecznej dalszej opieki niezbędna jest pełna dokumentacja historii medycznej pacjenta, w tym wszystkie zabiegi szpitalne i ambulatoryjne, rutynowe dane kliniczne, a także dane specyficzne dla przeszczepu17,18. Ponieważ zwykłe HIS są statyczne i koncentrują się na leczeniu szpitalnym, nie mogą integrować danych specyficznych dla przeszczepu, takich jak dane dawcy, czas zimnego niedokrwienia i dane dotyczące ludzkich antygenów leukocytarnych (HLA). Dane te są jednak podstawowym warunkiem wstępnym dla badań transplantacyjnych19,20,21,22, a także z długoterminowej opieki klinicznej. Podczas gdy początkowy pobyt w szpitalu trwa zwykle tylko 1-2 tygodnie, a procesy i wczesne wyniki po przeszczepieniu nerki są porównywalne między wieloma ośrodkami transplantacyjnymi, opieka przez całe życie po przeszczepie jest skomplikowana i brakuje w niej wspólnego, ustrukturyzowanego podejścia. Motywuje to zintegrowaną elektroniczną dokumentację medyczną i bazę danych badawczych do uchwycenia trwającej całe życie podróży pacjenta po przeszczepie. 23
W celu zintegrowania tych funkcji do rutynowej opieki i badań nad KTR, opracowano EHR o nazwie "TBase" z myślą, że rutynowe zastosowanie w opiece po przeszczepie stworzy unikalną bazę danych o najwyższej jakości danych (Tabela 2).
Projektowanie i architektura
Baza bazuje na typowej architekturze klient-serwer. Do rozwoju wykorzystano komponenty i narzędzia SAP High Performance Analytic Appliance extended application advanced (SAP HANA XSA). Oparta na najnowszych technologiach internetowych Hypertext Markup Language 5 (HTML5) elektroniczna dokumentacja medyczna została opracowana i przetestowana pod kątem aparatu Google Chrome. Ten silnik internetowy jest używany przez przeglądarkę Chrome i Microsoft Edge i umożliwia korzystanie z EHR w najczęściej używanych przeglądarkach internetowych24 bez konieczności instalacji lokalnej. Zastosowana technologia umożliwia responsywne projektowanie stron internetowych i pozwala na korzystanie z internetowej elektronicznej dokumentacji medycznej na wszystkich urządzeniach (komputer, tablet, smartfon). Innowacyjna, wysokowydajna platforma programistyczna składa się z różnych komponentów (Web IDE, UI5 i HANA DB) i umożliwiła nam szybkie wdrożenie projektu EHR TBase przy użyciu najnowocześniejszych narzędzi programowych (Rysunek 1).
Do reprezentacji danych pacjenta zastosowano prostą strukturę tabeli, która zapewnia intuicyjny i zrozumiały projekt EHR. Na przykład tabela pacjentów, której kluczem podstawowym jest identyfikator pacjenta, znajduje się w środku struktury tabeli. Prawie wszystkie tabele (z wyjątkiem pojedynczych podtabel) są połączone z tą centralną tabelą za pomocą identyfikatora pacjenta (Rysunek 2).
Rysunek 3 pokazuje bardziej szczegółowo część struktury tabeli TBase i używane typy danych. Użytkownik końcowy może uzyskać dostęp do pól danych za pośrednictwem graficznego interfejsu użytkownika (GUI), którego przykład pokazano w Rysunek 4.
Ten EHR zawiera wszystkie aktualne dane pacjenta i jest używany do rutynowej opieki ambulatoryjnej. Ważne rutynowe dane kliniczne (np. dane laboratoryjne, wyniki medyczne, dane radiologiczne, mikrobiologiczne, wirusologiczne i patologiczne, dane szpitalne itp.) są bezpośrednio importowane do TBase za pośrednictwem ustandaryzowanych interfejsów (np. na podstawie Health Level Seven (HL7) - standardu komunikacji cyfrowej w sektorze opieki zdrowotnej25). Dane specyficzne dla przeszczepu, takie jak czas zimnego niedokrwienia, dane dawcy, dane HLA, a także notatki kontrolne, parametry życiowe, raporty medyczne i lista leków są wprowadzane przez użytkowników za pośrednictwem graficznego interfejsu użytkownika do EHR. Przed przekazaniem danych do bazy danych przeprowadzana jest automatyczna kontrola wiarygodności w celu szybkiego wykrycia błędnych wpisów danych, z możliwością natychmiastowej korekty. Ponadto walidacja danych odbywa się podczas rutynowych zajęć klinicznych, w których użytkownicy kliniczni rutynowo piszą raporty i listy do pacjentów i lekarzy. Listy te muszą zawierać prawidłowe dane (np. dotyczące leków, wartości laboratoryjnych i uwag klinicznych) do dalszego leczenia i planów leczenia. W związku z tym lekarze i pacjenci stale weryfikują i korygują dane kliniczne w swojej codziennej praktyce, co skutkuje wysoką jakością danych. Jeśli dane są wprowadzane za pośrednictwem interfejsów programowania aplikacji (API) lub innych interfejsów, kontrole wiarygodności są przeprowadzane w backendzie podobnie jak kontrole wiarygodności w interfejsie użytkownika.
Interfejs użytkownika (GUI)
Do implementacji frontendu wykorzystywany jest UI5 Framework. Framework ten zapewnia obszerną bibliotekę elementów frontendu, a także szereg dodatkowych funkcji, takich jak wielojęzyczność i biblioteki graficzne do wizualizacji danych. Obecnie elementy frontendu TBase są wyświetlane w języku angielskim lub niemieckim, w zależności od ustawień językowych przeglądarki.
Interfejs master-detail jest używany dla frontendu, aby zapewnić prostą, intuicyjną strukturę strony. Górna część strony przeglądania składa się z indywidualnych zakładek dla stron szczegółów (dane podstawowe, dane medyczne, dane transplantacyjne itp.). Ta główna część pozostaje niezmieniona niezależnie od tego, która strona szczegółów jest pokazana poniżej (Rysunek 4). Widok szczegółowy każdej strony umożliwia łatwy przegląd tematu strony.
Do manipulacji danymi, EHR ma różne poziomy uprawnień użytkownika ("odczyt", "zapis", "usuń" i "administrator"). Oprócz poziomu "widoku" istnieje poziom "edycji", który może być aktywowany tylko przez użytkowników z wyższymi uprawnieniami niż "odczyt". Jeśli użytkownik ma prawo do zapisu, wszystkie pola wejściowe do wprowadzania danych są aktywowane i mogą być wypełnione danymi. Użytkownicy z uprawnieniami do usuwania mogą usuwać dane za pomocą odpowiedniego przycisku, ale tylko po potwierdzeniu za pomocą wyskakującego okienka.
Struktura bazy danych i interfejsy
Rozwój TBase odbywa się w programistycznej bazie danych. Obszerne i szczegółowe testowanie wszystkich zmian w oprogramowaniu, takich jak nowe funkcjonalności, odbywa się w bazie danych zapewnienia jakości. Aktualizacje oprogramowania, które przejdą kontrolę jakości, są przesyłane do systemu na żywo. Do celów badawczych system live jest kopiowany do bazy danych replikacji, która może być odpytywana za pośrednictwem standardowych interfejsów Open Database Connectivity (ODBC) (np. za pośrednictwem oprogramowania typu open source R Studio). Ponieważ nie ma bezpośredniego połączenia między replikacją a działającym systemem, dane w działającym systemie są chronione przed uszkodzeniem, utratą lub manipulacją danymi. Ta modułowa struktura i wyraźne rozdzielenie czterech baz danych (rozwojowa, zapewnienia jakości, systemu Live i replikacji bazy danych), które są dostosowane do konkretnych potrzeb programistów, badaczy i klinicystów, ułatwia utrzymanie i ochronę wrażliwych danych pacjentów.
EHR jest w pełni zintegrowany z infrastrukturą danych Charité i korzysta z różnych interfejsów do importu danych z różnych źródeł danych. Interfejs do HIS importuje wszystkie istotne dane, takie jak dane administracyjne, badania, leki, wyniki badań laboratoryjnych i pisma o wypisie. Interfejs ten łączy oba systemy za pośrednictwem strefy przejściowej. Tutaj wszystkie nowe dane (delta danych) są przesyłane z HIS do TBase w czasie rzeczywistym. Pacjenci są identyfikowani za pomocą numeru pacjenta lub numeru przypadku, a odpowiednie dane z HIS są importowane (jeśli nie są jeszcze dostępne w TBase).
Dla pacjentów ambulatoryjnych, nasz partner laboratoryjny dostarcza wyniki badań laboratoryjnych za pośrednictwem wiadomości HL7. Są one wdrażane we wspólnym obszarze systemu laboratoryjnego i odbierane za pośrednictwem interfejsu HL7 oraz importowane do elektronicznej dokumentacji medycznej. Do dwukierunkowej komunikacji i wymiany danych z KTR (za pośrednictwem aplikacji na smartfony) i nefrologami domowymi zaimplementowano interfejs HL7 Fast Healthcare Interoperability Resource (HL7 FHIR) 26. Interfejs ten zapewnia interoperacyjność i elastyczność w celu bezpiecznej wymiany danych z innymi źródłami danych (np. Eurotransplant, aplikacjami dla pacjentów) w przyszłości.
Zarządzanie użytkownikami i ochrona danych
TBase opiera się na zarządzaniu użytkownikami na poziomie aplikacji. W związku z tym użytkownik może uzyskać dostęp tylko do interfejsu aplikacji, ale nie do samej bazy danych. Jak opisano powyżej, zdecydowano się na czteroetapową koncepcję autoryzacji, zastrzegającą zarządzanie użytkownikami dla osób z uprawnieniami administracyjnymi. Administratorzy używają aplikacji "Identity Management Console" do dodawania nowych użytkowników z puli użytkowników Charité dla aplikacji TBase i zachowywania ich uprawnień użytkowników (Rysunek 5). Większość użytkowników ma dostęp do wszystkich pacjentów w bazie danych. Możliwe jest jednak ograniczenie dostępu dla określonych użytkowników, takich jak monitory badania, do grupy pacjentów.
Korzystając z komercyjnej platformy baz danych w pamięci, używana jest bezpieczna technologia baz danych, która chroni dane za pomocą strategii takich jak autoryzacja na poziomie aplikacji, jednokrotne logowanie (SSO), protokół MIT-Kerberos i Security Assertion Mark-up Language (SAML). Platforma zabezpiecza komunikację, przechowywanie danych i usługi aplikacyjne przy użyciu najnowszych technik szyfrowania i testowania. Wszystkie zmiany w bazie danych są kontrolowane przez uprawnienia. Zapewnia to bezpieczeństwo danych w fazie projektowania na wysokim poziomie. Ponadto wszystkie dane są przechowywane za certyfikowaną zaporą sieciową Charité. Zgodnie z najnowszym ogólnym rozporządzeniem Unii Europejskiej o ochronie danych (RODO) wdrożono solidną koncepcję ochrony danych, w tym diagramy przepływu danych, ocenę ryzyka dla ochrony danych (DSFA) i koncepcję autoryzacji. Wszystkie dokumenty znajdują się w katalogu procedur Urzędu Ochrony Danych Charité.