pobierz plik referatu

Transkrypt

pobierz plik referatu
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 43
w
Internetowy rozproszony system monitorowania
obiegu recept lekarskich
w
1 Wstęp
da
.b
w
Streszczenie. Artykuł zawiera opis internetowego systemu umożliwiającego
monitorowanie obiegu recept lekarskich. Przedstawiono korzyści
wypływające z zastosowania systemu dla każdego z uczestników (Narodowy
Fundusz Zdrowia, środowiska aptekarskie i lekarskie). Opisano zastosowanie
nowych rozwiązań technologicznych (dwuwymiarowy kod kreskowy,
internetowa technologia ASP.NET 2.0), dzięki którym udało się osiągnąć
zamierzoną funkcjonalność, bezpieczeństwo i ergonomię.
pl
s.
Internetowy system monitorowania obiegu recept to zestaw aplikacji i usług
umożliwiających wydruk blankietów recept lekarskich oraz monitorowanie ich stanu do
chwili końcowej realizacji w aptece. Zastosowanie nowoczesnych technologii
internetowych pozwoliło na stworzenie możliwości wydruku blankietów recept przez
lekarzy (lub podmioty przez nich upoważnione) w dowolnym miejscu (np. w mieszkaniu
czy w gabinecie) wyposażonym w stanowisko komputerowe z przeglądarką internetową.
Druk recepty, oprócz dotychczasowych informacji wymaganych przepisami prawa, zawiera
dodatkowo kod składający się z identyfikatora recepty, numeru lekarza, kodu
świadczeniodawcy oraz podpisu cyfrowego wcześniej wymienionych składników.
Informacje te umieszczone są na recepcie w postaci dwuwymiarowego kodu paskowego. W
trakcie realizacji takiej recepty aptekarz ma możliwość jej weryfikacji w bazie danych
zarządzanej przez regionalny oddział Narodowego Funduszu Zdrowia.
Monitorowanie i sterowanie przepływem blankietów recept lekarskich przynosi
wymierne korzyści dla każdego z uczestników przedsięwzięcia:
− lekarze nie muszą udawać się w do punktów dystrybucji druków recept w celu
zakupu bloczków, tylko sami realizują wydruk potrzebnej w danej chwili liczby
recept; dodatkowo mają możliwość anulowania wydrukowanych blankietów w
przypadku ich kradzieży lub zniszczenia,
− aptekarze, wykorzystując czytnik kodów kreskowych, w łatwy i szybki sposób mogą
wprowadzać dane z recepty do swojego systemu informatycznego; weryfikując
recepty w centralnej bazie danych mogą zapobiec realizacji tych, za które apteka nie
Dariusz Rafał Augustyn, Łukasz Wyciślik: Politechnika Śląska, Instytut Informatyki,
ul. Akademicka 16, 44-100 Gliwice, Polska
email:{draugustyn, lwycislik}@polsl.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
D. R. Augustyn, Ł. Wyciślik
w
otrzymałaby zwrotu kosztów refundacji (np. z powodu próby wyłudzenia leku nie
przysługującego danemu pacjentowi),
− Narodowy Fundusz Zdrowia otrzymuje narzędzie operacyjno-kontrolne
umożliwiające poczynienie znacznych oszczędności w obszarze gospodarki lekowej;
umożliwienie realizacji wydruku recepty przez lekarzy pozwala również na redukcję
nakładów związanych z utrzymaniem punktów dystrybucji recept lekarskich.
Poza opisanymi wyżej celami merytorycznymi, pilotaż systemu stanowił poligon dla
przetestowania zastosowanych mechanizmów i nowych technologii (dwuwymiarowy kod
kreskowy, podpis elektroniczny, technologia ASP.NET 2.0).
w
2 Analiza problemu
2.1 Geneza problemu
da
.b
w
Jednym z podstawowych obszarów funkcjonowania publicznego systemu ubezpieczeń
zdrowotnych w Polsce jest refundacja leków i materiałów medycznych. Corocznie na
sfinansowanie tego obszaru działalności Narodowy Fundusz Zdrowia przeznacza ok. 20%
całego budżetu, co w roku 2006 wyniesie ok. 7 mld. złotych. Możliwość zaoszczędzenia
nawet ułamka tej kwoty czyni znaczną sumę, dlatego wydatkowanie tak dużych środków
powinno podlegać ścisłej racjonalizacji. Jednym z negatywnych czynników mających
wpływ na wzrost nakładów na refundację leków w Polsce jest zjawisko nadużyć,
polegające na wyłudzaniu środków lub leków w ramach programu refundacyjnego.
Uczestnikami tego procederu potencjalnie może być każda ze stron tzn. pacjent, lekarz i
aptekarz, występujący oddzielnie lub będący w zmowie. Najprostsze i zarazem najczęściej
stosowane na polskim rynku metody wyłudzeń to podrabianie (wygenerowanie, bądź
powielenie) druku recepty przez pacjenta lub aptekarza oraz wystawianie przez lekarza
zniżkowej recepty pacjentowi, któremu takie uprawnienie nie przysługuje.
W chwili obecnej aptekarz realizując receptę nie ma technicznych możliwości
weryfikacji zarówno uprawnień specjalnych, przysługujących niektórym pacjentom
(np. inwalidom wojennym), jak i autentyczności druku, na którym jest ona wystawiona.
Powoduje to, że oddziały Narodowego Funduszu Zdrowia nie mają podstaw do odmowy
roszczeń refundacyjnych, nawet w przypadku stwierdzenia post-factum nieprawidłowości
dyskwalifikujących refundację danej recepty.
Wyposażenie apteki w techniczne środki umożliwiające weryfikację recepty przed jej
realizacją, daje podstawy do niezrealizowania nieprawidłowych recept, a nawet w
przypadku ich realizacji przez aptekę, do odmowy jej roszczeń refundacyjnych przez dany
oddział NFZ. Warunkiem koniecznym powodzenia wdrożenia systemu informatycznego,
zapewniającego takie środki techniczne, jest odpowiednia ergonomia systemu,
niezaburzająca sprawnej obsługi pacjentów w aptece oraz niski koszt jego wdrożenia.
pl
s.
2.2 Zabezpieczenie wiarygodności procesu obiegu druków recept
Obieg recept w proponowanym systemie zakłada możliwość generacji puli numerów,
generacji blankietów recept z kodami paskowymi i wydruku recepty. Czynności te może
wykonać lekarz samodzielnie, poprzez Internet z wykorzystaniem przeglądarki WWW.
Takie rozwiązanie powoduje, że lekarz będący użytkownikiem aplikacji WWW, nie będzie
musiał dokonywać zakupów drukowanych wcześniej bloczków blankietów i osobiście
414
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Internetowy rozproszony system monitorowania obiegu recept
odbierać ich w oddziałach NFZ. Wydrukowane blankiety recept (rys .1) będą przypisane do
lekarza (i ewentualnie świadczeniodawcy, u którego lekarz jest zatrudniony). Lekarz będzie
mógł dodatkowo poprzez system zgłosić anulowanie wskazanego zakresu numerów recept
w przypadku zagubienia lub kradzieży grupy blankietów.
Unikalny
numer
w
Dane
identyfikacyjne
świadczeniodawcy
Dane
identyfikacyjne
lekarza
da
.b
w
w
Unikalny numer
recepty w postaci
jawnej oraz kodu
kreskowego 2 z 5
Dane z recepty w
postaci
dwuwymiarowego
kodu paskowego
PDF 417
(rozszerzony kod
recepty)
pl
s.
Rys. 1. Nowy zaproponowany format recepty
Zastosowana technika kodów dwuwymiarowych pozwala zawrzeć w tymże kodzie numer
recepty, a także numer lekarza i świadczeniodawcy oraz podpis cyfrowy skrótu
wymienionych numerów. Taki mechanizm praktycznie uniemożliwi podrobienie druku
recepty i zapewni autentyczność druków recept spersonalizowanych na lekarza.
Na pierwszym etapie wdrożenia zakłada się ręczne wypisywanie recept przez lekarza,
tak jak to miało miejsce dotychczas. W aptece, w obecności pacjenta, przed realizacją
recepty, następuje jej weryfikacja formalna. Weryfikacja ta dotyczy autentyczności recepty
(weryfikacja kryptograficzna zestawu numerów zawartych w kodzie dwuwymiarowym).
Sprawdzenie w aptece autentyczności recepty może się odbywać w wersji on-line za
pośrednictwem przeglądarki internetowej poprzez aplikację WWW lub bezpośrednio z
aplikacji aptecznej (wykonanej przez producentów niezależnych w technologii grubego
klienta), która jest klientem weryfikującej usługi WWW (ang. web service). Dla aptek bez
415
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
D. R. Augustyn, Ł. Wyciślik
w
dostępu do Internetu, przewidziano wariant weryfikacji off-line, w którym logika
weryfikacji zawarta jest w dołączonej do aplikacji aptecznej bibliotece weryfikującej.
Opisana wyżej weryfikacja autentyczności nie zabezpiecza obiegu przed wielokrotnym
użyciem zduplikowanych (kserowanych) blankietów recept. Stąd drugi etap weryfikacji
dotyczący stanu realizacji recepty, tylko w wersji on-line, zakładający podłączenie apteki
do Internetu. Aptekarz za pomocą przeglądarki WWW lub z poziomu aplikacji aptecznej
(„grubego” klienta kolejnego zestawu usług WWW) dokonuje sprawdzenia stanu recepty
(czy recepta o podanym numerze nie była już wcześniej zrealizowana, czy nie była
anulowana).
Jeśli weryfikowana recepta była już zrealizowana, aptekarz otrzymuje informację
dotyczącą danych realizacji. Szczegółowość komunikatu zależy od miejsca poprzedniej
realizacji. Jeśli miejscem wcześniejszej realizacji recepty o tym samym numerze była ta
sama apteka (potencjalne próba wykorzystania dwukrotnego użycia blankietu recepty w tej
samej aptece), to uzyskiwana jest pełna informacja (numery lekarza, świadczeniodawcy,
data realizacji) o poprzednim użyciu recepty o tym samym numerze. W przeciwnym
wypadku aptekarz uzyskuje skrócona informację, dotyczącą jedynie daty zdarzenia
wcześniejszej realizacji.
Jeśli numer druku recepty jest autentyczny i recepta o danym numerze nie była ani
wykorzystana, ani anulowana, to aptekarz dokonuje odnotowania faktu realizacji recepty
(zapisując datę realizacji i kod apteki jako miejsce realizacji). Opisane czynności
weryfikujące odbywają się z zapewnieniem ergonomii użytkownika aptecznego tzn. odczyt
dwuwymiarowego kodu paskowego automatycznie uruchamia odpowiednie procedury
realizujące logikę weryfikującą.
da
.b
w
w
3 Zastosowanie kodów dwuwymiarowych w drukach recept
pl
s.
Rozwój technologii dwuwymiarowych kodów paskowych pozwolił na wykorzystanie
nowych rozwiązań w tej dziedzinie w proponowanym systemie informatycznym.
Zwiększona pojemność informatyczna liczona na jednostkę zajmowanej powierzchni (w
odniesieniu do dotychczas stosowanych kodów jednowymiarowych), mechanizmy detekcji
i korekcji błędów, zapewniające poprawny odczyt nawet przy uszkodzeniach pewnych
fragmentów kodu, czy zwiększona ergonomia odczytu (ergonomia w sposobie
posługiwania się czytnikiem przez użytkownika: tolerancja w zakresie odległości, kąta
nachylenia) to przyczyny wykorzystania kodów dwuwymiarowych w omawianym
systemie.
Najogólniej, rodzinę kodów dwuwymiarowych można podzielić na kody typu
matrycowego (ang. matrix) i łamanego (ang. stacked) [8]. Kody typu matrix są kodami, w
których informacja wykorzystuje faktycznie reprezentację dwuwymiarową. Przykładem
popularnego kodu typu matrix może być kod Data Matrix – ECC200 (rys. 2).
Rys. 2. Przykład zastosowania kodu Data Matrix
W dużym uproszczeniu, w kodach typu stacked (multi-rows) informacja reprezentowana w
postaci ciągu danych jest przekształcana zgodnie z formatem kodu, a kod ten jest „łamany”
416
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Internetowy rozproszony system monitorowania obiegu recept
i umieszczany w kolejnych wierszach. Przykładem takiego kodu jest PDF417 (ang.
portable data file) (rys. 3).
Rys. 3. Przykład zastosowania kodu PDF417
w
da
.b
w
w
W omawianym systemie zaproponowano kod typu stacked - PDF417, spełniający
wymagania techniczne, jak i uwarunkowania ekonomiczne.
Uzyskane w fazie testów praktyczne doświadczenia związane z symulowanymi
„uszkodzeniami” kodu (np. słaba jakość druku, zapisywanie ręczne części kodu)
potwierdziły deklarowaną odporność na założonym poziomie. Pozwoliły również dobrać
parametry kodu PDF417 typu tryb kompresji, poziom korekcji błędów, uwzględniając m.in.
zmienną długość kodowanego ciągu danych, przy zachowaniu w przybliżeniu stałej
powierzchni zajmowanej na blankiecie.
Wybór kodu PDF417 podyktowany był również uwarunkowaniami ekonomicznymi.
Kod ten może być obsługiwany przez wydajne czytniki droższe (np. HHP 4600 - czytnik z
kamerą cyfrową, odczytującego prostokątny obszar kodu w pojedynczej sesji) i jak również
przez tańszy uniwersalny czytnik (np. HHP 3800 matrycą liniową CCD) [9].
Omawiany system informatyczny (włączając w to propozycje dotyczące wariantów
czytników), zapewnia również odczyt tradycyjnych kodów jednowymiarowych, w związku
z obsługą recept w dotychczasowym formacie. Wybór kodu PDF417 pozwala
rekomendować kilka wariantów czytników działających poprawnie z omawianym
systemem o zróżnicowanej cenie, szybkości, działania i ergonomii, jak również
zapewniających wsteczną kompatybilność z tradycyjnymi drukami recept.
4 Zastosowanie mechanizmu podpisu cyfrowego w zapewnieniu
autentyczności druków recept
pl
s.
Internetowy system kontroli obiegu recept wykorzystuje infrastrukturę klucza publicznego
(ang. PKI – public key infrastructure).
Mechanizm podpisu cyfrowego został wykorzystany przy implementacji
funkcjonalności związanej z weryfikacją autentyczności druku recepty. Dla zestawu
złożonego z numeru recepty, numeru lekarza i ewentualnie kodu świadczeniodawcy
generowana jest funkcja skrótu z wykorzystaniem algorytmu SHA-1 (ang. secure hash
algorithm) [4], podpisywana następnie za pomocą klucza prywatnego. Cała sekwencja
numerów i znaków kontrolnych zapisywana jest w kodzie dwuwymiarowym i drukowana
na generowanym przez lekarza blankiecie recepty.
Unikalna para kluczy (prywatny/publiczny) jest związana z instalacją systemu
internetowego (jest charakterystyczna dla oddziału NFZ, w którym planuje się
uruchomienie systemu). Klucz publiczny wykorzystany jest w procesie weryfikacji
podpisanej sekwencji numerów. Weryfikacja odbywa się w aplikacji WWW, w ramach
zdalnego wywołania usługi WWW lub w ramach logiki lokalnej aplikacji aptecznej. W tym
ostatnim przypadku, dedykowanym dla rozwiązania off-line, wraz z biblioteką programową
do weryfikacji podpisu dystrybuowany jest klucz publiczny systemu dla producentów
oprogramowania aptecznego.
417
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
D. R. Augustyn, Ł. Wyciślik
w
W rozwiązaniu technicznym zastosowano algorytm DSA (ang. digital signature
algorithm) [4, 5], który (w odróżnieniu powszechniej używanego algorytmu RSA),
charakteryzuje się nieco dłuższym czasem kodowania (podpisywania), ale krótszym
czasem dekodowania (weryfikacji podpisu). Wybór DSA podyktowany jest faktem, że
spodziewanym, krytycznym wydajnościowo, procesem będzie proces weryfikacji recepty w
aptece (sytuacja, w której pacjenci oczekują przed okienkiem w kolejce), nie zaś proces
generacji kolejnego zbioru blankietów recept przez lekarza.
Standardowym rozwiązaniem w omawianym systemie, bazującym na infrastrukturze
klucza publicznego jest zabezpieczenie połączenia z aplikacją WWW poprzez protokół
https. Podobnie zabezpieczone są usługi typu WebService [1, 2] (poprzez szyfrowanie
transmisji parametrów i wyników wywołań zdalnych metod), przeznaczone do weryfikacji
formalnej druku - autentyczności, weryfikacji stanu recepty, odnotowania faktu realizacji
recepty. Wymagania związane z zapewnieniem autentyczności i szyfrowaniem zostały w
całości zrealizowane dzięki wykorzystaniu rozbudowanej funkcjonalności prefabrykowanej
infrastruktury .NET Framework 2.0 [4].
w
w
5 Architektura internetowego informatycznego systemu monitoringu
obiegu recept
da
.b
System bazuje na technologiach Internetu. Aplikacje zostały wykonane z wykorzystaniem
technologii ASP.NET [3] firmy Microsoft Corp., umożliwiającej stworzenie aplikacji
WWW oraz zaimplementowanie i bezpieczne udostępnienie usług weryfikacyjnych. W
skład systemu (rys. 4) wchodzą: zestaw aplikacji WWW (aplikacja lekarza, aptekarza,
administratora), zestaw usług WWW oraz biblioteki – w kodzie zarządzanym Win32 (dla
aplikacji Windows) i niezarządzanym (dla środowiska .NET Framework), przeznaczone do
włączania w kod lokalnych aplikacji aptecznych niezależnych producentów.
6 Podsumowanie
pl
s.
Koncepcja omawianego systemu informatycznego została zaimplementowana w portalu
internetowym clLek® firmy ComputerLand S.A., który jest gotowy do uruchomienia na
terenie województwa podkarpackiego, przy wsparciu tamtejszego oddziału NFZ[7].
Właścicielem systemu jest firma ComputerLand S.A. Autorami sytemu są pracownicy
związani z firmą Computerland .S.A o/Gliwice i Politechniką Śląską w Gliwicach: Łukasz
Wyciślik, Witold Kruczek, Łukasz Warchał, Dariusz Rafał Augustyn.
Wymagania do systemu weryfikowane były z potencjalnymi użytkownikami systemu w
Podkarpackim Oddziale NFZ oraz konsultowane w ramach ogólnokrajowej konferencji
dotyczącej zagadnień refundacji leków [6].
Uruchomienie internetowego system monitoringu obiegu recept powinno
zminimalizować patologie związane z wyłudzaniem środków finansowych poprzez
eliminację użycia fałszywych recept. W aspekcie praktyki informatycznej, może pozwolić
na wydajnościową weryfikację nowych technologii (ASP.NET, WebService) poprzez
wdrożenie na terenie województwa obejmującego około tysiąca aptek, uzyskujących od
NFZ środki refundacyjne.
418
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Internetowy rozproszony system monitorowania obiegu recept
dd Diagram kontekstowy dla systemu RecWeb
«document»
«drukarka»
podspisany druk recepty
Drukarka
komputer użytkownika
komputer dla aplikacji WWW
w
Lekarz
«executable»
Przeglądarka WWW
«executable»
Internet, https
server IIS dla aplikacji ASP.NET
«executable»
Aplikacja obsługi druków
recept: RecWeb
komputer pracownika
OWNFZ
Administrator
Internet,
intranet,
https
«executable»
w
w
Wyznaczony
(upoważniony)
personel
świadczeniodawcy
Przeglądarka WWW
Pracownik OWNFZ
Internet,
intranet,
https
«executable»
Aplikacja administratora
komputer dla DBMS Oracle
«executable»
«czytnik»
Recepta
d
.b
Apliakcja oddziałowa:
zatwierdzanie anulowanych
recept
«document»
czytnik kodów 2z5 i pdf417
«executable»
serwer bazy danych
ORACLE
«executable»
komputer Aptekarza
Aplikacja weryfikacji
realizacji recept z
możliwością zapisu o
realizacji
Internet, https
«executable»
Przeglądarka WWW
«executable»
Aplikcja apteczna niezależnego producenta
as
Aptekarz
komputer dla usług WWW
«library»
automatyczna kontrola druków recept offline
«executable»
l
.p
server IIS dla usług WebService
«library»
klient usługi sprawdzenia anulowania,
realizacji recepty lub zapisu informacji o
realizacji
«web service»
Internet, https,sprawdzenie,
zapis realizacji
SOAP
usługa sprawdzenia anulowania,
realizacji recepty
Rys. 4. Uproszczony diagram wdrożenia obrazujący architekturę internetowego systemu
monitoringu obiegu recept
419
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
D. R. Augustyn, Ł. Wyciślik
Literatura
1.
2.
3.
w
Understanding Web Services specification and the WSE. Microsoft Press. Redmond,
Washington 2004
XML Web Services and Server Components with Microsoft Visual BASIC .NET and Microsoft
Visual C#. Microsoft Press. Redmond. Washington 2003
Developing Web Applications with Microsoft Visual Basic and Visual C#. Microsoft Press.
Redmond, Washington 2003
http://msdn2.microsoft.com
http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
Materiały konferencyjne w ramach konferencji naukowej: Monitoring systemu ochrony zdrowia
z wykorzystaniem technologii informatycznych. Kontrola kosztów refundacji leków. Rzeszów,
7-8 wrzesień 2005
Kulczycka A.: Recepta z mozaiką. Gazeta Wyborcza. Rzeszów 9 wrzesień 2005.
http://www.idautomation.com/
http://www.skk.com.pl/
4.
5.
6.
w
7.
8.
9.
da
.b
w
pl
s.
420
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006