Вітаю усіх, хто читає мій блог!
Хочу повідомити, що в мене стартувала розробка серйозного масштабного проекту, який я збираюсь реалізувати спочатку в межах закладу, де я працюю, і в залежності від того наскільки вдало буде реалізовано ідеї, можливо, проект буде доступний як 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 амбулаторій, розміщених на території району. Також для оргметодкабінету було розроблено та впроваджено в роботу модуль для квартального звіту на область по щепленню проти кору (інформація вноситься в розрізі лікарів та формується зведений звіт по закладу). Майже готовий оновлювач модулів, в стані розробки реєстр пацієнтів та запис на прийом до лікаря через реєстратуру.
В планах реалізувати також наступні модулі:
На рівні бази даних планую реалізувати наступні особливості.
- розподілена база даних: при неможливості синхронізувати дані з сервером (за відсутності підключення до мережі або інтернету) необхідні дані зберігаються на стороні клієнта з приблизними ознаками які дані міняються або додаються, ким і коли, а за наявності відновлення підключення програма пропонує синхронізувати дані. Схожий підхід реалізовано у системах оффлайн клієнт-банкінгу, коли синхронізація даних відбувається за запитом.
- система логування основних подій з базою даних, при цьому для запису логів повинна використовуватись окрема база даних з метою зменшення об'єму основної бази. Відповідно періодично записи логів будуть підчищатись за терміном давності відповідно до налаштувань системи або за запитом.
На рахунок оновлень системи в мене є декілька варіантів як реалізувати краще. Один з них - оновлення модулів тримати в спеціальній базі даних, де буде зберігатись версія файлу модуля для оновлення, та або сам модуль в стиснутому форматі для певної операційної системи, або посилання на завантаження його з сервера. При запуску будь-якого модуля спочатку запускається оновлювач, який перевіряє чи є доступною нова версія, і відповідно якщо є, попередній модуль видаляється і на його місце записується новий.
- по структурі таблиць в базі даних хочу зробити певні правила: кожна таблиця буде мати префікс, який визначає використання цієї таблиці. Наприклад, префікс SYS_ будуть мати усі таблиці зі службовою або системною інформацією, префікс DIC_ в таблицях зі словниками та довідниками, які дуже рідко змінюються, REG_ для довідників, які досить часто змінюються та реєстрів, DOC_ для збереження документів та журналів документів, MISC_ для решти таблиць.
- Інколи при оновленні модуля буде необхідність також оновити структуру певних таблиць, тому одна зі службових таблиць повинна відповідати за збереження інформації про назву таблиці та номер версії її структури. Таким чином при оновленні модуля буде перевірятись версія структури потрібних таблиць, і у випадку коли версія нижче потрібної буде проводитись оновлення структури БД.
Ще одне важливе питання, яке потребує уваги при розробці системи такого масштабу - це права користувачів. В загальному, потрібно визначити які користувачі мають право отримувати дані та вносити зміни до яких таблиць. Найоптимальніший варіант реалізації - визначення ролей користувача, оскільки один користувач може мати декілька ролей (наприклад, оператор та реєстратор тощо). Все це реалізовується можливостями сервера БД.
Оскільки ідею я виношував вже не один рік, відповідно дещо пробував реалізувати. В якості сервера БД використовую Firebird 3 як на мою думку найоптимальніший варіант - проект Open Source, оснований на вихідному коді Interbase (ця БД свого часу використовувалась у МВС США, що вже говорить про її надійність та захищеність), не потребує багато ресурсів, майже необмежений об'єм БД (фактично обмежується лише вільним місцем на сервері), можливість шифрувати дані та розширити або обмежити способи авторизації користувачів. Працює в різних ОС, є багато хороших інструментів для адміністрування, при цьому до сервера БД під однією ОС можна підключатись з клієнтських програм в інших ОС незалежно від архітектури та розрядності. У випадку технічних неполадок сервера файли БД досить швидко можна перенести на іншу машину та переналаштувати сервер для швидкого відновлення роботи.
Для розробки модулів системи використовую Typhon IDE з комплекту CodeTyphon Studio (це такий дистрибутив Lazarus, який "з коробки" містить величезну кількість додаткових компонентів та інструменти для крос-платформової розробки). Порівняння цих інструментів можна подивитись на відео.
В планах реалізувати також наступні модулі:
- Робоче місце лікаря - робота з реєстром пацієнтів, ведення прийому по запису, ведення електронної медичної карти пацієнта (далі - ЕМК) з використанням кодування ICPC-2 та МКХ-10, направлення на обстеження та щеплення
- Електронна черга - друк талонів лише по направленню лікаря, талони містять дані пацієнта та лікаря який направив
- “Лабораторія” - прийом по електронній черзі, внесення результатів в ЕМК
- “Пункт щеплень” - прийом по електронній черзі, внесення результатів в ЕМК
- “Кабінет долікарського огляду” - прийом по електронній черзі, внесення результатів в ЕМК
- “Функціональна діагностика” - прийом по електронній черзі, внесення результатів в ЕМК
- “Звіти” - формування різних типових звітів та можливість універсальних виборок з БД
- З часом додати можливість для пацієнтів записуватись самим на прийом до лікаря через наш сайт та можливість перегляду ЕМК в особовому кабінеті.
Немає коментарів:
Дописати коментар