Wdrożenie w CRIK

Przykładem realizacji systemu automatycznej kompozycji może być system tworzony w celu planowania zadań (zabiegów rehabilitacyjnych, wizyt lekarskich, praktyk studenckich, etc.) dla Centrum Rehabilitacji i Kosmetologii (CRiK) przy Wyższej Szkole Informatyki i Umiejętności w Łodzi (http://crik.pl)

CRiK oferuje różnego rodzaju usługi medyczne, zarówno bezpośrednio dla pacjentów, jak i innych jednostek medycznych. Centrum jest również jednostką dydaktyczną, wspomagającą kształcenie studentów, oferującą system praktyk i ćwiczeń z zakresu rehabilitacji i innych usług medycznych. Projektowany system harmonogramowania będzie wspomagał pracę Centrum poprzez planowanie złożonych sekwencji wizyt i zabiegów dla pacjentów.

Centrum oferuje usługi dla wielu niezależnych klientów, korzystających z wizyt lekarskich oraz oferowanych zabiegów. Wszystkie te usługi muszą być odpowiednio zaplanowane, uwzględniając posiadane przez Centrum zasoby, zależności wynikające ze specyfiki stosowanej procedury leczniczej oraz wymagań pacjentów. Planowanie to polega na alokacji zasobów spełniających wymagane potrzeby. Definicje potrzeb i sposoby ich realizacji są często trudne do opisania w sposób formalny. Dodatkowo dostępność pewnych zasobów w wielu przypadkach może być ustalona jedynie dynamicznie, poprzez zapytanie niezależnych, zewnętrznych źródeł danych. Obecnie, przed wdrożeniem systemu, ze względu na brak odpowiedniego oprogramowania zapytania takie są realizowane w sposób nieformalny (telefonicznie, pocztą elektroniczną). Otrzymana w ten sposób wiedza nie może być opracowana automatycznie.

Założenia 

Przy projektowaniu systemu dla CRiK przyjęto następujące założenia:

  • zasady alokacji zasobów powinny być łatwo modyfikowane przez pracowników bez kwalifikacji w zakresie informatyki. Język wyrażania tych zasad powinien być możliwie bliski językowi naturalnemu lub ich tworzenie powinno być wspomagane przez odpowiednie kreatory;
  • system powinien mieć możliwość kontaktu (wymiany informacji) z systemami informatycznymi we współpracujących jednostkach (Szpital w Głownie, który jest jednostką macierzystą Centrum, Wyższa Szkoła Informatyki i Umiejętności w Łodzi, której studenci korzystają z zasobów Centrum, inne jednostki medyczne współpracujące z Centrum) poprzez zdefiniowane interfejsy;
  • system powinien potrafić realizować wskazania lekarza podane w postaci celu, który ma być osiągnięty (np. określonej liczby zabiegów rehabilitacji i następującej po nich wizyty lekarskiej), a nie w postaci precyzyjnego planu jak, gdzie i przez kogo ten cel ma realizowany. Określenie czynności pozwalających na osiągnięcie celu (wybór osoby nadzorującej rehabilitację, dostępność zasobów, wymagania pacjenta) powinno być wykonywane automatycznie przez system;
  • jednostkowe czynności tworzące plan mogą być realizowane przez różnych dostawców usług (tj. określonych lekarzy, współpracujące jednostki, szpital w Głownie itp.). Dostarczane usługi mogą mieć tę samą funkcjonalność (dają takie same rezultaty po ich zastosowaniu), ale mogą różnić się wskaźnikami jakościowymi (jak np. czas, koszt). System  powinien pozwolić ocenić otrzymany plan oraz dokonać korekt przez operatora (otrzymany plan może być traktowany jako punkt startowy dla dalszych, ręcznych korekt, które mogą być konieczne podczas jego realizacji, na podstawie trudno formalizowanych przesłanek).

 Komponenty

Tworzony system składa się z trzech podstawowych komponentów: ontologii, rejestru usług oraz modułu planującego (planera).

Ontologia dostarcza definicji usług, zawiera klasy i metausługi (typy usług), jest ona zbiorem zasad dla planera.

Rejestr jest miejscem składowania usług konkretnych, zawiera informacje o dostępnych usługach wraz z ich powiązaniami do typów w ontologii. Rejestr jest wyposażony w odpowiedni interfejs dla administratora i integratora usług.

Trzeci komponent systemu – planer, jest narzędziem generowania planów wynikających z wprowadzonych przez użytkownika zapytań, przy użyciu ontologii, rejestru usług konkretnych oraz poprzez kontakt z dostawcami usług.

Konstrukcję ontologii oparto na koncepcji hierarchicznej struktury klas wywodzących się ze wspólnego korzenia Resource z atrybutem quantity. Usługi wykorzystują zasoby, zmniejszając lub zwiększając ich quantity a ich realizacje są osadzone w skwantowanym czasie rzeczywistym. Następstwa między usługami są albo dane implicite (np. jedna usługa tworzy zasób, zmieniając jego quantity z zera na wartość dodatnią, druga go konsumuje) albo explicite: na wyjściu zapytania użytkownik wymienia interesujące go ślady wywołań. Następstwa zasobów są podawane przez położenie w sekwencji lub związki nierównościowe. Zapytanie możemy rozszerzać (te rozszerzenia nie są możliwe na ten moment w Planicsie i zostały wprowadzone we wdrożeniu ad hoc) o reguły kwantyfikowane.

Przygotowane narzędzia

1. Konstruktor zapytania:

Przeglądarka drzewa usług, pozwalająca na wybór usługi i umieszczenie jej w „potrzebach”. Usługę tę można sparametryzować przez określenie wymagań co do potrzebnych do jej pracy zasobów oraz narzucenia dodatkowych warunków czasowych na jej ślady.

2. Przeglądarka harmonogramów zasobów:

Przeglądarka drzewa o korzeniu w Resource. Po wybraniu typu pojawia się diagram Gantta z zaznaczonymi wszystkimi instancjami danego zasobu (i jego podtypów). Dane do zbudowania diagramu pochodzą z lokalnej bazy danych.

3. Domyślne wejście do zapytania (edytor):

Pozwala na określenie zasobów CRIK. Jest to przeglądarka poddrzewa Resource, pozwalająca na określenie “stanu posiadania” (maksymalnie, bez uwzględnienia zajętości w czasie). Rezultat jest zapisywany w bazie danych i trafia domyślnie do każdego zapytania.

4. Planer:

Usługi są osadzane w czasie, z możliwością przejrzenia wyników i wprowadzenia na tej podstawie wtórnych korekt. Plan zapisuje się w bazie danych.

Historia wdrożeń

2012 – prototypowy system Harmonics, bazujący na pracach zrealizowanych w ramach grantu 2011/01/B/ST6/01477 i sieci badawczej POIG.01.03.01-00-008/08

2014 – rewizja systemu w oparciu o system Planics 2, bazujący na pracach w ramach grantu 2011/01/B/ST6/01477

Prototyp systemu został przekazany pracownikom Wyższej Szkoły Informatyki i Umiejętności do pierwszej fazy wdrażania.