Professional Documents
Culture Documents
DOKUMENTY ELEKTRONICZNE
POLSKIEJ SŁUŻBY ZDROWIA
Jacek Lewiński
Społeczna Wyższa Szkoła
Przedsiębiorczości i Zarządzania w Łodzi
Studia II letnie magisterskie uzupełniające
Semestr II
Grupa projektowa nr 7
index 50564
jaceklewinski@gmail.com
dokumenty elektroniczne w służbie zdrowia Strona 2 z 2
W historii informatyzacji sektora zdrowia można wyróżnić trzy okresy. Pierwszy okres to lata
dziewięćdziesiąte ubiegłego wieku. W tym okresie informatyzacja odbywała się w optyce świadczeniodawcy
a głównym jego celem było wsparcie procesów zarządzania w jednostkach opieki zdrowotnej. Przejawem
tego był m.in. : projekt Banku Światowego realizowany w latach 1992 – 2002, w ramach, którego ponad
500 szpitali otrzymało komputery PC, stacje robocze, serwery, oraz oprogramowanie 'Ruch Chorych” i
„Apteka”. Drugi okres to przełom XX i XXI wieku oraz pierwsza dekada XXI wieku. W okresie tym podjęto
kilka nieudanych prób wdrożenia Rejestru Usług Medycznych. Jedynie płatnikowi publicznemu udało się, w
ramach bieżącego doskonalenia procesów sprawozdawczo-rozliczeniowych, zbudować bazę danych, w
której gromadzi się aktualnie szczegółowe informacje o większości świadczeń zdrowotnych (bez świadczeń
udzielonych przez podstawową opiekę zdrowotną) udzielonych osobom objętym powszechnym
ubezpieczeniem zdrowotnym. Obecnie wchodzimy w trzeci okres, w którym kluczowe znaczenie będzie
miała optyka pacjenta, przejawiająca się m.in. w następujących obszarach: elektroniczna kartoteka
medyczna, elektroniczna historia choroby, elektroniczna rezerwacja wizyt, skomputeryzowane
wprowadzanie zleceń medycznych, elektroniczny transfer recept, portale pacjentów, telemedycyna.
Zainteresowanie narzędziami informatycznymi wspierającymi procesy leczenia wiąże się przede wszystkim
ze wzrostem ogólnych kosztów ochrony zdrowia. Badania prowadzone w wielu państwach UE i Komisję
Europejską dowodzą, że odpowiednie wykorzystanie dobrodziejstw technologii informatycznych jest w
stanie szybko zwiększyć wydajność systemu opieki zdrowotnej.
Ograniczenia technologiczne, które występowały jeszcze 10 lat temu (np. przepustowość sieci,
bezpieczeństwo danych, dostępność do internetu) miały podstawowy wpływ na ukształtowanie się modelu
rozproszonego architektury systemu informatycznego. W modelu tym użytkownik końcowy dostarcza dane
(najczęściej na formularzu papierowym) do ośrodka regionalnego lub lokalnego, gdzie poddaje się je
obróbce, weryfikacji formalnej i merytorycznej. W związku z tym, że ośrodki najczęściej nie korzystają z
referencyjnych baz danych (rejestry) użytkownik oprócz formularza papierowego musi dostarczyć zestaw
różnych zaświadczeń potwierdzających jego szczególne uprawnienia. Następnie dane wprowadza się do
regionalnego lub lokalnego systemu informatycznego i w określonych odstępach czasu przesyła się drogą
elektroniczną do ośrodka centralnego, gdzie są scalane w ramach centralnej bazy danych (CBD). W ośrodku
centralnym zachodzi również proces porównywania danych regionalnych lub lokalnych. W przypadku
nieścisłości (np. podmiot lub osoba wystąpiła kilkakrotnie lub jej dane otrzymane z kilku ośrodków
regionalnych lub lokalnych znacznie się różnią) uruchamiany jest proces sprawdzania, co wiąże się
najczęściej ze zwrotem danych do ponownej weryfikacji do ośrodka lokalnego lub regionalnego. Model
rozproszony jak na razie przeważa w systemie informacyjnym ochrony zdrowia. Stanowi on obecnie
największą barierę w rozwoju systemów informatycznych, w tym we wdrożeniu tzw. usług on-line
(możliwość kontaktu użytkownika końcowego z podmiotem lub urzędem przy wykorzystaniu Internetu).
Dodatkowo utrwalają go regulacje prawne, które często zobowiązują wręcz podmioty lokalne lub regionalne
do prowadzenia własnych baz danych oraz wprowadzają autonomię organizacyjną w realizacji zadań.
jaceklewinski@gmail.com
dokumenty elektroniczne w służbie zdrowia Strona 3 z 3
zgromadzonych w jednym ośrodku centralnym niż kilkunastu regionalnych lub lokalnych. Systemy
scentralizowane łatwiej także integrować z innymi systemami, w tym centralnymi rejestrami publicznymi
(REGON, TERYT, PESEL, KRS, Centralny Wykaz Ubezpieczonych), centralnymi zasobami słownikowymi
zapewniającymi jakość danych (kody, klasyfikacje) czy centralnymi platformami (np. ePUAP) oraz wdrażać
usługi elektroniczne. Przejście z systemu rozproszonego na scentralizowany powoduje zasadniczą zmianę w
realizacji kluczowych ról przez ośrodki regionalne.
Standard HL7 umożliwia wymianę danych tekstowych na temat pacjenta, takich jak informacje dotyczące
jego danych personalnych, przyjęć i wypisów z danej placówki, podjętych leczeń czy przepisanych leków.
Jest standardem wymiany danych niezależnym od systemu komputerowego oraz protokołu
komunikacyjnego. Rozbudowa standardu nie powoduje konieczności wymiany systemów korzystających ze
starszych wersji standardu. Poza tym standard opisuje szereg rozwiązań, które pozwalają istniejącym już
systemom medycznym na integrację z systemami zgodnymi z HL7. Powoduje to znaczące rozszerzenie
zasięgu dostępności danych medycznych. Dodatkowo, standard HL7 pozwala na współpracę z takimi
standardami jak DICOM czy XML.
Digital Imaging and Communication in Medicine [DICOM] jest międzynarodowym standardem, który
definiuje sposób przetwarzania i wymiany różnego rodzaju danych zawierających obrazy medyczne oraz
obrazów medycznych, takich jak obrazy tomografii komputerowej, rezonansu magnetycznego, medycyny
nuklearnej, obrazów rentgenowskich, sekwencji wideo wykonanych aparaturą ultrasonograficzną i
endoskopową pomiędzy różnymi systemami i aplikacjami jednostek służby zdrowia.
Electronic Data Interchange for Administration Commerce and Transport [EDIFACT] jest standardem
elektronicznej wymiany danych w administracji, handlu i transporcie.
Standard EDIFACT stosowany jest również w elektronicznej wymianie danych pomiędzy różnymi
placówkami służby zdrowia.
Wiadomość zgodna ze standardem UN/EDIFACT składa się z zestawu logicznie uporządkowanych
segmentów danych, które mogą być pogrupowane. Ich pozycja, status wystąpienia oraz liczba wystąpień jest
ściśle określona przez standard. Podstawowa konstrukcja wiadomości zakłada wystąpienie:
* nagłówka wiadomości [ang. message header]
* co najmniej jednego segmentu danych
* stopki wiadomości [ang. message trailer].
jaceklewinski@gmail.com