{"id":19303067,"url":"https://github.com/asc-lab/medical-claims-ddd-example","last_synced_at":"2025-04-22T11:32:00.240Z","repository":{"id":113372125,"uuid":"158186883","full_name":"asc-lab/medical-claims-ddd-example","owner":"asc-lab","description":null,"archived":false,"fork":false,"pushed_at":"2018-11-19T09:38:20.000Z","size":244,"stargazers_count":5,"open_issues_count":14,"forks_count":1,"subscribers_count":8,"default_branch":"master","last_synced_at":"2025-04-01T22:46:50.988Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/asc-lab.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-11-19T08:28:14.000Z","updated_at":"2023-11-23T16:18:54.000Z","dependencies_parsed_at":"2023-06-15T11:30:35.241Z","dependency_job_id":null,"html_url":"https://github.com/asc-lab/medical-claims-ddd-example","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asc-lab%2Fmedical-claims-ddd-example","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asc-lab%2Fmedical-claims-ddd-example/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asc-lab%2Fmedical-claims-ddd-example/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/asc-lab%2Fmedical-claims-ddd-example/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/asc-lab","download_url":"https://codeload.github.com/asc-lab/medical-claims-ddd-example/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250232155,"owners_count":21396581,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T23:24:54.558Z","updated_at":"2025-04-22T11:32:00.165Z","avatar_url":"https://github.com/asc-lab.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Medical claims DDD example\n\nW ramach ćwiczenia budujemy komponent będący częścią systemu obsługi ubezpieczeń medycznych. \n\nIstnieje już komponent odpowiedzialny za zarządzanie polisami. Komponent ten, za każdym razem, gdy maja miejsce zmiany danych polisy publikuje zdarzenia ```PolicyVersionCreated```.\n\nZdarzenie to zawiera następujące dane polisy:\n\n```json\n{\n\"policyNumber\": \"P1212121\",\n\"productCode\": \"Pakiet Gold\",\n  \"policyHolder\": {\n    \"firstName\": \"Jan\",\n    \"lastName\": \"Nowak\",\n    \"pesel\": \"1111111116\",\n    \"accountNumber\": \"2738123834783247723\",\n    \"address\": {\n      \"country\": \"PL\",\n      \"city\": \"Warszawa\",\n      \"zipCode\": \"01-001\",\n      \"street\": \"JaksTam 123 m 2\"\n    }\n},\n\"policyValidFrom\": \"2018-01-01\",\n\"policyValidTo\": \"2018-12-31\",\n\"versionNumber\": 1,\n\"versionValidFrom\": \"2018-01-01\",\n\"versionValidTo\": null,\n\"covers\": [\n  {\n    \"coverCode\": \"KONS\",\n    \"services\": [\n      {\n        \"code\": \"KONS_INTERNISTA\",\n        \"coPayment\": {\n          \"percent\": 0.25\n        },\n        \"limit\": {\n          \"maxQuantity\": null,\n          \"maxAmount\": 100,\n          \"limitPeriod\": \"POLICY_YEAR\"\n        }\n      },\n      {\n        \"code\": \"KONS_PEDIATRA\",\n        \"coPayment\": {\n          \"amount\": 10\n        },\n        \"limit\": {\n          \"maxQuantity\": 20,\n          \"maxAmount\": 100,\n          \"limitPeriod\": \"POLICY_YEAR\"\n        }\n      }\n    ]\n  },\n  {\n    \"coverCode\": \"LAB\",\n    \"services\": [\n      {\n        \"code\": \"LAB_KREW_OB\",\n        \"coPayment\": {\n          \"percent\": 0.10\n        },\n        \"limit\": {\n          \"maxQuantity\": 5,\n          \"maxAmount\": 50,\n          \"limitPeriod\": \"POLICY_YEAR\"\n        }\n      },\n      {\n        \"code\": \"LAB_HDL\",\n        \"coPayment\": {\n          \"amount\": 2\n        },\n        \"limit\": {\n          \"maxQuantity\": 2,\n          \"maxAmount\": 28,\n          \"limitPeriod\": \"POLICY_YEAR\"\n        }\n      }\n    ]\n  }\n]}\n```\n\nKomponent polisowy posiada też API pozwalające na pobranie danych polisy po podaniu jej numeru i daty, na którą mają być zwrócone aktualne dane.\n\nNaszym zadaniem jest zbudowanie komponentu do obsługi szkód.\nObsługa szkód składa się z:\n\n1. **Rejestracja szkody (eng. submit claim)** \\\nW ramach rejestracji szkody system musi otrzymać następujące dane: numer polisy, datę zdarzenia, kod placówki medycznej (ze słownika) oraz listę pozycji na szkodzie. Każda pozycja zawiera kod usługi (ze słownika), ilość usług, cenę. System sprawdza, czy istnieje polisa o padnym numerze, jeśli nie to zgłasza błąd i proces się kończy.\nJeśli polisa istnieje to system zapisuje dane szkody a następnie sprawdza pokrycie ubezpieczeniem: jeśli data zdarzenie nie jest objęta okresem obowiązywania polisy, to szkoda zostaje automatycznie odrzucona z powodem: Zdarzenie nastąpiło poza okresem ochrony. Pełen koszt każdej usługi ponosi ubezpieczony. W przeciwnym przypadku system wylicza dla każdej pozycji kwotę do wypłaty przez ubezpieczyciela. System robi to w następujący sposób dla każdej pozycji:\n\n    - sprawdzenie, czy na polisie w ochronach jest usługa o kodzie z pozycji, jeśli nie ma to cały koszt ponosi ubezpieczony,\n    - system wylicza udział własny na podstawie definicji co-payment z polisy (procentowy, lub kwotowy)\n    - następnie pozostała kwota porównywana jest z limitem na daną usługę i dotychczasowym zużyciem tego limitu np. ```\"limit\" : { \"maxQuantity\" : null, \"maxAmount\" : 100, \"limitPeriod\" : \"POLICY_YEAR\" }``` oznacza, że w ciągu roku polisowego ubezpieczonemu przysługuje zwrot maksymalnie 100PLN ale ma nieograniczoną liczbę wystąpienia usługi. W ten sposób powstaje kwota do zapłaty przez ubezpieczyciela. System rezerwuje sobie kwoty konsumpcji limitu wynikające z danej linii.\n    - na końcu system zapisuje kwotę do zapłaty przez ubezpieczyciela i przez ubezpieczonego, generuje unikalny numer szkody i zapisuje dane. Na tym kończy się proces rejestracji.\n\n2. **Akceptacja, odrzucenia lub korekta zarejstrowanej szkody** \\\nZarejestrowana szkoda może zostać odrzucona, zaakceptowana lub poddane korekcie (funkcji korekty możemy nie implementować w pierwszej fazie).\n\n    - **Akceptacja** - użytkownik z odpowiednim uprawnieniem może zaakceptować szkodę. Akcje to powoduje trwałą konsumpcje limitów.\n    - **Odrzucenia** -akcja to zwalnia konsumpcje limitów i powoduje, że cały koszt szkody ponosi ubezpieczony.\n\n3. **Wyszukanie szkody** \\\nSystem pozwala na wyszukanie szkody po: numerze, statusie, zakresie dat zdarzenia, zakresie kwot roszczenia, numerze polisy, kodzie usługi, kodzie placówki medycznej.\n\n4. **Tworzenie poleceń zapłaty** \\\nDla zaakceptowanych szkód uruchamiany jest proces tworzenia poleceń wypłaty. Dla każdej zaakceptowanej szkody tworzone jest polecenie wypłaty. Polecenie wypłaty ma wskazanie na osobę, której wypłacamy odszkodowanie – zawsze jest to policy holder, datę utworzenia, kwotę – wyliczoną na szkodze, numer konta – konto policy holdera.\n\nCelem zadania jest zbudowanie komponentu, który zaprezentuje wzorcowe podejście do tworzenia komponentów  i nasze coding guidelines / best practices.\n\nW szczególności ważne jest zaprezentowanie zasad:\n1) podziału kodu na pakiety\n2) widoczności klas w pakietach\n3) odpowiedniego nazewnictwa klas\n4) właściwego użycia Springa (co wrzucamy do kontenera, a co nie)\n5) zasad używanie Optional (null handling)\n6) obsługa błędów, tworzenie i rzucanie wyjątków\n7) tworzenie złożonych encji\n8) enkapsulacja\n9) first class collections\n10) użycie specyfikacji\n11) Logowanie\n12) tworzenie czytelnego i testowalnego kodu\n13) zaprezentowanie implementacji typowych elementów:\n\n    - obsługa zdarzeń przychodzących\n    - implementacja logiki biznesowej\n    - implementacja zapisu / odczytu z bazy danych\n    - publikowanie zdarzeń\n    - komunikacja z innymi modułami\n    - implementacja wyszukiwanie\n    - API REST\n    - procesy batchowe\n    - konfiguracja\n    - testy jednostkowe\n    - testy integracyjne","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fasc-lab%2Fmedical-claims-ddd-example","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fasc-lab%2Fmedical-claims-ddd-example","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fasc-lab%2Fmedical-claims-ddd-example/lists"}