Для слабовидящих:   A+ A-
На главную Контакты Карта сайта
Найти
Регистрация

Вниманию жителей Челябинской области!

ТФОМС Челябинской области напоминает, что при изменении данных документа, удостоверяющего личность, а также при получении нового паспорта, Вам необходимо обратиться в Вашу страховую медицинскую организацию (её контактные данные указаны в полисе ОМС) в течение одного месяца со дня, когда эти изменения произошли.


Вернуться к списку тем

Обработка поданых NATIVE

Bost - 07.12.2015

почему так долго стали обрабатываться файлы отчетов ? Файл принят в 11:30 часов в обработку попал в 16:21. Мы за один день утром направленный файл успеваем получить ответ либо вечером либо утром другого дня. Такая большая очередь в обработке ?

EOmelchenko - 07.12.2015

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

Bost - 04.01.2016

почему не отвечает телефон службы технической поддержки. сегодня 4 января 2016 года с 10:30 пытаюсь дозвониться. ну хоть кто нибудь бы снял трубку. не понятно даже принимаются ли отчеты или нет. то провайдер МЕГАФОН линию чинил между Челябинском и Магнитогорском (координатор был недоступен в медис-транспорте), теперь после отправки в 10:30 молчок.

EOmelchenko - 11.01.2016

Добрый день. Файлы отчетов принимаются в штатном режиме.

Bost - 29.02.2016

В новой версии Medis при формировании NATIVE заполняется новые поле GUID1 , которое генерируется самой программой. Как нам поступать если данные для NATIVE.DBF формируются во внешней программе, а не в ПО Medis ? Самим формировать GUID ? или не заполнять данное поле ? Объясните назначение данного поля ?

EOmelchenko - 29.02.2016

Добрый день. Описание поля GUID1 приведено в совместном приказе Минздрава Челябинской области и ТФОМС Челябинской области "О внесении изменений в приказ Министерства здравоохранения Челябинской области и территориального фонда обязательного медицинского страхования Челябинской области от 27.01.2015г. №92/37/1". Приказ будет в ближайшее время опубликован в разделе Техподдержка-Правила инф.взаимодействия. В феврале 2016 года допускается не заполнять поле GUID1.

Bost - 15.03.2016

Сегодня 15.03.2016 г. С нетерпением ждём описания поля GUID1 из совместного приказа Минздрава Челябинской области и ТФОМС. Приложение №1 (Структура файлов персонифицированного учета медицинской помощи) к Приказу №92-37-1 от 27.01.2015, которое сейчас опубликовано в разделе "Техподдержка-Правила инф.взаимодействия" , не содержит такого поля.

EOmelchenko - 15.03.2016

Добрый день. Описание поля GUID1 приведено в совместном приказе Минздрава Челябинской области и ТФОМС Челябинской области "О внесении изменений в приказ Министерства здравоохранения Челябинской области и территориального фонда обязательного медицинского страхования Челябинской области от 27.01.2015г. №92/37/1". Приказ будет в ближайшее время опубликован в разделе Техподдержка-Правила инф.взаимодействия. В феврале-марте 2016 года допускается не заполнять поле GUID1.

Bost - 09.11.2016

в новой структуре NATIVE появились новые поля [GUID2],[SUMD1_T] ,[SUMD1_V] ,[SUMD1_P] ,[SUMD2_T] ,[SUMD2_V] ,[SUMD2_P] где найти описание этих полей ? Приложение №1 (Структура файлов персонифицированного учета медицинской помощи) к Приказу №92-37-1 от 27.01.2015, которое сейчас опубликовано в разделе "Техподдержка-Правила инф.взаимодействия" , не содержит таких полей.

EOmelchenko - 11.11.2016

Добрый день. Совместный приказ Минздрава Челябинской области и ТФОМС Челябинской области от "О внесении изменений в приказ Министерства здравоохранения Челябинской области и территориального фонда обязательного медицинского страхования Челябинской области от 27.01.2015г. №92/37/1". опубликован в разделе Техподдержка-Правила инф.взаимодействия.

Bost - 01.12.2016

В новой структуре NATIVE поле MEDUS_ID символьное (1000) , хотя согласно стандарта xBase Максимальный размер символьных полей 254. (http://www.clicketyclick.dk/databases/xbase/format/dbase_spec.html#DBASE_SPEC) Исходя из того, что Википедия https://ru.wikipedia.org/wiki/DBF прямо указывает на отсутствие какой-либо официальной стандартизации в настоящее время сложно гарантировать, что разрабатываемая прикладная программа будет писать и читать произвольный DBF-файл, но базовая совместимость всё-таки должна сохраняется. Это связано с кодированием длины поля (http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm) 1. 2 Field Descriptor Array 1 byte Field length in binary. т.е. под кодирование длины поля выделен 1 байт (в одном байте - 2^8-1 = 255) если файл NATIVE.DBF нужен только для конвертера в XML (XDconverter), то возможно и обойдется, но как пользоваться этим DBF страховым компаниям и ЛПУ после обратной конвертации ответа-ведомости из XML в DBF ? в Microsoft Office и Open(Libre) Office , а так же при использовании официальных драйверов ODBC и OLEDB такой файл коверкается как раз после поля MEDUS_ID. Выкручиваемся как можем. С ужасом ждём каждое новое обновление ПО от ТФОМС.

EOmelchenko - 01.12.2016

Добрый день. Правилами информационного взаимодействия при ведении персонифицированного учета медицинской помощи, оказанной застрахованным лицам в системе обязательного медицинского страхования Челябинской области (утв. приказом Министерства здравоохранения Челябинской области и Территориального фонда обязательного медицинского страхования Челябинской области от 27.01.2015 г. № 92/37/1) (далее - Правила информационного взаимодействия) утверждена структура файлов персонифицированного учета медицинской помощи (Приложение 1 Правил информационного взаимодействия), которые имеют формат XML. Ознакомиться с Правилами информационного взаимодействия Вы можете на сайте ТФОМС Челябинской области в разделе "Техподдержка-Правила информационного взаимодействия".

Bost - 01.12.2016

Спасибо за ответ. Мне понятно, что именно на конвертер (XDconverter) и расчитана работа по выгрузке из MEDIS и PCLINIC файла NATIVE.DBF и другое применение выгружаемых данных не предусматривается, кроме как для конвертирования и обмена XML файлами.

Bost - 31.01.2017

Где можно ознакомиться с алгоритмом заполнения новых (OBR_VIS,CNT_VISIT,VISIT_NXT) полей в NATIVE ? Как заполняются поля DATE_BEG , DATE_END , VISIT_DATE, GUID1,GUID2 для Обращения и посещений в рамках обращений и разовых посещений ? Можно ли где то на сайте найти новые "Правила информационного взаимодействия" с описанием новых полей и правил их заполнения ?

EOmelchenko - 31.01.2017

Обратитесь по тел. 8 (351) 211-07-13

Bost - 10.03.2017

Добрый день ! Как можно узнать, что посланный отчет поставлен в обработку или хотя бы принят и поставлен в очередь ? Если нет ответа в "ПШЧ" в "Деловой почте", то значит не прочитано и не получено ? Шлём как в пустоту. Никакой реакции. У нас в "Отправленных" есть, а ответа никакого.

EOmelchenko - 10.03.2017

Добрый день. Обратитесь, пожалуйста, в техподдержку по тел. 8 (351) 211-06-87.

Bost - 13.09.2018

Добрый день ! В новой структуре NATIVE поля ONK_SL,NAPR,ONK_USL символьные (1000), что не соответствует стандарту xBase. (повторяется старая история как с MEDUS_ID см. пост "Bost - 01.12.2016" на этой странице) и хотя я так понял из XDконвертера v5.0.1.2 , что заполнятся они должны по типу вложенного куска XML(согласно схеме h_3.1.xsd): , но это не меняет сути. Я заполнил эти поля кусками XML и VED98 уже не ругается (хотя ему всё равно что там написано), но прочитать этот файл DBF стандартизованные средства (DBASE драйверы,MSDASQL Microsoft dBase Driver, Microsoft Visual FoxPro Driver) не могут прочитать сведения из поля , длиной больше 254. оно либо уродуется(читается как сведения след.поля, либо вообще не читаются). Вопрос состоит в том, будут ли в дальнейшем изменяться длины в соответствии со стандартом ? или нам придётся урезать сведений "Онкослучая" под длину стандарта ?

EOmelchenko - 13.09.2018

Добрый день. На формат DBF отсутствует официальная стандартизация. Вы, видимо, пользуетесь ПО, не распознающим в дескрипторе поля dbf-файла 17-ый байт, являющийся старшим байтом в слове, определяющем полную длину символьного поля. Вы можете либо обновить свое ПО, чтобы оно распознавало этот байт, либо использовать xml-формат. Вот ссылки на описание dbf-формата, которое вы можете использовать для обновления своего ПО: 1) https://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT 7. Field length for non-numerical fields. (FoxPro, Clipper) Byte 16 is normally field length (0-255) and byte 17 represents the high byte for field length (256-65535). 2) http://www.autopark.ru/ASBProgrammerGuide/DBFSTRUC.HTM Табл. 5. Дескриптор поля (кроме dBASE 7). Адрес Длина Назначение 0 0x00 11 Имя поля 11 0x0B 1 Тип поля 12 0x0C 4 Зарезервировано 16 0x10 1 Полная длина поля 17 0x11 1 Число десятичных разрядов; для типа C - второй байт длины поля 30 0x1E 13 Зарезервировано (всегда 0) 31 0x1F 1 Флаг тэга файла MDX (только в dBASE IV) Т.о. для character-поля полная длина определяется двумя байтами - 16 и 17.
 

Добавлять сообщения могут только зарегистрированные пользователи

Контакт-центр
в сфере ОМС
8 800 300 10 03
График работы:
Пн.-чт.: с 08:30 до 17:30
Пт.: с 8:30 до 16:15
В остальное время: режим записи звонков
Сервис обратной связи
Задать вопрос специалистам ТФОМС