Internetowy rozproszony system monitorowania obiegu recept lekarskich

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 Rozdział 43 w...
9 downloads 2 Views 293KB Size
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