Search... (alt + k)

Административные объекты

Эта группа работает над двумя задачами.

1. Локализация ресурсов административного модуля спецификации FHIR (здесь нужна ссылка на http://hl7.org/fhir/administration-module.html). В первую очередь будут обработаны объекты:

  • Organization
  • Patient
  • Practitioner

Результатом этой работы станет руководство по реализации Руководство Ru Core в части административного модуля, достаточное для реализации следующих сценариев:

2. Мапирование на ресурсы FHIR федерального реестра медицинских организаций frmo

На встрече пробежались по инфраструктурным и редакторским задачам, определили приоритеты.

  • 02:37 проверка состояния работ по профилированию Patient & Encounter
  • 12:35 EpisodeOfCare: впоследствии нужно будет сделать профиль, в нем определить identifier с привязкой (extensible) к тому же ValueSet, который используется для CorePatient.
  • 19:50 Organisation
  • 29:30 Coverage
  • 31:40 Department: не увидели достаточных причин держать отдельный профиль, кроме как в рамках задачи о ведении справочника медицинских организаций. Профиль пока удаляем.
  • 36:30 Encounter.Subject: допустим ли Group? Иными словами, верно ли что RuCore предназначен только для обмена данными пациентов или для любых медицинских применений на территории РФ?
  • 39:44 Practitioner и PractitionerRole, в том числе – о профилировании HumanName для указания имени-отчества
  • 51:30 Association – нет требований к профилированию, удаляем
  • 51:41 Condition – хорошо бы его даже и на уровне Core сделала клиническая группа
  • 57:00 Naming Systems для справочников – размещать ли их на отдельных страничках или на страничках справочников
  • 00:00 статус работ по кодированию лабораторных профилей: 22 профиля, 10 сделано. Стоит ли включать профиль Media.
  • 03:35 профиль RuCore-Coverage – как кодировать Contract. Обсуждение поиска по номеру договора (неизвестно, бывает ли такое), обсуждение вариантов слайсинга.
  • 00:48 разбираем приоритеты инфраструктурных задач. Валидация по ValueSet: для коротких справочников сейчас доступное решение – только enum, для длинных пока решения нет.
  • 14:25 валидация нескольких ресурсов со связями: в окне профиля делать ее нелогично, можно через Bundle, через загрузку на собственный AidBox.
  • 23:18 описание справочников на страницах сайта
  • 30:34 Ю.Махоткин, Health Samurai – о планах по поддержке работы с терминологиями на FHIR Ru - получение из внешних источников, хранение, публикация, валидация ресурсов с использованием наборов значений
  • 47:54 держать ли одинаковыми именование артефактов и структуру папок на сайте? Оживлять ли ссылки в описаниях профилей чтобы они вели на странички терминологий и на детальные описания атрибутов?
  • 03:18 обсуждение Coverage
  • 31.40 разбор задач административной группы, приведение в порядок статусов
  • 02:12 А.Павлышина о структуре информации в файлах лабораторной группы и переносе их на сайт zendoc
  • 00:00 Patient
  • 13:40 Coverage
  • 29:05 Encounter
  • 39:12 Task
  • 00:00 Делать ли «финансовые профили» для пациента и организации. Дублировать ли номер полиса в Пациенте и в Coverage.
  • 05:52 Типы/подтипы документов в Coverage. Разница между типом оплаты и типом документа, который обосновывает оплату.
  • 1:30 разбор замечания В.Родионова о кодировании Patient.Gender – сделаем маппинг FHIR-НСИ в обе стороны, рекомендуем не использовать value Other.
  • 11:53 делать ли один профиль на организацию или два.
  • 21:45 маппинг документов удостоверяющих личность
  • 22:20 типизация организаций – еще раз обсудили уже известные идеи
  • 33:18 синхронизация терминологий с НСИ ЕГИСЗ – что именно мы должны делать при появлении новой версии на НСИ
  • 41:25 просмотр текущего состояния страничек вики
  • 45:00 временное имя пациента, идентификация новорожденных и неопознанных пациентов
  • 49:25 идентификация пациента по номеру в МИС (сделана дискуссия 128 )
  • 00:18 справочник типов организаций. Следует отказаться от использования типизации юрлиц – инд.предприниматель/АО/ПАО и т.п., потому что он не имеет смысла для наших задач. Справочник по видам деятельности медицинская/фармацевтическая/страховая следует оставить как пример. ОКАТО тоже как пример.
  • 23:06 надо ли дублировать указание юридического лица / подразделения в поле type; использование part of в юридическом лице и подразделении.
  • 33:08 пациент, идентификация по полису ОМС – систему идентификации будем называть «Единый реестр застрахованных», дадим ссылку на нормативный акт; создадим ресурсы NamingSystem для описания различных внешних систем идентификации
  • 42:23 паспорт пациента, указываем код по базовому ValueSet FHIR и код по справочнику «Документы, удостоверяющие личность» НСИ ЕГИСЗ.
  • В том числе 51:25-56:33 А.Павлышина объясняет использование ресурса NamingSystem, типов данных CodeableConcept, Coding, Identifier.Type, для идентификации объектов, на примере Patient.
  • 1:03:42 использование идентификаторов пациентов для поддержки бизнес-процесса опознания неизвестного. Для них нужно будет вводить специальные системы идентификации – медицинская справка о рождении, медицинская справка о смерти, номер по журналу неопознанных.
  • 1:07:32 индексы пациентов. Одна и та же персона может иметь множество идентификаторов пациента по различным МИС. Для обслуживания процесса слияния-разделения карточек пациентов можно использовать либо Patient.Link, либо Person.Link
  • 06:30 – Юридическое лицо, Подразделение. Осталось дожать адрес по ФИАС. Требуется знаток ФИАС. Вопросы – достаточно ли в лицензии номера, дат, выдавшей организации? Может ли наименование улицы быть одно (например, из паспорта), а наименование улицы, вычисленное из ее кода ФИАС, другое? В качестве примера можно теперь использовать список подразделений с адресами, предоставленный компанией Инвитро.
  • 29:32 – Сотрудник. Кодируем парой Practitioner – PractitionerRole, вопросов пока не встретили.
  • 36:05 – Пациент. Для документа удостоверяющего личность типа Паспорт можно сделать slice с дополнительным полем – номер выдавшего подразделения. Кроме поля BirthDate можно использовать расширение BirthTime, как уже предлагали на первом цикле создания RuCore. Организация, предоставившая сведения о пациенте, может быть закодирована Patient.ManagingOrganisation.
  • 11:24 Т.Алейников, Николай Рыжиков о том, следует ли не рассматривать структуру юридических лиц или, наоборот, на ней основываться
  • 18:48 Д.Фадин, Николай Рыжиков об объединениях организаций, core.Affiliation
  • 31:35 итого кратко, к какой структуре пришли Николай Рыжиков
  • 35:29 придерживаться ли старой структуры ФРМО – Коган, Алейников. Ответ – не обязательно.
  • 37:20 Д.Фадин, Т.Алейников, Н.Рыжиков, Е.Коган – развязывать ли функциональную и административную и юридическую структуры
  • 43:40 Ш.Низамов, Николай Рыжиков, Олег Пензин о разделении на Руководство Ru Core и другие IG
  • 58:54 С.Швырев, Т.Алейников о файлике со списком полей ФРМО для работы по подбору для него ресурсов FHIR
  • 1:09:18 Е.Коган, Н.Рыжиков о структуре веток дискуссий
  • 1:14:50 О.Пензин анонс темы о структуре диагнозов

Вы можете высказать замечания-предложения по поводу содержания этой страницы в этой дискуссии: (ссылка на дискуссию номер 88)

Наверх
Referenced By
groups