Данный документ есть подборкой типовых вопросов, которые нам доводилось слышать от пользователей, и ответов на них. Мы исходим из того, что раз уж какие-то вопросы задаются регулярно - то значит, либо ответы в документации отсутствуют, либо сформурированы недостаточно внятно, либо бывает неочевидно, как ту или иную описанную возможность можно применить в конкретной ситуации. Потому здесь мы попытались формулировать ответы максимально близко к тому, как нам это приходилось делать по телефону или при устном общении, и надеемся, что диалог в режиме "Вопрос-Ответ" позволит ликвидировать некоторые пробелы документации.
Вопросы пока что не структурированы. Просмотрите список вопросов, если ответ на какой-то из них Вас заинтересует - ткните в вопрос мышой.
Почему не совпадает количество умерших до одного года, подсчитанное в разных таблицах ОНКа? (новое)
Как получить список пациентов, подсчитанных в ту или иную клетку таблицы?
Что считается визуальными локализациями и запущенными формами в популяционном регистре?
Что есть "баланс" и как с ним "бороться"?
# # # # #
Не совпадает количество умерших до одного года,
подсчитанное в разных таблицах ОНКа:
количество больных, полученное при подсчете в onk.exe таблицы формы
35 "Сведения об умерших от злокачественных новообразований"
по интервалам в графе "Из числа впервые взятых на учет в
предыдущем году умерло до 1 года после установления диагноза",
не совпадает с количеством больных, полученном при подсчете таблицы
"ПОКАЗАТЕЛИ" - "СМЕРТНОСТЬ" -
"Абс. число умерших ф.35 (уточненное) по регионам (от локализации) "
в графе "Из числа впервые взятых на учет в предыдущем году умерло
до 1 года после установления диагноза" за тот же интервал.
В таблицах "ПОКАЗАТЕЛИ" - "СМЕРТНОСТЬ" -
"Летальность до года по регионам .... "
показатели в процентах вообще ничему не соответствуют. В чем причина?
Ответ: Для корректного подсчета "умерших до 1 года" нужно пересчитать таблицу формы 35 за 2 года: текущий и предыдущий. Но без ошибок может быть подсчитана только годовая таблица; при подсчете интервальной таблицы правильный результат получить невозможно.
# # # # #
Как получить список пациентов, подсчитанных
в ту или иную клетку таблицы?
Ответ: Во-первых, получить такой список можно не для всего подряд, а только для таблиц (т.е., матриц с абсолютными значениями, а не показателями!), которые считаются по данным картотеки, а не на основании данных из других таблиц (а то и вводятся вручную). Статус таблицы виден в меню выбора матриц. (Для того, чтобы узнать, из-за кого получилась то или иное число в производной таблице или показателе, нужно искать соответствующую клетку в исходной таблице.) Если эти условия выполняются, то воспользуйтесь опцией "Список" меню "Параметры" программы подсчета таблиц. По F4 добавьте строку (можно несколько), укажите там ячейку таблицы или подтабличное и имя файла для получения списка (без расширения и русских буковок!). После этого обязательно запустите подсчет таблицы. В результате получается список идентификаторов, который можно просмотреть в Поисковой системе, распечатать или использовать как Входной файл для какого-то еще поиска или подсчета таблиц.
Во-вторых, совсем не факт, что в таблицу идут люди. В Форму 7 или таблицу качества данных идут случаи, а в таблицы стационара вообще могут идти разые эпизоды - госпитализации, пребывания в отделении стационара, лечения... Следите за типом объектов, по которому считается матрица. Для каждого типа списков, когда будете его в Поисковой системе просматривать или печатать, нужно выбирать соответствующий сценарий. При необходимости можно преобразовать список с помощью опции "Список другого формата".
Об этом (и о многом другом) рассказано в книгах "Таблицы канцер-регистра" и "Тайны и загадки поисковой системы канцер-регистра".
# # # # #
Можно ли работать со списком,
полученным по клетке при подсчете таблицы Формы 7, прямо в программе ввода Х30?
Да, можно. Но, так как это - список случаев, его предварительно нужно преобразовать в список пациентов. Это можно сделать Поисковой программой или в программе Х30 (пункт "Список", "Преобразование случаев").
# # # # #
Что считается визуальными локализациями и запущенными
формами в популяционном регистре?
Вот что считается сейчас визуальными локализациями согласно нашим программам:
C43.*-C44.* (кожа)
C50.* (МЖ)
C00.*-C10.* (губа, полость рта, ротоглотка, слюнн.железы, миндалины)
C21.* (анус)
C51.*-C53.* (вульва, влагалище, шейка матки)
C60.* (яичко)
C62.* (пол.член)
C63.2 (мошонка)
C73.* (щитовидка)
C69.* (глаз) - исключен из Списка визуальных локализаций после долгих и продолжительных консультаций, последним распоряжением Минздрава, октябрь 2005 г.! Отражено в версии популяционного канцер-регистра 3.13 и выше.
Запущенными формами ЗН сейчас считаются следующие:
# # # # #
Как определяется первичный больной в популяционном регистре?
Есть ли отличия между первичным больным и первичным случаем заболевания?
Ой, долго рассказывать в деталях... Общий принцип определения "первичности" больного в форме 35 здрав: год учета первого диагноза больного равен году установления упомянутого диагноза. Таким образом, могут быть больные, которые не были "первичными" ни в одном году. В прошлом о нем еще не знали, а в этом году он уже не первичный. Это - нормально. Есть форма 35 здрав уточненная, где год учета игнорируется. В форме 7 со случаем заболевания все обстоит точно так же: год установления диагноза должен быть равен году взятия на учет; и тоже есть форма 7 уточненная, на год взятия на учет не глядящая (зато следящая, чтобы диагноз впоследствии не был снят). Но нужно помнить, что в форме 7 будут учтены и повторные диагнозы, т.е. установленные у не первичных больных.
# # # # #
Что есть "баланс" и как с ним "бороться"?
Баланс есть древним изобретением МинЗдрава и рассматривался как средство контроля годовых отчетов. Дело нужное и полезное, однако с тех пор, когда таблицы Годового отчета начала считать машина, выяснилось, что в жизни существуют абсолютно неописуемые (однако реальные!) ситуации, далеко выходящие за пределы фантазии авторов формул баланса. Поэтому в процессе многолетних модификаций как наших программ, так и министерских инструкций, число ситуаций, на которых реально можно счесть баланс, неуклонно сокращалось.
На сейчас, единственная известная мировой науке формула схождения межгодового баланса содержится в Письме Центра мед.статистики МинЗдава от 27.06.2001 №МС-01/85 за подписью М.В.Голубчикова, адресованном Главврачам облонкодиспансеров, начальникам областных центров мед.статистики и зав. оргметодотделами областных больниц. К сожалению, Национальный канцер-регистр Украины не числится в адресатах этого письма, потому о его существовании и полном тексте мы узнали уже в процессе подготовки отчетов. Поэтому данные комментарии и дополнения в программе появились только сейчас.
Согласно Письму, в алгоритме межтабличного контроля контингентов на конец отчетного года (т.н. "межгодовой контроль ф. 35-здрав") нужно придерживаться следующих правил:
Т. 2100 стр. 1 столб. 6 ("Всего состоит на учете на конец отчетного
года)
=
Т.2110, гр. 9 (Подтабл."Состояло на конец прошлого, т.е. начало текущего
года" )
+
Т.2100, стр.1, столб. 1 ("Первичных)"
+
Т.2110, гр. 7 (Подтабл."Взято на учет с диагн. установленным ранее , или
с прошлых лет")
-
Т.2110, гр. 1 (Подтабл."Выбыло из р-на деятельности")
-
Т.2110, гр. 2(Подтабл."Диагноз не подтвердился")
-
Т.2110, гр. 3(Подтабл."Снято с учета лиц, о которых не было сведений в
теч. 5 лет")
-
Т.2110, гр. 8(Подтабл."Снято по другим причинам")
-
Т.2200, стр. 1 столб. 1+2("Умерло в отчетном году - М + Ж")
+
Т.2200, стр. 1 столб. 3("Из числа умерших НЕ состояли на учете")
-
Т.2200, стр. 1 столб. 7("Умерло от др. причин из числа состоявших на учете")
-
Т.2210, стр. 1 гр. 2(Подтабл." Умерло в предыдущие годы, снято с учета
в отчетном году")
ВСЕ. Данные правила выглядят достаточно логичными, и нам пока что не удалось
придумать реальной ситуации, в которой бы полностью удовлетворялись условия
контроля данных Х30 и правила регистрации, но тем не менее не сошелся бы баланс.
Если Вам встретится таковая жизненная ситуация, т.е. карточка, нарушающая данную
формулу - СРОЧНО ВЫШЛИТЕ ЕЕ НАМ.
Далее. Что значит "Сходится баланс"? С точки зрения компьютера, это значит, что если ЕДИНОМОМЕНТНО пересчитать таблицу контингентов отчетного года (например, 2001), и таблицу предыдущего года (2000), то после выполнения вышеперечисленных арифметических операций мы получим верную цифру. Если не получим - что ж, вот все карточки перед нами, мы ищем тех больных, которые нарушают баланс, и исправляем в них ошибки. Нормально. Но, с точки зрения Министерства и Облздрава, в качестве таблицы предыдущего года мы берем не то, что пересчитали сегодня, а то, что сдали в министерство год назад!
В чем же может быть разница "прошлогодней" таблицы и свежепересчитанной? А во всех тех карточках, которые появились либо исчезли в базе данных за год работы и при этом как-то касались данных предыдущего года. Идиотскую ситуацию типа "их съели компьютерные вирусы" рассматривать не будем. Будем иметь в виду, что в процессе работы постоянно встречаются ситуации - ошибки, опечатки и т.д. - которые касаются прошлогодних данных и подлежат простому исправлению. Самая массовая (и доходчивая для министерства) операция - чистка дубликатов. Выявленный дубликат - это не больной, который "выехал", "снят с учета" и тому подобным легальным образом отражается в таблице. Это - недоразумение! Которое подлежит удалению сразу в момент выявления. Поясним: мы нашли некоего Воробьянинова, числящегося с одним диагнозом за какой-нибудь 1990 год в картотеках двух районов. Ну, мало ли, переехал он... Если в его "старом" районе написать, что он "выехал" - то у нас будет ДВА диагноза за 1990 год, и в пересчете любой заболеваемости 1990 года вылезет аж два таких диагноза. А их не два, их как был выявлен тогда один, так и должен быть один. Снять диагноз? Но тоже - на основании чего? Не от фонаря же... Когда его поставили, были уверены в диагнозе, и там таки рак - что ж снимать? Короче, ситуация наиболее адекватно описывается в терминах удаления записей, с оставлением в базе данных наиболее адекватного отражения\ теперешнего состояния больного. Но ни в какую графу таблицы такое "уменьшение" раньше не отражалось. Потому была введена пресловутая Графа 8 подтабличных выражений Формы 35-здрав "Знято з iнших причин" для таких вот "неописуемых ситуаций", когда человек пропадает, а снимать-хоронить-то и нечего. Кроме дублей, сюда же попадают, например, выявившиеся опечатки в данных. Снятые дубли просто наиболее массовый источник "недоучета", потому мы не делали графу "Снято дублей" (их-то можно было бы как раз и посчитать), а сделали одну кучу для всех ситуаций такого плана, т.е. принципиально приводящих к нарушению баланса с предыдущим годом. Машина эту цифру принципиально не считает - чтобы Вы имели возможность вписать сюда ту цифру "снятых по другим причинам", которая приведет к схождению баланса и порадует Ваш облздрав и Министерство. При этом мы исходили из принципа доверия к Вам и надеемся, что облегчаем Вам отчетность по реальной работе, а не помогаем покрывать бардак. Следите, пожалуйста, сами за правдоподобностью этой цифры и соизмеряйте ее с объемами выполненной в течение года работы по снятию тех же дубликатов.
Чтобы баланс всехда сходился, с января 2002 года сделана кнопка "Баланс" в программе ОНК. Она доступна в режиме "Операции" для годовой матрицы 35-здрав (неуточненной). Считаете таблицу. Вводите "с бумажки" заветное число "состоявших на конец прошлого года", сданное в Министерство - и имеете результат, который нужно вписать в Подтабличное 8. Ура.
Также поясняем: НЕТ абсолютного баланса между таблицами Формы 7 и 35-здрав! Мы не знаем, сколько физических лиц составляет то множество диагнозов, которое показано в подтабличном Формы 7 "Первично-множественных опухолей", и "Из них - возникли синхронно". У одного больного может возникнуть в один год и 2, и 3, и 4 опухоли. Сколько нужно вычитать из заболеваемости, чтобы получить больных - только Ааллаху ведомо.
Однако помните: Баланс - это не только лишний геморрой, но и способ вовремя заметить какие-то потери данных и проконтролировать ситуацию. Отнеситесь с уважением хотя бы к тем остаткам формул баланса, которые признаны разумными. Мы много лет боролись за то, чтобы Вам было легче "сводить баланс", но мы надеемся, что Вы избежите повода для фальсификаций, а сэкономленное время Вы потратите на улучшение качества данных и будете лучше контролировать свою ситуацию, а не обрадуетесь безнаказанности и перестанете вообще заглядывать в свои данные. Мы заглянем...
# # # # #
Как поступать с больными, которые были когда-то сняты
с учета (выехали, базалиома и т.п.), а вот теперь вернулись (или возник рецидив
заболевания и т.п.)?
Раньше, когда-то, было предписано снимать с учета базалиомы, безрецидивно живущие более 5 лет. Потом, спустя еще несколько лет, рецидив появляется и больного снова ставят на учет. Просто изменяют ему статус последнего наблюдения с 6 на 8. При этом в прошлом году его "не стояло", в этом году он уже не первичный, не взятый с "прошлых лет" и т.п., но при этом он есть в "состоящих на конец года" - то есть, возник из вакуума, баланс ругается... Вах. Некоторые (по нашему же совету и уповая на "Подтабличное 8", которое все покроет) на баланс плевали, исправляли статус последнего наблюдения, но имели долгие разговоры в облздраве по поводу такого несхождения. Особенно красива ситуация, когда таких больных было больше, чем снятых дублей, и в волшебное "Подтабличное 8" нужно было бы вписывать ОТРИЦАТЕЛЬНОЕ число.
Чтоб этого не было, разные области извращались, как могли: например, заводили новую карточку (= заведомый дубль!), куда вписывали старые данные и новый год учета. Такая же механика решения проблемы была и при внезапном появлении в районе ранее куда-то якобы выехавшего больного. И так же наиболее логичное действие - простое "восстановление этого больного в правах и на учете" - приводило к несхождению баланса.
Что делать в этом случае, чтоб и больные были сыты, и балансы целы? Предложение: изменить статус больного на "Состоит на учете", а дату учета диагноза - на текущий год. Т.о., он пойдет как бы "взятым с прошлых лет". НЕ СОЗДАВАЙТЕ ДУБЛЬ! Не было тут двух диагнозов, один из которых выехал, так пусть и дальше не будет! НЕ ТРОГАЙТЕ дату диагноза! Если это "старый" диагноз, то намного важнее дата его выявления, чем дата учета. Фактически, при предложенном подходе мы теряем только дату первичной регистрации больного, т.е. сведения о том, что он был вообще-то взят на учет сразу, в том самом 1990 году, а потом где-то скитался. Ну и Бог с ней. Эта дата научной ценности не имеет, а ее практическая ценность для "балансов" осталась в том самом далеком 1990 году. В текущем году больной будет легально взятым с "диагнозом, установленным ранее", что так и есть, а в уточненной заболеваемости 1990 года этот случай будет учтен. Все нормально.
# # # # #
У нас жил-был себе Хацапетовский район, и вдруг его
райцентр стал "городом областного подчинения", и нам нужно вынести
город Хацапетовск на уровень районов, разделив картотеки города и Хацапетовского
района... Как это сделать?
Во-первых, перед всеми подобными манипуляциями ОБЯЗАТЕЛЬНО ЗААРХИВИРУЙТЕ ДАННЫЕ. Вдруг что-то пойдет не так, как надо - сможете восстановить.
Далее, УРОВЕНЬ РАЙОНА ТРОГАТЬ САМОСТОЯТЕЛЬНО НЕЛЬЗЯ. У нас есть всеукраинский кодификатор, где каждой области и району (городу уровня района, в терминах дерева ПКР) соответствует 4-хзначный код. Он "зашит" у нас в справочнике, может встречаться не только в Вашей Х30, но и везде, где встречается больной из Вашего региона (скажем, в каком-то больничном регистре). Самостоятельное изменение этого кода приведет к тому, что, например, выписка откуда-то не дойдет по адресу и т.п. Такие изменения нужно делать только совместно с нами и сопровождать изменением кодификатора. Зато в пределах Вашей компетенции выделить себе в пределах Хацапетовского района отдельно город и отдельно район, т.е. разделить картотеки на уровни подрайона.
Итак, как проще всего отдельно выделить город:
1)X30_Inst.exe - "Добавление\Удаление региональных структур" - идете в исходный район, переходите на подструктуры (F5) и создаете 2 подструктуры, например, Город и Район. Если район имел код, скажем, 251200, то коды подструктур можно назвать 251201 и 251202, соответственно.
2) Вся ваша старая картотека района лежит в "старом" подкаталоге уровня района - DATA\251200, причем к ней доступиться через Х30 после создания подрайонов уже нельзя. Потому выходите из программы и обычными средствами файл-менеджера копируете все файлы с данными (а именно: pasp.dbf, diag.dbf, lec.dbf, nabl.dbf, ustan.dbf, chern_e.dbf, chern_l.dbf ) из 251200 в один из подрайонов, например, в 251201. Все файлы *.ntx удаляете, а все остальное - таблицы, население и, ГЛАВНОЕ, bdirs.dbf - пусть лежит где лежало, в 251200. Это все относится именно ко всему району в целом.
3)Теперь x30.exe: сначала индексируете многострадальный район со всеми подрайонами, и запускаете "Информацию по базе" - чтоб убедиться, что ВСЯ информация, которая лежала в "районе", теперь лежит в его первом подрайоне. Далее - опцией "Поиск по катротеке" стараетесь выделить список людей, которых нужно перенести в ДРУГОЙ подрайон. Скорее всего, это можно будет сделать, например, по признаку "Житель села" или по подстроке адреса. Главное - сделать список людей, подлежащих переносу.
4) Работа со списком - выбираете список "подлежащих переносу", и ПОМЕЧАЕТЕ всех их через "+". Теперь через F10 - "Макро" - вызываете "Перенос в другой регион отмеченных больных". Не пользуйтесь Shift_F9 - оно работает не со всем списком, а с одним-единственным текущим человеком, не стоит долго мучиться. Грозная красная рамочка расскажет Вам, как опасно переносить пачками больных туда-сюда, но увы - нам именно это и нужно. Не сдавайтесь, требуйте чтоб переносила. Дырррр - перенесла - идете снова в Информацию по базе, в картотеку, проверяете, что все правильно и - можно работать.
В принципе, пп. 3-4 можно делать и в "индивидуальном порядке", из картотеки одного подрайона переносить нужных людей в другой по одному, а не списком, если список сформировать не получается. Но это долго, зачем мучиться. Поодиночке перенесете только тех, кого не удалось загрести списком или потом заметили, что он почему-то не там лежит.
Ура, работайте.
# # # # #
Как бы сообразить такую табличку в БОЛЬНИЧНОМ РЕГИСТРЕ,
чтобы строки были по локализациям и по стадиям, а столбцы - по комбинациям лечения?
Или хотя бы просто получить раскладку комбинации лечения для больных определенной
стадии, локализации или еще чего-то из Данных диагноза, равно как и перенесенных\сопутствующих
заболеваний, и т.д... Желательно сделать это в виде "... из числа лечившихся
в нашем стационаре за последний год..."
Да уж, задачка, прямо сказать, непростая. Есть "стандартная" таблица по комбинациям лечения, считается со строками - отделениями, можно было бы попытаться Поиском сделать Список нужного формата из больных по локализациям и стадиям, или какой Вам нужно, и "пропустить" его через подсчет таблиц, использовав в качестве "входного файла". Но увы - по сценарию "Стационар", который и производит нужные нам файлы списков *.stn, никаких условий на базу ДИАГНОЗ наложить нельзя, как и на некоторые другие базы.
Фактически, нам нужно получить сначала СПИСОК ЗАПИСЕЙ СТАЦИОНАРА тех больных, которые имели 3-4 ст. рака легкого и т.п., и дальнейшие манипуляции проводить уже над этим списком. Это достигается с помощью опции "Список другого формата" - т.е. выбираете сценарий Обьект - Больной, на нем накладываете все мыслимые и немыслимые условия, и указываете имя файла для Списка другого формата по сценарию Стационар (или Госпитализация, если надо). Таким путем можно идти всегда, когда нужны какие-то хитрые условия, которых нельзя указать в сценарии Стационар (Госпитализация). Детали и подробности см. в книгах Тайн Поисковой Системы .
Для того, чтобы не запутаться со стационарами и госпитализациями и верно попасть выбранными таким образом госпитализациями в хитрый интервал "Дата ВЫБЫТИЯ из стационара = с... по..." с учетом всяких переводов, можно:
1) выделять по сценарию "Больной" ВСЕ госпитализации интересующих Вас
больных,
2) затем запускать стандартный запрос "Получение входных файлов для таблиц
по интервалу",
3) и наконец - ПЕРЕСЕЧЬ полученный на этапе (1) "список другого формата"
с полученным на этапе (2) списком попадающих в данный интервал - infile.sta,
(*.stn, *.lec). Получится оно самое - те и только те поступления, в которых
такие-сякие больные (с указанной Вами стадией, диагнозом и т.п.) должны считаться
в отчетености стационара за заданный интервал.
4) И вот этот список (3) можно подвергать любой "обычной" обработке
- пропустить его через таблицу Анализа деятельности, или Анализа видов лечения,
или разложить Поиском...
Я понимаю, что Вы щас скажете, мол это слишком сложно, марудно и вообще - нельзя ли сделать такую стандартную таблицу или хотя бы расширить сценарий... Но давайте задумаемся - ПОЧЕМУ сразу не сделали такую таблицу, и даже не включали вообще базу Диагноза в сценарии "Госпитализация" и т.д.
Как известно, статистика стационара норовит посчитать не Больного в целом,
а отдельную госпитализацию. Почему так повелось, кому это выгодно и т.п. я сейчас
обсуждать не буду, но традиционно сценарии "Стационар" и "Госпитализация"
использовались для получения больничной статистики (койко-день и т.п.), а не глубокого
анализа процесса. Потому многие вещи там упрощаются. Да, у больного может быть
несколько диагнозов. Но в госпитализации указывают тот, по которому он лечился
"в данный момент", пусть даже не злокачественный. Остальные - игнорируем.
О термине "Первичный больной" в трактовке стационара вообще можно
ругаться долго и безуспешно. Мы насчитали, помнится, 5 или 6 "трактовок",
что понимают в стационаре под "первичным больным". Некоторые довольно
экзотичны. На некоторых бланках историй болезни есть даже пометка "Первичный
ЭТОГО года", т.е. не вообще первичный, а в этом году первичный... Потому,
чтобы начинать более глубоко анализировать что-то по стационару, по сценарию
"Госпитализация", нам прийдется еще не раз вернуться к определению БАЗОВЫХ
понятий, как со статистической, так и из общелогической точки зрения.
К чему это я... Что мы сможем увидеть в Вашей таблице? Если таки как-то извратиться и таки ее подсчитать? А мы увидим, что у больного Х, скажем, стоит 1-2 стадия, но он весь из себя тяжелый, потому как несколько лет болеет, и врач скажет, что ему лечение назначает как для 3-4 стадии, что бы ему в Диагнозе ни написали (такая проблема есть у нас в клинике - они упорно пишут 3-4 стадию тем больным, которые у ВАС зарегистрированы как 1-2, но намного раньше, чем доехали до нашего института)... Далее мы увидим, что, скажем, кто-то Y получил ХТ, затем его не ПЕРЕВЕЛИ в отделение ЛТ, а ВЫПИСАЛИ домой на пару дней, и теперь тут "два больных" раздельно леченных, а не один леченный комбинированно. И много чего мы еще увидим, напрягшись с вычитанием списков и получив, наконец, заказанную кем-то таблицу... Которую сколько ни анализируй, все равно прийдешь к выводу, что весь анализ, выходящий за рамки стандартных таблиц, нужно делать по БОЛЬНОМУ В ЦЕЛОМ, а не пытаться втиснуть его и др. в рамки отдельной "Госпитализации", количество которых у больного зачастую обусловлено желанием увеличить\уменьшить средний койко-день или еще чем-то, не имеющим отношения к качеству лечения. Что и как и с какой стороны можно анализировать - над этим давайте вместе думать.
РЕЗЮМЕ: Задача анализа лечения больных в зависимости от локализации,
стадии и т.п. не должна решаться через призму статистики стационара, т.к. будет
при этом подвергаться массе воздействий, не имеющих отношения к решаемой проблеме.
Наиболее логичный путь - решать это через ПОПУЛЯЦИОННЫЙ РЕГИСТР. Где уже есть
методы определения первичности-повторности больного в целом, рассматривается
лечение именно ПЕРВИЧНЫХ больных, а также не имеет значения, было ли
комплексное/комбинированное лечение получено за один "присест"
или в несколько заходов,
в одной клинике или в разных. Для анализа роли именно онкологического диспансера
в общем процессе можно выделить в ПОПУЛЯЦИОННОМ регистре список первичных больных,
получивших лечение в ООД, и этот анализ провести на них через ПКР - при работающей
у Вас передаче из БКР в ПКР результаты должны быть вполне приемлемыми, а отличия
от аналогичного анализа, выполненного по данным только БКР,
скажут скорее всего о том, что в популяционном регистре известны некоторые нюансы
жизни Ваших больных за стенами Вашего стационара.
# # # # #
Как в ПОПУЛЯЦИОННОМ канцер-регистре получить количество химиотерапий,
проведенных за год (квартал и т.п.) жителям некоторого региона?
Во-первых, нужно отдавать себе отчет в том, что подтабличное таблицы лечения Формы 35-Здрав "Число больных, получивших в отчетном году химиотерапию" может не являться той цифрой, которую от вас хотят получить. В подтабличное (как и во всю таблицу) идут только специальные лечения (т.е., с характером лечения, указанным как "радикальное" или "паллиативное" или "адъювантное"), и если у вас есть какое-то количество химиотерапий с более экзотичным характером лечения - подтабличное о них ничего не скажет. Правильно ли это в принципе, какой характер нужно указывать т.н. профилактической (адъювантной) химиотерапии, входящей при этом в программу радикального курса, и т.д. - это тема отдельной дискуссии. Важно знать, что на сегодня дело обстоит именно так. Поэтому, для получения информации обо ВСЕХ химиотерапиях нужно отбросить химеру, именуемую характером лечения, и воспользоваться Поисковой системой. Задав ей простейшее условие: вид лечения = ХТ и Интервал Лечения =такой как Вам угодно.
Далее. Скорее всего, Вашего главврача будет интересовать на самом деле не число больных, получивших химиотерапию, а число самих химиотерапий. Т.е. если больному Пупкину было сделано за год 3 курса ХТ, то хочется посчитать все 3, ибо это позволяет отчитаться о расходе препаратов, полученных откуда-то там на область. Если это так, и Вас удручает отсутствие в поисковой системе популяционного канцер-регистра такого сценария «Лечение»*, как в системе больничного регистра - не беда. Используйте сценарий "Больной". Наложите условия на лечение, как указано выше. А в таблице укажите поле для сортировки, и ОБЯЗАТЕЛЬНО какое-нибудь поле из данных лечения. Например, тот же вид или характер лечения. Зачем? А для того, чтобы после проведения поиска в разделе "Результаты поиска", "Количество" можно было узнать не только число удовлетворивших условиям поиска обьектов (т.е. больных), но и число отдельных записей лечения, т.е., согласно нашим условиям, химиотерапий за указанный интервал времени. Выберите при просмотре количества какое-либо поле из базы Лечения (вот зачем мы его включили в таблицу, а не только для того, чтобы убедиться в том, что нашли именно то, что нужно!), и для этого поля выберите "Количество записей". Нетрудно заметить, что полученное число будет больше числа больных. А если взять на себя труд распечатать итоговый список и пересчитать число отдельных строчек (химиотерапий), то вы с изумлением получите это же число. Но мы надеемся, что Вы поверите нам на слово и потратите это время с большей пользой. Например, перечитав еще раз забытые главы из книги "Тайны и загадки поисковой системы", где рассказано и о возможности подсчета отдельных записей, и о многом другом.
* Начиная с версии 3.28 2016 года сценарий «Лечение» также есть в поисковой программе популяционного КР, что позволяет более подробно исследовать лечения пациентов в регионе.
# # # # #
ВОПРОС: Подсчитали ОНКом таблицу с разбивкой по стадиям
(35-здрав Контингенты, или же 35-уточненная, вкладыши по стадиям леченных или
нелеченных больных). Попытались сделать такую же работу Поиском. Прослезились:
даже если взять ТОТ ЖЕ список больных (выделенный по клетке "Всего"
исходной таблицы), разложение по стадиям в поисковой системе ЗНАЧИТЕЛЬНО отличается
от предложенного ОНКом. Что делать, Кто виноват, и Что нам за это будет?...
ОТВЕТ: Проблема возникла у неугомонного Луганска, при попытке разложить какую-то из подсчитанных ОНКом таблиц по регионам с помощью поисковой системы. Однако, на самом деле это проявление другой, более общей, проблемы, суть которой такова: многообразие способов стадирования больных как по ТНМ так и без учета оного. Если внимательно поглядеть в список полей Диагноза в Поисковой системе, то можно найти аж ТРИ поля, содержащих значение стадии: одно из них - "реальное", т.е. соответствует тому, что ФИЗИЧЕСКИ хранится в базе данных ("СТАДИЯ"), а также два "вычислимых" ("виртуальных"): В: "Стадия с 1 знаком", и В: "Стадия с 1 знаком на основании ТНМ и анализ ТНМ". В версии 3.11, мы собрали их рядышком в списке полей, чтобы вы использовали не то, до которого первым дотянулись, а видели все три и могли осознанно выбрать тот способ представления стадии, который Вам нужен в том или ином случае. По-видимому, настало время рассказать, чем же они все-таки отличаются.
Подробно эта информация изложена в подготовленном Е.В.Сумкиной документе. С точки зрения практического использования, считаю целесообразным добавить следующее:
1) Для разбивки таблиц ОНКа использована функция стадирования, формирующая значения поискового поля В:"Стадия с 1 знаком на основании ТНМ и анализ ТНМ".
2) Шокирующие расхождения между содержимым таблиц (или значением этого поля) и разбивкой стадий по полю В:"Стадия с 1 знаком", которая, напомним, соответствует реально хранящемуся в базах значению поля "Стадия", вызваны главным образом отказом нашей функции стадировать NX эквивалентно N0 (См. Анонс версии 3.11), а также и теми случаями, в которых стадия была проставлена не на основании индексов TNM. Таким образом, даже те случаи с NX, которым на протяжениии 2003 года стадия выставлялась автоматически, теперь считаются НЕСТАДИРОВАННЫМИ. Доля таких случаев достигает, по нашим наблюдениям, от 10% до 30%. Те же самые расхождения вы, кстати, можете пронаблюдать, пересчитав таблицу Контингентов - 2003 с помощью ОНКа версии 3.11 и сравнив со свежесданным отчетом (версия 3.10)...
3) Если хотите видеть разбивку по стадиям в соответствии с тем, как оно есть в Базе Данных - используйте разбивку по полю В:"Стадия с 1 знаком". Если хотите видеть соответствие таблицам ОНКа версии 3.11 (т.е.тому, как оно будет теперь считаться в Отчете-2004) - используйте разбивку по полю В: "Стадия с 1 знаком на основании ТНМ и анализ ТНМ". Заодно, проанализируйте.
4) В Версии 3.11 ВСЕ нестадированные (не попавшие в ст.1,2,3,4 или 0 (=in situ)) значения поля "Стадия с 1 знаком" выводились под грифом "норм - ТНМ нет и не должно быть (у лимфом не проставлена стадия)". Это значение взято из функции "анализа ТНМ", хотя на самом деле в этом случае было нашей опечаткой. В новой версии при отсутствии стадии в базе это значение будет звучать коротко и просто - "отсутствует".
Спасибо за внимание.