pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007
Rozdział 22
w
w
Zastosowanie protokołu DICOM oraz technologii
J2EE w komunikacji między urządzeniami
medycznymi a bazą danych
1 Wstęp
da
.b
w
Streszczenie. Głównym celem artykułu jest przedstawienie programu do
zdalnego łączenia się za pomocą przeglądarki internetowej ze skanerami
rezonansu magnetycznego z wykorzystaniem protokółu DICOM oraz
przesyłania obrazów z wybranego skanera do dowolnej bazy danych.
Program stanowi rozszerzenie autorskiej aplikacji „Medical Image Storage
System” służącej do przechowywania i dostarczania użytkownikowi
wymaganych danych medycznych. Rozwiązanie oparte jest na bazie danych
Oracle oraz biblioteki firmy PixelMed Publishing służące do komunikacji po
protokole DICOM. Produkt został wdrożony w szpitalu klinicznym
w Aarhus.
pl
s.
Opisywany w niniejszym artykule projekt jest kontynuacją systemu Medical Image Storage
System. Program jest realizacją wymagań lekarzy z komórki badawczej MR Center
Szpitala Uniwersyteckiego w Aarhus w Danii, którzy potrzebowali systemu do
gromadzenia i wymiany dużej ilości obrazów powstających podczas badań FMRI (ang.
Functional Magnetic Resonance Imaging). W trakcie tego typu badań mierzona jest
aktywność w poszczególnych obszarach mózgu podczas wykonywania określonych
czynności przez pacjenta umieszczonego w urządzeniu do wykonywania rezonansu
magnetycznego. Badanie to charakteryzuje się tym, że generowanych jest od kilku do
kilkunastu tysięcy obrazów.
Celem powstałej części projektu było opracowanie aplikacji pozwalającej na zdalne
łączenie się z urządzeniami i przesyłanie badań pacjentów do bazy danych Oracle, przy
czym protokołem komunikacyjnym był DICOM [15]–[20]. Aplikacja miała działać pod
kontrolą dowolnego systemu operacyjnego, być intuicyjna w obsłudze i posiadać cechę
łatwej rozbudowy. Niniejszy artykuł prezentuje poszczególne elementy funkcjonalne
powstałej aplikacji, przedstawia jej położenie w systemie oraz charakteryzuje użyte
technologie. Świadectwem dużego zainteresowania tą tematyką jest duża liczba publikacji
poświęconych rozwiązaniom podobnych problemów w różnych technologiach [1]–[14].
Konrad Wojciechowski, Adam Pelikant
Instytut Mechatroniki i Systemów Informatycznych, ul. Stefanowskiego 18/22, 93-590 Łódź
email: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2007
K. Wojciechowski, A. Pelikant
2 Założenia projektowe
w
Jednym ze wstępnych wymagań projektowych było napisanie aplikacji w architekturze
klient – serwer, która byłaby przenośna pomiędzy różnymi platformami systemowymi.
Wymogło to decyzję o użyciu technologii Java. Ponadto aplikacja została napisana
w oparciu o przeglądarkę internetową, co wyeliminowało konieczność instalowania
dodatkowych narzędzi na stacjach roboczych i zapewniło możliwość łączenia się
z dowolnego miejsca poprzez aplikację z urządzeniem skanera. Przy odpowiednio
skonfigurowanej sieci internetowej możliwe jest zatem połączenie z komputerem skanera
z dowolnego miejsca na świecie. W praktyce szpitalnej aplikacja jednak działa w obrębie
sieci wydzielonej.
Kolejną ważną cechą utworzonego oprogramowania jest jego wielozadaniowość.
Pozwala ona na jednoczesną pracę wielu użytkowników, którzy niezależnie mogą przesyłać
dane z różnych skanerów medycznych do bazy danych Oracle lub też innych urządzeń
medycznych. Modularna budowa aplikacji sprawia, ze w czasie zapisywania danych do
bazy przez jeden proces możliwe jest jednoczesne przesyłanie obrazów z bazy danych
Oracle na komputer użytkownika lub też inny komputer działający w sieci.
Ponadto stworzone oprogramowanie umożliwia zdalne swobodne przeglądanie
i eksplorację bazy danych komputera skanera na różnych poziomach szczegółowości
danych. Możliwe jest też dowolne wybieranie, filtrowanie danych do przesłania.
Na rys. 1 przedstawiono całość opracowanego systemu. Zacieniowano moduły
stanowiące przedmiot niniejszego artykułu.
da
.b
w
w
Folder na dysku
do
przechowywania
obrazów
Listener
Java Runtime
Enviroment
tmconfig.x
Sdiconfig.x
Komputer
skanera
pl
s.
Baza
Danych
Serwer Apache
Transfer
Manger
Serwer Oracle oraz serwer
Image
Explorer
Komputer
użytownik
a
Rys. 1. Schemat blokowy systemu do obsługi skanerów medycznych oparty na protokole
DICOM
Stworzone oprogramowanie jest równoległym modułem uzupełniającym poprzednie dwie
aplikacje (Image Explorer i Listener) [1]. Działa on, podobnie jak poprzednie, pod kontrolą
serwera Apache Tomcat, który wysyła interfejs aplikacji do przeglądarki działającej na
komputerze użytkownika. Do pełnego działania aplikacji wymagana jest instalacja
Maszyny Wirtualnej Java. Konfiguracja aplikacji przechowywana jest w pliku
tmconfig.xml.
230
Zastosowanie protokołu DICOM oraz technologii J2EE w komunikacji między...
3 Przechowywanie i przetwarzanie danych
w
Podstawą stworzonego systemu stanowi serwer danych ORACLE tworzący szkielet
aplikacji, oraz część pośrednią pomiędzy interfejsem zbierającym informację – Listenerem,
a częścią prezentującą dane – Image Explorerem. Wybór rozwiązania firmy Oracle został
podyktowany koniecznością spełnienia warunków niezawodności oraz bezpieczeństwa
przechowywanych danych, a także koniecznością zapewnienia niezależności od platformy
sprzętowej, a w szczególności bezproblemowego działania zarówno w środowisku
Microsoft Windows, jak i Linux. Tabele przechowujące dane w bazie, podzielić można na
dwie grupy, ze względu na pełnione funkcje: tabele opisujące przechowywane dane
medyczne oraz tabele pomocnicze, wspomagające zarządzanie informacją rys. 2 oraz rys. 3.
da
.b
w
w
Rys. 2. Schemat tabel przechowujących dane medyczne
Zadania najważniejszych tabel systemu polegają na:
− EXAMINATIONS: tabela centralna przechowująca dane odpowiadające poziomowi
pojedynczego badania – najwyższemu poziomowi zagnieżdżenia danych.
pl
s.
− PATIENTS: przechowuje dane dotyczące pojedynczego pacjenta, bardzo ważnym
parametrem jest waga stanowiąca podstawę do wyznaczania maksymalnego pola
magnetycznego, jakiego działaniu może zostać poddany pacjent.
− SERIES: zawiera dane związane z kolejnym poziomem zagnieżdżenia – serii i
zawiera dane niezmienne w obrębie całej serii, takie jak np.: grubość otrzymywanych
podczas skanowania „plastrów”, rozdzielczość obrazka itp.
− IMAGES: najniższy poziom zagnieżdżenia zbieranych danych medycznych
opisujący pojedynczy obraz.
− CONSTANTS: przechowuje dane niezmienne, lub rzadko zmieniające się, jak wersja
protokołu DICOM zaimplementowana w skanerach, ale przede wszystkim katalog
przechowywania pobieranych elementów plików.
− SCANNERS: Jednostka opisuje urządzenia medyczne produkujące obrazy,
znajdujące się w systemie.
231
Ponadto baza danych zawiera tabele pomocnicze zawierające informacje związane z
utrzymywaniem bezpieczeństwa dostępu do danych, przypisywaniem uprawnień,
operacjami administracyjnymi i zmianami struktury, logowaniem do systemu oraz
operacjami zwalniania przestrzeni danych (rys. 3).
w
w
w
Rys. 3. Schemat tabel przechowujących dane pomocnicze
pl
s.
da
.b
W celu poprawy wydajności przetwarzania dodane zostały globalne tabele tymczasowe,
które pozwalają przechowywać „oddzielnie” dane z pojedynczej transakcji. Pozwala to
zastosowanie wbudowanych mechanizmów optymalizacji przy wykonywaniu dużej ilości
operacji wstawiania i usuwania wierszy.
Jednym z bardziej kluczowych założeń projektu było przeniesienie możliwie wielu
zadań związanych z przetwarzaniem na poziom serwera danych i stosowanie tzw.
cienkiego klienta. Stąd większość operacji zostało przeniesione do pakietów rozszerzenia
proceduralnego PL/SQL. Ten krok w znacznym stopniu uniezależnia produkt finalny od
obranego języka programowania, odpowiedzialnego za stworzenie interfejsu użytkownika.
Dodatkowym atutem, nabierającym szczególnego znaczenia w systemach rozproszonych,
wspieranych przez technologię J2EE, jest minimalizowanie odwołań do bazy danych, a
jednocześnie optymalizacja przetwarzania informacji, przez prekompilowane procedury i
funkcje. Opracowane pakiety odpowiadają za:
− ImageGather - zawiera funkcje i procedury wykorzystywane przez część zbierającą
dane. Ponieważ każdy pojedynczy plik w standardzie DICOM, jest samoopisującą
się strukturą, która przechowuje informacje o serii i badaniu z jakiego pochodzi, to
podczas katalogowaniu takiego pliku, sprawdzać należy, czy dane badanie, seria,
pacjent i skaner nie są już umieszczone w bazie. Jeśli taka informacja jest już
zapisana należy wstawiać odpowiednie klucze obce w tabelach, w przeciwnym
wypadku uzupełniać także te tabele nadrzędne. Przy wstawianiu danych,
dokonywana jest też niezbędna konwersja formatu daty i czasu, jako że nie są one po
stronie DICOM ustandaryzowane i dopuszczalna jest ich dowolność, byleby tylko
mieściły się w 16 znakach. Na części zbierającej dane, spoczął też obowiązek
cyklicznego dokonywania sprawdzenia wolnego miejsca na dysku twardym
przeznaczonym na magazynowanie plików, oraz kasowania niepotrzebnych danych
np. z tabel logów.
− ImageStore – zawierający szereg funkcji i procedur związanych z częścią
prezentacyjną zaprojektowanego systemu. Najczęściej wykorzystywanymi funkcjami
są te, których wyniki są podstawą do budowania drzewa, ułatwiającego przeglądanie
danych w interfejsie użytkownika oraz funkcja zwracająca liczbę i rozmiar plików
dla poszczególnych poziomów drzewa. Kolejną funkcją pakietu jest archiwizowanie
danych na różnych poziomach (daty, badania, serii, pojedynczego obrazu). W
232
pakiecie tym znajduje się też szereg funkcji wspomagających zarządzanie dostępem
do informacji. Są to m.in. funkcje odpowiedzialne za dodawanie i usuwanie
użytkowników z bazy, zarządzające logowaniem do systemu oraz zwracające logi,
ułatwiające administratorowi zarządzanie zmagazynowaną informacją medyczną.
w
4 Rozwiązania programistyczne
da
.b
w
w
Dotychczasowe rozwiązanie [1] pozwalało na przesyłanie obrazów z bazy danych skanera
(przy czym proces był inicjalizowany poprzez komputer skanera) do bazy danych Oracle
oraz ich pobieranie z dowolnego komputera instytutu za pomocą przeglądarki internetowej.
Proces przebiega według schematu:
− Program Listener, napisany w języku Java, oparty o biblioteki firmy PixelMed
służące do komunikacji po protokole DICOM [14]–[20], nasłuchuje na określonym
porcie na połączenia ze skanerów. Gdy takie połączenie jest zestawione uruchamiany
jest nowy wątek obsługujący to połączenie tak, żeby można było nasłuchiwać na
połączenia z innych skanerów. Utworzony wątek zaczyna zapisywać w pamięci
kolejne przychodzące pakiety zawierające fragmenty obrazu medycznego. Gdy
skaner wyśle informację, że dany fragment jest już ostatnim program wysyła
potwierdzenie poprawnego otrzymania pliku i zaczyna je analizować. Odczytywany
jest nagłówek. Zawarte w nim informacje porównywane są z informacją
przechowywaną w bazie danych. Jeśli w tabelach znajdują się już wpisy na temat
takiego pliku nie jest on zapisywany na dysku. W przeciwnym razie jest. Po
przeanalizowaniu pliku obrazu pobierany jest kolejny aż do zakończenia transferu
danych przez skaner.
żądanie
Przeglądarka
JSP
odpowiedź
pl
s.
− Użytkownik w celu pobrania obrazów z serwera Oracle łączy się z aplikacja Image
Explorer, która pozwala w łatwy sposób przeglądać dane zgromadzone w bazie jak
również w bezpieczny sposób przesłać je na dysk użytkownika. Aplikacja działa pod
kontrolą serwera Apache Tomcat i również napisana jest wielowątkowo, co daje
możliwość korzystania z niej wielu użytkowników jednocześnie. Informacje
o statusie przesyłania danych prezentowane są użytkownikowi w czasie
rzeczywistym – w tym celu wykorzystana została technologia apletów. W celu
zapewnienia bezpieczeństwa dostępu do danych aplikacja chroniona jest unikalną
nazwą użytkownika i hasłem. Dodatkowo nazwy użytkowników przypisane są
zawsze do jednej z trzech grup: administratora, standardowej i gościa, różniących się
zapewnianymi stopniami uprawnień do przetwarzania i zarządzania sytsemem.
Java Bean
Serwer aplikacji
(np. Apache Tomcat)
źródło danych
(np.: baza danych )
Rys. 4. Java Model 1, baza dla architektury modułu Transfer Manager
233
w
Stworzony moduł Transfer Manager umożliwia zdalne łączenie się z bazą danych
dowolnego urządzenia medycznego i na przeglądanie przechowywanych w nim obrazów.
Eliminuje to konieczność każdorazowego podchodzenia do komputera skanera w celu
wysłania danych, co znacznie ułatwia pracę pracowników instytutu. Konfiguracja skanerów
przechowywana jest w zewnętrznym pliku konfiguracyjnym – istnieje możliwość
przesyłania danych między dowolnymi aplikacjami komunikującymi się z użyciem
protokołu DICOM. Implementację tego protokołu, podobnie jak w przypadku programu
Image Explorer stanowi pakiet bibliotek firmy PixelMed. Zaimplementowane zostały też
metody do testowania połączenia przed wysłaniem jakichkolwiek danych. Aplikacja
napisana jest wielowątkowo, co pozwala na jednoczesne łączenie się kilku użytkowników
z danym urządzeniem medycznym(o ile urządzenie na to pozwala). Aplikacja podobnie jak
Image Explorer działa pod kontrolą serwera Apacze Tomcat i napisana została z użyciem
technologii Java, przy czym bazę dla struktury klas stanowi tzw. Java Model 1, który
przedstawiono na rysunku 2.
Przetwarzanie żądań od przeglądarki użytkownika odbywa się z użyciem strony JSP, zaś
przetwarzanie danych odbywa się w klasach/ziarenkach Java Beans. Zastosowanie takiej
architektury umożliwia łatwe oddzielenie logiki biznesowej o prezentacji danych.
Moduł Transfer Manager ściśle współpracuje z programem Listener i Image Explorer
stanowiąc w pełni zintegrowane środowisko. Parametry konfiguracyjne dla tego modułu
przechowywane są w pilku tmconfig.xml.
da
.b
w
w
5 Funkcjonalność aplikacji i interfejs użytkownika
pl
s.
Po uruchomieniu aplikacji użytkownikowi dostarczany jest przedstawiony na poniższym
rysunku interfejs, który ma, zgodnie z założeniem, formę strony internetowej.
Pracę z programem rozpoczynamy od punktu oznaczonego na rysunku 5 numerem 1.
Z części configuration (menu source) wybieramy urządzenie, z którym chcemy się
połączyć. Następnie za pomocą przycisku ping sprawdzamy czy dany skaner jest aktualnie
dostępny. W kolejnym kroku z menu destination wybieramy maszynę docelową, do której
chcemy wysłać obrazy oraz podobnie jak w poprzednim kroku sprawdzamy jej dostępność
za pomocą przycisku ping. Dostępność obu urządzeń jest jest oczywiśćie warunkiem
koniecznym przesyłu danych.
Następnie przechodzimy do części Filter, która pozwala skonstruować bardziej
szczegółowe zapytanie do bazy danych skanera. Aplikacja daje możliwość wyszukiwania
po następujących kryteriach:
− Patient name (imię lub nazwisko pacjenta). Możliwe jest wpisanie pełnego imienia
i nazwiska lub też pierwszych kilku liter wraz ze znakiem * (gwiazdka).
Rozróżnialna jest wielkość znaków w zapytaniu, zatem wpisanie słowa ‘Andersen’
nie spowoduje znalezienia pacjentów o nazwisku ‘ANDERSEN’.
− Exam. Number (Numer badania) – jest to bardzo ważne kryterium, gdyż numer
badania jest unikalnym numerem, który w skali skanera jednoznacznie
identyfikującym pacjenta. Wyszukując po tym kryterium eliminuje się
niedoskonałości metody wyszukiwania po nazwiskach związane z wielkością liter.
Jednocześnie tak jak w poprzednim punkcie możliwe jest używanie symbolu ‘*’.
− Date: day|month|year – pola daty pozwalające wyświetlić listę badań pochodzących
z określonego dnia.
234
w
Pozostawienie odznaczonego pola „use date” przy pustych polach Patent name i Exam.
Number spowoduje wyświetlenie listy wszystkich badań dostępnych w skanerze.
Naciśnięcie przycisku query spowoduje zapisanie ustawień i wysłanie zapytania do bazy
skanera o przesłanie listy dostępnych badań. Prezentacja otrzymanych i przetworzonych
przez program wyników odbywa się w oknie: Study Level. W celu wyświetlenia informacji
o wykonanych na pacjencie seriach badań należy wybrać link będący jednocześnie
nazwiskiem pacjenta. Spowoduje to uaktualnienie zawartości okna Series Level oraz Image
Level. Jeśli chcielibyśmy wyświetlić informacje o obrazach z danej serii wystarczy w oknie
Series Level wybrać nazwę danej serii – zawartość okna Image Level zostanie
automatycznie uaktualniona.
pl
s.
da
.b
w
w
Rys. 5. Główne okno aplikacji
Kolejnym krokiem obsługi aplikacji, oznaczonym na powyższym rysunku cyfrą 4, jest
wybranie danych do wysłania. Możliwe jest dokonywanie wielokrotnego wyboru na
każdym z poziomów (study, series, images). Zaznaczone dane należy umieścić
w dostępnych dla każdego poziomu kontenerach (cyfra 5 na rysunku 5) poprzez naciśnięcie
przycisku Add.
Po dokonaniu wyboru należy wysłać do serwera żądanie transferu danych poprzez
naciśnięcie przycisku Confirm your choice.. (punkt 6), a następnie w aplecie
odpowiedzialnym za kontrolę przesyłanych danych należy nacisnąć przycisk …and start
sending (punkt numer 7). Aplet na bieżąco będzie informował o postępie przesyłania
i ewentualnych błędach. Poprzez wyświetlenie informacji Sending completed użytkownik
jest informowany o zakończeniu procesu transferu danych.
235
6 Podsumowanie
w
Posiadanie narzędzia, które umożliwia zdalne łączenie się ze skanerami medycznymi
i przesyłanie obrazów znacznie ułatwia pracę w szpitalu. Dodatkowo eliminuje konieczność
przerywania pracy lekarzy, którzy aktualnie wykonują badania, w celu spełnienia prośby
przesłania plików do bazy danych. Aplet do przesyłania obrazów wyświetlając informacje
o czasie potrzebnym na przesłanie plików do bazy umożliwia pracownikowi instytutu
lepszą samoorganizację. Dodatkowo możliwość podłączenia do programu danych o
różnych serwerach SCP może być stosowana do wymiany informacji pomiędzy lokalnymi
bazami lekarzy – zapewnia to spójność sposobu przechowywania jak i wymiany danych
pobranych ze skanerów, a przechowywanych lokalnie.
Zastosowanie języka Java oraz technologii serwletów z połączeniu ze standardem
DICOM i bazą danych Oracle zapewniło szeroką uniwersalność aplikacji. Można
zainstalować ją na serwerze pracującym pod kontrolą dowolnego systemu operacyjnego,
używać poprzez przeglądarkę internetową bez konieczności instalowania jakiegokolwiek
dodatkowego oprogramowania, bezpośrednio komunikować się ze wszelkiego rodzaju
urządzeniami medycznymi oraz bezpiecznie przechowywać dane zarówno na serwerze
centralnym, jak i na komputerach lokalnych. Aplikacja została wdrożona w szpitalu
klinicznym w Aarhus i została bardzo pozytywnie przyjęta przez personel medyczny.
1.
da
.b
w
w
Literatura
pl
s.
Szalinski M., Pelikant A.: Medical data migration and access management platform, MISC,
Zakopane 2005.
2. Kimura A., Aso T., Yoshida H., Kanematsu N., Tanaka S., Sasaki T.: DICOM data handling for
Geant4-based medical physics application, Nuclear Science Symposium Conference Record,
2004 IEEE, Volume 4, pp:2124 - 2127 Vol. 4.
3. Moreno R. A., Furuie S. S.: Integration of heterogeneous systems via DICOM and the clinical
image access service, Computers in Cardiology, 2002, pp. 385 – 388.
4. Marcheschi P., Positano V., Ferdeghini E. M., Mazzarisi A., Benassi A.: An open source based
application for integration and sharing of multi-modal cardiac image data in a heterogeneous
environment, Computers in Cardiology, 2003, pp. 367 – 370.
5. Bortoluzzi M. K., von Wangenheim A., Maximini K.: A clinical report management system
based upon the DICOM structured report standard, Computer-Based Medical Systems, 2003.
Proceedings. 16th IEEE Symposium, pp. 183 – 188.
6. Ribeiro L. A., Dellani P. R., von Wangenheim A., Richter M. M., Maximini K., Comunello E.:
CyclopsDistMedDB – a transparent gateway for distributed medical data access in DICOM
format, Computer-Based Medical Systems, Proceedings of the 15th IEEE Symposium pp. 315–
320.
7. Zhang H., Fritz S. L., Roys S.: Class library design for DICOM in C++,Engineering in Medicine
and Biology Society, 1995. IEEE 17th Annual Conference, Volume 1, pp. 435 - 436 vol.1.
8. Nedevschi S., Olinic D., Popovici R., Rusu F., Smeu A., Homorodean C.: DICOM compliant
environment for structured reporting in echocardiography. Computers in Cardiology, 2003, pp.
29 – 32.
9. Hoher M., Brummer T., Kestler, H. A.: Concept and initial experience with a mid-term DICOM
archiving system acting as an intelligent buffer to clinical requests, Computers in Cardiology
1999, pp. 319 – 322.
10. Nedevschi S., Rusu F., Popa I., Smeu A., Olinic D., Homorodean C.: Structured reporting of
echocardiography images in a DICOM environment, Computers in Cardiology, 2004, pp. 685 –
688.
236
w
11. Noumeir R.: DICOM structured report document type definition, Information Technology in
Biomedicine, IEEE Transactions on, Volume 7, pp. 318 – 328.
12. Blanquer I., Hernandez, V., Mas F.: A peer-to-peer environment to share medical images and
diagnoses providing context-based searching, Parallel, Distributed and Network-Based
Processing, 2005. 13th Euromicro Conference on, pp. 42 – 48.
13. Yacoub S. M., Ammar H. H.: The development of a client/server architecture for standardized
medical application network services, Application-Specific Systems and Software Engineering
and Technology, ASSET '99. pp. :2 – 9.
14. Revet B.: DICOM Cook Book for implementation in Modalties, chapter 1 and 2. Jan 1997.
15. Clunie D. A.: DICOM Structured Reporting.
16. http://medical.nema.org
17. http://www.dclunie.com/medical-image-faq/html/
18. http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html
19. http://www.rsna.org/practice/dicom/
20. http://www.xray.hmc.psu.edu/physresources/dicom/dicom_intro/index.html
pl
s.
da
.b
w
w
237
w
pl
s.
da
.b
w
w

pobierz plik referatu

Transkrypt

Podobne dokumenty

Zapytanie ofertowe na wykonanie diagnostyki i naprawy systemu

SRV (PACS) - Synektik SA

Obrazy cyfrowe DICOM i upraszczanie świata

NEC MD242C2 - NEC Display Solutions Europe

Sprawa nr ZP-271