Приветствую.
Слышно? Раз,
Два, три. Слышно ли?
Слышно, отлично.
Прекрасно.
Так, ну что, кажется, задача была открытая в сторону на этот раз. Да, там
Есть у меня краткий комментарий, но давайте сначала вы про изыскание, а потом, может быть, оно не потребуется.
Хорошо.
Так, что произошло? Я отправил агента делать эту работу, а именно переводить амбулаторный сэмпл на FHIR. Отправил я его делать точно то же, что мы делали с S&MP, то есть не строить профили, а переводить пример.
Значит, он сказал, что он все перевел, что он отмапировал 1300 значений атрибутов. Из них что-то перенесено один в один, что-то преобразовано, что-то, как мы и раньше делали, тоже электронным атрибутом CD, которое не нужно.
Первое, это работа оказалась очень полезной для самого Rucora. Валидатор выявил 12 ошибок, относящихся к трем. Сейчас я найду это место.
Мы экспериментально подтвердили, что практика — критерия истины.
Абсолютно.
Причем, мы экспериментально подтвердили, что RailCore в высокой степени применим. Найдены три проблемы. Сейчас мы их почистим. Я не начинал еще. Core coverage, что-то там с дискриминатором.
Вот,
И есть большая беда. Не надо будет разбираться. То, что мы в системах кодирования говорили, что они комплит, и сводили туда единственное значение нашего теста, что, конечно, неправда. Мы так делали, потому что в противном случае публикатор ругался, и я тогда не дожил.
Ну, наверное, надо будет попробовать с агентом, с публикатором поработать, и тогда снять флаги complete, да, вот по системам кодирования.
Да.
А с coverage, дискриминатор слайсов для identifier.
Можем пойти посмотреть, что там происходит.
Важная вещь.
Да, вот в решениях сразу видно, что мы вводили два среза на идентификатор, общий вариант документа, и у нас полисе.
Как это описано, ну.
Как тут никак не описано. У нас, кажется, и в других местах так не описано, что они open. Да, это по умолчанию, наверное.
Да.
Ну, если на вскипку не видно, то я с агентом поразбираюсь, что именно здесь неправильно. Поправить.
Хорошо.
Наверное, проще, если что.
Да, если что. Или встретимся, или напишу. Я не считаю себя готовым в деталях обсуждать, защищать. Просто статус таков, что в целом преобразование примера сделано, найдены несколько ошибок, они подлежат правке.
Причем подлежат правке на уровне рукора самого, и нет никаких поползновений, никаких требований к профилированию рукора, то есть его решений как бы достаточно, вроде как, для кодирования примера.
Главный вопрос у меня такой: в каком виде мы хотим эту работу сделать? Вот что я имею в виду. Если мы просто переводим пример на первом, то непонятно как, но статью написать. Если мы делаем профили, то тогда мы можем вот сюда, в ну либо в решение на fire, я не знаю, либо просто в сам рукор. Да, пока мы используем это не только кругов, да, вот для проекта гостом, вот сюда добавить еще пункт меню, вот сверху назвать его "кодирование sent" и тут разместить наследованную спецификацию.
Как вы считаете?
Ну, мне кажется, нужно точно публиковать, потому что, ну, как минимум, в процессе подготовки публикации мы чуть лучше сами выберем то, что у нас получилось.
Если это будет, например, некоторую практическую ценность упражнения повышать.
А так, на сайте вывесить тоже можно, пускай сообщество ознакомится, может, кто-то заинтересуется, придет, какую-то обратную связь оставит.
Но публикацию надо делать, в том числе, чтобы продолжать гнуть свою линию.
Хорошо, при этом я тогда подготовлю для.
Коллег из Минздрава из Ньюиза, да-да.
Да, да, ну и вообще, действительно, мы заявились. Вот мы зачем перевели как пример 1 в линейке. Вот, а дальше работа идет. Дальше, тем более что редакция журнала стандартизация здравоохранения сказывала готовность продолжать публикации. Кажется, надо продолжить.
Прошу. Сейчас, одну секунду, у меня тут еще звонок по обычной мобильной связи.
Евгений, я вернулся, как слышно.
Да, хорошо слышно, отлично. Итак, мы с вами решили, что целесообразно подготовить публикацию нового СМД для стандартизации правоохранения. Это первая часть. И вот слушаю дальше. Вас прерывали.
Ну а второй частью, еще до статьи, давайте разделим публикацию и статьи. Еще до статьи выложить на всеобщее обозрение сообщества на нашем сайте, который CICDish, что у нас часть тоже появилась. Вот, может быть, кто-то придет и скажет, что какие-то важные бизнес-кейсы остались не покрытыми, что-то не предусмотрено и так далее.
Хорошо, давайте представим себе, в каком виде это может быть сделано. Я представляю себе профили. Новых у нас не появляется. У нас появляются примеры. Правильно? Примеры ресурсов, представляющие собой переложение примера из Send.
Так?
Это все, или еще что-то там появится?
Наверное, примеры ресурсов, да. Это будет на первый этап точно достаточно. То есть, если еще где-то получится XML исходного сэмпла разместить, будет вообще классно. Который, собственно, стал исходником для маппинга.
И в целом можно коммуницировать, что ну вот сейчас нам, например, на ИТМе покажут свежую статистику по количеству зарегистрированных СЭМДов, да?
Да.
Опираясь на это, то есть просто идти, вот там, не знаю, сейчас там топ-1 мы сделали за счет лабораторных исследований. Вот сейчас добавим амбулаторные приемы, осмотры, консультации, там будет топ-2. Вот. Посмотреть, что еще сверху? Чем сейчас реально наполняется ренд, и если это получится автоматизировать до какого-то уровня, то просто покрыть вот эти верхние, наиболее частые сэнды.
А дальше смотрите, 80% текущего объема сендов уже покрыто и может рассматриваться как альтернатива на файл. Если мы за счет 3-5 документов это сможем сделать, это будет прекрасно. Достаточно сильная позиция для того, чтобы ее брали, смотрели, прорабатывали.
Хорошо, согласен. Надо только это головокружение от успехов получить, потому что я сделал первый шаг. Это не законченная работа, надо ее завершить.
Да, нужно продолжать и завершить. Но идея, наверное, если мы в какой-то момент скажем, что 80 процентов сендов, которые сейчас регистрируются в Рэмде, мы уже проверили и есть их маппинги на файр, как их передать в виде firebundles, то, наверное, это может быть для какого-то разговора достаточно сильным аргументом.
Да, да, это сильная позиция.
Особенно учитывая, что ни финансирования, ни каких-то сверхресурсов мы не привлекали. В инициативном порядке, на собственном энтузиазме, сделали.
Да, что показывает, ну, иллюстрирует наш аргумент, что стандарт существенно снижает затраты отрасли. Да, что если вот такой маппинг делается в инициативном порядке без ресурсов, то, значит, какие-то работы по интеграции, вот они того же порядка тоже делают дешевле, чем делать с нуля. Так, принято. Все, ну тогда спасибо, у меня больше нету.
Здесь все сразу, пока в контексте. Более того, реализация интеграции с помощью различных кодовых ассистентов будет заметно проще, потому что примеров кода на FIRE они в процессе. Ну вот эти модели, на которых эти кодовые ассистенты сделаны, видели намного больше, чем пример от кода на CDA.
Это гипотеза, но я бы ее смягчил. Кодовые ассистенты достаточно много видели кода на FHIR для того, чтобы практически с первого раза давать хорошие результаты.
Ну, здесь, наверное, можно привести такой пример, что условно на Python кодовый ассистент вам намного больше ассистирует, чем если, например, вы соберетесь вести разработку с помощью кодового ассистента на 1С.
Просто в силу того, что доступная кодовая база Python для обучения всех моделей в основе ассистентов была намного больше, чем доступная кодовая база 1С. Не принижая важность в российской экосистеме, но ровно в такой же аналогии.
Есть знания, которые подпитаны большими экосистемами, есть локальные экосистемы. Естественно, чем больше примеров, тем лучше работают.
Это безусловно, это подтверждается тем, что когда я прошу своего кодекса что-то сделать, то он в терминах четверки делает просто с первого раза и все чистенько. В терминах пятерки он иногда ошибается, промахивается, потом говорит: "Ой, да действительно, это в пятерке, вот иначе надо". У него очевидно меньше базы.
Пять пока еще подтверждает, что база очень важна. Так что, тогда спасибо. Я предлагаю эту тему отложить до следующего раза. Я подготовлюсь с кем-то более завершенными результатами.
Хорошо, тогда в продолжение прошлого обсуждения с тем, где какие идентификаторы располагать банды типа документ для передачи сэнда. Прочитал комментарий кодекса, еще сам немножко поразмыслил. В общем, выглядит следующим образом.
Бандл типа document накладывает обязательное требование, чтобы единственный возможный identifier бандли был заполнен уникальным значением system.value. Да, это требование от самого стандарта. При этом в бандле типа document у нас может быть resource composition с неограниченным количеством идентификаторов.
И текущая позиция кодекса в том, что давайте располагать идентификатор конкретного экземпляра документа на уровне бандла, а в Composition располагать, собственно, идентификатор набора версий документа. Вот здесь, наверное, мое возражение было бы: либо давайте продублируем идентификатор конкретной версии документа еще и в Composition, потому что, условно, если вдруг возникнет сценарий, что этот Composition будет обрабатываться как-то отдельно, чтобы из него могли извлечь конкретную версию.
Это первый такой компромиссный сценарий. Либо более радикальный сценарий: сказать, что нет. И набор версий, и идентификатор конкретного экземпляра должны быть в Composition, а обязательный идентификатор в Bangle вообще должен быть заполнен уникальным гуидом, сгенерированным в момент отправки от одной системы к другой. Это более радикально еще вариант, поэтому его можно, наверное, к обсуждению. Но компромиссный вариант, что должен быть хотя бы продублирован в композицию.
Ваш аргумент такой, что если эта композиция будет обрабатываться отдельно от остального бандла, остальных ресурсов бандла, то нам в нем потребуется идентификатор экземпляра документа. Важно разумно в нем.
Иметь, да, это просто будет удобно, вот.
Даже тогда, я хотел бы обсудить на самом деле единственный главный аргумент кодекса, который он тут приводит. Он приводит цитату из документации фаера. Давайте мы не посмотрим.
в
Composition Identifier прямо определен как документ, сохраняющийся при изменении версии и сопоставлен с CDA в SetID.
А я, кстати, не очень понимаю. Вы смотрели эту спецификацию? Давайте сейчас посмотрим.
Потому что звучит странно. Вот это высказывание звучит странно, потому что это множественный идентификатор. А значит, к нему не могут быть единым образом применены вот такие требования.
Давайте посмотрим.
Сейчас потратим еще немножко времени.
Нет, секундочку. Возможно, какие-нибудь дополнительные требования? Дополнительный?
apm да требуется дополнительные прекрасно да композицию.
Тут
Написано, что это версия индипендент.
Нажмите на identify, не на тип данных, а который в дереве. Да, здесь будет страничка с расширенным комментарием.
Вот.
Удивительно. Да, действительно, это написано и сопоставлено с этой идеей. Но удивительно, что у него кардинально стоит на звездочках.
и
Это бизнес-дискуссию дольше, но, видимо,
Не одним вы столкнулись. Кто-то еще? Ну,
Это звучит как не совсем наша тема: ресурсы, бизнес.
Но вот здесь мне больше нравится предложение, что этот идентификатор остается константным, в то время как композиция меняется во времени.
Верно, и тогда это серия только.
Да. Вот это, наверное, звучит как то, что кодекс разобрался в свеке стандарта лучше меня. Ну что ж, и такое тоже возможно.
Он был не один. У него там за спиной стояли много людей, которые что-то писали, а он это прочитал. Вот. Возможно, они как-то интерпретировали.
Так, а в дискуссии что?
В дискуссии о бизнес-идентификаторах. Но про то, что это не GUI серверы, это как бы другая сторона вопроса. Так.
ну
Нам остается согласиться с кодексом.
Получается, что да, это прям явное ограничение.
Если не появятся дополнительных альтернативных точек зрения, то, наверное, на текущий момент можно решение принять. А дальше будут у коллег аргументы. Вот, наверное, можно вспомнить о том, что бандлы типа «документ» должны храниться именно бандлам, а не набором отдельных ресурсов. Где-то такое пожелание когда-то проскакивало, и не пожелание, а требование.
Поэтому возможно, что конкретный экземпляр версии, ID-шник экземпляра мы не утеряем, потому что сам бандл будет тоже храниться, будет оберткой.
Получается, что, смотрите, сейчас, если вернуться к сути вопроса, вы говорите, что если композиция кем-то рассматривается отдельно от бандла, то в нем имеет смысл тоже хранить идентификатор экземпляра.
Но внутри кондишена находится только перечень ссылок на конкретные элементы документа, на ресурсы, которые входят в этот документ. Верно?
Ну и какое-то текстовое наполнение, которое соответствует идее второго уровня.
Ну окей. Текстовое наполнение.
В принципе, текстовое наполнение, конечно, уже тоже информация. Но если вот сейчас отложить в сторону вопроса текстового наполнения и поговорить именно о самих ресурсах, то когда экземпляры ресурсов меняются, выпускается версия. Экземпляры ресурсов меняются, содержание композиции тоже меняется, верно же? Там будут ссылки на другие экземпляры. То есть у этого composition тоже версия будет другая, а идентификатор будет, то есть содержание у него будет другое, а идентификатор.
Его будет тот же. А давайте откроем сейчас сам composition и посмотрим. Там, по-моему, должен быть явно атрибут для версии. Может быть, сейчас там и картинка сложится здесь.
Да, контент, конечно, есть вершин.
Ну вот, картинка замкнулась. Версия выделена отдельным атрибутом.
Дело вот в чем. Кажется, не всегда соответствует бизнес ведению, потому что версии часто номеруются просто номерами. Или вот сюда и надо вписать вот этот идентификатор версии?
Нет.
Смотрите, есть два способа идентификации конкретного документа. Ты делаешь идентификатор серии, и внутри серии ты пишешь номер версии. И этот номер не уникален глобально: один, два, три, четыре, пять. Либо ты делаешь уникальный идентификатор версии документа. Глобальный, уникальный. Здесь поддержана таким образом получается только идентификация.
Серийный номер версии или номер версии.
Именно так выглядит. Именно так, так то.
Есть, если я идентифицирую то и то, и то, то у меня здесь некуда. Этой ситуации не поддерживают.
Почему? Мы можем положить сам бандл. При этом нужно явно требовать, чтобы он был типа документ. Тогда его будут обрабатывать по соответствующему правилу, как единый взаимосвязанный пакет, не разрывая на отдельные экземпляры ресурсов.
Для бандлы типа документ может быть такое представление. Оно не обязательно такой, и оно, если у него что, если у него тип, если тип соответствует, то проверяй такой.
Да, это прямо записать как требование, что вот для send в бандле типа документ экземпляр id экземплярах должно быть записано в.
Идентификатор bundle. Смотрите, вот это сопоставление. Так вот, сейчас это и сделано. Формально описать средств невозможно, потому что кардинальности яичка и применено такое условное ограничение, что если тип не с документ, то система должна завершаться 51. Ну, или может быть подробнее.
Написать constraint.
Наверное, надо дожать описание. Здесь нет фишевого текста, и поэтому плохо видно. Неудобно смотреть на текст ограничения.
Так, я записал себе.
В бандле дописать в преамбула фиш-текст.
хорошо
Да, но получается, что то, что вы сказали, сейчас реализовано. В принципе, если он такого типа, а надо еще для композиции, то как это сделать? То есть вот это условие: просто если тип идентификаторами из документа или тип идентификаторами из документа и бандл типа композиция.
Мне кажется, достаточно будет только индикатор из документов.
Так. Спасибо.
Ну, в целом, выглядит как будто бы все.
Есть ли у вас камера, сэр?
Да, сейчас, секунду.
Пробуем.
Так, почему-то не активируется. А вот сейчас?
Чёрная карта.
О, всё. Есть. Хорошо.
Всего тогда. Спасибо. До будущих встреч.
Всего доброго.
