Page Comparison

Выполнение исследования

•  Будут ли в е-хелс зарегистрированы все лаборатории, и их сотрудники, которые имеют лицензии, в т.ч. те, у которых нет договора с МОЗ?  - да
  •  Как те, кто без договора, но с лицензиями, смогут постить результаты 
    •  Они могут быть зарегистрированы без договора - да и будут
    •  Они могут делать анализы по направлениям - да, нужна дополнительная квалификация на возможность выполнения этой услуги этой лабораторией (есть договор) на условиях оплаты государством (есть программа в которую включена эта услуга)
  •  Будут ли те, кто с договором или без и лаборатория в е-хелс присутствует, регистрировать всех сотрудников? (подозреваю, что будут постить от имени одного, имеющего регистрацию в е-хелсе, поэтому для исполнителя анализа предлагается делать текстовое поле)

• Даблфандинг закрывается:
  • документом (подпись пациента)
  • смс - под вопросом

Если пациент пришел с направлением:

• Специалист лаборатории по Human Readable Number ищет направления

•  Как убедиться, что с направлением пришел тот пациент, которому оно было выписано? (при необходимости получить определенные результаты, могут приходить другие люди вместо пациента - актуально для призывов, получения прав, мед персонала и т.п. - примеров много)

• Идентификацию делать через СМС - на каком месте только не понятно
• Из полученных направлений отбирает те, по которым возможен забор анализов и выполняет Use

•  

  В текущей реализации специалист лаборатории найдет все направления с таким же номером, а значит, может найти направления на консультации и процедуры в том числе. Как (и нужно ли) ограничить возможность Use разных категорий направлений медицинским учереждениям (а скорее их сотрудникам), которые могут иметь, а могут не иметь право на выполнение различных категорий услуг (например, кто-то может иметь и МРТ и анализы, кто-то только анализы, у кого-то и вторичка и анализы  и т.п.)? Если не ограничивать, могут получить доступ к данным пациента по консультационным направлениям - не ограничиваем никак.

•  В текущей реализации Use требует ссылку на врача, который будет предоставлять консультацию. В парадигме анализов: это тот, кто делает Use, кто собирает анализ (а это может быть неизвестно в момент, когда выполняется Use), тот, кто выполняет исследование, тот, кто пишет заключение (репорт)? - для юза по лаб анализам параметр не обязательный.

При отсутствии направления:

• Специалист лаборатории идентифицирует пациента поиском по ключевым параметрам (ФИО+что-то)

Независимо от наличия или отсутствия направления:

TBD в контексте передачи результатов

Release Service Request в контексте лабораторных анализов

• Use не является фактором, блокирующим Release другой лабораторией. 

 В текущей реализации для консультаций Release может быть выполнен только для направления, на которое не ссылается ни один эпизод в состоянии активный или завершенный. Т.е. только тогда, когда фактическое взаимодействие с пациентом выполнено и консультация предоставлена. Перенося этот принцип на направления на лабораторные исследования: фактом свершившегося взаимодействия с пациентом, может быть только наличие взятых образцов у пациента.

 Use может выполняться еще по телефону, т.к. пациенту нужно записываться на исследование (больше это относится к инструментальным исследованиям, но часто и на анализы записывают на время - личный опыт).  

Соответственно:

• Release направления кем бы то ни было, невозможен, если забор материала или фактическое исследование уже выполнены

•  Оплачивается ли неудавшаяся попытка забора анализов?
•  Что считать фактом забора материала? Образцы мы не регистрируем, вероятно, это наличие драфта диагностик репорта и/или эпизода со ссылкой на репорт

Передача результатов анализов в e-health

 В текущей реализации доступность на пост/изменение чего бы то ни было есть только у врача с декларацией и у хозяев эпизода (уточнить сделали ли правила на АБАКе по ланкам и ЗОЗам). В лаборатории по умолчанию нет эпизода, соответственно, нет права постить вообще что бы то ни было. Эпрувалы дают временный доступ пати к ресурсу и только на чтение.

Вариант 1: давать право на пост анализов лаборатории при определенных условиях, т.е. это по сути новые правила в авторизации: еще на уровне ABAC, мы выходим за рамки эпизода и изменяем правила работы эппрувалов.

• если нет ссылки на сервис-реквест
  • должен быть актуальный эппрувал 
  • такое правило  должно давать право на создание других сущностей под диагностик репортом (обзервейшны)

•            В нашем случае ресурса, на который выдавать эпрувал нет - делаем драфт диагностик репорта (пекеджа на самом деле, т.к. есть в нем обзервейшны)?
•            Для правил с диагностик репортами должна быть возможность указать изменение (вместо чтения) и срок действия - безвременный или очень большой (результаты анализов иногда могут приходить в течении полугода), отличный от сроков для консультаций. Отходим от концепции эппрувалов?

• если в диагностик репорте есть ссылка на сервис реквест:
  • Можно пойти по пути как с драфтом диагностик репорта (как для репорта без ссылки на сервис-реквест), тогда выдавать эпрувал можно сразу при 
  • Можно добавить правило в ABAC: принимать такой репорт (пекедж), если у него и сервис-реквеста, на который он ссылается, совпадают пациенты, и юз сервис реквеста выполнен той же лабораторией, что и постит диагностик репорт (+возможны условия на наличие договора, если клиники без договора могут работать в е-хелсе но не могут обрабатывать сервис-реквесты). В противном случае диагностик репорт и все его составляющие не принимается

•             Какой вариант выбираем? Учитывая, что драфт нужен для ограничения релиза реквеста, правильнее вариант с драфтом.

Вариант 2: использовать существующие правила и реализацию: создавать энкаунтеры эпизоды

Тогда в процессе выполнения исследования:

• Специалист лаборатории регистрирует эпизод и энкаунтер с пациентом
  • Если есть направление, то и с ссылкой на направление

- этого уже достаточно для того, чтобы не было повторного юза, тогда если что-то пойдет не так и клиент не сможет сдать анализы, то сделают энтеред ин эррор, но можно пойти дальше (недостаток - апдейт сущности, достоинство - контроль даты за которую постятся обзервейшны):

• Специалист лаборатории регистрирует драфт диагностик репорта с пациентом (по-хорошему тут образцы и вот их наличие как-раз и блокирует повторный юз. у нас образцов нет и не нужны, поэтому драфт репорта)
  • наличие драфта определяет то, что анализы приняты (например баночку принес пациент с собой)/будет выполнен забор
  • если что-то пошло не так, не смогли взять анализ и т.п., драфт закрывается как энтеред ин эррор - должна быть возможность выполнить Release Service Request при таких условиях

Diagnostic Report Package

• Diagnostic Report
  • один диагностик репорт на один реферрал 
    • код услуги в реферрале и код услуги в репорте должны совпадать 
      • наличие ссылки на услугу, которую оплачивает государство, в диагностик репорте со ссылкой на реферрал, запощеном клиникой без договора с МОЗ (если такое возможно - если она может быть зарегистрирована и может выполнять исследования по направлениям без договора), не означает оплату этой услуги
  •  может быть диагностик репорт без ссылки на реферрал
    • в таких репортах может быть generic код услуги 
    • наличие ссылки на услугу, которую оплачивает государство, в диагностик репорте без ссылки на реферрал, не означает оплату этой услуги
  •  обязательны ссылка на пациента, и (при варианте 2) энкаунтера

• Observations

•  В текущей реализации обзервейшн должен быть обязательно привязан к энкаунтеру или к эпизоду, к чему мы будем привязывать обзервейшны по диагностик репортам? Если к эпизоду из сервис реквеста, то это противоречит текущим правилам возможности поста (когда эпизод не относится к исполнителю анализа), и ИМХО, не правильно логически, обзервейшны по анализам не зависят логически от эпизода по которому их заказывали, они в принципе - есть на определенный момент времени. Для Варианта 1 нужно снимать обязательность эпизода/энкаунтера у обзервейшна. Для Варианта 2 проблемы нет.

• Обзервейшны по диагностик репорту должны содержать в себе дату забора анализов (и она не равна дате Use), соответственно, при их посте, дата обзервейшна должна быть в прошлом