Протокол обсуждения: валидация идентификаторов SEMD и логика диагнозов (Encounter)

Добрый день, хорошо слышно.

Давайте начнем с моей части, она коротенькая. Я должен был реализовать слайс практически на роли для сэмда и описать там этот вариант. Я сам еще не смотрел и сделал только что. Понятно, что делал не я. Сейчас мы с вами посмотрим. Значит, вот версия опубликованная 0.15. У него в корпоративной роли написано, что было такое бизнес-требование передать локальный идентификатор по правилам SEMPT и определенный вот такой срез MISS практически ROLL. Вот этот вот фиш-коди он написал, вот такое identifier открытый, может быть много их. Непонятно, почему это, наверное, неправильно. Или тут имеется ввиду, что их вообще много. И вообще идентифайер 0 звездочек. Да, вот. И содержит в том числе вот такой, да, в open режиме. Так, видимо, читать надо.

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

Подпишу вопрос. Теперь все остальное он не менял, и вот он добавил инвариант вот здесь. Здесь, наверное, ключевое это 70 в конце.

Да, но естественно, что регексы на глаз не читаются. Попробовать взять этот регекс и каким-нибудь онлайн-валидатором вот с этим регексом повалидировать тупо примеры из сендов, в том числе из примеров руководств по СЭМДУ.

Здесь мы видим, что 70 на конце – ок, то, что хотелось. Но надо проверить, что хотя бы примеры из руководств по СЭМДУ нормально провалидирует этот RegEx.

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

Пример медицинского работника. Доктор Смирнов. Это практишнер. Роль медицинского работника. Вот.

Пример Смирнов терапевт. Идентифайр. Вот он добавил какой-то идентифайр 1.1.70.

Окей. Похоже. Единственное, что… 1.1.77 – это фасед Москвы. Я не вижу фасед-то медорганизации. Обычно какой-то достаточно длинный, может, даже четырёхграничный. А после него уже идёт фасед-100, который для сэндовских сущностей.

Проверим.

Да, наверное, вот здесь стоит глянуть.

Так, тогда я себе записал, что мы провалидируем примеры из руководства SEMPF. Вот, и заодно посмотрим в этих примерах, что есть правильные данные. Тогда решение наше — мы распространяем эту практику на другие идентификаторы, но.

Не вижу оснований не сделать этого.

Я могу я сначала пока отложить эту спорную историю про амбулаторный случай, который понятно, что ставить.

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

При этом, хорошо, у меня все. Доклад закончен.

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

То есть, вы предлагаете, вот после этого будут оформлены эти слайсы идентификаторов? У меня пример это есть только CDN.

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

Значения вот этих идентификаторов, которые нас интересуют, как мы пытаемся проверить?

Да.

Как идентификаторы у нас возьмутся? Окей.

Особенно будет, конечно, интересно. Вот не самый простой пример: идентификатор сотрудника, а вот там, где номера карт, случаев, вот эти. Скорее всего, там будет больше специфики.

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

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

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

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

Да, виден.

Ну, вот это то, что еще мы делали на предыдущей итерации в рамках клинической группы. Как структурируется диагноз на базе условно-методических рекомендаций, потому что в Екатеринбургских нормативных документах это не описано. Вот, это был VIEW, собственно, из 2021 года. Принципиально, сейчас я посмотрел текущее состояние справочников Минздрава, которые, в том числе, используются в СЭМДе. Например, вот такой, если тут глянуть, то из того, что интересного, но у них добавились внешние причины заболеваемости и смертности, они в данном случае, наверное, нам не так актуальны.

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

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

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

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

И здесь мы можем перейти, собственно, посмотреть, что изменилось в бизнес-логике 2021 года и что изменилось в логике ресурсов. Сейчас показываю параллельный просмотр. Вот у нас пятая версия. Вот 4b, которая была на момент тех обсуждений. И это encounter ресурсы. Здесь у нас появляется элемент диагнозис. А вот он в пятерке. И вот он в 4b.

Собственно, разница в том, что у нас теперь в рамках каждого объекта внутри массива объектов диагнозис возможно как ссылка, так и непосредственно записанный код. Это упрощает для тех, кто не хочет создавать отдельный resource condition. Мы здесь можем предусмотреть указание кода и текста прямо внутри энкаунтера. В 4b нам обязательно пришлось бы создавать condition и делать на него отдельную ссылку.

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

Что мы потеряли? Мы потеряли один элемент, который был 4b и который сейчас в рамках пятерки недоступен. Для каждого объекта 4b был предусмотрен некий ранг, то есть мы могли положительным целым числом выразить порядок этого диагноза в его структуре, тем самым показав, какой из диагнозов является первым основным. Это было удобно, но если вот вспомнить логику, которую мы проговаривали еще вот на этом моменте, вот здесь при правильной рубрификации, если методологически правильно подошли на момент составления документа, либо описания случая, то основное заболевание, оно исходно было одним всегда.

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

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

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

Все необходимое для реализации текущей логики SEMDA уже есть в пятой версии, которая слева. Здесь можно заметить, что у нас есть некий preferred value set от самого стандарта, но его наполнение совершенно недостаточное, поэтому мы все-таки добавим несколько своих велюсетов на каждую из возможных осей классификации. То есть одна ось по этому справочнику, одна ось по этому.

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

Вы выпадали, или я выпадал? Так, я выпадал, наверное.

Да, про Preferred Value Set.

Про Preferred я слышал, да.

А, собственно, он нас, к сожалению, с наполнением из двух... Да, он нас не устраивает. Не устроит, поэтому мы берем мензураловские справочники, которые и так используются в Send, и подключаем их в качестве двух осей классификации в рамках Use.

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

Вот, опять же, можно его проиллюстрировать каким-нибудь примером из вот тех документов, которые я подсвечивал. То есть написано: «Эпикриз, протокол консультации, протокол лабораторного обследования».

Вот, на этом, наверное, свой доклад закончил. Вот, если нет возражений, предлагаю вот эту вот часть включить и продемонстрировать реализацию.

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

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

Здесь, смотрите, у вас

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

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

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

В FIRE есть такая в Condition, в самом Condition есть такой нумератор степень подтвержденности. Если вы сейчас откроете в Condition.

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

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

Давайте возьмем наши ресурсы. Да, здесь, конечно, есть и клиниковый статус, и верификационный статус.

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

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

А это судмеддиагноз, патологоанатомический диагноз. То есть ты можешь их между собой сопоставлять в целях экспертизы какой-то. Верно ли, что этот смысл следует вносить в encounter diagnosis?

Значит, почему предлагаю вносить? Если мы посмотрим комментарий, admission, discharge, нам как раз намекают диагноз при поступлении, диагноз при выписке.

Ну да, они прямо это пишут.

И если мы смотрим на наполнение вот этого Preferred Value Set, то здесь как раз рабочий заключительный. То есть, как будто бы они в первую очередь думали о вот этой оси, а уже мы в первую очередь подумали о основных и сопутствующих. Я бы вот так сказал. То есть, как будто бы рабочая группа самого стандарта думала в первую очередь про вот эту ось, а это мы подумали про основную и сопутствующую.

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

Я бы, наверное, предложил какую-то логику. Вот этот справочник считать, или, возможно, его альтернативу. То есть, может быть, я посмотрю, может быть, в НСИ и в документах есть какая-то еще альтернатива этому справочнику. Считать необязательным. То есть, его мы простилируем, но не делаем обязательным для использования.

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

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

Хорошо. С этим вопросом понятно. Разобрали. Спасибо.

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

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

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

Понятно. Ну и она не выжила, и вообще нет оснований стремиться к моделированию.

Ну, если посмотреть, на самом деле выжила. То есть мы смотрим вот здесь. Condition и Code Double Reference. Они предлагают, если состояние после, то указать пример через кодирование по справочнику.

Должно быть сформулировано состояние. Так, с этим ясно, тоже спасибо.

И следующий вопрос про... Ну, соответственно, если вдруг предполагается прямое кодирование, чтобы сюда что-то напрямую внести, то список справочников пока я бы предложил не жестко регламентировать. В качестве примера взять МКБ-10. Это наиболее частый.

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

Мне близкие темы уровней токсичности химиотерапии, токсических эффектов после химиотерапии. Вот тот захочет вот это вставить, так и вставлю.

Я поддерживаю полностью, потому что в узких областях, как то, что вы упомянули, или я в психиатрии, сталкивался с необходимостью какого-то многоосилового диагноза. Профессиональная литература требует от них. Так что да, ограничивать не будем.

В МГБ-10, конечно, нельзя. Тогда с этим вопросом про процедуры тоже все. Спасибо.

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

Гипертоническая болезнь и хроническая сердечная недостаточность.

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

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

Сейчас я саму мысль попытаюсь выразить. Значит, если мы сейчас не сделаем ран, а ограничим единственным основное заболевание, то мы вот эту коллизию не сможем разрешить. Я верно понимаю?

Наверное, честный ответ: не знаю. Мне кажется, что где-то там на уровне порядка оказания, ну если мы где-то действительно, вот кардиологический кейс, где-то на уровне порядков оказания помощи взрослому населению по профилю кардиология, либо в клин-реках на гипертоническую болезнь и ее осложнения должны быть данные разъяснений.

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

Олег, я как аргумент, наверное, бы скорее не принял то, что вы сейчас сказали. Потому что мы делаем базовый core. И на уровне, например, send мы можем ужесточить и сказать, что основное только одно. А на уровне, например, базового core основное и не одно. Ничего в этом нет. Странно.

Хорошо. Возможно, действительно, то есть совместимость с Send хороша, но она должна быть сужением к профилю Encounter Send, а не на уровне Encounter Core. Правильно понял идею? Но то есть Encounter Send может быть более узким и более жестким, чем Encounter Core. И вот эту логику, более строгую, нужно отнести на уровень Encounter Send в профиле.

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

Хорошо, то есть все-таки extension для рейтинга, который был атрибутом в R4, мы сохраняем и добавляем.

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

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

Все у нас закончились.

Наверное, можно попробовать собрать требования и пару примеров.

Супер, давайте мы так и сделаем. Как вы относитесь к идее, если это сделаете вы?

Ну давайте проэкспериментирую. Мы же хотели. У меня были проблемы на уровне подключения к репозиторию, что я руками вливал в прошлый раз. Вот заодно попробую их порешать.

Да, попробуйте. Если что будет не так, вы можете мне присылать. Я бы помнил техническую функцию по заливке.

Хорошо. У нас, кстати, если посмотреть на репозиторий... секунду, обратил внимание так.

Прошу прощения, 10 копий разных рукоров, который с большой буквы, рукор айджи, а выбросом. Хотите? Да, да.

В общем, в каком-то из репозиториев, в качестве авторов, я, вы и CursorAgent.

Серьезно? Ничего себе!

А я думаю, руку Raiji это и есть.

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

Да, все верно.

CursorAgent. Странно, у меня давно не курсор.

Это я экспериментировал с курсором. Есть официальный соавтор, контрибьютор.

Хорошо, в общем, я попробую вот это, о чем договорились, превратить в требования к профилю примера и влить сюда.

Вот, наверное, у меня на этом все.

Хорошо, спасибо. Я вот такую фотку сделал в качестве аватарки нашей встречи. Так,

Ладно, тогда всего доброго.

Всего доброго. До вечера, правильно?

Да.