Наказ НСЗУ від 30.09.2019 р. № 385

НАЦІОНАЛЬНА СЛУЖБА ЗДОРОВ’Я УКРАЇНИ
НАКАЗ
від 30.09.2019 р. № 385
«Про внесення змін до наказу Національної служби здоров’я України від 06.02.2019 р. № 28»

На виконання пунктів 52 та 54 Порядку функціонування електронної системи охорони здоров’я, затвердженого постановою Кабінету Міністрів України від 25.04.2018 №411,

НАКАЗУЮ:

1. Внести зміни до Технічних вимог до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я, затверджених наказом Національної служби здоров’я України від 06.02.2019 № 28 «Про затвердження технічних вимог до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я та тестової програми для встановлення відповідності до таких вимог», виклавши їх в новій редакції, що додається.

2. Внести зміни до Тестової програми для встановлення відповідності електронної медичної інформаційної системи технічним вимогам, затвердженої наказом Національної служби здоров’я України від 06.02.2019 № 28 «Про затвердження технічних вимог до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я та тестової програми для встановлення відповідності до таких вимог», виклавши її в новій редакції, що додається.

3. Департаменту розвитку електронної системи охорони здоров’я забезпечити виконання цього наказу Адміністратором електронної системи охорони здоров’я.

4. Контроль за виконанням цього наказу покласти на заступника Голови Національної служби здоров’я України — Рябцеву Наталію Сергіївну.

ГоловаО. Петренко

Затверджено

наказом Національної служби здоров’я України

від 30.09.2019 р. №385

ТЕХНІЧНІ ВИМОГИ
до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я

1. Загальні вимоги до електронної медичної інформаційної системи (далі — МІС)

1.1. МІС забезпечує можливість обміну даними з центральною базою даних (далі — ЦБД) електронної системи охорони здоров’я (далі — система) через відкритий прикладний програмний інтерфейс (далі — АРІ).

1.2. МІС забезпечує можливість внесення інформації до ЦБД системи через свій інтерфейс українською мовою. У випадках, коли використання літер українського алфавіту призводить до спотворення інформації, можуть використовуватися латинські літери та спеціальні символи, зокрема для запису адрес в інтернеті та адрес електронної пошти.

1.3. МІС забезпечує внесення до ЦБД системи даних, зокрема у вигляді електронних, в тому числі оцифрованих, документів (файлів), та доступ до них через свій інтерфейс із застосуванням засобів електронної ідентифікації (кваліфікованого електронного підпису, далі — КЕП).

1.4. МІС надає доступ до системи через свій інтерфейс після введення логіну та паролю користувача.

1.5. На стороні МІС заборонено використовувати проміжні інтерфейси авторизації користувачів, крім веб-сторінки авторизації, яка надходить з https://auth.ehealth-ukraine.org.

1.6. Параметр МІС redirect_uri має містити відповідний URL з чинним сертифікатом TLS, де доменом буде тільки такий домен, де МІС здатен опрацювати запити та відповіді від ЦБД.

1.7. МІС правильно працює з refresh і access token користувачів згідно специфікації АРІ, контролює дані про дату валідності токена (expiry date).

1.8. У запитах на гарантування обсягу аутентифікації (scopes) користувачів МІС передає правильний список прав у відповідності до специфікації АРІ, які необхідні користувачу для подальшої роботи із ЦБД системи.

1.9. При роботі з системою для користувача повинна бути забезпечена можливість отримати доступ до словників та класифікаторів, отриманих від ЦБД відповідним запитом МІС. Дані щодо будь-яких адрес в системі вводяться у відповідності з наданими словниками пошуку адрес і міст (сервіс Uadresses).

1.10. МІС повинна надавати функціональну можливість підпису даних, що вносяться до ЦБД користувачами, якщо це передбачено специфікацією АРІ системи, за допомогою КЕП користувача. КЕП повинен бути успішно перевірений системою автоматично. Успішною перевіркою вважається повна відповідність даних підписанта, що містяться в КЕП, даним, що містяться в ЦБД.

1.11. У випадку, якщо процес накладення КЕП здійснюється за межами МІС, остання має контролювати, що дані в підписаному об’єкті відповідають даним, введеним користувачем МІС.

1.12. МІС повинна правильно відобразити текст і прапорець (checkbox) для елементу Consent (погодження з правилами), а також повинна продемонструвати, або надати можливість перевірки, що елемент погодження з правилами відображається вірно, і що користувач може надати згоду з відповідними правилами після ознайомлення з ними.

1.13. У разі виникнення помилок у системі (неправильність введення даних користувачами, авторизація тощо), МІС відображає кінцевим користувачам МІС такі помилки у текстовому вигляді, що затверджується Адміністратором.

1.14. МІС відображає користувачу назви полів та параметрів системи у інтерфейсах згідно вимог, що розробляються та затверджуються Адміністратором.

1.15. На підставі виконання користувачем визначених дій та/або значень параметрів системи, МІС забезпечує інформування користувача через повідомлення в інтерфейсі. Підстава інформування та текст повідомлення розробляються та затверджуються Адміністратором.

2. Загальні вимоги до безпеки

2.1. МІС має забезпечувати розмежування доступу до даних, внесених до ЦБД системи.

2.2. МІС має використовувати тільки безпечні протоколи передачі даних,

а саме:

2.2.1. Між МІС та ЦБД — протокол Transport Layer Security (TLS) версії не нижче 1.2, що відповідає вимогам чинного законодавства;

2.2.2. Між МІС та користувачем МІС — саме протокол TLS версії не нижче 1.2 або інший спосіб, що відповідає вимогам чинного законодавства.

2.3. МІС заборонено зберігати паролі КЕП та файли приватних ключів.

3. Функціональні вимоги до модулів МІС

3.1. Модуль «Робоче міце лікаря первинної медичної допомоги»

Передумова відповідності функціональним вимогам: в системі успішно зареєстровані надавач медичних послуг первинної медичної допомоги (далі — НМП ПМД), користувач системи з відповідними правами.

3.1.1. Вимоги до укладання декларації:

3.1.1.1. успішний пошук пацієнта у реєстрі пацієнтів;

3.1.1.2. успішно створена декларація про вибір лікаря, що надає ПМД, з використанням методу онлайн-верифікації. Всі поля про пацієнта заповнені у відповідності зі специфікацією АРІ системи;

3.1.1.3. успішно створена декларація про вибір лікаря, що надає ПМД, з використанням методу офлайн-верифікації. Оцифровані документи у форматі JPEG, які вимагаються системою, успішно завантажені. Всі поля про пацієнта заповнені у відповідності зі специфікацією АРІ системи;

3.1.1.4. успішно створена декларація про вибір лікаря, що надає ПМД, для пацієнта, від імені якого діє законний представник;

3.1.1.5. успішно створена декларація про вибір лікаря, що надає ПМД, для пацієнта віком менше 14 років, у якого є уповноважений представник;

3.1.1.6. успішно укладена декларація для пацієнта, який вже має активну декларацію, що має наслідком припинення попередньої декларації;

3.1.1.8. всі згоди, які надає пацієнт, та всі прапорці (checkbox), які користувач встановлює на етапі створення декларації, коректно відображаються в інтерфейсі МІС. Користувач може отримувати всю інформацію про такі згоди та прапорці, включаючи згоду на обробку персональних даних.

3.1.2. Вимоги до електронних медичних записів:

3.1.2.1. Нефункціональні вимоги до електронних медичних записів:

3.1.2.1.1. Перед відправкою даних до ЦБД системи МІС має валідувати інформацію, введену користувачем, у відповідності до АРІ та не дозволяти відправку даних, якщо валідація не пройшла успішно. Користувач МІС має бути повідомлений про помилки як на стороні МІС, так і про помилки зі сторони ЦБД.

3.1.2.1.2. Режим роботи з ЦБД в контексті електронних медичних записів (ЕМЗ) передбачає роботу з даними пацієнта в рамках «сесії» — безпосереднього контакту лікаря з пацієнтом. Поза рамками цієї «сесії» заборонено виконувати автоматизовані запити щодо ЕМЗ пацієнта зі сторони МІС.

3.1.2.2. Функціональні вимоги до електронних медичних записів:

3.1.2.2.1. Успішно отримані і відображені ЕМЗ пацієнта користувачу з типом «лікар».

3.1.2.2.2. Успішно створений ЕМЗ (у пакеті взаємодії) у відповідності до специфікації АРІ системи, а саме:

3.1.2.2.2.1. з даними візиту, взаємодій, діагнозів — обов’язково;

3.1.2.2.2.2. спостережень, алергій, імунізацій — необов’язково.

3.1.2.2.3. МІС повинна надавати користувачу функціональну можливість позначення пакету взаємодії ЕМЗ як введеного помилково.

3.1.2.2.4. Успішно створений епізод медичної допомоги (далі — МД).

3.1.2.2.5. МІС повинна надавати користувачу функціональну можливість пошуку епізодів МД, закриття та зміни епізодів МД, позначення епізоду МД як введеного помилково у відповідності до специфікації АРІ.

3.1.2.2.6. МІС повинна надавати користувачу функціональну можливість пошуку ЕМЗ пацієнта у відповідності до пошукових параметрів, передбачених специфікацією АРІ. А саме:

3.1.2.2.6.1. взаємодій, діагнозів — обов’язково;

3.1.2.2.6.2. спостережень, алергій, імунізацій — необов’язково.

3.1.2.2.7. МІС повинна надавати користувачу функціональну можливість отримання зведеної інформації про пацієнта у відповідності до пошукових параметрів, передбачених специфікацією АРІ, а саме щодо:

3.1.2.2.7.1. діагнозів та діагнозів за відкритими епізодами МД — обов’язково;

3.1.2.2.7.2. спостережень, алергій, імунізацій — необов’язково.

3.1.3. Вимоги до виписування електронного рецепту за програмою реімбурсації «Доступні ліки»:

3.1.3.1. успішне створення заявки (драфту) на електронний рецепт (далі за текстом — заявка на ЕР) згідно АРІ системи на лікарський засіб (далі за текстом — ЛЗ), а саме на міжнародну непатентовану назву (далі за текстом — МНН) із зазначенням форми випуску, сили дії, кількості доз ЛЗ, тривалості лікування в днях та способу застосування (сигнатури) ЛЗ;

3.1.З.2 успішне підписання заявки на ЕР кваліфікованим електронним підписом (далі — КЕП), який отримано в будь-якому акредитованому центрі сертифікації ключів (АЦСК) користувача згідно АРІ системи та, як наслідок, успішне створення ЕР в системі;

3.1.3.3. всі записи в системі щодо ЕР мають відповідати даним, які надає користувач;

3.1.3.4. до початку надання користувачу можливості створити заявку на ЕР МІС має перевірити наступні умови:

3.1.3.4.1. надавач ПМД та структурний підрозділ надавача ПМД, в якому працює користувач, зареєстровані в системі;

3.1.3.4.2. надавач ПМД, в якому працює користувач, має чинний договір про медичне обслуговування населення за програмою медичних гарантій, укладений з НСЗУ в системі;

3.1.3.4.3. надавач ПМД, в якому працює користувач, має чинну ліцензію на провадження господарської діяльності з медичної практики;

3.1.3.4.4. користувач зареєстрований в системі як employee з типом doctor;

3.1.3.4.5. користувач зареєстрований в системі як лікар зі спеціальністю терапевт, сімейний лікар, педіатр, або будь-яка комбінація цих спеціальностей;

3.1.3.4.6. пацієнт, якому буде виписано ЕР, обрав користувача своїм лікарем з надання ПМД, про що свідчить чинна декларація про вибір лікаря ПМД, подана таким пацієнтом надавачу ПМД, в якому працює користувач;

3.1.3.5. у випадку наявності протестованого Адміністратором функціоналу ЕМЗ з позитивним висновком необхідно забезпечити запис щодо епізоду МД в рамках якого виписується ЕР;

3.1.3.6. при формуванні заявки на ЕР запит до системи має містити:

3.1.3.6.1. актуальний ідентифікаційний номер програми «Доступні ліки» у параметрі «medical_program_id»;

3.1.3.6.2. значення «order» в параметрі «intent» (позначає, що ЕР призначений для погашення в аптеці);

3.1.3.6.3. значення «community» в параметрі «category» (позначає, що створюваний ЕР належить до категорії рецептів загального призначення);

3.1.3.6.4. значення «1» в параметрі «dosage_instruction.sequence» (позначає, що існує один спосіб застосування (сигнатура) ЛЗ);

3.1.3.7. сценарій наповнення заявки на ЕР інформацією від користувача має містити такі обов’язково етапи:

3.1.3.7.1. обрання користувачем МНН з наявних позицій у актуальному довіднику системи «Get Drugs»;

3.1.3.7.2. обрання користувачем програми реімбурсації «Доступні ліки»;

3.1.3.7.3. обрання користувачем форми випуску та сили дії ЛЗ з наявних для обраної МНН позицій у актуальному довіднику системи «Get Drugs»;

3.1.3.7.4. визначення користувачем тривалості курсу лікування цим ЛЗ, причому в МІС має оути обмеження на максимальну тривалість курсу лікування — 90 днів;

3.1.3.7.5. визначення кількості ЛЗ;

3.1.3.7.6. зазначення користувачем способу застосування ліків (сигнатури);

3.1.3.8. МІС може додатково організувати для користувача пошук ЛЗ за кодом анатоміко-терапевтично-хімічної класифікації (АТХ код);

3.1.3.9. строк початку дії ЕР «created_at» має виставлятися МІС як поточна дата автоматично і не може змінюватись користувачем;

3.1.3.10. дата початку лікування ЛЗ (МНН) «started_at»,

3.1.3.10.1. має дорівнювати даті «created_at» якщо в пацієнта немає на момент виписування ЕР іншого терміну лікування тим самим ЛЗ (МНН);

3.1.3.10.2. для пацієнта в якого ще не закінчився термін лікування за попереднім ЕР повинна визначатись як «ended_at» попереднього терміну лікування + 1 день.

3.1.3.11. дата закінчення лікування ЛЗ (МНН) «ended_at» має розрахуватись автоматично виходячи з визначеної тривалості курсу лікування цим ЛЗ;

3.1.3.12. При повторному виписуванні ЕР і якщо у пацієнта є активний або погашений рецепт на той же МНН, то МІС має попереджати користувача, що повторний ЕР на той же МНН можна виписати за таку кількість днів до закінчення терміну лікування попереднього ЕР:

3.1.3.12.1. 7 днів, якщо тривалість лікування > 21 день;

3.1.3.12.2. 3 дні, якщо тривалість лікування < 21 день.

3.1.3.13. ЕР може бути виписаний тільки на кількість ЛЗ, що кратна кількості ЛЗ в упаковці, тому для формування заявки на ЕР слід забезпечити наступні умови:

3.1.3.13.1. кількість ЛЗ для виписування має зазначатися користувачем тільки шляхом вибору одного значення з виключного переліку;

3.1.3.13.2. цей перелік має формуватися з урахуванням запропонованих у актуальному довіднику системи «Get Drugs» варіантів кількості ЛЗ в упаковці «package_qty» для обраного МНН так, щоби кожна позиція сформованого переліку була кратна принаймні одному з варіантів кількості ЛЗ в упаковці;

3.1.3.13.3. значення в переліку мають враховувати загальну кількість ЛЗ необхідну для всього курсу лікування цим ЛЗ, та бути наближеними (рівними або більшими, але не меншими) до неї;

3.1.3.14. При формуванні способу застосування ліків «dosage_instructiom» (сигнатури) незалежно від опційності параметрів в ЦБД забезпечити користувачу обов’язкове вказання та валідацію заповнення параметрів:

3.1.3.14.1. добову дозу ЛЗ «max_dose_per_period»;

3.1.3.14.2. разову дозу ЛЗ (на один прийом) «max_dose_per_administration»;

3.1.3.14.3. текст сигнатури рецепту «text», в якій користувач повинен вказати спосіб застосування ліків для пацієнта;

3.1.3.15. після формування заявки на ЕР користувачу має бути надана можливість разом з пацієнтом перевірити номер телефона для автентифікації, якщо він вказаний в системі;

3.1.3.16. якщо пацієнт не підтвердив лікарю правильність номеру телефону для автентифікації, необхідно вивести повідомлення для користувача: «Виписування рецепту неможливе. Для виписування рецепту необхідно змінити номер телефону для автентифікації. Зверніться до інформаційно-довідкової служби НСЗУ (номер телефону: 1677) для отримання роз’яснень щодо процедури скидання номеру телефону для автентифікації та після його скидання укладіть з пацієнтом нову декларацію з актуальним номером телефону для автентифікації»;

3.1.3.17. після формування заявки на ЕР та успішної процедури перевірки номеру телефону для автентифікації, МІС має надати можливість користувачу перевірити введені дані та у разі потреби зробити коригування введених даних, або виправити помилки, якщо вони будуть виявлені користувачем в заявці на ЕР; до даних, що вносяться до заявки на ЕР для коригування введених даних або виправлення помилок мають застосовуватися ті ж вимоги, що і до початково введених даних;

3.1.3.18. користувач має змогу на будь-якому етапі створення та (або) редагування заявки на ЕР тимчасово зупинити цей процес, а потім повернутися до нього або видалити заявку на ЕР незалежно від терміну її життя в системі;

3.1.3.19. після підтвердження користувачем правильності вказаних даних, заявка на ЕР має бути підписана КЕП користувача;

3.1.3.20. при успішному підписанні заявки на ЕР КЕП користувача в системі створюється ЕР, про що необхідно повідомити користувача:

• якщо у пацієнта є номер телефону для автентифікації та метод автентифікації в системі визначений як ОТР «Рецепт № ___ створено в електронній системі охороні здоров’я. Номер рецепту та код погашення надіслано в СМС-повідомлення на номер вказаний в декларації пацієнта. Не забудьте попередити про це пацієнта»;
• якщо у пацієнта немає номеру телефону для автентифікації та/або метод автентифікації в системі інший ніж ОТР «Рецепт № ____ створено в електронній системі охороні здоров’я. Код погашення: 0000. Не забудьте повідомити дані пацієнту»;

3.1.3.21. при неуспішному підписанні заявки на ЕР КЕП користувача в системі не буде створено ЕР, про що необхідно повідомити користувача, вивести інформацію щодо помилки та надати користувачу можливість підписати заявку на ЕР ще раз, або тимчасово зупинити процес формування заявки на ЕР, або видалити заявку на ЕР;

3.1.3.22. МІС має надати користувачу можливість роздрукувати інформацію про виписаний ЛЗ, а саме: МНН, форму випуску, силу дії, добову дозу ЛЗ, разову дозу ЛЗ, сигнатуру, номер ЕР та код підтвердження (в разі якщо метод аутентифікації інший за ОТР) у вигляді документу, який лікар віддає пацієнту при завершенні прийому, яким в залежності від реалізації кабінету лікаря МІС може бути:

3.1.3.22.1. інформаційна пам’ятка щодо виписаного ЕР яка відтворює інформацію, що зазначається на рецептурних бланках форми №1 (Наказ МОЗ № 360)або

3.1.3.22.2. консультаційний висновок чи інший документ, який містить вказану інформацію про виписаний ЛЗ;

3.1.3.23. інформаційна памятка, консультаційний висновок чи інший документ, який друкується пацієнту повинен додатково містити номер рецепту відображеним у штрих-коді формату СосІе-128 (тип А), При цьому ширина штрих- коду не повинна бути не менше та орієнтовно 8 см, а висота — не менше та орієнтовно 1 см. Під штрих-кодом, посередині, повинен дублюватись номер рецепту друкованими літерами та цифрами шрифтом висотою не менше ніж 10 пт.

Приклад:

3.1.3.24. МІС має надати користувачу, який виписав ЕР, можливість його відкликати вказавши причину такого відкликання та підписати таку дію своїм КЕП, а якщо ЕР на момент спроби відкликання вже буде погашеним — повідомити про це користувача;

3.1.3.25. користувач, який виписав ЕР пацієнту з наявним в системі номером телефону для автентифікації, має мати можливість без присутності пацієнта тільки одноразово (про що слід попередити користувача) ініціювати повторну відправку СМС-повідомлення методом Resend Medication Request та побачити успішність виконання даної операції;

3.1.3.26. користувач, який виписав ЕР пацієнту має мати можливість повторно роздрукувати інформацію з п. 3.1.3.22 даних вимог;

3.1.3.27. МІС має забезпечувати інформування користувача щодо ЕР, які не були погашені в термін 30 днів після виписування.

3.2. Модуль «Адміністративний модуль надавача медичних послуг ПМД»

Передумова відповідності функціональним вимогам: відсутня.

3.2.1. Вимоги до реєстрації НМП ПМД, реєстрації керівників НМП ПМД:

3.2.1.1 Успішне створення заявки на реєстрацію нового НМП ГІМД, що обов’язково повинна містити:

• код ЄДРПОУ/РНОКПП,
• тип закладу в системі, а саме «PRIMARY CARE»,
• дані про керівника НМП (підписанта): прізвище, ім’я та по батькові, посаду, стать, дата народження, країна та населений пункт народження згідно з чинними документами, серія та/або номер паспорту/ ID картки, ІПН, номер контактного телефону та адреса робочої електронної поштової скриньки;
• дані про ліцензію НМГІ: дата та номер наказу, серія та номер (опціонально), назва органу, що видав, тип ліцензії, дата видачі (діє з), що ліцензується, дата завершення дії (опціонально) або ідентифікатор раніше зареєстрованої в системі ліцензії;
• фактичну адресу надання медичних послуг НМП ПМД: область, район, населений пункт, вулиця (або інший тип), номер будівлі, номер корпусу (за наявності);
• контактні дані закладу (номер телефону(ів), адреса електронної пошти);

3.2.1.2 опціонально заявка може містити:

• Дані про акредитацію НМП: категорія, номер сертифікату акредитації, дата видачі, термін дії, дата та номер наказу, назва органу, що видав;
• посилання на веб-сторінку НМП,
• код одержувача/розпорядника бюджетних коштів для Казначейства;
• інформація про власника (бенефіціара) закладу;

3.2.1.3. після введення та перевірки введеної інформації, керівник НМП СМД повинен погодитись на обробку введених даних та підтвердити їх достовірність (передача параметрів consent_text, consent).

3.2.1.4. можливість оновлення інформації про НМП, ліцензії НМП, керівнику НМП з обов’язковою передачею в заявці відповідних унікальних ідентифікаторів НМП, ліцензії або користувача відповідно, в тому числі якщо заклад вже було зареєстровано в ЦБД з іншим типом.

3.2.1.5. відображення користувачу автоматично заповненої інформації про НМП з ЄДР:

• види діяльності (КВЕД),
• місце реєстрації: область, район, населений пункт, вулиця, будівля, організаційно-правова форма,
• повна назва або прізвище ім’я та по батькові повністю для ФОП, публічна назва (за наявності), скорочена назва (за наявності),

3.2.1.6. відображення користувачу блоку параметрів, а саме:

• Верифікації НСЗУ (nhs_verified, nhs_reviewed, nhs_comment)
• Стан суб’єкта в ЄДР ЮО та ФОП (edr.state);
• Статусу закладу в системі (status).

3.2.1.7. Дані про реєстрацію користувачів, в тому числі, з типом «OWNER» та «ADMIN», мають збігатися з даними, наданими користувачем МІС;

3.2.1.8. у разі неуспішної реєстрації НМГІ у ЦБД системи, МІС повинна інформувати користувача МІС про невідповідність введених даних або інші помилки, у разі їх виникнення при реєстрації відповідно до додатків визначених пунктами 1.13–1.15 цих вимог;

3.2.1.9. успішна реєстрація кожного з можливих типів користувачів;

3.2.1.10. МІС надає можливості введення всіх даних про посаду, рівні освіти, кваліфікації, спеціальності та наукові ступені користувачів згідно зі специфікацією АРІ системи;

3.2.1.11. новостворений запис в ЦБД системи відповідає даним про реєстрацію НМП в ЄДР та даним, наданим користувачем МІС.

3.2.2. Вимоги до управління підрозділами НМП:

3.2.2.1. успішна реєстрація підрозділів НМП;

3.2.2.2. новостворений запис в ЦБД системи відповідає даним про реєстрацію підрозділу НМП, наданим користувачем МІС;

3.2.2.3. користувач при реєстрації підрозділу НМП може передати (введені або обрані) GPS-координати підрозділу;

3.2.2.4. користувач системи з відповідними правами доступу може отримати список зареєстрованих підрозділів даного НМП;

3.2.2.5. користувач системи з відповідними правами доступу може оновити інформацію щодо раніше зареєстрованого підрозділу НМП;

3.2.3. Вимоги до управління співробітниками НМП:

3.2.3.1. успішна реєстрація співробітників НМП;

3.2.3.2. дані про співробітників, створених в МІС, в повній мірі відповідають даним, що надійшли в ЦБД системи;

3.2.3.3. МІС надає можливості введення всіх даних про посаду, рівні освіти, кваліфікації, спеціальності та наукові ступені користувачів згідно зі специфікацією АРІ системи;

3.2.3.4. можливість оновлення персональних і професійних даних існуючих користувачів;

3.2.3.5. керівник НМП може бачити статуси запитів на створення користувачів в системі (прийнятий або не прийнятий);

3.2.3.6. користувач системи з відповідними правами може змінювати статус користувачів на «звільнений» (dismissed) з діалогом підтвердження дії або скасування.

3.2.4. Вимоги до договору між НМП та НСЗУ:

3.2.4.1. успішне внесення та передача необхідних даних для формування заяви про укладення договору у відповідності із АРІ системи;

3.2.4.2. успішне підписання договору з боку НМП;

3.2.4.3. можливість оновлення даних договору, у тому числі внесення змін до даних щодо лікарів, підрозділів та підрядників НМП;

3.2.4.4. можливість введення даних за договором надається лише користувачу з типом «Керівник НМП»;

3.2.4.5. користувач системи з відповідними правами має бачити актуальні статуси заявок на договір та договорів, та отримувати оперативне сповіщення про зміни таких статусів;

3.2.4.6. користувач Системи з відповідними правами перед підписанням договору повинен побачити текст договору та повідомлення: «Накладаючи свій електронний підпис/кваліфікований електронний підпис я підтверджую, що текст договору мною прочитано, і зміст договору мені зрозумілий».

3.3. Модуль «Адміністративний модуль аптечного закладу»

Передумова відповідності функціональним вимогам: відсутня.

3.3.1. Вимоги до реєстрації АЗ, реєстрації користувачів:

3.3.1.1. успішне створення заявки на реєстрацію нового АЗ, що обов’язково повинна містити:

• код ЄДРПОУ/РНОКПП,
• тип закладу в системі, а саме «PHARMACY»,
• дані про керівника АЗ (підписанта): прізвище, ім’я та по батькові, посаду, стать, дата народження, країна та населений пункт народження згідно з чинними документами, серія та/або номер паспорту/ ID картки, ІПН, номер контактного телефону (бажано мобільний) та адреса робочої електронної поштової скриньки;
• дані про ліцензію АЗ: дата та номер наказу, серія та номер (опціонально), назва органу, що видав, тип ліцензії, дата видачі (діє з), що ліцензується, дата завершення дії (опціонально) або ідентифікатор раніше зареєстрованої в системі ліцензії;
• адреса провадження діяльності АЗ;
• контактні дані закладу (номер телефону(ів), адресу електронної пошти);

3.3.1.2. опціонально заявка може містити:

• посилання на веб-сторінку АЗ,
• код одержувача/розпорядника бюджетних коштів для Казначейства;
• інформація про власника (бенефіціара) закладу;

3.3.1.3. після введення та перевірки введеної інформації, керівник АЗ повинен погодитись на обробку введених даних та підтвердити їх достовірність (передача параметрів consent_text, consent).

3.3.1.4. можливість оновлення інформації по АЗ, ліцензії АЗ, керівнику АЗ з обов’язковою передачею в заявці відповідних унікальних ідентифікаторів АЗ, ліцензії або користувача відповідно, в тому числі якщо заклад вже було зареєстровано в ЦБД з іншим типом.

3.3.1.5. відображення користувачу автоматично наповненої інформації по АЗ з ЄДР:

• види діяльності (КВЕД),
• місце реєстрації: область, район, населений пункт, вулиця, будівля, організаційно-правова форма,
• повна назва,
• публічна назва (за наявності),
• скорочена назва (за наявності),

3.3.1.6. відображення користувачу блоку параметрів, а саме:

• верифікації НСЗУ (nhs_verified, nhs_reviewed, nhs_comment),
• стан суб’єкта в ЄДР ЮО та ФОП (edr.state),
• статусу закладу в системі (status).

3.3.1.7. У разі неуспішної реєстрації АЗ у Системі, МІС повинна інформувати користувача про невідповідність введених даних або інші помилки, що могли виникнути при реєстрації;

3.3.1.8. успішна реєстрація кожного з можливих типів користувачів.

3.3.1.9. МІС надає можливості введення всіх даних про посаду, рівні освіти, кваліфікації, спеціальності та наукові ступені користувачів згідно зі специфікацією АРІ Системи;

3.3.1.10. для перееєстрації раніше зареєстрованого в ЦБД АЗ через іншу МІС (реалізація методу «Manage more than one client connections») МІС повинен забезпечити для користувачів заповнення відповідних полів доступною та існуючою в ЦБД інформацією по АЗ з подальшою можливістю їх відкоригування.

3.3.1.11. Новостворений запис в ЦБД системи відповідає даним про реєстрацію АЗ в ЄДР та даним, наданих користувачем МІС;

3.3.1.12. дані про реєстрацію користувачів, в тому числі, з тином «PHARMACY OWNER» та «HR», мають збігатися з даними, наданими користувачем МІС;

3.3.2. Вимоги до управління підрозділами АЗ:

3.3.2.1. успішна реєстрація підрозділів АЗ;

3.3.2.2. новостворений запис в ЦБД відповідає даним про реєстрацію підрозділу АЗ, наданих користувачем МІС;

3.3.2.3. при реєстрації підрозділів АЗ, МІС повинна надавати користувачам можливість автоматичного завантаження даних про підрозділи АЗ Реєстру ДЛС, вносити іншу інформацію згідно з даними Реєстру ДЛС, або попереджати користувача про необхідність внесення в ЦБД системи назви підрозділу та іншої інформації щодо підрозділу згідно з даними Реєстру ДЛС;

3.3.2.4. користувач при реєстрації підрозділу АЗ повинен обов’язково передати (введені або обрані) GPS-координати підрозділу незалежно від опційності параметрів в ЦБД;

3.3.2.5. користувач системи, з відповідними правами доступу може отримати список зареєстрованих підрозділів даного АЗ;

3.3.2.6. користувач системи, з відповідними правами доступу може оновити інформацію щодо раніше зареєстрованого підрозділу;

3.3.2.7. користувач системи повинен бачити значення dls_id (ідентифікатор підрозділу в реєстрі ДЛС) для кожного зареєстрованого підрозділу та статус його верифікації: «верифікований з реєстром ДЛС» (dls^erifiedMrue) або «неверифікований з реєстром ДЛС» (dls_verified=false) якщо ці дані повертаються від ЦБД на запит get divisions. В разі відсутності даних або при отриманні значення «null» відображати користувачу текст «невідоме значення».

3.3.2.8. у разі отримання статусу «Не верифікований з реєстром ДЛС» необхідно відображати користувачу інформаційне повідомлення: «Відпуск ліків по даному підрозділу заборонено! Інформація по внесенному підрозділу не співпадає з інформацією в реєстрі ДЛС. Для відпуску лікарських засобів у даному підрозділі просимо скорегувати дані згідно реєстру ДЛС».

3.3.2.9. МІС може оперативно сповіщати керівника АЗ про зміну статусів dls_verified.

3.3.3. Вимоги до управління співробітниками АЗ:

3.3.3.1. успішна реєстрація співробітників АЗ;

3.3.3.2. дані, про співробітників створених в МІС в повній мірі відповідають даним, що надійшли в Систему;

3.3.3.3. МІС надає можливості введення всіх даних про посаду, рівні освіти, кваліфікації, спеціальності та наукові ступені користувачів згідно зі специфікацією АРІ Системи;

3.3.3.4. користувач системи з відповідними правами може оновити персональні, професійні та інші дані зареєстрованих співробітників;

3.3.3.5. користувач системи з відповідними правами може бачити статуси запитів на створення співробітників в системі (прийнятий або не прийнятий);

3.3.3.6. користувач системи з відповідними правами може змінювати статус користувачів на «звільнений» (dismissed) з діалогом підтвердження дії або скасування

3.3.4. Вимоги до договорів з НСЗУ:

3.3.4.1. у відповідності до АРІ Системи успішне введення необхідних даних для формування заяви про укладення договору та можливість вибору з раніше зареєстрованих в Системі підрозділів АЗ, які необхідно включити до участі у програмі реімбурсації;

3.3.4.2. успішне підписання договору з боку АЗ;

3.3.4.3. можливість оновлення даних договору, у тому числі оновлення переліку підрозділів АЗ, які беруть участь у програмі реімбурсації;

3.3.4.4. можливість введення та оновлення даних по договору надається лише користувачам з типом «Керівник АЗ»;

3.3.4.5. користувач Системи з відповідними правами має бачити актуальні статуси заяви про укладення договору та договорів, отримувати оперативне сповіщення про зміни таких статусів;

3.3.4.6. користувач Системи з відповідними правами перед підписанням договору повинен побачити текст договору та повідомлення: «Накладаючи свій електронний підпис/кваліфікований електронний підпис я розумію, про настання певних прав та обов’язків, зрозумів текст договору».

3.4. Модуль «Робоче місце фармацевта»

Передумова відповідності функціональним вимогам:

• АЗ, його підрозділи (місця провадження діяльності) та співробітники аптеки, які мають право відпускати ЛЗ, зареєстровано в системі через будь яку МІС, що надає такі можливості та яка підключена до системи;
• АЗ верифіковано НСЗУ;
• АЗ та його підрозділи мають чинну ліцензію в Реєстрі ДЛС.

3.4.1. Загальні вимоги:

3.4.1.1. успішна авторизація користувачів системи які мають права на відпуск ЛЗ згідно з АРІ системи;

3.4.1.2. за умови створення модуля «Робоче місце фармацевта» окремо від «Адміністративного хмодуля АЗ» в МІС реалізовано функціонал підтвердження керівником АЗ права роботи співробітників АЗ через даний МІС (реалізація методу «Manage more than one client connections») шляхом:

3.4.1.2.1. повідомлення користувача (тип owner або HR) перед реєстрацією права роботи співробітників через даний МІС:

«Для роботи в електронній системі охорони здоров’я для відпуску ліків за електронним рецептом вам необхідно переконатися в тому, що:

• ваш аптечний заклад зареєстровано в Єдиному державному реєстрі ЮО та ФОП;
• ваш аптечний заклад та його підрозділи мають чинну ліцензію в Реєстрі місць провадження діяльності з оптової та роздрібної торгівлі ЛЗ Державної служби України з лікарських засобів та контролю за наркотиками;
• ваш аптечний заклад, його підрозділи та співробітники зареєстровані в електронній системі охорони здоров’я;
• ваш аптечний заклад успішно верифікований НСЗУ.

Актуальний перелік МІС, які мають протестований адміністративний модуль аптечних закладів опубліковано на сайті: https://ehealth.gov.ua».

3.4.1.2.2. Введення необхідної інформації керівником АЗ для перереєстрації (Create/Update Legal Entity) даних АЗ, який був раніше зареєстрований через іншу МІС згідно з АРІ системи,

3.4.1.2.3. доповнення згідно з АРІ системи службовою інформацією про даний МІС;

3.4.1.2.4.скріплення введених даних чинним КЕП власника АЗ.

3.4.2. Вимоги до погашення електронного рецепту:

3.4.2.1 успішне введення номеру ЕР користувачем та коректне відображення поточного статусу ЕР;

3.4.2.2. при отриманні статусу ЕР «Погашений», «Відхилений або «Прострочений» слід візуалізувати відповідну інформацію користувачу, який має проінформувати пацієнта про неможливість погасити ЕР з відповідної причини;

3.4.2.3. при отриманні статусу ЕР «Діючий» користувачу необхідно забезпечити успішне погашення ЕР з наступними етапами та в наступному порядку:

• отримання та візуалізація інформації з ЕР;
• отримання та відображення переліку ЛЗ з «Реєстру лікарських засобів, вартість яких підлягає відшкодуванню», які задовольняють вимогам ЕР;
• обрання користувачем одного (обов’язково) або декількох торговельних найменувань (опційно) для відпуску, відповідно до побажань пацієнта;
• створення заявки на погашення ЕР, введення коду підтвердження ЕР;
• проведення відпуску ліків по касі АЗ;
• погашення ЕР та скріплення факту відпуску ліків КЕП користувача як співробітника АЗ;

3.4.2.4. отримання та візуалізація такої інформації з ЕР:

3.4.2.4.1. медична програма, в рамках якої виписано ЕР

3.4.2.4.2. НМП, в якому було виписано ЕР:

• назви НМП (в тому числі повна та публічна),
• код ЄДРПОУ (або РНОКПП, у випадку ФОП),
• юридична адреса НМП,
• інформація про підрозділ НМП, в тому числі контактні дані,
• інформація про ліцензію на медичну практику;

3.4.2.4.3. лікар, який виписав ЕР:

• ПІБ лікаря, що виписав рецепт,
• контактні дані лікаря;

3.4.2.4.4 пацієнт, якому було виписано ЕР:

• ID пацієнта (відображення в МІС як «Номер медичної карти амбулаторного хворого»),
• прізвище та ініціали пацієнта,
• кількість повних років пацієнта;

3.4.2.4.5. інформація щодо виписаного ЛЗ:

• назва ЛЗ, включаючи МНН «medication_name»,
• сила дії ЛЗ «dosage»,
• форма випуску ЛЗ «form»,
• виписана кількість ЛЗ «medication_qty»,
• сигнатура ЕР «dosage_instruction» (в тому числі, добова доза ЛЗ «max_dose_per_per iod», разова доза ЛЗ на один прийом «max_dose_per_administration», текст сигнатури рецепту «text»);

3.4.2.4.6. терміни дії рецепту:

• дата створення рецепту «created at»,
• дата першого дня, коли можливо отримати виписаний ЛЗ «dispensed valid from»,
• дата останнього дня, коли можливо отримати виписаний ЛЗ «dispensed valid to»,
• дата початку курсу лікування виписаним ЛЗ «started at»,
• дата завершення курсу лікування виписаним ЛЗ «ended at»;

3.4.2.5. тримання та відображення переліку ЛЗ з «Реєстру лікарських засобів, вартість яких підлягає відшкодуванню» (далі — Реєстр відшкодування), які задовольняють вимогам ЕР.

3.4.2.5.1 обов’язковий перелік:

• торговельна назва «participants.medication_name»,
• форма випуску «participants.form»,
• назва виробника та країна виробника «participants.manufacturer»,
• кількість в упаковці «participants.package_qty»,
• номер реєстру відшкодування «participants.registry_number»,
• дата початку дії реєстру відшкодування «participants.start_date»,
• дата закінчення дії реєстру відшкодування «participants.end_date», (якщо параметр відсутній, слід виводити текст «не визначено»),
• розмір відшкодування за упаковку лікарського засобу згідно реєстру відшкодування «participants.registry_number», грн. «participants.reimbursement_amount»,
• сума доплати пацієнтом за упаковку згідно реєстру відшкодування «participants.registry_number», грн «participants. estimated_payment_amount».

3.4.2.5.2. додатково система може відобразити користувачу довідкову інформацію:

• оптово-відпускну ціну за упаковку, грн «participants.wholesale_price»,
• рекомендовану роздрібну ціна за упаковку, грн «participants. consumer_price»,
• добову дозу лікарського засобу, рекомендовану ВООЗ «participants.daily_dosage»,
• розмір відшкодування добової дози лікарського засобу, грн «participants.reimbursement_daily_dosage»;

3.4.2.6. Обрання користувачем одного або декількох торгівельних найменувань для відпуску, відповідно до побажань пацієнта та внутрішніх процесів A3 пов’язаних з реалізацією ліків за відповідними реєстрами відшкодування.

3.4.2.6.1. МІС повинна забезпечити користувачу можливість обрати з запропонованого переліку одну (обов’язково) або декілька торгових назв (опційно) тільки з одного визначеного користувачем реєстру відшкодування paiticipants.registry_number» сформувавши таку інформацію по кожному обраному торговельному найменуванню:

• торговельне найменування у реєстрі відшкодування «participants.registry_number».
• кількість виписаного ЛЗ «medication_qty»,
• ціна за 1 упаковку «sell_price»,
• загальна ціна «sell_amount»,
• вартість на відшкодування однієї упаковки «Reimbursement_amount» у реєстрі відшкодування «participants.registry_number»,
• загальна вартість відшкодування в рамках реімбурсації обраного торгівельного найменування в рамках даного рецепту «discount_amount» згідно реєстру відшкодування «participants.registry_number».

3.4.2.6.2. користувач не повинен вводити з клавіатури кількість ЛЗ до видачі, а вибрати необхідну кількість упаковок обраної торгової назви — МІС має розрахувати таку кількість упаковок до видачі з урахуванням того, що:

• кількість одиниць ЛЗ кожного торгівельного найменування до видачі має бути кратною кількості одиниць ЛЗ в упаковці «package_qty»
• сумарна кількість одиниць ЛЗ всіх торговельних найменувань до видачі повинна дорівнювати кількості виписаного ЛЗ «request.medication_qty»;

3.4.2.6.3. якщо в результаті процесу обрання торговельних найменувань немає згоди між користувачем та пацієнтом, то користувач повинен закрити процес відпуску ЛЗ за даним ЕР;

3.4.2.7. створення заявки на погашення ЕР, введення коду підтвердження ЕР:

3.4.2.7.1. якщо в результаті процесу обрання одного торговельного найменування (обов’язково) або декількох торговельних найменувань (опційно) є згода між пацієнтом та користувачем, то користувач керуючись внутрішніми процесами АЗ, пов’язаними з обранням користувачем того чи іншого реєстру відшкодування, МІС повинна створити заявку на погашення ЕР з кодом підтвердження від пацієнта та обов’язковим зазначенням «program_medication_id», що відповідає обраному користувачем учасника реєстру відшкодування. В результаті успішного створення заявки ЕР закріплюється за поточним АЗ для виписування на 10 хвилин і не може бути погашений в іншому АЗ протягом цього терміну;

3.4.2.7.2. МІС повинна забезпечити формування нової заявки якщо за 10 хвилин користувач не встигне погасити ЕР;

3.4.2.7.3. якщо на етапі створення заявки пацієнт відмовився від обраної торгової назви, то МІС повинна забезпечити користувачу закриття процесу відпуску ліків за ЕР і направити запит до системи по відхиленню заявки на погашення ЕР;

3.4.2.8. проведення відпуску ліків по касі АЗ є внутрішнім процесом АЗ, але в результаті даного етапу в МІС повинні бути сформовані 2 параметри:

• сума в чеку, яку заплатив пацієнт «payment_amount»;
• номер фіскального чеку «payment_id» (опціонально, за можливості технічної інтеграції з касовим апаратом);

3.4.2.9. погашення ЕР та скріплення факту відпуску ліків КЕП користувача як співробітника АЗ:

• МІС повинна сформувати необхідний контент у json файл відповідно до АРІ системи та технічних вимог до МІС,
• користувач в МІС повинен підписати json КЕП співробітника аптеки,
• МІС повинна перекодувати підписаний json у base64 формат,
• МІС повинна виконати відповідний запит до системи;

3.4.2.10. в разі успішного виконання запиту ЕР переходить у статус «Погашений», в системі формується запис про реімбурсований ЕР за даним АЗ, а користувач повинен бути проінформованим про успіх процесу та можливість віддати ліки пацієнту;

3.4.2.11. у разі виникнення помилок на будь якому етапі користувач повинен бути проінформований про це з можливістю виправити дані та повторити етап;

3.4.2.12. МІС повинна забезпечити користувачам можливість отримати інформацію щодо відпущених ними ЕР відповідно до АРІ системи;

3.4.2.13. МІС повинна забезпечити можливість отримати керівнику АЗ інформацію щодо відпущених ЕР усіма співробітниками АЗ відповідно до АРІ системи.

3.5. Модуль «Адміністративний модуль НМП спеціалізованої медичної допомоги»

3.5.1. Вимоги до реєстрації НМП СМД, реєстрації керівників НМП СМД:

3.5.1.1. успішне створення заявки на реєстрацію нового НМП СМД, що обов’язково повинна містити:

• код ЄДРПОУ/РНОКПП,
• тип закладу в системі, а саме «OUTPATIENT»,
• дані про керівника НМП СМД (підписанта): прізвище, ім’я та по батькові, посаду, стать, дата народження, країна та населений пункт народження згідно з чинними документами, серія та/або номер паспорту/ ID картки, ІПН, номер контактного телефону (бажано мобільний) та адреса робочої електронної поштової скриньки;
• дані про ліцензію НМП СМД: дата та номер наказу, серія та номер (опціонально), назва органу, що видав, тип ліцензії, дата видачі (діє з), що ліцензується, дата завершення дії (опціонально) або ідентифікатор раніше зареєстрованої в системі ліцензії;
• фактичну адресу надання медичних послуг НМП СМД
• контактні дані закладу (номер телефону(ів), адресу електронної пошти);

3.5.1.2. опціонально заявка може містити:

• дані про акредитацію НМП СМД: категорія, номер сертифікату акредитації, дата видачі, термін дії, дата та номер наказу, назва органу, що видав;
• посилання на веб-сторінку НМП СМД,
• код одержувача/розпорядника бюджетних коштів для Казначейства; і
• інформація про власника (бенефіціара) закладу;

3.5.1.3. після введення та перевірки введеної інформації, керівник НМП СМД повинен погодитись на обробку введених даних та підтвердити їх достовірність (передача параметрів consent_text, consent).

3.5.1.4. можливість оновлення інформації по НМП СМД, ліцензіях НМП СМД керівнику НМП СМД з обов’язковою передачею в заявці відповідних унікальних ідентифікаторів НМП СМД, ліцензії або користувача відповідно в тому числі якщо заклад вже було зареєстровано в ЦБД з іншим типом.

3.5.1.5. відображення користувачу автоматично наповненої інформації по НМП СМД з ЄДР:

• види діяльності (КВЕД),
• місце реєстрації: область, район, населений пункт, вулиця, будівля,
• організаційно-правова форма,
• повна назва,
• публічна назва (за наявності),
• скорочена назва (за наявності),

3.5.1.6. відображення користувачу блоку параметрів, а саме:

• Верифікації НСЗУ (nhs_verified, nhs_reviewed, nhs_comment)
• Стан суб’єкта в ЄДР ЮО та ФОП (edr.state);
• Статусу закладу в системі (status)

3.5.1.7. Новостворений запис в ЦБД системи відповідає даним про реєстрацію НМП в ЄДР та даним, наданих користувачем МІС;

3.5.1.8. дані про реєстрацію користувачів, в тому числі з типом «OWNER» та «ADMIN», мають збігатися з даними, наданими користувачем МІС;

3.5.1.9. у разі неуспішної реєстрації НМП у ЦБД системи, МІС повинна інформувати користувача МІС про невідповідність введених даних або інші помилки, у разі їх виникнення при реєстрації відповідно до додатків визначених пунктами 1.13–1.15 цих вимог;

3.5.1.10. успішна реєстрація кожного з можливих типів користувачів;

3.5.1.11. МІС надає можливості введення всіх даних про посаду, рівні освіти, кваліфікації, спеціальності та наукові ступені користувачів згідно зі специфікацією АРІ системи.

Директор Департаменту розвитку електронної системи охорони здоров’яД. Черниш

ЗАТВЕРДЖЕНО

наказ Національної служби здоров’я України

від 30.09.2019 р. № 385

ТЕСТОВА ПРОГРАМА
встановлення відповідності електронних медичних інформаційних систем технічним вимогам

1. Загальні положення

1.1. Тестова програма встановлення відповідності електронних медичних систем технічним вимогам (далі — Тестова програма) встановлює алгоритм тестування електронних медичних інформаційних систем (далі — МІС) на відповідність технічним вимогам, дотримання яких є необхідним для підключення МІС до центральної бази даних електронної системи охорони здоров’я (далі — система).

1.2. Тестуванню підлягають МІС, розроблені з урахуванням специфікацій, визначених Державним підприємством «Електронне здоров’я» (далі — Адміністратор), заявка на тестування яких подана Адміністратору оператором МІС відповідно до законодавства.

1.3. Тестуванню підлягають функціональні можливості МІС, передбачені технічними вимогами в рамках кожного модуля, включеного до заявки на тестування.

2. Порядок тестування

2.1. Тестування МІС здійснюється виключно шляхом визначення відповідності МІС технічним вимогам в частині функціональних вимог до модулів МІС (розділ 3 Технічних вимог до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я).

2.2. Тестування МІС здійснюється на тестових середовищах системи.

3. Процедура тестування

3.1. Оператор МІС, подаючи заявку на тестування згідно із затвердженою Адміністратором формою, надає технічну можливість провести тестування функціоналу, що передбачений технічними вимогами в межах модулів МІС, включених до заявки на тестування, на актуальній версії програмного забезпечення МІС, шляхом:

• направлення копії програмного забезпечення або посилання на відповідну веб-сторінку МІС (що налаштовані на роботу з тестовим середовищем системи) та ключів, логінів та паролів доступу до МІС (спеціального доступу до інтерфейсу (апаратно-програмних засобів, що забезпечують графічне відображення і обмін інформацією в межах тестового середовища ЦБД без надання доступу до персональних даних, що можуть оброблятись в МІС));
• проведення тестування в режимі онлайн за допомогою програмного забезпечення для віддаленого доступу з обов’язковим записом процесу тестування.

3.2. Додатково або на вимогу Адміністратора, Оператор МІС надає аудіо- відеозапис процесу виконання робочих операцій, що визначені вимогами до відповідного модулю. Вказані робочі операції виконуються оператором МІС на тестовому середовищі системи. Файл з аудіо-відеозаписом скріплений кваліфікованим електронним підписом (далі — КЕП) оператор МІС додає до заявки на тестування разом з іншими документами, передбаченими законодавством.

3.3. Адміністратор розглядає подану заявку і додані до неї документи та приймає рішення про початок тестування, або інформує оператора МІС про необхідність усунення недоліків у заявці та (або) доданих до неї документах.

3.4. В разі прийняття рішення про початок тестування, уповноважені особи Адміністратора здійснюють аналіз функціоналу наданого оператором МІС на тестування та документів, в тому числі аудіо-відеозапису (якщо надано), з метою встановлення відповідності МІС технічним вимогам в частині функціональних вимог до модулів МІС.

3.5. У разі якщо надані матеріали містять недоліки, через які неможливо провести аналіз, або якщо на основі проведеного аналізу неможливо однозначно встановити відповідність або невідповідність МІС технічним вимогам, зокрема відповідність модулів МІС функціональним вимогам, Адміністратор інформує оператора МІС про необхідність усунення таких недоліків та пропонує повторно подати заявку на тестування.

3.6. Адміністратор має право повторно протестувати МІС на вимоги цієї Тестової програми з моменту приєднання оператора МІС до Договору про підключення електронної медичних інформаційних систем до центральної бази даних в тому числі без попереднього попередження оператора МІС.

Директор Департаменту розвитку електронної системи охорони здоров’яД. Черниш

Бажаєте завжди бути в курсі останніх новин фармацевтичної галузі?
Тоді підписуйтесь на «Щотижневик АПТЕКА» в соціальних мережах!