Пропустить команды ленты
Пропустить до основного контента

Территориальный фонд ОМС Архангельской области

Информационные технологии

:

СРОЧНАЯ ИНФОРМАЦИЯ!!! :Страница непрерывноДля открытия меню воспользуйтесь сочетанием клавиш SHIFT+ВВОД (в новом окне).Открыть менюОткрыть меню

Срочная информация в виде вопросов и ответов по переходу на новый формат обмена (XML, "Общие принципы")
Вложения
  
  
Вопрос
Ответ
  
В реестре присутствует обязательное поле (О) CODE_MD (Код медицинского работника, оказавшего медицинскую услугу), которое в соответствии с комментарием, должно заполнятся "В соответствии с территориальным справочником". Чем его заполнять, где взять указнный справочник?
Пока ничем. Пришлось сделать это поле не обязательным. Оно не будет проверяться на обязательность заполнения при проведении ФЛК и МЭК. Территориального (регионального) справочника врачей пока нет. Как только будет - мы об этом сразу же сообщим.
 
Примечание: в ПК "Полиус" поле пока заполняется 4-значным табельным номером из списка врачей учреждения.
 
  
Поле PODR встречается в описании структуры реестра (Таблица Д.1) дважды: идут поля PODR, LPU, LPU_1, PODR. Что это значит, не ошибка ли? К чему относятся данные поля, для чего они?
Нигде четко это не описано, но мы полагаем, что они относятся:
1. Вышестоящее – к головной (основной) МО
2. Нижестоящее – к филиалам МО (не являющихся самостоятельными участниками ОМС, т.е. не являющихся юрлицами)
Примером может являться вновь вошедшая в систему ОМС больница УФСИН. Головная организация у них – в Архангельске, и имеет в своем составе отделения, в которых оказывается МП. Поля PODR и LPU должны заполняться кодами головной организации. У б-цы УФСИН есть филиал в (вроде бы, не помню точно) Вельске, в нем тоже есть свои отделения. Поле LPU_1 и нижеследующее поле PODR служат уже для указания самого филиала и отделения в филиале (если существует). Полагаю, что мы не будем детализироваться до отделений филиалов. К тому же, можно предположить, что в документе «Общих принципов» в наименовании второго поля PОDR опечатка. Оно по сравнению с полем LPU_1 должно бы называться PODR_1. Хотя, как знать – может и потребуется.
  
На какой адрес e-mail отправлять реестры из МО для определения страховой принадлежности и каковы правила формирования почтового сообщения?
Об адресе электронной почты
 
Все реестры (реестры на определение страховой принадлежности, а также реестры на оплату (для передачи в СМО), реестры с результатами экспертизы из СМО для МО) - должны передаваться на адрес электронной почты MP@ARHOFOMS.RU
 
На старый адрес (RLU@ARHOFOMS.RU) реестры нового формата передаваться не должны. На этот адрес можно передавать только те реестры, которые в соответствии с письмом ТФОМС АО от 19.01.2012 № 72/06-33 продолжают передаваться в старом формате (RLU).
 
О формировании почтового сообщения из МО в ТФОМС
 
  1. В информационный пакет, содержащий Реестр сведений об оказанной медицинской помощи, включаются два файла
    1. Файл, со сведениями об оказанной медицинской помощи(Приложение Д - файл типа Н).
    2. Файл, содержащий персональные данные пациентов, которым оказана медицинская помощь (Приложение Д – файл типа L).
  2. Имена файлов, входящих в пакет формируются исходя из Приложения Д – Общих Принципов
  3. Оба файла (H и L) упаковываются в один архив формата ZIP.
  4. Имя архива соответствует имени файла, содержащего Реестр сведений об оказанной медицинской помощи, расширение – ZIP. Например: HM290202S29030_1112013.ZIP
  5. После архивирования – пакет подписывается ЭЦП, затем шифруется.
  6. Отправка пакета посредством электронной почты:
    1. Одно письмо должно содержать не более  одного информационного пакета
    2. Поле темы письма должно содержать название (имя и расширение) исходного информационного пакета,  прикрепленного  к  письму

Внимание! Пользователям электронной почты GMAIL.COM: GMail НЕ принимает файлы формата ZIP архива.

 

  
Чем заполнять обязательное поле NHISTORY (Номер истории болезни/ талона амбулаторного пациента)? Талон амбулаторного пациента не имеет номера!
Для стационара
 
Поле NHISTORY следует заполнять номером стационарной карты пациента (истории болезни).
 
Для поликлиники
 
В связи с тем, что талон амбулаторного пациента действительно не имеет номера, это поле следует запонять уникальным (буквенным, числовым или буквенно-числовым) идентификатором для случая лечения. Иными словами, если пациент обратился на прием к врачу-терапевту поликлиники с ОРЗ, и лечился 10 дней, то для всех записей о случаях посещения врача-терапевта (а также всех прочих специалистов, которые пациент посетил в течение этих 10-и дней), этот номер должен быть одинаковым. Если пациент выписался, а через месяц обратился вновь, номер в NHISTORY будет уже другой. Наличие такого номера позволит объединить набор разрозненных записей в законченный случай лечения.
 
Примечание: в ПК "Полиус" такой номер генерируется автоматически.
 
  
У меня в специальности стоят ????????? вместо текста.
Специальную утилиту, исправляющую кодировку таблиц базы, из за которой была проблема выложена тут. После исполнения необходимо заново загрузить справочники.
  
МО формирует в фонд запрос на определение страховой принадлежности (файлы типа "H" и типа "L"). Какого формата должен быть этот файл и что возвращается из фонда в качестве ответа на запрос? Какой формат ответа?
Формат запроса на определение страхвой принадлежности (СП), отправляемый в фонд, ничем не отличается от формата обычного реестра на оплату, за одним исключением: узел SCHET у файла-запроса типа "H" на определение СП не заполняется!!!
 
В качестве ответа возвращается файл типа "H" с измененным содержанием (файл типа "L" не возвращается). В файле типа "H" меняется содержание полей (по итогам определения страховой принадлежности в центральном сегменте регистра):
  • SMO_OGRN (ОГРН СМО)
  • SMO_OK (ОКАТО территории страхования)
  • VPOLIS (тип документа, подвтерждающего факт страхования)
  • NPOLIS (всегда возвращается ЕНП)

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

Формат возвращаемого файла типа "H" не меняется.

  
В файле со сведениями об оказанной медицинской помощи есть обязательное поле PODR (Отделение МО из регионального справочника). Чем его заполнять?
На данном этапе (пока не готов региональный справочник отделений (подразделений) МО) мы не будем проверять обязательность заполнения данного поля. В перспективе, заполнять его будет необходимо в следующих случаях:
  • МО имеет подразделения, которые по иному тарифицируются. Например, онкодиспансер имеет отделение в Северодвинске, которое работает по тарифам Крайнего Севера, и ничем более от отделений онкодиспансера не отличается;
  • МО имеет подразделения (филиалы), которые не являются юридическими лицами (самостоятельными участниками сферы ОМС).

Смотрите также здесь.

  
Как перекодировать введенные данные за январь по стоматологическим услугам из старого классификатора УЕТ в новый, который действует с 1 января 2012 года?
В ПК "Полиус" такая перекодировка выполняется автоматически. Услуги из старого справочника, которым есть соответствие в новом классификаторе - перекодируются, по остальным будет выставлена ошибка, которую нужно будет исправить вручную.
 
Те, кто работает в других МИС - используйте эту таблицу перекодировки:
 
  
Наша медицинская организация переименовалась, из МУЗ стала государственным буджетным учреждением здравоохранения (ГБУЗ). Но в справочниках все еще указывается как МУЗ. Почему так произошло и что нам делать?
Мы перешли на использование федеральных справочников, по "Общим принципам". Отдел организации ОМС ТФОМС АО все изменения регулярно вносит в специальный раздел на корпоративном сайте ФФОМС. Однако последнее обновление реестра МО, доступное для загрузки с сайта ФФОМС, только на 16.12.2011. В нем многие изменения не отражены. В ФФОМС написан запрос на актуализацию реестра, доступного для загрузки. Как только реестр будет доступен, мы разместим его на нашем сайте, раздел "Информационные технологии", подраздел "Справочники". Следите за его содержанием.
  
Новый реестр включает 2 понятия: случай и услуга. Что считать случаем оказания медицинской помощи? Сколько услуг должно входить в случай?
Здесь следует определиться: в реестрах указывается случай оплаты (ветвь SLUCH). Он не обязательно является законченным случаем лечения с медицинской точки зрения. Случай оплаты является по сути тарифной единицей из старого порядка информационного обмена. Т.е. для амбулаторно-поликлинической помощи случаем оплаты будет являться посещение, для стационара - период лечения в койко-днях или стандарт.
 
Случай оплаты состоит как минимум из одной услуги (ветвь USL) и заполняется из регионального классификатора услуг (поле CODE_USL). Сделано это для обеспечения совместимости со старой системой кодирования медпомощи и с действующей системой тарифов, которая в значительной степени опирается на старую систему кодирования.
 
Случай может содержать и более одной услуги. Например, случаи посещения в поликлинике к врачам-специалистам, которые оплачиваются из двух источников (по территориальной программе ОМС и по программе модернизации), будут содержать две услуги: 1-я - посещение по тарифу территориальной программы, 2-я - посещение по стоимости программы модернизации. Обе услуги будут браться из регионального классификатора услуг. При этом только 1-я услуга (по террпрограмме) войдет в стоимость случая (SUMV), 2-я будет использоваться только для формирования отдельного счета и в сумме реестра не участвует.
 
Для некоторых случаев, которые сплошь состоят из услуг (ЦАХ, ЦЗ, стоматология) случай будет включать несколько услуг и все они войдут в стоимость случая (SUMV).
  
Если один и тот же человек попадает в файл со сведениями об оказанной медицинской помощи (файл "H") несколько раз, надо ли его указывать столько же раз в файле персональных данных (файл "L")? Или только один раз с уникальным для этого человека идентификатором ID_PAC?
В файле персональных данных "L" сведения о пациенте достаточно указать один раз с уникальным (в пределах реестра) идентификатором ID_PAC.
  
В формате записи на уровне случая присутствуют поля CODE_MES1 и CODE_MES2. Они условно-обязательные (У). В каких случаях необходимо их заполнение и откуда брать коды для их заполнения?
Для совместимости с действующей системой тарифов у нас принято формирование случая через услуги (ветка USL, поле CODE_USL). Поэтому в случае применения стандарта (МЭС) достаточно указания соответствующей услуги (стандарта) из регионального классификатора услуг.  Соответственно, поля CODE_MES1 и CODE_MES2 могут не заполняться вообще. Желающие их заполнять - могут заполнить эти поля кодом соответствующей услуги и регионального классификатора услуг. На МЭК эти поля проверяться не будут, их содержание будет игнорироваться.
  
Как формируется имя файла для реестров счетов по пролеченным из других регионов?
Надо ли в имени файла ...T29_... (т.е. в фонд) или ...S00000_... (т.е. в конкретную СМО иного региона)?
Получателем нужно указывать фонд (T29). В другие территории мы формируем реестры самостоятельно, объединяя все записи от всех ЛПУ нашей области на конкретную территорию.
  
На какую СМО выставлять реестры по застрахованным РОСНО-МС? ПК "Полиус" вообще не дает возможности ввести застрахованного РОСНО-МС.
Застрахованногоо РОСНО-МС невозможно ввести в ПК "Полиус" по той причине, что данная СМО более не работает на территории Архангельской области. ФФОМС убрал ее из справочника СМО, мы ее туда самостоятельно добавить не можем.
 
Кроме того, сейчас все основано на определении страховой принадлежности (СП). К сожалению, около 90 тыс. бывших застрахованных РОСНО-МС не перестраховались в других СМО. В итоге у них возникла неопределённая СП.
 
Для разрешения этой ситуации ТФОМС АО самостоятельно(по согласованию с ФФОМС) перераспределил СП бывших застрахованных РОСНО-МС пропорционально между СМО области. В региональном сегменте эти изменения уже внесены, сейчас ждем их подтверждения от центрального сегмента, должны получить их в течение сегодняшнего дня (1 февраля). После завершения этой операции, бывшие застрахованные РОСНО-МС будут считаться застрахованными другими СМО. Запрос на определение СП даст ответ, за какой СМО закреплен конкретный застрахованный.
  
В ПК "Полиус": Новые тарифы, открываем окно Тарифы для стоматологическая, нет врача-ортодонта взрослого и врача-ортодонта детского, как ввести эти специальности в тарифы?
Ввод услуг врача-ортодонта реализован в ПК "Полиус" версии 1.3.8.
 
Для других информационных систем следует выполнять привязку тарифов услуг врача-ортодонта к коду 140101 справочника V004.
  
Как правильно сформировать запись о случае, оплачивающемся из 2-х источников: территориальной программы (региональный источник) и программы модернизации (федеральный источник)?
Правильное заполнение случая по модернизации базируется на принципе, что любой случай состоит из услуг.
 
Например, случаи посещения в поликлинике к врачам-специалистам, которые оплачиваются из двух источников (по территориальной программе ОМС и по программе модернизации, т.н. "доступность"), будут содержать две услуги:
  1. посещение по тарифу территориальной программы,
  2. посещение по стоимости программы модернизации.

Обе услуги будут браться из регионального классификатора услуг. При этом только 1-я услуга (по террпрограмме) войдет в стоимость случая (SUMV), 2-я будет использоваться только для формирования отдельного счета и в сумме реестра не участвует.

Аналогичная ситуация и с формирование случаев по стационарной помощи с использованием стандартов оказания МП.

  
1) У нас выдает ошибки в результате определения страховой принадлежности пациентов: "У врача не найден код специальности по федеральному справочнику!"
почему так? У врачей все коды мы внесли правильно.
При редактировании сведений о враче, в ПК "Полиус" есть поле в самом верху – дата с которой  применяются изменения, так вот она по умолчанию устанавливается в текущую датоу. Вы начали редактировать сведения о врачах в конце января, дату не поменяли на начало года (2012-01-01) и у вас установилась дата, например 2012-01-25. Поэтому посещения до этой даты выдают указанную ошибку.
  
На официальном сайте фонда невозможно найти новые тарифы. Где они лежат?
Дело в том, что документы по тарифам, помимо утверждения на совещании комиссии по разработке терпрограммы (которое состоялось только 31.01.2012), должны быть подписаны всеми членами этой комиссии. Список, как можете убедиться, не маленький. И процесс не быстрый. Поэтому документы по тарифам, не будучи подписанными всеми членами комиссии, не считаются официально принятыми и на нашем официальном сайте размещены быть не могут.
  
Обязательное ли заполнение поля PROFIL при указании услуги по стандарту в стационаре? Или при указании дополнительно (доплатной) услуги - стоимости стандарта по федеральной составляющей?
Да, заполнение поля PROFIL обязательно во всех случаях.
Вложение
  
Есть поля, обязательные для заполнения в любом случае. Почему же к нам в СМО приходят реестры с записями, в которых обязательные поля не заполнены? Как они проходят форматно-логический контроль (ФЛК) в фонде?
На ФЛК отклоняются только грубые ошибки, которые либо делают дальнейшую обработку реестра невозможной, либо заведомо могут привести к недостоверности данных. Следует учитывать, что при непрохождении ФЛК отклоняется весь реестр целиком. Поэтому если мы будем проводить чрезмерно жесткий ФЛК, то передать реестры на оплату в СМО будет для медицинских орнанизаций крайне затруднительно.
 
Поэтому бОльшая часть контролей перенесена на этап медико-экономического контроля (МЭК) в СМО. На этапе МЭК могут быть выборочно отклонены только ошибочные записи, а все остальные - приняты. Это значительно повышает возможность получения медицинскими организациями денег по большей части счетов. Непринятые же (отклоненные) записи могут быть исправлены в МО и представлны для оплаты позднее. 
 
К данному сообщению прилагается таблица ошибок, которые отслеживаются в ходе проведения ФЛК в фонде. Эта же таблица размещена здесь.
  
Вопрос СМО:
Прошу разъяснить,  какой  код услуги  (CODE_USL) необходимо применять при кодировке паценто-дней (койко-дней) в ЦАХ? В нынешнем классификаторе  для ЦАХ есть только коды оперативных вмешательств. Тариф ЦАХ за койко-день такой же, как  у дневного стационара. Поле CODE_USL  является обязательным, а МО его не заполняют для ЦАХ. Если это поле не заполнено, случай не принимается к оплате?
Совершенно верно, поле CODE_USL должно быть обязательно заполнено для любого случая лечения. Если оно не заполнено – то случай не должен приниматься к оплате. Коды услуг для тарификации по пациенто-дню (койко-дню) в ЦАХ должны применяться такие же, как для соответствующих дневных стационаров, они ничем не отличаются.
 
  
По какому принципу должна выставляться модернизация для законченного случая центра здоровья
и случая со стоматологическими услугами. Ранее в поле ОСС указывался код 9 (Реестровая запись по программе модернизации). Справочники  "Региональный классификатор услуг" и V010 (классификатор способов оплаты) не содержат соответствующих пометок
Общие принципы формирования реестров, содержащих доплаты по модернизации, описаны здесь:
Доплаты по модернизации для законченного случая в центрах здоровья тарифицируются точно так же, как доплаты по т.н. "доступности" АПП. Следовательно, Вы должны указывать:
  1. как первую услугу - законченный случай комплексного обследования при первичном обращении (код услуги 12.63). "Взрослый" или "детский" законченный случай - определяется на основании значения поля DET узла SLUCH (записи о случае);
  2. как вторую услугу - указываете доплатную услугу по "доступности МП" из регионального классификатора услуг. Для "взрослого" законченного случая - это врач-терапевт (код услуги 50.01), для "детского" - врач-педиатр (код услуги 50.07).

Что касается стоматологических услуг, то доплатная услуга указывается к каждой основной услуге, по количеству УЕТ. Например, в случай входят две услуги, оказанные врачом-стоматологом:

  1. 9.2.2.10 (6 УЕТ) и
  2. 9.2.2.5 (4 УЕТ).
  3. К услуге 9.2.2.10 добавляется доплатная услуга врача-стоматолога (код услуги 50.09) на 6 УЕТ (доплата по действующему тарифу 22 р. * 6 = 132 р.)
  4. К услуге 9.2.2.5 также добавляется доплатная услуга врача-стоматолога (код услуги 50.09) на 4 УЕТ (доплата по действующему тарифу 22 р. * 4 = 88 р.)
  5. Общая сумма доплат составляет (по случаю) 220 р., но в сумму случая (SUMV) сумма доплат не входит. Она сидит исключительно в услугах.

Пометки ОСС для учета услуг, оплачиваемых как по территориальной программе, так и по программе модернизации, теперь не нужны. Факт оказания услуг по модернизации должен явно кодироваться соответствующими доплатными услугами из регионального классификатора услуг.

  
Просим разъяснить правила ввода данных в ПК «Полиус» о посещениях врачей и тарифах передвижного лечебно-профилактического модуля.
На посещения передвижных лечебно-профилактических модулей (ПЛПМ) устанавливаются отдельные тарифы, отличные от обычных поликлинических посещений. Все остальное у посещений ПЛПМ точно так же, как в поликлинике, отличий с точки зрения заполнения реестров нет.
 
Естественно, возникает вопрос: как различить, правильно или неправильно был применен тариф, а также как правильно сформировать реестры по таким посещениям?
 
Для этих целей был разработан "Региональный справочник подразделений медицинских организаций". Он вводит своего рода определение места оказания медицинской помощи (МП), для тех случаев, когда от места оказания МП зависит тариф.
 
Таким образом, для правильного указания и проверки тарифа на посещения ПЛПМ следует заполнять (помимо всех остальных обязательных полей) поле LPU_1.
 
Поддержка регионального справочника подразделений МО включена в ПК "Полиус" начиная с версии 1.3.15. В файле "Izmenenya.doc" описан порядок работы для заполнения информации по ПЛПМ.
Вложение
  
В перид лечения было два передвижения по профилям койки – одно началось в январе (плановая), второе  закончилось в феврале (экстренная).  Из-за особенностей выгрузки в «Полиусе» виды мед помощи выгружаются в разных реестрах. И получилось, что страховая отказала первое передвижения с  ошибкой: период не соответствует счету. По-моему, специально для таких случаев заполняется специально поле NHISTORY, чтобы можно было объединить такие передвижения в один случай. Каков порядок выгрузки по таким случаям?
И еще, какой тариф брать в таких случаях: на  конец лечения или передвижения?

Ситуация с переводами разъяснена в прилагаемом письме ТФОМС АО от 04.04.2012 № 969/01-17 в Северодвинский роддом "О направлении разъяснений по учету пролеченных больных". Вот выдержка из письма:

 

В соответствии с тарифами на медицинскую помощь в сфере обязательного медицинского страхования, утвержденными Соглашением о тарифах на 2012 год от 31.01.2012 (и изменениям к ним) при переводе из отделения в отделение внутри одной медицинской организации на оплату предъявляется один законченный случай лечения по профилю отделения соответствующего основному заключительному диагнозу, за исключением переводов из отделения патологии беременности в родильное отделение (в данной ситуации на оплату предъявляется два законченных случая, с отражением в реестре счета двух номеров позиций реестра).

 

Собственно говоря, можно ориентироваться на п. 15 соглашения о тарифах на 2012 год.

 

Поле NHISTORY служит для объединения в законченный случай посещений в поликлинике. По стационару нескольких записей с одним NHISTORY быть не должно. Т.е. по стационарной помощи случай д.б. законченный и выставляться на оплату единовременно. Без частей по переводам.

 

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

  
Возникла проблема со СМО, а именно: СМО говорит, что поля в реестре, которые должны заполняться СМО не должны содержать значений (поля <OPLATA>, <SUMP>, <SANK_MEK>, <SANK_MEE>, <SANK_EKMP>, <SUMMAP>)

У нас поля: <SCHET>
    <SUMMAV>391834.68</SUMMAV>
    <SUMMAP>0.00</SUMMAP>
    <SANK_MEK>0.00</SANK_MEK>
    <SANK_MEE>0.00</SANK_MEE>
    <SANK_EKMP>0.00</SANK_EKMP>

<SLUCH>
        <SUMV>93.15</SUMV>
        <OPLATA>0</OPLATA>
        <SUMP>0.00</SUMP>
        <SANK_MEK>0.00</SANK_MEK>
        <SANK_MEE>0.00</SANK_MEE>
        <SANK_EKMP>0.00</SANK_EKMP>
Просят:
    <SUMMAV>391834.68</SUMMAV>
    <SUMMAP></SUMMAP>
    <SANK_MEK></SANK_MEK>
    <SANK_MEE></SANK_MEE>
    <SANK_EKMP></SANK_EKMP>
  </SCHET>
<SLUCH>
        <SUMV>93.15</SUMV>
        <OPLATA></OPLATA>
        <SUMP></SUMP>
        <SANK_MEK></SANK_MEK>
        <SANK_MEE></SANK_MEE>
        <SANK_EKMP></SANK_EKMP>

Как должны заполняться указанные поля?

1.       Поля, которые не должны заполняться – должны вообще отсутствовать в реестре, а не быть пустыми или содержать фиктивные значения. Т.е. указанные Вами поля (<OPLATA>, <SUMP>, <SANK_MEK>, <SANK_MEE>, <SANK_EKMP>, <SUMMAP>)не должны заполнятся нулями и вообще не должны присутствовать в реестрах от МО. Т.к. по формату обмена, если числовое поле присутствует, но не содержит значения, то оно приобретает значение 0 (ноль), а не NULL (пусто).

2.       Все эти поля являются условно-обязательными. В «Общих принципах» явно указано, что заполняются поля в ТФОМС или СМО.

3.       Более того, в «Общих принципах» описаны условия проверки данных полей. Хоть и не в таблице Д.1, а в таблице Е.2 (для МТР) – эти условия можно применить и для таблицы Д.2: SUMMAP = SUMMAV – (SANK_MEK + SANK_MEE + SANK_EKMP). Получается, что если заполнить содержимое полей SANK_* нулями, то тогда значение в поле SUMMAP должно быть выставлено в значение поля SAMMAV. Т.е. Вы указываете, что сумма, принятая к оплате, равна сумме выставленного к оплате. Что, как минимум, странно. Если же все заполнить нулями (или передать пустые значения полей), то не выполняется требование проверки значения поля SUMMAP.

4.       У нас в фонде значения полей SUMMAP, SUMP, OPLATA, SANK_* в реестрах от МО вообще игнорируются и никак не учитываются, по той простой причине, что не имеют для значения в данном виде реестров. Вернее, так: их значение не важно. СМО могла бы поступать так же, и просто игнорировать содержание/наличие/отсутствие данных полей в реестрах от МО. Они не мешают проведению МЭК , вообще при ней не учитываются. СМО просто может их сбросить и установить свои значения.