|
Стр. 10
В расчете контрольной суммы по выделенной строке применяется
алгоритм Secure Hash Algorithm (SHA) стандарта Secure Hash
Standard (SHS).
Алгоритм SHA (Secure Hash Algorithm) стандарта безопасного
хеширования (Secure Hash Standard, SHS).
В зависимости от выходного хеш-значения выделяют следующие виды
SHA:
SHA1 - выходное значение 160 бит;
SHA256 - выходное значение 256 бит;
SHA512 - выходное значение 512 бит;
SHA384 - выходное значение 384 бита.
Стандарт ИСО - ISO/IEC 10118-3:2004
(http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?
CSNUMBER=39876).
Настоящий документ описывает стандарт SHA1.
Описание реализации алгоритма SHA1 на языке C++:
typedef int HASH[5];
typedef int T512[16];
typedef int T80[80];
typedef int (*LPFNHASH)(int, int, int);// Функции F1, F2, F3
const int K1 = 0x5a827999;
const int K2 = 0x6ed9eba1;
const int К3 = 0x8f1bbcdc;
const int K4 = 0xca62c1d6;
unsigned ROL(unsigned a, size_t s) { return a << s | (a >> (sizeof
(T)*8 - s)); }
int f1(int x, int y, int z) { return x&y; | (~x)&z; }
/\ /\
int f2(int x, int y, int z) { return x y z; }
int f3(int x, int y, int z) { return x&y; | x&z; | y&z; }
void FillT80(T512 M, T80 W)
{
size_t t;
for(t = 0; t < 16; t++)W[t] = M[t];
/\ /\ /\
for(; t < 80; t++)W[t] = ROL(W[t-3] W[t-8] W[t-14] W[t-16], 1);
}
void MainStep(T80 W, size_t t, HASH H, LPFNHASH f, int K)
{
int tmp = ROL(H[0], 5) + f(H[1], H[2], H[3]) + H[4] + W[t] + K;
H[4] = H[3];
H[3] = H[2];
H[2] = R0L(H[1], 30);
H[1] = H[0];
H[0] = tmp;
}
void StepSHA(T512 M, HASH Hr)
{
T80 W;
FillT80(M, W);
size_t t;
HASH H;
memcpy(H, Hr, sizeof(HASH));
for(t = 0; t < 20; t++) MainStep(W, t, H, f1, K1);
for(; t < 40; t++) MainStep(W, t, H, f2, K2);
for(; t < 60; t++) MainStep(W, t, H, f3, К3);
for(; t < 80; t++) MainStep(W, t, H, f2, K4);
for(size_t i = 0; i < 5; i++)
Hr [i] += H[i];
}
Функции F1, F2, F3:
F1(X,Y,Z) = (X \/ Y) \/ ((-¬X) /\ Z)
F2(X,Y,Z) = X (+) Y (+) Z
F3(X,Y,Z) = (X /\ Y) \/ (X /\ Z) \/ (Y /\ Z)
ROL(X,Y) - циклический сдвиг Х влево на Y разрядов,
где:
/\ - логическое "И";
\/ - логическое "Или";
-¬ - логическое "Не";
(+) - логическое "Исключающее или".
Перед запуском алгоритма хеш-значение должно инициализироваться
следующими константами:
const HASH HASHFIRST = {0x67452301, 0xefcdab89, 0x98badcfe,
0x10325476, 0xc3d2e1f0};
Замечание: тип int хранит байты в обратном порядке. В
приведенном примере минимальной единицей памяти является 32-битный
блок, поэтому способ хранения на диске неважен. При побайтовой
обработке это следует учитывать.
Приложение N 3.3
к Методическим рекомендациям
по организации информационного
взаимодействия между участниками
лекарственного обеспечения отдельных
категорий граждан при обязательном
медицинском страховании
(с изменениями и дополнениями)
от 21 марта 2006 года
СПЕЦИФИКАЦИЯ ПРОТОКОЛА ЭКСПОРТА-ИМПОРТА
НОРМАТИВНО-СПРАВОЧНОЙ ИНФОРМАЦИИ И РЕГИОНАЛЬНОГО СЕГМЕНТА
ФЕДЕРАЛЬНОГО РЕГИСТРА ЛИЦ, ИМЕЮЩИХ ПРАВО НА ПОЛУЧЕНИЕ
ГОСУДАРСТВЕННОЙ СОЦИАЛЬНОЙ ПОМОЩИ
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ
ЦОД Центр обработки данных
НСИ Нормативно-справочная информация
ТФОМС Территориальный фонд обязательного медицинского
страхования
ЛПУ Лечебно-профилактическое учреждение
ФО Фармацевтическая организация
СМО Страховая медицинская организация
АУ Аптечное учреждение
ПФР Пенсионный фонд России
ОПФР Территориальное отделение Пенсионного фонда России
МКБ Международный классификатор болезней
ДЛО Дополнительное лекарственное обеспечение
МНН Международное непатентованное наименование
ЛС Лекарственное средство
ЛФ Лекарственная форма
СНИЛС Страховой номер индивидуального лицевого счета в
системе персонифицированного учета ПФ РФ
ОГРН Общероссийский государственный регистрационный номер
ОКАТО Общероссийский классификатор административно-
территориальных образований
ОКВЭД Общий классификатор видов экономической деятельности
ОКОГУ Общероссийский классификатор органов государственной
власти и управления
ИНН Идентификационный номер налогоплательщика
КПП Код причины постановки
БД База данных
СУБД Система управления БД
ЛПД Логический поток данных
ПО Программное обеспечение
ППО Пакет программного обеспечения
ДФВ Дефектная ведомость
1. ОБЩИЕ ПОЛОЖЕНИЯ
Настоящая спецификация описывает обязательные правила
(протокол) при экспорте/импорте нормативно-справочной информации
дополнительного лекарственного обеспечения федерального и
территориального уровней и регионального сегмента федерального
регистра лиц, имеющих право на получение государственной
социальной помощи, между экспортером и импортером и рекомендуемые
методики при реализации указанного протокола.
2. ТЕРМИНЫ И ПОНЯТИЯ
ППО ЦОД - пакет программного обеспечения, работающий в ЦОД.
ППО участника ДЛО - пакет программного обеспечения, работающий
на стороне участника дополнительного лекарственного обеспечения,
получающего нормативно-справочную информацию (ЛПУ, АУ, ФО, СМО).
В настоящем протоколе выделяются следующие основные типы
информации, экспортируемые из ЦОД участникам ЛПУ:
1. Нормативно-справочная информация федерального уровня (поток
данных НСИ и поток справочных данных), к которой относятся
следующие справочники и классификаторы:
- перечень (справочник) лекарственных средств (ЛС) в составе:
перечень ЛС, отпускаемых по рецептам врача (фельдшера) при
оказании дополнительной бесплатной медицинской помощи отдельным
категориям граждан, имеющим право на получение государственной
социальной помощи, справочник торговых наименований ЛС, справочник
международных непатентованных наименований ЛС, классификатор
лекарственных форм (ЛФ), классификатор единиц измерения дозировки,
классификатор единиц объема ЛФ, классификатор единиц веса ЛФ,
классификатор фармгрупп ЛС, справочник зарегистрированных цен
лекарственных средств, справочник торговых надбавок, справочник
разделов Перечня лекарственных средств, справочник предельных цен
возмещения;
- международный классификатор болезней (МКБ-10);
- справочник врачебных (медицинских) должностей;
- справочник медицинских специальностей;
- справочник квалификационных категорий врачей;
- общероссийский классификатор административно-территориальных
образований (ОКАТО);
- справочник категорий граждан, имеющих право на ГСП;
- справочник результатов обращений в поликлинику;
- справочник причин отказов в оплате ЛС, отпущенных гражданам
отдельных категорий;
- прочие справочники: виды документов, удостоверяющих личность
граждан, источники финансирования, проценты льгот рецептов, сроки
действия рецептов.
2. Нормативно-справочная информация территориального уровня:
к потоку Справочных данных относятся:
- перечень медицинских услуг;
к потоку регулярных данных - регистров относятся:
- справочник врачей и фельдшеров, имеющих право на выписку
рецептов отдельным категориям граждан;
- справочник лечебно-профилактических учреждений;
- справочник страховых медицинских организаций;
- справочник территориальных фондов ОМС;
- справочник фармацевтических организаций.
3. Федеральный регистр лиц, имеющих право на получение
государственной социальной помощи в виде набора социальных услуг
(далее - федеральный регистр, относится к потоку регулярных данных
- регистров).
В данном документе описывается структура XML файлов, содержащих
НСИ и федеральный регистр, которые участвуют в обмене между ЦОД и
участниками ДЛО. Указанные типы данных передаются в различных XML
файлах.
Экспортер - сторона, передающая собственные данные в
соответствии с настоящей спецификацией для другой стороны.
Импортер - сторона, принимающая и использующая в своих целях
данные, переданные другой стороной.
3. ВЕРСИИ ПРОТОКОЛА
Настоящая спецификация определяет протокол версии 3.0. В
последующем возможно внесение изменений в описываемый протокол.
Изменения протокола формируют соответствующую новую версию
протокола. Каждый XML-файл по данному протоколу должен нести
внутри себя информацию о версии протокола.
4. ВЗАИМОДЕЙСТВИЕ СТОРОН
Обмен данными, экспорт/импорт между ЦОД и участниками ДЛО
осуществляется на файловом уровне, данные информационного обмена
формируются, хранятся и обрабатываются ППО ЦОД и ППО участников
ДЛО в виде файлов XML формата. Файлы XML формата содержат
структурированный набор блоков информации. Каждый блок информации
обозначается соответствующим предопределенным набором тегов.
Настоящая версия протокола предусматривает направление передачи
данных только от ЦОД (экспортер) к участникам ДЛО (импортер).
Экспортер данных обязан формировать XML-файлы в соответствии с
настоящим протоколом. Экспортер несет ответственность за полноту,
достоверность и актуальность передаваемых данных.
На импортирующую сторону возлагается ответственность за
выполнение всех требуемых проверок по целостности принятых данных.
ППО ЦОД формирует XML файлы, включающие в себя НСИ, Справочники
и Регистры, по данным БД в Центре Обработки Информации.
ППО участника ДЛО принимает информацию в виде XML файлов,
анализирует их на предмет соответствия настоящей спецификации,
формирует перечень предупреждений и перечень критичных ошибок
(дефектную ведомость), разносит полученные данные в свой экземпляр
БД.
4.1. Потоки данных
При экспорте/импорте данных по настоящему протоколу выделяются
три основных логических потока данных по соответствующим типам
данных:
- поток данных НСИ (мнемоника протокола ISDLO-NSI);
- поток Справочных данных (мнемоника протокола ISDLO-REFS);
- поток регулярных данных - Регистров (мнемоника протокола
ISDLO-REGISTR).
Каждый логический поток данных имеет свой собственный состав
}jqonprhpsel{u/импортируемых данных и обособленную структуру XML-
файла, соответствующую потоку передаваемых данных.
4.2. Атрибутивные характеристики НСИ, Справочников и Регистров
Атрибутивные характеристики НСИ, Справочников и Регистров -
условно постоянные характеристики. К ним относятся уникальные
коды, номера, имена, названия и другие атрибуты, характеризующие
объекты НСИ, Справочников и Регистров.
Для XML-файлов логических потоков данных НСИ, Справочников и
Регистров определены следующие целевые назначения:
Начальный импорт
Целевое назначение "Начальный импорт" подразумевает, что целью
обмена информацией является первичное получение данных участниками
ДЛО для синхронизации с БД ЦОД. Направление потока данных только
от ЦОД к участнику ДЛО.
Регулярные обновления
Целевое назначение "Регулярные обновления" подразумевает, что
ЦОД, взаимодействующий в рамках настоящего протокола, может
регулярно отправлять другой стороне данные об изменениях
атрибутивных характеристик. Целью обмена информацией при этом
является обновление данных в БД импортера по данным экспортера.
Направление потока данных только от ЦОД к участнику ДЛО.
5. ОБЯЗАТЕЛЬНЫЕ ПРАВИЛА
Настоящая версия протокола экспорта/импорта между ЦОД и
участником ДЛО предусматривает следующий набор обязательных правил
при обмене данными между экспортером и импортером.
5.1. Общие правила представления данных в XML формате
Здесь и далее используются определения и спецификации,
разработанные The World Wide Web Consortium (W3C)
(http://www.w3.org).
Структура XML файлов протоколов и других документов описывается
с помощью схем (XML Schema), спецификация которых описана
(http://www.w3.org/2001/XMLSchema). Схема для каждого вида
документа (XML файла) представляется в виде XSD файла.
5.2. Структура файла
Для всех документов (файлов XML) применяется следующая базовая
схема:
Тег корневого файла . Корневой тег содержит
атрибут "chsm" - значение контрольной суммы. Алгоритм расчета
контрольной суммы описан в п. 8 данного документа.
Тег (обязательный) с идентификатором формата , в
котором указывается GUID, соответствующий формату.
Тег (обязательный) , в котором указывается мнемоника
протокола.
Тег (обязательный) , в котором указывается версия формата.
Тег (необязательный) содержит наименование
программы, создавшей экземпляр файла.
Тег (необязательный) содержит номер сборки (версии)
программы, создавшей экземпляр файла.
Тег (необязательный) содержит дату и время
создания файла.
Тег (необязательный) содержит строку со смысловым
обозначением формата файла.
Тег <ЕСР> (необязательный) содержит двоичные данные с
электронной подписью отправителя.
Раздел SENDINFO (тег <sendinfo>, обязательный) типа
docFlowInfoType (определение приведено ниже).
Все остальные данные включаются в теге <datamain>, структура
которого определяется конкретным форматом.
5.3. Правила формирования посылок
Тег SENDINFO с информацией о посылке экспорта/импорта является
обязательным.
В теге <host_guid> должен быть указан GUID экспортера. GUID
экспортера представляет собой символьный идентификатор участника,
уникальный в пределах территориальной информационной системы
дополнительного лекарственного обеспечения отдельных категорий
граждан. При обработке файла необходимо провести проверку
допустимости приема файла данного протокола от данного экспортера.
В качестве GUID хоста в системе используется ОГРН учреждения
экспортера. В случае, если у одного учреждения присутствует
несколько хостов экспортеров (например, разные отделения одного
лечебно-профилактического учреждения), для уникальности к ОГРН в
квадратных или круглых добавляется номер хоста внутри данного
учреждения. Например:
<host_guid> 1023101687190[2]</host_guid>.
Посылки от одного экспортера должны последовательно
нумероваться, и номер посылки указываться в теге <package_number>.
ПО должно исключить возможность формирования двух разных посылок с
одним номером от одного экспортера. ПО, осуществляющее импорт
посылок, должно контролировать последовательность обработки
посылок и исключить возможность нарушения порядка обработки
посылок одного экспортера.
Для каждой вновь создаваемой посылки, экспортер должен
определить новый GUID посылки, который должен быть отражен в теге
<send_guid>, а также сохранен для последующего использования. ПО,
осуществляющее импорт посылок, обязано контролировать уникальность
импорта посылок и исключить возможность обработки посылок с
одинаковым GUID. В качестве GUID (Global Unique Identifier)
посылки должен использоваться Глобальный Уникальный Идентификатор,
используемый в операционной системе Microsoft Windows.
GUID представляет собой уникальное псевдослучайное 128-битное
значение, которое теоретически не должно повториться. Алгоритм
генерации GUID основан на аппаратной части компьютера (параметры
BIOS, частота процессора, номер сетевой карты и т.д.) и использует
случайные показания внутреннего таймера. Эту запись можно
определить в виде строки следующего формата:
'{хххххххх-хххх-хххх-хххх-хххххххххххх}'
В каждой посылке необходимо указывать GUID предыдущей посылки в
теге <prev_send_guid>. При обработке файла необходимо обеспечивать
правило, по которому посылки должны обрабатываться
последовательно, т.е. значение тега <prev_send_guid> должно
соответствовать предыдущей принятой посылке. Для первой посылки от
экспортера тег <prev_send_guid> имеет пустое значение.
В случае, когда посылка разбивается на несколько файлов, в ней
необходимо указывать теги <file_number>, <prev_file_number>,
<next_file_number>, номер текущего файла, предыдущего и
последующего. Все файлы посылки имеют сквозную (в рамках посылки)
нумерацию. При обработке многофайловой посылки необходимо соблюсти
последовательность обработки файлов.
5.4. Формирование XML-файлов
При формировании XML файла ПО экспортера данных обязано
выдержать все требования настоящей спецификации по структуре
файлов и соответствию его XSD-схеме.
После полного формирования файлов ППО экспортера обязано
проверить сформированный файл на соответствие XSD-схеме.
Все данные при формировании файла должны приводиться к
форматам, определенным в пункте 6 настоящего документа.
Расчет контрольной суммы производится в соответствии с пунктом
8 настоящего документа.
5.5. Контроль версии протокола
При приеме файлов ППО импортера в первую очередь должно
провести проверку по версии протокола, указанной в принимаемом XML
файле. XML файлы без указания версии протокола не должны
приниматься ППО импортера. ППО импортера также не должно принимать
к обработке XML-файлы с неизвестной ему версией протокола.
5.6. Контроль структуры файла
Следующим шагом при приемке справочной информации должна быть
проверка полученного XML-файла на соответствие определенной для
версии протокола XSD-схеме. При каком-либо несоответствии ППО
импортера должно отвергнуть файл в целом и не пытаться
осуществлять импорт полученных данных.
Для ППО импортера рекомендуется формировать файл обнаруженных
ошибок в полученном XML-файле для разбора возможных конфликтных
ситуаций.
5.7. Проверка контрольной суммы
До начала исполнения импорта ППО импортера обязано рассчитать
контрольную сумму по обрабатываемому XML-файлу в соответствии с
алгоритмом, указанным в пункте 8 настоящего документа.
Рассчитанная контрольная сумма сравнивается с контрольной суммой,
указанной в атрибуте chsm головного тега <main> XML-файла. При
несоответствии рассчитанной и указанной контрольных сумм файл
должен считаться дефектным и не приниматься к дальнейшей
обработке.
6. ФОРМАТЫ ДАННЫХ
При записи данных в XML файлах используются типы данных
(форматы представления), описанных в спецификации W3.ORG
(http://www.w3.org/2001/XMLSchema). Используются простые базовые
типы, производные (путем введения ограничений) от простых типов и
комплексные типы.
При создании XML файлов необходимо использовать следующие
форматы данных:
6.1. Форматы применяемых простых типов
------------T------------T---------------------------------------¬
¦ XSD Тип ¦ Тип данных ¦ Описание ¦
+-----------+------------+---------------------------------------+
¦xs:string ¦Строка ¦Произвольная строка ¦
+-----------+------------+---------------------------------------+
¦xs:integer ¦Целое число ¦ ¦
+-----------+------------+---------------------------------------+
¦xs:decimal ¦Дробное ¦"YYYYY.XXX", где YYYY - целая часть, ¦
¦ ¦число ¦XXX - дробная, разделитель целой ¦
¦ ¦ ¦и дробной части "." /точка/ ¦
+-----------+------------+---------------------------------------+
¦xs:double ¦Вещественное¦Разделитель целой и дробной части ¦
¦ ¦ ¦"." /точка/ ¦
+-----------+------------+---------------------------------------+
¦xs:date ¦Дата ¦"ГГГГ-ММ-ДД", например, 2004-09-12 ¦
+-----------+------------+---------------------------------------+
¦xs:dateTime¦Дата+время ¦"ГГГГ-ММ-ДДТЧЧ:ММ:СС" разделитель даты ¦
¦ ¦ ¦и времени - латинская Т, например, ¦
¦ ¦ ¦2004-12-31Т23:55:57 ¦
L-----------+------------+----------------------------------------
6.2. Производные типы
Производный тип: money2
Базовый тип: xs:decimal
Описание: Тип деньги
Производный тип: rесТуре
Базовый тип: xs:string
Возможные значения для типа:
- значение: "I"
- значение: "U"
- значение: "D"
Описание: Тип передаваемой записи. Используется для указания
причины, по которой передается запись. I - новая запись, U -
измененная запись, D - удаленная запись
Производный тип: date0
Базовый тип: xs:string
Формат:
ГГГГ-ММ-ДД,
где ГГГГ - год (допустимые значения от 0000 до 3333)
ММ - месяц (допустимые значения от 00 до 12)
ДД - дата (допустимые значения от 00 до 31)
Описание: Специальный формат даты. Допустимо в полях год, месяц
или день сохранять значение 0. Интерпретируется данная ситуация
как отсутствие информации об одном из полей
6.3. Составные типы
Составной тип: docFlowInfoType
Описание: Раздел информации для файлов, участвующих в посылке
экспорта/импорта
Вложенные теги:
Тег: HOST_GUID
Тип значения: xs:string
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: GUID хоста экспортера файла. Определяется для каждого
экспортера как константа
Тег: TARGET_HOST_GUID
Тип значения: xs:string
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: GUID хоста импортера, которому предназначена эта
посылка
Тег: SEND_GUID
Тип значения: xs:string
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: GUID посылки. Создается новый для каждого экземпляра
посылки
Тег: PREV_SEND_GUID
Тип значения: xs:string
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: GUID предыдущей посылки
Тег: FILE_NUMBER
Тип значения: xs:integer
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Номер файла в посылке. Указывается в случаях, когда
посылка разбита на несколько файлов. Нумерация производится,
начиная с 1. 1, 2, 3 и т.д.
Тег: PREV_FILE_NUMBER
Тип значения: xs:integer
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Номер предыдущего файла в посылке. Указывается в
случаях, когда посылка разбита на несколько файлов. В случае, если
файл первый в посылке, тег отсутствует
Тег: NEXT_FILE_NUMBER
Тип значения: xs:integer
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Номер следующего файла в посылке. Указывается в
случаях, когда посылка разбита на несколько файлов. В случае, если
файл последний в посылке, тег отсутствует
Тег: PACKAGE_NUMBER
Тип значения: xs:integer
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Номер посылки. Указывается в случаях, когда посылки
нумеруются
7. СТРУКТУРА ФАЙЛОВ
В соответствии со спецификацией формата .XML (www.w3.org):
- XML файл должен иметь идентифицирующий тег, указывающий на
то, что данный файл является файлом XML формата (первый тег XML-
файла).
- XML файл, а также каждый его блок должен иметь открывающий и
закрывающий теги, указывающие на начало и конец содержания XML-
файла (блока). В XML-файле должен быть один и только один корневой
тег.
7.1. Общие требования
В тегах, описывающих количество (или цену) лекарственного
средства, в качестве единицы измерения принято считать упаковку (в
соответствии с перечнем зарегистрированных цен на лекарственные
средства, которыми обеспечиваются отдельные категории граждан,
принятым Приказом Федеральной службы по надзору в сфере
здравоохранения и социального развития от 26 мая 2005 г. N 1136-Пр-
05 (1137-Пр-05)).
В тегах с типом значения "xs:dateTime", описывающих дату и
время, в случае отсутствия значения (неопределенного) приняты
следующие правила:
- для тегов (полей), описывающих дату (и время) какого - либо
события, - значение тега должно быть пустым или "1900-01-
01Т00:00:00";
- для тегов (полей), описывающих дату (и время) начала какого -
либо временного интервала (например, дата включения в справочник),
- значение тега должно быть пустым или "1900-01-01Т00:00:00";
- для тегов (полей), описывающих дату (и время) окончания
какого - либо временного интервала (например, дата исключения из
справочника), - значение тега должно быть пустым или "2222-01-
01Т00:00:00".
В настоящем документе везде далее при описании тегов XML файлов
знак + (плюс) перед тегом означает, что выделенный таким образом
тег имеет вложенные теги.
Описание в табличном виде обрамления для всех типов файлов
экспорта:
------T--------------------------------T--------------T----------¬
¦ N ¦ Наименование ¦ Обозначение ¦Примечания¦
+-----+--------------------------------+--------------+----------+
¦1. ¦Корневой раздел ¦<main> ¦<*> ¦
+-----+--------------------------------+--------------+----------+
¦1.1. ¦Версия формата ¦<format_guid> ¦<*> ¦
+-----+--------------------------------+--------------+----------+
¦1.2. ¦Мнемоника протокола, к которому ¦<protocol> ¦<*> ¦
¦ ¦принадлежит данный файл ¦ ¦ ¦
+-----+--------------------------------+--------------+----------+
¦1.3. ¦Версия протокола ¦<ver> ¦<*> ¦
+-----+--------------------------------+--------------+----------+
¦1.4. ¦Создано программой ¦<create_by> ¦ ¦
+-----+--------------------------------+--------------+----------+
¦1.5. ¦Версия программы ¦<app_build> ¦<*> ¦
+-----+--------------------------------+--------------+----------+
¦1.6. ¦Время создания ¦<create_time> ¦<*> ¦
+-----+--------------------------------+--------------+----------+
¦1.7. ¦Титул протокола ¦<title> ¦<*> ¦
+-----+--------------------------------+--------------+----------+
¦1.8. ¦Электронно-цифровая подпись ¦<ecp> ¦ ¦
+-----+--------------------------------+--------------+----------+
¦1.9. ¦Раздел описания для файлов, ¦<sendinfo> ¦<*> ¦
¦ ¦участвующих в экспорте/импорте ¦ ¦ ¦
+-----+--------------------------------+--------------+----------+
¦1.10.¦Передаваемая информация ¦<datamain> ¦<*> ¦
L-----+--------------------------------+--------------+-----------
--------------------------------
<*> - Обязательный тег.
Пример общей (заглавной) части XML-файла экспорта данных:
<?xml version="1.0" encoding="windows -1251" ?>
<main chsm="">
<format_guid>96826F8E-A469-4018-A00E-08AC41ECE80A </format_guid>
<protokol>ISDLO-NSI</protokol>
<ver>3.0</ver>
<create_by>ISDLO</creator_by>
<app_ build>1</app_>
<create_time>01.10.2004</create_time>
<title>Нормативно справочная информация ИС ДЛО
... .
+
+
...
7.2. Структура XML-документа логического потока НСИ
Тег: MAIN
Уровень вложенности тега: 1 (корневой)
Тип значения: <составной тип, имеет вложенные теги>
Атрибуты для MAIN:
Имя атрибута: chsm
Тип значения: xs:string
Описание: Контрольная сумма содержимого тэга MAIN
Содержимое тега MAIN:
Тег: FORMAT_GUID
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 1 (обязательный)
Фиксированное значение тега: {Е9408085-1CEB-4cbc-B94B-
A8BF6C99DF4E}
Описание: GUID формата файлов. Всегда должен иметь значение
{Е9408085-1СЕВ-4сbс-В94В-A8BF6C99DF4E}
Тег: PROTOCOL
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Фиксированное значение тега: NSI_REESTR
Описание: Мнемоника протокола, к которому принадлежит данный
файл. Для данного протокола должно быть "NSI_REESTR"
Тег: VER
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Фиксированное значение тега: 3.0
Описание: Номер версии формата. Данная версия 3.0
Тег: CREATE_BY
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Название программы, создавшей файл
Тег: APP_BUILD
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Номер сборки (версии) программы, создавшей файл
Тег: CREATE_TIME
Уровень вложенности тега: 2
Тип значения: xs:dateTime
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Время создания экземпляра файла (например, 2004-10-
10Т24:59:59)
Тег: TITLE
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Наименование документа. Произвольная строка.
Например, "Нормативно-справочная информация"
Тег: ЕСР
Уровень вложенности тега: 2
Тип значения: xs:string
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Электронная цифровая подпись экспортера
Тег: SENDINFO
Уровень вложенности тега: 2
Тип значения: docFlowInfoType
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Раздел информации для файлов, участвующих в посылке
экспорта/импорта. См. раздел "Описание общих типов данных"
Тег: DATAMAIN
Уровень вложенности тега: 2
Тип значения: <составной тип, имеет вложенные теги>
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Содержимое тега DATAMAIN:
Тег: DOCUMENTS
Уровень вложенности тега: 3
Тип значения: <составной тип, имеет вложенные теги>
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Блок данных, содержащий списки экспортируемых
документов
Содержимое тега DOCUMENTS:
В целом тег должен содержать один или большее
количество необязательных тегов, каждый из которых соответствует
определенному списку документов.
Максимально состав вложенных в необязательных тегов
списков документов может быть следующим:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Необязательные теги списков документов, их структура и
назначение описываются в нижеследующих подпунктах настоящего
протокола.
7.2.1. Справочник разделов Перечня лекарственных средств
Тег: SRP_DOC
Уровень вложенности тега: 4
Тип значения: <составной тип, имеет вложенные теги>
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Справочник разделов Перечня лекарственных средств.
Формируется аналогично таблице 22.3 Методических рекомендаций. Тег
является необязательным и в случае наличия должен быть
вложен в тег
Содержимое тега SRP_DOC:
Тег: SRP
Уровень вложенности тега: 5
Тип значения: <составной тип, имеет вложенные теги>
Тег должен быть указан минимум (раз): 0 (необязательный)
Тег должен быть указан максимум (раз): unbounded
(неограниченно)
Описание: Раздел Перечня лекарственных средств
Атрибуты для SRP:
Имя атрибута: ор
Тип значения: rесТyре
Описание: Тип передаваемой записи. Используется для указания
причины, по которой передается запись. См. раздел "Описание общих
типов данных"
Содержимое тега SRP:
Тег: C_RLP
Уровень вложенности тега: 6
Тип значения: xs:decimal(3)
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Код раздела перечня
Тег: N_RAZD
Уровень вложенности тега: 6
Тип значения: xs:decimal(3)
Тег должен быть указан минимум (раз): 1 (обязательный)
Тег должен быть указан максимум (раз): 1 (уникальный)
Описание: Номер раздела по перечню
|
