ПРИКАЗ ГЛАВНОГО УПРАВЛЕНИЯ ЗДРАВООХРАНЕНИЯ АДМИНИСТРАЦИИ САМАРСКОЙ ОБЛАСТИ от 22.12.1998 № 397
"ОБ УТВЕРЖДЕНИИ "ПОЛОЖЕНИЯ О ПОРЯДКЕ ФОРМИРОВАНИЯ ЕДИНОГО ОБЛАСТНОГО БАНКА ДАННЫХ ОКАЗАННЫХ МЕДИЦИНСКИХ УСЛУГ НАСЕЛЕНИЮ САМАРСКОЙ ОБЛАСТИ"
Официальная публикация в СМИ:
публикаций не найдено
Положение, утвержденное данным документом, вступило в силу с 1 января 1999 года.
ГЛАВНОЕ УПРАВЛЕНИЕ ЗДРАВООХРАНЕНИЯ АДМИНИСТРАЦИИ
САМАРСКОЙ ОБЛАСТИ
ПРИКАЗ
от 22 декабря 1998 г. № 397
ОБ УТВЕРЖДЕНИИ "ПОЛОЖЕНИЯ О ПОРЯДКЕ ФОРМИРОВАНИЯ
ЕДИНОГО ОБЛАСТНОГО БАНКА ДАННЫХ ОКАЗАННЫХ
МЕДИЦИНСКИХ УСЛУГ НАСЕЛЕНИЮ САМАРСКОЙ ОБЛАСТИ"
В настоящее время в Самарской области созданы необходимые предпосылки для реализации мониторинга заболеваемости населения области. С 1996 года ведется сбор сведений о больных, получивших стационарную медицинскую помощь. В течение последних двух лет формируется база данных о медицинских услугах, оказанных населению амбулаторно-поликлиническими учреждениями.
Для передачи данных между ЛПУ, органами управления здравоохранением, страховыми медицинскими организациями и территориальным фондом обязательного медицинского страхования эффективно используется региональная медицинская вычислительная сеть.
К настоящему времени объем накопленных данных составил более полутора миллионов записей.
Вместе с тем, использование существующих информационных массивов для расчета различных медико-статистических, экономических показателей и ежеквартального мониторинга медицинских услуг в лечебно-профилактических учреждениях области затруднено из-за отсутствия единого стандарта для форматов таблиц областного банка данных.
В целях стандартизации информационного обмена в едином информационном пространстве системы здравоохранения Самарской области при формировании областного банка данных оказанных медицинских услуг приказываю:
1. Утвердить "Положение о порядке формирования единого областного банка данных оказанных медицинских услуг населению Самарской области".
2. Ввести указанное Положение в действие с 1 января 1999 года.
3. Руководителям органов управления здравоохранением, главным врачам лечебно-профилактических учреждений:
3.1. Обеспечить с 01.01.1999 переход на автоматизированный статистический учет пролеченных больных и оказанных медицинских услуг во всех подведомственных лечебно-профилактических учреждениях.
3.2. Обеспечить сбор сведений и ежеквартальную передачу данных в соответствии с требованиями "Положения о порядке формирования единого областного банка данных оказанных медицинских услуг населению Самарской области".
3.3. Представить вместе с годовым отчетом за 1998 год сведения о пролеченных больных и оказанных медицинских услугах за IV квартал текущего года.
4. Директору МИАЦ Тяпухиной Т.В.:
4.1. Обеспечить ежеквартальный сбор, обработку и передачу обновлений единого областного банка данных оказанных медицинских услуг в Главное управление здравоохранения Администрации Самарской области в соответствии с утвержденным Положением.
5. Контроль за исполнением настоящего приказа возложить на первого заместителя начальника Главного управления здравоохранения Администрации Самарской области Павлова В.В.
Начальник
Главного управления здравоохранения
Р.А.ГАЛКИН
Утверждаю
Начальник Главного управления
здравоохранения Администрации
Самарской области
___________________ Р.А. ГАЛКИН
"______" _______________1998 г.
ПОЛОЖЕНИЕ
О ПОРЯДКЕ ФОРМИРОВАНИЯ ЕДИНОГО ОБЛАСТНОГО БАНКА ДАННЫХ
ОКАЗАННЫХ МЕДИЦИНСКИХ УСЛУГ НАСЕЛЕНИЮ САМАРСКОЙ ОБЛАСТИ
Введение
В настоящее время в Самарской области созданы необходимые предпосылки для реализации мониторинга заболеваемости населения области.
Мониторинг заболеваемости должен осуществляться в рамках единой информационной системы областного уровня с использованием отображающих динамику здоровья населения моделей, которые могут быть использованы в качестве инструмента для разработки социально-экономических обоснований научно-практических программ борьбы с социально значимыми группами заболеваний.
Стандартизация информационных потоков в едином информационном пространстве позволит перейти от локальной задачи по обеспечению взаиморасчетов между ЛПУ и страховыми медицинскими организациями к формированию достоверных медико-экономических и статистических банков данных, на основе которых может быть решен более широкий круг задач, связанных с созданием предпосылок для мониторинга здоровья населения области.
Формирование на уровне ЛПУ первичной медико-статистической информации и научно обоснованный объем сведений, собираемых от ЛПУ, должны стать основным источником медицинской статистики для решения следующих задач:
- принятия обоснованных управленческих решений на всех уровнях (от ЛПУ до Администрации области и Губернской Думы);
- анализа деятельности системы здравоохранения области и подготовки установленных форм государственной статистической отчетности;
- формирования обоснованной территориальной программы по охране здоровья населения;
- обеспечения информационной поддержки законодательной инициативы органов управления здравоохранением, ТФОМС, санитарного и экологического надзора, органов социальной защиты;
- оптимизации структуры медицинской сети и видов оказываемой медицинской помощи в области;
- моделирования и оптимизации ресурсов, выделенных на охрану здоровья населения;
- предоставления медицинской статистической информации страховым медицинским организациям для проведения актуарных расчетов с учетом потребности средств на одного застрахованного;
- контроля за диспансерным обслуживанием регламентированных групп больных;
- анализа здоровья населения и качества деятельности ЛПУ.
Перечисленные задачи указывают на необходимость практического применения автоматизированной системы сбора и анализа медико-экономической и статистической информации, направленной на решение указанных проблем и позволяющей:
- полно и в достаточной степени достоверно контролировать потребности населения области в медицинских услугах;
- в необходимом объеме полно и правильно учитывать работу медицинских учреждений;
- рационально подходить с точки зрения социальной значимости к реализации тех или иных видов медицинской помощи, а также оказывать помощь в формировании необходимых финансовых ресурсов в соответствии с территориальной программой обязательного медицинского страхования;
- объективно планировать и контролировать расходование финансовых средств, направляемых на содержание инфраструктуры системы здравоохранения региона.
Для нормального функционирования указанной системы помимо компьютерных технологий необходимо соответствующее организационное обеспечение. Одним из элементов этого организационного обеспечения является данное Положение.
Основной целью введения данного Положения является регламентация порядка сбора и обмена информацией, которая позволит осуществлять ежеквартальный мониторинг медицинских услуг в лечебно-профилактических учреждениях области, рассчитывать различные медико-статистические показатели и периодически проводить адекватные расчеты и анализ стоимости программы ОМС.
1. Назначение и область применения
Основным назначением настоящего Положения является стандартизация информационных потоков в едином информационном пространстве системы здравоохранения Самарской области. Положение определяет:
1. Субъекты информационного взаимодействия, участвующие в формировании и использовании единого областного банка данных;
2. Структуру баз данных, входящих в состав единого областного банка медицинских услуг, оказанных населению Самарской области в лечебно-профилактических учреждениях;
3. Структуру информационных потоков;
4. Сроки и периодичность представления информации;
5. Методику формального и логического контроля информационного наполнения полей баз данных.
Настоящее Положение обязательно к применению во всех лечебно-профилактических учреждениях Самарской области, оказывающих медицинские услуги, независимо от их формы собственности и ведомственной принадлежности.
Настоящее Положение использует некоторые понятия и содержит соответствующие ссылки на "Положение о порядке информационного взаимодействия в системе обязательного медицинского страхования на территории Самарской области".
2. Субъекты информационного взаимодействия
Субъектами информационного взаимодействия при формировании единого областного банка данных оказанных медицинских услуг являются:
1. Главное управление здравоохранения Администрации Самарской области (ГУЗАСО);
2. Муниципальные органы управления здравоохранением и центральные городские (районные) больницы Самарской области;
3. Самарский областной медицинский информационно-аналитический центр (МИАЦ);
4. Организация, занятая оказанием медицинских услуг (лицо, занимающееся частной медицинской практикой).
3. Состав передаваемой информации
3.1. Информационные пакеты
Информация, подлежащая включению в банк данных медицинских услуг, оказанных населению Самарской области, подразделяется на несколько типов информационных массивов, каждый из которых характеризуется определенным составом и форматом данных. Использование форматов данных, отличающихся от регламентированных Положением, не допускается.
Обмен данными между отправителем и адресатом осуществляется посредством передачи информационных пакетов - созданных архиватором ARJ архивных файлов со специально сформированными мнемоническими именами. В архивах содержатся фрагменты соответствующих баз данных, представляющие собой набор взаимосвязанных файлов таблиц в формате DBF. Типы передаваемых информационных пакетов описаны ниже:
Присутствующий в таблице параметр SKIND соответствует типу медицинских услуг по классификации, принятой в "Положении о порядке информационного взаимодействия в системе ОМС на территории Самарской области". В таблице также использованы следующие обозначения:
LLLLL - пятизначный числовой код субъекта информационного взаимодействия, сформировавшего пакет, записанный с лидирующими нулями.
YMD - дата формирования пакета (равная дате в поле OUTDATE сопроводительного файла INVOICE.DBF, описанного ниже) в свернутом формате. Здесь: Y - последняя цифра номера года; M - месяц в шестнадцатиричной системе счисления (для месяцев с января по декабрь - соответственно 1, 2, 3, 4, 5, 6, 7, 8, 9, A(10), B(11), C(12); D - число месяца в системе счисления по основанию 32 (для чисел с 1 по 31 - соответственно 1, 2, 3, 4, 5, 6, 7, 8, 9, A(10), B(11), C(12), D(13), E(14), F(15), G(16), H(17), I(18), J(19), K(20), L(21), M(22), N(23), O(24), P(25), Q(26), R(27), S(28), T(29), U(30), V(31)).
В качестве примера рассмотрим информационный пакет, содержащий информацию о госпитализациях, сформированный ОКБ им. Калинина (код 6002) 25 октября 1998 г. Имя пакета в этом случае будет 06002HSP.8AP.
Структура таблиц баз данных, входящих в состав информационных пакетов, описана далее в настоящем Положении. Все субъекты, в обязанности которых входит формирование и передача информации, подлежащей включению в банк данных медицинских услуг, оказанных населению Самарской области, обязаны привести используемое ими программное обеспечение независимо от того, кто является его производителем, в соответствие с требованиями настоящего Положения.
Ниже описываются требования к составу и содержанию информации, находящейся в информационных пакетах.
Каждый информационный пакет любого типа должен содержать в своем составе помимо файлов основных таблиц, перечисленных в пункте 3.1, также сопроводительный информационный файл INVOICE.DBF, представляющий собой таблицу типа DBF, содержащую одну запись, в которую заносятся сведения об информационном пакете.
----T----------T-------------------------------------------------T------¬
¦ № ¦ Имя поля ¦ Содержимое поля ¦ Тип ¦
¦п/п¦ ¦ ¦ ¦
+---+----------+-------------------------------------------------+------+
¦ 1 ¦ LPU ¦Код учреждения, сформировавшего пакет ¦ N5 ¦
+---+----------+-------------------------------------------------+------+
¦ 2 ¦ PACKTYPE ¦Тип информационного пакета (согласно табл. 3.1) ¦ C3 ¦
+---+----------+-------------------------------------------------+------+
¦ 3 ¦ PACKET ¦Полное имя файла информационного пакета ¦ C12 ¦
+---+----------+-------------------------------------------------+------+
¦ 4 ¦ OUTDATE ¦Дата формирования информационного пакета ¦ D8 ¦
+---+----------+-------------------------------------------------+------+
¦ 5 ¦ REMARK ¦Словесное описание содержимого пакета ¦ С64 ¦
+---+----------+-------------------------------------------------+------+
¦ 6 ¦ BEGDATE ¦Начальная дата периода выгрузки информации ¦ D8 ¦
+---+----------+-------------------------------------------------+------+
¦ 7 ¦ ENDDATE ¦Конечная дата периода выгрузки информации ¦ D8 ¦
+---+----------+-------------------------------------------------+------+
¦ 8 ¦FILECOUNT ¦Общее количество файлов в пакете без учета¦ N2 ¦
¦ ¦ ¦сопроводительного файла ¦ ¦
+---+----------+-------------------------------------------------+------+
¦ 9 ¦ FILESIZE ¦Общий объем файлов в пакете без учета размера¦ N12 ¦
¦ ¦ ¦сопроводительного файла (в байтах) ¦ ¦
+---+----------+-------------------------------------------------+------+
¦10 ¦REPEATDATE¦Максимально допустимая дата повторной передачи¦ D8 ¦
¦ ¦ ¦исправленной информации ¦ ¦
L---+----------+-------------------------------------------------+-------
Сопроводительный файл INVOICE.DBF в обязательном порядке должен присутствовать в каждом информационном пакете, его отсутствие автоматически интерпретируется как ошибка.
3.3. Файл примечания README.TXT
Каждый информационный пакет любого типа может содержать в своем составе помимо файлов основных таблиц и сопроводительного файла INVOICE.DBF также файл примечания README.TXT, в который может быть занесена любая текстовая информация в формате ASCII (кодовая страница 866).
Файл примечания README.TXT является необязательным, и его отсутствие в составе информационного пакета ошибкой не является.
3.4. Общие требования к заполнению полей баз данных
Все поля баз данных являются обязательными для заполнения. Для предотвращения ошибок, возникающих при использовании нестандартных драйверов клавиатуры, символьная информация подвергается дополнительной обработке, связанной с заменой всех латинских букв сходными по начертанию русскими буквами (A, B, C, E, H, K, M, O, P, T, X).
Все данные в символьные поля заносятся в верхнем регистре. Лидирующие пробелы должны быть удалены.
При отсутствии значений символьные поля не заполняются, а в цифровые поля заносится ноль.
Если длина данных в символьных полях превышает длину поля таблицы, то значение поля усекается.
Текстовая информация в таблицах и других файлах должна представляться с использованием кодовой страницы 866.
4. Описание структуры баз данных,
входящих в состав информационных пакетов
База данных, содержащаяся внутри информационного пакета любого типа, всегда имеет одну главную таблицу и (необязательно) определенный набор подчиненных таблиц. Связь между таблицами в пределах одного пакета осуществляется по специальному ключевому полю TKEY. В пределах главной таблицы значения ключевого поля TKEY должны быть уникальны.
Каждая запись главной таблицы в пакетах всех типов содержит два технологических поля, предназначенных для контроля за процессом корректировки и исправления информации в базах данных: LASTMOD - дата последней модификации информации в записи главной таблицы или в связанных с ней по ключевому полю TKEY записях подчиненных таблиц; LASTEXP - дата последней передачи данных, содержащихся в текущей записи главной и связанных с ней по полю TKEY записях подчиненных таблиц.
4.1. Структура таблиц базы данных госпитализаций (пакет HSP)
4.1.1. Таблица HOSPCARD.DBF (главная) -
сведения о случае госпитализации
TKEY - уникальный ключ случая обслуживания. Используется для реляционного связывания записей главной и подчиненных таблиц. Методика формирования номера изложена в пункте 4.1.1.3.
LPU - код ЛПУ госпитализации.
MEDDOC - номер истории болезни (карты выбывшего), должен быть уникален для стационара в пределах минимум одного календарного года (по дате поступления).
SURNAME, NAME, SECNAME - фамилия, имя и отчество пациента.
SEX - пол пациента: 1 - мужской, 2 - женский.
BIRTHDAY - дата рождения пациента.
NDOC, NSDOC, SDOC - номер серии, серия и номер документа, удостоверяющего личность пациента. Примеры заполнения: для паспортов бывшего СССР: если паспортные данные XII-ЕР № 234567, то поле NSDOC = 12, SDOC = "ЕР", NDOC = 234567; для новых российских паспортов: если паспортные данные 36 97 012024, то поле NSDOC = 36, SDOC = "97", NDOC = 012024.
DOCTYPE - характеризует документ, согласно которому выдан полис: 1 - паспорт, 2 - свидетельство о рождении, 3 - паспорт граждан, на которых не заполняются адресные данные (сотрудники правоохранительных органов), 4 - паспорт иностранца (паспортные данные могут быть заполнены не полностью).
SPOLIS, NPOLIS - серия и номер страхового полиса ОМС.
INSCAT - страховая категория пациента: 1 - застрахованный работающий житель Самарской области, 2 - застрахованный неработающий житель Самарской области, 3 - временно не застрахованный житель Самарской области, 4 - лицо без определенного места жительства, 5 - иногородний гражданин РФ, 6 - иностранец.
STATUS - социальное положение: 1 - работающий, 2 - дошкольник, 3 - учащийся, 4 - безработный, 5 - беженец, 6 - временно не работающий, 7 - пенсионер.
RGN1, RGN2, RGN3 определяют место прописки пациента и заполняются значениями из справочника STANDART.DBF.
ANONYMOUS - признак анонимного лечения: 1 - да, 2 - нет. Для лица, проходящего анонимное лечение, поля SURNAME, NAME, SECNAME, SPOLIS, NPOLIS, NDOC, NSDOC, SDOC, DOCTYPE могут не заполняться.
INSURER - код страховой медицинской организации, выдавшей пациенту полис ОМС. Заполняется значениями из справочника SMO.DBF.
LPUBASE - код ЛПУ по месту прикрепления пациента. Заполняется значениями из справочника LPU.DBF.
LPUOUT - код ЛПУ, направившего пациента на лечение. Заполняется значениями из справочника LPU.DBF.
SPRINT - признак экстренной доставки: 1 - да, 2 - нет.
FIRSTDAY - срок доставки пациента в стационар с момента начала заболевания: 1 - до 6 часов, 2 - от 7 до 24 часов, 3 - позже 24 часов. Если доставка не экстренная (SPRINT не равно 1), заполняется значением 3.
FIRST - признак повторной госпитализации: 1 - поступил в данный стационар впервые в текущем календарном году, 2 - повторно.
STARTDATE - дата начала лечения в стационаре.
ENDDATE - дата выписки из стационара. В случае смерти пациента проставляется дата смерти.
DS_MAI№ - окончательный (основной) клинический диагноз. Заполняется из справочника MKB10.DBF.
FINISH - исход заболевания: 1 - выписался без нарушения режима, 2 - умер, 3 - переведен, 4 - выписался с нарушением режима, 5 - лечение продолжается (только для фтизиатрических и психиатрических больных с длительным сроком пребывания). Если исход заболевания равен 2, то в таблице HSPDIAGS должны присутствовать три связанные записи, соответствующие: 1) непосредственной причине смерти, 2) заболеванию, вызвавшему смерть, 3) патологоанатомическому диагнозу.
RESULT_H - результат лечения: 1 - выздоровление, 2 - улучшение, 3 - без перемен, 4 - ухудшение.
RES_RW - результат обследования на RW: 1 - отрицательный, 2 - положительный.
DOCTOR - личный идентификационный код лечащего врача. Заполняется значениями из справочника DOCTORS.DBF.
NEWBOR№ - признак новорожденного. Принимает значение, большее 1, если пациент - новорожденный (заносятся все данные матери, за исключением пола, даты рождения и диагнозов), при этом данное поле равно порядковому номеру родившегося плюс единица (например, при рождении двойни формируются 2 записи со значениями этого поля 2 и 3).
BABYMASS - масса новорожденного в граммах.
PR_TERM - срок беременности в неделях.
SKIND - тип оказанной медуслуги, для информационного пакета HSP может принимать значение 1 - пребывание в круглосуточном стационаре, 7 - в стационаре дневного пребывания.
BEDPROF - профиль койки. Заполняется значениями из справочника LPUPL.DBF.
BASEROF - профиль отделения. Заполняется значениями из справочника LPUPL.DBF.
TYPEOPER - вид лечения. Заполняется значениями из справочника TYPEOPER.DBF.
DSLEVEL - степень тяжести заболевания, обусловливающая дополнительные расходы на лечение. Представляет собой целое число. Для каждого диагноза градация возможных степеней тяжести заболевания определяется действующим прейскурантом.
COSTREAS - дополнительный фактор, влияющий на определение стоимости лечения. Определяется для особых случаев оплаты госпитализации в конкретных медицинских учреждениях или отделениях. Заполняется из справочника COSTREAS.DBF.
PAYTYPE - вид оплаты: 1 - по ОМС, 2 - средства граждан, 3 - по договору с организацией, 4 - добровольное страхование, 5 - бюджет.
PRICECODE - код тарифа на медицинскую услугу. Заполняется значениями из действующего на дату выбытия справочника KSGPRICE.DBF.
PART - коэффициент изменения тарифа в зависимости от условий договора.
SUBTOTAL - итоговая сумма, выставленная к оплате лечения.
LASTMOD - дата последней модификации информации в текущей записи или в реляционно связанных с ней записях подчиненных таблиц.
LASTEXP - дата последней выгрузки информации для текущей записи и реляционно связанных с ней записей подчиненных таблиц.
4.1.1.3. Методика формирования
уникального ключа случая обслуживания
Поле TKEY - уникальный ключ случая обслуживания - заполняется однократно при первичном формировании записи и не изменяется в дальнейшем. Представляет собой строку вида LLLLLYYMMDDCCCCС, где:
- LLLLL - код медучреждения, где оказывались медицинские услуги;
- YYMMDD - год, месяц и день формирования записи;
- ССССС - логический номер записи, удовлетворяющий требованию обеспечения уникальности значений ключевого поля TKEY.
4.1.2. Таблица HSPINTO.DBF -
сведения об оперативных вмешательствах
4.1.2.1. Структура таблицы
----T-----------T---------------------------------------------T---------¬
¦ № ¦ Имя поля ¦ Комментарий ¦ Тип ¦
¦п/п¦ ¦ ¦ ¦
+---+-----------+---------------------------------------------+---------+
¦ 1 ¦ TKEY ¦Уникальный ключ случая обслуживания ¦ C16 ¦
+---+-----------+---------------------------------------------+---------+
¦ 2 ¦ INTO ¦Код вмешательства ¦ N6.2 ¦
+---+-----------+---------------------------------------------+---------+
¦ 3 ¦ DATEOPER ¦Дата проведения оперативного вмешательства ¦ D8 ¦
+---+-----------+---------------------------------------------+---------+
¦ 4 ¦ TIMEOPER ¦Время проведения оперативного вмешательства ¦ N4.0 ¦
+---+-----------+---------------------------------------------+---------+
¦ 5 ¦ BADOPER ¦Осложнения вмешательства ¦ С8 ¦
+---+-----------+---------------------------------------------+---------+
¦ 6 ¦ DOCTOR ¦Код врача, производившего операцию ¦ C8 ¦
+---+-----------+---------------------------------------------+---------+
¦ 7 ¦ INTODEAD ¦Признак того, что операция является причиной¦ N1.0 ¦
¦ ¦ ¦смерти пациента ¦ ¦
L---+-----------+---------------------------------------------+----------
4.1.2.2. Описание полей
TKEY - уникальный ключ случая обслуживания.
INTO - код оперативного вмешательства. Заполняется значениями из справочника INTERV.DBF.
DATEOPER - проставляется дата проведения оперативного вмешательства.
TIMEOPER - время проведения оперативного вмешательства: первые первая и вторая цифры - часы, третья и четвертая цифры - минуты.
BADOPER - осложнения вмешательства.
INTODEAD - признак учета смерти пациента. Принимает значение, равное 1, если учет смерти осуществляется по данному вмешательству, и 2 - в противном случае. Заполняется лишь в случае, когда значение поля HOSPCARD.FINISH равно 2.
4.1.3. Таблица HSPDIAGS.DBF -
сведения об установленных диагнозах
TKEY - уникальный ключ случая обслуживания.
DS - диагноз. Заполняется из справочника MKB10.DBF.
DSTYPE - тип диагноза: 1 - диагноз направившего учреждения, 2 - диагноз при поступлении, 3 - диагноз сопутствующего заболевания, 4 - непосредственная причина смерти, 5 - заболевание, вызвавшее смерть, 6 - патологоанатомический диагноз, 7 - фактор, влияющий на состояние здоровья населения (раздел Z по МКБ-10).
При регистрации сведений, характеризующих репродуктивное здоровье населения (роды, аборты, сведения о новорожденных), таблица HSPDIAGS должна обязательно содержать хотя бы одну запись с признаком DSTYPE = 7.
4.1.4. Таблица HSPSHEET.DBF -
сведения о выданных больничных листах
TKEY - уникальный ключ случая обслуживания.
VID_NETR - вид временной нетрудоспособности: 1 - заболевание, 2 - несчастный случай, 3 - карантин, 4 - уход за больным, 5 - санаторно-курортное лечение, 6 - отпуск по беременности и родам.
BEGSHEET - дата выдачи листка нетрудоспособности. Если за время заболевания листок нетрудоспособности продлевался, указывается дата выдачи первичного листка.
ENDSHEET - дата закрытия листка нетрудоспособности. Если за время заболевания листок нетрудоспособности продлевался, указывается дата закрытия последнего листка.
SEXNURSE - пол лица, ухаживающего за пациентом: 1 - мужской, 2 - женский.
AGENURSE - возраст лица, ухаживающего за пациентом, в годах.
Поля SEXNURSE и AGENURSE заполняются только в случаях, когда лицу, ухаживающему за пациентом, листок нетрудоспособности выписывался и закрывался в стационаре.
4.1.5. Таблица HSPBED.DBF - сведения
об использовании коечного фонда
4.1.5.1. Структура таблицы
----T-------------T-------------------------------------------T---------¬
¦ № ¦ Имя поля ¦ Комментарий ¦ Тип ¦
¦п/п¦ ¦ ¦ ¦
+---+-------------+-------------------------------------------+---------+
¦ 1 ¦ STARTDATE ¦Дата начала отчетного периода ¦ D8 ¦
+---+-------------+-------------------------------------------+---------+
¦ 2 ¦ ENDDATE ¦Дата окончания отчетного периода ¦ D8 ¦
+---+-------------+-------------------------------------------+---------+
¦ 3 ¦ LPU ¦Код ЛПУ ¦ N5.0 ¦
+---+-------------+-------------------------------------------+---------+
¦ 4 ¦ SKIND ¦Тип услуги (тип стационара) ¦ N2.0 ¦
+---+-------------+-------------------------------------------+---------+
¦ 5 ¦ BEDPROF ¦Профиль койки ¦ N3.0 ¦
+---+-------------+-------------------------------------------+---------+
¦ 6 ¦ FAСT_BED ¦Количество коек на конец отчетного периода ¦ N5.0 ¦
+---+-------------+-------------------------------------------+---------+
¦ 7 ¦ AVG_BED ¦Среднее количество коек за отчетный период ¦ N8.2 ¦
+---+-------------+-------------------------------------------+---------+
¦ 8 ¦ ILL_BEG ¦Больных на начало периода ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦ 9 ¦ ENTERRED ¦Поступило больных всего ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦10 ¦ ENT_VILL ¦В том числе сельских жителей ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦11 ¦ ENT_BABY ¦В том числе детей до 14 лет ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦12 ¦ ILL_I№ ¦Переведено из других отделений ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦13 ¦ ILL_TO ¦Переведено в другие отделения ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦14 ¦ DRAW№ ¦Выписано больных ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦15 ¦ ILL_OUT ¦Выбыло больных в другие стационары ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦16 ¦ DEAD ¦Умерло больных ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦17 ¦ ILL_END ¦Больных на конец отчетного периода ¦ N6.0 ¦
+---+-------------+-------------------------------------------+---------+
¦18 ¦ BEDDAYS ¦Количество койко-дней (по графе 4 ф. 007/У)¦ N7.0 ¦
+---+-------------+-------------------------------------------+---------+
¦19 ¦ BEDDAYS13 ¦Количество койко-дней (по графе 13 ф.¦ N7.0 ¦
¦ ¦ ¦007/У) ¦ ¦
+---+-------------+-------------------------------------------+---------+
¦20 ¦ BD_VILL ¦В том числе сельских жителей ¦ N7.0 ¦
+---+-------------+-------------------------------------------+---------+
¦21 ¦ BD_MOTHER ¦В том числе матери, ухаживающие за детьми ¦ N7.0 ¦
L---+-------------+-------------------------------------------+----------
4.1.5.2. Описание полей
STARTDATE - дата начала отчетного периода.
ENDDATE - дата окончания отчетного периода.
LPU - код лечебно-профилактического учреждения.
SKIND - тип услуги. Для пакета HSP может принимать значения: 1 - круглосуточный стационар, 7 - стационар дневного пребывания.
BEDPROF - профиль койки.
FACT_BED - количество коек на конец отчетного периода.
AVG_BED - среднее количество коек за отчетный период.
ILL_BEG - больных на начало периода.
ENTERRED - поступило больных всего.
ENT_VILL - поступило сельских жителей.
ENT_BABY - поступило детей до 14 лет.
ILL_I№ - переведено из других отделений.
ILL_TO - переведено в другие отделения.
DRAW№ - выписано больных.
ILL_OUT - выбыло больных в другие стационары.
DEAD - умерло больных.
ILL_END - больных на конец отчетного периода.
BEDDAYS - количество койко-дней (по графе 4 ф. 007/У).
BEDDAYS13 - количество койко-дней (по графе 13 ф. 007/У).
BD_VILL - в том числе сельских жителей.
BD_MOTHER - в том числе матери, ухаживающие за детьми.
4.2. Структура таблиц базы данных о случае
амбулаторно-поликлинической помощи (пакет AMB)
4.2.1. Таблица AMBCARD.DBF (главная) - сведения
о случае амбулаторно-поликлинической помощи
TKEY - уникальный ключ случая обслуживания.
DSTYPE - тип диагноза, для пакета AMB возможно значение: 3 - диагноз сопутствующего заболевания.
DS - диагноз. Заполняется из справочника MKB10.DBF.
Описание поля NDISEASE аналогично описанию одноименного поля таблицы AMBCARD.DBF (пункт 4.2.1.2).
4.3. Структура таблиц базы данных
об услугах скорой медицинской помощи (пакет EMR)
4.3.1. Таблица EMRCARD.DBF (главная) - сведения
об услугах скорой и неотложной медицинской помощи
Для занесения данных перечислимого типа в поля таблиц баз данных используются электронные справочники - специальные таблицы формата DBF, содержащие определенный набор допустимых для этих полей значений.
Справочники распространяются среди всех субъектов информационного обмена без каких-либо ограничений в виде идентичных копий соответствующих файлов.
Все субъекты информационного обмена должны в безусловном порядке использовать версии справочников, актуальные на момент формирования информации, подлежащей включению в банк данных медицинских услуг, оказанных населению Самарской области.
Корректировка справочников осуществляется только организациями, ответственными за ведение справочников (МИАЦ, ТФОМС). Остальным субъектам информационного обмена вносить изменения в справочники в одностороннем порядке категорически запрещается.
5.2. Список используемых справочников
Ниже приводится перечень справочников, которые обязаны использовать субъекты информационного обмена при формировании информации, подлежащей включению в банк данных медицинских услуг, оказанных населению Самарской области.
Для обеспечения регулярности получения и контроля достоверности данных устанавливается ежеквартальная периодичность передачи информационных массивов в Самарский областной медицинский информационно-аналитический центр.
Прием информации за четвертый квартал осуществляется в соответствии с графиком приема годовых отчетов.
График приема для всех ЛПУ Самарской области с указанием конкретных дат должен ежеквартально публиковаться в Самарском областном медицинском вестнике.
Данный порядок информационного обмена не распространяется на существующую систему финансовых взаимоотношений субъектов ОМС.
6.2. Порядок передачи информации
Порядок передачи информации приведен на схеме.
1 - информация об оказанных медицинских услугах.
2 - сведения об ошибках в представленной информации.
3 - информация, удовлетворяющая спецификациям настоящего Положения.
4 - интегрированная база данных.
Лечебно-профилактические учреждения передают информацию об оказанных медицинских услугах по подчиненности:
в городах области - в соответствующий территориальный орган управления здравоохранением (поток 1);
в сельских районах - в центральную районную больницу (поток 1);
лечебно-профилактические учреждения областного подчинения и вневедомственные ЛПУ - непосредственно в МИАЦ (поток 1).
В МИАЦ создается интегрированная база данных по всем видам медицинских услуг, которая передается в ГУЗАСО (поток 4).
Информация передается в виде специальных информационных пакетов - архивных файлов, содержащих соответствующие фрагменты баз данных. Стандартные имена архивных файлов, которые необходимо использовать, приведены в пункте 3.1.
6.3. Способ передачи информации
Информация может быть передана в соответствующую инстанцию (см. рисунок) двумя способами:
- на магнитных носителях с курьером;
- по электронной почте на узел связи МИАЦ по адресам:
Актуальное состояние информации об оказанных медицинских услугах должно непрерывно поддерживаться в объеме, соответствующем последнему отчетному году, плюс информация предыдущего года. Информация, выходящая за пределы этого временного интервала, подлежит архивации и должна храниться в МИАЦ в течение семидесяти пяти лет.
6.5. Порядок выгрузки данных
из исходных информационных массивов в пакеты
Выгрузка данных из исходных информационных массивов осуществляется путем отбора записей, у которых дата выписки (ENDDATE), окончания лечения (LASTDATE), оказания услуги (ENDDATE) соответствует отчетному интервалу (от первого до последнего дня квартала).
Дата последней выгрузки данных проставляется в поле LASTEXP.
Одновременно с выгружаемыми данными формируется сопроводительный информационный файл (см. п. 3.2).
6.6. Порядок исправления ошибок
При обнаружении ошибок в передаваемой информации субъект, проводивший контроль, формирует специальный информационный пакет дефектуры типа DEF и отправляет его субъекту, первоначально сформировавшему исходный информационный пакет. После устранения ошибок повторная передача информационного пакета производится в полном объеме, т.е. в него включаются все записи таблиц баз данных за отчетный период, а не только исправленные.
6.7. Контроль достоверности и качества информации
Для обеспечения контроля достоверности информации используется многоступенчатая система формального и логического контроля правильности заполнения полей баз данных.
Формальный контроль (выявление нарушений правил заполнения карты или талона, связанных с отсутствием значений необходимых реквизитов) осуществляется соответствующими программными модулями и процедурами комплексов, формирующих карту выбывшего из стационара, талон амбулаторного пациента и другие исходные формы. Ответственность за наличие подобных ошибок возлагается на организации, представляющие первичную информацию.
Информация, подлежащая включению в единый областной банк данных оказанных медицинских услуг населению Самарской области, должна подвергаться формальному логическому контролю на предмет полноты и непротиворечивости заполнения полей баз данных, описанных в настоящем документе.
Контроль должен осуществляться как отправителем, так и получателем информации. Эксплуатируемые программные средства независимо от их производителя должны в безусловном порядке использовать описанную ниже в этой главе систему кодирования и обработки ошибок.
Получатель информации по результатам проверки формирует специальную базу данных дефектуры, в которой приводятся сведения о содержании и местонахождении ошибки (имена таблиц и полей, значения ключей). База данных дефектуры отправляется субъекту информационного взаимодействия, первоначально сформировавшему ошибочные данные, который обязан принять меры к устранению ошибок и передать исправленную информацию повторно. Исправления могут производиться только в смысловых предметных полях, модификация ключевых полей (TKEY) категорически запрещается.
Логический контроль, выявляющий нарушение установленных логических и смысловых соотношений между отдельными реквизитами или между значениями реквизитов и их границами, осуществляется путем автоматизированного и ручного выборочного контроля специалистами МИАЦ и ГУЗАСО.
6.8. Список критериев логического контроля
предъявленной информации
------------------------------------------------------------------------¬
¦ Описание критерия логического контроля ¦
+-----------------------------------------------------------------------+
¦Отсутствует код ЛПУ, оказавшего услугу (LPU) ¦
+-----------------------------------------------------------------------+
¦Не проставлена фамилия (SURNAME) ¦
+-----------------------------------------------------------------------+
¦Пустая дата рождения (BIRTHDAY) ¦
+-----------------------------------------------------------------------+
¦Дата рождения (BIRTHDAY) больше даты поступления (STARTDATE) ¦
+-----------------------------------------------------------------------+
¦Неверно заполнен пол (SEX) ¦
+-----------------------------------------------------------------------+
¦Отсутствует профиль отделения (LPUPROF) ¦
+-----------------------------------------------------------------------+
¦Отсутствует дата поступления (STARTDATE) ¦
+-----------------------------------------------------------------------+
¦Дата поступления (STARTDATE) больше даты выписки (ENDDATE) ¦
+-----------------------------------------------------------------------+
¦Результат лечения (RESULT_H) не заполнен или неверно заполнен ¦
+-----------------------------------------------------------------------+
¦Отсутствует дата выписки (ENDDATE) ¦
+-----------------------------------------------------------------------+
¦Отсутствует основной диагноз (DS_MAIN) ¦
+-----------------------------------------------------------------------+
¦Отсутствует или неверно указан тип медицинской услуги (SKIND) ¦
+-----------------------------------------------------------------------+
¦Отсутствует КСГ (PRICECODE) ¦
+-----------------------------------------------------------------------+
¦КСГ (PRICECODE) не соответствует типу стационара ¦
+-----------------------------------------------------------------------+
¦КСГ (PRICECODE) не найден в прейскуранте ¦
+-----------------------------------------------------------------------+
¦Дата операции (DATEOPER) задана неверно ¦
+-----------------------------------------------------------------------+
¦Код операции (INTO) отсутствует или задан неверно ¦
+-----------------------------------------------------------------------+
¦Тип операции (TYPEOPER) отсутствует или задан неверно ¦
+-----------------------------------------------------------------------+
¦Не проставлен номер карты (MEDDOC) ¦
+-----------------------------------------------------------------------+
¦Неверно указан профиль койки (BEDPROF) ¦
+-----------------------------------------------------------------------+
¦Неполное или пустое имя (NAME) ¦
+-----------------------------------------------------------------------+
¦Неполное или пустое отчество (SECNAME) ¦
+-----------------------------------------------------------------------+
¦Регион жительства (RGN1-RGN2-RGN3) не заполнен или заполнен неверно ¦
+-----------------------------------------------------------------------+
¦Отсутствуют данные о страховке (SPOLIS, NPOLIS, INSURER, LPUBASE) ¦
+-----------------------------------------------------------------------+
¦Вид оплаты (PAYTYPE) не заполнен или неверно заполнен ¦
+-----------------------------------------------------------------------+
¦Исход заболевания (FINISH) не заполнен или заполнен неверно ¦
+-----------------------------------------------------------------------+
¦Доля помощи (PART) равна нулю ¦
+-----------------------------------------------------------------------+
¦Цена (SUBTOTAL) равна нулю ¦
+-----------------------------------------------------------------------+
¦Отсутствует тип больничного листа ¦
+-----------------------------------------------------------------------+
¦Отсутствует патологоанатомический диагноз ¦
+-----------------------------------------------------------------------+
¦Неверно заполнен статус (STATUS) ¦
+-----------------------------------------------------------------------+
¦Отсутствует код направившего ЛПУ (LPUOUT) ¦
+-----------------------------------------------------------------------+
¦Отсутствует направительный диагноз (DS_WAY) ¦
+-----------------------------------------------------------------------+
¦Дублирован номер документа (MEDDOC) в пределах одного информационного¦
¦пакета ¦
+-----------------------------------------------------------------------+
¦Не заполнен характер заболевания (NDISEASE) при наличии диагноза¦
¦(DIAGS) ¦
+-----------------------------------------------------------------------+
¦Не заполнен характер заболевания (NDISEASE) при наличии диагноза¦
¦(DS_MAIN) ¦
+-----------------------------------------------------------------------+
¦Дата оказания услуги (AMBSERV.ENDDATE) вне интервала дат начала и¦
¦окончания лечения (AMBCARD.STARTDATE и AMBCARD.ENDDATE) ¦
L------------------------------------------------------------------------
6.9. База данных дефектуры предъявленной информации
6.9.1. Таблица DEFECT - список
обнаруженных ошибочных ситуаций
6.9.1.1. Структура таблицы
----T----------T-----------------------------------------------T---------¬
¦ № ¦ Имя поля ¦ Комментарий ¦ Тип ¦
¦п/п¦ ¦ ¦ ¦
+---+----------+-----------------------------------------------+---------+
¦ 1 ¦ PACKET ¦Имя проверяемого исходного информационного¦ C12 ¦
¦ ¦ ¦пакета ¦ ¦
+---+----------+-----------------------------------------------+---------+
¦ 2 ¦ TKEY ¦Идентификатор случая обслуживания, определяющий¦ C16 ¦
¦ ¦ ¦запись в главной таблице пакета, где обнаружена¦ ¦
¦ ¦ ¦ошибка ¦ ¦
+---+----------+-----------------------------------------------+---------+
¦ 3 ¦ ERRCODE ¦Код ошибки ¦ N4 ¦
+---+----------+-----------------------------------------------+---------+
¦ 4 ¦ TABLE ¦Имя таблицы, в которой обнаружена ошибка ¦ C8 ¦
+---+----------+-----------------------------------------------+---------+
¦ 5 ¦ FIELDS ¦Список полей или взаимосвязанных групп полей,¦ С64 ¦
¦ ¦ ¦в которых обнаружена ошибка ¦ ¦
+---+----------+-----------------------------------------------+---------+
¦ 6 ¦ DESCRIPT ¦Описание ошибочной ситуации ¦ C64 ¦
L---+----------+-----------------------------------------------+----------
6.9.1.2. Описание полей
PACKET - имя исходного проверяемого информационного пакета.
TKEY - значение ключа, однозначно идентифицирующего случай обслуживания (госпитализацию, амбулаторно-поликлинический случай и т.п.), и соответственно определяющего запись в главной таблице пакета.
ERRCODE - идентификационный код, определяющий смысл ошибочного состояния. Возможные значения кодов приведены в следующем пункте этой главы.
TABLE - имя таблицы базы данных из информационного пакета PACKET, в которой обнаружена ошибка.
FIELDS - список полей, в которых обнаружена ошибка, или взаимосвязанных групп полей, содержащих противоречивую информацию. Перечисление полей и групп полей осуществляется через запятую. Взаимосвязанные поля в группе перечисляются через дефис (знак минус). Поля из таблиц, отличающихся от указанной в поле TABLE, приводятся с дополнительным указанием имени таблицы.
DESCRIPT - описание или иная информация, касающаяся обнаруженной ошибочной ситуации, изложенные на естественном языке. Например, в этом поле могут быть приведены сами ошибочные значения, содержащиеся в полях таблиц, чтобы обратить внимание на опечатки и несоответствия.
В качестве примера рассмотрим следующую ситуацию. В информационном пакете 06002HSP.845 в записи таблицы AMBSERV с ключом TKEY, равным 0600298032610458, в поле ENDDATE указана дата услуги, не лежащая в интервале между датами начала и окончания лечения (соответственно поля STARTDATE и LASTDATE таблицы AMBCARD). В этом случае в таблицу дефектуры будет добавлена запись со следующими значениями полей: PACKET = "06002AMB.845", TKEY = "0600298032610458", ERRCODE = 104, TABLE = "AMBSERV", FIELDS = "ENDDATE-AMBCARD.STARTDATE-AMBCARD.LASTDATE".
6.10. Сообщения об ошибках
-------T----------------------------------------------------------------¬
¦ Код ¦ Описание ошибки ¦
+------+----------------------------------------------------------------+
¦ Логические ошибки заполнения полей ¦
+------T----------------------------------------------------------------+
¦ 101 ¦Отсутствует значение в обязательном для заполнения поле. Имя¦
¦ ¦ошибочного поля указывается в поле FIELDS таблицы дефектуры¦
¦ ¦DEFECT ¦
+------+----------------------------------------------------------------+
¦ 102 ¦Значение числового поля выходит за допустимые границы. Имя¦
¦ ¦ошибочного поля указывается в поле FIELDS таблицы дефектуры¦
¦ ¦DEFECT ¦
+------+----------------------------------------------------------------+
¦ 103 ¦Значение поля перечислимого типа выходит за пределы допустимого¦
¦ ¦множества. Имя ошибочного поля указывается в поле FIELDS таблицы¦
¦ ¦дефектуры DEFECT ¦
+------+----------------------------------------------------------------+
¦ 104 ¦Недопустимое сочетание (логическое противоречие) значений полей.¦
¦ ¦Имена ошибочных полей указываются в поле FIELDS таблицы¦
¦ ¦дефектуры DEFECT ¦
+------+----------------------------------------------------------------+
¦ Технические ошибки в структуре информационных пакетов ¦
+------T----------------------------------------------------------------+
¦ 901 ¦В информационном пакете отсутствует сопроводительный файл¦
¦ ¦INVOICE.DBF ¦
+------+----------------------------------------------------------------+
¦ 902 ¦Несоответствие структуры сопроводительного файла INVOICE.DBF¦
¦ ¦требованиям настоящего Положения ¦
+------+----------------------------------------------------------------+
¦ 903 ¦Несоответствие имени файла информационного пакета и значений¦
¦ ¦полей LPU, PACKET, OUTDATE в сопроводительном файле INVOICE.DBF ¦
+------+----------------------------------------------------------------+
¦ 904 ¦Отсутствие в информационном пакете обязательной для этого типа¦
¦ ¦пакета таблицы ¦
+------+----------------------------------------------------------------+
¦ 905 ¦Несоответствие структуры таблицы в составе информационного¦
¦ ¦пакета требованиям настоящего Положения ¦
+------+----------------------------------------------------------------+
¦ 906 ¦Нарушение ссылочной целостности базы данных по полю TKEY внутри¦
¦ ¦информационного пакета ¦
+------+----------------------------------------------------------------+
¦ 907 ¦Дублирование значений ключевого поля TKEY в главной таблице¦
¦ ¦информационного пакета ¦
L------+-----------------------------------------------------------------
7. Контроль выполнения Положения
Контроль за выполнением требований настоящего Положения осуществляют:
- Главное управление здравоохранения Администрации Самарской области;
- Самарский областной медицинский информационно-аналитический центр.
Возложение обязанностей на конкретных исполнителей по контролю за выполнением требований данного Положения осуществляется соответствующими приказами по указанным учреждениям.
8. Заключение
Содержащиеся в данном документе правила обязывают все лечебно-профилактические учреждения на территории Самарской области неукоснительно соблюдать порядок формирования единого областного банка данных оказанных медицинских услуг.
Данное Положение основано на сложившихся технологиях информационного обмена в едином информационном пространстве системы здравоохранения Самарской области и полностью соответствует требованиям действующего "Положения о порядке информационного взаимодействия в системе ОМС на территории Самарской области".
Вносимые изменения и дополнения в данный документ должны быть согласованы с Самарским областным медицинским информационно-аналитическим центром и утверждены начальником Главного управления здравоохранения Администрации Самарской области.
9. Стороны, принимавшие участие в разработке Положения
Самарский областной медицинский
информационно-аналитический центр
Заместитель директора Ю.А.Мальшин
Главный специалист П.В.Тяпухин
Начальник отдела Т.А.Стрельникова
Ведущий программист М.В.Ляхманова
Управление здравоохранения Администрации г. Самары
Заведующий бюро медицинской ______________Т.И.Овсеенко
статистики
Начальник отдела информационных ______________В.М.Серов
систем ИЦ УЗ г. Самары (ПАРУС)
