Реставрація ну ду-у-уже староко комп'ютера. Чи можливе нове життя?

 

Минулого року мені дістався дуже старий комп'ютер, якому понад 20 років. На відео я зробив перше включення і огляд нутрощів цього "динозавра".

XORcerer: шифруємо й розшифровуємо інформацію

Недавно я опублікував статтю про свій алгоритм шифрування - я назвав його XORcerer. Тоді я лише обдумав концепцію шифрування і розшифровування, основану на базовому алгоритмі шифрування XOR.
Коротко нагадаю, як це працює. Є пароль, яким шифрується потрібна інформація, і сама інформація, яку потрібно зашифрувати. Пароль повторюється стільки разів, скільки потрібн для розміру інформації, і відповідні байти накладаються один на одного за допомогою оператора XOR. Ця операція оборотня, тобто, маючи пароль і застосувавши його таким самим методом до зашифрованої інформації, ми в результаті отримаємо розшифровані дані.
Цей алгоритм досить стійкий для взлому, але тривалим перебором можна підібрати пароль для розшифрування.
Моя ідея заключалась в наступному: після шифрування дані переводяться в текстовий шістнадцятеричний вигляд, тому результат можна передавати як звичайний текст наприклад, по електронній пошті. При цьому розшифрування стає на порядок складніше, але все ще можливе, тому що достатньо кожну пару символів перевести в двійковий вигляд і потім примінити метод перебору. Проте, якщо до зашиврованого тексту застосувати ще один прохід для кодування, підібрати пароль стане дуже важко.
До попередньої статті я додав відео, на якому показав як застосувати мій алгоритм до текстового файлу. Там же я обіцяв вдосконалити алгоритм і написати клас-обгортку для можливості шифрувати дані в будь-яких файлах, а також в потоці. Клас поки ще знаходиться в стані доопрацювання, але окремо виділені функції шифрування і розшифрування. В параметрах цих функцій вказується джерело для шифрування (поки що лише текст), пароль та кількість проходів шифрування. Також я допрацював тестову програму, додавши можливість вказати кількість проходів шифрування.
Якщо зловмиснику не буде відомо точної кількості проходів, підібрати пароль для розшифрування буде АБСОЛЮТНО НЕМОЖЛИВО! Таким чином, цей алгоритм можна застосовувати в системах, де необхідне шифрування даних з високим ступенем захисту і високою швидкістю шифрування.
Звісно, немає абсолютного захисту за допомогою шифрування, але при умові, що алгоритм маловідомий, зловмиснику буде потрібно як мінімум спочатку дизасемблювати програму щоб виділити яким алгоритмом інформація зашифрована, і лише тоді можна пробувати підбирати пароль для розшифрування. А не знаючи кількості проходів, підібрати його буде дуже складно і затратно по часу.
Є ще ряд ідей по вдосконаленню шифрування, але я про них розповідати наразі не буду, оскільки хочу реалізувати їх в одному зі своїх комерційних проектів, де важливо якісно захистити інформацію.

МІС "Гіппократ" - бути!

Привіт усім читачам мого програмістського блоґу!

Вже понад місяць часу не доходили в мене руки до нових дописів, але змін за цей час відбулось чимало.

Сама головна подія - я подав заявку на розробку в Електронну систему охорони здоров'я (ЕСОЗ) і отимав доступ до тестової бази даних Міністерства охорони здоров'я! А це означає лише одне - проект "Гіппократ" починає втілюватись в життя, і це не може не радувати! Звісно, є дуже багато технічних моментів, над якими потрібно буде задуматись в процесі реалізації, але сам факт доступу до додаткових ресурсів при розробці такого об'ємного проекту вже додає оптимізму.

Оскільки я був досить сильно завантажений іншою роботою, пов'язаною зі своїми посадовими обов'язками, часу на розробку в мене майже не було. Проте, використовуючи отримані ідентифікатори доступу, я зміг отримати з тестової бази довідники в форматі JSON, які тепер можна імпортувати у власну БД, оскільки я не вважаю за потрібне щоразу завантажувати їх з Центральної БД, створюючи цим додаткове навантаження на сервери ЕСОЗ. Ці довідники змінюються досить рідко, а тому варто оновлювати їх у власній БД лише при внесенні змін в ЦБД.

Заодно було трохи переосмислено зі структурою БД "Гіппократа" на власному сервері. Зваживши усі "за" і "проти", було прийнято рішення скоротити систему логування, оскільки для більшості таблиць просто немає сенсу вести логи. Логуватись будуть лише важливі зміни даних, які будуть записуватись безпосередньо в саму БД в спеціальну таблицю. Відповдні зміни будуть зроблені в адмінці.

Також я обдумав, як мені реалізувати інтерфейс користувача та авторизацію - для цього буде використовуватись власний локальний веб-сервер. Основна ідея полягає в тому, що при запуску інтерфейсу користувача запускається локальний веб-сервер, який при зверненні до нього через браузер буде генерувати сторінку входу користувача, де потрібно ввести адресу електронної пошти і натиснути кнопку "Авторизуватись". Після цього веб-сервер перевіряє, чи така пошта є зареєстрована в БД "Гіппократа" і визначає, чи потрібно авторизувати користувача через систему eHealth (для лікарів), чи просто запитує пароль користувача і перевіряє хеш пароля в БД. Авторизувати через eHealth є смисл лише тих користувачів, які мають право вносити інформацію в ЦБД (заключати декларації, виписувати рецепти та направлення тощо). Відповідно, реєстрація користувачів в програмі теж відбувається в залежності від того, чи потрібно користувача реєструвати в ЕСОЗ. Наприклад, запис на прийом відбувається лише в БД "Гіппократа" і реєстратура  не вносить ніяких змін в ЦБД, тому їх реєструвати в ЕСОЗ немає необхідності.

Ще одна, на мій розсуд, непогана думка - реалізувати чат-боти для мессенджерів Telegram та Discord, які дозволять пацієнтам самим записуватись на прийом до обраного лікаря на потрібну дату та час. Яка ваша думка на цей рахунок, чи потрібно такий функціонал?

До речі, вже закінчую модуль "Реєстратура", який дозволяє вносити інформацію про графіки прийому лікарів, вихідні дні та записувати пацієнтів на прийом. Лишилось дописати коректне відображення запису на екрані та організувати правильні запити до БД на виборку даних.

Так що продовжую і далі розробляти функціонал, поступово втілюючи проект "Гіппократ" до життя!

Шифрування інформації

Вітаю усіх читачів мого блогу зі свтлим святом Воскресіння Христового! Христос воскрес!
За день до Великодня прийшла мені в голову ідея як можна шифрувати інформацію в БД для захисту персональних даних та іншої інформації, яка мала б лишатись конфіденційною і доступною лише для осіб, які мають право доступу до неї. Другими словами, навіть якщо зловмисник за допомогою будь-якого методу зможе отримати копію файла БД, це йому мало чим допоможе, оскільки вся потрібна інформація буде зашифрованою.
Ще під час проектування структури своєї БД я цікавився як засобами сервера БД можна забезпечити шифрування інформації. В принципі, Firebird підтримує шифрування БД за потреби, але реалізовується воно за допомогою сторонніх засобів за допомого написання спеціального плагіна, який прописується на сервері. Не буду вдаватись в технічні подробиці і переказувати документацію як такий плагін можна написати, оскільки кого цікавить зможе без проблем це нагуглити, зазначу лише, що в офіційній документації є приклад такого плагіна з використанням простого алгоритма шифрування XOR.
Спробую пояснити, що з себе представляє цей метод і наскільки він стійкий до підбору пароля або взлому. Спочатку розглянемо принцип XOR-шифрування  - як це працює. Взагалі, досить детально це описано в Вікіпедії, тому я лише зазначу, що ця операція є оборотною, тобто її можна застосовувати як для шифрування, так і для розшифрування інформації. На практиці, якщо:

 a XOR b = c, то:
 c XOR b = a
 c XOR a = b

По-простому, знаючи будь-які два значення з трьох, можна отримати третє.
Добре, зашифрувати і розшифрувати просто, якщо використовується один символ для всього блоку інформації. Стійкість до взлому майже ніяка, тому що зловмиснику достатньо методом перебору варіантів одного символу нескладно буде підібрати потрібний і розшифрувати інформацію.
Коли інформація шифрується за допомогою пароля довільної довжини, ситуація складніша -  кожен симфол інформації шифрується за допомогою відповідного йому символа з пароля, при цьому пароль повторяється стільки раз, скільки потрібно для досягнення довжини блоку інформації. В цьому випадку зловмиснику підібрати пароль для розшифровки буде набагато важче, але все ще можливо - на основі частотного аналізу входження символів в шифрований текст за наявності великого фрагменту шифрованого тексту можна пвдвбрати пароль і розшифрувати текст, хоча ця операція відносно тривала по часу. Такий алгоритм шифрування відносно стійкий, взламати пароль можливо лише для зашифрованого тексту.
Цей алгоритм застосовується в прикладі написання плагіна для шифрування наступним кодом:

  Move(src^, dst^, length);
  pxor(length, dst);

Для використання в реальних проектах такий метод шифрування не підходить, оскільки складність його все-таки дозволяє підібрати пароль і розшифрувати дані. Але за основу його взяти все-таки можна. Тому на основі цього алгоритму я вирішив розробити власний алгоритм, і мені це таки вдалося! Для цього алгоритму я придумав назву XORcerer (від англ. Sorcerer - чарівник).
Мій алгоритм використовує двопроходне XOR-шифрування на основі пароля довільної довжини з перетворенням байтів в їх шістнядцяткове текстове представлення. Кінцевий зашифрований файл буде представляти собою текстовий файл, в якому використані лише наступні символи: 0-9 та A-F. Ось так виглядає фрагмент зашифрованого файла:

160C07173F081D495A7803041F1835154953664B0256463733192A352D3F331740136330291

Після першого проходу ми отримуємо текстовий файл аналогічного виду, до яког приміняємо другий прохід і отримуємо повторно закодований файл в аналогічному представленні! Як до цього можна підібрати пароль для розшифровки - я просто не уявляю!
Для розшифровки використовується обернений метод - по 2 байти тексту перетворюється з текту в шістнадцятковий код символа, до якого і приміняється операція XOR, після цього те ж саме повторюється в другий прохід і в результаті ми отимуємо повністю розшифрований файл, який був спочатку! При цьому, якщо ввести хоч один символ пароля невірно, розшифрування відбудеться некоректно і навіть частини початкової інформації не вдасться відновити.
Для перевірки стійкості алгоритмуXORcerer до підбору пароля для розшифровки я спробував використати наступний підхід. Оскільки використовуються однобайтні коди символів, їх є всього 256 - від 0 до 255. Подвійним вкладеним циклом перебираються значення кодів символа, відбувається шифрування за допомогою мого алгоритма і перевіряється на відповідність результуючого символа. Якщо символи однакові, ймовірно, або перший, або другий з них входить у відповідно позицію в паролі. Проте підібрати правильний пароль для розшифровки в мене так і не вийшло, що свідчить про досить високу стійкість алгоритму до взлому. Єдиний недолік такого методу - збільшення в об'ємі інформації, оскільки для кожного байта вихідної інформації використовується два байта після кодування в представленні текстовим виглядом.
На даному етапі я реалізував роботу для шифрування лише текстових даних, надалі планую розвинути реалізацію алгоритму XORcerer у вигляді окремого класу з підтримкою потокового шифрування/розшифрування будь-яких даних з і стисненням шифрованих даних та розмістити сирці у вільному доступі.
Переглянути демонстрацію роботи алгоритму можна на цьому відео:

Розробка адмінки для системи. Інтерфейс користувача

Всім привіт, продовжую обдумувати та розробляти універсальну систему, і сьогодні хочу поділитись деякими думками на рахунок створення адмінки.

Отже, саме перше: за що повинна відповідати адмінка? Визначу по пунктах:

• робота з БД (настройки підключення, резервне копіювання, відновлення з резервної копії та інші функції адміністрування)
• робота з користувачами (призначення прав, ролей, груп)
• робота з модулями системи (призначення прав, створення потрібних таблиць, прописування залежностей, керування оновленнями)

Це будуть основні задачі, розбиті на розділи. Враховуючи специфіку цих задач (кожну з них детально я буду розглядати в процесі реалізації необхідного функціоналу), звичайному користувачу доступ не бажаний - можна натворити багато чого не лише небезпечного, а й пошкодити саму БД. На стороні звичайного користувача достатньо буде лише роботу в автоматичному режимі з локальним фрагментом БД, яка буде синхронізувати дані з сервером (і задавати налаштування підключення до центральної БД, з якою буде відбуватись синхронізація). До речі, щоб на клієнтських машинах не встановлювати повністю сервер Firebird (або використовувати його Embedded версію) я вирішив використовувати БД SQLite3 - легку однокористувацьку БД, для роботи з якою достатньо лише одного файлу на відміну від Firebird. Звісно, є певні відмінності при роботі з цими БД, але я маю досвід використання їх обох (на SQLite3 працює моя програма тарифікації для медичних закладів, яка використовувалась понад десятком закладів по всій Україні).

Рис. 1.1. Інтерфейс адмінки після запуску

Рис. 1.2. Інтерфейс адмінки після підключення БД

Інтерфейс адмінки буде досить простий. Фактично, це вікно без заголовку, в якому розміщено декілька  кнопок з іконками, по натисненю на які й будуть викликатись потрібні діалоги налаштувань. Доки не активувати підключення до БД, кнопки керування користувачами та модулями системи будуть неактивні (Рис. 1.1.)!
Тепер розгляну кожен розділ більш детально. Самим першим пунктом йде робота з базою даних. Саме тут можна буде підключатись до БД на сервері, включати або відключати можливість ведення логів при роботі з БД, виконувати архівне копіювання та відновлення БД та виконувати усі необхідні операції адміністрування, включаючи виконання SQL-запитів як з файлів, так і введених вручну. Спробую спроектувати інтерфейс такого діалогу.

Мій варіант реалізації буде за допомогою вікна з кількома вкладками, на кожній з яких згруповані відповідні підзадачі. На першій вкладці будуть налаштування підключення до головної БД та БД логування (Рис. 2.1.).

Рис.2.1. Налаштування підключення до БД та логування

Після успішного підключення до головної БД розблоковуються кнопки головного вікна для режимів керування користувачами і модулями (Рис. 1.2.). При активації форми настройки завантажуються з файла, а при натисненні кнопки "ОК" - записуються в файл налаштувань. По кнопці "БД Інфо" буде виводитись вікно зі службовою інформацією про сервер БД та саму БД. В тому випадку, якщо в підключеній БД відсутні службові таблиці для роботи системи, буде виводитись відповідне повідомлення та стане доступною кнопка "Ініціалізація БД", по натисненні на яку такі таблиці будуть створюватись.

Код, який відповідає за все вище описане, досить рутинний, тому не буду детально на ньому зупинятись. Кому цікаво подивитись сирці, після завершення роботи над адмінкою викладу все на Гітхаб, про що повідомлю додатково.
На сьогодні буде все, а наступного разу спробую доробити виведення інформації про сервер та БД, а також початкову ініціалізацію БД.

P.S. Не маючи ніякої кращої ідеї, поки що система називається "OpenIS" (можливо, все-таки не система, а платформа?), а функціонал для медичних закладів, який ще в процесі проектування, має кодову назву "Гіппократ". Можливо, хтось запропонує кращі назви? Пишіть в коментарях!

Перші кроки розробки

Усім привіт.

В попередній публікації я описав концепцію універсальної системи збору та аналізу інформації, а сьогодні хочу почати поетапний опис конкретних модулів та особливості їх розробки.

Отже, самий перший і основний модуль - це адмінка, за допомогою якої можна налаштовувати підключення до БД, адмініструвати користувачів та керувати встановленням інших модулів системи. Як я вже згадував, в якості сервера БД планую використання Firebird 3, а середовище розробки - CodeTyphon Studio.

Оскільки система планується модульною, кожен модуль буде представлений окремим проектом в середовищі розробки. Також Typhon IDE має дуже зручну функцію - мультипроект, який дозволяє одночасно працювати з групою проектів. Це дозволяє вести розробку кожного проекту як окремо, так і збирати одночасно усі проекти групи не відкриваючи кожен з них окремо.

З допоміжних інструментів я використовую FlameRobin - програма, яка призначена для адміністрування БД Firebird, доступна в різних дистрибутивах Linux, а також є версії і для Windows та MacOS X. Інший корисний інструмент - універсальна адмінка різних БД DBeaver, яка також доступна для різних ОС та розповсюджується у двох редакціях - безкоштовна Community та комерційна Enterprise. Я використовую DBeaver Community. Також безумовно найкращою адмінкою БД Firebird для Windows вважається IBexpert - комерційний продукт, але також існує безкоштовна версія для персонального використання,потрібно лише зареєструватись на офіційному сайті та отримати код активації на електронну пошту.

Щодо компонентів, які будуть використовуватись в середовищі розробки для доступу та роботи з БД, в більшості випадків мене влаштовують стандартні компоненти на вкладках "Data Access", "Data Controls", "SQL DB". Проте для адміністрування БД, керування користувачами та інших специфічних для Firebird функцій я встановив додаткові компоненти IBX for Lazarus, які спочатку конвертував для сумісності з CodeTyphon IDE спеціальною утилітою.

Оскільки переважну частину процесу розробки я проводжу в ОС Linux (відповідно сервер БД в мене теж розгорнуто та налаштовано на спеціально виділеному комп'ютері під керуванням ОС Ubuntu Server). Для організації зовнішнього доступу до БД в мене виділена постійна IP-адреса та прокинуто потрібні порти в роутері. Розробку я веду на ноутбуці Lenovo Ideapad 330 (Intel(R) Pentium(R) Silver N5000 CPU @ 1600MHz, 8 Гб ОЗУ DDR4, SSD 128Gb+HDD 500Gb) під ОС Linux Mint 19.3 з додатковим монітором, на який розширено робочий стіл.

Для того, щоб можна було працювати з БД, необхідно встановити бібліотеки для розробки. Це робиться командою

sudo apt-get install firebird-dev

Після цього можна запускати середовище розробки та приступати безпосередньо до програмування.

Ще один момент, як у мене реалізовано структуру проекту в файловій системі:

Папка проекту
-bin
--i386-win32
--i386-linux
--x86_64-win64
--x86_64-linux
-lib
--i386-win32
--i386-linux
--x86_64-win64
--x86_64-linux
-src
--admin
--updater
--sheduler
...папки з сирцями інших модулів
--forall
-res
-doc

Спробую трошки пояснити що і для чого використовується.

• тека bin - містить вкладені підтеки для запису готових виконуваних файлів під відповідну платформу;
•  тека lib аналогічно містить вкладені підтеки для проміжних файлів компіляції під відповідні платформи;
• тека src містить підтеки з сирцями окремих модулів системи, а у вкладеній теці forall я виніс сніпети коду та бібліотеки, які використовуються в різних модулях системи;
• тека res містить файли ресурсів, які використовуються в різних модулях проекту;
• тека doc містить документацію по розробці та опис системи, а також що потрібно зробити та логи розробки.

Також в теці src зберігається файл мультипроекту для автоматизації збирання усіх модулів системи та налаштування середовища розробки при роботі з двома моніторами.
Сирці системи та скрипти структури БД буду викладати на Github по мірі розробки, також буду використовувати вже готові напрацювання, пристосовуючи їх до цього проекту.
Залишилось придумати назву такої системи, може, є якість пропозиції? Пишіть в коментарях, буду вдячний!

Старт серйозного проекту

Вітаю усіх, хто читає мій блог!

Хочу повідомити, що в мене стартувала розробка серйозного масштабного проекту, який я збираюсь реалізувати спочатку в межах закладу, де я працюю, і в залежності від того наскільки вдало буде реалізовано ідеї, можливо, проект буде доступний як Open Source для всіх охочих з можливістю зібрати та запустити під наступними операційними системами: Windows x32 та x64, Linux x32 та x64, робота через Web-інтерфейс в браузері. Коли з'явиться така можливість, також перевірю чи буде працювати в MacOS X.

Коротко опишу що саме я збираюсь зробити.

Завдання і мета проекту

Вже декілька років я виношував ідею  створення універсальної системи для збору та аналізу інформації, а також автоматизації певних процесів роботи будь-якого закладу чи організації.

Оскільки передбачити усі можливі аспекти роботи неможливо, система повинна складатись з окремих модулів, кожен з яких відповідав би за конкретні можливості роботи (внесення інформації, формування звітів, аналіз даних тощо). Фактично, можливості системи залежать лише від набору модулів, які використовуються системою, і за потреби ці можливості можна збільшувати доробляючи нові модулі. Ідея не нова, аналогічним методом організовано можливості ОС Linux - в залежності від набору встановлених пакунків можна отримати як сервер, так і декстоп або мультимедійну робочу станцію чи "тонкий клієнт", в залежності від потреб користувача.

Аналогічно, моя система теж повинна складатись з ядра, яке відповідає за роботу з базою даних, адміністрування користувачів та модулів системи, надавати можливість оновлення модулів та конфігурацію на робочі місця користувачів.
На рівні бази даних планую реалізувати наступні особливості.
- розподілена база даних: при неможливості синхронізувати дані з сервером (за відсутності підключення до мережі або інтернету) необхідні дані зберігаються на стороні клієнта з приблизними ознаками які дані міняються або додаються, ким і коли, а за наявності відновлення підключення програма пропонує синхронізувати дані. Схожий підхід реалізовано у системах оффлайн клієнт-банкінгу, коли синхронізація даних відбувається за запитом.
- система логування основних подій з базою даних, при цьому для запису логів повинна використовуватись окрема база даних з метою зменшення об'єму основної бази. Відповідно періодично записи логів будуть підчищатись за терміном давності відповідно до налаштувань системи або за запитом.
На рахунок оновлень системи в мене є декілька варіантів як реалізувати краще. Один з них - оновлення модулів тримати в спеціальній базі даних, де буде зберігатись версія файлу модуля для оновлення, та або сам модуль в стиснутому форматі для певної операційної системи, або посилання на завантаження його з сервера. При запуску будь-якого модуля спочатку запускається оновлювач, який перевіряє чи є доступною нова версія, і відповідно якщо є, попередній модуль видаляється і на його місце записується новий.
- по структурі таблиць в базі даних хочу зробити певні правила: кожна таблиця буде мати префікс, який визначає використання цієї таблиці. Наприклад, префікс SYS_ будуть мати усі таблиці зі службовою або системною інформацією, префікс DIC_ в таблицях зі словниками та довідниками, які дуже рідко змінюються, REG_  для довідників, які досить часто змінюються та реєстрів, DOC_ для збереження документів та журналів документів, MISC_ для решти таблиць.
- Інколи при оновленні модуля буде необхідність також оновити структуру певних таблиць, тому одна зі службових таблиць повинна відповідати за збереження інформації про назву таблиці та номер версії її структури. Таким чином при оновленні модуля буде перевірятись версія структури потрібних таблиць, і у випадку коли версія нижче потрібної буде проводитись оновлення структури БД.
Ще одне важливе питання, яке потребує уваги при розробці системи такого масштабу - це права користувачів. В загальному, потрібно визначити які користувачі мають право отримувати  дані та вносити зміни до яких таблиць. Найоптимальніший варіант реалізації - визначення ролей користувача, оскільки один користувач може мати декілька ролей (наприклад, оператор та реєстратор тощо). Все це реалізовується можливостями сервера БД.
Оскільки ідею я виношував вже не один рік, відповідно дещо пробував реалізувати. В якості сервера БД використовую Firebird 3 як на мою думку найоптимальніший варіант - проект Open Source, оснований на вихідному коді Interbase (ця БД свого часу використовувалась у МВС США, що вже говорить про її надійність та захищеність), не потребує багато ресурсів, майже необмежений об'єм БД (фактично обмежується лише вільним місцем на сервері), можливість шифрувати дані та розширити або обмежити способи авторизації користувачів. Працює в різних ОС, є багато хороших інструментів для адміністрування, при цьому до сервера БД під однією ОС можна підключатись з клієнтських програм в інших ОС незалежно від архітектури та розрядності. У випадку технічних неполадок сервера файли БД досить швидко можна перенести на іншу машину та переналаштувати сервер для швидкого відновлення роботи.
Для розробки модулів системи використовую Typhon IDE з комплекту CodeTyphon Studio (це такий дистрибутив Lazarus, який "з коробки" містить величезну кількість додаткових компонентів та інструменти для крос-платформової розробки). Порівняння цих інструментів можна подивитись на відео.

На даний час частково працює адміністративний модуль, в якому реалізовано налаштування підключення до бази даних та робота з користувачами, а також декілька тимчасових модулів для подання лікарями щомісячних звітів в оргметодкабінет, та отримання зведених даних для подальшого аналізу якості роботи лікарів на рівні керівництва. Потрібно зазначити, що лікарі подають звіт з 15 амбулаторій, розміщених на території району. Також для оргметодкабінету було розроблено та впроваджено в роботу модуль для квартального звіту на область по щепленню проти кору (інформація вноситься в розрізі лікарів та формується зведений звіт по закладу). Майже готовий оновлювач модулів, в стані розробки реєстр пацієнтів та запис на прийом до лікаря через реєстратуру.
В планах реалізувати також наступні модулі:

• Робоче місце лікаря - робота з реєстром пацієнтів, ведення прийому по запису, ведення електронної медичної карти пацієнта (далі - ЕМК) з використанням кодування ICPC-2 та МКХ-10, направлення на обстеження та щеплення
• Електронна черга - друк талонів лише по направленню лікаря, талони містять дані пацієнта та лікаря який направив
• “Лабораторія” - прийом по електронній черзі, внесення результатів в ЕМК
• “Пункт щеплень” - прийом по електронній черзі, внесення результатів в ЕМК
• “Кабінет долікарського огляду” - прийом по електронній черзі, внесення результатів в ЕМК
• “Функціональна діагностика” - прийом по електронній черзі, внесення результатів в ЕМК
• “Звіти” - формування різних типових звітів та можливість універсальних виборок з БД
• З часом додати можливість для пацієнтів записуватись самим на прийом до лікаря через наш сайт та можливість перегляду ЕМК в особовому кабінеті.

Ось такий проект в мене планується реалізувати, а якщо все піде досить вдало, можна буде спробувати підключитись і до Центральної БД Електронної системи охорони здоров'я.