Medicover Sp. Z o.o.

System PFM – wspieranie zarządzania ruchem pacjenta w sieci Medicover

High-Level Business Requirements

Katarzyna Skarbek

Wersja: 2015-01-13.4
Wstęp........................................................................................................................................................................3
Historia zmian.......................................................................................................................................................3
Model RACI...........................................................................................................................................................3
Przedmiot i cel dokumentu...................................................................................................................................3
Słownik pojęć........................................................................................................................................................4
Akronimy...............................................................................................................................................................7
Tematy, zagadnienia w kontekście TBD/TBC........................................................................................................7
Ogólne informacje o projekcie PFM..........................................................................................................................8
Tło i przyczyny.......................................................................................................................................................8
Cel projektu PFM..................................................................................................................................................8
Zakres projektu PFM.............................................................................................................................................8
Wykluczenia..........................................................................................................................................................8
Kryteria sukcesu projektu PFM.............................................................................................................................9
Interesariusze projektu PFM.................................................................................................................................9
Kamienie milowe projektu PFM...........................................................................................................................9
Założenia dotyczące wyboru oferentów oraz kryteria oceny...............................................................................9
Obecny proces umawiania wizyt........................................................................................................................10
Nowy proces umawiania świadczeń...................................................................................................................11
Różnice pomiędzy obecnym procesem a nowym procesem.............................................................................13
Procesy powiązane z procesem ‘To Be’..............................................................................................................14
Założenia dla Systemu PFM....................................................................................................................................14
Przeznaczenie Systemu PFM..............................................................................................................................14
Główne założenia architektoniczne....................................................................................................................14
Wymagania dla Systemu PFM.................................................................................................................................15
Biznesowe – ogólne dotyczące platformy BPM..................................................................................................15
Architektoniczne.................................................................................................................................................15
Funkcjonalne.......................................................................................................................................................16
Diagram przypadków użycia...........................................................................................................................16
Przypadki użycia.............................................................................................................................................16
Niefunkcjonalne..................................................................................................................................................25
Lista użytkowników........................................................................................................................................25
Bezpieczeństwo..............................................................................................................................................26
Wydajność......................................................................................................................................................26
Skalowalność..................................................................................................................................................26
Dostępność.....................................................................................................................................................26
Raporty...............................................................................................................................................................26
Alerty i powiadomienia – TBC.............................................................................................................................26
Powiązania z innymi projektami.............................................................................................................................27
Załączniki.................................................................................................................................................................27
Mapa procesów..................................................................................................................................................27
Harmonogram.....................................................................................................................................................27
Plan testów (TBD)...............................................................................................................................................27
Wskaźniki............................................................................................................................................................27

2
3
WSTĘP

HISTORIA ZMIAN
Wersja Data Autor Opis

1.0 2014-12-23 Katarzyna Skarbek Pierwsza wersja dokumentu

1.1 2015-01-07 Piotr Machowski Uzupełniona definicja pojęć, uzupełnione

wymagania funkcjonalne

1.2 2015-01-19 Sonia Kondratowicz Uzupełniona definicja pojęć, uzupełnione

wymagania funkcjonalne

1.3 2015-01-21 Katarzyna Skarbek Korygowanie definicji pojęć, uzupełnione

wymagania funkcjonalne

1.4 2015-01-26 Katarzyna Skarbek Korygowanie definicji pojęć, uzupełnione

wymagania funkcjonalne

MODEL RACI 1
Imię i Nazwisko Stanowisko R A S C I

Katarzyna Skarbek Kierownik Projektu X

Piotr Machowski Konsultant Zewnętrzny X X

Mirosław Suszek Sponsor Projektu X X

Sonia Kondratowicz Członek Zespołu Projektowego X X X

Małgorzata Kiljańska Członek Zespołu Projektowego X X X

Marta Kacorzyk Członek Zespołu Projektowego X X X

Urszula Przybył Członek Zespołu Projektowego X X X

Robert Koźliczak Członek Zespołu Projektowego X X X

Iwona Diduszko Członek Zespołu Projektowego X X X

Maria Andrulewicz Członek Zespołu Projektowego X X X

PRZEDMIOT I CEL DOKUMENTU

1
R- responsible (osoba odpowiedzialna za zadanie)
A- accountuble/approve (do kogo R raportuje w celu akceptacji rozwiązania)
S- supportive (kto wspiera R przy realizacji zadania)
C- consulted (z kim należy konsultować temat w celu wypracowania, zakończenia zadania)
I- informed (kogo należy informować o postępie)

4
 Przedmiotem dokumentu jest przedstawienie ogólnych wymagań biznesowych wynikających z
potrzeby wdrożenia rozwiązania wspierającego nowy proces zarządzania ruchem pacjentów w sieci
Medicover (Patient Flow Management System, w skrócie System PFM), w kontekście umawiania
świadczeń medycznych na wybrane przypadki medyczne.

Dokument posłuży do:

1. Zebrania założeń do projektu PFM oraz zebrania wymagań do systemu PFM (jeden
zbiorczy plik dla projektu)
2. Akceptacji zebranych niżej wymagań przez zespół projektowy oraz sponsora projektu.
3. Prezentacji wymagań oferentom.
4. Wybrania najlepszego rozwiązania systemowego do obsługi nowego procesu, osiągnięcia
celów i mierników sukcesu procesu poprzez wdrożenie wybranego systemu.
5. Wybrania dostawcy spełniający kryteria doboru.

SŁOWNIK POJĘĆ
Nazwa Opis

Wizyta Konsultacja realizowana w placówce medycznej

Pacjent Beneficjent usług Medicover definiowany z różnym statusem oraz rodzajem.

Klient Firma lub osoba fizyczna, która wykupiła lub opłaca usługi medyczne dla
beneficjenta.

Operator Operator to:

 Pracownik CallCenter Medicover lub
 Pracownik Centrum Medicover lub
 System Medicover Online lub
 Aplikacja mobilna Medicover
Uwaga:

Pracownik CallCenter – obecnie pracownik FrontLine, BackOffice, Reklamcje

Pracownik Centrum Medicover – obecnie pracownik:

 Recepcja
 Kierownik Zespołu Pielęgniarskiego
 Koordynator Opieki
 Kierownik Obsługi Klienta
 Indywidualny Opiekun Pacjenta

Status pacjenta  FFS

 Aktywny
 Nieaktywny
 Zawieszony (pacjent ma dostęp tylko od usług HotLine)

Rodzaj pacjenta  VIP

 Zwykły
 ZOP

Rentowność pacjenta Do zdefiniowania – faza analiz

Uwaga:
Przy definicji należy pamiętać o określeniu ‘rentowności pacjenta’ ze
statusem FFS- wymagane do UseCase identyfikacja pacjenta (gdy pacjent FFS

5
Nazwa Opis

to także należy określić jaka jest rentowność w ocenie Medicover, wziąć pod
uwagę statusy klientów bo to ma wpływ na to co chcemy mu pokazywać)

Przywileje pacjenta Do zdefiniowania – faza analiz

Uwaga:
Tutaj należy pamiętać jak będziemy definiować ‘przywileje pacjenta’ ze
statusem FFS- wymagane do UseCase identyfikacja pacjenta

Wskazania medyczne Jeden z możliwych atrybutów pacjenta w kontekście wskazań medycznych:

 Skierowanie z Medicover (z terminem ważności, na konkretne
badanie, w przypadku Medycyny Pracy dodatkowa informacja o
narażeniach) lub brak
 Kontynuacja leczenia (alert) lub brak
 Wizyta kontrolna lub brak
 Zewnętrzne skierowanie (lekarz z zewnątrz sieci Medicover) lub
brak
 Pierwsza wizyta
 Brak wskazań– nietypowe sytuacje

Identyfikacja pacjenta Wiedza o:

- rodzaj pacjenta
- status pacjenta
- rentowność pacjenta
- zakres dostępnych świadczeń pacjenta
- przywileje pacjenta (np. preferencja/ograniczenie dostępność do lekarza,
pacjent nie chce się umawiać do lekarza X, lub lekarz nie chce przyjmować
pacjenta X, patrz reklamacje)
- wskazania medyczne
- medical case

Wiedza o pacjencie Historia o pacjencie (np. wysłany formularz do KO 2h temu w sprawie

wystawienia recepty)

Pytanie gdzie ta informacja powinna być zapisana, czy przy Pacjencie po

identyfikacji MRN?

Identyfikacja potrzeby Informacja:

1. Od Pacjenta:
- czy potrzeba = pilny przypadek
- opis problemu medycznego (odpowiedź na pytanie: ‘Co się dzieje
niepokojącego’) + załącznik drzewko od Gosi z medical case
2. Od PFM-Engine:
- kwalifikacja do właściwego świadczenia medycznego na podstawie danych
o: Identyfikacja Pacjenta oraz Reguły Medyczne

Kanał kontaktu z Medicover Jedna z 5 dostępnych opcji:

 Centrum Medicover (recepcja, PCM, KO, KZP, KOK,)
 CallCenter Medicover (Front Line, back Office)
 HotLine Medicover
 Usługa Medicover OnLine (dostępna na stronie
WWW.medicover.pl)
 Usługa Mobile Application (aplikacja mobilna Medicover)

Klient Medicover może umówić świadczenie tylko w:

6
Nazwa Opis

 CM Medicover
 CM Medicover Franszyza
 Call Center Medicover
 On Line Medicover
 Mobile Application Medicover

Możliwość umówienia świadczenia (wizyty) do:

 Medicover
 MediPartner
 Network
 Poddostawca
 Franszyza
 Centrum Damiana

Obecnie umówienia świadczenia (online, Tel, mail, karetka, wizyta domowa)

możliwe jest tylko w spółce Medicover.

Kanał dostarczenia Na dzień 31.12.2014 dostępne są następujące kanały dostarczania świadczeń

świadczeń medycznych medycznych:
 On Line (chat, video- konsultacje)
 Kontakt telefoniczny (do lekarza, do pielęgniarki)
 Mail (do lekarza, do pielęgniarki)
 Wizyta w Centrum Medicover
 Wizyta w Centrum Medicover-Franszyza
 Wizyta w Centrum Damiana
 Wizyta w Centrum MediPartner
 Wizyta w placówkach Network
 Wizyta u poddostawcy zewnętrznego
 Wizyta domowa
 Karetka

Placówki zewnętrzne Placówki Network lub Poddostawcy (jako kanał dostarczenia świadczeń
medycznych, obecnie dotyczy tylko wizyt)

PFM- Engine Silnik reguł dla projektu PFM. W skład PFM -Engine wchodzą:
1. Reguły medyczne
2. Reguły biznesowe
3. Reguły autoryzacji
4. Inne (wynikające z modelu architektury systemu)

Reguły medyczne Reguła kwalifikacji świadczenia medycznego.

Kwalifikacją jest specjalizacja lekarska + zasady nowego modelu opieki.
Z reguł medycznych może wyjść tylko jedna kwalifikacja.

Reguły biznesowe Reguła doboru świadczenia medycznego.

Doborem jest lista dostępnychświadczeń medycznych uwzględniająca
identyfikacje pacjenta oraz dostępność świadczeń w różnych kanałach.
Zapisy w umowie dotyczące dostępności.
Segmentacja klienta

Reguły autoryzacji Mechanizm autoryzacji w placówkach zewnętrznych

Reguły dostępności Zasady dostępności zasobów

Świadczenie medyczne Usługa medyczna realizowana przez dostawcę w sieci Medicover. Dostawcy
realizują następujące usługi:

7
Nazwa Opis

 Konsultacje on-line (chat, video- konsultacje dostępne w usłudze

Medicover OnLine)
 Konsultacje telefoniczne (kontakt z lekarzem lub z koordynatorem
opieki)
 Mail
 Konsultacje (wizyta w placówce)
 Konsultacje jako wizyta domowa (zlecone przez HotLine Medicover)

MedicalCase Przypadek medyczny (problem medyczny), których definicje pochodzą z

nowego Modelu Opieki w Medicover, tzw. umawianie na problem (aktualny
na dzień 31.12.2014).

Medicover Express (MEX) Jedna z form ‘MedicalCase’

W przypadku gdy dany problem medyczny = przeziębienie, grypa,
szczepienie
MEX traktowane jest jako specjalny typ wizyty dostępny tylko w Centrach
Medicover (na dzień 31.12.2014).

Poradnia Bólu Pleców (PBP) Jedna z form ‘MedicalCase’

W przypadku gdy dany problem medyczny = ból pleców
PBP traktowane jest jako specjalny typ wizyty dostępny tylko w Centrach
Medicover (na dzień 31. 12.2014).

Baza kwalifikacji świadczenia Baza reguł medycznych

Baza doboru świadczenia Baza reguł biznesowych

Tutaj jest określona segmentacja Network oraz Poddostawców
Zewnętrznych. Medi Partner, CMD (na kody autoryzacji także i jako
poddostawca)
Tutaj są określone definicje.
Sa to dane referncyjne.

Baza zasobów W zasobach mamy: atrybuty partnera, grafik, dostępność (np.godzina i

miejsce lub zadzwoń)
Baza dostępnych zasobów grafikowych z wszystkich kanałów świadczeń
medycznych.
 On Line (chat, video- konsultacje)
 Kontakt telefoniczny
 Mail
 Wizyta w Centrum Medicover
 Wizyta w Centrum Medicover-Franszyza
 Wizyta w Centrum Damiana
 Wizyta w Centrum MediPartner
 Wizyta w placówkach Network
 Wizyta u poddostawcy zewnętrznego
 Wizyta domowa
 Karetka

Umówione świadczenie Świadczenie jest umówione gdy:

 W CIS jest zarejestrowany fakt umówionej wizyty czyli konsultacji
(pacjent ma na koncie umówienie wizyty)
 W CIS jest zarejestrowany fakt rezerwacji zasobów czyli wizyty
(grafik zajęty, slot zajęty)

Dodatkowo PFM powinien zawierać Informacje jaką opcje wybrał operator,

8
Nazwa Opis

czyli jakie rozwiązanie zostało zaakceptowane

Projekt PFM Projekt mający na celu poprawę skuteczności doboru świadczenia do

potrzeby, podniesienie dostępności świadczeń oraz poprawę efektywności
kosztowej. Projekt obejmuje zakresem zaprojektowanie i wdrożenie nowego
procesu umawiania świadczeń (na potrzebę) oraz zaprojektowanie i
wdrożenie Systemu wspierającego realizację nowego procesu.

System PFM Rozwiązanie technologiczne wspierające realizację nowego procesu

umawiania świadczeń. Zaprojektowanie Systemu PFM, wyłonienie jego
dostawcy oraz przeprowadzenie budowy, testów i wdrożenia Systemu PFM
są częścią (zadaniami) projektu PFM. System PFM będzie się składał z
Platformy BPM, bazy reguł medycznych i biznesowych, powiązań
(interfejsów) z innymi systemami Medicover.

AKRONIMY
Skrót Opis

MRN Indywidualny numer pacjenta w bazie CIS. Numer unikalny.

FFS Fee For Service

CIS/CIS MM System wewnętrzny Moduły Medyczne dostępny dla pracowników Centrum

Medicover oraz Call Center.

MOB Mobile Application

MOL Medicover OnLine

MEX Medicover Express

PBP Poradnia Bólu Pleców

APD Ambulatoryjna Pomoc Doraźna

KZP Kierownik Zespołu Pielęgniarskiego

KO Koordynator Opieki

KOK Kierownik Obsługi Klienta

ZOP Zespół Opiekunów Pacjenta

PCM Patient Care Manager – Indywidualny Opiekun Pacjenta

PFM Patient Flow Management

TEMATY, ZAGADNIENIA W KONTEKŚCIE TBD/TBC

 Rodzaj pacjenta - definicja

 Reguły medyczne/kwalifikacja świadczenia definicja

9
  Reguły biznesowe - definicja
 Reguły dostępności - definicja
 Reguły autoryzacji (patrz use case) – definicja + use case
 Reguła rezerwacji/+zwalniania (patrz use case) + reguła rezerwacji wizyt pierwszorazowych
(do konkretnego lekarza lub specjalisty) – definicja + use case
 Reguły edukacji pacjenta (np. kontekst przygotowania się do leczenia, badania)- definicja +
wymagania biznesowe, raporty
 Integracja z systemami do umawiania wizyt w placówkach zewnętrznych (Network,
poddostawcy zewnętrzni) oraz konsultacji on-line, telefoniczne, wyjzadowe (wizyta domowa,
karetka) – do Architekta IT
 Proces sprzedaży w procesie umawiania świadczenia – definicja + use case
 Udostępnianie zasobów dla pacjentów FFS (patrz rezerwacja wizyt dla pacjentów FFS, jak ich
obsługujemy w przypadku, gdy nie maja wskazania medycznego zarejestrowanego przez
Medicover, np. zawsze znajdujemy dla nich dostępne wizyty a nie proponujemy chat)

OGÓLNE INFORMACJE O PROJEKCIE PFM

TŁO I PRZYCZYNY

 Umówienie do właściwego świadczenia medycznego (poprawny schemat opieki medycznej)

 Zapewnienie właściwego standardu świadczeń różnym segmentom pacjentów
 Ułatwienie pacjentom korzystania ze świadczeń Medicover
 Powtarzalny wysoki standard pracy konsultantów
 Budowanie właściwego wizerunku Medicover
 Edukacja pacjentów w zakresie dostępnych świadczeń
 Ograniczenie strat (poprawa efektywności kosztowej)

CEL PROJEKTU PFM

Poprawa dostępności świadczeń medycznych, ich skuteczności dostarczenia oraz efektywności

kosztowej.

ZAKRES PROJEKTU PFM

 Usprawnienie procesu umawiania wizyt/ umawianie świadczeń medycznych (np.: porada tel,
chat, wizyta)
 Opracowanie architektury IT rozwiązania wspierającego nowy proces
 Wybór i wdrożenie rozwiązania technologicznego dla Recepcji, CallCenter i MedicoverOnLine
oraz MedicoverMobile
 Wdrożenie zmian w procesach
 Zaprojektowanie i wdrożenie mechanizmu autoryzacji świadczenia w kanałach zewnętrznych
 Na obecnym etapie projekt obejmuje tylko pacjentów Medicover
 Kanały umawiania świadczeń jak w definicji wyżej

WYKLUCZENIA

Umawianie świadczeń w:
 Szpitalu Medicover
 Centrum Damian

10
  MediPartner
 Network
 Poddostawcy
 Integracja z CareExperts
 Integracja z Invimed
 Obsługa Aptek Medicover

KRYTERIA SUKCESU PROJEKTU PFM

 #1 wzrost efektywności kosztowej

 dostarczanie świadczeń zgodnie z potrzebą medyczną
 dobór właściwych świadczeń dla danego segmentu
 #2 wzrost skuteczności procesu opieki (efektywności dobrania świadczenia do problemu)
 #2 wzrost dostępności świadczeń medycznych
 #3 wzrost satysfakcji pacjentów z umówienia świadczenia
 #3 wzrost efektywności pracy konsultantów CC i CM (skrócenie średniego czasu obsługi: talk
time + after call)

INTERESARIUSZE PROJEKTU PFM

 Pion Operacyjny, Pion Medyczny, Dział Customer Service, Network, MediPartners,

Poddostawcy, Dział Rozwoju Biznesu (MOL), Marketing (komunikacja zewn.), Klienci
(biznesowi), Dział Finansowy (rozliczenia i BC), IT
 Odbiorcy: Pacjenci, Recepcje Medicover+MediPartner+Network+Poddostawcy, Call Center
MC, Placówki MediPartner, Placówki Network , Poddostawcy

OBECNY PROCES UMAWIANIA WIZYT

Obecnie proces umawiania wizyt skupia się na odkryciu oczekiwania pacjenta i zarezerwowaniu dla
niego wizyty.

CEL I WŁAŚCICIEL PROCESU

Cel
 Umówienie pacjenta na właściwą wizytę (zgodną z oczekiwaniami pacjenta)
 spełnienie oczekiwań klientów przy zachowaniu zasad dostępności usług zgodnie z zakresem
wykupionej usługi
 Umówienie wizyty zgodnie z życzeniem pacjenta lub zaproponowanie rozwiązania zgodnego z
odkrytą potrzebą
 Realizacja potrzeb klienta; takie pokierowanie realizacją usługi, żeby zbudować dobre
doświadczenia; tworzenie dobrego pierwszego wrażenia
 Dostarczenie pacjentowi rozwiązania (próbujemy zidentyfikować potrzebę i dobrać
rozwiązanie, ale wciąż mamy procedury ustawione na "umawianie wizyt")
Właściciel
Brak (niezdefiniowany)

11
MIERNIKI SUKCESU

Brak (niezdefiniowane)

PRZEBIEG PROCESU – OGÓLNY MODEL DLA TRZECH PODSTAWOWYCH KANAŁÓW

UMAWIANIA

NOWY PROCES UMAWIANIA ŚWIADCZEŃ

Nowy proces ma zapewnić odkrycie realnej potrzeby medycznej pacjenta oraz dobranie dla tej potrzeby
optymalnego świadczenia, zgodnie z warunkami biznesowymi opisującymi relację z pacjentem/klientem.

CEL I WŁAŚCICIEL PROCESU

Cel: Optymalny dobór świadczenia medycznego dla konkretnego przypadku pacjenta.

Dobór jest optymalny, gdy jednocześnie zapewnia:

Skuteczność: zgodny z wiedzą medyczną i potrzebą wynikającą ze stanu zdrowia pacjenta
Dostępność:
 zgodnie ze standardami dostarczania opieki Medicover (spełnione zobowiązania umowne
Medicover wobec Klienta),
 zgodnie z profitability danego klienta,

12
  w jak najbliższym terminie i miejscu (lub zgodnie z oczekiwaniem dot. miejsca i terminu) oraz
zgodnie z nowymi standardami opieki
 z zapewnieniem spełnienia zaleceń lekarza (skierowanie z terminem badania, wynik badania
dostępny przed kolejną wizytą, termin wizyty kontrolnej zapewniający kontynuację leczenia)
Oszczędność: zapewniający efektywność kosztową (zgodnie z regułami biznesowymi, przy najniższych
kosztach dla Medicover)

Właściciel: dyr. Customer Service Medicover

MIERNIKI SUKCESU PROCESU

1. Skuteczność (efektywności dobrania świadczenia do problemu)

 udział (%) przypadków skierowanych do świadczenia wśród wszystkich przypadków
kwalifikujących się do świadczenia
 udział (%) umówień świadczeń gdzie została przeprowadzona kwalifikacja w PFM wśród
wszystkich umówień
 udział (%) propozycji PFM zaakceptowanych przez pacjenta wśród wszystkich umówień
 udział (%) wizyt umawianych przez PFM wśród wszystkich wizyt (kryterium sukcesu projektu)
 udział (%) badań w zakresie medycyny pracy skierowanych poprzez PFM wśród wszystkich
badań medycyny pracy (oczekiwane 100%)
2. Dostępność
 turnaround time: okres czasu między stwierdzeniem potrzeby świadczenia, a dostarczeniem
skutecznego świadczenia
 udział (%) przypadków gdzie specjalne zalecenie lekarza zostało spełnione wśród wszystkich
przypadków ze specjalnym zaleceniem lekarza
 ilość dostępnych wizyt na następne 24h/72h/7d, w poszczególnych lokalizacjach, w
poszczególnych specjalnościach, w placówkach Medicover
 ilość dostępnych wizyt na następne 48h/14d, w poszczególnych lokalizacjach, w
poszczególnych specjalnościach, w placówkach Partnerów (Network)
 ilość dostępnych wizyt na następne 24h/72h/7d, w poszczególnych lokalizacjach, w
poszczególnych specjalnościach, w placówkach MediPartners
3. Efektywność kosztowa
 zapewnić założony administracyjnie rozkład umówień do droższych i tańszych dostawców
(ukrywać droższe rozwiązania, jeśli rozkład jest niekorzystny), chcemy kierować do tańszych
świadczeń i usługodawców
 udział (%) skierowań na dodatkowe świadczenia (badania, konsultacje specjalistów,
rehabilitacja) zgodnych ze schematem leczenia lub autoryzowanych ręcznie lub zgodnie z
regułami biznesowymi wśród wszystkich skierowań (skierowania wewnętrzne są zawsze
autoryzowane pozytywnie - automatyczna reguła biznesowa); dotyczy tylko świadczeń
płatnych z abonamentu; nie chcemy wizyt i badań, które nie mają uzasadnienia medycznego
 średni koszt medyczny per pacjent, w segmentach (rodzaj pacjenta, status pacjenta)
 średni koszt dostarczenia skutecznego świadczenia medycznego per pacjent, w segmentach
(rodzaj pacjenta, status pacjenta)
 skrócenie średniego czasu obsługi talk time, after call
4. Satysfakcja pacjentów
 Ankieta satysfakcji dla procesu umawiania świadczeń (krótko po umówieniu, nie dotyczy
dostarczenia świadczenia)

13
PRZEBIEG PROCESU – OGÓLNY MODEL

RÓŻNICE POMIĘDZY OBECNYM PROCESEM A NOWYM PROCESEM

 Zmiana procesu z ‘Umawianie wizyt’ na ‘Umawianie świadczeń’. Nowy proces ma szerszy

zakres i oferuje pacjentom poza wizytą dodatkowe świadczenia:

14
  Skierowanie do porady telefonicznej z lekarzem
 Skierowanie do porady on Line z lekarzem (tzn Chat z Lekarzem)
 Umówienie konsultacji medycznej na wskazany problem w odpowiednie miejsce
 Właściwy dobór świadczenia zgodny z kwalifikacją medyczną
 Efektywne zarządzenie skutecznością, dostępnością oferowanego świadczenia
 Jednolity proces umawiania świadczeń w recepcji Medicover, CallCenter Medicover,
MedicoverOnLine (aplikacja, strona WWW) do różnych kanałów dostarczenia (kanały
dostarczenia: Medicover, Damian, MediPartner, Network, Poddostawcy, Franszyza)
 Mechanizm autoryzacji umawiania świadczenia do placówek zewnętrznych
 Szersza identyfikacja pacjenta (rentowność kontraktu, status pacjenta, rodzaj pacjenta, zakres
dostępnych świadczeń, przywileje)
 Wdrożenie reguł medycznych - każdorazowe pytanie o potrzebę w procesie umawiania
świadczenia, celem kwalifikacji do właściwego świadczenia
 Wdrożenie reguł biznesowych - dobór dostępnego świadczenia w różnych kanałach
świadczenia medycznego
 Udostępnianie wolnych zasobów do umawiania świadczeń (patrz grafiki lekarskie z różnych
kanałów świadczenia medycznego: Medicover, MediPartner, Network, Poddostawcy, Damian,
Franszyza)
 System rezerwacji zasobów (lista rezerwacji + sms)
 System potwierdzania rezerwacji zasobów (i zwalniania zasobów w przypadku braku
potwierdzenia)
 Możliwość ofertowania sprzedaży i dosprzedaży usług medycznych w procesie umawiania
świadczeń

PROCESY POWIĄZANE Z PROCESEM Z NOWYM PROCESEM

 Odwoływanie wizyt (na życzenie pacjenta)

 Odwoływanie wizyt (z przyczyn po stronie Medicover)
 Zmiana terminu wizyt (na życzenie pacjenta)
 Kontakt z Hotline (pacjent dzwoni lub przełączenie z CallCenter Medicover)
 Obsługa umówienia wizyt u poddostawcy
 Obsługa umówienia wizyt u MediPartner
 Uruchomienie wizyty dodatkowej (tylko w Recepcjach Medicover)
 Kontakt BackOffice  Pacjent, w celu umówienia wizyty
 Kontakt Centrum Medicover  Pacjent, w celu umówienia wizyty
 Przyjmowanie reklamacji
 Obsługa umówienia ze skierowania
 Obsługa spraw pacjentów (np. wyjaśnianie, edukacja)
 Sprzedaż usług – upsell (pilot)
 Telefoniczna pomoc medyczna (pilot od lutego 2015)
 Obsługa "kodu czerwonego"
 Uzyskanie dostępu do Medicover Online
 Dostarczenie wizyty

ZAŁOŻENIA DOTYCZĄCE WYBORU OFERENTÓW ORAZ KRYTERIA OCENY

Zgodne z Załącznikiem nr1 oraz Załącznikiem nr2

Poniżej propozycja, do zweryfikowania z aktualną formą Medicover:
Rozpatrywane będą oferty podmiotów, które spełnią łącznie wszystkie poniższe kryteria:

15
 Roczny przychód za ostatni rok obrachunkowy za bieżący lub poprzedni rok obrotowy (2014) z tytułu
świadczenia usług wyniósł minimum x zł słownie: x. Wymagana kopia sprawozdania finansowego za
dany okres.
Oferent przeprowadził minimum x samodzielnych wdrożeń platformy BPM w okresie x miesięcy przed
złożeniem niniejszej oferty na ternie Polski (wymagane potwierdzenie poprzez załączenie do oferty
kopii odbiorów końcowych wdrożeń platformy BPM wraz z referencjami).
Oferent zapewni bezpłatny serwis przez okres jednego roku od wdrożenia systemu.
Posiada certyfikat zarządzania bezpieczeństwem informacji ISO 27001.
Dostawca oprogramowania w ofercie przedstawi harmonogram rzeczowo-finansowy prac z podziałem
na poszczególne etapy realizacji zadania, z uwzględnieniem etapu analizy przedwdrożeniowej,
realizacji, testowania i szkolenia pracowników.
Wykonawca zobowiąże się do udostępnienia zamawiającemu kodów źródłowych w celu rozwijania i
utrzymania przez zamawiającego platformy BPM wyłącznie na własny użytek, na wypadek gdyby
istniało zagrożenie zaprzestania prowadzania działalności przez wykonawcę lub zaprzestania
świadczenia usług w tym serwisowych przez podmiot realizujący projekt na rzecz zamawiającego.

ZAŁOŻENIA DLA SYSTEMU PFM

PRZEZNACZENIE SYSTEMU PFM

Przeznaczeniem Systemu PFM jest osiągnięcie założonych kryteriów sukcesu, czyli takie wsparcie realizacji
nowego procesu umawiania świadczeń, aby w powtarzalny sposób zapewniać optymalny dobór świadczenia do
potrzeby medycznej, we wszystkich kanałach umawiania objętych zakresem projektu.

GŁÓWNE ZAŁOŻENIA ARCHITEKTONICZNE

System PFM będzie się składał z następujących części:

 Platforma BPM (silnik przetwarzania reguł)

 Interfejsy do istniejących systemów

WYMAGANIA DLA SYSTEMU PFM

BIZNESOWE – OGÓLNE DOTYCZĄCE PLATFORMY BPM

Platforma BPM powinna:

 adresować zarówno procesy z udziałem pracowników jak również procesy systemowe

 być utrzymywana przez właściciela biznesowego oraz być łatwo publikowana dla wykonania
procesu
 obsłużyć wykonywanie i zarządzanie zarówno prostymi jak również bardzo złożonymi
procesami przez silnik procesowy (PFM Engine), zarzadzanie procesami których przebieg
zmienia się dynamicznie w trakcie ich realizacji w rezultacie uzyskiwania danych (Dynamic
Case Management)
 szybkie tworzenie elektronicznych formularzy, które uzupełniają przepływ pracy w procesie,
eliminują wykorzystanie papieru oraz usprawniają pracę (formularze w CallCenter oraz
BackOffice)
 łatwe udostępnienie, zarządzanie oraz kontrolę treści, która jest potrzebna dla podejmowania
właściwych decyzji

16
  monitorowanie aktywności procesu, uzyskiwanie natychmiastowego wglądu w zawartości
procesu z podglądem statusu wraz z generowaniem raportów
 umożliwienie zmian w czasie rzeczywistym, z modyfikacją sterowania, zmianą ról, formularzy
oraz możliwością szybkiego i łatwego dodawania nowych procesów bez wpływu na operacje
biznesowe, które mogłoby spowodować ich spowolnienie
 integracje z obecnym środowiskiem IT Medicover wg ustalonych serwisów integracyjnych
 zarządzanie zasobami (ilość wizyt) dostosowanymi do potrzeb pacjenta

ARCHITEKTONICZNE

 Model architektury – do potwierdzenia z Architektem IT

 Bazodanowe – do potwierdzenia z Architektem IT
 Sprzętowe – do potwierdzenia z Architektem IT
 Proponowane zmiany do CIS (wersja 5.4., wdrożenie planowane na sierpień 2015)
o Informacja w CIS, że skierowanie do Medycyny Pracy zostało wystawione na
konkretnego membera plus jakie narażenia (potrzebne do identyfikacji pacjenta w
kontekście wskazań medycznych, dalej do procesu jak postępować z pacjentem
mając takie informacje)
o Informacja w CIS, że pacjent chce umówić świadczenie medyczne (np. info z IVR, info
dla CallCenter celem szybkiego przełączenia na nowy widok PFM)
o Rejestracja w CIS propozycji świadczeń i odmowy (czyli nie tylko umówienia
konsultacji/wizyty, ale także propozycja: rezerwacji zasobów, konsultacja APD,
telefoniczna, on-line, wizyty dodatkowe). Informacja z PFM do CIS.
o WS umówienie świadczeń w CIS dla akcji rezerwacji zasobów oraz propozycji
alternatywnych świadczeń (teraz WS umawia w CIS świadczenia = wizyta czyli
konsultacja)

FUNKCJONALNE

DIAGRAM PRZYPADKÓW UŻYCIA

Aktorzy:
Aktor1 – pacjent
Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine
Aktor5 – PFM GUI nowy system, widok dla operatora
Aktor6 – pracownik Centrum Medicover
Aktor7 – pracownik CallCenter Back Office
Aktor8 – placówka zewnętrzna
Aktor9 – dział Sprzedaży w Medicover
Aktor10- administrator zmian w PFM

PRZYPADKI UŻYCIA

IDENTYFIKACJA PACJENTA
Nazwa Identyfikacja pacjenta

Krótki Opis Przypadek dotyczy czynności związanych z identyfikacją pacjenta, który wybrał

17
 kanał kontaktu z Medicover celem umówienia świadczenia medycznego.

Klient jako pacjent zarejestrowany w bazie CIS (może mieć dowolny status pacjenta:
FFS, Aktywny, Nieaktywny).
Warunki wstępne Zarejestrowany w bazie CIS = ma numer MRN
Informacja w CIS, że Pacjent chce umówić świadczenie medyczne.
Operator zna tożsamość pacjenta (jest założona karta MRN dla pacjenta).

Pacjent został zidentyfikowany przez PFM.

Pacjent Zidentyfikowany oznacza, że PFM zna:
- rodzaj pacjenta
- status pacjenta
Warunek pomyślnego
- rentowność pacjenta
zakończenia
- zakres dostępnych świadczeń pacjenta
- przywileje pacjenta
- wskazanie medyczne
- medical case

Jeśli przynajmniej jedna z opcji identyfikacji pacjenta z warunku pomyślnego

zakończenia nie jest znana. Nie jest znana, czyli PFM nie mógł zidentyfikować:
- rodzaj pacjenta lub
- status pacjenta lub
- rentowność pacjenta lub
Warunek - zakres dostępnych świadczeń lub
niepomyślnego - przywileje lub
zakończenia - wskazanie medyczne
- medical case
Jeśli Pacjent nie został zidentyfikowany to PFM wysyła komunikat do Operatora
‘Umówienie świadczenia nie jest możliwe dla tego pacjenta’ . Dotyczy tylko
przypadków, które przeszły przez system PFM. Przypadki medyczne, które nie
przeszły przez PFM są obsługiwane przez operatora w ten sam sposób co obecnie.

Aktor1 – pacjent
Aktor2 – operator
Aktor
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM Engine

1. Pacjent kontaktuje się z Operatorem

Jeśli Operator <> (System Medicover Online lub Aplikacja mobilna) to Operator
wyszukuje Pacjenta za pomocą:MRN lub Imię i Nazwisko lub PESEL i adres
zamieszkania = identyfikacja tożsamości pacjenta
Jeśli Operator = (System Medicover Online lub Aplikacja mobilna) to Operator
wyszukuje Pacjenta za pomocą:Login do systemu (MRN+hasło)
2. Jeśli Pacjent został znaleziony to:
Główny scenariusz
System wyświetla informacje o Pacjencie:MRN, Imię, Nazwisko, Pesel, Nr telefonu,
Adres zamieszkania (zakres danych weryfikujących tożsamość zależny od rodzaju
systemu: CIS, MOL)
3. System wysyła informacje o identyfikacji pacjenta do PFM Engine.
4. Identyfikacja pacjenta przez PFM Engine poprawna

KONIEC

Alternatywny 2.1. Jeśli Pacjent nie został znaleziony to:

scenariusz 1 2.2. System nie wyświetla Informacji o Pacjencie
2.3. System nie wysyła Informacji o identyfikacji pacjenta do PFM Engine
2.4. Operator zakłada kartę Pacjenta w CIS.

Dotyczy przypadku gdy Operator <> (System Medicover Online lub Aplikacja

18
 mobilna)

2.5. Dalsze kroki identyfikacji jak w Głównym Scenariuszu 3-4 (znamy tożsamość
pacjenta, mamy numer MRN pacjenta w bazie CIS)

KONIEC

4.1. Identyfikacja pacjenta przez PFM Engine niepoprawna

4.2. Jeśli Pacjent nie został zidentyfikowany to PFM wysyła komunikat do Operatora
Alternatywny ‘Umówienie świadczenia nie jest możliwe dla tego pacjenta’ . Dotyczy tylko
scenariusz 2 przypadków, które przeszły przez system PFM. Przypadki medyczne, które nie
przeszły przez PFM są obsługiwane przez operatora w ten sam sposób co obecnie.

KONIEC

Do Architekta:

Czy:

‘identyfikacja pacjenta’ powinna wychodzić z CIS do PFM czyli bez Informacji o

tożsamości pacjenta (czyli nr MRN, imie, nazwisko, pesel) , dalej PFM na podstawie
danych o identyfikacji pokazuje 1 pytanie ‘co się dzieje niepokojącego’ itd.?
Pytania/do czy może z CIS do PFM Engine ma wychodzić tożsamość pacjenta (MRN, imię,
potwierdzenia nazwisko, pesel) , dalej PFM wysyła informacje o identyfikacji pacjenta do CIS +
pokazuje 1 pytanie w XML.?

Przy drugim rozwiązaniu musi być baza podpięta do PFM, która zbiera informacje o
tożsamości pacjenta i identyfikacji pacjenta (kwestia aktualizacji takiej bazy z CIS,
jak często, jaka metoda aktualizacji).

Powyższy use case opisuje sytuacje nr 1

IDENTYFIKACJA POTRZEBY
Nazwa Identyfikacja potrzeby pacjenta

Krótki Opis Przypadek dotyczy czynności związanych z identyfikacją potrzeby medycznej

wskazanej przez pacjenta i właściwą kwalifikacją świadczenia medycznego do
konkretnego problemu wg reguł medycznych

Warunki wstępne Zidentyfikowany pacjent w PFM.

Wykonany przypadek użycia: identyfikacja pacjenta

Warunek pomyślnego Kwalifikacja do właściwego świadczenia medycznego.

zakończenia Kwalifikacja wg reguł medycznych.
Wynikiem jest jedna kwalifikacja

Warunek PFM nie potrafił skwalifikować danego przypadku medycznego do właściwego

niepomyślnego świadczenia.
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine
Aktor5 – PFM GUI nowy system, widok dla operatora

Główny scenariusz 1. Do PFM trafia informacja o identyfikacji pacjenta.

19
 2. Pacjent został zidentyfikowany przez PFM
3. Jeśli przypadek nie jest pilny to system dalej sprawdza, czy dany medical
case jest obsługiwany przez PFM (znamy proces obsługi danego przypadku
medycznego, np. jak osbluzyc pacjenta dla problemu ból pleców)
4. Jeśli PFM zna obsługę danego przypadku medycznego (medical case) to
PFM-Engine wysyła pierwszy komunikat do PFM GUI
5. Operator przedstawia dany komunikat Pacjentowi
6. Operator uzyskuje informacje zwrotną od Pacjenta i rejestruje ją w PFM
GUI
7. PFM GUI wysyła informacje do PFM-Engine.
8. PFM-Engine zwraca kolejny komunikat do PFM GUI itd.
9. Krokiem końcowym scenariusza jest akcja podana przez ustalony proces w
systemie PFM dla obsługiwanego przypadku medycznego (medical case).
Będzie to akcja po której PFM-Engine rozpozna, że pacjent ma kwalifikacje
do świadczenia medycznego.
10. Wynikiem końcowym procesu jest jedna kwalifikacja medyczna dla danej
potrzeby.

KONIEC

Alternatywny 3.1. Jeśli przypadek jest pilny to przekierowanie do obsługi pacjenta wg

scenariusz 1 istniejących procedur obsługi pacjenta na ‘kod czerwony’ w CM
Medicover, nagły przypadek w CallCenter Medicover

Alternatywny 4.1. Jeśli przypadek nie jest pilny i PFM nie zna obsługi danego przypadku
scenariusz 2 medycznego (medical case) to przekierowanie obsługi pacjenta wg
istniejących procedur obsługi pacjenta dla danego przypadku medycznego
(np. obsługa Medycyny Pracy, diagnostyka, pediatria, itp.)

Uwagi Treść komunikatu/ów wyświetlana w PFM GUI zależna od struktury ustalonego

procesu w PFM. Może być różna w zależności od medical case w kontekście
identyfikacji pacjenta oraz reguł medycznych, np.:
 Czy pacjent FFS (patrz Identyfikacja Pacjenta)
 Czy wskazanie medyczne = skierowanie (patrz Identyfikacja Pacjenta) itp.
Ilość wymienionych komunikatów pomiędzy PFM-Engine a PFM GUI zależna od
struktury ustalonego nowego procesu w projekcie PFM.
Proces uwzględnia atrybut pilnego przypadku oraz reguły medyczne na podstawie,
których jest generowana decyzja o kwalifikacji do konkretnego świadczenia
medycznego.
Szczegółowy nowy proces PFM będzie ustalony na etapie analiz systemowych.
Zakładamy, że w PFM zawsze jest kwalifikacja, może być różna w zależności od
wskazań medycznych (podanych w definicji wskazań medycznych) oraz ogólnie
reguł medycznych.

Pytania/do Do Architekta:
potwierdzenia PFM GUI czyli nowy widok dla operatora, pytanie jaki to będzie widok, czy forma
okna XML (pytanie zadane przez PFM-Engine - odpowiedz wskazana przez
operatora) czy może część graficzna UI w systemie CIS MM, czy może osobna
aplikacja?

DOBÓR ŚWIADCZENIA
Nazwa Dobór świadczenia medycznego

Krótki Opis Przypadek dotyczy czynności związanych z wyszukaniem i doborem świadczeń

20
 medycznych w poszczególnych kanałach dostarczania świadczeń (proces zależny od
reguł biznesowych).

Warunki wstępne Pacjent posiada jedną kwalifikacje do świadczenia medycznego (informacja w PFM-
Engine).
Wykonany przypadek użycia: Identyfikacja potrzeby

Warunek pomyślnego Operator otrzymał jedną lub kilka (jeśli kilka to z określonym priorytetem)
zakończenia propozycji realizacji świadczenia medycznego (np. chat, wizyta w CM Medicover,
wizyta w Network).

Warunek Operator nie otrzymał żadnej propozycji z PFM-Engine.

niepomyślnego
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine
Aktor5 – PFM GUI nowy system, widok dla operatora

Główny scenariusz 1. PFM-Engine wyszukuje dostępne świadczenia medyczne (wynikowa

kwalifikacji) w określonych kanałach dostarczania świadczeń.
2. Określonych, czyli wynikających z reguł biznesowych.
3. Wyszukanie na podstawie dostępnych Informacji w bazie zasobów PFM
4. PFM znalazł przynajmniej jedną propozycje świadczenia
5. PFM-Engine podsyła zakres proponowanych świadczeń do PFM GUI
Jeśli proponowane świadczenie dotyczy umówienia wizyty w placówkach
zewnętrznych, które nie są automatycznie zintegrowane ze środowiskiem
PFM to wymagane jest uruchomienie przypadku użycia: Zgłoszenie
potrzeby ręcznej weryfikacji dostępności zasobu (zewnętrznego)
6. Operator prezentuje dostępne świadczenia medyczne pacjentowi wg
priorytetów wskazanych w regułach biznesowych.

KONIEC

Alternatywny 4.1. PFM-Engine nie znalazł dostępnych świadczeń wynikających z reguł

scenariusz 1 medycznych i biznesowych
4.2. Uruchomienie procesu alternatywnych świadczeń tj.:
 proces informowania pacjenta o możliwości umówienia
świadczeń on-line lub
 proces informowania pacjenta o możliwości umówienia wizyt
dodatkowych w Centrach Medicover = wysłanie formularza
bezpośrednio do CM, czyli przypadek użycia zgłoszenie potrzeby
organizacji wizyty dodatkowej lub
 proces informowania pacjenta o możliwości umówienia
świadczenia w APD lub
 proces informowania pacjenta o możliwości konsultacji
telefonicznej
4.3. PFM – Engine powinien otrzymać i odłożyć informacje jakie alternatywne
świadczenie zostało zaproponowane pacjentowi (patrz mierniki sukcesu
procesu).

KONIEC

Uwagi Zakres przedstawionych kanałów dostarczenia zależny jest od Informacji jakie

otrzymał PFM-Engine z bazy zasobów.

21
 Zakres dostępnych zasobów w poszczególnych kanałach dostarczenia zależny jest
od Informacji jakie posiada PFM-Engine pobranych z bazy dostępności zasobów
grafikowych.

ZGŁOSZENIE POTRZEBY ORGANIZACJI DODATKOWEJ WIZYTY

Nazwa Zgłoszenie potrzeby organizacji dodatkowej wizyty

Krótki Opis Przypadek dotyczy czynności związanych ze zgłoszeniem potrzeby rezerwacji wizyty
dodatkowej w Centrum Medycznym Medicover przez operatora CallCenter.

Warunki wstępne Brak dostępnych wizyt w określonych kanałach dostarczenia lub wizyt dostępnych
w godzinach preferowanych dla pacjenta.
Potrzeba pacjenta organizacji wizyty dodatkowej.

PFM-Engine nie znalazł dostępnych świadczeń w określonych kanałach dostarczenia

świadczeń.

Warunek pomyślnego Potrzeba umówienia Wizyty dodatkowej została zgłoszona do Centrum

zakończenia Medycznego Medicover.

Warunek Potrzeba umówienia Wizyty dodatkowej nie została zgłoszona do Centrum

niepomyślnego Medycznego Medicover.
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine

Aktor5 – PFM GUI nowy system, widok dla operatora

Aktor6 – pracownik Centrum Medicover

Główny scenariusz 1. Operator CallCenter zaproponował Pacjentowi możliwość umówienia wizyty

dodatkowej w Centrum Medicover
2. Pacjent zaakceptował propozycje
3. Operator przekazał potrzebę umówienia wizyty dodatkowej w danym regionie,
na daną specjalizacje lekarska (opcjonalnie konkretny lekarz: imię i nazwisko),
na dany termin (dzień, preferowana godzina). Potrzeba przekazana do
pracownika Centrum Medicover. Zgłoszenie zarejestrowane w PFM GUI,
widoczne dla pracownika Centrum Medicover.
4. Pracownik Centrum Medicover otrzymuje informacje (alert) w PFM GUI o
potrzebie umówienia wizyty dodatkowej na dany przypadek medyczny dla
danego pacjenta (wszystko odbywa się w środowisku PFM).
5. PFM powinien przetrzymać informacje o wysłanym alercie (kiedy data godzina
oraz przez kogo i w jakiej sprawie).

KONIEC

ZGŁOSZENIE POTRZEBY RĘCZNEJ WERYFIKACJI DOSTĘPNOŚCI ZASOBU (ZEWNĘTRZNEGO)

Nazwa Zgłoszenie potrzeby ręcznej weryfikacji dostępności zasobu (zewnętrznego)

Krótki Opis Przypadek dotyczy czynności związanych z potrzebą ręcznej weryfikacji dostępności
zasobu w placówkach zewnętrznych

22
 Warunki wstępne Możliwe dostępne wizyt w określonych kanałach dostarczenia lub wizyt dostępnych
w godzinach preferowanych dla pacjenta.
Potrzeba pacjenta organizacji wizyty.

PFM-Engine znalazł dostępne świadczenia w zewnętrznych kanałach dostarczenia

świadczeń.

Warunek pomyślnego Potrzeba umówienia wizyty została zgłoszona do placówki zewnętrznej.

zakończenia

Warunek Potrzeba umówienia wizyty nie została zgłoszona do placówki zewnętrznej

niepomyślnego
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine

Aktor5 – PFM GUI nowy system, widok dla operatora

Aktor6 – pracownik Centrum Medicover

Aktor7 – pracownik CallCenter - Back Office

Główny scenariusz 1. Operator callCenter zaproponował możliwość umówienia wizyty w placówkach

zewnętrznych
2. Pacjent zaakceptował propozycje
3. Operator przekazał do Back Office potrzebę umówienia wizyty w danym
regionie, na daną specjalizacje lekarska, na dany termin (dzień, preferowana
godzina) dla danego pacjenta
4. Back Office otrzymał informacje od Operatora o potrzebie umówienia wizyty na
dany przypadek medyczny dla danego pacjenta.
5. Back Office oddzwoni do pacjenta z propozycją rezerwacji wizyty w placówce
zewnętrznej.
6. Dalej wg procesu utworzenia kodu autoryzacji wizyty (mechanizm autoryzacji).

KONIEC

Uwaga Jeśli na etap wdrożenia systemu PFM, Medicover będzie gwarantować dostępność
do systemu PFM GUI dla placówek zewnętrznych to krok 3, Głównego Scenariusza
zostanie zmodyfikowany o:

3.1. Operator przekazał do Administracji Placówki Zewnętrznej potrzebę

umówienia wizyty w danym regionie, na daną specjalizacje lekarska, na dany
termin (dzień, preferowana godzina) dla danego pacjenta
3.2. Administracja Placówki Zewnętrznej otrzymuje informacje od Operatora o
potrzebie umówienia wizyty na dany przypadek medyczny dla danego
pacjenta.
3.3. Administracja Placówki Zewnętrznej oddzwoni do pacjenta z propozycją
rezerwacji wizyty w placówce zewnętrznej.
3.4. Dalej wg procesu utworzenia kodu autoryzacji wizyty (mechanizm autoryzacji).

KONIEC

AKCEPTACJA I UMÓWIENIE ŚWIADCZENIA

Nazwa Akceptacja i Umówienie świadczenia

23
Krótki Opis Przypadek dotyczy czynności związanych z akceptacja przez pacjenta propozycji
świadczenia medycznego i jednoczesnym umówieniem wizyty przez operatora.

Warunki wstępne Operator otrzymał jedną lub kilka (jeśli kilka to z określonym priorytetem)
propozycji realizacji świadczenia medycznego.
Wykonany przypadek użycia: Dobór świadczenia

Warunek pomyślnego Zaproponowane świadczenie zostało zaakceptowane przez pacjenta i

zakończenia zarejestrowane jako umówione w CIS, czyli wizyta zarezerwowana w CIS, umówiona
dla konkretnego pacjenta

Warunek Jeśli potrzeba umówienia świadczenia przez pacjenta nie zakończyła się
niepomyślnego umówieniem świadczenia w CIS.
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine

Aktor5 – PFM GUI nowy system, widok dla operatora

Główny scenariusz 1. Operator prezentuje dostępne świadczenia medyczne pacjentowi.

2. Jeśli umówienie świadczenia = konsultacja (wizyta) to operator podaje
pacjentowi następujące informacje:
Placówka (gdzie planowana jest wizyta)
Data i godzina (kiedy planowana jest wizyta)
Lekarz (do kogo planowana jest wizyta)
Specjalizacja (na jaką specjalizacje planowana jest wizyta)
3. Pacjent akceptuje świadczenie medyczne
4. Informacja o akceptacji jest podsyłana do systemu CIS gdzie następuje
rejestracja umówienia wizyty w CIS (obecną usługą CIS – umówienie wizyty).
5. Pacjent otrzymuje potwierdzenie umówienia świadczenia (potwierdzenie
każdorazowo mailem, w przypadku umówienia w Centrum Medicover
opcjonalnie Pacjent otrzymuje wydruk danych zarezerwowanej wizyty)
6. Propozycja konkretnego rozwiązania na konkretny przypadek medyczny dla
konkretnej identyfikacji pacjenta jest zarejestrowana w PFM-Engine (celem
raportowania, patrz mierniki sukcesu procesu)

KONIEC

Alternatywny 2.1. Jeśli umówienie świadczenia = propozycja alternatywnego świadczenia to

scenariusz 1 operator podaje pacjentowi następujące informacje:
Wszystkie możliwości alternatywnych świadczeń (konsultacja on-line, telefoniczna,
APD, możliwość umówienia wizyt dodatkowych, umówienie u poddostawców
zewnętrznych)
2.2. Pacjent wybiera i akceptuje jedną z propozycji świadczenia medycznego
2.3. Informacja o akceptacji danego rozwiązania dla danego przypadku medycznego
dla konkretnej identyfikacji pacjenta jest zarejestrowana w PFM-Engine (celem
raportowania, patrz mierniki sukcesu procesu)

KONIEC

Alternatywny 3.1. Pacjent nie akceptuje propozycji świadczenia (wizyty w danym terminie,
scenariusz 2 miejscu).
3.2. Operator proponuje alternatywne świadczenia

24
 3.3. Pacjent wybiera i akceptuje daną propozycje
3.4. Informacja o akceptacji i wcześniejszym odrzuceniu dla konkretnego przypadku
medycznego dla konkretnej identyfikacji pacjenta jest zarejestrowana w PFM-
Emgine (celem raportowania, patrz mierniki sukcesu procesu)

KONIEC

Alternatywny 2.2.1. Pacjent nie akceptuje danej propozycji świadczenia

scenariusz 3
2.2.2. Informacja o odrzuceniu i braku rozwiązania dla danego przypadku
medycznego dla konkretnej identyfikacji pacjenta jest zarejestrowana w PFM-
Engine (celem raportowania, patrz mierniki sukcesu procesu)

KONIEC

MECHANIZM AUTORYZACJI
Nazwa Mechanizm autoryzacji

Krótki Opis Przypadek dotyczy czynności związanych z procesem utworzenia kodu autoryzacji
dla wizyty w przypadku gdy umówienie wizyty (świadczenia) jest w placówce
zewnętrznej

Warunki wstępne Wykonany przypadek użycia: dobór świadczenia, zgłoszenie potrzeby ręcznej
weryfikacji dostępności zasobu (zewnętrznego), akceptacja i umówienie
świadczenia

Warunek pomyślnego Wygenerowany kod autoryzacji na umówienie świadczenie w placówce

zakończenia zewnętrznej. Pacjent otrzymał kod autoryzacji

Warunek Niewygenerowany kod autoryzacji na umówienie świadczenia w placówce

niepomyślnego zewnętrznej i/lub pacjent nie otrzymał kodu autoryzacji.
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine

Aktor5 – PFM GUI nowy system, widok dla operatora

Aktor6 – pracownik Centrum Medicover

Aktor7 – pracownik CallCenter Back Office

Aktor8 – placówka zewnętrzna

Główny scenariusz 1. Operator umawia wizytę w placówce zewnętrznej (przy warunkach kwalifikacji
i doboru)
2. System PFM generuje indywidualny kod autoryzacji dla konkretnego pacjenta
na konkretne świadczenie
3. Pacjent otrzymuje kod autoryzacji sms-em
4. Placówka zewnętrzna otrzymuje kod autoryzacji celem potwierdzenia
świadczenia do realizacji.

KONIEC

Uwagi Kod autoryzacji musi mieć zaszyty zakres świadczenia, czyli:

 Na jaką usługę medyczną, specjalizacje

25
  Termin
 Dla kogo (pacjent, MRN, imie, nazwisko, pesel)

ODWOŁANIE UMÓWIONEJ WIZYTY

Nazwa Odwołanie umówionej wizyty

Krótki Opis Przypadek dotyczy czynności związanych z odwołaniem umówionej wizyty w danym
kanale umawiania świadczeń.

Warunki wstępne Pacjent ma umówioną wizytę.

Wykonany przypadek użycia: Akceptacja i umówienie świadczenia

Warunek pomyślnego Umówiona wizyta została pomyślnie odwołana przez Pacjenta.

zakończenia Wizyta trafiła jako wolny zasób dostępny dla innych Pacjentów (pod warunkiem, że
termin wizyty jest aktualny)

Warunek Umówiona wizyta nie została pomyślnie odwołana przez Pacjenta.

niepomyślnego Wizyta nie trafiła jako wolny zasób dostępny dla innych Pacjentów.
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine

Aktor5 – PFM GUI nowy system, widok dla operatora

Główny scenariusz 1. Pacjent ma potrzebę odwołania wizyty

2. Jeśli odwołanie wizyty nie dotyczy placówki zewnętrznej to Pacjent zgłasza się
do operatora z informacją o odwołaniu wizyty
3. Jeśli operator = call center to IVR przełącza do procesu odwołania wizyt w PFM
4. Jeśli operator = pracownik CM Medicover to pracownik sam wybiera opcje
odwołania wizyty w PFM
5. Jeśli operator = pacjent to aplikacja MOL lub MOB odwołuje się do procesu
odwołania wizyty w PFM
6. Pacjent podaje dane dotyczące wizyty, której dotyczy odwołanie.
7. Operator anuluje wizyte. Czas przeznaczony dla konkretna wizytę zostaje
zwolniony w grafiku w CIS.
8. PFM – engine przetrzymuje informacje jaki rodzaj wizyty na jaki przypadek
medyczny, dla jakiej identyfikacji pacjenta został odwołany (cele raportowe)

KONIEC

Alternatywny 2.1. Jeśli odwołanie wizyty dotyczy placówki zewnętrznej to Pacjent zgłasza się do
scenariusz 1 operatora = CallCenter.
2.2. IVR przełącza do procesu odwołania wizyt w PFM
2.3. Pacjent podaje dane dotycząc wizyty, której dotyczy odwołanie
2.4. Operator zgłasza potrzebę odwołania wizyty bezpośrednio do danej placówki
zewnętrznej (której dotyczy odwołanie)
2.5. PFM – engine przetrzymuje informacje jaki rodzaj wizyty na jaki przypadek
medyczny, dla jakiej identyfikacji pacjenta został odwołany (cele raportowe)

KONIEC

OFERTOWANIE SPRZEDAŻY

26
 Nazwa Ofertowanie sprzedaży

Krótki Opis Przypadek dotyczy czynności związanych z ofertowaniem produktów sprzedaży w

procesie umówienia świadczeń

Warunki wstępne Dostępny zasób z ofertą sprzedaży aktualną na dzień umawiania świadczenia
Przypadek użycia: dobór świadczenia

Warunek pomyślnego Jeśli pacjent został poinformowany przez operatora o aktualnej targetowanej
zakończenia ofercie w procesie umówienia świadczenia.
Pytanie do biznesu> czy warunkiem końcowym jest sprzedanie usługi, czy aprobata
ze strony pacjenta do kontaktu z nim celem przedstawiania oferty lub zakupu, czy
chcemy to mierzyć, czyli ile propozycji sprzedazowych zostało finalnie
zrealizowanych przez pacjenta?

Warunek Pytanie do biznesu

niepomyślnego
zakończenia

Aktor Aktor1 – pacjent

Aktor2 – operator
Aktor3 – system (CIS, MOL, MOB)
Aktor4 – PFM-Engine

Aktor5 – PFM GUI nowy system, widok dla operatora

Aktor6 – pracownik Centrum Medicover

Aktor7 – pracownik CallCenter Back Office

Aktor8 – placówka zewnętrzna
Aktor9 – dział Sprzedaży w Medicover

Główny scenariusz 1. Operator prezentuje dostępne świadczenia pacjentowi

2. Zanim pacjent dokona akceptacji i rezerwacji świadczenia, PFM pokazuje
informacje o danej ofercie sprzedażowej (danej= aktualnej na dany dzień,
targetowanej dla pacjenta)
3. Pacjent akceptuje ofertę sprzedażową
4. Informacja o akceptacji jest przekazywana (formularzem w PFM) do działu
sprzedaży oraz zachowana w PFM-Engine.
5. Dział sprzedaży otrzymuje alert z informacją o kontakt z pacjentem w zakresie
danej akcji promocyjnej
6. Dalej wg procesu Akceptacja i umówienie świadczenia

Alternatywny 3.1. Pacjent nie akceptuje oferty sprzedażowej.

scenariusz 3.2. Informacja o niezaakceptowanej ofercie jest przekazana do PFM Engine. Dział
sprzedazy nie dostaje żadnej informacji
3.3. Dalej wg procesu Akceptacji i umówienie świadczenia

MODYFIKACJA REGUŁ KWALIFIKACJI MEDYCZNEJ

Nazwa Modyfikacja reguł kwalifikacji medycznej

Krótki Opis Przypadek dotyczy czynności związanych z modyfikacją ustalonych reguł kwalifikacji
medycznej

Warunki wstępne Dostępny silnik reguł PFM

Warunek pomyślnego Dana reguła została zmieniona przez administratora

27
 zakończenia
Działanie procesów w systemie PFM wg zmienionej reguły

Warunek Administrator nie może zmienić reguły

niepomyślnego Lub
zakończenia Procesy w PFM nie działają wg zmienionej reguły

Aktor Aktor10- administrator zmian w PFM

Główny scenariusz 1. Administrator ma wgląd do reguł medycznych zaszytych w systemie PFM

2. Administrator zmienia zakres danych reguł medycznych lub tworzy nowe
3. Administrator zapisuje zmiany w systemie PFM
4. Wprowadzone i zapisane zmiany wpływają na proces działania umawiania
świadczeń

KONIEC

MODYFIKACJA REGUŁ DOBORU ŚWIADCZENIA

Nazwa Modyfikacja reguł doboru świadczenia

Krótki Opis Przypadek dotyczy czynności związanych z modyfikacją ustalonych reguł doboru
świadczenia

Warunki wstępne Dostępny silnik reguł PFM

Warunek pomyślnego Dana reguła została zmieniona przez administratora

zakończenia Działanie procesów w systemie PFM wg zmienionej reguły

Warunek Administrator nie może zmienić reguły

niepomyślnego Lub
zakończenia Procesy w PFM nie działają wg zmienionej reguły

Aktor Aktor10- administrator zmian w PFM

Główny scenariusz 1. Administrator ma wgląd do reguł biznesowych zaszytych w systemie PFM

2. Administrator zmienia zakres danych reguł biznesowych lub tworzy nowe
3. Administrator zapisuje zmiany w systemie PFM
4. Wprowadzone i zapisane zmiany wpływają na proces działania umawiania
świadczeń

KONIEC

NIEFUNKCJONALNE

LISTA UŻYTKOWNIKÓW

Do grupy użytkowników kwalifikowane są osoby (w roli Operatora) mające dostęp do procesu umówienia
świadczenia w Medicover.

Rok CM CallCenter MOL MOB

Medicover Medicover
Ilość użytkowników 2015  233 230
2016  244 260

28
(suma) 2017  257 290
2018  269 320
Ilość użytkowników 2015 85 136
(jednoczesnych) 2016 89 155
2017 94 175
2018 98 195
Ilość
transakcji/minutę
(instancje procesu)
Oczekiwana
wydajność
(oczekiwanie na
reakcje)

BEZPIECZEŃSTWO

WYDAJNOŚĆ

SKALOWALNOŚĆ

DOSTĘPNOŚĆ

RAPORTY

 Raporty dotyczące KPI nowego procesu

 Odrzucenie propozycji przez operatora (dlaczego, ile przypadków)
 Rezerwacja wizyt (w jakich przypadkach najczęściej)
 Skuteczność leczenia z konsultacji on-line (identyfikacja rozpoznania medycznego przy
konsultacji online chat, dalej informacja czy na dane rozpoznanie była kontynuacja leczenia,
pacjent zamówił inna konsultacje i ile ich było)
 Edukowanie pacjentów (na jaki temat, jak często, w jakich przypadkach medycznych)
 Ilość umówień świadczeń, które przeszły przez PFM (rozpoznanie medyczne, medical case)
 Ile wizyt, z danym rozpoznaniem nie przeszło przez PFM , a powinno
 Wykrycie zagrożenia braku dostępności świadczeń
 Informacja jak szybko (SVL) pracownik odbiera podesłany alert w PFM (formularz realizacji
danej usługi)

ALERTY I POWIADOMIENIA

 Wykryte zagrożenie braku dostępności świadczeń - Dla kierowników CM celem zwiększenia

zasobów grafikowych (np. jak jest wskazanie medyczne a brak zasobów
 Informacje do centrum Medicover o umówieniu wizyty dodatkowej
 Informacje do działu sprzedaży o oddzwonieniu do pacjenta (informacja o zainteresowaniu
pacjenta daną akcją promocyjną)
 Informacja do placówki zewnętrznej o potrzebie umówienia świadczenia na dany problem
medyczny

POWIĄZANIA Z INNYMI PROJEKTAMI

29
 Segmentacja rentowności Network (Zarządzanie ruchem pacjenta Network)
Segmentacja rentowności Poddostawców zewnętrznych (e-Provider)
Zarządzanie zasobami – podgląd grafików lekarzy z Network
Zarządzanie zasobami – podgląd grafików lekarzy od Poddostawców Zewnętrznych
Zarządzanie zasobami – podgląd grafików on-line
Zarządzanie zasobami – podgląd grafików wizyt domowych
Zarządzanie zasobami – podgląd grafików lekarzy na telefon
Zarządzanie zasobami – podgląd grafików lekarzy wyjazdowych /dostępność karetki
Nowe standardy opieki medycznej

ZAŁĄCZNIKI

KRYTERIA DOBORU DOSTAWCÓW

KRYTERIA OCENY

MAPA PROCESÓW

Proces AS IS – ogólny model (gotowy na dzień 31 styczeń 2015)

Proces AS IS – model szczegółowy (gotowy na dzień 31 styczeń 2015
Proces TO BE – ogólny model (gotowy na dzień 31 styczeń 2015)
Proces TO BE – model szczegółowy (do realizacji na etapie analizy: marzec 2015)
Proces Nowe standardy medyczne (do reguł medycznych)

HARMONOGRAM

PLAN TESTÓW (TBD)

WSKAŹNIKI

30