# Baltique OS Core 2.2.0
## Clinical Experience, Identity, Smart Intake & Governed AI Release

Wydanie 2.2.0 jest skumulowanym releasem dla instalacji Baltique OS 2.1.0.1. Łączy oficjalne motywy, rzeczywisty kontekst lokalizacji, bezpieczną tożsamość i adres pacjenta, Smart Intake z dokumentu/zdjęcia/kamery, nadzorowaną analizę badań przedoperacyjnych, język pacjenta PL/EN, governance dokumentów oraz Premium Patient Care Guide z syntetyczną przewodniczką Magdaleną.

## Najważniejsze elementy

### Oficjalne motywy całego systemu

- `Ciemny`
- `Jasny`
- `Systemowy`

Preferencja jest zapisywana dla zalogowanego użytkownika i stosowana w Enterprise Shell, panelach, formularzach, tabelach oraz PWA.

### Rzeczywisty kontekst lokalizacji

- Gdańsk, Sopot, Online i kolejne lokalizacje;
- widok `Wszystkie lokalizacje` dla uprawnionych osób;
- ukrywanie lokalizacji planowanych lub nieaktywnych przed personelem;
- reguły widoczności według roli i użytkownika;
- kontekst lokalizacji przekazywany do obsługiwanych zapytań pacjentów, Case Spine, Work Queue i wyszukiwania;
- zmiana kontekstu nie przenosi pacjenta między placówkami.

### Jednoznaczna tożsamość pacjenta

- PESEL z walidacją sumy kontrolnej i daty urodzenia;
- paszport, zagraniczny dokument krajowy lub inny zatwierdzony dokument;
- data urodzenia i kraj wydania;
- zaszyfrowany numer dokumentu;
- ślepy indeks HMAC do kontroli duplikatów;
- jawne ostatnie cztery znaki wyłącznie do bezpiecznego podglądu;
- status weryfikacji oraz audit trail.

### Adres pacjenta

Adres zamieszkania jest obowiązkowym elementem nowego Smart Intake i zawiera:

- kraj;
- kod pocztowy;
- miejscowość;
- województwo/region;
- ulicę;
- numer budynku;
- numer lokalu;
- dodatkową linię adresu.

Pełny adres jest szyfrowany w bazie. Strukturalnie przechowywane są wyłącznie pola wymagane do routingu operacyjnego: kraj, kod pocztowy, miasto i region. Adres może być używany w zatwierdzonych dokumentach i zgodach jako `{{patient.address_formatted}}`.

### Profile społecznościowe

System może zapisać identyfikatory Facebook i Instagram, ale:

- profil nie oznacza zgody na kontakt;
- kontakt organizacyjny wymaga dowodu zgody;
- marketing wymaga osobnego dowodu zgody;
- domyślnie kontakt i marketing są wyłączone.

### Smart Patient Intake

Dostępne są trzy tryby:

1. ręczne dodanie pacjenta;
2. dokument elektroniczny lub zdjęcie dokumentu;
3. Live Camera Intake z komputera, telefonu lub tabletu.

OCR i kamera jedynie proponują dane. Pacjent powstaje dopiero po ręcznej weryfikacji przez personel. Obraz z kamery jest analizowany lokalnie pod kątem ostrości, jasności i stabilności; do serwera trafia zaakceptowany kadr, nie ciągły strumień.

### Język pacjenta

Każdy pacjent ma niezależną preferencję:

- `Polski`;
- `English`.

Preferencja steruje portalem, przewodnikiem, komunikacją, dokumentami i zgodami. Angielskie dokumenty prawno-kliniczne wymagają osobnych zatwierdzonych Content Blocks. Automatyczne tłumaczenie maszynowe nie jest źródłem prawdy.

### Governed Pre-op Lab Intelligence

System może:

- wykorzystać wyniki OCR;
- wskazać odchylenia i braki;
- skierować review do chirurga lub anestezjologa;
- utworzyć zadanie Work Queue;
- przygotować draft odpowiedzi PL/EN;
- materializować zatwierdzony draft do Communication Hub jako `draft`.

System nie może automatycznie:

- postawić diagnozy;
- wydać clearance anestezjologicznego;
- zmienić GO/HOLD/NO-GO;
- wysłać zaleceń medycznych pacjentowi.

### Premium Patient Care Guide

Syntetyczna przewodniczka Magdalena działa w dwóch kluczowych momentach:

- pierwsze logowanie przed konsultacją;
- po kwalifikacji do operacji.

Dostępne są zatwierdzane scenariusze PL/EN, postęp kroków i odsłuch systemowym głosem urządzenia. Interfejs jawnie informuje, że przewodniczka jest syntetyczna, nie jest lekarzem i nie zastępuje pilnego kontaktu medycznego. Klon głosu jest wyłączony.

### Role, PWA i push

Wydanie integruje:

- dedykowane pulpity i menu ról;
- ochronę tras technicznych dla admin/superadmin;
- PWA dla Android/iOS;
- rejestr urządzeń i Web Push;
- wyłączony automatyczny push do czasu zatwierdzenia governance i konfiguracji VAPID/APNs/FCM.

## Instalacja

Patrz: `README_UPGRADE_2_2_0.md`.

## Kontrole po wdrożeniu

1. `/system_clinical_experience_220.php`
2. `/system_runtime_preflight.php`
3. `/system_appearance.php`
4. `/system_site_context_governance.php`
5. `/patient_identity_intake.php`
6. `/system_preop_lab_intelligence.php`
7. `/system_patient_care_guide.php`
8. `/system_document_language_governance.php`
9. `/workspace.php`
10. `/mobile/index.php`

## Bezpieczeństwo

Paczka nie zawiera:

- `app/config.php`;
- `.env`;
- dumpu bazy;
- prywatnego klucza szyfrowania;
- VAPID private key, APNs, Firebase ani innych sekretów;
- oryginalnych zdjęć przekazanych do przygotowania postaci.

Prywatny klucz danych tożsamości i adresu jest tworzony na serwerze podczas kontrolowanego upgrade’u w `storage/keys/patient_identity.key` i musi być objęty backupem chronionym poza publicznym katalogiem WWW.

## Ograniczenia formalnej walidacji

Wydanie zostało zamknięte i zwalidowane statycznie, ale nie było uruchamiane na żywej bazie OVH. Przed produkcją wymagane są:

- backup i test restore;
- upgrade na środowisku staging;
- testy UAT wszystkich ról;
- test MySQL/migracji na kopii bazy;
- test obciążeniowy;
- formalna akceptacja reguł laboratoryjnych;
- formalna akceptacja dokumentów i zgód EN;
- browser/device matrix;
- ocena bezpieczeństwa i prywatności.
