Często zadawane pytania dotyczące interfejsu API platformy Azure dla platformy FHIR

Projekt standardu Fast Healthcare Interoperability Resources (FHIR — wymawiany jako „fajer”) to standard współdziałania, którego celem jest umożliwianie wymiany danych opieki zdrowotnej między różnymi systemami opieki zdrowotnej. Ten standard został opracowany przez organizację HL7 i jest przyjmowany przez organizacje opieki zdrowotnej na całym świecie. Najnowsza dostępna wersja standardu FHIR to R4 (wersja 4). Interfejs API platformy Azure dla platformy FHIR obsługuje język R4 i poprzednią wersję STU3 (Standard for Trial Use 3). Aby uzyskać więcej informacji na temat platformy FHIR, odwiedź HL7.org.

Tak, dane są przechowywane w zarządzanych bazach danych na platformie Azure. Interfejs API platformy Azure dla standardu FHIR nie zapewnia bezpośredniego dostępu do bazowego magazynu danych.

W usłudze zarządzanej nie można uzyskać dostępu do danych bazowych. Jest to zapewnienie, że interfejs API platformy Azure for FHIR oferuje certyfikaty dotyczące prywatności i zgodności wymagane dla danych opieki zdrowotnej. Jeśli potrzebujesz dostępu do danych bazowych, możesz użyć serwera FHIR typu open source.

Obsługujemy Microsoft Azure Active Directory jako dostawcę tożsamości.

Nie, nie obsługujemy usługi B2C w interfejsie API platformy Azure for FHIR. Jeśli potrzebujesz bardziej szczegółowych mechanizmów kontroli dostępu, zalecamy zapoznanie się z serwerem proxy FHIR typu open source.

Kopie zapasowe danych usługi zarządzanej są tworzone automatycznie co 4 godziny i są przechowywane dwie kopie zapasowe. Dlatego czas przechowywania wynosi 8 godzin. Odzyskiwanie danych odbywa się przez zespół pomocy technicznej, a cel punktu odzyskiwania (RPO) jest krótszy niż 240 minut.

Klienci mogą wysłać żądanie przywrócenia danych lub zmienić domyślne zasady tworzenia kopii zapasowych danych za pośrednictwem biletu pomocy technicznej.

Obsługujemy wersje 4.0.0 i 3.0.1. Aby uzyskać więcej informacji, zobacz funkcje obsługiwane przez standard FHIR. Możesz również przeczytać o tym, co zmieniło się między wersjami FHIR (STU3 do R4) w historii wersji dla HL7 FHIR.

Usługa Azure IoT Connector for FHIR (wersja zapoznawcza) obecnie obsługuje tylko wersję FHIR R4 i jest widoczna w wystąpieniach R4 interfejsu API platformy Azure for FHIR.

Interfejs API platformy Azure for FHIR to ogólnie dostępna zarządzana usługa FHIR. Usługi Azure Health Data Services umożliwiają wdrażanie usługi FHIR i usługi DICOM w tym samym obszarze roboczym. Omówienie usług Azure Health Data Services zawiera więcej szczegółów.

Interfejs API platformy Azure for FHIR to hostowana i zarządzana wersja serwera Microsoft FHIR dla platformy Azure typu open source. W usłudze zarządzanej firma Microsoft zapewnia całą konserwację i aktualizacje.

Po uruchomieniu serwera FHIR dla platformy Azure masz bezpośredni dostęp do podstawowych usług, ale jesteśmy odpowiedzialni za konserwowanie i aktualizowanie serwera oraz wszystkie wymagane działania związane z zgodnością, jeśli przechowujesz dane PHI.

Mamy ogólną dostępność zarówno dla instytucji publicznych, jak i rządowych w wielu regionach geograficznych. Aby uzyskać informacje o usługach w chmurze dla instytucji rządowych w firmie Microsoft, zobacz Usługi platformy Azure według fedRAMP.

Strona informacji o wersji zawiera omówienie wszystkich elementów dostarczanych do usługi zarządzanej w poprzednim miesiącu.

Aby uzyskać więcej informacji o tym, co jest zwalniane w interfejsie AZURE API for FHIR, zobacz wydania serwera FHIR typu open source. Pracowaliśmy nad tagami elementów za pomocą usługi Azure-API-for-FHIR, jeśli zostaną one wydane w usłudze zarządzanej i są zwykle dostępne dwa tygodnie po ich udostępnieniu na stronie wydania w środowisku open source. Dołączyliśmy również instrukcje dotyczące testowania kompilacji , jeśli chcesz przetestować je we własnym środowisku.

Aby zobaczyć, jaki pakiet wydania znajduje się obecnie w usłudze zarządzanej, możesz wyświetlić instrukcję capability dla interfejsu API platformy Azure for FHIR we software.version właściwości . Zobaczysz, który pakiet został wdrożony.

Dokładną wersję FHIR uwidocznioną w instrukcji capability można znaleźć we fhirVersion właściwości .

Nie. Nie mamy sposobu na zmianę wersji istniejącej bazy danych. Musisz utworzyć nowy interfejs API platformy Azure dla platformy FHIR i ponownie załadować dane. Możesz użyć konwertera JSON do FHIR jako miejsca, aby rozpocząć konwersję danych STU3 na R4.

Nie. Nie można zmienić adresu URL interfejsu API platformy Azure for FHIR.

SMART (substitutable Medical Applications and Reusable Technology) on FHIR to zestaw otwartych specyfikacji do integracji aplikacji partnerskich z serwerami FHIR i innymi systemami IT kondycji, takimi jak elektroniczne rejestry kondycji i wymiany informacji o kondycji. Tworząc aplikację SMART on FHIR, możesz mieć pewność, że aplikacja będzie mogła uzyskiwać dostęp do aplikacji i korzystać z nich w wielu różnych systemach. Aby uzyskać więcej informacji na temat funkcji SMART, odwiedź witrynę internetową SMART Health IT .

Tak, funkcja SMART on FHIR jest obsługiwana przy użyciu przykładów usługi AHDS. Jest to nazywane smart on FHIR(Enhanced). Rozwiązanie SMART on FHIR(Enhanced) można uznać za spełniające wymagania z przewodnikiem implementacji SMART on FHIR (wersja 1.0.0) i §170.315(g)(10) Standardized API dla kryterium usług pacjentów i populacji. Aby uzyskać więcej informacji, odwiedź stronę SMART on FHIR(Enhanced) Documentation (Dokumentacja funkcji SMART on FHIR(Enhanced).

Nie zezwalamy na niestandardowe zasoby FHIR. Jeśli potrzebujesz niestandardowego zasobu FHIR, możesz utworzyć zasób niestandardowy na podstawie zasobu Podstawowego z rozszerzeniami.

Umożliwiamy załadowanie jakichkolwiek prawidłowych danych JSON FHIR do serwera. Jeśli chcesz przechowywać definicję struktury definiującą rozszerzenie, możesz zapisać go jako zasób definicji struktury. Aby wyszukać rozszerzenia, należy zdefiniować własne parametry wyszukiwania.

Zasób musi być nieco poniżej 2 MB. Jest to ograniczenie od bazowego magazynu danych i nie możemy zwiększyć tej wartości.

W usłudze zarządzanej obsługujemy tylko kod JSON. Serwer FHIR typu open source obsługuje pliki JSON i XML. Aby wyświetlić wersję XML w środowisku open source, użyj polecenia _format= application/fhir+xml.

Bieżący limit dla _count wynosi 1000. Jeśli ustawisz _count na więcej niż 1000, zostanie wyświetlone ostrzeżenie w pakiecie, które będzie wyświetlane tylko 1000 rekordów.

W przypadku eksportu grupy eksportujemy tylko dołączone odwołania z grupy, a nie wszystkie cechy zasobu grupy.

Obecnie obsługujemy publikowanie pakietów wsadowych, ale nie obsługujemy publikowania pakietów transakcji w interfejsie API platformy Azure for FHIR. Jeśli potrzebujesz obsługi pakietu transakcji, możesz użyć usługi FHIR w usługach Azure Health Data Services.

Możesz użyć operacji cierpliwej $everything lub użyć wyszukiwania przedziałów w interfejsie API platformy Azure for FHIR. Dzięki temu można uzyskać wszystkie zasoby związane z konkretnym pacjentem. Należy pamiętać, że przedział pacjenta zawiera wszystkie zasoby związane z pacjentem, ale nie sam pacjent, więc należy również wyszukać, aby uzyskać pacjenta, jeśli potrzebujesz zasobu pacjenta w wynikach.

Obsługujemy sortowanie według daty ostatniej aktualizacji: _sort=_lastUpdated. Obsługujemy również _sort elementów FirstName, LastName, BirthDate i ClinicalDate. Aby uzyskać więcej informacji na temat innych obsługiwanych parametrów wyszukiwania, zobacz Omówienie wyszukiwania FHIR.

Tak, mamy wsparcie dla $everything pacjentów. Aby uzyskać więcej informacji, zobacz Przewodnik dotyczący $Everything pacjentów.

Nie, interfejs API platformy Azure for FHIR nie obsługuje obecnie operacji terminologii.

$export jest częścią specyfikacji FHIR. Jeśli usługa FHIR jest skonfigurowana przy użyciu tożsamości zarządzanej i konta magazynu, a tożsamość zarządzana ma dostęp do tego konta magazynu, możesz wywołać $export interfejsu API FHIR, a wszystkie zasoby FHIR zostaną wyeksportowane na konto magazynu. Aby uzyskać więcej informacji, zobacz artykuł $export.

Mamy narzędzie open source do deidentyfikowania danych FHIR. Ta sama technologia jest również zintegrowana z interfejsem API platformy Azure for FHIR w postaci de-zidentyfikowanego eksportu.

Zanonimizowany eksport jest obecnie obsługiwany tylko w przypadku pełnego eksportu systemu (/$export), a nie eksportu pacjenta (/Pacjenta/$export). Pracujemy nad udostępnieniem go również na poziomie pacjenta.

Istnieją dwa podstawowe typy usuwania obsługiwane w interfejsie AZURE API for FHIR. Są to usuwanie i usuwanie warunkowe.

• Za pomocą opcji Usuń można wybrać usuwanie nietrwałe (najczęściej używanego typu) i nadal mieć możliwość odzyskania historycznych wersji rekordu.
• W przypadku usuwania warunkowego można przekazać kryteria wyszukiwania, aby usunąć zasób jeden element jednocześnie lub kilka naraz.
• W przypadku usunięcia lub usunięcia warunkowego po przekazaniu parametru hardDelete wszystkie rekordy i historia zostaną usunięte i nieodwracalne.

Jeśli nie używasz parametru hardDelete , możesz odzyskać usunięte pliki. Rekordy w interfejsie AZURE API for FHIR powinny nadal istnieć. Rekordy można znaleźć, wyszukując historię zasobu i wyszukując ostatnią wersję z danymi.

Aby uzyskać szczegółowe informacje na temat włączania dzienników inspekcji i przykładowych zapytań, zobacz Włączanie rejestrowania diagnostycznego w interfejsie AZURE API for FHIR. Jeśli chcesz uwzględnić dodatkowe informacje w dziennikach, zobacz używanie niestandardowych nagłówków HTTP.

Aby rozwiązać ten problem, możesz zwiększyć przepływność lub przełączyć się na skalowanie automatyczne , aby upewnić się, że masz wystarczającą ilość zasobów obliczeniowych do przetwarzania żądań. Jeśli nadal występują problemy, otwórz bilet pomocy technicznej.

Minimalna wartość ru musi wynosić co najmniej 40 RU na GB. Podczas ładowania danych liczba jednostek RU w bazie danych będzie zwiększana, jeśli jesteś poniżej tej minimalnej wartości.

Mamy kolekcję architektur referencyjnych dostępnych na stronie GitHub Architektura kondycji.

Aby przeprowadzić kontrolę kondycji w usłudze FHIR, wprowadź {{fhirurl}}/health/check w żądaniu GET. Powinien być widoczny stan usługi FHIR. Odpowiedź kodu stanu HTTP z 200 i GeneralStatus jako "W dobrej kondycji" w odpowiedzi oznacza, że sprawdzanie kondycji zakończyło się pomyślnie. W przypadku błędów otrzymasz odpowiedź na błąd z kodem stanu HTTP 404 (Nie znaleziono) lub kodem stanu 500 (wewnętrzny błąd serwera) i szczegółowymi informacjami w treści odpowiedzi w niektórych scenariuszach.

Tak, interfejs API platformy Azure for FHIR umożliwia konfigurowanie kluczy zarządzanych przez klienta przy użyciu obsługi usługi Azure Cosmos DB. Aby uzyskać więcej informacji na temat szyfrowania danych przy użyciu klucza osobistego, zobacz Konfigurowanie kluczy zarządzanych przez klienta w usłudze REST.