Mierz własność publiczną, a nie narażenie pacjenta
Badania dotyczące uwierzytelniania w domenie opieki zdrowotnej mogą opisywać konfigurację publicznego DNS w ramach określonej próbki. Nie może ustalić, czy dane pacjenta zostały ujawnione, czy system kliniczny jest niebezpieczny lub czy organizacja naruszyła obowiązek prawny. Publiczna domena internetowa może w ogóle nie zawierać wiadomości od pacjentów. Metoda powinna od początku oddzielać zaobserwowane właściwości techniczne, mapowanie podmiotu leczniczego i wszelkie niezmierzone ryzyko operacyjne.
Niniejszy manuskrypt nie zawiera żadnych informacji o pacjencie, skanów organizacyjnych ani ustaleń dotyczących zgodności. Proponuje powtarzalny projekt badania z wyraźnymi ograniczeniami. Fakt, że opieka zdrowotna jest wrażliwym tematem, sprawia, że staranne przypisanie informacji jest ważniejsze, a nie mniej: słabo poparty nagłówek może stworzyć poważny zarzut na podstawie dowodów potwierdzających jedynie wąską obserwację DNS .
Wybierz dokładnie populację objętą opieką
Strona z publicznymi raportami Inicjatywy na rzecz Jakości Szpitala CMS opisuje informacje szpitalne w Care Compare i Katalogu danych dostawców. Stwierdza, że wyświetlanie szpitali jest zasadniczo ograniczone do określonych typów szpitali i obejmuje dane ze szpitali posiadających certyfikat Medicare. Jest to ograniczony oficjalny kontekst źródłowy, a nie spis wszystkich organizacji opieki zdrowotnej, klinicystów, ubezpieczycieli, laboratoriów czy placówek opieki zdrowotnej.
Badanie wykorzystujące to źródło musi zachować swój zakres i datę publikacji. Badanie innego kraju lub placówki opieki wymaga własnej, autorytatywnej populacji lub wyraźnie określonej próby. Nie nazywaj próbki szpitalnej sektorem opieki zdrowotnej bez wyjaśnienia, co zostało pominięte. Dla tej wersji roboczej nie pobrano żadnego zbioru danych CMS ani listy obiektów; źródło obsługuje wyłącznie pytania dotyczące projektowania populacji.
Oddzielne obiekty, systemy i wspólne marki
System opieki zdrowotnej może obsługiwać wiele szpitali, klinik i marek publicznych w ramach jednej domeny, natomiast placówka może po przejęciu korzystać z kilku stron internetowych lub domen odziedziczonych. Zapisz identyfikator obiektu, system nadrzędny, powiązanie z marką i daty wejścia w życie, jeśli jest to możliwe. Wielokrotne zliczanie domeny współdzielonej każdego obiektu może zmienić wagę badania bez dodawania niezależnych obserwacji technicznych.
Zdecyduj, czy analiza ma być ważona obiektem, ważona organizacją czy ważona domeną. Zachowaj relacje, aby inny analityk mógł obliczyć inny pogląd bez zgadywania. Nie łącz organizacji tylko dlatego, że ich nazwy lub projekty stron internetowych są do siebie podobne. Mapowanie musi opierać się na zachowanych źródłach, a nierozwiązane powiązania powinny pozostać widoczne w dzienniku wykluczeń lub niepewności.
Określ rolę każdej próbki domeny
Witryna internetowa szpitala publicznego, portal pacjenta, witryna rekrutacyjna, platforma zbierania funduszy i usługa przypomnień mogą mieć różnych operatorów i różne tożsamości pocztowe. Badanie powinno określić, jaka rola jest faktycznie wykazana w przypadku domeny objętej próbą. Link do strony internetowej w oficjalnym źródle populacji nie określa domen używanych do przypomnień o wizytach, korespondencji klinicznej lub wiadomości rozliczeniowych.
RFC 7208 I RFC 9989 zdefiniuj uwierzytelnianie w kategoriach określonych tożsamości SMTP i domeny wiadomości. Obserwacja wyłącznie DNS nie może wypełnić brakującego kontekstu wiadomości. Nie wysyłaj wiadomości testowych, nie wchodź w interakcję z portalami pacjentów ani nie sprawdzaj prywatnej komunikacji w celu ustalenia tożsamości bez osobnego autoryzowanego zadania. Żadne z tych działań nie miało tutaj miejsca.
Traktuj infrastrukturę współdzieloną jako zależność, a nie przypisanie
Kilka organizacji opieki zdrowotnej może korzystać z tego samego hosta DNS , platformy e-mail lub dostawcy usług angażowania pacjentów. Zaobserwowana wspólna zależność nie dowodzi wspólnej kontroli administracyjnej ani identycznego zachowania uwierzytelniania. Konfiguracja specyficzna dla konta, trasy produktów i opcje domeny niestandardowej mogą się różnić. Zapisz zależność i jej dowody, nie przypisując wyniku jednego klienta każdemu innemu klientowi dostawcy.
Podobnie domena będąca własnością dostawcy w rejestrze publicznym nie wskazuje, że informacje o pacjencie przepływają przez tę usługę. W badaniu nie obserwowano treści danych ani przebiegu postępowania klinicznego. Zachowaj relacje konfiguracyjne oddzielnie od oświadczeń dotyczących przetwarzania danych. Jakakolwiek ocena narażenia danych pacjenta wymagałaby odpowiednich autoryzowanych dowodów i wykwalifikowanej oceny, a nie ekstrapolacji na podstawie nazw DNS .
Zachowaj powtarzalną metodę zbierania
Zamroź mapowanie domeny i zdefiniuj dokładne zapytania, źródła rozpoznawania nazw, okna obserwacyjne, reguły ponawiania prób i wersje analizatora składni. Zachowaj osobno obserwacje autorytatywne i rekurencyjne, jeśli zostały zebrane. RFC 1035 definiuje strukturę DNS ; wielu ciągów TXT w jednym rekordzie nie należy mylić z wieloma rekordami. Interpretacja specyficzna dla protokołu powinna następować po wiernym zachowaniu surowej odpowiedzi.
Zdefiniuj kategorie wyników dla braku danych, błędu nazwy, przekroczenia limitu czasu, awarii serwera, źle sformułowanych zasad i nierozwiązanego wykrycia. Nie zgłaszaj każdego niepowodzenia w zbieraniu danych jako organizacji opieki zdrowotnej nieposiadającej uwierzytelnienia. Zachowaj wszystkie próby w ramach zadeklarowanych zasad ponawiania, aby późniejsi recenzenci mogli ocenić przejściowe niepowodzenia. Dla tego rękopisu nie przeprowadzono żadnego zbierania DNS i nie uwzględniono żadnych wymyślonych wyników skanowania.
Trzymaj wiadomość i dowód transportu oddzielnie
Opublikowany DMARC polityka dotyczy zachowania uwierzytelniania domeny, a nie dowodu zaszyfrowanego transportu lub poufności konkretnej wiadomości. RFC 8461 definiuje MTA-STS w przypadku polityki transportu poczty odbiorczej odrębny mechanizm. Nawet obserwacja polityki transportowej nie ujawnia, czy wysłano konkretną wiadomość kliniczną, jaką drogą została wysłana i co zawierała.
Jeśli przyszłe autoryzowane badanie doda dowody w postaci otrzymanej wiadomości, RFC 8601 wymaga zwrócenia uwagi na granicę zaufania Authentication-Results. Takie dowody wspierałyby obserwację komunikatu o określonym zakresie, a nie domyślne wnioski dotyczące narażenia pacjenta. W projekcie badania należy unikać gromadzenia identyfikatorów pacjentów lub treści komunikatów, gdy rzeczywistym tematem jest konfiguracja publiczna.
Arkusz badań dotyczących opieki zdrowotnej
Utwórz pola dla źródła populacji, daty wypuszczenia, ustawienia opieki, identyfikatora placówki, powiązania systemowego, marki, roli w domenie i dowodów mapowania. Dodaj wagę domeny, dane wejściowe zapytań, znaczniki czasu, skróty surowych dowodów, wersję analizatora składni, kategorię wyników, historię błędów i przyczynę wykluczenia. Dołącz wyraźne pole dotyczące granicy roszczenia stwierdzające, że obserwacja nie ustala sposobu postępowania z danymi pacjenta, narażenia ani zgodności z przepisami.
W ramach przeglądu należy sprawdzić zarówno powtarzalność techniczną, jak i język publikacji. Wynik oznaczony jako brak zasad w próbkowanej domenie internetowej jest węższy niż niezabezpieczona organizacja lub zagrożone dane pacjenta. Użyj wąskiego sformułowania poparte dowodami. Jeżeli faktycznie poważny problem zostanie później wykryty w drodze autoryzowanej pracy, należy zająć się nim w ramach odpowiedniego odpowiedzialnego procesu, a nie wykorzystywać badania publiczne jako nieuzasadniony kanał oskarżeń.
Fikcyjna diagnoza: udostępniona strona internetowa staje się nagłówkiem poświęconym ryzyku dla pacjenta
Fikcyjne badanie przypisuje kilka szpitali do jednej witryny internetowej systemu opieki zdrowotnej i obserwuje nierozwiązane zapytanie uwierzytelniające. Projekt nagłówka twierdzi, że pacjenci wszystkich tych szpitali są narażeni. W proponowanym przeglądzie odrzuca się wnioskowanie: zapytanie nie ustaliło statusu nadawcy operacyjnego, treści wiadomości ani ujawnienia jakichkolwiek danych, a powtarzające się wiersze obiektu nie prowadzą do niezależnych ustaleń.
Zespół zachowa wąski, nierozwiązany wynik DNS , udokumentuje wagę współdzielonej domeny i usunie roszczenie dotyczące narażenia pacjenta. Mógłby przeprowadzić inną, odpowiednio zatwierdzoną ocenę, jeżeli istnieje uzasadniona potrzeba. Ten scenariusz jest fikcyjny i nie zawiera rzeczywistego szpitala, pacjenta, skanu ani zdarzenia. Jego celem jest wykazanie granicy pomiędzy badaniami dotyczącymi konfiguracji publicznej a zarzutami dotyczącymi wrażliwego ryzyka.
Stan wydania
Katalog wymaga wersjonowanego zbioru danych, metody zapytania i dziennika błędów/wykluczeń, które inny analityk może odtworzyć. Te oryginalne artefakty pozostają otwarte. Otwarte pozostają także przegląd specjalistów, możliwość zastosowania źródeł, trasy produkcji, dostępność i zezwolenie właściciela. W tej wersji roboczej przedstawiono metodę specyficzną dla opieki zdrowotnej, a nie przeprowadzone badanie, diagnozę świadczeniodawcy lub wnioski na temat informacji o pacjencie.