Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Zdarzenia umożliwiają subskrybowanie zmian danych w usłudze FHIR® lub DICOM® i otrzymywanie powiadomień za pośrednictwem Azure Event Grid. Zdarzenia umożliwiają wyzwalanie przepływów pracy, automatyzowanie zadań, wysyłanie alertów i nie tylko. W tych często zadawanych pytaniach znajdziesz odpowiedzi na kilka typowych pytań dotyczących zdarzeń.
Can używać zdarzeń z nie-Microsoft FHIR lub USŁUGI DICOM?
Nie. Funkcja Zdarzenia obsługuje tylko usługi Azure Health Data Services FHIR i DICOM.
Jakie zmiany zasobów FHIR są obsługiwane przez zdarzenia?
Zdarzenia są generowane na podstawie następujących typów usług FHIR.
FhirResourceCreated. Zdarzenie emitowane po utworzeniu zasobu FHIR.
FhirResourceUpdated. Zdarzenie emitowane po zaktualizowaniu zasobu FHIR.
FhirResourceDeleted. Zdarzenie emitowane po usunięciu zasobu FHIR jest nietrwałe.
Aby uzyskać więcej informacji na temat typów usuwania w usłudze FHIR, zobacz REST API capabilities in the FHIR service in Azure Health Data Services (Funkcje interfejsu API FHIR w usłudze FHIR).
Czy zdarzenia obsługują pakiety FHIR?
Tak. Funkcja zdarzeń emituje powiadomienia o zmianach danych na poziomie zasobu FHIR.
Zdarzenia obsługują następujące typy pakietów FHIR.
Batch. Zdarzenie jest emitowane dla każdej pomyślnej operacji zmiany danych w pakiecie. Jeśli jedna z operacji generuje błąd, żadne zdarzenie nie jest emitowane dla tej operacji.
Na przykład: pakiet wsadowy zawiera pięć operacji, z których jeden zawiera błąd. Zdarzenia są emitowane dla czterech pomyślnych operacji bez zdarzeń emitowanych dla operacji, która wygenerowała błąd.Transakcja. Zdarzenie jest emitowane dla każdej pomyślnej operacji pakietu, o ile nie ma żadnych błędów. Jeśli w pakiecie transakcji występują błędy, żadne zdarzenia nie są emitowane.
Na przykład: pakiet wsadowy zawiera pięć operacji, z których jeden zawiera błąd. Żadne zdarzenia nie są emitowane dla tego pakietu.
Note
Zdarzenia nie są wysyłane w sekwencji operacji danych w pakiecie FHIR.
Jakie zmiany obrazu DICOM obsługują zdarzenia?
Zdarzenia są generowane na podstawie następujących typów usług DICOM:
DicomImageCreated. Zdarzenie emitowane po utworzeniu obrazu DICOM.
DicomImageDeleted. Zdarzenie emitowane po usunięciu obrazu DICOM.
DicomImageUpdated. Zdarzenie emitowane po zaktualizowaniu obrazu DICOM. Aby uzyskać więcej informacji, zobacz Aktualizowanie plików DICOM.
Jaki jest ładunek komunikatu o zdarzeniach?
Opis struktury komunikatów zdarzeń, w tym wymaganych i nieprzychyłych elementów, można znaleźć w temacie Event message structures (Struktury komunikatów zdarzeń).
Jaka jest przepływność komunikatów zdarzeń?
Przepływność usługi FHIR lub DICOM oraz usługa Event Grid zarządza przepływnością zdarzeń FHIR i DICOM. Po pomyślnym wysłaniu żądania do usługi FHIR zwraca on kod stanu HTTP 2xx. Generuje również zasób FHIR lub zdarzenie zmiany obrazu DICOM. Bieżące ograniczenie to 5000 zdarzeń na sekundę na obszar roboczy dla wszystkich wystąpień usługi FHIR lub DICOM w obszarze roboczym.
Jak są naliczane opłaty za korzystanie ze zdarzeń?
Za korzystanie ze zdarzeń
Jak subskrybować oddzielnie wiele usług FHIR lub DICOM w tym samym obszarze roboczym?
Użyj funkcji filtrowania usługi Event Grid. W ładunku komunikatu o zdarzeniach istnieją unikatowe identyfikatory w celu odróżnienia kont i obszarów roboczych. Globalny unikatowy identyfikator obszaru roboczego można znaleźć w polu source, które jest identyfikatorem zasobu Azure. Możesz zlokalizować unikatową nazwę konta FHIR w tym obszarze roboczym data.resourceFhirAccount w polu. Unikatową nazwę konta DICOM można znaleźć w obszarze roboczym data.serviceHostName w polu . Podczas tworzenia subskrypcji użyj operatorów filtrowania, aby wybrać zdarzenia, które chcesz uwzględnić w subskrypcji.
Czy mogę użyć tego samego subskrybenta dla wielu obszarów roboczych, kont FHIR lub kont DICOM?
Tak. Użyj różnych subskrybentów dla każdej usługi FHIR lub DICOM, aby włączyć przetwarzanie w izolowanych zakresach.
Czy usługa Event Grid jest zgodna z wymaganiami dotyczącymi zgodności HIPAA i HITRUST?
Tak. Usługa Event Grid obsługuje zobowiązania Health Insurance Portability and Accountability Act (HIPAA) i Health Information Trust Alliance (HITRUST). Aby uzyskać więcej informacji, zobacz Microsoft Azure Compliance Offerings.
Jak długo trwa odbieranie komunikatu o zdarzeniach?
Po pomyślnym żądaniu HTTP otrzymasz średnio komunikat o zdarzeniach w ciągu jednej sekundy. 99.99% komunikatów o zdarzeniach są dostarczane w ciągu pięciu sekund, chyba że osiągnięto ograniczenie usługi FHIR, usługi DICOM lub usługi Event Grid .
Czy można odbierać zduplikowane komunikaty o zdarzeniach?
Tak. Usługa Event Grid gwarantuje co najmniej jedno dostarczanie komunikatów zdarzeń w trybie wypychania. Mogą wystąpić przypadki, gdy żądanie dostarczenia zdarzeń zwraca kod stanu błędu przejściowego. W takiej sytuacji usługa Event Grid traktuje ją jako niepowodzenie dostarczania i ponownie wysyła komunikat o zdarzeniach. Aby uzyskać więcej informacji, zobacz Azure Event Grid dostarczanie i ponawianie.
Ogólnie rzecz biorąc, upewnij się, że idempotentność dla subskrybenta zdarzenia. Identyfikator zdarzenia lub kombinacja wszystkich pól we data właściwości zawartości wiadomości są unikatowe dla każdego zdarzenia. Można polegać na nich, aby deduplikować.
Jak uniknąć opóźnienia przetwarzania zdarzeń usługi AHDS w okresach długotrwałych operacji zapisu na dużą skalę, takich jak scenariusze importowania na dużą skalę lub pozyskiwania zbiorczego?
To zachowanie jest spowodowane podstawową architekturą przetwarzania zdarzeń, w której generowanie i dostarczanie zdarzeń działa asynchronicznie z pozyskiwania danych. Gdy przepływność pozyskiwania przekracza pojemność przetwarzania systemu zdarzeń, może utworzyć listę prac, co powoduje opóźnienie dostarczania zdarzeń. W obserwowanych przypadkach to opóźnienie może trwać do wielu dni i nie jest ograniczane wyłącznie przez skalowanie obliczeniowe.
Aby zapewnić, że zdarzenia pozostają zgodne z pozyskiwaniem danych, należy wziąć pod uwagę następujące podejścia:
- Ograniczanie przepływności pozyskiwania do szybkości przetwarzania przez system zdarzeń niemal w czasie rzeczywistym.
- Wstrzymywanie lub przygotowywanie importu zbiorczego okresowo w celu umożliwienia systemowi zdarzeń nadrabiania zaległości.
- Zaplanuj spójność ostateczną podczas dostarczania zdarzeń podczas obciążeń o dużej ilości.