В: При обръщението към https://auth.his.bg кой метод се използва – POST или GET?
О: Заявката е GET и се извършва на адрес https://auth.his.bg/token
В: От къде можем да вземем XSD валидационна схема за подписа на съобщенията?
О: Подписът следва спецификацията по https://www.w3.org/TR/xmldsig-core/, където има и примери. Самата схема е достъпна чрез адрес http://www.w3.org/2000/09/xmldsig#
В: Имаме проблем с правилното форматиране на подписа към заявките. За какво да внимаваме?
О: Подробности за метода на подписване можете да намерите на https://www.w3.org/TR/xmldsig-core/. Подписът се прави върху цялото съобщение и трябва да съдържа сертификата. Съдържанието и структурата на Signature не се променя, и е според спецификацията.
В: Как могат служители в лаборатории, които не са лекари, да достъпят е-направление чрез заявка R003?
О: Организациите, които искат техни служители, които не са лекари, да извличат информация за е-направления, трябва да предоставят списък данни за тези лица, които ще се въведат в специален регистър в НЗИС. Организациите също така трябва да осигурят КЕП за всеки един от тях. Заявките за търсене и извличане на е-документи от НЗИС (и в частност заявка R003) очакват както подпис от служителя, който ги изпраща (независимо дали е лекар или не), така и регистрационния номер на самото лечебно заведение, в което той работи в момента на изпращане на заявката. Ако служителят е регистриран в НЗИС за съответното ЛЗ, заявката ще върне резултат – в противен случай ще върне грешка. Очевидно, ако дадено лице работи в различни ЛЗ, то тогава трябва да бъде регистрирано поотделно за всяко ЛЗ.
В: Как да изпращаме повече от един елемент при cardinality различно от 1..1, например за поле code (медико-диагностична дейност) в заявката за създаване на е-направление?
О: Стандартно за XML структури, в такъв случай таговете за това поле се подреждат един след друг без необходимост от допълнителен групиращ таг. Обърнете внимание, че подредбата е от значение, както при елементите в масив.
В: Какво се има предвид под поле nhifNumber, поделемент на requester частта в заявката за създаване на е-направление?
О: Спрямо Приложение № 2 "Първични медицински документи": НЗОК номер се отнася за ЛЗ, които имат един ИАМН номер/РЗИ номер и склчени договори в различни РЗОК или ЛЗ по чл. 5 от ЗЛЗ.
В: В поле qualification предвиждате посочване на специалност на лекар. В номенклатурата CL006 за ОПЛ най-близката специалност е с код 1043 Обща медицина, но това е специалност, която не всички ОПЛ притежават. Какво да попълним като стойност в такъв случай?
О: Номенклатура CL006 съдържа мапинг към кодовете в НЗОК. На код 1043 от НЗИС отговаря код 00 по НЗОК.
В: Какво точно е значението на условие CDR07 спрямо подаването на държава на пациента в заявката за създаване на е-направление?
О: Условие CDR07 казва, че ако типа на идентификатора на пациента е ЕГН, то тогава държавата на пациента може да бъде само BG (т.е. фиксирана стойност). Във всички случаи подаване на държава е задължително.
В: В какви случаи се попълва поле pmiDeputy в заявката за създаване на е-направление?
О: Спрямо Приложение № 2 "Първични медицински документи": Вписва се УИН на лекаря заместник (нает персонал), осъществил преглед. Моля обърнете внимание, че НЗИС също така очаква УИН на лекаря-титуляр в поле pmi, дори и ако направлението се издава от заместник.
В: По какви критерии да генерираме Локален Референтен Номер (ЛРН)?
О: ЛРН трябва да бъде уникален за всеки един документ в контекста на един и същи УИН. Можете да генерирате и UUID, но е добре да се вземе под внимание, че може да се наложи ЛРН да се използва при търсене на е-документ и е добре да има по-удобен формат.
В: Виждаме, че правите валидация на пациентските имена срещу ГРАО и връщате грешка, ако има несъвпадение. Защо е необходимо това?
О: Това е по изискване за сигурност, както и за консистентност на данните в новия Индекс на Пациентите. Ако има разминаване на имената (погрешно изписване или напълно сгрешено име), то НЗИС ще върне грешка, индикираща проблема. В този случай потребителят ще трябва да коригира въведеното.