Názor ke článku SÚKL zprovoznil nový systém pro elektronické recepty od xbenakk - Pane doktore, jak to říct slušně ... Řešil...

Pane doktore, jak to říct slušně ... Řešil jste někdy něco s kontaktním centrem eReceptu? Byly chvíle, kdy se o mě pokoušel infarkt, kdy jsem nevěřícně civěl na text jejich vyjádření s koutkem svěšeným a slinou dlouhou až pod stůl, prostě jasný případ čtyřnásobné těžké mrtvice. Byly chvíle, kdy jsem zlostí málem obyčejnou pěstí rozpůlil stůl ve dví a to vše letos. Dokonce jsem jim jednou natočil video, aby nakonec uznali, že mají sakra problém. A teď najednou div ne oslavný článek na téma eRecept! Tohle mi nedělejte!

Pokud dobře počítám, pak se v současné chvíli jedná o čtvrtou implementaci eReceptu. První verze, ještě za PharmDr. Beneše coby ředitele SÚKLu, byla hrozná. Hnusná, odporná. Technologicky byla shodná s druhou, ale byla nejvíc fuj, jak si dovedete představit. Zprávy byly nelogicky pojmenované, datové typy v XSD se asi učili za pochodu, člověk občas musel hodně přemýšlet, co tím chtěl autor říct. Přišlo mi to, jako kdyby napřed programovali a pak teprve udělali definice pro ostatní programátory, vlastně jen vysypali JavaDoc.
Technologicky tam byly pro lékárny VPN routery a SonicESB sběrnice + nějaký JavaAppServer. Komunikovat se mohlo buď pomocí JMS protokolu, nebo pomocí WSDL. JMS nepoužil snad žádný z tvůrců lékárenských a lékařských SW, protože autentizace byla ... no třeba ve vývojovém prostředí téže firmy jako je SonicESB nebyla podpora veškerá žádná. Lékaři mohli přistupovat přes SSL autentizaci.
Druhá verze byla z pohledu schemat podle mě celkem povedená. Bylo na ní vidět, že jí vymýšlel někdo, kdo rozumí lékárně. Navíc byla poměrně elegantně "svázaná" s LEK13 a když se vydal eRecept, nemusel se již hlásit přes LEK13. Co si budeme nalhávat, eRecept by měl být z větší části o výdeji, protože to je to, co pacient sezobe a z čeho pak dostane díky interakcím např. osypky. Mimochodem, když jsem zmínil interakce, jejich hlášení žádná z verzí eReceptu nikdy neřešila. Pak se ale Dr. Beneš rozešel ve zlém s ministrem Hegerem (který se pro změnu postaral o totální zabití předepisování a výdeje léčivého konopí, z té legislativy je to jasné jako facka - úkol zněl jasně, konopí musí být na oko legalizováno, ale legislativně tak svázáno, že je jeho oficiální prodej takřka nerealizovatelný - poděkujte TOP09 a SÚKLu) a byl ze SÚKLu odejit. Dodavatelé technologií a tvůrci se s novým vedením začali dohadovat a dohadovat a dohadovat ... a pak přišla slavná kauza soudních příkazů. Argumentovalo se tím, kolik bylo receptů předepsáno a kolik vydáno a jak to bylo finančně neefektivní ... Nojo, jenže pokud to chápu dobře, byly to náklady fixní. Něco tvořila implementace, něco licence a pak fixní náklady na provoz, které budou nejspíš ve zhruba stejné výši i u implementace poslední.
Takže se SÚKL s dodavateli rozkmotřil, bude to mít jistě soudní dohru a celé je to podle mě "politicky" motivované až hanba (nečekaně). API služeb mu zůstalo a přešlo se k náhradnímu řešení. Stále jsme u SSL routerů, ale už je možné používat i https, naopak JMS je KO. Tvůrce lékařských a lékárenských SW se to zase tolik nedotklo, jen pár nepříjemností stran odlišného hlášení problémů s přihlašováním, přečíslování některých chyb, ale jinak vše při starém. Stále nedostatečně dořešené konopí ...
No a letos přišla bomba, implementace nového rozhraní, relativně podobnému tomu starému, ale bez routerů, vše přes https na jeden certifikát pro celé zařízení, stále MembraneProxy. A zavedení kontaktního centra, které se někdy svou rychlostí vyřizování dotazů a hlášení chyb podobá warpovému motoru. Vypnutému. Nové řešení mi přijde, jako kdyby si s ním vyhrál doktor medicíny, tímto zdravím MUDr. Hřiba za Piráty, ale lékárenská část mi přijde ... trošku nedořešená. Jako kdyby byl stěžejním předpis a ne výdej ... prostě to tak instinktivně cítím, že něco není úplně košér jak by mělo být, ale neumím to popsat.
Aby bylo z technického hlediska jasno. Pro komunikaci mezi lékařem a CÚ (centrální úložiště) a mezi CÚ a lékárnou bude podporováno jen TLS 1.3, alespoň to bylo zmíněno na semináři, když jsem se na to ptal. Autentizace pomocí certifikátu vydaného na zařízení, součástí SOAP zprávy odchází "autorizační řetězec", kterým se uživatel identifikuje vůči nějaké databázi nebo LDAPu (čert ví jak to teď mají). Bez tohoto řetězce ... pešek, Membrána vás nepustí. Kvalifikovaný certifikát je použit pro digitální podpis vybraných zpráv které nějakým způsobem vytvářejí, modifikují nebo mažou ať již lékařské, nebo lékárnické záznamy. Proto budou potřebovat doktoři i lékárníci tokeny nebo čipovky, protože eIDAS. Škoda, že tam není provázání s LEK13 a co hůř, pro pomocné číselníkové záznamy se v obou rozhraních budou používat jiné hodnoty. Bordel jak na SÚKLu jak říká kolegyně.
IPLP přípravky samozřejmě předepisovat a vydávat půjdou, podle mě ale měli dámy a pánové na SÚKLu začít jako první věcí distribucí číselníků v nějaké formě REST. Původní koncept nejspíš počítal s messagingem, tedy že by SÚKL poslal zprávu všem odběratelům "mám pro vás nové číselníky". Takhle si budeme muset udělat sérii naplánovaných úloh a jak trubky se ptát, zda se něco nezměnilo. Každopádně online distribucí číselníků ve strojově načitatelném formátu měli podle mě začít.
Sakra, to jsem se rozepsal, takže jen na závěr. Naštěstí jsem se nemusel potýkat s problémy uživatelské registrace, této kratochvíle jsem byl uchráněn. Jak to tak čtu, registrace musí být skutečný opruz :-) Ale to mě nepřekvapuje. Ovšem skutečný opruz to je programovat to v ABL. Aspoň že se Progressové už naučili komunikovat s .NETem, jinak by mi snad nepomohli ani všichni svatí.