В будущих версиях может быть добавлена дополнительная категория, чтобы выполнить определенные требования устройств ЭКГ, используемых в других областях (например, в телемедицине или лечении на дому).
Все устройства, для которых объявлена категория формата данных SCP-ECG, должны импортировать как минимум разделы данных 0, 1, 3, 6, 7 и 8. Все категории могут иметь дополнительные разделы (например, 9, 10, 11). Данные, специфичные для конкретного производителя, должны необязательно включаться только в поля, байты и блоки, специфичные для производителя, которые были определены в документе. Зарезервированные, не специфицированные и не определенные поля, байты или блоки данных не должны использоваться для данных, специфичных для производителя.
Для конкретного устройства заявление о соответствии SCP-ECG перечисляет категории экспортируемых данных (т.е. снимаемых и доступных записей SCP-ECG) и импортируемых (т.е. принимаемых и доступных пользователю записей SCP-ECG). Устройство может также объявить свою способность передачи (т.е. возможности сделать доступной запись SCP-ECG без смены формата данных, например, экспортировать записи, которые были импортированы до этого). (В целях настоящего стандарта эти термины точно определены в приложении B.)
Выборка и определение синтаксиса высокого уровня, ориентированного на ЭКГ и предназначенного для передачи сообщений и данных между серверами, например EDIFACT или ASN.1, не входит в область применения настоящего стандарта.
Настоящий стандарт определяет общие соглашения, требующиеся для обмена конкретными данными пациента (демографическая информация, записи и т.д.), данными сигнала ЭКГ, измерениями ЭКГ и результатами интерпретации ЭКГ как между устройством картирования и сервером, так и между устройствами картирования.
Настоящий стандарт устанавливает содержание и структуру информации, которой будут обмениваться цифровые устройства картирования ЭКГ и компьютерные системы управления ЭКГ, а также другие компьютерные системы, в которых хранятся данные ЭКГ.
В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты. Для датированных ссылок применяют только указанное издание ссылочного документа, для недатированных ссылок применяют последнее издание ссылочного документа (включая все его изменения):
ISO/IEC 646 Information technology - ISO 7-bit coded character set for information interchange (Информационные технологии. 7-битный набор кодированных символов ИСО для обмена информацией)
ISO/IEC 2022:1994, Information technology - Character code structure and extension techniques (Информационные технологии. Структура кода символов и методы расширения)
ISO/IEC 4873, Information technology - ISO 8-bit code for information interchange - Structure and rules for implementation (Информационные технологии. 8-битный набор кодированных символов ИСО для обмена информацией)
ISO/IEC 8859-1, Information technology - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1 (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 1. Латинский алфавит N 1)
JIS X 0201-1976, Code for Information Interchange (Код для обмена информацией)
JIS X 0208-1997, Code of the Japanese Graphic Character Set for Information Interchange (Код японского набора графических символов для обмена информацией)
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 кардиограф, снимающий показания (acquiring cardiograph): Кардиограф, записывающий исходный сигнал ЭКГ.
3.2 бимодальное сжатие (bimodal compression): Использование низкочастотного фильтра и прореживания считываний за пределами защищенной зоны, содержащей комплекс QRS, без прореживания или фильтрации внутри защищенной зоны. На это указывает байт 6 из 5.9.3.
3.3 подтверждение (confirming): Процесс, в ходе которого обученный и опытный кардиолог проверяет сгенерированную компьютером интерпретацию ЭКГ (или расшифровку), чтобы подтвердить сгенерированную компьютером интерпретацию (или расшифровку) либо внести окончательные изменения в текст интерпретации.
Примечание - Подтвержденная ЭКГ является окончательной клинически приемлемой версией для диагностики и лечения.
3.4 Проект CSE (CSE Project): Проект, поддерживаемый генеральным директоратом XII Европейской комиссии, нацеленный на разработку общих стандартов для (количественной) электрокардиографии.
3.5 коэффициент снижения частоты/коэффициент прореживания (downsampling factor/decimation factor): Коэффициент, задающий сокращение считываний в разделах данных, где частота считываний снижена относительно исходной частоты считываний.
Примечание - Это применимо к бимодальному сжатию данных.
Пример - Исходная частота считываний 500 отсчетов в секунду (равносильна интервалу между считываниями 2 мс) сокращена до 125 считываний в секунду (равносильно интервалу между считываниями 8 мс). Коэффициент снижения частоты в таком случае составляет 4.
3.6 интерпретирующее устройство (interpretive device): Устройство (картирующее устройство, компьютер), анализирующее сигнал ЭКГ.
3.7 сообщение (message): Текстовое тело информации.
3.8 расшифровка (overreading): Процесс, в ходе которого кардиолог или ассистент проверяет интерпретацию ЭКГ, сгенерированную компьютером, чтобы проверить точность интерпретации или внести изменения в ее текст.
Примечание - Расшифровка ЭКГ, как правило, не является окончательной клинически приемлемой версией для диагностики и лечения. Как правило, процесс расшифровки предшествует процессу подтверждения.
3.9 запись (record): Весь файл данных, который необходимо передать, включая данные ЭКГ и связанную с ними информацию, например, идентификацию пациента, демографические и другие клинические данные.
3.10 эталонный цикл (reference beat): Эталонный/типичный цикл ЭКГ, вычисленный с помощью любого (но не указанного) алгоритма, охватывающий зубцы P, QRS и ST-T.
3.11 остаточные данные (residual data): Данные исходной ЭКГ, остающиеся после "надлежащего" вычитания эталонного цикла, где "надлежащий" означает точное совмещение циклов.
3.12 данные ритма (rhythm data): Полные данные исходной ЭКГ или разархивированные и восстановленные данные ЭКГ с уменьшенным разрешением.
Примечание - Длина ритма, как правило, равна 10 с.
3.13 раздел (section): Совокупность элементов данных, связанная с одним аспектом записи, измерения или интерпретации электрокардиографии.
3.14 универсальные коды интерпретации (universal statement codes): Коды интерпретации ЭКГ (см. приложение F).
Примечание - Другие технические термины, связанные с настоящим стандартом, см. в приложении G.
В настоящем стандарте применены следующие сокращения:
5.1.1 Запись данных, которая предполагается для обмена, должна быть разделена на разные разделы. Содержание и формат каждого из этих разделов определяются в настоящем стандарте.
5.1.2 Все текстовые данные (строки символов) должны удовлетворять ограниченным требованиям для соответствия ИСО/МЭК 2022, которые описаны в приложении A. Latin-1 (ИСО/МЭК 8859-1) должен быть набором символов по умолчанию.
5.1.3 Все строки символов должны завершаться байтом NULL (не является частью ИСО/МЭК 2022).
5.1.4 Для всех двоичных значений со знаком должен использоваться дополнительный код.
5.1.5 Все двоичные значения, состоящие из одного или нескольких байтов, считаются целочисленными без знака, если не указано иное.
5.1.6 Двоичные значения, состоящие из нескольких байтов, должны передаваться в порядке возрастания значимости (наименьший значащий байт передается первым, а наибольший - последним).
5.1.7 Последовательные байты нумеруются слева направо (начиная с первого). Биты байта нумеруются справа налево (0 - LSB, 7 - MSB).
5.1.8 Первый байт записи (т.е. первый байт контрольной суммы) определен как Байт 1.
5.1.9 Считывания ЭКГ индексируются и нумеруются, начиная со считывания номер 1. Номер считывания 0 не используется в настоящем стандарте. Номер считывания является 16-битным индексом. Первое считывание происходит в момент времени 0. Второе считывание, в случае частоты 500 считываний в секунду, происходит в 0 + 2 мс.
5.1.10 Разделы нумеруются, начиная с 0 (указатель раздела) по 32 767.
5.1.11 Термин "эталонный цикл" используется в настоящем стандарте по отношению к комплексу ЭКГ, выбранному в качестве представителя класса таких комплексов. Данный термин не предполагает никакого конкретного статистического смысла; например, это может быть усредненный цикл, "средний цикл", выбранный или какой-либо другой единичный цикл, взятый из общей записи ЭКГ. "Эталонный цикл" включает в себя P-зубцы, если они присутствуют (не в случае предсердной фибрилляции), сегмент ST-T и T-зубец данного цикла.
ЭКГ может обладать множеством эталонных циклов. Термин "тип цикла", используемый в настоящем стандарте, означает один цикл из упорядоченного списка эталонных циклов, начиная с типа эталонного цикла 0 (ноль). Эталонный цикл типа 0 по определению является эталонным циклом, применяемым для классификации ЭКГ и для вычитания, если при сжатии используется вычитание эталонного цикла. Упорядочивание списка эталонных циклов не предполагает наличия их последовательности во времени в данных ритма.
Термин "данные ритма" применяется для описания данных ЭКГ, полученных на протяжении всего времени записи, как правило, 10 сек. в большинстве записывающих устройств. Описание этих терминов и рекомендованной методологии сжатия данных, включая цифровые примеры и методы испытания сжатия данных и искажения сигнала на соответствие минимальным требованиям, даны в разделе 6, приложениях B и C.
В 5.8 данные эталонного цикла типа 0 предназначены для использования в целях отображения, (повторного) анализа, и если для сжатия данных было использовано вычитание эталонного цикла, то для реконструкции данных ритма.
5.1.12 Все индексы или указатели определены в байтах и начинаются с единицы, если не указано обратное.
5.1.13 1 Кбайт = 1024 байтам.
5.2.1 Все разделы должны начинаться с нечетного индекса (четное смещение). Это предполагает, что все разделы должны содержать четное число байтов. В конец любого раздела, содержащего нечетное число байтов, должен быть добавлен заполняющий байт. Заполняющие байты должны всегда иметь значение NULL. Блоки данных в разделе могут содержать либо нечетное, либо четное число байтов. Заполнение происходит только в конце раздела, если оно необходимо.
5.2.2 Всем разделам присваиваются идентификационные номера. Номера разделов с 0 по 11 на данный момент определены в протоколе SCP-ECG, номера с 12 по 127, а также номера, превышающие 1023, зарезервированы для будущего использования. Номера с 128 по 1023 назначаются разделам, специфичным для конкретного производителя. Сочетания кода производителя (см. 5.4.3.1, тег 14) и номера раздела с 128 по 1023 уникально определяют содержание разделов, специфичных для конкретного производителя. Не существует никаких конкретных правил для раскладки и формата этих разделов. Тем не менее рекомендуется использование структуры, определенной в 5.2.7.
5.2.3 Включение разделов 2, 4, 5, 7 - 11 (см. 5.2.7 и 5.2.8) является необязательным. Любая запись данных SCP-ECG должна содержать раздел 0 (указатели), раздел 1 (заголовок), раздел 3 (определение отведения ЭКГ) и раздел 6 (данные ритма). Не предполагается никаких иных проверок целостности других присутствующих разделов. В частности, если присутствует какой-либо из разделов 8, 9 или 11, то не предполагается, что должны быть в наличии все три.
5.2.4 Запись ЭКГ начинается с 6-байтового заголовка, состоящего из 2-байтовой контрольной суммы, за которым следует 4-байтовая длина записи. Они определяются следующим образом:
1) 2-байтовый циклический избыточный код (CRC) вычисляется по алгоритму CRC-CCITT, описанному в E.5.5. CRC вычисляется для всей записи, начиная с первого байта, следующего за CRC, и заканчивая последним байтом в записи;
2) 4-байтовая длина записи обозначает число байтов во всей записи, включая 6 байтов заголовка данной записи.
![]() Рисунок 1 - Обзор записи
5.2.6 Порядок последовательности разделов записи является свободным, за исключением раздела 0 (ноль), который должен следовать непосредственно за ее заголовком. Однако в записи данных SCP-ECG разрешен максимально один экземпляр любого раздела.
1) идентификации заголовка раздела (ID заголовка раздела);
2) части данных раздела.
Любой раздел должен начинаться с "ID заголовка раздела" (16 байтов), определенного ниже:
Каждый раздел должен иметь номер версии протокола раздела (см. байты 9 и 10), который может использоваться для указания различных уровней совместимости со стандартом, когда этот стандарт будет обновлен в будущем (см. приложение B). Для разделов с 1 по 11 номера версий разделов (байт 9) должны быть версией протокола, для которой был одобрен данный раздел. Для разделов данных с 12 по 1023 версия раздела должна обозначать версию производителя для данного раздела, не зависящую от версии протокола.
![]() Рисунок 2 - Обзор организации раздела
5.2.10 Числа, указанные курсивом, в обзорах организации раздела (в 5.2.5, 5.2.9), указывают длину соответствующего поля в байтах или обозначенный блок (var - переменная длина).
5.2.11 Общий обзор структуры данных SCP-ECG приведен в таблице 2.
Таблица 2
Структура данных SCP-ECG
5.2.12 Приведенные ниже замечания применимы к областям данных, определенным выше.
5.3.1 Цель данного раздела заключается в хранении указателей на остальные разделы записи. Всем разделам даются идентификационные номера в соответствии с 5.2.2.
5.3.2 Данный раздел начинается с "ID заголовка раздела" в соответствии с 5.2.7. Байты с 11 по 16 ID заголовка раздела должны содержать строку ASCII из шести символов "SCPECG".
5.3.3 Для обеспечения гибкости управления разделом данные раздела указателей определяются следующим образом:
- независимо от присутствия необязательных разделов должно быть предоставлено одно поле указателя для каждого раздела с 0 по 11, определенного протоколом SCP-ECG. Для каждого необязательного раздела, не включенного в запись данных SCP-ECG, поле указателя должно содержать специальные коды, определенные в 5.3.3.2 и 5.3.3.3;
- каждому разделу, специфичному для производителя (если присутствуют), должно соответствовать поле указателя в разделе 0.
Каждое поле указателя содержит три части:
a) идентификация раздела (см. 5.3.3.1);
b) длина раздела (см. 5.3.3.2);
c) индекс раздела (см. 5.3.3.3).
5.3.3.1 Идентифицирующий номер раздела хранится в двух байтах, содержащих этот номер, в соответствии с 5.2.2. В настоящее время номера разделов с 0 по 11 определены в протоколе SCP-ECG, номера с 12 по 127, а также номера, превышающие 1023, зарезервированы для будущего использования. Номера с 128 по 1023 являются кодами разделов, специфичных для производителя.
5.3.3.2 Длина раздела в байтах (четное число, см. 5.2.1) представлена в данной 4-байтовой целочисленной части поля без знака. Длина включает байты "ID заголовка раздела" (см. 5.2.7). Четырехбайтовое целое необходимо, чтобы позволить разделы, длина которых превышает 32 Кбайта. Для данных, содержащихся в разделах 2 - 11, поле указателя должно присутствовать. Если в каком-либо из этих разделов не передается никаких данных, то длина этого раздела должна иметь значение 0.
5.3.3.3 Индекс первого байта раздела должен быть представлен в данной 4-байтовой целочисленной части поля без знака. Индекс вычисляется относительно начала записи, т.е. байта 1 записи (первый байт CRC). Например, если раздел 11 начинается со сдвигом в 128 900 байтов от начала записи ЭКГ, то индекс раздела 11 будет иметь значение 128 901. Четырехбайтовое целое необходимо, чтобы позволить запись SCP-ECG, длина которой превышает 32 Кбайта. Если раздел не включен в запись SCP-ECG, то его индекс должен иметь значение NULL (0). Индекс раздела 0 должен всегда иметь значение 7, так как разделу 0 всегда предшествует контрольная сумма (2 байта) и длина записи (4 байта).
5.3.3.4 Поля указателя должны быть представлены в порядке возрастания номеров разделов. Но сами разделы не обязаны следовать в порядке возрастания номеров.
5.3.4 Обзор структуры раздела указателя:
![]() Рисунок 3 - Обзор структуры раздела указателя
5.4.1 Общие положения
Раздел должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.4.2 Введение в данные раздела
Приведенная ниже раскладка подробно описывает формат, который должен использоваться для передачи демографических данных пациента и административных данных ЭКГ в качестве части стандартного (SCP-ECG) протокола коммуникаций для цифровых данных ЭКГ.
5.4.3 Базовая методология
5.4.3.1 Известно, что несмотря на возможность передачи большого числа параметров, большинство устройств передает только их подмножество. Поэтому было принято решение сделать формат демографических данных пациента более гибким.
Каждый параметр должен храниться в отдельном поле. Включение поля в данный раздел должно быть необязательным при условии, что присутствуют следующие параметры (с 1 по 4):
Кроме того, рабочая группа SCP-ECG настоятельно рекомендует следующие параметры для уникальной идентификации пациента и времени снятия:
5.4.3.2 Гибкость достигается путем идентификации каждого поля с помощью следующих средств:
a) один ведущий байт спецификации, именуемый "тег", идентифицирует содержание поля параметров;
b) 2-байтовое целое число без знака, именуемое "длиной", содержащее длину значения поля в байтах, позволяет вносить текстовые записи различной длины и использовать мультибайтовые наборы символов (например, наборы японских символов). В длину поля должен входить символ NULL, завершающий строку текста. Например, длина фамилии "Menuel" должна иметь значение 7, учитывающее NULL. Допустима длина поля 0, эквивалентная утверждению "не определено";
c) нуль или более байтов параметра, именуемых "значением", содержащие фактические данные параметра.
Тег поля (один двоичный байт) разрешает определять всего 255 различных типов поля (от 0 до 254; 255 используется для завершения), из которых 55 (с 200 по 254) зарезервированы для использования конкретным производителем. Любое поле, идентифицированное значением от 200 до 254, не определено в рамках спецификации данного протокола, что позволяет производителю определить свой собственный набор полей.
Длина поля (два двоичных байта) должна содержать фактическую длину значения поля. Байты длины и тега (первые три байта любого поля) не включены в длину поля. Максимальная возможная длина каждого значения поля составляет 65 535 байтов (два байта без знака). Тем не менее по практическим причинам максимальная длина поля не должна превышать 64 байта, за исключением элементов произвольного текста (см. 5.4.3.5).
Значение поля, содержащее данные фактических параметров, может иметь любую комбинацию двоичных байтов и текстовых символов.
5.4.3.3 В разделе "Заголовок" разрешено использование не более одного экземпляра любого поля, определенного в 5.4.5, за исключением полей, перечисленных ниже:
5.4.3.4 Первые 16 символов идентификации пациента должны быть уникальными.
5.4.3.5 Для упрощения реализации протокола были определены максимальная длина поля, т.е. 64 байта (за исключением тега 13, тега 30 и тега 35, где ограничение составляет 80), и разумные значения длины разных полей свободного текста (таблица 3).
Таблица 3
Максимальная и разумная длина полей произвольного текста
5.4.4 Обзор части данных раздела "Заголовок" представлен ниже.
Примечание - Заполняющие байты (если имеются) должны иметь нулевое значение. Это применимо ко всем разделам, но не будет отображаться во всех последующих диаграммах.
![]() Рисунок 4 - Обзор части данных раздела "Заголовок"
Таблица 4
Спецификация определенных параметров
Продолжение таблицы 4
Продолжение таблицы 4
Продолжение таблицы 4
Продолжение таблицы 4
Продолжение таблицы 4
Продолжение таблицы 4
Продолжение таблицы 4
Продолжение таблицы 4
Окончание таблицы 4
5.5.1 Если этот раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.5.2 Схема для сжатия сигнала, представленная ниже, основана на методе кодирования Хаффмана. Данный метод не является единственным возможным, но является рекомендуемым.
5.5.3 Данный раздел записи ЭКГ содержит определение кодовых таблиц Хаффмана, которые использовались для кодирования ЭКГ. Предоставление нескольких таблиц позволяет осуществлять оптимальное кодирование данных (например, для сжатия эталонного цикла и данных ритма, скорее всего, будут использованы разные таблицы). Следует предполагать, что при кодировании данных каждого элемента использовалась таблица N 1 (т.е. первая таблица, определенная в этом разделе 2). Для перехода к другой таблице должны использоваться управляющие коды.
1) Базовое время считываний, определенное в разделе, описывающем закодированные данные (т.е. разделе 5 "Данные эталонного цикла" и разделе 6 "Данные ритма").
2) Базовая амплитуда ЭКГ, как она определена в разделе, описывающем закодированные данные (т.е. в разделе 5 "Данные эталонного цикла" и разделе 6 "Данные ритма").
Соответственно, структура данных, описанная в настоящем пункте, имеет следующий вид:
Коды Хаффмана были определены, чтобы разрешить отдельной структуре, описанной выше, задавать серии последовательных значений амплитуды. Упомянутый выше "префикс" является общим для всех кодов, описывающих последовательные значения - оставшееся битовое поле изменяется на один младший значащий бит (LSB) при его приращении в указанном диапазоне.
Пример байтовой структуры кода Хаффмана для этого случая показан в таблице 5.
Таблица 5
Пример байтовой структуры (код Хаффмана)
Примечание - Данный пример представляет следующие закодированные значения:
P1 P2 P3 P4 C1 C2 C3 C4 C5 C6
4-битовый префикс для общей длины кода 10.
P5 P6 P7 C7 C8 C9 C10 C11
3-битовый префикс для общей длины кода 8.
P8 P9 P10 C12 C13 C14
3-битовый префикс для общей длины кода 6.
Следует учесть, что "выбор" битов в заданном байте осуществляется от старшего значащего к младшему значащему и что обработка байтов осуществляется в том порядке, в котором они были получены.
Управляющие коды, т.е. коды, которые диктуют смену таблицы Хаффмана, должны включать в себя нулевое значение (0) "переключателя режима таблицы". "Базовое значение" должно в таком случае содержать номер таблицы, на которую необходимо переключиться.
Обзор данных этого раздела представлен на рисунке 5.
![]() Рисунок 5 - Обзор структуры раздела таблиц Хаффмана
5.6.1 Данный раздел определяет отведения, которые передаются вместе с некоторой общей административной информацией.
5.6.2 Если данный раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
Если не все отведения записываются одновременно, то эти отведения должны быть представлены в группах, соответствующих тем отведениям, что записаны одновременно.
Пример - Тройки отведений записываются одновременно: например, первая тройка отведений I, aVF, V2; вторая тройка отведений X, Y, Z и т.д. Детальная информация об отведениях должна быть приведена в описанном выше порядке: отведение I в первом сегменте (с 3 по 11), отведение aVF во втором сегменте (с 12 по 20), отведение V2 в третьем сегменте (с 21 по 29), отведение X в четвертом сегменте (с 30 по 38) и т.д.
Для каждого отведения передается следующая детальная информация:
Таблица 6
Коды идентификации отведений
5.6.4 Нумерация считываний должна начинаться с номера считываний 1 и ссылаться на все одновременно записываемые отведения. Чтобы преобразовать эти значения в единицы времени, следует учитывать частоту считываний соответствующего раздела данных (см. 5.8.3).
Например, если восемь отведений (I, II, V1 - V6) записываются одновременно в течение 10 сек. с частотой 500 считываний в секунду и хранятся таким же образом, то каждое отведение начинается со считывания 1 и заканчивается считыванием 5000.
Если отведения записываются в группах по три отведения в каждой, например, в течение 2,5 сек. с частотой 500 считываний в секунду, то отведения I, II и III начинаются со считывания 1 и заканчиваются считыванием 1250, а отведения aVR, aVL и aVF начинаются со считывания 1251.
5.6.5 Обзор данных этого раздела представлен на рисунке 6.
![]() Рисунок 6 - Обзор части данных раздела определения
отведения ЭКГ
5.7.1 Если этот раздел присутствует, то он определяет местоположения и ширину различных комплексов QRS. Определение эталонного цикла, типов цикла и значимости эталонного цикла типа 0 см. в 5.1.11. Подробное описание общего процесса см. в приложении C.
5.7.2 Раздел должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.7.3 Область заголовка данных раздела определяет конкретные величины, общие для всех отведений эталонного цикла типа 0. Остальные данные обозначают тип эталонного цикла и местоположение каждого комплекса QRS по отношению к "остаточному" сигналу. Область заголовка данных раздела имеет следующее содержание:
5.7.4 Приведенная ниже информация о местоположении зон вычитания эталонного цикла хранится в блоках по 14 байтов для каждого QRS-комплекса. Общее число блоков равно числу QRS-комплексов. Оно хранится в байтах с 5 по 6 области заголовка, см. 5.7.3.
--------------------------------
<1> Все номера считываний в данном разделе ссылаются на исходные считывания, сделанные перед обработкой для прореживания и/или сжатия. Первое считывание исходных данных нумеруется числом 1.
<2> Если байты 1, 2 указывают на эталонный цикл типа 0, то байты с 3 по 6 и с 11 по 14 выделяют область вокруг QRS-комплекса для вычитания или добавления эталонного цикла типа 0 в соответствии с указаниями и иллюстрациями, приведенными в приложении C. Границы этой области в приложении C сокращенно называются SB(k) и SE(k) соответственно.
<3> Если байты 1, 2 указывают на эталонный цикл не нулевого типа, то вычитание эталонного цикла не используется, в таком случае байты с 3 по 6 и с 11 по 14 содержат 0 (нуль).
5.7.5 Приведенная ниже информация по местоположению защищенных областей (QRS-комплексов) хранится в блоках по 8 байтов на каждый QRS-комплекс. Общее число блоков равно числу QRS-комплексов и хранится в байтах с 5 по 6 области заголовка <2>, см. 5.7.3.
--------------------------------
<1> Все номера считываний в данном разделе ссылаются на исходные считывания, сделанные перед обработкой для прореживания и/или сжатия. Первое считывание исходных данных нумеруется числом 1.
<2> Блоки, описанные в 5.7.4 и 5.7.5, могут также использоваться для указания местоположения защищенных зон при использовании бимодального сжатия без вычитания эталонного цикла. В этом случае байты с 3 по 6 и с 11 по 14 блока, описанного в 5.7.4, должны иметь значение 0.
<3> Если байты 1, 2 указывают на эталонный цикл типа 0, то байты с 3 по 6 и с 11 по 14 выделяют область вокруг QRS-комплекса для вычитания или добавления эталонного цикла типа 0 в соответствии с указаниями и иллюстрациями, приведенными в приложении C. Границы этой области в приложении C сокращенно называются SB(k) и SE(k) соответственно.
<4> Если байты 1, 2 указывают на эталонный цикл не нулевого типа, то вычитание эталонного цикла не используется, в таком случае байты с 3 по 6 и с 11 по 14 содержат 0 (нуль).
5.7.6 Обзор данных этого раздела представлен на рисунке 7.
![]() Рисунок 7 - Обзор структуры раздела 4
5.8.1 Данный раздел содержит подробное описание эталонного цикла типа 0. Определение эталонного цикла, типов эталонного цикла и значимости эталонного цикла типа 0 см. в 5.1.11. Детальное описание общего процесса см. в приложении C.
5.8.2 Если этот раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
Примечания
1 Данные разности определяются как: [значение считываний (разность) в момент времени t] - [значение считываний (разность) в момент времени t - 1]. См. таблицу 7.
2 Для первых двух считываний в каждом отведении разности второго порядка в протоколе SCP-ECG не вычисляются. Амплитуды исходных значений этих считываний сохраняются. Значение первого считывания также сохраняется в потоке закодированных данных, использующем разности первого порядка.
3 Пример результатов, закодированных с помощью разностей второго порядка, приведен в таблице 8 для серии из восьми считываний.
4 Пример результатов, закодированных с помощью разностей первого порядка, приведен в таблице 9 для той же серии из восьми считываний.
Таблица 7
Таким образом, общая формула для разности первого порядка имеет следующий вид
D1(n) = X(n) - X(n - 1).
Общая формула для разности второго порядка имеет следующий вид
D2(n) = X(n) - 2·X(n - 1) + X(n - 2).
Декодирование данных разности второго порядка выполняется по следующей формуле
X(n) = D2(n) + 2·X(n - 1) - X(n - 2).
Таблица 8
второго порядка
Таблица 9
первого порядка
5.8.4 Данные раздела содержат длины байтов закодированных отведений. Они имеют следующий формат:
5.8.5 Затем следуют закодированные данные эталонного цикла 0. Если раздел 2 присутствует, то данные кодируются как последовательности кодов Хаффмана, взятых из раздела 2. Отведения кодируются в порядке, указанном в разделе 3. Если раздел 2 отсутствует, то данные ЭКГ (разностные или неразностные) должны иметь формат двухбайтовых целых чисел со знаком.
Могут быть применены другие форматы за счет предоставления "фиктивной" таблицы Хаффмана с одной структурой кода. Числу битов префикса должен быть присвоен нуль. Числу битов всего кода должно быть присвоено желаемое число битов в значении считывания.
5.8.6 Обзор данных этого раздела представлен на рисунке 8.
![]() Рисунок 8 - Обзор структуры раздела закодированного
эталонного цикла типа 0
5.9.1 Данный раздел содержит либо:
1) все данные ритма ЭКГ целиком, если не было произведено никаких вычитаний эталонного цикла (см. 5.6.3, байт 2), либо
2) остаточный сигнал после вычитания эталонных циклов.
5.9.2 Если данный раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
Примечание - Если используется бимодальное сжатие, то интервал времени защищенной области считываний соответствует указанному в 5.8.3, но AVM такой, как в байтах 1 и 2 из настоящего пункта. За пределами защищенной области, AVM и интервал времени считываний соответствуют байтам с 1 по 4 из настоящего пункта.
5.9.4 Данные этого раздела содержат длины байтов закодированных отведений, имеющие следующий формат:
5.9.5 Затем следуют данные ритма. Если раздел 2 присутствует, то эти данные кодируются как последовательности кодов Хаффмана, взятых из раздела 2. Отведения кодируются в порядке, указанном в разделе 3. Если раздел 2 отсутствует, то данные ЭКГ (разностные или неразностные) должны иметь формат двухбайтовых целых чисел со знаком.
Могут быть применены другие форматы за счет предоставления "фиктивной" таблицы Хаффмана с одной структурой кода. Числу битов префикса должен быть присвоен нуль. Числу битов всего кода должно быть присвоено желаемое число битов в значении считывания.
5.9.6 Обзор данных этого раздела представлен на рисунке 9.
![]() Рисунок 9 - Обзор структуры раздела данных ритма
5.10.1 Общие положения
Данный раздел содержит результаты глобальных измерений для каждого типа эталонного цикла либо для каждого QRS-комплекса в записи, а также список импульсов электрокардиостимулятора в записи. Если измерения предоставлены для каждого QRS-комплекса, то первый блок измерений должен содержать глобальные измерения цикла типа 0. Понятие "глобальный" относится к измерениям, снятым со всех отведений ЭКГ, но не обязательно представляющих более одного отдельного цикла. Обсуждение типов циклов см. в 5.1.11.
5.10.2 ID заголовка раздела
Если раздел присутствует, то должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.10.3 Данные глобальных измерений электрокардиограммы и данные измерений импульсов электрокардиостимулятора
5.10.3.1 Общие положения
Данные раздела содержат данные глобальных измерений ЭКГ и данные измерений пиковых потенциалов электрокардиостимулятора, если таковые присутствуют. Специальные коды, определенные в проекте CSE, зарезервированы для обозначения следующего:
Эти коды должны заменять результаты измерений в соответствующих случаях.
Время и амплитуда этих импульсов электрокардиостимулятора представляются физической величиной со знаком в диапазонах от 0 до 65535 с и +/- 32767 мВ соответственно.
Разрешение времени для импульсов электрокардиостимулятора должно быть меньше или равно 2 мс.
5.10.3.4 Информация об импульсах электрокардиостимулятора
Для каждого импульса, идентифицированного в 5.10.3.2, байт 2, а также в 5.10.3.3, этот раздел должен содержать один блок из шести байтов, предоставляющий дополнительную информацию об импульсе. Порядок блоков соответствует порядку импульсов, идентифицированных в 5.10.3.3.
Данный раздел идентифицирует тип эталонного цикла для каждого комплекса QRS в ЭКГ. Комплексы рассматриваются по порядку. Типы эталонного цикла нумеруются в соответствии с их появлением в разделе данных глобальных измерений ЭКГ (5.10.3.2).
5.10.3.6 Дополнительные глобальные измерения
Данный раздел предусмотрен для дополнительных измерений сверх тех, что определены в 5.10.3.2. Он размещен здесь, чтобы реализации предыдущих версий протокола оставались работающими.
Таблица 10
5.10.4 Формат блока измерений для каждого типа эталонного цикла или для каждого отдельного комплекса QRS
Примечания
1 Если блок измерений содержит данные эталонного цикла некоторого типа, то времена начала и окончания задаются в миллисекундах от начала эталонного цикла. Если блок измерений содержит данные конкретного цикла, то времена начала и окончания задаются в миллисекундах от начала записи ЭКГ. Длительности зубцов и интервалов могут быть вычислены вычитанием времени начала зубца или интервала из времени окончания.
2 Для осей (P, QRS, T) на фронтальной плоскости используется соглашение, показанное на рисунке 10.
![]() Рисунок 10 - Определение угла
5.10.5 Блок глобальных измерений, специфичный для производителя
Блок переменной длины, содержащий глобальные измерения, специфичные для производителя, может быть добавлен в данный раздел после информации об импульсах электрокардиостимулятора.
Начало блока, специфичного для производителя (считая от начала ID заголовка раздела), должно определяться по информации, приведенной в данных глобальных измерений ЭКГ. Например, если блоки измерений содержат глобальные измерения для каждого типа эталонного цикла, то начало блока, специфичного для производителя, будет равно 16 (см. 5.2.7) + 6 + (число типов эталонного цикла, умноженное на 16) + (число импульсов электрокардиостимулятора, умноженное на 4) + (число импульсов электрокардиостимулятора, умноженное на 6) + (2 + число QRS-комплексов) + (9 + число байтов в тегированных глобальных измерениях) + 1. Конец блока должен предоставляться в ID заголовка раздела с помощью общей длины раздела, включая ID заголовка раздела (см. 5.2.7).
5.10.6 Структура данных глобальных измерений
Структура данных раздела 7, содержащего глобальные измерения, представлена на рисунке 11.
![]() 5.11.1 Данный раздел содержит текстовую версию самой поздней диагностической интерпретации ЭКГ.
5.11.2 Если раздел присутствует, то должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.11.3 Данные этого раздела включают заголовок, за которым следует несколько утверждений.
5.11.4 Заголовок имеет следующую структуру:
5.11.5 Данные утверждений
5.11.6 В утверждениях не допускаются никакие коды, если они не сопровождаются текстовым описанием.
5.11.7 Структура раздела представлена на рисунке 12.
![]() Рисунок 12 - Структура раздела 8
5.12 Хранение интерпретирующих утверждений, специфичных для производителя, и данных, относящихся к цепочке расшифровок. Раздел 9
5.12.1 Данный раздел зарезервирован для диагностических описаний, специфичных для производителя анализирующего устройства, и интерпретируемых цепочек расшифровок. Источник анализирующего устройства, фамилия и имя проводящего расшифровку врача (или наименование устройства) определены в "Разделе заголовка" (раздел 1).
5.12.2 Если раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.12.3 Структура и формат данных этого раздела специфичны для производителя.
5.13.1 Данный раздел содержит отдельные измерения каждого записанного отведения. Обязательные измерения и их формат приведены ниже. В нем предусмотрены область, специфичная для производителя, а также управляющие коды особых условий.
5.13.2 Если раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.13.3 Данные раздела измерения отведений должны состоять из одной записи для каждого измеряемого отведения. Каждая запись должна состоять из четырех полей:
a) идентификатор отведения (двоичный, два байта). Схему нумерации отведения см. в 5.6.4, байт 9;
b) длина записи в байтах (целое без знака), исключая байты с 1 по 4 (двоичное; 2 байта);
c) до 50 базовых измерений (целые со знаком) (двоичные поля; 2 байта каждое);
d) область измерений, специфичная для производителя, начиная с байта 105 и до конца (двоичные). Организация или формат этой области настоящим документом не регламентируются.
5.13.4 Специальные коды, определенные в проекте CSE, зарезервированы для обозначения следующего:
Заголовок данных этого раздела содержит число отведений, для которых передается блок измерений (двоичное, 2 байта). За ним следуют два байта информации, специфичной для производителя.
5.13.5 Каждый блок измерений отведения должен иметь следующий состав:
Примечание - Определение изоэлектрических сегментов I и K см. в European Heart Journal 1985, том 6, стр. 815 - 825. Кратко говоря, "I" является интервалом между глобальным началом QRS, полученным из всех одновременно записанных отведений, и началом QRS в конкретном отведении. Аналогично, "K" является временем между окончанием QRS в определенном отведении и глобальным окончанием QRS.
Все измерения должны быть выражены целочисленными значениями со знаком. Амплитуды зубцов Q, S, S', T(-) и P(-) должны быть выражены отрицательными целочисленными значениями. То же относится к амплитуде точек J, J + 20, J + 60 и J + 80, когда они отрицательные. Обратите внимание, что точка J (J) совпадает с окончанием комплекса QRS.
Байты с 67 по 104 должны иметь значение 0 и передаваться, если раздел содержит блок, специфичный для производителя.
5.13.5.1 Коды описания морфологии P и T (байты с 45 по 48) определены следующим образом:
5.13.5.2 Код качества (байты 55, 56) определен следующим образом:
Два двоичных байта на отведение, состоящие из 8 двухбитовых полей. Каждое поле характеризует уровень шума одного из четырех классов.
Младший значащий бит байта 55 определен как бит 0. Старший значащий бит байта 56 определен как бит 15.
5.13.5.3 Структура данных этого раздела представлена на рисунке 13.
![]() Рисунок 13 - Структура данных раздела блока
измерений отведений
5.14.1 Настоящий раздел содержит данные самой последней интерпретации и расшифровки, закодированные в соответствии с Универсальными кодами утверждений и правилами кодирования, определенными в приложении F. Данные, содержащиеся в этом разделе, должны быть согласованы с данными, передаваемыми в разделах 8 и 9.
5.14.2 Если этот раздел присутствует, то он должен начинаться с "ID заголовка раздела" в соответствии с 5.2.7.
5.14.3 Определение структуры и формата
Данные должны храниться по принципу "утверждение за утверждением". Существует три возможных типа утверждений:
1) универсальные коды интерпретации (в соответствии с приложением F);
2) полный текст (как используется в разделе 8);
3) логика утверждений (идентифицирующая логические связи между утверждениями).
Для хранения трех типов утверждений определены три отдельных поля утверждений.
Только одному полю типа "Логика утверждений" разрешается идентифицировать логические связи между утверждениями других типов. Если раздел не содержит поле типа "Логика утверждений", то предполагается, что все утверждения равным образом действительны и не имеют "специальных" связей друг с другом помимо того, что объявлено в утверждении. Число полей типов "Универсальные коды интерпретации" и "Полный текст" не ограничивается.
5.14.4 Организация данных этого раздела представлена в 5.14.5, а ее объяснение дано ниже.
5.14.4.1 Заголовок
5.14.4.2 Данные утверждения
5.14.4.3 Тип утверждения
Пример - выражение "(1 + 2); 3", где "+" = "ИЛИ", ";" = "И", а скобки "(...)" указывают приоритет, читается как "(утверждение N 1 ИЛИ утверждение N 2) И утверждение N 3.
См. рисунок 14.
![]() Рисунок 14 - Структура данных раздела 11
Как описано в разделе 1, ЭКГ применяется в повседневной клинической практике, когда пациент находится в спокойном состоянии, получает дозированные физические нагрузки, ведет обычную повседневную деятельность в течение длительного времени, например при амбулаторном мониторинге (так называемым холтеровским мониторингом), или находится в палате интенсивной терапии для контроля нарушения сердечного ритма. Рекомендации по сжатию данных записей ЭКГ на протяжении длительных периодов времени были исключены из настоящего стандарта. Спецификации кодирования и сжатия, описанные в настоящем стандарте, ограничиваются обычным снятием электрокардиограммы пациента в состоянии покоя.
Записи ЭКГ в состоянии покоя, как правило, имеют длину 10 сек. При оцифровке этих данных с точностью, рекомендованной Международными комитетом по электрокардиографии организация AHA, AAMI, CSE и другими, а именно 500 считываний/с и максимум 5 мкВ/LSB для каждого отведения ЭКГ, в секунду формируется 1000 байтов данных, в которых на каждое считывание отводится 16 битов. Таким образом, данные стандартной 10-секундной ЭКГ в 12 отведениях занимают 80 000 байтов (в этом случае избыточность отведений от конечностей, которые можно реконструировать из отведений I и II, уже была устранена).
Хотя эти объемы данных существенно меньше тех, что возникают при медицинской визуализации, электрокардиография дает большое количество цифровых данных по сравнению с другими медицинскими данными, например, с историей болезни пациента, кодами диагнозов и биомедицинскими лабораторными данными. Хотя современные технологии значительно повысили доступный объем хранения данных и скорость их передачи, снижение объема данных по-прежнему остается желательным (и даже экономически необходимым), в особенности при передаче этих данных по обычной телефонной сети.
В действительности существует два веских основания сжатия цифровых данных ЭКГ:
1) снизить требования к (магнитному) хранилищу медицинских баз данных и больничных информационных систем;
2) сократить время (и затраты на телефонную связь) передачи данных ЭКГ.
Хотя семантика диагностической информации ЭКГ теоретически может храниться в нескольких байтах, постоянно необходимы повторные анализы сделанных записей и сравнение новых записей с предыдущими, в особенности для кардиологических пациентов. Небольшие изменения морфологии ЭКГ могут служить чувствительными индикаторами протекания заболевания. Их можно распознать с помощью сравнения последовательного ряда записей ЭКГ, но если вместо записей хранятся только текстовые результаты анализа основных особенностей ЭКГ, эта возможность может быть потеряна.
За последние десятилетия были разработаны разные алгоритмы сжатия ЭКГ. Сжатие ЭКГ, за исключением специфичных ситуаций, когда применялось только сокращение избыточности, всегда сопровождалось некоторым ухудшением исходной записи. Так как стандарты точности, форматов данных или методов сжатия отсутствуют, то сжатые данные ЭКГ могут подвергаться повторному анализу и сравнению только в рамках систем обработки одного производителя. Также невозможен обмен сжатыми данными между системами разных производителей. Кроме того, отсутствует количественная информация о ухудшении данных, вызванных процедурами сжатия и реконструкции сжатых данных.
Главной целью и достижением, достигнутым в ходе осуществления направления Workpackage 2 в рамках Проекта SCP-ECG предварительных программ AIM (1989 - 1990) Европейского сообщества, было определение и согласование пределов точности и спецификаций сжатия данных ЭКГ, а также определение такого кодирования данных, при котором сжатые ЭКГ можно было бы передавать и повторно анализировать в системах разных производителей. Рекомендации, полученные в результате реализации этого направления, сформировали основу настоящего стандарта.
Можно идентифицировать следующие принципы, применяемые к сжатию данных ЭКГ:
1) сокращение избыточности в рамках цифровой записи (обратимое сжатие данных);
2) ограничение полосы пропускания и снижение частоты считываний;
3) сокращение информации с помощью необратимого сжатия данных, при котором могут задаваться, а могут и не задаваться пределы точности.
В ходе проекта SCP-ECG был подготовлен обзор различных алгоритмов, разработанных за последние 20 лет, для сжатия ЭКГ, снятых у пациента в состоянии покоя, а также холтеровских ЭКГ. Важный вклад в сжатие данных ЭКГ можно найти в работах, приведенных в библиографии.
Ниже приведены основные заключения, сделанные в этом обзоре:
1) сокращение избыточности является единственным методом избежать ухудшения сигнала. Сокращение избыточности приводит к коэффициентам сжатия в диапазоне от 2 до 5;
2) другие схемы сжатия позволяют получить коэффициент сжатия от 5 до 12;
3) меры искажения реконструкции сигнала, как правило, приводятся в единицах среднеквадратичной амплитуды RMS (root mean square). Однако показатели RMS являются усредненными и даже при малых величинах RMS может возникнуть непредвиденно большое число абсолютных искажений важных частей сигнала;
4) проверка схем сжатия всегда должна включать в себя анализ ошибок в абсолютной амплитуде, так как они могут превышать показатели RMS в 10 - 20 раз;
5) применялись также различные преобразования сигнала (дискретное преобразование Фурье, преобразование Карунена-Лоэва (Karhunen-Loeve), преобразование Уолша). Полученный диапазон коэффициентов сжатия составил от 6 до 12. Однако для этих методов точность восстановления задается только в RMS. Опубликованные результаты указывают на то, что сжатие с помощью таких преобразований может использоваться для сокращения данных одного типичного цикла ЭКГ, но не для сжатия всей записи ЭКГ;
6) измеримость минимальных зубцов и воспроизводимость зазубрин/волн соединения определяет возможное сжатие ЭКГ. В настоящий момент согласно рекомендациям CSE требуется минимальная измеримость элементов до 20 мкВ/6 мс. В отчетах отмечались клинически значимые зазубрины длиной 4 мс. Однако в результате недавних экспериментов требования к минимальной длительности элементов сигнала по практическим причинам были доведены до 10 мс. При частоте 500 считываний/с более короткие элементы в действительности не могут быть надежно измерены;
7) стандартизация сжатия данных ЭКГ требует:
a) гармонизации спецификаций аппаратного обеспечения, шума усилителя, диапазона входного напряжения, точности аналого-цифрового преобразования, значения LSB и т.п.;
b) определения пределов воспроизводимости и максимальной устойчивости к ошибкам.
6.4.1 Предложенное решение по сжатию
За исключением сокращения избыточности, любое сжатие приводит к сокращению разрешения сигнала. Тем не менее, с практической точки зрения, не каждый мкВ разрешения и не каждый бит разрешения являются значимыми. Более важно то, что измерения, полученные при адекватных параметрах разрешения времени и амплитуды, соответствуют друг другу перед сжатием и после него.
Поэтому исследователями некоторых компаний была разработана схема сжатия, в которой эталонный цикл обрабатывается с помощью исходных данных и хранится или передается таким образом, чтобы повторная обработка обеспечила такие же результаты измерения, как и прежде. Этого можно достигнуть с помощью:
a) сжатия, использующего только сокращение избыточности;
b) передачей указателей (точек идентификации зубцов), позволяющих повторное измерение, на основании тех же ссылок.
За исключением эталонного цикла остаточная запись хранится и передается. Остаточная запись формируется путем вычитания эталонного цикла из исходной записи сигнала ЭКГ в каждой локации цикла. Остаточная запись пропускается через низкочастотный фильтр, обрезается, и частота считываний сокращается. Из этой записи первые или вторые разности амплитуды кодируются методом Хаффмана и хранятся или передаются. Воссоздание записи ЭКГ для просмотра возможно с помощью добавления эталонного цикла в остаточную запись в соответствующих местах циклов. Данный метод позволяет получить общие коэффициенты сжатия до 20 раз.
Подробный анализ данной схемы сжатия в проекте SCP-ECG показал, что в реконструированной записи могут возникать относительно большие ошибки в QRS-комплексе. Эти ошибки возникают в результате низкочастотной фильтрации. В частности, разделы QRS в остаточной записи содержат высокочастотные компоненты, которые удаляются после низкочастотной фильтрации, огрубления и сокращения частоты считываний, осуществляемых методами, предложенными и используемыми в некоторых коммерческих программах.
Поэтому в проекте SCP-ECG был разработан метод, применяющий, по сути, ту же самую схему сжатия, но при этом защищающий раздел QRS от низкочастотной фильтрации и сокращения частоты считываний. Таким образом, сохраняются все детали комплекса QRS-T, на основании которых должен быть выведен основной морфологический диагноз. В остаточной записи, необходимой для реконструкции записи ЭКГ, на основании которой должен быть сделан диагноз ритма, при применении схемы сжатия, разработанной в SCP-ECG, могут быть обнаружены только едва заметные человеческому глазу изменения. Эти изменения не влияют на диагноз ритма исследуемых случаев.
Основным преимуществом новой схемы сжатия является защита существенных деталей чувствительных разделов данных QRS и возможность значительного улучшения общей точности. Подробное описание методологии приведено в приложении C вместе с числовыми примерами.
6.4.2 Методология тестирования предложенных решений
Для исследования поведения этого и других разных алгоритмов сжатия первым использовался набор (тестовый набор номер 1), состоящий из 11 ЭКГ, взятых из базы данных CSE, предназначенной для оценки точности распознавания зубцов. Эти ЭКГ были выбраны в соответствии с ритмом (синусовый ритм, фибрилляция предсердий, трепетание предсердий), наличием "нормальных" циклов и экстрасистол, с различной морфологией QRS, включая обычный инфаркт, инфаркт миокарда, гипертрофию левого желудочка и другие. Они представляют различные типы сигналов ЭКГ и содержат низкие и высокие уровни низкой частоты (изолинии) и высокочастотного шума (частота сканирования, мышечный тремор). Основные наблюдения могут быть произведены на основании этого набора данных. Для получения статистически значимых данных был разработан второй набор (тестовый набор номер 2), состоящий из 89 + 19 ЭКГ из диагностических исследований CSE. Эти данные были выбраны в соответствии с распределением амплитуд, которые должны быть кратными 1 мкВ. Они также состоят из случаев с нормальным и нарушенным ритмом, экстрасистолами, а также с нормальной и патологической морфологией QRS.
В некоторых ситуациях полезно использовать искусственные сигналы (например, симулирующих трепетание предсердий) и нескольких искусственных ЭКГ с нормальной морфологией P-QRS-T. Во избежание неправдоподобных результатов, связанных с краями сигнала и т.п., было предусмотрено, что первые и вторые производные всех отведений являются непрерывными. Преимущество синтезированных сигналов заключается в том, что истинные амплитуды и интервалы известны, а результаты экспериментов сжатия не скрываются за последствиями удаления шума или его воспроизведения.
В приложении C представлен набор тестовых ЭКГ, с помощью которого в соответствии с требованиями, описанными в настоящем стандарте, может быть выполнено тестирование соответствия и оценивание на наличие ошибок в алгоритмах сжатия ЭКГ.
6.5.1 Общие положения
На основании результатов исследований, проведенных в рамках проекта SCP-ECG, в качестве стандарта для цифрового кодирования и сжатия ЭКГ были выбраны описанные ниже дискретизация и пределы искажений.
6.5.2 Категории схем сжатия
Можно идентифицировать три основные категории сжатия информации ЭКГ:
6.5.3.1 Способ сжатия данных оставлен на усмотрение производителей. Однако в том случае, когда применяется вычитание эталонного цикла, должны передаваться эталонный цикл типа 0 и остаточная запись. Ошибки реконструкции в единицах RMS и в абсолютных величинах должны верифицироваться на тестовом наборе SCP. Меры искажений должны вычисляться от начала первого вычитания до конца последнего вычитания. Для сжатия, при котором только исключается избыточность, ошибки реконструкции (в единицах RMS и абсолютных величинах, за исключением ошибок дискретизации) должны равняться 0 при оцифровке с частотой 500 считываний/с и дискретизацией 5 мкВ/LSB.
6.5.3.2 Если для сжатия данных используется вычитание эталонного цикла, то все отведения записи ЭКГ должны записываться одновременно.
6.5.3.3 Дискретизация: SR >= 500 считываний/с; LSB <= 5 мкВ.
6.5.3.4 Эталонный цикл: SR >= 500 считываний/с; LSB <= 5 мкВ.
6.5.3.5 Остаточная запись: ошибка усечения <= +/- 15 мкВ.
6.5.3.6 Остаточная запись: интервал между считываниями <= 8 мс.
6.5.3.7 Ошибка реконструкции: RMS <= 10 мкВ.
6.5.3.8 Абсолютная ошибка: <= 100 мкВ в одном считывании за пределами P-QRS-T.
6.5.3.9 Абсолютная ошибка внутри QRS: <= 15 мкВ в отдельном считывании.
(обязательное)
В МНОГОЯЗЫЧНОЙ СРЕДЕ
A.1 Общие положения
В настоящем приложении рассмотрен метод кодирования текстовых полей в SCP-ECG. Он взят из стандартов ИСО/МЭК, описывающих использование нескольких наборов символов. Для лучшего понимания настоящего приложения необходимо ознакомиться со структурой и правилами расширения 8-битового кода ИСО, представленных в ИСО/МЭК 4873 и ИСО/МЭК 2022.
Несколько наборов символов требуется не только в случае японского языка, но также для европейских языков, использующих символы, не входящие в ASCII (например,
Строка символов, включающая неизвестные наборы символов, может привести к серьезным проблемам в идентификации пациентов в некоторых машинах. Поэтому в данном приложении должен быть также описан метод обработки не поддерживаемых наборов символов.
A.2 Область применения
К полям протокола SCP-ECG, перечисленным в таблице A.1, должно быть применено кодирование текста.
Таблица A.1
Поля протокола SCP-ECG
Данное кодирование предназначено в качестве формата обмена, а не внутреннего представления. Ожидается (но не требуется), что каждая компьютерная система ЭКГ должна преобразовывать данный формат в некоторое внутреннее представление для обработки и визуализации, а для обмена данными преобразовывать внутреннее представление в данный формат.
A.3 Ссылки и определения
A.3.1 Ссылки
См. раздел 2, а также следующие источники:
ИСО/МЭК 2375, Информационные технологии. Процедура регистрации управляющих последовательностей и наборов кодированных символов (ISO/IEC 2375, Information technology - Procedure for registration of escape sequences and coded character sets)
ИСО/МЭК 6429:1992, Информационные технологии. Функции управления для наборов кодированных символов (ISO/IEC 6429:1992, Information technology - Control functions for coded character sets)
ИСО/МЭК 8859-2:1999, Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 2. Латинский алфавит N 2 (ISO/IEC 8859-2:1999, Information technology - 8-bit single-byte coded graphic character sets - Part 2: Latin alphabet No. 2)
JIS X 0202, Методики расширения кода для использования с кодом для обмена информацией; Японский промышленный стандарт (JIS) [JIS X 0202, Code Extension Techniques for Use with the Code for Information Interchange; Japanese Industrial Standard (JIS)]
SCHEIFLER R.W. Compound Text Encoding version 1.1, MIT X Consortium Standard
A.3.2 Термины и определения
Для целей настоящего приложения следующие определения были взяты из ИСО/МЭК 4873 и JIS C 6228, который 1 марта 1987 г. был переименован в JIS X 0202.
В соответствии с настоящим стандартом набор символов Latin-1, определенный в ИСО/МЭК 8859-1, должен использоваться по умолчанию.
A.3.2.1 кодированный набор символов, код (coded character set, code): Набор однозначных правил, определяющий набор символов и связь один-к-одному между каждым символом набора и его кодированным представлением с помощью одного или нескольких сочетаний битов.
A.3.2.2 управляющий символ (control character): Функция управления, кодированное представление которой состоит из комбинации значений одного бита.
A.3.2.3 графический символ (graphic character): Символ, не являющийся функцией управления, обладающий визуальным представлением, как правило, написанным от руки, напечатанным или отображенным, который также обладает кодированным представлением, состоящим из одной или нескольких комбинаций битов.
A.3.2.4 функция управления (control function): Действие, влияющее на запись, обработку, передачу или интерпретацию данных, которое также обладает кодированным представлением, состоящим из одной или нескольких комбинаций битов.
A.3.2.5 спецификация формата (format effector): Символ, управляющий организацией и расположением информации в устройствах визуализации символов, например, устройствах печати и отображения.
A.3.2.6 назначать (to designate): Идентифицировать набор символов, которые необходимо представить заранее определенным образом в некоторых случаях сразу, а в других при появлении следующей функции управления.
A.3.2.7 вызывать (to invoke): Обеспечить представление назначенного набора символов с помощью заранее определенных комбинаций битов там, где эти комбинации битов возникают, и до тех пор, пока не появится соответствующая функция расширения.
A.3.2.8 представлять (to represent):
a) использовать заранее определенную комбинацию битов, назначающую символ из назначенного и вызванного набора символов, или
b) использовать управляющую последовательность со значением дополнительной управляющей функции.
A.4 Значения
Значения байтов представлены в настоящем приложении как два десятичных числа в форме столбец/строка в соответствии со стандартами ИСО/МЭК. Это означает, что значение может быть вычислено как (столбец*16) + строка; например, 01/11 соответствует значению 27 (1B hex).
Пространство кодирования байтов разделено на четыре диапазона (см. рисунок A.1):
Диапазоны C0 и C1 являются наборами "управляющих символов", в то время как GL и GR являются наборами "графических символов". В диапазоне GL байт 02/00 всегда определяется как пробел (SPACE), а байт 07/15 (обычно команда удаления DELETE) никогда не используется.
Массив из столбцов 16 на 16, пронумерованных от 00 до 15, и строк, пронумерованных от 0 до 15, содержит 256 позиций кодов. Столбцы массива с 00 по 07 содержат 128 позиций символов, которые находятся в отношении один к одному с символами 7-битового набора. Их кодированное представление является таким же, как в 7-битовой среде с добавлением восьмого бита, равного НУЛЮ. Столбцы с 08 по 15 содержат дополнительные 128 позиций. Восьмой бит их кодового представления является ЕДИНИЦЕЙ. Столбцы с 08 по 09 используются для обозначения управляющих символов, а столбцы с 10 по 15 - для обозначения графических символов, за исключением позиций 10/0 и 15/15.
Кодовая 8-битовая таблица может быть расширена за счет различных средств расширения, одним из которых является применение соответствующей управляющей последовательности, как показано в A.6.2.
![]() A.5 Управляющие символы
Определение каждого управляющего символа взято из ИСО/МЭК 646 и ИСО/МЭК 4873.
Как показано в таблице A.2, в SCP-ECG для кодирования свободного текста должно использоваться только подмножество управляющих символов C0. Не должны использоваться никакие значения из управляющего набора C1.
При обмене данными текстовых строк (например, определенных в разделах 8, 10 и 11) может потребоваться некоторая информация по их формату. Для этой цели должны использоваться символы форматирования (перечисленные в таблице A.2), но их использование должно быть сведено к минимуму, так как некоторые машины могут неправильно их обрабатывать.
Таблица A.2
1) BS
Возврат может использоваться для формирования составных символов с помощью наложения знаков (ИСО/МЭК 646 позволяет осуществлять представление такого рода). Тем не менее некоторые машины не имеют возможности наложения знаков, поэтому для представления составных символов лучше использовать адекватные наборы символов (например, ИСО/МЭК 8859-1).
2) HT, VT
Спецификация настроек ширины табуляции не является частью данного предложения.
3) CR
Возврат каретки также может использоваться для образования составных символов. То же самое можно сказать о BACKSPACE.
4) LF
Некоторые машины (например, работающие с операционной системой UNIX) могут интерпретировать перевод строки (00/10) как переход на начало новой строки (NEWLINE). Это можно интерпретировать как использование (нерекомендуемого) режима NEW LINE, описанного в E.1.3 в ИСО/МЭК 6429:1992.
В настоящем приложении символ форматирования NEWLINE представлен парой CR + LF. Поэтому при использовании описанной выше среды ожидается, что эта пара преобразуется во внутреннее представление (т.е. CR + LF преобразуется в LF).
Нулевой байт (NULL) используется в протоколе SCP-ECG в качестве признака завершения строки. Но он не является частью этой строки. Это соответствует ИСО/МЭК 646 и ИСО/МЭК 4873.
A.6 Кодирование набора символов
A.6.1 Общий принцип многоязычного кодирования текста
Для реализации многоязычной среды необходимо средство переключения разных наборов символов в текстовой строке. Некоторые графические символы обладают различным визуальным представлением, но имеют один код, например, строчная "a" с тильдой, определенная в ИСО/МЭК 8859-1, и строчная "a" с бревисом, определенная в ИСО/МЭК 8859-2, имеют один код, а именно 14/03. Кроме того, существуют некоторые многобайтовые наборы символов, например японский Кандзи и китайский Ханьцзы, содержащие тысячи символов, кодирование которых одним байтом невозможно.
ИСО/МЭК 2022 определяет способы расширения кода (см. рисунок A.2), делая возможным использование нескольких наборов графических символов в текстовой строке, обеспечивая тем самым многоязычную среду. В ИСО/МЭК 2022 расширение кода реализуется отображением желаемого набора графических символов на кодовое пространство, используя следующие два шага:
1) желаемый набор графических символов назначается как одно из множеств G0, G1, G2 или G3; это выполняется с помощью управляющих последовательностей;
2) назначенный набор (G0, G1, G2 или G3) отображается в пространстве кодирования с 02/00 по 07/15 или 10/00 по 15/15; это выполняется с помощью функций переключения регистра.
![]() A.6.2.1 Следует использовать только 8-битовую среду, а также всегда применять G0 для GL и G1 для GR (см. рисунок A.3). Такой подход реализуется за счет объявления необходимых средств расширения в соответствии с разделом 9 в ИСО/МЭК 2022:1994. В этом случае назначение также служит вызовом, поэтому необходимость в явном вызове отсутствует.
Набор из 96 символов может быть назначен/вызван только в диапазон GR. Это связано с тем, что код 02/00 назначен пробелу (SPACE), а код 07/15 - удалению (DELETE), поэтому диапазон GL может содержать только 94 символа в диапазоне кодов от 02/01 до 07/14. Диапазон GR может содержать 96 символов с кодами от 00/00 до 15/15. Поэтому в диапазон GR могут быть вызваны как наборы из 94 символов, так и наборы из 96 символов.
В наборе из 94 символов никакие символы не должны размещаться в позициях 02/00, 07/15, 10/00 и 15/15, в то время как в наборе из 96 символов эти позиции могут содержать символы. Трехмерный блок на рисунке A.3 представляет многобайтовый набор символов. Набор из 94N символов использует N (N > 1) байтов для каждого символа, как показано на рисунке A.3.
A.6.2.2 По умолчанию набор GL соответствует левой половине таблицы ИСО/МЭК 8859-1. Это равносильно кодировке ASCII (ANSI X3.4-1968).
A.6.2.3 По умолчанию набор GR соответствует правой половине таблицы ИСО/МЭК 8859-1. Эти спецификации определяют набор символов по умолчанию, который может использоваться без управляющей последовательности в соответствии с указанным в 6.4 "Начальным назначением и вызовом" в ИСО/МЭК 2022. Подмножество ИСО/МЭК 2022 для SCP-ECG показано на рисунке A.3.
![]() (подмножество ИСО/МЭК 2022)
A.6.2.4 Подразумеваемое начальное состояние в ИСО/МЭК 2022 определено последовательностью, показанной в таблице A.3.
Таблица A.3
Подразумеваемое начальное состояние в ИСО/МЭК 2022
Набор символов по умолчанию для SCP-ECG показан на рисунке A.4.
![]() Рисунок A.4 - Набор символов по умолчанию для SCP-ECG
A.6.3 Расширение набора символов
A.6.3.1 На рисунке A.5 показана структура поля строки, закодированного в соответствии с ИСО/МЭК 2022. Текстовая строка с таким кодированием содержит символы управляющей последовательности или функции переключения регистра, а также объявление средств расширения в начале строки.
![]() A.6.3.2 Метод ИСО/МЭК 2022 является гибким и эффективным, но его полная реализация может быть очень сложной для протокола SCP-ECG. Некоторые управляющие последовательности, функции переключения регистра и объявления могут быть опущены в соответствии с настоящим стандартом.
Чтобы опустить некоторые управляющие последовательности и предложить более простой метод многоязычного кодирования, применяются следующие правила:
1) объявления (1), показанные на рисунке A.5, должны быть опущены по соглашению между обменивающимися сторонами о средствах расширения;
2) функции переключения регистра (3) и (4) должны быть опущены с помощью управляющих последовательностей, которые назначают, а также вызывают G0 и G1 в GL и GR соответственно, как это определено последовательностью "ESC 02/00 04/03";
3) управляющая последовательность (2) опускается с помощью следующей начальной установки по умолчанию:
- назначить ASCII (левая часть таблицы ИСО/МЭК 8859-1) в G0, а также вызвать ее в GL,
- назначить Latin-1 (правая часть ИСО/МЭК 8859-1) в G1, а также вызвать ее в GR,
- назначить ИСО/МЭК 646 в C0,
- никаких назначений в C1.
Если используется только набор ИСО/МЭК 8859-1, то в текстовой строке не должны присутствовать никакие управляющие последовательности. Это обычная 8-битовая текстовая строка в кодировке ASCII. Если в строке требуется другой набор символов, то для переключения набора символов необходимо указать перед ним управляющую последовательность.
Формат текстового поля с несколькими наборами символов приведен в таблице A.4.
Таблица A.4
Формат кодированной текстовой строки в SCP-ECG
Каждая передаваемая строка должна начинаться с набора символов по умолчанию. Новое поле или завершающий NULL должны осуществлять сброс к набору символов по умолчанию.
A.6.3.3 Формат управляющей последовательности для набора символов расширения
ESC {I} F:
- "ESC" является символом начала управляющей последовательности. Он имеет кодовое представление 01/11.
- "{I}" означает один или несколько "промежуточных символов", которые находятся в диапазоне 02/00 - 02/15. Он задает функцию управляющей последовательности.
- "F" означает "финальный символ", который всегда находится в диапазоне 04/00 - 07/14. Финальные символы зарегистрированы международным регистрирующим органом. Некоторые из финальных символов перечислены в A.6.4.
A.6.3.4 Чтобы указать, что другой набор символов является GL-набором, используется одна из следующих управляющих последовательностей:
В последовательности "ESC 02/04 F" могут использоваться финальные символы 04/01 и 04/02. Это исключение взято из 6.3.9, ИСО/МЭК 2022:1994. Последовательность "ESC 02/04 04/02" для набора японских символов широко используется в Японии.
A.6.3.5 Чтобы указать, что другой набор символов является GR-набором, используется одна из следующих управляющих последовательностей:
A.6.3.6 Разрешены промежуточные символы 02/00, 02/01, 02/04, 02/09 и 02/13. Следующие промежуточные символы не разрешены в SCP-ECG:
02/02, 02/03, 02/05, 02/06, 02/07, 02/10, 02/11, 02/12, 02/14 и 02/15.
A.6.3.7 Финальные символы для частного кодирования (в диапазоне от 03/00 до 03/15) не разрешены в SCP-ECG.
A.6.3.8 Другие управляющие последовательности, описанные в ИСО/МЭК 2022, не должны использоваться для SCP-ECG.
A.6.3.9 Набор из 94N символов использует для каждого символа N байтов (N > 1). Значение N получено из значения столбца финального символа F, указанного выше:
В кодировании 94N значения байтов 02/00 и 07/15 (в GL), а также 10/00 и 15/15 (в GR) никогда не используются (определения столбцов взяты из ИСО/МЭК 2022).
В SCP-ECG должны использоваться только международные зарегистрированные финальные символы. Некоторые из финальных символов, которые могут использоваться, показаны в таблице A.5.
Наборы, перечисленные как "Левая половина...", всегда должны определяться как GL. Наборы, перечисленные как "Правая половина...", всегда должны определяться как GR. Другие наборы могут определяться как GL, так и GR.
Если финальные коды 04/01, 04/02 и 04/03 используются в форме "ESC 02/04 F", то они всегда определены как GR.
Таблица A.5
A.7 Код языка
Поле "Код языка" раздела 2 в протоколе SCP-ECG используется для идентификации класса используемого набора символов. Это поле кодируется в соответствии с таблицей A.6.
Таблица A.6
Код языка
Следует учитывать, что при использовании правой половины ИСО/МЭК 8859-1 бит 0 должен иметь значение 1. В этом случае в строке не должны появляться никакие управляющие последовательности.
A.8 Метод обработки не поддерживаемых наборов символов
A.8.1 Общие положения
Использование в строке не поддерживаемых наборов символов может привести к серьезным проблемам при идентификации пациента. Ниже описан метод обработки не поддерживаемых наборов символов. Предполагается, что существует система, которая может отобразить/напечатать все символы.
A.8.2 Машина, использующая ИСО/МЭК 8859-1
Все символы диапазонов GR и GL, которые не поддаются обработке, следует распечатывать, отображать и вводить следующим образом:
- заменить все символы "\" (05/02) на два символа "\\";
- заменить символ перехода (escape) (01/11), предшествующий неизвестным управляющим последовательностям, на четыре символа "\033". Следует учесть, что известные управляющие последовательности должны обрабатываться надлежащим образом.
A.8.2.1 Машина, использующая ASCII
Все символы диапазонов GR и GL, которые не поддаются обработке, следует распечатывать, отображать и вводить следующим образом:
- заменить все символы "\" (05/02) на два символа "\\";
- заменить символ перехода (escape) (01/11), предшествующий неизвестным управляющим последовательностям, на четыре символа "\033" (следует учесть, что известные управляющие последовательности должны обрабатываться надлежащим образом);
- заменить символы диапазона GR на четыре символа "\nnn", где "nnn" - трехзначное восьмеричное представление каждого байта.
Проверка кода языка является полезной практикой для данного метода. Тем не менее синтаксический разбор текстовой строки по-прежнему необходим, так как в одной строке могут быть как поддерживаемые, так и неподдерживаемые наборы символов.
Примечание - Это предложение не определяет действия для случаев переполнения полей отображения, печати или ввода.
A.9 Краткое изложение управляющих последовательностей, описанных в данном приложении для кодирования произвольного текста в SCP-ECG
В начале обмена информацией может потребоваться объявление средств расширения кода, использованных в последующих данных. Если подобное объявление должно быть вложено в кодированную символьную информацию, то следует использовать один или несколько классов трехсимвольных управляющих последовательностей ESC 02/00 F. В зависимости от соглашения между обменивающимися сторонами подобное объявление может быть опущено.
Не перечисленные в таблице A.7 управляющие последовательности не должны использоваться в текстовых полях. "Объявитель" не должен явно отображаться в этом поле.
Таблица A.7
Управляющие последовательности
A.10 Примеры кодированных текстовых строк
Ниже приведены некоторые примеры закодированных строк. Показано также представление в неподдерживающей среде.
Примеры
Таблица A.8
Кодовое представление
(обязательное)
B.1 Общие сведения
Стандарт SCP-ECG определяет средства, с помощью которых устройства и системы ЭКГ могут обмениваться информацией. Категории формата данных, определенные в настоящем приложении, предоставляют пользователям и производителям устройств и/или систем ЭКГ достаточно простую кодификацию функций и информационного содержания, связанного с SCP-ECG, которые могут быть предоставлены конкретным устройством. Способы кодирования данных ЭКГ точно определены, но при этом являются гибкими. При реализации настоящего стандарта производитель может ограничиться некоторым подмножеством всех возможных способов кодирования данных ЭКГ. Поэтому в разделе B.3 определена процедура тестирования, которое должны пройти производители, объявляющие соответствие SCP-ECG. В связи с гибкостью, допускаемой в информационном содержании и кодировании, пользователь/покупатель должен определить, насколько устройство и/или система пригодны для конкретного применения.
Производители, объявляющие соответствие своих устройств и/или систем стандарту SCP-ECG, должны следовать спецификациям и определениям, приведенным в настоящем приложении. Формат данных включает в себя элементы, указанные в разделах 5 и 6 настоящего стандарта (и в приложениях, на которые они ссылаются). Соответствие поддержки коммуникаций не является обязательной частью настоящего стандарта. Если обмен записями ЭКГ между двумя разными устройствами картирования и/или системами выполняется по каналам последовательной передачи данных (прямое подключение по кабелю или через модем), то возможным решением может служить использование функций передачи сообщений запросов, указанных в приложении D, и транспорта данных, описанного в приложении E. Если используются различные средства обеспечения коммуникаций (например, Bluetooth, беспроводное соединение, ЛВС и т.п.), то сообщения запросов и транспорт данных должны быть точно описаны в стиле приложений D и E. Эти описания должны быть сделаны свободно доступными, чтобы потенциальные пользователи/покупатели устройства картирования или системы могли получать их по запросу.
В настоящее время не существует признанного средства/метода, позволяющего осуществлять проверку соответствия спецификациям настоящего стандарта. В лучшем случае подобное средство было бы полезно производителям в их деятельности по обеспечению совместимости их устройств. За счет гибкости, которую позволяют информационное содержание и кодирование, совместимость между устройствами разных производителей должна определяться для каждого случая, даже если было показано, что оба устройства соответствуют стандарту SCP-ECG. От одной лишь декларации о соответствии настоящему стандарту будет мало пользы пользователю/покупателю. Поэтому декларация о соответствии стандарту SCP-ECG должна сопровождаться декларацией о совместимости с устройством или устройствами другого производителя или производителей, однозначно идентифицированных торговой маркой производителя, описанием модели и идентификатором программного обеспечения, реализующего SCP.
B.2 Спецификация соответствия
B.2.1 Категории форматов данных
В таблице B.1 определены категории форматов данных, которые должны использоваться в декларации о соответствию стандарту SCP-ECG. Информационное содержание, предусмотренное каждой категорией, представлено в графе "Описание содержания". Соответствие предполагает, что данные каждого раздела должны кодироваться, как указано в применимом подразделе раздела 5.
Таблица B.1
В будущих версиях может быть добавлена дополнительная категория, удовлетворяющая определенным требованиям устройств ЭКГ, используемых в других приложениях (например, в телемедицине или медицинской помощи на дому).
Все устройства, для которых декларировано соответствие стандарту SCP-ECG, должны как минимум импортировать данные, описанные в разделах 0, 1, 3, 6, 7 и 8. Во все категории могут быть добавлены дополнительные разделы (например, 9, 10, 11). Данные, специфичные для производителя, должны (не обязательно) быть включены в определенные в настоящем стандарте поля, байты и блоки данных, специфичные для производителя. Зарезервированные, не указанные и не определенные поля, байты и блоки данных не должны использоваться для данных, специфичных для производителя.
B.2.2.1 Экспорт
Способность сделать запись SCP-ECG, имеющую заданную категорию формата данных, доступной для коммуникационных каналов. В соответствии со спецификацией SCP-ECG запись SCP-ECG создается из необработанных данных ЭКГ, с использованием сжатия, указанного в 6.5.3.
B.2.2.2 Импорт
Способность принимать из коммуникационного канала, извлекать и делать доступной для пользователя информацию из записи SCP-ECG, имеющей заданную категорию формата данных. Импортирующее устройство должно как минимум импортировать данные, описанные в разделах 0, 1, 3, 6, 7 и 8 [например, из стандартного 10-секундного ЭКГ в 12 отведений (кодируются I, II, V1, V2, V3, V4, V5, V6)], и делать извлеченную информацию доступной для пользователя (при этом должны быть выполнены требования 6.5.3).
B.2.2.3 Пересылка
Экспорт ранее импортированной записи в том же формате данных, с модификацией или без модификации отдельных разделов. Записи ЭКГ, хранящиеся в форматах, отличных от SCP, могут быть преобразованы в соответствии с форматом SCP-ECG. Данные сигнала ЭКГ, импортированные в формате SCP ЭКГ, не должны искажаться в процессе сжатия для пересылки.
Целью определения пересылки является сохранение компонентов записи (например, раздела, специфичного для производителя), которые импортирующее устройство неспособно обработать. Требование того, чтобы данные ЭКГ не испытывали дополнительные потери при пересылке, подразумевает либо отправку исходных сжатых данных или дополнительное сжатие без потери качества. Редактирование пользователем демографических данных, измерений и интерпретаций, а также сокращение или потери данных по выбору пользователя, не входят в настоящий стандарт.
B.2.2.4 Коммуникационный канал
Любой механизм, способный передать запись SCP-ECG для внешнего доступа.
Примечание - Примером коммуникационного канала может служить RS-232, используемый для передачи сообщений запросов, описанных в приложении D, с использованием транспорта, описанного в приложении E. Настоящий стандарт не запрещает, но и не поддерживает использование какого-либо другого механизма.
B.2.3 Передача сообщений SCP-ECG/транспортный протокол
Если обмен записями ЭКГ между разными устройствами картирования и/или системами выполнен по каналу последовательной передачи данных (прямое подключение по кабелю или через модем), то возможное решение задачи отправки сообщений запросов можно найти в приложении D, а решение транспорта данных - в приложении E. Для устройства должны быть декларированы поддерживаемые технологии коммуникаций (RS-232, Bluetooth, беспроводное соединение, ЛВС и т.д.), а также утверждение, что информация о коммуникационном протоколе отправки сообщений запросов и транспорте данных может быть получена по запросу. Обычно производитель должен раскрыть информацию о механизме или механизмах, с помощью которых можно получить доступ к файлам данных, форматированных в соответствии со стандартом SCP-ECG.
Если устройство картирования/система поддерживает коммуникационный протокол RS-232, то декларация "поддерживается отправка сообщений запросов" означает, что имеет место соответствие с приложением D, но при этом используется транспортный протокол, который не определен в настоящем стандарте и который производитель должен раскрыть. Декларация "поддерживаются отправка сообщений запросов и транспортный протокол" означает соответствие приложениям D и E. Если устройство не поддерживает все указанные функции, оно будет считаться соответствующим стандарту, если может отвечать на запросы таким образом, как это описано в настоящем стандарте. Например, если "Запрос списка пациентов" (D.2.2.2) не поддерживается, то на такой запрос можно передать ответ "обработка запроса не поддерживается" [D.2.6, 11)]. Устройство, которое не может возвратить ответ на неподдерживаемый запрос или его ответ отличается от указанного в настоящем стандарте, не будет считаться соответствующим стандарту.
Известно, что существуют другие механизмы для передачи файлов в формате SCP-ECG. Настоящий стандарт не запрещает, но и не поддерживает использование каких-либо других механизмов, отличных от отправки сообщений запросов SCP-ECG и транспортного протокола, определенных в приложениях D и E.
Декларация о соответствии стандарту SCP-ECG должна иметь следующую форму и содержание:
B.2.5 Гипотетические примеры
B.2.5.1 Кардиограф
B.2.5.2 Система управления
B.2.5.3 Дефибриллятор, ЭКГ в 12 отведений
B.3.1 Обзор
Тестирование/подтверждение соответствия/совместимости формата данных стандарту SCP-ECG может быть выполнено отдельными производителями. Требования к тестированию/подтверждению соответствия показаны на рисунке B.1 и подробно рассмотрены в B.3.2. Каждый производитель, декларирующий соответствие экспорта, предоставляет публично доступный и бесплатный пример записей в формате SCP-ECG для каждого устройства, генерирующего ЭКГ, и для каждого заявленного уровня формата данных, а также дополнительные обеспечивающие файлы данных, позволяющие импортирующему производителю подтвердить соответствие точного декодирования записей SCP-ECG. Прочитав файлы производителя A, производитель B может подтвердить, что файлы производителя A могут быть импортированы. Если в декларации о соответствии SCP-ECG производитель B заявляет, что совместимость с A в области импорта была подтверждена, то производитель B в письменной форме оповещает об этом производителя A. Затем производитель A может заявить о подтверждении совместимости с B в области экспорта. Тем самым производители совместно подтверждают совместимость друг с другом.
Подтверждение соответствия импорта может быть представлено диаграммой, показанной на рисунке B.1.
![]() Производитель экспорта должен создать пять типов файлов и сделать их открытыми и общедоступными для каждого предоставленного теста, для каждого типа экспортирующего устройства и для каждого уровня соответствия.
1) двоичный файл в формате SCP-ECG (***.ECG);
2) исходный файл необработанных данных ЭКГ, из которого был получен файл SCP-ECG, в двоичном формате, определенном в B.3.3 (***.EC0);
3) распакованный файл данных ЭКГ из файла SCP-ECG, полученный с помощью процесса распаковки производителя экспорта и имеющий двоичный формат, определенный в B.3.3 (***.EC1);
4) текстовый файл, описанный в B.3.3 и содержащий определения данных в исходном и распакованном двоичных файлах ЭКГ (***.EC2);
5) файл данных ASCII (для данных, не являющихся сигналами), содержащий все демографические данные, измерения и данные интерпретации (***.EC3).
Производитель экспорта должен предоставить тестовые комплекты, состоящие из файлов пяти требуемых типов, как минимум для тех случаев, что указаны в разделе C.5 (и в таблице C.13). Производитель экспорта может также предоставить дополнительные тестовые комплекты, состоящие из файлов требуемых типов. Набор тестовых комплектов, предоставляемых производителем экспорта, должен включать файлы, содержание которых ограничено пределами реализации стандарта производителем экспорта.
Для всех тестовых комплектов, предоставленных производителем экспорта, производитель импорта должен импортировать записи SCP-ECG, а затем подвергнуть их декодированию и распаковке. Для каждого теста распакованные данные ЭКГ должны сравниваться с исходными данными ЭКГ (сравнение "A" на рисунке B.1), а распакованные данные ЭКГ должны соответствовать требованиям к дискретизации и пределам искажений, указанным в 6.5. Сравнение "B" между распакованными данными производителя экспорта и распакованными данными производителя импорта позволяет производителю импорта оценить различия, наблюдаемые в сравнении "A". Сравнение "B" не обязательно.
Для каждого тестового комплекта производитель импорта должен сравнить декодированную демографическую информацию, измерения и данные интерпретации с данными в файле ASCII, предоставленном производителем экспорта (сравнение "C" в диаграмме). Это сравнение должно быть точным для всех полей данных, декодированных производителем импорта.
Производитель может заявить совместимость импорта для каждого устройства производителя и для каждой категории формата данных, которая была подтверждена. Если декларировано соответствие импорта для экспортированных файлов другого производителя, то производитель экспорта должен быть оповещен об этом в письменной форме, и экспортирующий производитель должен иметь возможность декларировать совместимость экспорта между ним и импортирующим производителем.
Каждая тестовая ЭКГ должна быть предоставлена вместе со следующей информацией:
1) текстовый файл (***.EC2), содержащий:
i) описатели данных каждого отведения ЭКГ, разделенные запятой (может быть как больше, так и меньше отведений, чем типичные 8, хранящиеся для ЭКГ в 12 отведениях, снятой в состоянии покоя),
ii) общее число считываний для каждого отведения,
iii) частота считываний (в секунду) или интервал между считываниями (микросекунды),
iv) число нановольт в младшем значащем бите,
2) двоичные файлы (***.EC0, ***EC1) с данными ЭКГ, хранящимися в виде 16-битовых слов со знаком в формате Intel (нижний байт, верхний байт). Последовательность считываний (S1, S2, ..., Sn) для отведений (L1, L2, ..., Lm):
S1L1, S1L2 ... S1Lm, S2L1, S2L2 ... SnL1, SnL2... SnLm
Пример - Приведенный в таблице B.2 пример описывает сигнал, снятый с 8 отведений ЭКГ, идентичный для каждого отведения, с чередующимися считываниями +/- 1,0 мВ на каждое отведение. В данном случае значениям +/- 1000 соответствуют шестнадцатеричные значения 03E8 и FC18.
***.EC2 - Текстовый файл, имеющий следующее содержание:
отведения: I, II, V1, V2, V3, V4, V5, V6;
5000 считываний на отведение; 500 считываний в секунду; 1000 нановольт в младшем значащем бите.
***.EC0 или ***.EC1 - Двоичный файл (в шестнадцатеричном формате для каждого байта).
Таблица B.2
В 5.4.5 указано, что байт 16 тега 14 (идентификатор машины снимающего устройства) содержит кодированные категории совместимости. Старшие четыре бита байта 16 должны использоваться для характеристики категории формата данных, а младшие четыре бита того же байта зарезервированы, как это показано в таблице B.3. Хотя конкретное устройство может декларировать множество разных категорий формата данных (B.2.4), старшие четыре бита байта 16 должны указывать категорию формата данных записи, в которую встроен тег.
Таблица B.3
Спецификация 5.4.5, тег 14, байт 16
(обязательное)
МЕТОДА СЖАТИЯ СИГНАЛА ЭЛЕКТРОКАРДИОГРАММЫ
C.1 Общие положения
В настоящем приложении представлен общий подход к рекомендуемым методам сжатия данных сигнала SCP-ECG. Принципы методологии сжатия вначале представлены в форме различных диаграмм (раздел C.2). Затем приводится более детальное описание рекомендуемой методологии сжатия и распаковки данных вместе с соответствующими математическими определениями (см. разделы C.3 и C.4). В заключение приведено описание набора тестов для испытания соответствия (см. раздел C.5).
Для оценки ошибок распаковки при применении данных методов сжатия ЭКГ, а также для тестирования абсолютной точности реализации сжатия был разработан общедоступный набор тестов. Он полезен для подтверждения соответствия и тестирования производительности.
a) Выделить опорные точки во всех комплексах ЭКГ, например, время QRSmax или какой-либо иной маркер:
- опорные точки для вычитания эталонного цикла (см. fc1 - fc7 на рисунке C.1).
b) Идентифицировать типы комплексов ЭКГ, например нормальный тип, различные экстрасистолы:
- QRS-тип 0, 1 и т.д.
![]() Рисунок C.1 - Пример необработанных данных,
опорных точек и типизации QRS
C.2.2 Эталонный цикл 0
a) Вычислить "Эталонный цикл типа 0", например, репрезентативный усредненный цикл, медианный цикл, модальный цикл.
b) Идентифицировать точки начала и завершения зубцов эталонного цикла 0 (см. рисунок C.2):
- длина вычитаемого эталонного цикла 0;
- указатели на сегменты данных QRS (см. рисунки C.3 и C.4), которые должны быть защищены от фильтрации и прореживания.
![]() C.2.3 Остаточная запись
Вычесть эталонный цикл типа 0 из всех комплексов ЭКГ типа 0, используя опорные точки (см. рисунок C.3).
![]() C.2.4 Сжатые данные
a) Низкочастотная фильтрация остаточной записи (исключая защищенные области p).
b) Прореживание считываний от 2 до 8 мс (исключая защищенные области p).
c) Вычисление последовательных разностей второго порядка для всех результирующих данных (см. рисунок C.4).
![]() C.2.5 Кодирование
Далее последовательные разности второго порядка кодируются методом Хаффмана, см. численные примеры.
Для распаковки данных ЭКГ, как правило, выполняются в обратном порядке шаги, применяемые для сжатия. Если используется "высокое сжатие", то для остаточной записи и репрезентативного цикла 0 должны выполняться шаги (a) и (b), описанные ниже. Шаги (c) и (d) применимы только к остаточной записи, в то время как (e) и (f) применимы и к репрезентативному циклу 0, и к остаточной записи.
Ниже приведены шаги распаковки:
a) декодирование с применением таблиц Хаффмана;
b) воссоздание данных из разностей первого или второго порядка;
c) воссоздание прореженных считываний;
d) низкочастотная фильтрация воссозданной остаточной записи за пределами защищенных областей;
e) умножение на AVM (модификатор значения амплитуды);
f) в случае высокого сжатия: сложение эталонного цикла 0 с остаточной записью во всех местах комплекса типа 0. Для этого должны использоваться хранящиеся указатели fc(k), SB(k) и SE(k) остаточной записи и fcM эталонного цикла 0.
C.3.1 Определения
C.3.1.1 Необработанные данные
Элементы необработанных данных: Xr(m, n)
Нижний индекс r: необработанные данные
Отведение: m; 1 <= m <= M
Считывание: n; 1 <= n <= N
Дискретизация амплитуды: LSB [мкВ] = AVM·10-3
(AVM, множитель значения амплитуды, указанный в разделе 6, байты заголовка 1, 2.)
Интервал между считываниями: Sl [мс] = STM·10-3
(STM, множитель времени считываний, указанный в разделе 6, байты заголовка 3, 4.)
C.3.1.2 Связь номера и времени считывания
a) По определению: первое считывание (n = 1) выполняется в момент t = 0.
b) Интервал между считываниями (SI) 2 мс указан как минимальное требование для данных, совместимых с SCP-ECG.
c) При SI = 2 мс связь между считыванием n и временем t записи имеет вид
t = (n - 1)·S/[мс] = 2(n - 1)[мс].
C.3.1.3 Примеры деноминации и индексирования данных ЭКГ
C.3.1.3.1 Необработанные данные
Отведения I, II, V1, ...,
.Длина записи 10 с, интервал между считываниями 2 мс.
Число считываний
![]()
C.3.1.3.2 Эталонный цикл
Отведения I, II, V1, ...,
.Длина записи 1 с, интервал между считываниями 2 мс.
Число считываний
![]()
Примечание - Данные (потенциалы B) для отведений III, aVR, aVL и aVF могут быть вычислены по формуле Эйнтховена и Голдберга, согласно которой:
C.3.1.4 Указатели
C.3.1.4.1 Необработанные данные
Указатель на опорную точку цикла k в необработанных данных (число комплексов QRS в необработанных данных: K): fc(k).
C.3.1.4.2 Эталонный цикл
C.3.1.4.3 Остаточная запись
Примечание - Указатели QB(k), QE(k) явно хранятся в записи SCP-ECG, раздел 4 (см. 5.7.5). Защищенная область включает в себя интервал от начала до завершения QRS-комплекса, но он может превышать его (например, из-за границ прореженных N-считываний, см. C.3.4.2). Начало и завершение QRS-комплекса могут быть вычислены по значению опорной точки fcM эталонного цикла 0, длительности его QRS-комплекса и интервалов bM и eM (см. C.3.3.1), а также по значениям опорных точек fc(k) для каждого цикла.
QRSonset(k) = fc(k) - bM,
QRSoffset(k) = fc(k) - eM,
где QRSonset - начало комплекса QRS, а QRSoffset - его завершение.
C.3.2 Огрубление всех значений до разрешения 5 мкВ
C.3.2.1 Общие положения
При дискретизации амплитуды (разрешение, точность) необработанных данных и данных эталонного цикла младший значащий бит (LSB) должен иметь значение <= 5 мкВ. Следующие уравнения описывают огрубление данных до 5 мкВ/LSB в предположении, что исходные данные записываются с разрешением 1 мкВ/LSB.
Примечания
1 Не все компиляторы одинаково обрабатывают округление и огрубление. При разработке программы, выполняющей сжатие, необходимо обеспечить правильное выполнение округления положительных и отрицательных чисел. Например, в процессорах Intel огрубление всегда направлено к нулю, т.е. -9/5 = -1,8 огрубляется до -1. Напротив, при вычислениях со смещением двоичного числа результат огрубления будет эквивалентен -2.
2 Индекс t: огрубленные данные.
для Xr (m, n) >= 0, для Xr (m, n) < 0. для Yr (m, p) >= 0, для Yr (m, p) < 0.C.3.3 Вычитание эталонного цикла из необработанных данных сигнала
Протокол SCP-ECG спроектирован для обработки данных сигнала ЭКГ, которые могут подвергаться сжатию и кодированию различными методами:
a) только сокращение избыточности;
b) "высокое сжатие" при помощи "эталонного цикла 0", кодируемого отдельно; он может быть вычтен из необработанных данных и остаточные данные могут быть отфильтрованы, считывания прорежены и т.д.
Далее подробно описаны вычисление и спецификация остаточной записи в случае, когда применяется метод b), описанный выше как схема "высокого сжатия".
C.3.3.2 Огрубленные необработанные данные
Пусть имеются огрубленные необработанные данные отведения V6 с выделенными комплексами ЭКГ (опорные точки fck), показанные на рисунке C.5.
![]() Рисунок C.5 - Пример необработанных данных
и опорных точек с указанием типов QRS
В таблице C.1 приведены местоположения и типы комплексов QRS, выделенных в необработанных данных, показанных на рисунке C.5 в диапазоне от t = 0 до t = 5 с (считывания от 1 до 2500).
Таблица C.1
Местоположения и типы комплексов QRS
C.3.3.3 Вычисление остаточных данных
C.3.3.3.1 Совместите ("синхронизируйте") опорную точку fcM данных эталонного цикла 0 с каждой из опорных точек fc1, fc2, ..., fc(k) комплексов необработанных данных цикла типа 0. См. рисунок C.6.
![]() Рисунок C.6 - Пример эталонного цикла
и указателей его разметки
В таблице C.2 представлены непосредственные места размещения указателей и формула для их вычисления по данным записи SCP-ECG.
Таблица C.2
Непосредственные места размещения указателей
C.3.3.3.2 Вычитание каждого считывания данных эталонного цикла из необработанных данных в соответствующем месте цикла fc(k).
Примечание - Длина сегмента данных, который необходимо вычесть, не обязательно является полной длиной LM эталонного цикла. К тому же в необработанных данных она может изменяться от цикла к циклу. Чтобы это учесть, в разделе 4 протокола SCP-ECG (см. 5.7.4) байты с 3 по 6 зарезервированы для хранения указателей начала вычитания данных эталонного цикла. Байты с 11 по 14 зарезервированы для хранения конца вычитания данных эталонного цикла для каждого цикла соответственно.
C.3.3.3.3 Из практических соображений удобнее всего постоянно вычитать данные "полного" эталонного цикла от PBM до TEM (данный сегмент имеет длину LM). Указатели на начало и конец вычитания данных эталонного цикла для цикла k вычисляются по следующим формулам:
SB(k) = fc(k) - PM,
SE(k) = fc(k) - TM.
Эти указатели должны использоваться во время процедуры вычитания и должны храниться в поле данных QRS, описанном в разделе 4.
Примечание - Вычитание эталонного цикла ("нормального" типа 0) не является эффективным, если цикл необработанных данных имеет другой тип, например, является экстрасистолой (тип 1). Тем не менее сегменты данных QRS экстрасистол также должны быть защищены от низкочастотной фильтрации и прореживания считываний.
C.3.3.3.4 Данные, остающиеся после вычитания эталонного цикла во всех подходящих местах комплекса fc(k), называются остаточной записью.
C.3.4 Низкочастотная фильтрация
C.3.4.1 Низкочастотная фильтрация остаточной записи эффективно повышает коэффициент сжатия. Так как высокочастотные компоненты, как правило, можно встретить только в QRS, все сегменты данных за исключением тех, где были размещены комплексы QRS, могут быть отфильтрованы и подвергнуты прореживанию считываний.
QB(k) = ORSonset(k) - eB(k),
QE(k) = ORSoffset(k) + eE(k).
Если глобальные измерения эталонного цикла (см. 5.10.4) представлены для типа цикла k, то указатели на QRSonset и QRSoffset вычисляются следующим образом:
ORSonset(k) = fc(k) - bM,
ORSonset(k) = fc(k) - eM,
где bM обозначает интервал от опорной точки fcM до начала QRS эталонного цикла, а eM - это интервал от fcM до завершения QRS. Значения bM и eM могут быть вычислены по местоположению опорной точки эталонного цикла (хранится в байтах 3, 4 раздела 4, см. 5.7.3) и указателей на начало и завершение QRS (хранятся в байтах 5, 6, 7, 8 раздела 7, см. 5.10.4).
Значения eB(k) и eE(k) в уравнениях являются поправками к сегменту защищенных данных, предотвращающими проблемы, связанные с прореживанием/восстановлением считываний. Практическим решением является определение таких границ QB и QE, чтобы интервал прореживания считываний между циклом k - 1 и циклом k[= QB(k) - QE(k - 1) - 1] являлся бы кратным интервалу считываний остаточной записи.
Таким образом, QB(k) может быть сокращен на значение eB(k) (от 0 до коэффициента снижения частоты - 1), чтобы учесть потребность в сохранении кратности предшествующего незащищенного интервала коэффициенту снижения частоты. Более того, указатель QE(k) последнего комплекса может быть увеличен на значение eE(k) (от 0 до коэффициента снижения частоты - 1), чтобы учесть необходимость в сохранении кратности последнего незащищенного интервала коэффициенту снижения частоты. Опорные точки eB(k) или eE(k) могут дополнительно быть уменьшены или увеличены на значения, кратные коэффициенту снижения частоты, чтобы обеспечить "запас надежности" от возможных ошибок в местах начала и завершения QRS.
C.3.4.3 Простой нерекурсивный фильтр, работающий по принципу "скользящего среднего", дает приемлемые результаты низкочастотной фильтрации остаточной записи. Длина фильтра L составляет 9 считываний.
Для нечетной длины фильтра L фильтруемые значения вычисляются следующим образом:
F(m, a) = X(m, a);
![]() ![]() F(m, a + 3) = ...;
![]() X(m, b - 3) = ...;
![]() ![]() F(m, b) = X(m, b).
Примечание - Методы округления определены в C.3.2.2 и C.3.2.3. Константы округления 1, 2, ..., (L - 1)/2 в следующих уравнениях фильтра должны быть отрицательными, если фильтруемые значения отрицательны.
После вычитания эталонного цикла типа 0 могут потребоваться дополнительные отступы в остаточных данных на границах зон вычитания SB(k) и SE(k). Эти отступы не должны фильтроваться, чтобы их можно было воспроизвести в восстановленных остаточных данных.
Существует три интервала фильтрации, a и b для каждого комплекса k и один дополнительный от конца комплекса K до конца потока данных.
1) От конца вычитания эталонного цикла типа 0 из предшествующего комплекса (k - 1) до начала вычитания из текущего комплекса k.
a = SE(k - 1) + 1, SE(0) = 0,
b = SB(k) - 1.
2) От начала вычитания эталонного цикла типа 0 из текущего комплекса k до начала QRS текущего комплекса k:
a = SB(k),
b = SB(k - 1).
3) От начала QRS текущего комплекса k до конца вычитания эталонного цикла типа 0 из текущего комплекса k.
a = QE(k) + 1,
b = SE(k).
4) Интервал фильтрации для остающихся считываний до конца данных:
a = SE(K)+ 1,
b = N,
где m - номер отведения;
n - номер считывания;
K - число комплексов QRS;
N - номер последнего считывания;
k - номер комплекса QRS;
C.3.5 Прореживание считываний
К "медленно изменяющимся" данным наряду с низкочастотной фильтрацией может быть применено прореживание считываний. Для остаточной записи протокол SCP-ECG определяет минимальную частоту считываний - 125 считываний/с, что равносильно интервалу между считываниями 8 мс.
Прореживание считываний разрешается только за пределами защищенных сегментов данных QRS. В SCP прореживание считываний именуется "бимодальным сжатием".
Для прореживания считываний применяется усредняющий алгоритм. Он отличается от прореживания считываний с последующим усреднением четырех считываний.
Для реализации SCP-ECG производители могут выбрать метод прореживания считываний, а именно усреднение или пропуск считываний. Следует отметить, что лучшие результаты получаются, если алгоритмы сжатия и распаковки согласованы между собой.
Хотя настоящий стандарт не требует никакого конкретного метода прореживания и восстановления, на границах зон вычитания в процессе восстановления могут возникнуть переходные эффекты, если не были выполнены определенные требования. Поэтому SCP-ECG рекомендует использовать следующие границы вычитания эталонного цикла типа 0:
- поместить SB(k) в начале интервала прореженных считываний (например, считывания 1, 5, 9, 13, 17, 21, ...);
- поместить SE(k) в конце интервала прореженных считываний (например, считывания 4, 8, 12, 16, 20, ...).
Если эти условия выполнены, то нет необходимости знать, какой алгоритм прореживания используется во избежание переходных состояний на границах зон вычитания во время восстановления.
Интервал считываний 8 мс является максимальным разрешенным для остаточной записи в SCP-ECG. Поэтому наименьшая эффективная частота считываний для остаточной записи составляет 125 считываний/с. Признак бимодального сжатия указан в 5.9.3, байт 6.
Чтобы избежать проблем восстановления при прореживании считываний, практическим решением является задание таких границ QB и QE, при которых интервал прореживания считываний между циклом k - 1 и циклом k(= QB(k) - QE(k - 1) - 1) является кратным интервалу между считываниями в остаточной записи.
В обновлении указателей начала и конца защищенной области после прореживания считываний нет необходимости, так как они находятся внутри остаточной записи, а не в остаточной записи, прореженной считываниями (см. спецификацию раздела 4 в 5.7).
Не существует никакого универсального алгоритма для восстановления прореженных считываний. Выбор способа выполнения восстановления (интерполяция или повторение считываний) оставлен на усмотрение производителей. Однако среднеквадратичная ошибка и абсолютные отклонения восстановления между исходной и распакованной ЭКГ должны быть проверяемыми на тестовом наборе SCP-ECG. Этот тестовый набор описан в C.5.
Пример фильтрации и прореживания остаточной записи, получаемой из данных ЭКГ, представлены в таблице C.3.
Таблица C.3
Пример фильтрации и прореживания
Примечание - QB2 не равно QRSonset2, так как в этом случае разность для прореживания считываний (= QB2 - QE1 - 1) была бы равна 609 - 361 - 1 = 247 считываний, что не кратно коэффициенту прореживания считываний, равному 4. Подходящим для QB2 является считывание 606, так как 606 - 361 - 1 = 244 считывания, что кратно этому коэффициенту.
C.3.6 Вычисление и хранение разностных данных
C.3.6.1 Общие положения
Чтобы воспользоваться взаимосвязью считываний, вместо "исходных" значений эталонного цикла и данных остаточной записи можно хранить и кодировать последовательные разности первого или второго порядка соответствующих данных. Как правило, длина слова (в битах) исходных считываний гораздо больше, чем длина последовательных разностей первого или второго порядка.
Протокол SCP-ECG оставляет за пользователем выбор того, хранить/передавать разности первого или второго порядка (или даже исходные данные) или нет. Это должно быть указано в байте 5 заголовка раздела 5 (для данных эталонного цикла) и раздела 6 (для остаточных данных) соответственно.
C.3.6.2 Вычисление последовательных разностей первого и второго порядков
Предполагается, что из остаточной записи, полученной из записи необработанных данных с N считывания, в прореженной записи остаются Q считываний.
Эти считывания обозначаются следующим образом для отведения m:
Z(m, 1), Z(m, 2), ..., Z(m, q), ..., Z(m, Q).
Затем вычисляются разности следующим образом:
Разности первого порядка:
; q = 1, ..., (Q - 1).Примечание -
, где Разности второго порядка:
; q = 1, ..., (Q - 2).Примечание -
, .Подобным же образом разности первого и/или второго порядка для эталонного цикла могут быть вычислены для данных эталонного цикла Yt(m, p).
C.3.6.3 Восстановление данных из разностей
Восстановление данных из разностей требует хранения/передачи одного (первого) исходного значения, поскольку
; q = 1, ..., (Q - 1),где Z(m, 1) необходимо для восстановления Z(m, 2):
.Примечание -
.Восстановление данных из разностей второго порядка требует хранения и передачи двух исходных значений:
; q = 1, ..., (Q - 2),где Z(m, 1) и Z(m, 2) являются обязательными значениями для восстановления Z(m, 3),
.Примечание -
, .Соответствующие исходные значения должны храниться в начале кодированных данных (см. 5.8.3).
C.3.7 Кодирование записи SCP-ECG методом Хаффмана
C.3.7.1 Общие положения
Кодирование методом Хаффмана обеспечивает минимальную избыточность кодирования данных с неодинаковой вероятностью возникновения. Применяется схема кодирования, в которой наиболее часто возникающим значениям назначается самая короткая длина битового кода. А наиболее редко возникающим данным присваивается наибольшая длина битового кода. Кодирование Хаффмана заменяет данные, представленные словами, на данные, представленные битами.
С помощью таблиц Хаффмана, представленных в протоколе SCP-ECG, можно использовать полное кодирование методом Хаффмана и исходное кодирование. Если распределение длин слов в данных меняется, то можно использовать более одной таблицы Хаффмана, а также переключать разные таблицы во время кодирования в целях более эффективного сжатия.
C.3.7.2 Полное кодирование Хаффмана
При полном кодировании Хаффмана одно слово данных представляется в таблице Хаффмана "полным кодом", который хранится как "базовый код" или "префикс". Префикс должен использоваться для кодирования, а для декодирования должно использоваться базовое значение, взятое из таблицы. Длина полного кода в битах после кодирования равна длине префикса.
Пример - В таблице Хаффмана N 1 (см. таблицу C.4) код значения "0" равен 0b в префиксе. Вся длина кода составляет 1 бит, что равносильно длине префикса. Для значения "1" префикс равен 100b, а длина битового кода равна 3, т.е. длине префикса.
C.3.7.3 Исходное кодирование
Если значение не содержится в таблице Хаффмана, то оно должно иметь исходный код. Базовое значение в этом случае не содержит никакого приемлемого или полезного значения (должно быть "0"). Но таблица содержит информацию о числе битов "остатка" в потоке битов, который следует за префиксом. Из этого остатка должно вычисляться восстанавливаемое слово данных. Число этих битов равно разности между числом битов всего случая и префикса.
Пример - Битовый поток: 1110000000101b.
1) Сравнение битового потока с таблицей Хаффмана N 1 (см. таблицу C.4) указывает на структуру 6 для декодирования. Поэтому используются первые 4 бита, которые служат переключателем на таблицу Хаффмана N 2.
2) Для декодирования должен использоваться метод исходного кодирования, так как в таблице N 2 число битов префикса 1 (префикс 0b) меньше длины всего кода (9 битов - 1 бит = 8 битов > 0).
3) Длина остатка равна разности между числом битов всего кода и префикса. В данном случае это 8 битов (00000101b), используемых для восстановления слова данных.
4) Чтобы завершить слово данных (2 байта), недостающие биты должны быть заполнены значением старшего значащего бита остатка.
Пример - Восстановленное слово данных: 0000000000000101b = 5h.
C.3.7.4 Таблицы Хаффмана, используемые в SCP-ECG
C.3.7.4.1 Общие положения
Таблицы C.4 и C.5 используются в примерах кодирования данных ЭКГ.
C.3.7.4.2 Структура таблиц Хаффмана
Таблица Хаффмана N 1 содержит семь структур. Из них пять структур используются для полного кодирования Хаффмана, одна - для 8-битового исходного кодирования и одна - для смены таблицы на таблицу N 2. Значения не более 2 кодируются с помощью полного кодирования Хаффмана. Значения более 2 кодируются с помощью исходного кодирования. В этом случае первые 4 бита из 12 битов полного кода являются префиксом (1111b). Следующие 8 битов являются остатком.
Если третий байт (переключатель таблиц) структуры (в данном случае номер 6) равен 0, то это указывает, что текущую таблицу Хаффмана необходимо сменить на таблицу, номер которой указан в базовом значении. В данном случае префикс смены таблиц равен 1110b, а номер новой таблицы равен 2.
Таблица C.4
Таблица Хаффмана N 2 содержит пять структур. Из них три структуры используются для полного кодирования Хаффмана, одна - для 8-битового исходного кодирования и одна - для смены таблицы на таблицу N 1. Значения не более 1 кодируются с помощью полного кодирования Хаффмана. Значения более 1 кодируются с помощью исходного кодирования. Первый бит 9-битового кода является префиксом.
Если третье поле (переключатель таблиц) структуры (в данном случае номер 5) равно 0, то это означает, что фактическую таблицу Хаффмана необходимо сменить на таблицу, номер которой указан в базовом значении. В данном случае префикс для смены таблиц равен 111b, а номер новой таблицы равен 1.
Таблица C.5
C.3.7.4.3 Таблицы Хаффмана без переключателя таблиц
Рассмотрим пример следующей последовательности байт-ориентированных данных:
1, 2, -1, 0, 3, 0, 4, 1, 0, -2,
0, 15, -1, 0, 13, 0, 1, -2, -1, 1.
Эти данные должны кодироваться с помощью таблицы Хаффмана N 1. Для каждого значения данных выбирается соответствующий битовый код из таблицы Хаффмана и соединяется с битовым потоком. Если значение не обнаружено в таблице, то оно должно кодироваться с помощью исходного кодирования, как описано выше.
Таблица C.6
Полученный поток битов:
100110010101111000000110111100000100100011010111100001111101011110000110101001101101100
C.3.7.4.4 Таблицы Хаффмана с переключением таблиц
Для более эффективного сжатия можно кодировать данные с помощью нескольких таблиц Хаффмана. Например, разумным является кодирование эталонного цикла и остаточной записи с помощью разных таблиц или переключаться на другую таблицу в процессе кодирования, если вероятность появления значений данных со временем изменилась.
Пусть, например, извлечена следующая последовательность байт-ориентированных значений данных (включая объявления переключения):
1, 2, -1, 0, 3, 0, 4, 1, 0, -2, переключение на таблицу 2,
0, 15, -1, 0, 13, переключение на таблицу 1, 0, 1, -2, -1, 1.
Кодирование начинается с таблицы Хаффмана N 1. После 10-го значения для кодирования используется таблица Хаффмана N 2, а после кодирования 16-го значения снова используется таблица N 1.
Соответствие байт-ориентированных значений данных и битовых кодов Хаффмана см. в таблице C.7.
Таблица C.7
Результирующий поток битов:
100110010101111000000110111100000100100011011110
10000000111111010000000110111101001101101100
C.3.7.5 Определение и хранение таблиц Хаффмана в разделе 2
В целях объяснения того, как таблицы Хаффмана (для базового кода/префикса см. примечание 1) должны храниться в разделе 2, в таблицах C.6 и C.7 представлен общий вид их расположения в стиле, использованном в основном документе протокола SCP-ECG. См. таблицу C.8.
Таблица C.8
Пример хранения двух таблиц Хаффмана в разделе 2
Примечания
1 Первый бит базового кода/префикса в коде представлен младшим значащим битом 4-байтовой области. Это означает, что код хранится в 4-байтовом поле с обратным порядком битов. Таким образом, код 100b (десятичное 4) хранится как 1b (десятичное 1), код 1100b (десятичное 12) как 0011b (десятичное 3) и т.д. Для понимания необходимо сравнить два последних столбца в таблице Хаффмана по умолчанию (таблица C.9 - см. C.3.7.6).
2 Числа, выделенные курсивом, указывают длину соответствующих полей в байтах.
Теоретически для разных наборов данных ЭКГ могут требоваться разные кодовые таблицы Хаффмана. Однако в результате широких экспериментов с различными наборами данных было выявлено, что следующая таблица Хаффмана может использоваться практически для всех типов данных ЭКГ без особых потерь в эффективности сжатия.
Если, с другой стороны, производитель хочет применять разные таблицы к разным ЭКГ (наборам данных ЭКГ), то он может определить свои таблицы в разделе 2 протокола SCP-ECG.
Таблица C.9 является таблицей Хаффмана по умолчанию в SCP-ECG, упомянутой в 5.5.4, байты 1, 2. Она использовалась для кодирования данных, приведенных в примерах 1 и 2 соответственно в C.4.1 и C.4.2.
Таблица C.9
Чтобы идентифицировать переключение на другую таблицу Хаффмана, следует использовать ПТ (см. в основном документе пункт 5.6.4, байт 7). Этот переключатель должен быть вставлен в поток данных, кодируемый по Хаффману. Он идентифицирует смену таблицы Хаффмана. Новая таблица Хаффмана, которая должна использоваться для декодирования данных, идентифицирована в соответствующей структуре (см. 5.6.4, байты 8, 9 в основном документе).
C.3.8 Декодирование сжатых ЭКГ данных
C.3.8.1 Общие положения
Для логически согласованного описания сжатия и распаковки используется одинаковая нотация для переменных и индексов. Имена переменных и индексов, используемых в алгоритме распаковки, дополнены знаком штриха (').
Пример - Сжатие: X(m, n), Z(m, q),
и т.д.; распаковка: X'(m, n), Z'(m, q), и т.д.C.3.8.2 Декодирование с помощью таблиц Хаффмана
Декодирование данных, закодированных методом Хаффмана, осуществляется следующим образом.
Выбирается первый бит из битового потока каждого кодированного отведения и сравнивается с первой таблицей Хаффмана (или с таблицей по умолчанию). Если найден совпадающий префикс, то соответствующее значение должно быть введено в поле декодированных данных. При использовании полного кодирования Хаффмана оно является соответствующим базовым значением, а при использовании исходного кодирования - значением данных, восстановленным из остатка. Длина остатка равна разнице длины всего кода и префикса. Если не обнаружено никакого совпадающего кода префикса, то выбираются первые два бита и сравниваются, если необходимо, с первыми тремя и т.д. Если код найден и значение данных введено в поле, то сравнение продолжается со следующим битом.
Если найден префикс структуры переключателя таблиц Хаффмана, то из текущей таблицы необходимо выйти. На это указывает значение переключателя, равное 0. Номер новой таблицы считывается из базового значения данной структуры. После переключения на новую таблицу декодирование может продолжаться в соответствии с данным описанием.
C.3.8.3 Восстановление из разностей первого и второго порядков
C.3.8.3.1 Общие положения
Протокол SCP-ECG оставляют на усмотрение пользователя, будет ли он хранить/передавать разности первого или второго порядка либо даже исходные данные. Тип данных указан в байте 5 заголовка раздела 5 (для эталонного цикла) и заголовка раздела 6 (для остаточной записи). Предполагается, что остаточная запись, являющаяся результатом декодирования Хаффмана, содержит всего Q значений.
C.3.8.3.2 Разности первого порядка
Обозначим считывания, декодированные по Хаффману для отведения m, следующим образом:
, , ..., , ..., ."Исходные" данные Z'(m, n) могут быть вычислены по следующей формуле:
; q = 2 по Q.Восстановление "исходных" данных из разностей первого порядка требует хранения/передачи одного (первого) исходного значения данных:
, ,где
является необходимым "исходным" значением.C.3.8.3.3 Разности второго порядка
Обозначим считывания, декодированные по Хаффману для отведения m, следующим образом:
, , ..., , ..., ."Исходные" данные Z'(m, n) могут быть вычислены по следующей формуле:
; q = 3 по Q.Восстановление "исходных" данных из разностей второго порядка требует хранения и передачи двух исходных значений:
, , ,где
и являются необходимыми "исходными" значениями.Таким же образом данные эталонного цикла Y'(m, p) могут быть вычислены из разностей первого и/или второго порядка эталонного цикла.
Соответствующие исходные значения должны храниться в начале кодированных данных (см. 5.8.3).
C.3.8.4 Восстановление прореженных считываний
К "медленно меняющимся" данным может применяться прореживание считываний (до максимального интервала между считываниями 8 мс, что равносильно частоте 125 считываний/с). Использование прореживания считываний называется бимодальным сжатием, его признаком служит байт 6, указанный в 5.9.3.
Не существует алгоритма для точного восстановления прореженных считываний. Лучшие результаты прореживания считываний получаются, если алгоритмы сжатия и распаковки согласованы между собой.
Следующий усредняющий алгоритм сжатия дает удовлетворительные результаты:
первое среднее значение:
![]() второе среднее значение:
![]() ...
и для распаковки:
![]() где 1 <= i <= 4.
Величина Z'av(m, 1) является левосторонним средним значением [равна X'(m, 1)], а величина Z'av(m, 2) является правосторонним средним значением четырех повторно вычисленных значений интервала. Это восстановление целиком покрывает незащищенную область, a, b (b - a равно числу непрореженных считываний). Первые два восстановленных считывания данной области полагаются равными первому среднему значению, а два последних считывания полагаются равными последнему среднему значению.
Интервал a, b:
X'(m, a) = Z'av(m, a),
X'(m, a + 1) = Zav(m, a).
Интерполяция в интервалах (b - a - 1)/4:
X'(m, b - 1) = Z'av(m, (b - a)/4),
X'(m, b) = Z'av(m, (b - a)/4).
Пример - В таблице C.10 приведен пример прореживания и восстановления 100 считываний. Для более простого представления шаги вычисления разностей и кодирования Хаффмана были опущены. Значения Zav вычисляются так, как описано выше.
Таблица C.10
Пример прореживания и восстановления 100 считываний
C.3.8.5 Низкочастотная фильтрация восстановленной остаточной записи
Низкочастотная фильтрация остаточной записи, выполненная за пределами защищенных областей после восстановления прореженных считываний, "сглаживает" шум, возникший во время восстановления. Простой нерекурсивный фильтр "скользящего среднего" дает удовлетворительную низкочастотную фильтрацию остаточной записи.
Длина фильтра составляет три считывания. Значения фильтра вычисляются следующим образом:
F'(m, a) - X'(m, a),
![]() ![]() ...
![]() ...
![]() F'(m, b) = X'(m, b).
от k = 0 до K,
a = QE(k) + 1, QE(0) = 0,
b = QB(k + 1) - 1, QB(K + 1) = N + 1,
a + 1 <= n <= b - 1.
Примечание - Методы округления определены в C.3.2.2 и C.3.2.3. Константа округления "1" в предыдущем уравнении должна быть сделана отрицательной, если фильтруемые значения отрицательны.
C.3.8.6 Умножение необработанных данных на AVM
C.3.8.6.1 Общие положения
Этот шаг означает калибровку. С этой целью данные умножаются на AVM для получения необработанных данных, а в случае высокой степени сжатия на него также умножаются остаточная запись и эталонный цикл, имеющие одинаковое разрешение.
C.3.8.6.2 Необработанные данные
C.3.8.6.3 Данные эталонного цикла
C.3.8.7 Добавление эталонного цикла к остаточной записи
Протокол SCP-ECG спроектирован для обработки данных, которые можно сжимать и кодировать различными методами:
a) только сокращение избыточности;
b) "высокое сжатие SCP-ECG".
В случае "высокого" сжатия необходимо снова добавить эталонный цикл к остаточной записи во всех тех местах, где он был вычтен во время сжатия. Поэтому эталонный цикл должен быть синхронизирован с остаточной записью в опорных точках fc(k) и fcM, хранящихся в записи SCP-ECG. Указатели на защищенные зоны QRS вычисляются из хранящихся указателей. Область для добавления эталонного цикла в цикл k вычисляется по указателям SB(k) (начало добавления) и SE(k) (конец добавления).
Примечания
1 В разделе 4 протокола SCP-ECG (см. 5.7.4) байты с 3 по 6 зарезервированы для хранения указателей на начало добавления данных эталонного цикла [SB(k)]. Байты с 7 по 10 зарезервированы для хранения опорной точки цикла k [fc(k)], а байты с 11 по 14 зарезервированы для хранения конца добавления данных эталонного цикла к циклу k [SE(k)] для всех циклов. Добавление данных эталонного цикла в остаточную запись (по принципу считывание за считыванием) в соответствующем месте цикла fc(k) позволит восстановить исходные данные считываний.
2 Если QRS имеет ненулевой тип (в байтах 1, 2, см. 5.7.4), то эталонный цикл 0 не был вычтен из цикла (см. сноску 3 5.7.4).
C.3.8.8 Параметры распаковки записи SCP-ECG по умолчанию
В алгоритме распаковки записи SCP-ECG по умолчанию используются следующие параметры:
- использование вычитания эталонного цикла (раздел 3, байт 2, бит 0 = 1);
- AVM для данных эталонного цикла = 5 мкВ (раздел 5, байты 1 + 2 = 5000);
- интервал между считываниями в данных эталонного цикла = 2 мс (раздел 5, байты 3 + 4 = 2000);
- для представления данных эталонного цикла используются разности второго порядка (раздел 5, байт 5 = 2);
- AVM для остаточной записи = 20 мкВ (раздел 6, байты 1 + 2 = 20 000);
- интервал между считываниями в остаточной записи за пределами защищенных зон (QRS) = 8 мс (раздел 6, байты 3 + 4 = 8000);
- для представления данных остаточной записи используются разности второго порядка (раздел 6, байт 5 = 2);
- интерполяция считываний осуществляется для интервала между считываниями 2 мс (алгоритм см. C.3.8.9);
- низкочастотная фильтрация, осуществляемая после интерполяции считываний, имеет длину фильтра три считывания (алгоритм см. C.3.8.10);
- для декодирования данных эталонного цикла и остаточной записи используется таблица Хаффмана (см. таблицу C.9).
В сжатых данных только защищенные области имеют исходный интервал между считываниями. Чтобы восстановить исходный интервал между считываниями, области сигнала, находящиеся между защищенными областями, а также части сигнала перед первой и после последней защищенной области должны быть развернуты с помощью алгоритма интерполяции.
Удовлетворительные результаты интерполяции считываний в интервале a, b можно получить с помощью следующего алгоритма:
Z'(m, a') - прореженные считывания;
X'(m, a) - считывания, прошедшие интерполяцию;
m - номер отведения;
X'(m, a) = Z'(m, a');
X'(m, a + 1) = Z'(m, a');
;![]() ![]() ![]() ![]() ...
![]() ...
...
...
X'(m, b - 1) = Z'(m, b');
X'(m, b) = Z'(m, b').
Следующие вычисления выполняются для всех сегментов данных K + 1, находящихся за пределами защищенных областей:
от k = 0 до K
a = QE(k) + 1QE(0) = 0,
b = QB(k + 1) - 1QB(K + 1) = N + 1.
Низкочастотная фильтрация восстановленной остаточной записи выполняется для сглаживания результатов огрубления. Она может выполняться только за пределами защищенных областей, так как внутри QRS ошибка восстановления строго ограничена 15 мкВ. Особое внимание следует уделять границам областей вычитания. После вычитания данных эталонного цикла к этим границам могли применяться смещения, которые должны быть учтены после добавления данных эталонного цикла. Поэтому они не могут быть устранены при фильтрации. Для низкочастотной фильтрации восстановленной остаточной записи достаточно эффективен описанный ниже нерекурсивный фильтр "скользящего среднего".
Длина фильтра L должна составлять три считывания. Значения фильтра для нечетной длины фильтра L вычисляются следующим образом:
F'(m, a) = X'(m, a),
![]() ...
![]() ...
![]() F'(m, b) = X'(m, b).
Существует три интервала фильтрации: a и b для каждого комплекса k и один дополнительный от конца комплекса K до конца потока данных.
1) От конца вычитания эталонного цикла типа 0 из предшествующего комплекса (k - 1) до начала вычитания из текущего комплекса k.
a = SE(k - 1) + 1, SE(0) = 0,
b = SB(k) - 1.
2) От начала вычитания эталонного цикла типа 0 из текущего комплекса k до начала QRS текущего комплекса k.
a = SB(k),
b = SB(k - 1).
3) От начала QRS текущего комплекса k до конца вычитания эталонного цикла типа 0 из текущего комплекса k.
a = QE(k) + 1,
b = SE(k).
4) Интервал фильтрации для остающихся считываний до конца данных:
a = SE(K) + 1,
b = N,
где m - номер отведения;
n - номер считывания;
K - число комплексов QRS;
N - номер последнего считывания;
k - номер комплекса QRS;
Примечание - Методы округления определены в C.3.2.2 и C.3.2.3. Константы округления 1, 2, ..., (L - 1)/2 в предыдущих уравнениях должны браться отрицательными, если фильтруемые значения отрицательны.
В настоящем примере показаны разные данные, полученные при высоком сжатии SCP-ECG для первых 28 считываний записи ЭКГ.
RAW - необработанные данные 1 мкВ/LSB, интервал между считываниями 2 мс (500 считываний/с);
TRU - огрубленные необработанные данные 1 мкВ/LSB -> 5 мкВ/LSB;
RES - остаточная запись после вычитаний эталонного цикла;
FIL - нерекурсивный фильтр "скользящего среднего" по девяти считываниям;
DEC - прореживание до интервала между считываниями 8 мс с усреднением (125 считываний/с);
2D - разности второго порядка, первые два значения исходные;
HUF - кодирование Хаффмана (код по умолчанию, таблица C.9).
Таблица C.11
Данные, получаемые при высоком сжатии записи SCP-ECG
56 байтов = 448 битов -> сокращены до 71 бита.
Первые 28 считываний необработанных данных отведения сжимаются в битовый поток
11111111100000111011111111100001001001111011111111110111101111011111100...,
имеющий следующее шестнадцатеричное представление:
FF 83 BF E1 27 BF F7 BD...
В этом примере показаны разные данные, получаемые при полном сокращении избыточности по методу SCP-ECG для первых 28 считываний записи ЭКГ.
RAW - необработанные данные 1 мкВ/LSB, интервал между считываниями 2 мс (500 считываний/с);
TRU - огрубленные необработанные данные 1 мкВ/LSB -> 5 мкВ/LSB;
RES - остаточная запись после вычитаний эталонного цикла;
2D - разности второго порядка, первые два значения исходные;
HUF - кодирование Хаффмана (код по умолчанию, таблица C.9).
Таблица C.12
Полное сокращение избыточности по методу SCP-ECG
56 байтов = 448 битов -> сокращены до 113 битов.
Первые 28 считываний необработанных данных отведения сжимаются в битовый поток
11111111100000110111111111100000111001101111010101010011011001
010101100110110110010110111001011001001011100101100...,
имеющий следующее шестнадцатеричное представление:
FF 83 7F E0 E6 F5 53 65 59 B6 5B 96 4B 96...
В таблице C.13 представлены ЭКГ, выбранные для тестирования ошибок сжатия и распаковки SCP-ECG. Данные предоставлены в виде 10-секундных цифровых записей с частотой 500 считываний/с и уровнем дискретизации 5 мкВ/LSB. В ЭТОТ набор включены ЭКГ с синусовым ритмом, фибрилляцией предсердий, трепетанием предсердий, полиформными и моноформными желудочковыми экстрасистолами, а также с суправентрикулярной экстрасистолой. Включены два случая со значительными нарушениями внутрижелудочковой проводимости. Для верификации абсолютной калибровки в набор включена искусственная ЭКГ с низким уровнем шума и частотой сердечных сокращений 120 ударов в минуту с синусовым ритмом.
Эти данные взяты из эталонной базы данных CSE, содержащей многие отведения и предназначенной для тестирования распознавания зубцов, а также из диагностической эталонной базы CSE. Некоторые данные были слегка "сглажены", чтобы избавиться от определенного уровня шума. Все эти записи ЭКГ подверглись сжатию и распаковке в соответствии со стандартами, предложенными рабочей группой SCP-ECG. Среднеквадратичные ошибки (RMS) и абсолютные максимальные ошибки, выявленные после восстановления, приведены в таблице C.13.
![]() Рисунок C.7 - ЭКГ для данных примера (отведения с V1 по V6)
Таблица C.13
в соответствии со стандартом SCP-ECG
(справочное)
И ЗАПРОСОВ ДЛЯ ОБМЕНА ДАННЫМИ ЭЛЕКТРОКАРДИОГРАММЫ
D.1 Общие положения
Часть стандарта SCP-ECG, посвященная обмену сообщениями, описывает тип информации, который можно запрашивать и передавать на прикладном уровне между устройствами, а также формат заголовков сообщений. Настоящий стандарт определяет структуры сообщений данных и указывает последовательности обменов сообщениями, необходимые для передачи данных и запросов, требуемых протоколом, вместе с форматом каждого типа сообщений. Описано также использование информационных сообщений. Содержание данных описано ранее в разделе 5. Знание содержания данных протокола необходимо для понимания части, описывающей обмен сообщениями.
D.2.1 Общие положения
Длина каждого блока сообщения составляет 256 байтов. Первый байт каждого блока сообщения является символом ASCII, идентифицирующим тип сообщения. В настоящий момент определены следующие типы (минимальный набор): I, R, S, A и D. Двоичные данные по умолчанию и зарезервированные поля должны заполняться нулями. Строки текстовых символов должны завершаться байтом NULL. Разработчик должен следить за тем, чтобы все сообщения имели длину 256 байтов или меньше. Для выполнения этого требования может понадобиться усечение полей данных свободного текста (например, раздел 1, тег 14). Сообщения с длиной больше 256 байтов будут восприниматься как неправильно форматированные.
Таблица D.1
Обмен идентификационными данными (тип сообщения - "I")
D.2.3 Запрос (тип сообщения - "R")
Таблица D.2
Запрос (тип сообщения - "R")
Таблица D.3
Запрос списка ЭКГ (подзапрос типа "E" или "L")
D.2.3.2 Правила поиска для подзапросов типа "I" или "P"
Таблица D.4
Запрос списка пациентов (подзапрос типа "I" или "P")
Таблица D.5
Запрос тестирования (подзапрос типа "R" или "S")
Данные, отправленный в ответ на запросы типов "L" и "P" (для каждого отчета или пациента, соответствующего критериям поиска), состоят из последовательности разделов заголовков SCP-ECG, состоящей только из разделов 0 и 1.
D.2.3.4 Правила поиска для типов подзапросов "L" и "P"
1) При запросе списка ЭКГ (тип подзапроса "L") или списка пациентов (подзапрос типа "P") применимы следующие правила поиска:
i) любое поле может быть указано или не указано;
ii) если поле не указано, то предполагается, что оно "безразлично" и не используется как часть критериев поиска;
iii) если поле указано без символов подстановки [см. перечисление iv)], то необходимо точное совпадение;
iv) поля идентификатора пациента и его именования могут включать в себя "символы подстановки", они определяются следующим образом:
? - совпадает ровно с одним символом в данном месте,
* - совпадает с нулем или несколькими символами в данном месте,
символы "*" и "?" могут интерпретироваться буквально, если им предшествует символ обратной косой черты "\";
v) любой поиск является нечувствительным к регистру (символы в верхнем и нижнем регистрах эквивалентны).
Примеры
1 Идентификатор пациента = 123, фамилия и имя не указаны, совпадает со всеми фамилиями и именами пациентов, имеющих идентификатор = 123.
2 Фамилия пациента - "M*CFARL*" соответствует "MCFARLEY", "MacFarlane", "Macfarlane", "Mcfarlane" и т.д.
3 ID пациента - "\*FAR?" соответствует "*FAR1", "*FAR2", но не "*FAR99".
2) Эти правила поиска применяются только к запросам списков и не применимы к запросам ЭКГ (тип подзапроса "R"), в которых критерии поиска являются точными для обязательных параметров (организация, отделение, идентификатор пациента, дата и время снятия).
3) Тег типа 255 длиной 0 применяется для маркировки конца тегированных данных в сообщении "запроса списка".
Формат сообщения статуса показан в таблице D.6.
Таблица D.6
Сообщение статуса (тип сообщения - "S")
Порядковый номер запроса в этом сообщении совпадает с порядковым номером того сообщения "запроса", чей статус возвращается.
Ложные сообщения "STATUS OK" (нормальный статус), полученные до ожидаемого сообщения типа "D" (запрос выполнен), будут игнорироваться.
D.2.5 Информационное сообщение (тип сообщения - "A")
Формат информационного сообщения показан в таблице D.7.
Таблица D.7
Информационное сообщение (тип сообщения - "A")
Руководство по использованию информационных сообщений приведено в D.5.
Сообщение о выполнении ("DONE") означает завершение выполнения команды. Сообщение "выполнено" имеет следующий формат.
Таблица D.8
Информация к сообщению о выполнении:
- каждое устройство управляет флагом "ожидание завершения" (PT - pending termination);
- посылая сообщение типа "D" и устанавливая свой флаг РТ, ведущее устройство изменяет свой статус на ведомое;
- приняв сообщение типа "D", ведомое устройство изменяет свой статус на ведущее и устанавливает свой флаг РТ;
- если у ведомого устройства флаг РТ установлен, то при приеме сообщения типа "D" (без предшествующего сообщения типа "R"), оно должно завершить сеанс и прекратить связь;
- если у ведомого устройства флаг РТ не установлен, то оно может отправить сообщение типа "D", не меняя свой статус на ведущее устройство. При этом состояния флагов РТ ведущего и ведомого устройства не изменяются;
- если у ведущего устройства флаг РТ не установлен, то при приеме сообщения типа "D" оно устанавливает свой флаг РТ;
- если у ведущего устройства флаг РТ установлен, то при приеме сообщения типа "D" оно прекращает связь.
b) Коды производителя и обозначение модели устройства записи ЭКГ определены в полях демографических данных пациента и полях данных снятия ЭКГ раздела 1 (см. 5.4.3.1 и 5.4.5).
c) Код поддержки языка определен в 5.4.5, раздел 1, тег 14, байт 17.
1 - (LSB) запасной;
2 - запасной;
4 - запасной;
8 - запасной;
16 - печать ECG;
32 - интерпретация ECG;
64 - хранение ECG;
128 (MSB) - снятие ECG.
"E" - запрос на отправку списка ЭКГ, снятых для заданного пациента;
"I" - запрос на отправку списка пациентов с заданными именем и фамилией;
"L" - запрос на получение списка ЭКГ, снятых для заданного пациента;
"P" - запрос на получение списка пациента с заданными именем и фамилией;
"R" - запрос на получение ЭКГ;
"S" - запрос на отправку ЭКГ;
"X" - переход на запрос, специфичный для поставщика.
f) Данное поле используется только для запросов типа "R" и "X". Для этих типов запроса получатель извлекает из этого поля дополнительный код запроса.
В запросах типа "R" с помощью этого поля можно запросить несколько тестов. При этом нет необходимости использовать несколько запросов или обязательно знать дату и время проведения теста. Это поле является битовым массивом. Его значения определены следующим образом:
0 (ни один бит не установлен) - маска запроса не нужна: передать все ЭКГ;
1 (LSB) - запрошенная ЭКГ будет иметь дату и время;
2 - самая последняя ЭКГ;
4 - первая предыдущая ЭКГ;
8 - вторая предыдущая ЭКГ;
16 - базовая ЭКГ, если имеется, иначе самая ранняя ЭКГ;
32 - все с определенного срока, будет дополнен датой и временем.
В запросах типа "X" коды подзапросов являются расширениями, специфичными для поставщика, и здесь не определены.
g) Если система-получатель требует пароль, данное поле содержит пароль в кодировке ASCII, состоящий из девяти символов и заканчивающийся байтом NULL.
h) Даты имеют следующий формат (см. 5.4.5, раздел 1, теги 5 и 25):
Байты с 1 по 2 - двоичное: год.
Байт 3 - двоичное: месяц (с 01 по 12).
Байт 4 - двоичное: день месяца (с 01 по 31).
i) Время имеет следующий формат (см. 5.4.5, раздел 1, тег 26):
Байт 1 - двоичное: часы (с 00 по 23).
Байт 2 - двоичное: минуты (с 00 по 59).
Байт 3 - двоичное: секунды (с 00 по 59).
"G" - ОК (можно продолжать); код ошибки не используется. Приемник должен возобновить работу и отправить следующее сообщение.
"E" - Не ОК, ошибка:
- если ошибка идентификации, то вызов сразу завершается;
- в случае ошибки в запросе или в данных ЭКГ получатель может отправить другой запрос или сообщение "выполнено".
k) Для флага статуса "E" (статус ошибки) данное поле содержит следующий двоичный код, указывающий причину ошибки:
0 - неспецифичная ошибка;
1 - тип последнего сообщения не распознан;
2 - последнее сообщение недействительно;
3 - недействительный код местоположения; отправленное местоположение (т.е. номер организации или отдела) не определено;
4 - недействительный пароль;
5 - запрос на обработку не распознан: обрабатывающее устройство не понимает запрос;
6 - запрос на обработку не поддерживается: обрабатывающее устройство не поддерживает запрос;
7 - запрос на обработку не поддерживается: обрабатывающему устройству не хватает памяти;
10 - идентификация пациента недействительна;
11 - фамилия и имя пациента недействительны;
12 - демографические данные пациента недействительны; данные, не являющиеся идентификацией, фамилией или именем, имеют недействительный тип или диапазон;
13 - демографические данные пациента являются противоречивыми; данные не согласуются с уже хранящейся информацией о пациенте.
Следующие коды относятся к данным сигнала и к их поддержке принимающим устройством:
20 - неправильная частота считываний;
21 - неправильная комбинация отведений;
22 - ошибочная длительность отведения;
23 - неправильное сжатие данных;
24 - другая ошибка данных ЭКГ;
30 - измерения недействительны; одно или несколько измерений недействительны;
31 - недействительный диагноз;
40 - устройство вывода не готово;
41 - устройство хранения не готово;
42 - ошибка базы данных;
43 - другая системная ошибка;
44 - ошибка нехватки памяти;
50 - ЭКГ для данного местоположения отсутствуют;
60 - нет данных, соответствующих запросу.
Коды в диапазоне с 128 по 255 зарезервированы для кодов ошибок, специфичных для производителя.
l) Области, определенные в блоках данных сообщения как "ЗАПАСНЫЕ", доступны реализациям, специфичным для производителя.
D.2.8 Минимальные функциональные возможности
Чтобы соответствовать спецификациям данного раздела, система, состоящая из устройства картирования и сервера, должна быть способна:
1) обмениваться идентифицирующими сообщениями;
2) отвечать на запрос типа "R" с дополнительным кодом 0 в соответствии с D.2.7, перечисление f);
3) передавать "все" ЭКГ в соответствии с D.2.7, перечисления e) или f).
D.3 Диаграммы перехода состояний
На рисунке D.1 описан процесс обмена идентифицирующими сообщениями между устройством картирования и сервером, обеспечивающего установление сеанса взаимодействия по стандарту SCP-ECG. Необходимо отметить, что сеанс не переходит в состояние "соединения", пока не произошел успешный обмен идентифицирующими сообщениями (см. D.2.2). Описание функционирования после установления сеанса см. в D.3.2.
![]() На диаграмме состояний, приведенной на рисунке D.2, показаны операции системы обмена сообщениями запросов, выполняемые после обмена идентифицирующими сообщениями в соответствии с D.3.1. В процессе работы устройство системы существует в одном из двух состояний: ведущее или ведомое. Ведущему устройству разрешено отправлять команды. Ведомое устройство может только отвечать на команды.
Сообщения и ответы, специфичные для производителя, не обязаны следовать этой диаграмме.
![]() системы обмена сообщениями запросов
D.4 Примеры последовательности сообщений
D.4.1 Общие положения
В следующих примерах под "Данными ЭКГ" подразумевается файл данных, отформатированный в соответствии с SCP-ECG, а "Идентификационное", "Запрос", "Статус", "Выполнено" и "Информационное" означают сообщения SCP-ECG, определенные в D.2.
Нормальная последовательность сообщений для отправки инициатором ЭКГ ответчику имеет следующий вид:
Нормальная последовательность сообщений для запроса списка пациентов, соответствующих маске запроса, имеет следующий вид:
Последовательность сообщений запроса у ответчика списка отчетов по ЭКГ, снятых для заданного пациента, имеет следующий вид:
Последовательность сообщений запроса у ответчика конкретного отчета или отчетов по ЭКГ, снятых для заданного пациента, имеет следующий вид:
Примечания
1 Если принятые данные непригодны, то ответчик возвращает код ошибки (см. D.2.4). Затем инициатор переходит к g), чтобы повторно передать те же данные, другие (новые) данные или отправить статус "Выполнено".
2 С помощью этого механизма может быть передан "пакет" ЭКГ или "набор списков пациентов". См. также пример 2 в D.5.
В любой точке, приведенной выше последовательности, где может быть отправлено сообщение управления (идентификация, запрос, статус или "Выполнено"), могут быть дополнительно отправлены одно или несколько информационных сообщений. Информационное сообщение не оказывает никакого влияния на последовательности обработки. Оно позволяет предоставить дополнительную информацию оператору-человеку.
Передача информационного сообщения не приводит к смене ведущего и ведомого. По получении информационного сообщения вместо очередного сообщения управления получатель обрабатывает информационное сообщение (обычно отображая его оператору) и продолжает находиться в том же состоянии, ожидая сообщения управления, которое он рассчитывал получить до этого.
Ниже рассмотрены примеры использования информационных сообщений.
Пример 1
(справочное)
НИЗКОГО УРОВНЯ ДЛЯ ВЗАИМОДЕЙСТВИЯ УСТРОЙСТВА
КАРТИРОВАНИЯ ЭЛЕКТРОКАРДИОГРАММЫ С СЕРВЕРОМ
E.1 Общие положения
Низкоуровневый транспортный протокол, предназначенный для обмена ЭКГ между цифровыми устройствами картирования ЭКГ и компьютеризированными системами управления (хранения) ЭКГ, состоит из двух функциональных уровней:
- канальный уровень;
- физический уровень.
Коммуникации между двумя системами управления ЭКГ и коммуникации между этими системами и другими серверами не входят в рамки данной спецификации.
E.2 Функциональный канальный и физический уровни
В разделе E.3 приведено краткое описание минимальных требований для локального и дистанционного соединения и передачи данных, связанных с ЭКГ, позволяющих использовать малозатратные, высокоскоростные асинхронные модемы или простые локальные каналы RS-232-C. Выполнение этих требований должно гарантировать, что устройства, использующие данный стандартный протокол, способны взаимодействовать.
В разделе E.5 описаны методы, обеспечивающие синхронизацию двух взаимодействующих устройств и отсутствие искажений данных в процессе передачи. Настоящий стандарт описывает состояния, необходимые для обработки исключительных ситуаций.
При обмене данными между устройствами, в особенности сжатыми двоичными данными, которые особенно подвержены искажению из-за ошибок передачи, важно использовать некоторые устройства или программное обеспечение, позволяющие обеспечивать целостность данных и канала передачи данных. Такие устройства или программное обеспечение доступны во многих форматах, например, низкоуровневые сетевые протоколы, модемы с коррекцией ошибок и т.д. В данном приложении описан низкоуровневый протокол, который можно использовать в отсутствие какого-либо другого доступного или пригодного адекватного протокола.
Для облегчения понимания данного уровня в настоящее приложение включены диаграммы перехода состояний, алгоритм вычисления контрольной суммы каждого пакета данных и формат каждого определяемого блока данных. В целом этот канальный уровень является улучшением протокола XMODEM.
E.3.1 Общее описание
В данном разделе дано описание физического уровня стандартного протокола передачи ЭКГ. Приведены минимальные требования как для "локального", так и для "дистанционного" соединения. Локальные соединения определены как прямые соединения "точка-точка". Дистанционными являются те соединения, которые задействуют публичные коммутируемые телефонные сети или их эквивалент.
Отдельные производители могут принять решение о расширении приведенных здесь требований или об использовании других физических уровней. Описанные в данном приложении стандарты не усложняют разработку будущих систем и не приводят к деградации их производительности. Они предлагают общий интерфейс, обеспечивающий достаточные показатели эффективности при минимальной стоимости реализации и предоставляющий общий метод передачи ЭКГ между поставщиками.
E.3.2 Локальные соединения
Локальное соединение представляет собой канал RS-232-C, способный обеспечить следующие параметры:
9600 бод;
8 битов данных;
1 стоповый бит;
без бита четности.
E.4 Дистанционное соединение
Минимальным требованием для дистанционного соединения является модем V.22bis, официально разрешенный в стране использования. Стандарт V.22bis реализуется полнодуплексным асинхронным модемом 2400 бод. Функция обнаружения и коррекции ошибок по протоколу MNP level 5 не требуется, так как уровень обработки ошибок спроектирован для ее выполнения. Другие требования те же, что и для локальных соединений.
E.5.1 Общее описание
E.5.1.1 В данном разделе определен уровень коррекции ошибок и линии арбитража стандартного протокола передачи ЭКГ. Целью данного раздела является определение минимального стандарта, обеспечивающего коммуникации устройств картирования и систем разных производителей. Он не предназначен для определения или предложения метода коммуникаций между системами. Данный уровень протокола называется канальным уровнем.
Описанный здесь канальный уровень является модифицированной (расширенной) версией протокола XMODEM. Он легко реализуется с помощью "стандартных" асинхронных коммуникационных устройств и адекватен требованиям к производительности при передаче ЭКГ.
Эти требования отдельно рассмотрены в E.5.1.2 - E.5.1.6.
E.5.1.2 Таймауты были сокращены с 10 до 2,5 с (t1) и 3,5 с (t2), тем самым снижая время выполнения, когда производительность машины ниже оптимальной.
E.5.1.3 Временная задержка текста была введена, чтобы машина могла поддерживать соединение в отсутствие данных для отправки. Это обеспечивает поддержку ситуаций, в которых передающее устройство ожидает передачу блока данных, но данные не готовы из-за задержек обработки. При обычном протоколе XMODEM получатель, ожидающий данные, несколько раз прервется по таймауту, а затем отключит соединение.
E.5.1.4 Была добавлена способность передающего устройства запрашивать повторную передачу сообщения подтверждения самого последнего блока данных, чтобы учесть ситуацию, в которой управляющие символы ACK или NAK получателя были искажены. В стандартном протоколе XMODEM передающая станция просто повторно передает свой блок данных, что является потенциально долгим процессом.
E.5.1.6 Протокол позволяет "реверс канала", чтобы данные можно было передавать в обоих направлениях во время одного сеанса.
Ниже для идентификации участвующей станции два устройства именуются "передатчиком" и "приемником". Устройство, передающее данные или передавшее данные последним, является ведущим. Эти роли могут меняться во время сеанса коммуникации (см. также рисунок E.2).
Во время пребывания в каждом описанном ниже состоянии, за исключением TRANSMIT WAKE-UP и RECEIVE WAKE-UP, обе станции могут получать или передавать код завершения EOT. Возможность передачи и получения EOT в любой момент времени является необходимой для обработки аварийных завершений. Этот же механизм может использоваться для нормального завершения, поскольку на канальном уровне между этими двумя ситуациями нет различий.
E.5.2.1 Графическое представление передатчика см. на рисунках E.3 - E.5.
E.5.2.2 Передатчик имеет три состояния: TRANSMIT WAKE-UP (пробуждение для передачи), NO DATA WAIT (нет данных, ожидание) и WAIT FOR ACKNOWELDGE (ожидание подтверждения).
E.5.2.2.1 Состояние TRANSMIT WAKE-UP является начальным для вызывающего устройства. Предполагается, что отвечающее устройство отправит управляющий код ASCII "ENQ". По получении ENQ, если данные готовы к отправке, вызывающее устройство отправляет данные и переходит в состояние WAIT FOR ACK. Если по получении ENQ у этого устройства нет данных, готовых к передаче, то его текущим состоянием становится NO DATA WAIT. Если в течение одной минуты не получено ни одного управляющего кода ENQ, то процесс прекращается.
E.5.2.2.2 Состояние NO DATA WAIT. В данном состоянии передатчик ожидает данные для отправки. Это случается, когда станция передачи ждет блок данных для его передачи, но этот блок еще не был подготовлен приложением более высокого уровня. Данное состояние имеет таймаут, длящийся только 2,5 с.
Если таймер сработал через 2,5 с, то передатчик проверяет наличие данных. Если они существуют, то данные отправляются и текущим состоянием становится WAIT FOR ACK. Если данных нет, то отправляется временная задержка текста, чтобы предотвратить отключение принимающей станции по таймауту, а управление передатчиком сохраняется в состоянии NO DATA WAIT. Если данные становятся доступными до истечения 2,5 с, то они могут быть отправлены в соответствии с представленным выше описанием.
E.5.2.2.3 Состояние WAIT FOR ACK. В этом состоянии передатчик ожидает ответа от приемника на последний отправленный блок данных. Надлежащими ответами являются управляющие коды ACK или NAK.
E.5.2.2.3.1 Если получен управляющий код ACK и передатчик получил от прикладного уровня указание выполнить реверс канала, то он передает управляющий код ENQ и управление передатчиком переходит в состояние получения WAIT FOR TURNAROUND.
E.5.2.2.3.2 Если получен управляющий код ACK и передатчик не ожидает реверса, то он проверяет наличие данных для отправки. Если данные имеются, то они отправляются и передатчик остается в состоянии WAIT FOR ACK. Если доступных данных нет, то текущим состоянием становится NO DATA WAIT.
E.5.2.2.3.3 Если получен управляющий код NAK, то происходит повторная передача последнего блока данных. Состояние WAIT FOR ACK сохраняется. Если было последовательно получено 10 кодов NAK, то будет отправлен код завершения EOT с номером ошибки 006, и соединение прекращается.
E.5.2.2.3.4 Если ответ не пришел в течение 2,5 с, то происходит повторная передача последнего пакета. После десяти передач того же пакета без ответа отправляется код завершения EOT с номером ошибки 001, и соединение прекращается.
E.5.3.1 Графическое представление приемника см. на рисунках E.6 - E.9.
E.5.3.2 Приемник имеет четыре состояния: RECEIVE WAKE-UP (пробуждение для приема), WAIT FOR TURNAROUND (ожидание реверса канала), WAIT ON DATA (ожидание данных) и BAD DATA (плохие данные).
E.5.3.2.1 RECEIVE WAKE-UP. Это начальное состояние приемника. При пробуждении устройство передает управляющий код ENQ и переходит в состояние WAIT FOR TURNAROUND.
E.5.3.2.2 WAIT FOR TURNAROUND. В этом состоянии приемник ждет от передатчика передачи первого блока данных. Допустимы два варианта входной информации: блок данных или управляющий код TTD.
E.5.3.2.2.1 Если данные получены, то проводится проверка их правильности, основанная на номере блока и контрольной сумме. Если данные хорошие, то отправляется управляющий код ACK и текущим состоянием становится WAIT ON DATA. Если данные плохие, то отправляется NAK и приемник переходит в состояние BAD DATA.
E.5.3.2.2.2 Если принят управляющий код TTD, то не выполняется никаких действий (кроме перезапуска часов таймаута).
E.5.3.2.2.3 Если за 3,5 с не принято никаких данных, то осуществляется повторная передача управляющего кода ENQ. Если после отправки десяти кодов ENQ ответа нет, то соединение прерывается и отправляется управляющий код EOT с номером ошибки 002.
E.5.3.2.3 WAIT ON DATA. Это нормальное состояние приема. Приемник ждет получения блока данных от передатчика. Допустимы четыре вида входной информации: данные, управляющие коды TTD, SYN и ENQ. Недействительная входная информация отбрасывается.
E.5.3.2.3.1 Если получены данные, то проводится проверка их правильности, основанная на номере блока и контрольной сумме. Если данные хорошие, то отправляется управляющий код ACK, а машина остается в состоянии WAIT ON DATA. Если данные плохие, то отправляется управляющий код NAK и текущим состоянием становится BAD DATA.
E.5.3.2.3.2 Если только что полученный пакет совпадает с предыдущим, то отправляется управляющий код ACK, а полученный пакет отбрасывается. После приема десяти последовательных копий одного и того же пакета отправляется управляющий код EOT с номером ошибки 005 и соединение прекращается.
E.5.3.2.3.3 Если получен управляющий код TTD, то не предпринимается никаких действий (кроме перезапуска часов таймаута).
E.5.3.2.3.4 Если получен управляющий код SYN, то осуществляется повторная передача управляющего кода ACK и состояние WAIT ON DATA остается действительным.
E.5.3.2.3.5 Если получен управляющий код ENQ, то приемник готов стать передатчиком. Проверяется наличие данных для отправки. Если данных нет, то приемник становится передатчиком в состоянии NO DATA WAIT. Если данные имеются, то они отправляются и управление передается состоянию передачи WAIT FOR ACK.
E.5.3.2.3.6 Если в течение 3,5 с никакие данные не получены, то передается управляющий код NAK. Это гарантирует, что передатчик перешлет последний блок данных, если он был потерян. Код NAK отправляется вместо кода ACK, поскольку передача ACK может привести к потере данных, если передатчик отправил блок данных, который приемник не смог принять. Приемник переходит в состояние BAD DATA.
E.5.3.2.4 BAD DATA. После отправки управляющего кода NAK приемник ожидает в состоянии BAD DATA. Допустимой входной информацией являются данные, а также управляющие коды SYN и ENQ.
E.5.3.2.4.1 Если получены хорошие данные, то приемник отправляет управляющий код ACK и переходит в состояние WAIT ON DATA. Если данные плохие, то приемник отправляет управляющий код NAK. После отправки десяти кодов NAK подряд и получения еще одного блока плохих данных отправляется управляющий код EOT с номером ошибки 003 и соединение прекращается.
E.5.3.2.4.2 Если получен управляющий код SYN, то последний управляющий код NAK передается повторно. Состояние BAD DATA сохраняется.
E.5.3.2.4.3 Если за 3,5 с не приняты никакие данные, то передается управляющий код NAK. Если десять NACK были отправлены в связи с отсутствием входной информации, а не из-за плохих данных, то соединение прекращается и отправляется управляющий код EOT с кодом ошибки 004.
E.5.3.2.4.4 Если получен управляющий код ENQ, то приемник скоро станет передатчиком. Проверяется наличие данных для отправки. Если данных нет, то приемник становится передатчиком в состоянии NO DATA WAIT. Если данные имеются, то они отправляются и управление передается состоянию передачи WAIT FOR ACK.
E.5.4 Формат блоков данных
E.5.4.1 Управляющие коды должны передаваться следующим образом:
где три символа (CHAR) являются цифрами в кодировке ASCII, означающими коды завершения, т.е. коды ошибок с 001 по 006, упомянутые в E.5.2 и E.5.3. При нормальном завершении должен отправляться код ошибки 000.
E.5.4.2 Блоки данных имеют следующий формат:
Примечание - Для сообщений и блоков данных используется один и тот же счетчик номеров. Он должен прирастать для каждого экземпляра блока любого типа.
Алгоритм вычисления контрольной суммы CRC основан на полиноме CRC-CCITT (X16 + X12 + X5 + 1). Контрольная сумма CRC является 16-битовым числом, которому должно быть присвоено двоичное значение из всех единиц (FFFF hex) перед началом вычисления для каждого блока данных. CRC вычисляется для всего блока данных вплоть до самого значения CRC, как показано на рисунке E.1.
Область CRC
?
?<??????????????????????????????????????????????????>?
? ?
??????????????????????????????????????????????????????????????????????
? Тип ? Номер блока?255 - (номер? Данные ? CRCHI ? CRCLO ?
? сообщения ? ? блока) ? ? ? ?
??????????????????????????????????????????????????????????????????????
1 1 1 256 1 1
Рисунок E.1 - Обнаружение ошибок в соответствии с CRC-CCITT
Алгоритм CRC-CCITI описан ниже. Учтите, что все операции осуществляются над байтами.
A - новый байт;
B - временный байт;
CRCHI - старший байт (старший значащий) 16-битовой CRC;
CRCLO - младший байт (младший значащий) 16-битовой CRC.
START:
FOR A = FIRST_BYTE TO LAST_BYTE IN BLOCK DO:
A = A XOR CRCHI
CRCHI = A
SHIFT A RIGHT FOUR TIMES (ЗАПОЛНЕНИЕ НУЛЯМИ)
A = A XOR CRCHI {I J K L M N O P}
CRCHI = CRCLO {перестановка CRCHI, CRCLO}
CRCLO = A
ROTATE A LEFT 4 TIMES {M N O P I J K L}
B = A {сохранить во временном байте}
ROTATE A LEFT ONCE {N O P I J K L M}
A = A AND $1F {0 0 0 I J L L M}
CRCHI =A XOR CRCHI
A = B AND $F0 {M N O P 0 0 0 0}
CRCHI = A XOR CRCHI {завершить вычисление CRCHI}
ROTATE B LEFT ONCE {N O P 0 0 0 0 M}
B = B AND $ E0 {N O P 0 0 0 0 0}
CRCLO = B XOR CRCLO {завершить вычисление CRCLO}
DOEND;
FINISH
Последняя проверка CRC осуществляется с помощью добавления (конкатенации) CRCHI и CRCLO к концу потока данных. Контрольная сумма CRC, вычисленная для дополненного потока данных, должна быть нулевой, если данные были получены правильно.
E.5.6 Диаграммы переходов состояний (STD - State transition diagram)
E.5.6.1 Схема потоков данных (не STD)
![]() E.5.6.2 Диаграмма переходов состояний передатчика
![]() E.5.6.3 Диаграмма переходов для состояния "Отсутствие данных, Ожидание"
![]() Рисунок E.4 - Диаграмма переходов для состояния
"Отсутствие данных, Ожидание"
E.5.6.4 Диаграмма переходов для состояния "Ожидание ACK"
![]() "Ожидание ACK"
E.5.6.5 Диаграмма переходов состояний приемника
![]() E.5.6.6 Диаграмма переходов для состояния "Ожидание реверса канала"
![]() Рисунок E.7 - Диаграмма переходов для состояния
"Ожидание реверса канала"
E.5.6.7 Диаграмма переходов для состояния "Ожидание данных"
![]() Рисунок E.8 - Диаграмма переходов для состояния
"Ожидание данных"
E.5.6.8 Диаграмма переходов для состояния "Плохие данные"
![]() "Плохие данные"
E.5.7 Сценарий коммуникаций
Сценарий, в котором электрокардиограф отправляет ЭКГ центральной системе управления ЭКГ
(справочное)
ОПИСАНИЙ ЭЛЕКТРОКАРДИОГРАММЫ
F.1 Общие положения
Универсальные коды интерпретации ЭКГ могут использоваться в дополнение к свободному тексту для обмена интерпретирующими описаниями между различными системами анализа ЭКГ, а также между такими системами и клиническими рабочими станциями и больничными информационными системами.
Общий набор кодов описаний является крайне важным для обмена сообщениями, интерпретирующими ЭКГ, в многоязычной среде. Он также является важным ресурсом для сжатия данных.
Эти коды могут использоваться в том числе для хранения предыдущих расшифровок, важного в силу юридических аспектов. Изменения, внесенные кардиологом в компьютерную интерпретацию, необходимо хранить. Они должны быть доступны врачам общей практики или другим специалистам, а также третьим сторонам.
F.2 Ограничения
Представленная ниже схема кодирования демонстрирует "прагматичный" подход к решению проблемы отображения компьютерных описаний на общепринятый и понятный лексикон. Предлагаются простые, базовые мнемокоды, их модификаторы и союзы, которые можно использовать для создания и отображения как простых, так и достаточно сложных интерпретирующих описаний ЭКГ.
Необходимо ясно понимать, что не предполагается, что компьютерные программы будут пытаться интерпретировать ЭКГ, используя все описания, перечисленные в данном приложении. Это выходит за рамки существующей технологии и даже желаний кардиологов. На самом деле, если используется только ЭКГ, то некоторые из описаний, перечисленных в данном приложении, трудно сделать объективными. При разработке настоящего стандарта не было желания давать оценку полезности или ограничений стандартной электрокардиографии. Тем не менее в данном приложении предпринята попытка дать достоверное представление о терминологии электрокардиографии и описаний ЭКГ, используемой в современной практике.
F.3 Создание кода и общие синтаксические правила
F.3.1 Общий принцип
Используются мнемокоды, которые широко используются в литературе и которые, вероятно, могут запомнить врачи, выполняющие расшифровку ЭКГ. Эти мнемокоды могут быть преобразованы в числовые коды для "внутреннего" использования в программе. Нельзя ожидать, что специалист по электрокардиографии, который лишь иногда имеет дело с компьютерными интерпретациями ЭКГ, запомнит шифры кодов или порой достаточно сложные мнемокоды, используемые в программах различных производителей.
Используя гибкую, но уникальную структуру кодов, можно добиться того, чтобы компьютер был способен получить хотя бы общее представление об изменениях, выполняемых читателями, не заставляя их оперировать числами. С другой стороны, довольно сложные конструкции, встречающиеся в свободном тексте описаний, интерпретируемых компьютером, могут быть с помощью акронимов и простых синтаксических правил преобразованы в универсально понимаемые коды описаний.
F.3.2 Базовая композиция кода
Универсальный код интерпретации SCP-ECG состоит из одного или нескольких полей. Принципиальных ограничений числа различных полей нет, разве что синтаксический анализ и формулировка интерпретирующего описания могут оказаться слишком долгими.
Первое поле (5 байтов) определяет базовую диагностическую интерпретацию или описательное утверждение.
Второе поле (1 или 2 байта) в основном используется для указания предполагаемой вероятности того, что описание правильное, или для определения степени вероятности.
Например,
Второе поле может также использоваться для других целей.
Третье и другие поля (по 2 байта) используются для других модификаторов.
F.3.3 Модификаторы
Могут использоваться следующие модификаторы:
1) стадия развития инфаркта или ишемических изменений ST-T:
2) локализация ST-T и других патологических изменений:
3) степень тяжести патологического изменения, например, гипертрофии, нарушения проводимости или депрессии сегмента ST:
MA - значительная (major), MO - умеренная (moderate) и MI - легкая (minor).
Может использоваться другая схема кодирования, например, с S1 по S5, где степень S1 используется для указания легкой тяжести, а степень S5 представляет собой очень значительную тяжесть;
4) развивающийся характер или период действия некоторых патологических изменений:
5) патофизиологический характер изменений ST-T:
LV - совместим с напряжением левого желудочка (compatible with left ventricular strain);
MD - совместим с ишемическим поражением миокарда (compatible with myocardial ischemic damage);
PE - совместим с перикардитом (compatible with pericarditis);
EL - совместим с электролитными аномалиями (compatible with electrolyte abnormalities);
6) нормальное или аномальное состояние:
NO - в пределах нормы (within normal limits);
NX - может быть вариантом нормы (may be normal variant);
BO - пограничное (borderline);
AB - аномальное (abnormal);
BN - пограничное нормальное (borderline normal);
BA - пограничное аномальное (borderline abnormal);
SI - синусовый (sinus);
AT - предсердный (atrial);
SV - суправентрикулярный (supraventricular);
ND - узловой (nodal);
VE - вентрикулярный (ventricular);
8) прочие термины:
IC - неполный (incomplete);
CP - полный (complete);
TY - типичный (typical);
YT - атипичный (atypical).
Примечание - AT означает "предсердный", см. перечисление 7) выше.
F.3.4 Разделители
1) Разные поля в описаниях кода разделяются с помощью нижнего подчеркивания, например, LVH_PR.
2) Основной диагностический код ставится первым. Модификатор достоверности или вероятности кода ставится вторым (как это показано в перечислении 1) (LVH_PR). Если программа или читатель не уверены в модификаторе, например касающемся стадии инфаркта или ишемических изменений ST-T, то к этому модификатору следует добавить модификатор достоверности, как это показано в следующих примерах:
AMI_PR_AC - вероятный острый передний инфаркт.
AMI_AC_PR - передний инфаркт, вероятно, острый.
AMI_PR_AC_PR - вероятный передний инфаркт, вероятно, острый.
Во втором случае предполагается (определенная) уверенность возникновения инфаркта, но неуверенность в его стадии.
3) Различные коды описаний отделяются друг от друга с помощью точки с запятой. Во время передачи данных перед описаниями идут порядковые номера (см. протокол SCP-ECG). Эти порядковые номера могут использоваться для соединения различных описаний, но для этой цели могут также использоваться термы связи.
F.3.5 Термы связи
Термы связи могут использоваться для связи описаний или для создания составных описаний.
1) Классические булевы операторы могут применяться как союзы, т.е.: AND, OR, NOT, XOR, EOR.
Союз NOT может использоваться для указания на то, что основное описание является истинным "в отсутствие" или "без" следующего описания;
2) Приведенные ниже арифметические операторы и операторы отношений могут использоваться как союзы:
ADD - сложить (+);
SUB - вычесть (-);
MPY - умножить (*);
DIV - разделить (/);
EXP - экспонента;
SQR - квадратный корень;
ABS - абсолютное значение;
MAX - максимальное значение;
MIN - минимальное значение;
EQU - равно;
ILT - меньше чем;
IGT - больше чем;
INE - равно;
IGE - больше или равно;
ILE - меньше или равно;
3) Термы связи для последовательного сравнения, например:
SER - последовательные изменения;
DEC - снижено (по сравнению с предыдущей записью);
INC - повышено (по сравнению с предыдущей записью);
UNC - неизмененное/не изменилось (по сравнению с предыдущей записью);
CHG - измененное/было изменено (по сравнению с предыдущей записью);
DIS - (теперь) исчезло (по сравнению с предыдущей записью);
REP - (теперь) заменено [(описание) было представлено ранее];
IMP - улучшено (по сравнению с);
WRS - ухудшено (по сравнению с);
4) Могут также использоваться другие термы связи, например:
RES - чтобы указать на то, что основное описание "приводит к" к (или "вызывает") следующее описание (results);
SEC - чтобы указать на то, что основное описание является "вторичным" по отношению к последующему описанию (secondary);
ASS - связано с (assotiated);
EXC - исключить, отклонить или учесть также следующее описание (exclude);
WTH - с (with);
ALT - является альтернативой для (alternating with).
Термы связи могут иметь максимальный размер 3 байта и ставятся между двумя точками с запятой для связи двух отдельных описаний.
Связывание термов связи в рамках составного описания выполняется с помощью нижнего подчеркивания (_).
F.4 Акронимы в интерпретирующих описаниях ЭКГ
F.4.1 Ссылки, используемые при детальной разработке этого предложения
Чтобы детально разработать данное предложение, рассматривались списки акронимов, встречающихся в интерпретирующих описаниях ЭКГ, выдаваемых различными компьютерными программами. Эти списки можно найти в пятом и восьмом Докладах о работе CSE (Canadian Society of Echocardiography - Канадское общество по электрокардиографии), а также в руководствах для врачей от нескольких производителей.
Кроме того, часто используются два отчета по "Стандартизации терминологии и интерпретации" и по "Определениям и классификации сердечной аритмии". Эти отчеты опубликованы в Amer. J. Cardiology (1978, 41, pp. 130 - 145) и в Amer. Heart J. (1978, 95, pp. 796 - 806) соответственно.
F.4.2 Акронимы
F.4.2.1 Нормальное/аномальное состояние
F.4.2.2 Гипертрофия желудочка
F.4.2.3 Инфаркт миокарда
(Локализация инфаркта преимущественно определяется базовым акронимом, но может также определяться с помощью модификатора локализации.)
F.4.2.4 Нарушения проводимости
(Определения см. в J. Amer. Coll. Cardiol., 5, pp. 1261 - 1275, 1985.)
F.4.2.5 Другая морфология QRS или обобщающие описания
F.4.2.6 Описания ритма
(Определения описаний ритма см. в Amer. Heart J., 95, pp. 796 - 806, 1978.)
Описания, связанные с формированием импульса (аномалиями):
Дисфункция синусового узла, предсердные и атриовентрикулярные нарушения проводимости:
Описания, связанные с аномалиями эктопического ритма:
Описания, связанные с (предоминирующей) проводимостью и блокадой:
Типы кардиостимулятора и функция кардиостимулятора:
Международная классификация типов кардиостимуляторов:
Другие описания, связанные с ритмом:
F.4.2.7 Описание осей
F.4.2.8 Описания ST-T
Предлагаются следующие базовые корни:
Для указания локализации изменений ST-T могут использоваться два решения - добавить модификатор локализации либо расширить корень двумя дополнительными символами, указывающими область, что выполняется следующим образом:
F.4.2.9 Описания, относящиеся к предсердиям
F.4.2.10 Описания, связанные с педиатрическим анализом ЭКГ
F.4.2.11 Описания, относящиеся к калибровке ЭКГ
F.4.2.12 Технические проблемы
F.4.3.1 Описание "Вероятный старый передний инфаркт и фибрилляция предсердий" должно кодироваться следующим образом: AMI_OL_PR; AFIB. Описание AFIB не имеет прямой связи с AMI, поэтому союз AND не используется. В действительности имеется два независимых описания, одно - для контура QRS и одно - для сердечного ритма.
F.4.3.2 Описание "Вероятная гипертрофия левого желудочка с изменениями ST-T, совместимыми с напряжением левого желудочка" кодируется следующим образом: LVH_PR_AND_STT_LV. Знаки нижнего подчеркивания до и после союза AND указывают на то, что этот союз используется в одном описании.
F.4.3.3 Если такое же описание написано на двух отдельных строках и их необходимо логически связать, т.е.:
- вероятная гипертрофия левого желудочка,
- изменения ST-T, указывающие на гипертрофию левого желудочка,
то кодирование выполняется следующим образом: LVH_PR;AND;STT_LV.
F.5 Расшифровка результатов измерений
F.5.1 Обозначения зубцов и сегментов
F.5.2 Обозначения отведений
a) Обозначения отведений см. в 5.6 "Определение отведения ЭКГ - раздел 3".
b) Приведенные ниже условные обозначения отведений должны использоваться наиболее часто:
d) Дополнительные сокращения:
Примечание - сокращение INN используется вместо сокращения IN, которое зарезервировано для "inferior" (нижний).
F.5.3 Единицы измерения
F.5.4 Примеры
В большинстве случаев используются достаточно простые единичные или составные интерпретирующие описания ЭКГ, например показанные в F.4.3, но могут создаваться и более сложные описания, подобные показанным ниже. Следует отметить, что эти сокращения и соглашения о создании описаний предназначены обеспечения взаимодействия разнородных систем, а каждый производитель систем может продолжать использование собственных сокращений для внутренних целей.
P_AMP_INN_LEAD_V1_EQU_120_MVOLT
Амплитуда зубца P в отведении V1 составляет 120 милливольт.
Q_DUR_INN_LEAD_D3_EQU_40_MSEC
Длительность зубца Q в отведении D3 составляет 40 миллисекунд.
RATIO_Q_AMP_DIV_R_AMP_INN_D2_IGT_0.5
Отношение Q/R в отведении D2 превышает 0,5.
(S_AMP_INN_V1_ADD_R_AMP_INN_V5)_IGT_3.5_MVOLT
Сумма амплитуды зубца S в отведении V1 и амплитуды зубца R в отведении V5 превышает 3,5 милливольта (т.е. индекс Соколова положительный).
(MAX_R_AMP_ADD_MAX_S_AMP)_INN_V_LEADS_IGT_4.5_MVOLT
Сумма максимальной амплитуды зубца R и максимальной амплитуды зубца S в прекордиальных отведениях превышает 4,5 милливольта.
(справочное)
Необходимыми условиями для понимания читателем данного стандарта коммуникационного протокола компьютерной электрокардиографии являются базовые знания электрокардиографии и компьютерных технологий. Поэтому в данном словаре представлены только те термины, которые выходят за рамки базовых названий и определений, используемых в этих областях знаний.
Кодирование амплитуды
Последний из трех шагов преобразования аналогового сигнала в цифровой. Для экономии памяти последовательность целочисленных значений, создаваемая на шаге квантования, может кодироваться (например, методом Хаффмана, первая разность).
Квантование амплитуды
Второй из трех шагов преобразования сигнала из аналогового в цифровой. Амплитуда каждого считывания округляется до целого кратного фиксированному значению, которое выбирается достаточно "малым" по сравнению с представляемыми деталями исходного сигнала.
Аналого-цифровое преобразование
Процесс приближения, в котором непрерывный сигнал преобразуется в цифровое представление. Степень приближения должна гарантировать сохранность всей полезной информации исходного сигнала.
Фильтр артефактов
Фильтр, удаляющий артефакты из сигнала ЭКГ.
Фильтр изолинии
Фильтр, удаляющий низкочастотные колебания или дрейф из сигнала ЭКГ.
Данные цикла
Данные, относящиеся к морфологическим характеристикам одиночных циклов ЭКГ.
Коэффициент сжатия
Соотношение занимаемой памяти перед сжатием данных и после него.
Сжатие данных
Любой метод, удовлетворяющий общей цели сокращения размера заданного набора данных. Алгоритмы, как правило, используют особенности характеристик сжимаемого сигнала, например, алфавитно-цифровых данных, оцифрованных сигналов или оцифрованных изображений.
Прореживание
Процесс выбора меньшего количества считываний из упорядоченного набора (см. приложение C).
Опорная точка
Точка отсчета в сигнале ЭКГ.
Метод кодирования Хаффмана
Метод кодирования, в котором коды переменной длины используются таким образом, что наиболее часто возникающие данные получают самые короткие коды.
Необратимое сжатие данных
Сжатие данных необратимо, если возможность реконструкции исходного сигнала в тот вид, в котором он был до сжатия, потеряна.
Низкоуровневый транспортный протокол
Детально описанная процедура, используемая в отсутствие других методов обеспечения целостности данных и канала обмена данными во время коммуникаций между двумя цифровыми машинами.
Фильтр высоких частот
Фильтр, удаляющий компоненты входного сигнала, частота которых превышает заданную частоту.
Заграждающий фильтр
Фильтр, который должен удалять компонент входного сигнала, имеющий определенную частоту, как правило, 50 Гц или 60 Гц, т.е. частоту сети переменного тока.
Импульсы кардиостимулятора
Импульсы кардиостимулятора, наложенные на ЭКГ.
Тег
Число, используемое для идентификации определенного элемента данных.
Считывание по таймеру
Первый из трех шагов преобразования сигнала из аналогового в цифровой, т.е. дискретные считывания непрерывного сигнала с определенной частотой.
Преобразование/обратное преобразование
Сигнал может быть представлен в виде взвешенной суммы ортогональных функций. Этот набор весов или коэффициентов известен как отображение сигнала в заданную область. Взвешенная сумма этих сигналов известна как обратное преобразование. Нередко представление, обработка или сжатие сигналов упрощаются, если они осуществляются над их преобразованиями.
Другие специальные термины, используемые в настоящем стандарте, см. в разделе 3.
(справочное)
ДОКУМЕНТОВ НАЦИОНАЛЬНЫМ СТАНДАРТАМ
Таблица ДА.1
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/30/gost_35158.html
На правах рекламы:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||