Протокол: обсуждение типизации идентификаторов и публикации implementation guide

Олег, привет.

Да, Евгений, добрый день.

Так, ну что, наши свои планы по ИТМу не реализовались?

Да, я так не добрался до него. Задержался в командировке, а потом что-то много было. Но, судя по некоторым обручкам фотографий, было интересно.

Да, да, было интересно. Секция была не два часа, а два с половиной. Народ не мог разойтись и перестать дискутировать. Вот, так что было. Ну, может, наверное, она записывалась. Можно, наверное, послушать.

Ну, да, да. Я надеюсь, что через какое-то время это выложат. Обычно они выкладывают все записи.

Вот. Да, меня, конечно, сильно отвлекло. Ну, все-таки это выставка. Какой крючок, я довольно мало успел сделать, но кое-что сдвинуло по решениям прошлой встречи. Сейчас могу указать. Да, теперь делает такой файлик вот, в виде проекта протокола совместной встречи получается.

Вам кодекс прям к повестку встречи готовит?

Да, конечно. То есть, он это синхронизировано. Я говорю: "Прошла встреча, иди посмотри решения, попробуй их реализовать, что надо, спроси".

Он обсуждает со мной эти решения, как там реализовать. И у него в инструкции стоит, что когда он реализует, то он вписывает это в протокол следующих встреч в проект, с тем, чтобы мы могли обсудить прям со ссылками, что он сделал.

Предыдущую встречу вы ему отдаете как YouTube запись?

Нет, нет, нет. Здесь все-таки еще недоавтоматизированная. Я ему отдаю городовский протокол встречи с решениями. Ну вот, как они опубликованы на YouTube. И у него написано, что если в решении написано Cogon, то делай. Если не Cogon, то игнорируй.

Прекрасно. Ну, ладно. Здесь, наверное, можно поблагодарить OpenAI и другие лаборатории за поддержку.

Да.

На нашем нелегком пути.

Просто мощная поддержка, безусловно. Причем я ни разу не наблюдал галлюцинации, ошибки в ссылках и прочее.

Сейчас уже очевидно совершенно, что это не просто запросы моделей, это множество агентов, которые друг друга проверяют. Так, значит, он заявляет, что он восстановил корень имени здрава. Вот давайте для надежности проверим что-нибудь насчет у пациента. Корень здрава должен быть, ну например, идентификатор пациента в миссии идентификация. Вот. Индикатор пациента в экземпляре МИС находится вот так. Рукор проверяет.

А вот комментарий он не исправил. Посмотрим, исправил ли он вариант. Вы умеете читать такое?

Нет, это лучше. Можно даже прям в режиме чата скормить нейронки, пускай она расшифрует этот RegEx. Они всегда выглядят как некая древняя магия. Лучше скормить любой нейронке, можно прям в режиме чата объяснить, как он будет проверять. Но в целом выглядит...

Нет, я не вижу.

Мы не видим констант Мездрава.

Да, констант Мездрава.

Должен быть все-таки 1.2.643.

Может быть, он просто не вынес вот этот фиш-текст, не переписал. Врач. Мисс Патиент. Вот. Мисс Патиент. Так. И как здесь должно быть отображено? Систем. Так. А где должны быть написаны инварианты вот в таком представлении?

В таком представлении, да, они ниже. Там в дереве только восклицательные знаки.

Но это только последний пассет.

Выглядит так, что ничего не исправилось.

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

Мы с вами решали, что мы с вами напоролись на идентификаторы подразделения по формулам. Помните? Когда разбирали аблатурный сэнт, мы напоролись на идентификатор подразделения и написали, что может быть такой срез этого идентификатора. Ну, решили написать, что должен быть такой срез идентификатора, который ссылается на соответствующий справочник в составе формулы, справочник подразделения. И нам надо было как-то его идентифицировать. По системе, по типу. Этот вопрос как-то остался подвисшим. Мы с вами решили, что это будет по типу.

Но при разборе выяснилось, что нарезка вообще идентификаторов пациента происходит по системе сейчас. Ну вот там ИНН, документы, удостоверяющие личность, там все такое. Я с ним стал это дело обсуждать, и снова вернулись мы с ним к спецификации Файеровской, где написано, что типы предназначены для широкой классификации. Какой смысл этого идентификатора? Он страховой или он там группу каких-то идентификаторов смысловой описывает? И что если это один конкретный систем, то так использовать не надо.

Поэтому у меня вопрос. Не следует ли, скажем, оставить нарезку по системе, но сделать два разных система для...

Организации и для подразделения. Но смотрите, на уровне... Еще буквально одну.

Кусочек фразы в догонку. И сделать, например, тип под названием "фрмо" в целом. Когда мы тем самым передаем, что мы идентифицируем по "фрмо", а какое конкретное пространство этих кодов, это будет зависеть, ну, какое надо использовать пространство кодов, зависит от типа этой организации.

Доклад закончен, вопрос закончен.

Так, давайте смотреть. Значит, у нас есть Firmware, целая подсистема в рамках EDZ. У нее есть API, но эти API доступны только тем, кто подключен к EDZ, и то там, в каких-то объемах. Да, мы сейчас все регламенты подключения MIS-ов и иных систем к EDZ, мы, наверное, не охватим. И все нюансы.

Однако, для нашего с вами удобства, ИСОФРМО делается каждую ночь выгрузка. Обновляется справочник, который точка 1461. Это перечень всех медицинских и фармацевтических организаций на 100 тысяч записей. И, скорее всего, должен обновляться справочник подразделений. Я не знаю, происходит это или нет, это надо отдельно исследовать. Но у него точно также есть свой OIT, вот как у справочников медицинских и фармацевтических организаций .1461, там тоже какой-то OIT есть. Да, он может быть не в основной ветке NCE, а в ветке дополнительных справочников, но это не принципиально для нас.

Нам нужно понять, насколько он вообще обновляем. То есть можем ли мы считать, что он поддерживается актуальным, или на него опереться здесь нельзя. Вот. Есть ли SEND? На него ссылается, да, то есть дает ссылку на вот этот OID этого справочника, то, скорее всего, проектировщики SAMD рассчитывали, что он обновляется. Поэтому, наверное, такое допущение можем принять и мы, вот, и тогда просто вот этими двумя OID-ами различать.

Ну, или не OID-ами, да, если мы OID-ы завернем в наши Naming System, FireRoot. Вот, а выдадим человека, читаемого Юри, то пускай будет человек, читаемый Уру. Вот, в котором внутри, в namesystem будет торчать код справочника NCE, который по факту является еженочной выгрузкой FMO. Вот, наверное, не вижу препятствий, кроме того, чтобы проверить, точно ли это работает. Вот. То есть найти этот справочник, открыть его паспорт, открыть его историю версии, понять, что он обновляется, кто ответственен и так далее.

Тут бы я разделил вопросы о фактическом обновлении и включении в Rucore, потому что мы включаем Rucore на том основании, что спецификация SEMD этого требует.

А поскольку SEMD весьма распространенная в России штука, то мы в Rucore показываем, как именно это нужно сделать, если делаешь файл. Вот и все.

Кажется, что ответственность за поддержание актуальности этого кода не относится к ответственности рукора.

Хорошо, но тогда, наверное, нам точно нельзя его загнать в обязательное, этот слайс. То есть его оставить просто как... Никакой слайс. Просто как возможный.

Да, в этом смысл всех наших слайсов. Ну, для подразделения это еще и потому так, что разработчик в праве передать главную организацию, а в праве передать подразделение в зависимости от смысла передаваемого. Обязательности здесь никакой быть не нужно.

Но это общее правило, и в прочих всех слайсах на уровне РУКОРа обязательности я не ставил нигде и везде старался проверять, потому что только конечная спецификация определяет, как в этом процессе такого рода информация приходит, какая является обязательной.

Однако в вашей речи вы не затронули другую часть вопроса. Следует ли дополнить справочных типов идентификаторов?

В целом, не возражаю, но для индексации все равно будет использоваться пара System WebView. Это может поднять, наверное, человекочитаемость какую-то. Именно человекочитаемость.

Когда аналитики, разработчики, может быть, агенты будут разбирать смысл всех спроектированных слайдов, для них вот эта типизация может более ясно прояснить его смысл и назначение.

В остальном случае вот именно индексация ресурсов, она будет сделана по system value и технологически, наверное, не принесет никакой выгоды добавление этого типа. Читаемость повысит, это точно.

Хорошо. Тогда мы можем принять решение: делать или не делать. Умолчания всегда сложно не делать, если есть сомнения. Или, может быть, подождать какого-то реального премьера.

Давайте подождем. На него точно именно технологическая логика не завязывается. То есть я сейчас вижу, как удобство восприятия, как бы пока это гипотеза. Не некому нам сказать, что да, стало удобнее. Тем более некому это сделать статистически значимое количество раз, независимо от предыдущих оценок.

Хорошо, все, тогда с этим решили. Теперь следующий содержательный вопрос. В какой-то предыдущий раз мы предполагали начать публиковать вот эти решения по маппингу, которые образуются для аблатурного сэнда. Они не доделаны все до конца, но многое сделано, поэтому мы решили как-то опубликовать это на сайте.

Я стал думать, как и пришел к вот такому предположению, что на самом деле речь идет про Implementation Guide. Несмотря на то, что мы вроде почти напоролись на необходимость расширения, сейчас, кажется, вообще ни одного нет. Но мы же должны включить Mass Support по тем атрибутам, которые вошли в спецификацию.

И, возможно, спецификация определяет некоторые жесткости, дополнительные ограничения кардинальности. То есть, все равно нужно публиковать эти профили, к ним будут примеры. И это, на самом деле, implementation guide. Верно я рассуждаю?

Ну, наверное, да. То есть, в целом, тогда каждый send, переложенный на fire, будет сопровождаться своим implementation гайдом. Наверное, в целом это удобно для какого-то там распространения.

Просто указываешь, на какой implementation гайд, какой vrcity нужно посмотреть, если ты хочешь замапить, ну, там, разобраться с маппингом на fire такого-то send, такой-то версии SEMD.

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

Но и стандартный паблишер, наверное, будет работать.

Стандартный, да, именно об этом речь. То есть просто мы выражаем наши мысли в виде стандартных профилей, со стандартными примерами к этим ресурсам.

И он их собирает, стандартный паблишер, собирает это в сайт. Хорошо, как гипотезу тогда принимаем эту, я пробую реализовать. И мы смотрим результаты.

У меня, к сожалению, все.

Ну, учитывая, какая была предыдущая неделя, мы вполне продвинулись. Вот у меня тоже на сегодня нету чего-то для доклада.

Давайте попробуем, насколько получится собрать, и насколько он заверстает, будет там понятен сайт. Если его получится выложить, можно будет даже ссылку в телеграм-чат кинуть.

Может быть, какая-то обратная связь придет из тех, кто в практическом плане уже был вынужден поработать с ЭМДами и с FHIR, например.

Ну да. Вдруг такие найдутся.

Ну, как-то так.

Хорошо, тогда спасибо. Двигаемся дальше. Можете, пожалуйста, включить камеру.

А я сегодня без, поэтому воспользуемся яркой АВ-атакой.

Хорошо. Всё, тогда спасибо большое.

Всё, на связи.

До следующей встречи.

Всего доброго.