Bezpieczne i wydajne zarządzanie danymi dotyczącymi zdrowia ma kluczowe znaczenie dla organizacji opieki zdrowotnej. Usługi Azure Health Data Services zapewniają zaawansowaną platformę, której te organizacje mogą używać do przechowywania, przetwarzania i analizowania poufnych danych przy jednoczesnym przestrzeganiu rygorystycznych standardów zabezpieczeń i zgodności. Jednak wdrażanie usług danych kondycji w złożonym środowisku przedsiębiorstwa może być trudne, jeśli nie masz przewodnika po architekturze referencyjnej i implementacji.
Ten artykuł zawiera przykładową architekturę, towarzyszący przykładową implementację oraz strategię wdrażania usług danych kondycji z rozszerzonymi zabezpieczeniami i integrowania jej z innymi usługami platformy Azure. Postępując zgodnie z praktykami opisanymi w tym przewodniku, możesz zwiększyć możliwość ochrony danych zdrowotnych.
Architektura
Pobierz plik programu Visio z tą architekturą.
Przepływ pracy
- aplikacja systemu Azure Gateway odbiera pojedyncze komunikaty fast healthcare Interoperability Resources (FHIR) (na przykład dane pacjentów) za pośrednictwem połączenia TLS z rozszerzonymi zabezpieczeniami, które korzysta z przepływu poświadczeń klienta. Usługa Application Gateway wysyła dane za pośrednictwem usługi Azure API Management do usługi FHIR usług danych kondycji, gdzie są one utrwalane.
- Jednocześnie klient może odczytywać te same dane FHIR za pośrednictwem połączenia TLS za pośrednictwem usługi Application Gateway i usługi API Management.
- W przypadku przetwarzania zbiorczego danych usługa Application Gateway odbiera pakiety FHIR za pośrednictwem połączenia TLS, które używa przepływu poświadczeń klienta i ładuje dane na konto magazynu. Funkcja platformy Azure FHIR Loader zintegrowana z siecią wirtualną przetwarza pakiety FHIR i ładuje dane do usługi FHIR.
- Jeśli dane przychodzące są w formacie HL7 w wersji 2 lub C-CDA, możesz najpierw przekonwertować je na format FHIR przy użyciu punktu końcowego $convert-data w usłudze FHIR. Następnie możesz opublikować dane w usłudze FHIR przy użyciu usługi Application Gateway. Usługa Azure Container Registry, połączona za pośrednictwem prywatnego punktu końcowego, służy do przechowywania, z rozszerzonymi zabezpieczeniami, dostosowanymi szablonami Liquid do konwertowania danych HL7 v2 lub C-CDA na dane FHIR. Usługa Container Registry jest wyświetlana na diagramie architektury, ale konwersja HL7 v2/C-CDA na FHIR za pośrednictwem
$convert-data
nie jest implementowana przez przykładowy szablon implementacji Bicep. - Funkcja FHIR do agenta synchronizacji usługi Synapse wyodrębnia dane z usługi FHIR (w przypadku danych pozyskanych za pośrednictwem pojedynczego lub zbiorczego przepływu danych), konwertuje wyodrębnione dane na hierarchiczne pliki Parquet i zapisuje je w usłudze Azure Data Lake Storage.
- Usługa Azure Synapse Analytics używa bezserwerowej puli SQL lub Spark do nawiązywania połączenia z usługą Data Lake Storage w celu wykonywania zapytań i analizowania danych FHIR. Usługa Azure Synapse Analytics jest wyświetlana na diagramie architektury, ale nie jest implementowana przez szablon implementacji Bicep.
- Sieć wirtualna piasty zawiera maszynę wirtualną przesiadkową i hosta usługi Azure Bastion w celu zapewnienia rozszerzonego dostępu zabezpieczeń do konfiguracji usługi FHIR. Administratorzy i operatorzy mogą również używać maszyny wirtualnej przesiadkowej do testowania punktów końcowych usługi FHIR bez przekazywania przez usługę Application Gateway i ręcznego ładowania danych FHIR za pośrednictwem usługi Azure Storage, pomijając usługę Application Gateway.
- Jeśli ustanowisz lokalną łączność sieciową za pośrednictwem usługi Azure ExpressRoute lub sieci VPN typu lokacja-lokacja, lokalni użytkownicy i usługi będą mogli bezpośrednio uzyskać dostęp do usługi FHIR za pośrednictwem tego połączenia.
Uwaga
Opcjonalnie można dodać zaporę aplikacji internetowej (WAF) do usługi Application Gateway, ale istnieje znany problem z błędną identyfikacją obiektów FHIR zapory aplikacji internetowej i traktowanie ich jako złośliwego kodu. Jeśli potrzebujesz zapory aplikacji internetowej, musisz ręcznie zmodyfikować zestaw reguł zapory aplikacji internetowej, aby umożliwić zaporze aplikacji internetowej pracę z obiektami FHIR.
Składniki
Microsoft Entra ID to wielodostępna usługa katalogów w chmurze i zarządzania tożsamościami. Aplikacje klienckie są rejestrowane w usłudze Microsoft Entra ID i mogą być używane do uzyskiwania dostępu do usługi FHIR usług Azure Health Data Services.
Application Gateway to usługa typu "platforma jako usługa" (PaaS) w warstwie 7, która może działać jako usługa zwrotnego serwera proxy. Użytkownicy wewnętrzni i zewnętrzni uzyskują dostęp do interfejsów API FHIR za pośrednictwem usługi Application Gateway za pośrednictwem usługi API Management.
Usługa API Management to hybrydowa platforma wielochmurowa do zarządzania interfejsami API we wszystkich środowiskach. Interfejsy API FHIR można zaimportować do usługi API Management przy użyciu definicji interfejsu API programu Swagger. Usługi API Management można użyć do ograniczania wywołań przychodzących, uwierzytelniania/autoryzowania użytkowników i wykonywania innych zadań.
Health Data Services to zestaw zarządzanych usług interfejsu API opartych na otwartych standardach i strukturach, które umożliwiają przepływy pracy, które zwiększają opiekę zdrowotną i oferują skalowalne, ulepszone rozwiązania opieki zdrowotnej. Usługa FHIR usług danych kondycji jest wdrażana z prywatnym punktem końcowym, aby zapewnić, że dostęp do niej można uzyskać tylko z sieci wirtualnej lub przez użytkowników zewnętrznych za pośrednictwem Internetu za pośrednictwem usługi Application Gateway.
FHIR Loader to rozwiązanie usługi Azure Functions, które zapewnia usługi importowania pakietów FHIR (skompresowanych i nie skompresowanych) oraz plików NDJSON do usługi FHIR.
Azure Key Vault to usługa platformy Azure służąca do przechowywania i uzyskiwania dostępu do wpisów tajnych, kluczy i certyfikatów z ulepszonymi zabezpieczeniami. Usługa Key Vault zapewnia zabezpieczenia oparte na module HSM i inspekcję dostępu za pośrednictwem kontroli dostępu opartej na rolach, które są zintegrowane z identyfikatorem Entra firmy Microsoft. W tej architekturze usługa Key Vault przechowuje poświadczenia serwera przesiadkowego, certyfikaty usługi Application Gateway, szczegóły usługi FHIR i szczegóły modułu ładującego FHIR.
Container Registry to zarządzana usługa rejestru oparta na rejestrze platformy Docker typu open source 2.0. W tej architekturze jest używana do hostowania szablonów Liquid . Możesz użyć niestandardowego punktu końcowego
$convert-data
w usłudze FHIR, aby przekonwertować dane kondycji z HL7 v2 i C-CDA na FHIR. Operacja$convert-data
używa szablonów Liquid z konwertera FHIR do konwersji danych FHIR.FHIR to Synapse Sync Agent to aplikacja kontenera platformy Azure, która wyodrębnia dane z serwera FHIR przy użyciu interfejsów API zasobów FHIR, konwertuje je na hierarchiczne pliki Parquet i zapisuje je w usłudze Data Lake Storage niemal w czasie rzeczywistym. Zawiera również skrypt do tworzenia zewnętrznych tabel i widoków w bezserwerowej puli SQL usługi Azure Synapse Analytics, która wskazuje pliki Parquet. Chociaż diagram architektury przedstawia środowisko FHIR dla agenta synchronizacji usługi Synapse, usługi Data Lake Storage i usługi Azure Synapse Analytics, implementacja Bicep nie zawiera obecnie kodu służącego do wdrażania tych usług.
Azure Firewall to natywna dla chmury usługa inteligentnej zapory sieciowej, która zapewnia ochronę przed zagrożeniami dla obciążeń w chmurze na platformie Azure. W tej architekturze tabela tras służy do kierowania ruchu wychodzącego z sieci wirtualnej koncentratora za pośrednictwem usługi Azure Firewall w celu zapewnienia, że eksfiltracja danych nie wystąpi. Podobnie można utworzyć trasy tabeli tras i dołączyć je do podsieci sieci wirtualnej będącej szprychą, aby zapobiec eksfiltracji danych informacji o zdrowiu publicznym (PHI).
Serwer przesiadkowy to maszyna wirtualna platformy Azure z systemem Linux lub Windows, z którą administratorzy i operatorzy mogą łączyć się przy użyciu protokołu RDP (Remote Desktop Protocol) lub Secure Shell (SSH). Ponieważ większość usług (Health Data Services, API Management, Key Vault i inne) w tej architekturze jest wdrażana przy użyciu prywatnego punktu końcowego, potrzebna jest maszyna wirtualna przesiadkowa, aby wprowadzić zmiany konfiguracji lub przetestować te usługi. Dostęp do serwera przesiadkowego można uzyskać tylko za pośrednictwem usługi Azure Bastion.
Usługa Azure Bastion umożliwia nawiązywanie połączenia z maszyną wirtualną przy użyciu przeglądarki, witryny Azure Portal lub natywnego klienta SSH/RDP na komputerze. W tej implementacji usługa Azure Bastion zapewnia zwiększony dostęp zabezpieczeń do maszyny wirtualnej serwera przesiadkowego.
Defender dla Chmury i inicjatywy zasad zgodności HIPAA i HITRUST pomagają zapewnić, że wdrożenie infrastruktury platformy Azure jest zgodne z wymaganiami firmy Microsoft dotyczącymi testów porównawczych zabezpieczeń w chmurze i zgodności z branży opieki zdrowotnej.
Szczegóły scenariusza
To rozwiązanie zawiera wskazówki dotyczące wdrażania usług danych kondycji z zwiększonymi zabezpieczeniami, pozyskiwania pojedynczych i zbiorczych danych FHIR oraz utrwalania danych w usłudze Health Data Services FHIR.
Za pomocą rozwiązania można ładować komunikaty FHIR pojedynczo i zbiorczo do usługi FHIR przy użyciu połączenia usługi Application Gateway z rozszerzonymi zabezpieczeniami.
Aby przeanalizować dane FHIR i wyodrębnić szczegółowe informacje, możesz wdrożyć środowisko FHIR w agencie synchronizacji usługi Synapse, jak pokazano na diagramie. Usługa Azure Synapse Analytics może łączyć się z usługą Data Lake Storage w celu wykonywania zapytań i analizowania danych FHIR.
Rozwiązanie można rozszerzyć, aby otrzymywać dane z urządzeń medycznych i urządzeń do noszenia przy użyciu usługi Health Data Services MedTech. Za pomocą tej usługi można przekształcać dane w format FHIR i utrwalać je w usłudze FHIR, aby można było wyodrębnić szczegółowe informacje przy użyciu usługi Azure Synapse Analytics.
Możesz również rozszerzyć rozwiązanie na pozyskiwanie danych innych niż FHIR (HL7 v2 i C-CDA), przekonwertować je na FHIR przy użyciu szablonów Liquid, które można przechowywać w usłudze Container Registry i utrwalać je w usłudze FHIR.
Wdróż to rozwiązanie
Aby wdrożyć to rozwiązanie, wykonaj kroki opisane w temacie Wprowadzenie.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Umar Mohamed Usman | Główny inżynier
Inni współautorzy:
- Mick Alberts | Składnik zapisywania technicznego
- Srini Padala | Starszy inżynier
- Sonalika Roy | Starszy inżynier
- Victor Santana | Starszy inżynier
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- Warsztaty dotyczące usługi Azure Health Data Services
- Rozpoczynanie pracy z usługami Azure Health Data Services
- Moduł ładujący i eksport zbiorczy FHIR
- Generowanie struktury Swagger serwera FHIR dla usługi API Management
- Konwertowanie danych HL7 v2 i C-CDA za pomocą konwertera FHIR