Стандарт «Уровень 7». Глава 4. Ввод заказов СОДЕРЖАНИЕ

Под ред. Шортлифс Е.Х. и Перролт Л.Е.Стандарт «Уровень 7». Глава 4. Ввод заказовShortlifse E. H., Perreault L. E.Health level seven.Eddison Wesley Publishing Company. January 1995, Edition 2.07500 Old Oak Boulevard, Reading, MAКлючевые словаВзаимодействие компьютерных приложенийПравила кодированияКомпьютеризованная история болезниУправление информацией в здравоохраненииПакетная обработкаТемыСистемы информационного обеспеченияздравоохраненияВерсия 2.2 от 1 декабря 1994 г. Окончательный стандартСОДЕРЖАНИЕ4.1 ВВЕДЕНИЕ1.1 ПРЕДИСЛОВИЕ (ОРГАНИЗАЦИЯ СОДЕРЖАНИЯ ГЛАВЫ)1.2 ТЕРМИНОЛОГИЧЕСКИЙ СЛОВАРЬ4.2 ОПРЕДЕЛЕНИЯ СООБЩЕНИЙ ЗАКАЗА4.2.1 ORM ОБЩЕЕ СООБЩЕНИЕ ЗАКАЗА4.2.1.1 Примечания к использованию сообщения ORM4.2.2 СООБЩЕНИЕ ORR ОБЩЕЕ СООБЩЕНИЕ ОТВЕТА НА ЗАКАЗ (ОТВЕТ НАЛЮБОЕ СООБЩЕНИЕ ORM)4.3 СЕГМЕНТЫ, ОБЩИЕ ДЛЯ ВСЕХ ЗАКАЗОВ4.3.1 СЕГМЕНТ ORC ОБЩИЙ ЗАКАЗПримечания к использованию сегмента ORC4.3.1.0 Определения полей сегмента ORC4.3.1.1 Примечания к кодам управления заказом в сегменте ORC4.3.2 СЕГМЕНТ BLG - ОПЛАТА4.3.2.0 Определения полей сегмента BLG4.4 КОЛИЧЕСТВО/СРОК (TQ) ОПРЕДЕЛЕНИЕ4.4.1 КОМПОНЕНТ КОЛИЧЕСТВА (CQ)4.4.2 КОМПОНЕНТ ИНТЕРВАЛА (CM)4.4.3.1 Субкомпонент явного интервала времени4.4.4 КОМПОНЕНТ ДЛИТЕЛЬНОСТИ4.4.5 КОМПОНЕНТ ДАТЫ И ВРЕМЕНИ НАЧАЛА (TS)4.4.6 КОМПОНЕНТ ДАТЫ И ВРЕМЕНИ КОНЦА (TS)4.4.7 КОМПОНЕНТ ПРИОРИТЕТА (ID)

4.4.8 КОМПОНЕНТ УСЛОВИЯ (ST)4.4.9 КОМПОНЕНТ ТЕКСТА (TX)4.4.10 КОМПОНЕНТ СОЧЕТАНИЯ (ID)4.4.11 ПОРЯДОК ВЫПОЛНЕНИЯ ЗАКАЗОВ (КОМПЛЕКС)4.4.11.1 Субкомпоненты порядка выполнения4.4.11.2 Циклическое повторение групп заказов4.4.11.3 Наследование статуса заказа4.4.12 ПРИМЕРЫ ПРИМЕНЕНИЯ КОЛИЧЕСТВА/СРОКА4.5 ЗАКАЗЫ НА ВЫПОЛНЕНИЕ ИССЛЕДОВАНИЯ ИЛИ ПРОВЕДЕНИЯДИАГНОСТИКИ4.5.1 СЕГМЕНТ OBR - ЗАПРОС НА ВЫПОЛНЕНИЕ ИССЛЕДОВАНИЯ4.5.1.0 Определения полей сегмента OBR4.5.1.1 Порядковый номер запроса на выполнение исследований (SI) 002374.5.1.2 Номер заказа у заказчика (CM) 002164.5.1.3 Номер заказа у исполнителя (CM) 002174.5.1.4 Универсальный идентификатор услуги (CE) 002384.5.1.5 Приоритет (ID) 002394.5.1.6 Дата и время начала (TS) 002404.5.1.7 Дата и время исследования (TS) 002414.5.1.8 Дата и время завершения исследования (TS) 002424.5.1.9 Объем сбора (CQ) 002434.5.1.10 Лицо, собравшее биоматериал (CN) 002444.5.1.11 Код действия с биоматериалом (ID) 002454.5.1.12 Код опасности (CE) 005354.5.1.13 Релевантная клиническая информация (ST) 002474.5.1.14 Дата и время получения биоматериала (TS) 002484.5.1.15 Источник биоматериала(CM) 002494.5.1.16 Лицо, сделавшее заказ(CN) 002264.5.1.17 Телефон для справок по заказу (TN) 002504.5.1.18 Поле заказчика 1 (ST) 002514.5.1.19 Поле заказчика 2 (ST) 002524.5.1.20 Поле исполнителя 1 (ST) 00253Определение: назначение поля задается приложением-исполнителем(диагностическим подразделением) по своему усмотрению.4.5.1.21 Поле исполнителя 2 (ST) 002524.5.1.22 Дата и время формирования отчета о результатах или изменения статусазаказа (TS) 002554.5.1.23 Счет другому лечебному учреждению (CM) 002564.5.1.24 Идентификатор участка диагностического подразделения (ID) 002574.5.1.25 Статус результатов (ID) 002584.5.1.26 Результаты заказа-отца (CM) 00259

4.5.1.27 Количество/срок (TQ) 002214.5.1.28 Лицо, получающее копию результатов (CN) 002604.5.1.29 Номер заказа-отца (CM) 002614.5.1.30 Способ перемещения (ID) 002624.5.1.31 Причина исследования (CE) 002634.5.1.32 Основной интерпретатор результатов (CM) 002644.5.1.33 Помощник интерпретатора результатов (CM) 002654.5.1.34 Лаборант (CM) 002664.5.1.35 Оператор (CM) 002674.5.1.36 Плановые дата и время (TS) 002684.5.2 ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ4.5.2.1 Один заказ заменяется на три других4.6 ЗАКАЗЫ НА ДИЕТПИТАНИЕ4.6.1 СЕГМЕНТ ODS ЗАКАЗ ДИЕТЫ, ДОПОЛНЕНИЙ И ПРЕДПОЧТЕНИЙ4.6.1.0 Определения полей сегмента ODS4.6.2 СЕГМЕНТ ODT ИНСТРУКЦИИ ПО ДОСТАВКЕ ПИЩИ4.6.2.0 Определения полей сегмента ODT4.6.3 Пример сообщений заказа на диетпитание4.6.3.1 Первый заказ:4.6.3.2 Сложный заказ4.6.3.3 Питание через трубку4.6.3.4 Предпочтения пациента4.7 ЗАКАЗЫ НА РАСХОДУЕМЫЕ МАТЕРИАЛЫ4.7.1 СЕГМЕНТ RQD - ДЕТАЛИ ТРЕБОВАНИЯ4.7.1.0 Определения полей сегмента RQD4.7.2 СЕГМЕНТ RQ1 - ДЕТАЛИ ТРЕБОВАНИЯ-14.7.2.0 Определения полей сегмента RQ14.7.3 ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ СЕГМЕНТОВ RQD И RQ14.8 ЗАКАЗЫ НА ЛЕКАРСТВА4.8.1 СООБЩЕНИЕ ORM - РЕЦЕПТ ДЛЯ АПТЕКИ4.8.2 СООБЩЕНИЕ ORR: ОТВЕТ АПТЕКИ:4.8.3 СЕГМЕНТ RXO - РЕЦЕПТ ДЛЯ АПТЕКИ4.8.3.0 Определения полей сегмента RXO4.8.4 СЕГМЕНТ RXR - СПОСОБ ПРИМЕНЕНИЯ4.8.3.0 Определения полей сегмента RXR4.8.4 СЕГМЕНТ RXC - ЗАКАЗ КОМПОНЕНТОВ В АПТЕКЕ4.8.4.0 Определения полей сегмента RXC4.8.5 ГРУППЫ ВНУТРИВЕННЫХ РАСТВОРОВ4.8.6 СООБЩЕНИЕ RDE: ЗАКОДИРОВАННЫЙ АПТЕКОЙ ЗАКАЗ4.8.7 СЕГМЕНТ RXE - ЗАКОДИРОВАННЫЙ АПТЕКОЙ ЗАКАЗ

RGVRQ1RQDRXARXCRXDRXERXGRXORXR–T–TQ–А–Аптечные запросы–Г–Группы внутривенных растворов–З–Заказы на диетпитаниеЗаказы на лекарстваЗаказы на расходуемые материалы–К–Количество/срок–Н–Наследование статуса заказаНомер заказа у заказчикаНомер заказа у исполнителя–О–Ответ на запросR0RRARRDRRERRGR–П–Повторение групп заказовциклическое–С–СегментыBLGOBR

ODSODTORCRQ1RQDRXARXCRXDRXERXGRXORXRСообщениеORM 4; 55ORRRASRDERDSRGVСообщение ORRответ аптекиСообщенияопределения сообщений заказа–Ц–Циклическое повторение групп заказов4.1 ВведениеКомплекс трансакций по вводу заказов предназначен для передачи заказов илиинформации о заказах между приложениями, которые собирают заказы, заполняютзаказы, а также другими приложениями по мере необходимости. Заказом являетсятребование материальных ресурсов или услуг, обычно предназначенных дляконкретного пациента. Эти услуги включают в себя отпуск лекарств из аптеки,проведение клинических осмотров (например для выявления симптомов)медицинскими сестрами, выполнение тестов в лаборатории, приготовлениепитания в пищеблоке, передачу снимков из рентгенологического отделения,постельных принадлежностей из бельевой, получение расходуемых материалов сцентрального склада, требование на получение лекарства (в отличие от отправкилекарства в отделение) и т.д.Большинство заказов связано с конкретным пациентом. Однако в стандарте HL7допускается, чтобы одно отделение давало заказ другому вспомогательномуподразделению безотносительно к пациенту (например для возобновлениязапасов на складе этажа). Заказ может быть инициирован вспомогательнымподразделением (таким образом любое приложение может быть как исполнителемзаказа, так и заказчиком).Ниже личность или структурная единица, которая размещает заказ, будетназываться заказчиком (placer), а личность или структурная единица,

выполняющая заказ - исполнителем заказа (filler, а в терминологии стандартовASTM - producer). В случае, если личность или структурная единица,выполняющая заказ, также и размещает заказ, она будет именоваться заказчикоми исполнителем заказа. Исполнитель может также обратиться с запросом кдругому приложению на присваивание заказу регистрационного номера заказчикаили исполнителя (коды управления заказами см. в примечаниях I и L).В этой главе даются определения трансакций на седьмом уровне, т.е. какабстрактных сообщений. Для формирования конкретных символов, составляющихсообщение в той или иной коммуникационной среде, могут использоватьсяразличные схемы. Если уровень представления не замкнут, то надо применятьправила кодирования стандарта HL7, как это описано в разделе 2.4.8 главы 2.Включенные в эту главу примеры составлены с помощью правил кодированиястандарта HL7.1.1 Предисловие (организация содержания главы)В этой главе описаны сообщения, используемые для составления заказов.Специальные комплексы трансакций определены для следующих заказов: а)выполнение клинических осмотров и диагностики, б) лекарственных назначений, в)диетпитания, г) расходуемых материалов и д) прочих заказов. В соответствии сэтим настоящая глава организована следующим образом: ее первые разделы (4.1и 4.2) описывают общую структуру и обоснования для этих сообщений. В разделе4.3 представлены сегменты сообщений, общие для всех сообщений заказа. Вразделе 4.4 описан тип данных количество/срок TQ (Quantity/Timing). В разделах4.5 - 4.8 описаны сообщения каждой из основных указанных выше категорийзаказов. Каждый из разделов, посвященных конкретной категории заказов,содержит описание предпосылок и введение, определение структуры сообщения иего сегментов (тех, что специфичны для заказов данной категории). Включенытакже специальные обсуждения использования полей, сегментов или сообщенийи, кроме того, примеры.Сегменты представляются в том порядке, в котором они входят в сообщение. Впредметном указателе в конце главы можно найти ссылки на номера страниц,содержащих определения сегментов. Для облегчения чтения список значенийполя, задаваемых стандартом, включен в текст определения поля.Заказы на выполнение лабораторных тестов, проведение прикроватногомониторинга, выполнение диагностических снимков, кардиограмм, определениеантропометрических показателей и других исследований задаются комплексомсообщений, содержащих заказ на выполнение исследования (раздел 4.5). Приразработке комплекса трансакций, связанных с лечебными заказами (раздел 4.8),основное внимание уделялось лекарственной терапии, но тот же комплекстрансакций может быть использован для полного парентерального питания (ППП).Можно надеяться, что этот комплекс окажется вполне подходящим и для другихвидов заказов, например тех, что выполняются медицинскими сестрами при уходеза пациентами. Однако он еще не был достаточно проверен в этих ситуациях и неисключено, что потребуется его доработка. Заказы на диетпитание (раздел 4.6)включают в себя все обычные спецификации диеты, включая быстрые закуски ипитание с посторонней помощью. Заказы на расходуемые материалы (раздел 4.7)имеют ту специфику, что чаще всего они не привязаны к конкретному пациенту(например заказы на пополнение запасов на складе отделения).1.2 Терминологический словарьисполнитель: реагирующее приложение, выполняющее запрос на выполнениеуслуги (заказ) или проведение исследования. Исполнитель может такжеинициировать запросы на услуги (новые заказы), и дополнительные услуги к ужесуществующим заказам, заменять существующие заказы, приостанавливатьвыполнение заказа, прекращать его выполнение, возобновлять его выполнение, атакже отменять существующие заказы.сегмент исследований: сегмент OBX, определенный в главе 7.

заказ: запрос от одного приложения к другому на выполнение услуги. В некоторыхслучаях второе приложение может совпадать с первым; таким образом,приложение может давать заказ самому себе.сегмент деталей заказа: один из нескольких сегментов, которые могут нестиинформацию заказа. Примерами служат сегменты OBR и RXO. В последующихверсиях стандарта при необходимости могут быть определены и другие сегменты,специфические для конкретных подразделений.заказчик: приложение или лицо, инициировавшее запрос на услуги (заказ).пакет заказов: список связанных заказов, относящихся к одному пациенту ипришедших из одного места.4.2 Определения сообщений заказа4.2.1 ORM -общее сообщение заказаФункцией этого сообщения является инициация передачи информации о заказе.Сюда относятся размещение новых заказов, отмена существующих заказов,прекращение исполнения, прерывания и т.д. Сообщения ORM могут бытьинициированы как заказчиком, так и исполнителем, а также третьейзаинтересованной стороной.Событием для этого сообщения является любое изменение заказа. К такимизменениям относятся создание нового заказа, отмена, изменение заказа,специфические и неспецифические для пациента заказы и т.д.ORM Общее сообщение заказа ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 3[PV1] Визит пациента 3]{ORC Общий заказ 4[Сегмент деталей заказа OBR и т.д. 4[{NTE}] Примечания и комментарии (к деталям) 2[{OBX Исследование/результат 7[{NTE}] Примечания и комментарии (к результатам) 2}]][BLG] Сегмент оплаты 4}4.2.1.1 Примечания к использованию сообщения ORMa) Синтаксис абстрактного сообщения может незначительно различаться длянекоторых сегментов заказа. Обращайтесь к соответствующим разделам дляспецифических примеров: для заказа расходуемых материалов (RQ),см. раздел 4.7; для заказа лекарств см. раздел 4.8; для заказа диетпитаниясм. раздел 4.7.b) Сегмент, названный “сегментом деталей заказа” представляет тот или те изсегментов с детальными сведениями, которые соответствуют назначениюсообщения, в данной версии к их числу принадлежат сегменты OBR, RQD,RQ1, RXO, ODS, ODT.c) Сегменты NTE могут быть включены в четыре места сообщения ORM; в

каждом из них содержание сегментов NTE относится к непосредственнопредшествующим им сегментам. В частности, сегменты NTE,непосредственно следующие за сегментом MSH, относятся только к сегментузаголовка, а сегменты NTE, непосредственно следующие за сегментомдеталей заказа, относятся к сегменту ORC и сегменту деталей заказа.d) Сегмент идентификации пациента PID требуется в том и только том случае,если вводятся новые заказы и они связаны с конкретным пациентом. Однакоиногда он может включаться в сообщение в целях местного характера, ноникогда не включается в заказы, не связанные непосредственно спациентами.e) Необязательный сегмент PV1 присутствует в сообщении в основном длятого, чтобы позволить передачу в заказе информации о визите пациента,например о его текущем местонахождении.f) Сегменты деталей заказа не требуются, если передается простоеуправляющее сообщение. Например, в сообщении прерывания выполнениязаказа (значение поля ORC-1-управление заказом = HD) не требуется, чтобыза сегментом ORC следовал сегмент деталей заказа.g) Наличие поля ORC-1-управление заказом критично для выполненияопераций, инициированных как сообщением ORM, так и сообщением ORR.Например, для отмены исполнения заказа надо передать значение CA в полеORC-1-управление заказом соответствующего сегмента. (См. определениеполя ORC-1-управление заказом.)h) Метод запроса информации о состоянии заказа в дисплейном форматеописан в главе 2, а формат ответа в виде группы записей описан в главе 7.I) Каждое сообщение заказа, которое описывает любой тип нового заказа(значение поля ORC-1-управление заказом = NW, CH, RO или SN), требуетпары сегментов ORC/OBR, определяющих каждый заказ дляприложения-получателя. Это правило приложимо к любому другому типузаказа с той лишь разницей, что сегмент OBR заменяется на подходящийсегмент деталей заказа, как это определено ниже. Два смежных сегментаORC могут встретиться, если за запросом на отмену заказа (в которомдостаточно указать только номер заказа) непосредственно следует еще одинзапрос на отмену заказа. Возможны и другие подобные примеры.4.2.2 Сообщение ORR -общее сообщение ответа на заказ (ответна любое сообщение ORM)Назначением этого сообщения является ответ на сообщение ORM. СообщениеORR является прикладным подтверждением для сообщения ORM. Описаниепарадигмы подтверждения см. в главе 2.Сегменты ORC обязательно должен включаться в сообщения ORM и ORR, если вних присутствует сегмент деталей заказа, но в противном случае может иотсутствовать. Например, ответное сообщение ORR может включать в себя толькосегменты MSH и MSA, но если в него включен сегмент RQ1, то ему долженпредшествовать сегмент ORC.Функция (например, отмена заказа, новый заказ) как сообщения ORM, так исообщения ORR, определяется по значению поля ORC-1-управление заказом.(Полный список функций см. в таблице кодов управления заказом.)ORR Общее сообщение подтверждения заказа ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2

{ORC Общий заказ 4[Сегмент деталей заказа ] OBR и т.д 4[{NTE}] Примечания и комментарии (к деталям) 2}]Примечание: сообщения ORR для заказа расходуемых материалов,лекарств и диетпитания имеют немного отличающийся синтаксис;точные детали см. в соответствующих разделах, номера которыхуказаны в разделе 4.2.1.1.4.3 Сегменты, общие для всех заказовСледующие сегменты (ORC и BLG) являются общими для многих сообщенийзаказа.4.3.1 Сегмент ORC -общий заказОбщий сегмент заказа (ORC) используется для передачи данных, общих для всехзаказов (всех запрашиваемых типов услуг). Сегмент ORC является обязательнымкак для сообщения заказа (ORM), так и для сообщения подтверждения (ORR).Если для конкретного типа сегмента заказа требуются детали (например длязаказа лекарств, диетпитания), то сегмент ORC должен предшествовать любомусегменту деталей заказа (например RXO, ODS). В некоторых случаях сегмент ORCможет сводиться к простой строке ORC|OK|||.Если для заказа не требуются детали, то сегмент деталей заказа может бытьопущен. Например, для прерывания выполнения заказа надо передать сегментORC со следующими заполненными полями: ORC-1-управление заказом должноиметь значение HD, поле ORC-2-номер заказа у исполнителя, и полеORC-3-номер заказа у заказчика .Между полями сегмента ORC и полями в сегментах деталей заказа существуютопределенные перекрытия. Они описаны в последующих разделах.П\П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАЗВАНИЕЭЛЕМЕНТА1 2 ID О 0119 00215 Управление заказом2 75 CM У 00216 Номер заказа уисполнителя3 75 CM У 00217 Номер заказа узаказчика4 75 CM 00218 Номер пакетазаказов5 2 ID 0038 00219 Статус заказа6 1 ID 0121 00220 Флаг ответа7 200 TQ 00221 Количество/срок8 200 CM 00222 Заказ-отец9 26 TS 00223 Дата и времятрансакции10 80 CN 00224 Лицо, которое ввелозаказ11 80 CN 00225 Лицо, проверившее

заказ12 80 CN 00226 Лицо, сделавшеезаказ13 80 CM 00227 Адрес лица, котороеввело заказ14 40 TN Д/2 00228 Телефон длясправок по заказу15 26 TS 00229 Дата и время вводазаказа в действие16 200 CE 00230 Причина управлениязаказом17 60 CE 00231 Учреждение,которое ввело заказ18 60 CE 00232 Идентификаторустройства, скоторого был введензаказ19 80 CN 00233 Лицо,инициировавшееуправление заказомРис. 4-1 Атрибуты сегмента ORCПримечания к использованию сегмента ORCa) пакеты заказовВ стандарте HL7 предусмотрен механизм сбора нескольких заказов в одинпакет. Чаще всего он используется для реализации “сеанса заказов”,обеспечивающего ввод всех заказов для одного пациента.Пакет заказов представляет собой список заказов (сегментов ORC), у которыхполе ORC-4-номер пакета заказов имеет одно и то же значение. Пакетпорождается, когда исполнитель присваивает номер пакета исходному заказу.Пакет состоит из всех сегментов ORC и сегментов деталей заказов, имеющиходин и тот же номер пакета. Заказы могут быть удалены из пакета, используяоперацию отмены заказа, или добавлены в пакет, используя механизмызамещения или отношения отец-потомки. Новые заказы не могут быть инымобразом добавлены к пакету.b) дублируемые поляСегмент ORC предназначен для однородного определения полей, общих длявсех сегментов (например, поля, определяющего запрашиваемую услугу).Некоторые поля сегмента ORC дублируются в отдельных сегментах деталейзаказа (например OBR, RXO). К примеру, поле ORC-2-номер заказа уисполнителя имеет то же значение и тот же смысл, что и поле OBR-2-номерзаказа у исполнителя. Тем самым обеспечивается совместимость спредыдущими версиями стандарта HL7 и со стандартом ASTM.Правило использования этих полей таково: значение должно появиться всегменте деталей заказа, если оно не было указано в сегменте ORC. Однакорекомендуется передавать это значение в обоих полях во избежаниенедоразумений.c) отец/потомки - отмена, прерывание, прекращение выполнения заказаПри передаче запроса на отмену, приостановку или прекращение исполнениязаказа, он должен применяться рекурсивно как к заказу-отцу, так и ко всем

связанным с ним заказам-потомкам.Пример:1) Приложение, выполняющее обработку ЭКГ, получило заказ на выполнениепо одному утреннему исследованию ЭКГ в течение трех дней.2) Приложение обработки ЭКГ создает три заказа-потомка, по одному длякаждого запрошенного исследования ЭКГ.3) Исследование ЭКГ первого дня было уже выполнено, когда пришел запросна отмену исходного заказа-отца. (Таким образом, часть работы,порожденной заказом-отцом, уже была выполнена к моменту поступлениязапроса на его отмену.)4) В результате запроса на отмену заказа-отца были отменены оставшиесяеще не выполненными порожденные заказы-потомки.4.3.1.0 Определения полей сегмента ORCУправление заказом (ID) 00215Определение: задает функцию сегмента заказа. Допустимые значения приведеныв таблице 0119 - управление заказом . Весьма детальные объяснения поуправлению заказами даются в конце этого раздела.Это поле может рассматриваться как идентификатор “события “, связанного сзаказами. Его значения можно грубо подразделить на три категории кодов:a) запросы событийДля инициации событий используются коды типа “NW” (новый заказ) и “CA”(запрос на отмену заказа).b) подтверждение событияВ ответах на запросы событий используются коды типа “OK” (заказ принят) и“CR” (заказ отменен в соответствии с запросом).c) уведомление о событииПри уведомлении других приложений о том, что произошло событие,используются коды типа “OC” (заказ отменен) и “OD” (выполнение заказапрекращено). При этом ответа от этих приложений не требуется.Коды запроса событий используются при инициации события. Кодыподтверждения событий используются при ответе приложению, которое запросилособытие. Коды уведомления о событиях используются для уведомления другогоприложения, к примеру, о том, что заказчик выполнил некоторое действие сзаказом, о чем это приложение, например исполнитель, должно знать.Как заказчики, так и исполнители, и другие приложения могут использоватьзапросы событий, подтверждения событий и уведомления о событиях. Однаконекоторые коды управления заказами могут исходить только от заказчика(например CR), а другие только от исполнителя (например CA).Значе-ние 1 Описание Иници-аторПриме-чание2кполю 3NW Новый заказ З lOK Заказ принят И lCA Запрос на отмену заказа З aOC Заказ отменен ИCR Заказ отменен в соответствии с запросом ИUC Отмена заказа невозможна И bDC Запрос на прекращение выполнения заказа З c

OD Выполнение заказа прекращено ИDR Выполнение заказа прекращено в соответствии с ИзапросомUD Прекращение выполнения заказа невозможно ИHD Запрос на приостановку выполнения заказа ЗOH Выполнение заказа приостановлено ИUH Приостановка выполнения заказа невозможна ИHR Выполнение заказа приостановлено вИсоответствии с запросомRL Продолжить приостановленное выполнение заказа ЗOR Выполнение заказа продолжено в соответствии с ИзапросомUR Продолжение приостановленного выполнения Изаказа невозможноRP Запрос на замещение заказа З e,d,hRU Заказ заменен по инициативе исполнителя И f,d,hRO Замещающий заказ З,И g,d,h,lRQ Заказ замещен в соответствии с запросом И d,e,g,hUM Замещение заказа невозможно ИPA Заказ-отец И ICH Заказ-потомок И IXO Запрос на изменение заказа ЗXX Заказ изменен по инициативе исполнителя ИUX Изменение заказа невозможно ИXR Заказ изменен в соответствии с запросом ИDE Ошибка в данных З,ИRE Результаты последуют З,И jRR Запрос получен З,И kSR Ответ на запрос о посылке статуса заказа ИSS Запрос на посылку статуса заказа ЗSC Статус заказа изменен ИSN Послать номер заказа И lNA Номер присвоен, комбинация результатов З lCN Комбинация результатов И mТаблица 0119 Коды управления заказом и их значения1 Значение поля управления заказом2 “З”: значения исходят от заказчика и не обязаны посылаться только исполнителю.“И”: значения исходят от исполнителя или другого приложения с правами исполнителя(в соответствии с соглашениями о взаимодействии приложений).3 Объяснения кодов см. в примечаниях к таблице с указанной буквой.

4.3.1.1 Примечания к кодам управления заказом в сегменте ORCa) CAОтмена представляет собой запрос, требующий не выполнять ранеезаказанную услугу. Подтверждение отмены обеспечивается исполнителем,например в сообщении, у которого поле ORC-1-управление заказом имеетзначение CR.b) UCКод невозможности отмены заказа используется в ситуации, когда заказ науслугу находится в таком состоянии, что либо он не может быть отмененисполнителем, либо местные правила не позволяют исполнителю отменитьзаказ. Использование этого кода зависит от значения поля ORC-6-флагответа.c) DCЗапрос на прекращение выполнения заказа используется для аварийногозавершения уже начатого выполнения заказа. Прекращение не эквивалентноотмене заказа, которая представляет собой попытку предотвратитьвыполнение заказа.d) RPRQЗамещение представляет собой замену одного или нескольких ранеепереданных заказов на один или несколько других заказов.RUROЗамещаемые заказы трактуются как отменяемые. При каких условиях и когдауже заказанные услуги могут быть заменены на другие, зависит от местныхсоглашений.Используйте управляющие коды отношения отцы/потомки, если местныеправила требуют, чтобы исходный заказ оставался интактным. В этом случаекоды замещения употреблять нельзя.Для каждого замещаемого заказа присваивайте полю ORC-1-управлениезаказом значение RP (запрос на замещение, направленный исполнителю) илиRU (замещение по инициативе исполнителя), используемые исполнителемдля уведомления заказчика или других приложений. По местнымсоглашениям, за сегментом ORC (с кодами управления заказом RP или RU)может следовать сегмент деталей исходного заказа. За сегментами ORC (скодами RP или RU) должен следовать сегмент ORC, у которого полеORC-1-управление заказом имеет значение RO (обозначающее замещающийзаказ). По местным соглашениям, за сегментом ORC (с кодом управлениязаказом RO) может следовать сегмент деталей заказа.Для примера предположим, что приложение вспомогательного подразделениязаменило два заказа OBR на три различных заказа. В этом случаепоследовательность передаваемых сегментов может иметь следующий вид:Сегмент КодКомментарийуправленияORC RU Сегмент ORC первого замещаемого заказаOBRСегмент деталей первого замещаемого заказаORC RU Сегмент ORC второго замещаемого заказаOBRСегмент деталей второго замещаемого заказаORC RO Сегмент ORC первого замещающего заказаOBRСегмент деталей первого замещающего заказаORC RO Сегмент ORC второго замещающего заказаOBRСегмент деталей второго замещающего заказа

ORC RO Сегмент ORC третьего замещающего заказаOBRСегмент деталей третьего замещающего заказаРисунок 4-2 Использование кодов RU и RO (пример)Обязательность присутствия сегментов OBR определяется значением поляORC-6-флаг ответа.Описанный выше метод замещения заказов охватывает все возможныеслучаи замещения: один к одному, один ко многим и многие ко многим. Если вприведенном выше примере заказчик посылает исполнителю два запроса(сообщения) с кодами RP, то, как показано в следующем примере реакцииисполнителя на эти запросы, два кода RU (замещение по инициативеисполнителя) заменяются на два кода RQ (замещение в соответствии сзапросом заказчика).Сегмент КодКомментарийуправленияORC RQ Сегмент ORC первого замещаемого заказаOBRСегмент деталей первого замещаемого заказаORC RQ Сегмент ORC второго замещаемого заказаOBRСегмент деталей второго замещаемого заказаORC RO Сегмент ORC первого замещающего заказаOBRСегмент деталей первого замещающего заказаORC RO Сегмент ORC второго замещающего заказаOBRСегмент деталей второго замещающего заказаORC RO Сегмент ORC третьего замещающего заказаOBRСегмент деталей третьего замещающего заказаРисунок 4-3 Использование кодов RQ и RO (пример)e) RPRQКод запроса на замещение заказа позволяет исполнителю заказа заместитьодин или несколько новых заказов по запросу приложения-заказчика.f) RUКод замещения по инициативе исполнителя позволяетприложению-исполнителю уведомить другое приложение о замещении, хотязапроса на замещение от заказчика не было.g) RORQКод замещения заказа посылается приложением-исполнителем другомуприложению и обозначает услугу, замещающую ранее заказанную. Ониспользуется с кодами управления заказом RP и RU, как это было описано

выше.h) RPRQПравила для номеров заказов в сегментах ORC, содержащих кодыуправления заказом RO определяются в зависимости от типа замещения (RPили RU).RUROВ случае типа RU (заказ замещается по инициативе исполнителя), номерзаказа у исполнителя формируется как обычно, приложением-исполнителем.Номер заказа у заказчика идентичен номеру заказа, переданному заказчикомв первом сообщении, у которого сегмент ORC содержит код управлениязаказом RU.В случае типа RP (замещения заказа инициировано запросом другогоприложения, переданным исполнителю), номер заказа у заказчикаформируется приложением-заказчиком с помощью процедуры присваиванияномеров новым заказам. Номер заказа у исполнителя формируетсяисполнителем с помощью аналогичной процедуры.Если замещающая последовательность используется в сообщении ORU (тоесть при передаче результатов), то для замещающих заказов рекомендуетсяиспользовать следующие сегменты:1) Сегмент ORC со значением поля управления заказом RO2) Любой сегмент OBR (может быть заменен на любой сегмент деталейзаказа)3) За этими сегментами может следовать необязательный сегментрезультатов исследований (OBX)4) Сегменты NTE могут быть указаны после сегмента OBR (или любогосегмента деталей заказа)) либо после сегмента OBX, как в обычномсообщении ORUI) PACHКоды управления заказом-отцом (PA) и заказом-потомком (CH) позволяютразмножение заказов-потомков, не изменяя исходного заказа-отца. За однимили несколькими сегментами ORC, у которых поле ORC-1-управлениезаказом имеет значение PA, передаются один или несколько сегментов ORC,у которых поле ORC-1-управление заказом имеет значение CH. Должны липри этом присутствовать сегменты OBR, зависит от значения поляORC-6-флаг ответа.Предположим, к примеру, что микробиологическая лаборатория высеяла двекультуры микроорганизмов из присланного биоматериала и подготовила дваотчета о результатах исследования этих культур на чувствительность кантибиотикам. Соответствующая последовательность сегментов может иметьследующий вид:Сегмент КодКомментарийуправленияORC PA Первый сегмент ORC заказа-отцаORC CH Первый сегмент ORC заказа-потомкаOBRПервый сегмент деталей заказа-потомкаORC CH Второй сегмент ORC заказа-потомкаOBRВторой сегмент деталей заказа-потомка

Рисунок 4-4 Пример двух заказов-потомковПрисваивание номеров заказа в парадигме отец-потомки зависит от того,был ли заказ-потомок инициирован заказчиком или исполнителем, а впоследнем случае - от того, допускает ли заказчик трансакцию SN/NA. Еслизаказчик создает заказы-потомки, то он присваивает им регистрационныеномера заказчика в соответствии со своей обычной процедурой. Еслизаказы-потомки созданы исполнителем, то существуют две возможности:каждый заказ-потомок наследует регистрационный номер заказчика от своегозаказа-отца, либо исполнитель будет использовать трансакцию SN/NA длязапроса регистрационных номеров для заказов-потомков у заказчиказаказа-отца. В любом случае приложение-исполнитель создаетрегистрационные номера исполнителя для заказов-потомков, следуя своейобычной процедуре.При формировании сообщения с заказом-потомком полю ORC-8-заказ-отецего сегмента ORC присваивается регистрационный номер заказа-отцаисполнителя (если сообщение исходит от исполнителя) или регистрационныйномер заказа-отца заказчика (если сообщение исходит от заказчика).Механизм отцов-потомков может быть использован для “расширения”заказа-отца (например для передачи заказа на утреннее выполнение ЭКГ втечение трех последовательных дней).j) REКод результаты последуют используется для передачи в сообщении заказаинформации, специфической для данного сегмента. За сегментом деталейзаказа (например OBR) могут следовать один или несколько сегментовисследований/результатов (OBX). С помощью этого механизма можнопередавать любые данные исследований, которые могут быть переданы всообщении ORU. Если результаты передаются вместе с заказом, то онидолжны следовать немедленно за заказом или заказами, с которыми онисвязаны.В следующем примере показана последовательность сегментов для трехзаказов на лекарства. Он иллюстрирует использование кода RE:СегментУправлениезаказомКомментарийMSHPIDORC NW Первый новый заказRXOСегмент первого заказаORC NW Второй новый заказRXOСегмент второго заказа[ORC OBR] RE Информация о пациенте, необязательная в версии 2.2OBX Сегмент деталей заказа, необязательный в версии 2.2OBXСегмент исследований/результатовOBXДополнительный сегмент исследований/результатовOBXДополнительный сегмент исследований/результатовORC NW Дополнительный сегмент исследований/результатовRXOТретий заказСегмент деталей третьего заказа

ii) С помощью сообщения ORR, у которого поле ORC-1-управление заказомимеет значение NA (см. приведенное ниже описание).NAКод присваивания номера позволяет “другому” приложению уведомитьприложение-исполнитель о значении вновь присвоенного регистрационногономера заказа у исполнителя. Сегмент ORC должен содержать полеORC-1-управление заказом со значением NA, поле ORC-2-номер заказа узаказчика (взятое из сегмента ORC со значением SN), а также вновьприсвоенный регистрационный номер заказа у исполнителя.Примечание: Как регистрационный номер заказчика, так ирегистрационный номер исполнителя должны содержатьидентификатор приложения-исполнителя.Код Источник ORC-2-номер у заказчика ORC-3-номеру исполнителяSNNAприложение-исполнитель номер узаказчика^идентификаторприложения-исполнителядругоеприложениеномер узаказчика^идентификаторприложения-исполнителяпустойномер узаказчика^идентификаторприложения-исполнителяПриложению-исполнителю необходим регистрационный номер заказа узаказчикаSNКод посылки номера заказа обеспечивает механизм, с помощью которогоприложение-исполнитель может запросить значение ORC-2-номер заказа узаказчика у некоторого другого (называемого “другим” в приведенной нижетаблице, посылая сообщение ORM, у которого в сегмента ORC полюORC-1-управление заказом присвоено значение SN. Этот сегмент ORC имеетпустые поля ORC-3-номер заказа у исполнителя и ORC-2-номер заказа узаказчика, создаваемые приложением-исполнителем, когда оно инициируетзаказ.Сообщение ORM (типа SN) может быть подтверждено двумя способами:i) С помощью сообщения ORR, у которого поле ORC-1-управление заказомимеет значение OK. Прямое сообщение ORM может быть послано спустякакое-то время, и в этом случае оно должно содержать сегмент ORC, укоторого поле ORC-1-управление заказом имеет значение NA.ii) С помощью сообщения ORR, у которого поле ORC-1-управление заказомимеет значение NA (см. приведенное ниже описание).NAКод присваивания номера позволяет “другому” приложению уведомитьприложение-исполнитель о значении вновь присвоенного регистрационногономера ORC-2-номер у заказчика. Сегмент ORC должен содержать полеORC-1-управление заказом со значением NA, поле ORC-2-номер у заказчикаи поле ORC-3-номер у исполнителя (взятое из сегмента ORC со значениемSN)Примечание: новое значение ORC-2-номер у заказчика содержитидентификатор приложения-заказчика.

Код Источник ORC-2-номер у заказчика ORC-3-номеру исполнителяSNNAприложение-исполнитель пустойдругоеприложениеномер узаказчика^идентификаторприложения-заказчиканомер уисполнителя^идентификаторприложения-исполнителяномер уисполнителя^идентификаторприложения-исполнителяПриложению требуется регистрационный номер заказа у исполнителяNWЕсли приложение (не являющееся исполнителем) создает заказ и ему надоприсвоить этому заказу регистрационный номер исполнителяилиRO(сегмент с кодом RO, следующий за сегментом с кодом RP). В этом случае“другое” приложение дополняет значение поля ORC-3-номер заказа уисполнителя, используя в качестве второго компонента регистрационногономера заказа у исполнителя идентификатор приложения-исполнителя.Код Перемещение ORC-2-номер заказау заказчикаNWилиROот другогоприложения кисполнителюномер заказа узаказчика^идентификаторприложения-заказчикаORC-3-номер заказау исполнителяномер заказа уисполнителя^идентификаторприложения-исполнителяm) CNКод комбинации результатов обеспечивает механизм передачи результатов,связанных с двумя или большим числом заказов. Эта ситуация нередковстречается при передаче заключений по рентгенологическимисследованиям, когда врач-рентгенолог диктует одно заключение по двум илибольшему числу исследований, соответствующим двум или большему числузаказов. Например, врач-рентгенолог может надиктовать одно заключение поснимкам колена и кисти пациента с ревматоидным артритом.Когда передаются такие результаты, то во всех сегментах ORC, кромепоследнего, вместо кода RE используется код CN, а сами результаты следуютза последним сегментом ORC и сегментом деталей заказа OBR. Вприведенном ниже примере один результат следует за тремя сегментамиORC:MSH|...PID|...ORC|CN|...OBR||A4461XA^HIS|81641^RAD|73666^Обе ступни |...ORC|CN|...OBR||A4461XB^HIS|81642^RAD|73642^Обе кисти|...ORC|RE|...OBR||A4461XC^HIS|81643^RAD|73916^Оба колена|...OBX||CE|73916&IMP||Наблюдаемая картина|...OBX||CE|73642&IMP||Наблюдаемая картина|...OBX||FT|73642&GDT||Заключение|...Номер заказа у заказчика (CM) 00216Компоненты:

^Определение: регистрационный номер заказа, присвоенныйприложением-заказчиком.Это поле является составным. Первый компонент представляет собой строкудлиной до 15 символов, идентифицирующую конкретный заказ (например OBR).Он присваивается заказчиком (приложением, оформляющим заказ). Онидентифицирует данный заказ среди всех остальных, созданных даннымприложением-заказчиком. Второй компонент является идентификаторомприложения-заказчика. Идентификатор приложения представляет собой строкудлиной до шести (6) символов, которая однозначно определяет данноеприложение. Учреждение или группа взаимодействующих учреждений должнысоздать единый список приложений, которые могут быть потенциальнымизаказчиками и исполнителями, и присвоить этим приложениям уникальныеидентификаторы. Два компонента отделяются друг от друга разделителемкомпонентов.Есть три ситуации, когда истинный заказчик произволен (и поэтому не уникален):a) когда поле ORC-1-управление заказом имеет значение RO и следует засегментом ORC замещаемого заказа (у которого значение этого поля равноRU);b) когда поле ORC-1-управление заказом имеет значение CH (заказы-потомки);c) когда поле ORC-1-управление заказом имеет значение (послать номер).Детали того, какие значения присваиваются полю ORC-2-номер заказа у заказчикав указанных выше ситуациях, см. в таблицах, приведенных в описании поляORC-1-управление заказом.Учреждение или группа взаимодействующих учреждений должны создать единыйсписок приложений, которые могут быть потенциальными заказчиками иисполнителями, и присвоить этим приложениям уникальные идентификаторы.Список идентификаторов приложений становится одним изсправочно-нормативных файлов учреждения, документированных в другом местеверсии 2.2 стандарта HL7. Поскольку третьи приложения (не являющиесязаказчиками или исполнителями заказов) могут посылать и получать сообщенияORM и ORR, то приложение с идентификатором, указанным в поле ORC-2-номерзаказа у заказчика, может не совпадать ни с приложением-отправителем, ни сприложением-получателем (идентификаторы которых указаны в сегментезаголовка сообщения MSH).Поле ORC-2-номер заказа у заказчика имеет тот же смысл, что и полеOBR-2-номер заказа у заказчика . Если регистрационный номер заказа,присваиваемый заказчиком, отсутствует в сегменте ORC, то он долженприсутствовать в ассоциированном сегменте OBR, и наоборот. Если оба поля,ORC-2-номер заказа у заказчика и OBR-2-номер заказа у заказчика , присутствуютв сообщении, то они должны содержать одно и то же значение. Если результатыпередаются в сообщении ORU, то сегмент ORC не является обязательным иидентифицирующий заказ номер заказчика должен присутствовать в сегментахOBR.Эти правила равным образом применимы к нескольким другим полям,присутствующим как в сегменте ORC, так и в сегменте OBR для совместимости спредыдущими версиями стандарта (например количество/срок; номера отцов;лицо, сделавшее заказ; телефоны для справок по заказу).Номер заказа у исполнителя (CM) 00217Компоненты: ^Определение: регистрационный номер заказа, присвоенныйприложением-исполнителем. Первый компонент представляет собой строкудлиной до 15 символов, идентифицирующую конкретный сегмент деталей заказа

(например OBR). Он присваивается исполнителем заказа (приложением,получающим заказ). Он идентифицирует данный заказ среди всех остальных,полученных данным приложением-исполнителем (например клиническойлабораторией). Уникальность этого номера должна сохраняться с течениемвремени.Второй компонент является идентификатором приложения-заказчика.Идентификатор приложения представляет собой строку длиной до шести (6)символов, которая однозначно определяет данное приложение среди другихприложений данной сети. Второй компонент номера заказа у исполнителя всегдаотносится к фактическому исполнителю заказа.Учреждение или группа взаимодействующих учреждений должны создать единыйсписок приложений, которые могут быть потенциальными заказчиками иисполнителями, и присвоить этим приложениям уникальные идентификаторы.Список идентификаторов приложений становится одним изсправочно-нормативных файлов учреждения, документированных в другом местеверсии 2.2 стандарта HL7. Поскольку третьи приложения (не являющиесязаказчиками или исполнителями заказов) могут посылать и получать сообщенияORM и ORR, то приложение с идентификатором, указанным в поле ORC-3-номерзаказа у исполнителя, может не совпадать ни с приложением-отправителем, ни сприложением-получателем (идентификаторы которых указаны в сегментезаголовка сообщения MSH).Поле ORC-3-номер заказа у исполнителя имеет тот же смысл, что и полеOBR-3-номер заказа у исполнителя. (Это правило относится и к несколькимдругим полям, присутствующим как в сегменте ORC, так и в сегменте OBR длясовместимости с предыдущими версиями стандарта HL7 и стандартом ASTM.) Этоособенно важно, когда результаты передаются в сообщении ORU. В этом случаесегмент ORC не является обязательным и идентифицирующий заказ номерисполнителя должен присутствовать в сегментах OBR.Номер заказа у исполнителя (поле OBR-3 или поле ORC-3) также однозначноидентифицирует заказ и связанные с ним результаты исследований.Предположим, к примеру, что учреждение получает результаты исследований отнескольких приложений вспомогательных подразделений и помещает их в общуюбазу данных. Пусть какое-то другое приложение обращается к этой базе данных сзапросом на получение результатов исследований. В этом случаерегистрационные номера заказа у заказчика и исполнителя, переданные из базыданных, должны быть теми же, что были у фактических заказчика и исполнителя, ане новые, присвоенные приложением, обрабатывающим запросы к базе данных.Аналогично, если некоторое третье приложение, не являющееся ни исполнителем,ни заказчиком, наделено правами модифицировать состояние заказа (напримеротменять его), то это третье приложение должно посылать исполнителюсообщение ORM, у которого поле ORC-1-управление заказом сегмента ORCсодержит значение “CA” и исходные номера заказа у заказчика и исполнителя, ане присваивает эти номера самостоятельно.Номер пакета заказов (CM) 00218Компоненты: ^ Определение: позволяет приложению-заказчику группировать заказы в пакеты изатем идентифицировать эти пакеты.Первый компонент представляет собой строку из 15 символов, которая однозначноидентифицирует конкретный пакет заказов среди всех пакетов данногоприложения. Он присваивается приложением-заказчиком и может выбираться изтого же ряда, что и номера заказа у заказчика в сегменте ORC, но это не являетсяобязательным.Второй компонент является идентификатором приложения-заказчика и совпадаетсо вторым компонентом поля ORC-2-номер заказа у заказчика . Пакеты заказов и

их использование детально описаны в конце раздела, посвященного сегментуORC, а также в примерах.Статус заказа (ID) 00219Определение: статус заказа. Допустимые значения см. в таблице 0038 - статусзаказа. Это поле служит для того, чтобы можно было передать информацию осостоянии выполнения заказа или по запросу (инициированному другимиприложением), или при изменении этого состояния (как прямое сообщение). Ононе инициирует никаких действий. Предполагается, что статус заказа всегдаотражает состояние выполнения заказа, известное приложению-отправителю вмомент отправки сообщения. Только приложение-исполнитель может даватьзначение этому полю.Хотя таблица 0038 - статус заказа содержит многие из тех значений, чтоуказаны в таблице 0119 - управление заказом , у нее иное назначение. Обычностатус заказа используется в сообщении, у которого поле ORC-1-управлениезаказом имеет значение SR или SC, чтобы передать информацию о статусе заказадругому приложению по его запросу или по собственной инициативе.ЗначениеCACMDCERHDIPRPSCОписаниеЗаказ был отмененВыполнение заказа завершеноВыполнение заказа было прекращеноОшибка, заказ не найденВыполнение заказа приостановленоИдет обработка, неспецифицированнаяЗаказ был замещенПоставлен в очередь на выполнениеТаблица 0038 Статус заказаФлаг ответа (ID) 00220Определение: позволяет приложению-заказчику (отправителю) задать объеминформации, возвращаемой исполнителем заказа. Иногда запрашиваемый объеминформации не может быть передан немедленно, но как только это становитсявозможным, приложение-исполнитель (получатель) должно послать этуинформацию. Если это поле пусто, то по умолчанию предполагается значение D.Допустимые значения поля см. в таблице 0121 - флаг ответа.ЗначениеERDFNОписаниеТолько исключения из отчетаТо же, что и E, но также замещения и отцы-потомкиТо же, что и R, но также другие ассоциированные сегментыТо же, что и D, но также явное подтверждениеТребуется только возвращение сегмента MSA

Таблица 0121 Флаг ответаКоличество/срок (TQ) 00221Компоненты: ^ ^ ^ ^ ^ ^ ^ ^ ^ Определение: определяет приоритет, количество, частоту и сроки выполненияединичной услуги. Сегменты заказа должны рассматриваться как описаниеединичной услуги. Это поле является составным; детали его определения см. вразделе 4.4.Например, если сегмент OBR описывает дозу крови, то это поле может задавать,что три таких дозы должны быть даны по утрам в течение трех последовательныхдней. В этом случае поле ORC-7-количество/срок должно иметь значение“1^XQAM^X3”. Значение поля ORC-7-количество/срок то же, что и у поляOBR-27-количество/срок.Заказ-отец (CM) 00222Компоненты: ^ Определение: связывает заказ-потомок с его отцом, если существует отношениеотец-потомки. Механизм отцов-потомков описан в примечаниям к полюORC-1-управление заказом. Первый компонент содержит регистрационный номерзаказа-отца у заказчика. Он обязателен, если данный заказ является потомкомдругого заказа.Второй компонент содержит регистрационный номер заказа-отца у исполнителя.Компоненты номера заказа у заказчика и номера заказа у исполнителя передаютсякак субкомпоненты двух компонентов этого поля. Значение поляORC-8-заказ-отец то же, что и у поля OBR-29-заказ-отец.Дата и время трансакции (TS) 00223Определение: дата и время ввода текущей трансакции приложением-заказчиком.При создании новых заказов это поле содержит дату и время ввода заказа.Для других сообщений это поле содержит дату и время ввода текущей трансакции(например отмены заказа). Эти дата и время относятся к текущей трансакции, а нек времени “замещения” при коррекции исходного заказа. Аналогично, поляORC-10-лицо, которое ввело заказ, ORC-11-лицо, проверившее заказ иORC-13-адрес лица, которое ввело заказ относятся к текущей трансакции, а не кисходному заказу.Лицо, которое ввело заказ (CN) 00224Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентифицирует лицо, которое непосредственно ввело запрос вприложение. Оно обеспечивает возможность найти это лицо, если запрос введеннеправильно и вспомогательному подразделению необходимо уточнить запрос. Поместным соглашениям либо идентификатор, либо фамилия, имя и отчество могутопускаться.Лицо, проверившее заказ (CN) 00225Компоненты: ^ ^ ^ ^ ^ ^ ^

Определение: идентифицирует лицо, которое проверило точность введенногозапроса. Оно используется в ситуации, когда запрос вводится оператором идолжен быть утвержден более ответственным работником (например медицинскойсестрой). По местным соглашениям либо идентификатор, либо фамилия, имя иотчество могут опускаться.Лицо, сделавшее заказ (CN) 00226Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентифицирует лицо, ответственное за создание запроса(например лечащего врача). Значение поля ORC-12-лицо, сделавшее заказ то же,что у поля OBR-16-лицо, сделавшее заказ.Адрес лица, которое ввело заказ (CM) 00227Определение: местонахождение (например отделение, этаж) лица, которое ввелозаказ. Это поле является составным; оно может включать в себя в соответствии сместной спецификой некоторую субкатегорию подразделения. Например, значениеICU4 может являться обозначением блока интенсивной терапии (ICU),расположенного на четвертом этаже.Телефон для справок по заказу (TN) 00228Определение: номер телефона, по которому можно уточнить запрос или другуюинформацию. связанную с заказом. Значение поля ORC-14-телефон для справокпо заказу то же, что у поля OBR-17-телефон для справок по заказу .Дата и время ввода заказа в действие (TS) 00229Определение: дата и время, когда изменения в запросе вступили в силу илипредполагаются ввести в действие.Если значение поля ORC-9-дата и время трансакции следует за значением поляORC-15-дата и время ввода заказа в действие или совпадает с ним, то значенияданных в сегменте ORC и подчиненных ему сегментах имели место в моментвремени ORC-15-дата и время ввода заказа в действие.Если значение поля ORC-9-дата и время трансакции предшествует значениюполя ORC-15-дата и время ввода заказа в действие, то значения данных всегменте ORC и подчиненных ему сегментах планируются в момент времениORC-15-дата и время ввода заказа в действие.Если значение поля ORC-15-дата и время ввода заказа в действие оставленопустым, то оно предполагается равным тому значению, которое указано в полеORC-9-дата и время трансакции или в поле MSH-7-дата и время сообщения,если дата и время трансакции оказалось также пустым.В случае, если время, указанное в поле ORC-15-дата и время ввода заказа вдействие (для события управления заказом в том же сегменте ORC) отличаетсяот соответствующих даты и времени, указанных в поле ORC-7-количество/срок, товремя, указанное в поле ORC-15-дата и время ввода заказа в действие, имеетприоритет. Таким образом, если событие, связанное с сегментом ORC,представляет собой запрос исполнителю на прекращение продолжающегосявыполнения заказа, и дата и время ввода заказа в действие предшествуют дате ивремени конца, указанным в поле ORC-7-количество/срок, то дата и время вводазаказа в действие должны иметь приоритет. Если заказ, чей идентификатор указанв сегменте ORC, имеет потомков, то те заказы-потомки, чье выполнение еще неначато, должны быть отменены; те, чье выполнение все еще продолжается,должны быть прекращены; те же потомки, чье выполнение уже завершилось, неизменят своего статуса.Причина управления заказом (CE) 00230Компоненты: ^ ^ ^

^ ^ Определение: объяснение (в кодированном виде или в виде свободного текста)причины события заказа, заданного кодом управления заказом (таблица 0119). Вто время как сегмент комментария NTE, следующий за конкретным типом сегментадеталей заказа (например RXO, ORO, OBR) мог бы содержать пояснения кпоследнему сегменту, назначение поля причины управления заказом состоиттолько в пояснении причины события заказа.Если поле ORC-1-управление заказом имеет значение NW, то полюORC-16-причина управления значение обычно не присваивается, хотя оно может иприсутствовать. Например в случае отмененного заказа это поле нередкоиспользуется для объяснения причины отмены заказа. Аптечная система, котораяотменила лекарственное назначение лечащего врача из-за документальнозафиксированной аллергии, вполне может воспользоваться этим полем, чтобысообщить о факте аллергии.Если назначение было отменено из-за выявленного лекарственноговзаимодействия, то это поле может содержать как минимум названиявзаимодействующих субстанций (а если надо, то и их коды), текст, описывающийвзаимодействие, а также силу взаимодействия.Учреждение, которое ввело заказ (CE) 00231Компоненты: ^ ^ ^ ^ ^ Определение: организация, которую представляло лицо, что ввело заказ, в моментего ввода или выполнения трансакции с этим заказом.Идентификатор устройства, с которого был введен заказ (CE) 00232Компоненты: ^ ^ ^ ^ ^ Определение: идентифицирует физическое устройство (терминал, персональныйкомпьютер), использованное для ввода заказа.Лицо, инициировавшее управление заказом (CN) 00233Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентифицирует лицо, инициировавшее событие, представленноесоответствующим кодом управления заказом. Например, если код управлениязаказом имеет значение CA (отмена заказа), то в этом поле указано лицо,отменившее заказ.4.3.2 Сегмент BLG - оплатаСегмент BLG используется для предоставления приложению-исполнителюинформации об оплате заказанной услуги.П/П123

Рисунок 4-6 Атрибуты сегмента BLG4.3.2.0 Определения полей сегмента BLGМомент оплаты (CM) 00234Компоненты: ^ Определение: это поле задает код момента оплаты заказанной услуги. Первыйкомпонент содержит значение, определенное в таблице 0100-момент оплаты.Второй компонент используется для указания точных даты и времени оплатызаказанной услуги; он используется только в том случае, если код моментаоплаты имеет значение T. Коль скоро он указан, его значение имеет тип данных.ЗначениеDORSTОписаниеПри выпискеПо получении заказаПо завершению выполнения услугиПеред началом выполнения услугиВ заданные дату и времяТаблица 0100 Момент оплатыТип оплаты (ID) 00235Определение: идентифицирует кого-то или что-то, отличное от пациента иобеспечивающее оплату данной услуги. Используется в сочетании с полемBLG-3-идентификатор счета.ЗначениеCHCOCRDPGRNCPCRSОписаниеРазовая оплатаКонтрактКредитПодразделениеГрантБез оплатыПрофессиональная деятельностьИсследованиеТаблица 0122 Тип оплатыИдентификатор счета (CK) 00236

Компоненты: ^ ^ ^ Определение: идентифицирует счет, по которому проводится оплата.Используется в сочетании с полем BLG-2-тип оплаты. См. таблицу 0061 - схемаконтрольного суммирования в главе 2.4.4 Количество/срок (TQ) определениеКомпоненты: ^ ^ ^ ^ ^ ^ ^ ^ ^ Определение: поля количества/срока (ORC-7, OBR-27 обеспечивают возможностьуказания момента, когда указанная в сегменте заказа услуга должна бытьвыполнена, и периодичности ее выполнения. Это сложное многокомпонентноеполе допускает повторы, т.е. можно указывать несколько спецификацийколичества и срока, разделяя их символами повтора. Это отличающийся типданных (см. раздел 2.4.5.20); компоненты отдельной спецификацииколичества/срока описаны в подразделах 4.4.1-4.4.10.4.4.1 Компонент количества (CQ)Субкомпоненты: Определение: количество услуг, которые должны быть оказано в каждом периодеуслуг. Например, если две культуры микроорганизмов из крови должны получатьсякаждые 4 часа, то количество должно быть равно 2. Если для трех дозы кровидолжны быть определены группы и проведены сравнения с группой реципиента, токоличество должно быть 3. Значение по умолчанию равно 1. После разделителясубкомпонентов можно добавить единицы измерения.Примечание: Разделитель компонентов в этом типе данных CQпонижен до разделителя субкомпонентов.4.4.2 Компонент интервала (CM)Субкомпоненты: Определение: задает интервалы повторения услуги.По умолчанию услуга повторяется однократно, первый субкомпонент представляетсобой повторяемый шаблон, а второй субкомпонент - явное время, от которогоотсчитывается шаблон.Повторяемый шаблонОпределение: некоторые рекомендуемые коды:QSкаждые секундQMкаждые минутQHкаждые часовQDкаждые днейQWкаждые недельQLкаждые месяцев (по лунномукалендарю)QJ повторять в заданный день недели (буква J - отфранцузского слова jour - день). Если отсутствует, то по умолчанию полагаетсяравным 1. Отсчет дней недели идет отпонедельника = 1 до воскресенья = 7. Таким

BIDTIDQIDобразом, Q2J2 означает каждый второй вторник;Q1J6 означает каждую субботу.дважды в день во время, назначенное конкретнымучреждением (например, 9-16)трижды в день во время, назначенное конкретнымучреждением (например, 9-16-21)четырежды в день во время, назначенноеконкретным учреждением (например, 6-12-18-23)Примечание: Ни одна из указанных выше трех спецификаций неэквивалента спецификации QH, например QID неэквивалентна Q6H, поскольку первая задает неравные интервалы, авторая равные.QAMQSHIFTQODQHSQPMCU PRNPRNxxxOnceпо утрам во время, назначенное конкретнымучреждениемв течение каждой восьмичасовой смены во время,назначенное конкретным учреждениемчерез день (то же, что и Q2D)каждый день перед сномпо вечерам во время, назначенное конкретнымучреждениемуслуга оказывается непрерывно с момента началадо момента концадля будущего использования, где представляет собой спецификацию интервала,определенную в операционной системе UNIX длякоманды cron.давать при необходимостигде xxx - некоторый код интервала (например,PRNQ6H); давать при необходимости с заданнойпериодичностью.Только однократно. Это значение берется также поумолчанию, если этот компонент пуст.4.4.3.1 Субкомпонент явного интервала времениОпределение: явное перечисление фактических моментов времени, на которыессылается код первого субкомпонента, в формате: ЧЧММ,ЧЧММ,ЧЧММ,... Этотвторой субкомпонент используется для уточнения первого субкомпонента вситуации, когда фактические моменты времени выполнения назначений неявляются одинаковыми для всего учреждения. Если время выполнения заказаохватывает промежуток более одного дня, то этот новый субкомпонент имеетсмысл только в том случае, если моменты выполнения назначений наступают водно и то же время дня в течение всего периода выполнения заказа. Еслифактическое время начала выполнения заказа (заданное в четвертомсубкомпоненте поля количество /срок) оказывается позже первого явно заданногомомента, то первое назначение должно выполняться в тот явно заданный момент,который оказался первым после времени начала выполнения заказа. В случае,если пациент переведен в другое место, где действует иной список явныхмоментов выполнения назначений, то существующий заказ может бытьмодифицирован с тем, чтобы в поле количество/срок был отражен новый списокмоментов выполнения назначений.Пример 2-го компонента поля количество/срок:

...^QID&0230,0830,1430,2030^...4.4.4 Компонент длительностиОпределение: задает продолжительность выполнения услуги. По умолчаниюимеет значение INDEF (выполнять без ограничения по времени). Этот компоненткодируется следующим образом:S = секундM = минутH = часовD = днейW = недельL = месяцевX = повторений заданного в заказе. Запросна 2 культуры крови вида Q2H X3 подразумевает3-кратное получение 2 культур крови с интервалом в 2часа, то есть всего 6 культур крови.T = начиная с заданных интервала и количества, пока всумме не будет получено “доз”.Единицы измерения подразумеваются те же, что и вполе КОЛИЧЕСТВО.INDEF = выполнять без ограничения по времени (это значениепринимается по умолчанию)4.4.5 Компонент даты и времени начала (TS)Определение: этот компонент может быть указан заказчиком, и в этом случаезадает самые ранние дату и время, когда должно начаться выполнение услуги.Однако во многих случаях дата и время начала не задаются явным образом илиопределяются значениями других полей сообщения заказа (например приоритет= STAT). В этих случаях данный компонент должен быть пустым.Исполнитель услуги нередко записывает значение этого компонента послеполучения заказа и, отталкиваясь от него, вычисляет время конца выполнениязаказа для своих внутренних нужд.4.4.6 Компонент даты и времени конца (TS)Определение: если этот компонент заполнен заказчиком услуги, то он долженозначать самые поздние дату и время, до которых должно быть завершеновыполнение услуги. Если она не была выполнена до этого момента, то она вообщене должна выполняться. Заказчик может не всегда заполнять этот компонент,однако исполнитель услуги может сделать это сам на основании полученных иминструкций и момента фактического начала выполнения услуги.Независимо от значения даты и времени конца, выполнение услуги должно бытьостановлено до самых ранних даты и времени, указанных либо компонентомпродолжительности выполнения, либо компонентом даты и времени концавыполнения.4.4.7 Компонент приоритета (ID)Определение: описывает срочность запроса. Рекомендуются следующие значенияприоритета (по умолчанию значение приоритета равно R):S = цито (Stat). Наивысший приоритет.A = срочный (ASAP). Выполняется после заказов с приоритетом S.R = обычный (Routine). По умолчанию.P = предоперационный (Preop).

T = время выполнения критично (Timing critical). Запрос с этим приоритетомозначает важность выполнения заказа как можно ближе к заданному моментувремени, например обеспечить требуемую минимальную концентрациюантибиотиковЕсли задано значение приоритета T (время выполнения критично), то степенькритичности может характеризоваться следующим образом:Формат:TS = время критично с точностью до секунд.TM = время критично с точностью до минут.TH = время критично с точностью до часов.TD = время критично с точностью до дней.TW = время критично с точностью до недель.TL = время критично с точностью до месяцев.При спецификациях последовательности заказов эти значения задают критичностьвремени следования данного заказа за его предшественником.4.4.8 Компонент условия (ST)Определение: этот компонент содержит свободный текст, описывающий условие,при котором лекарство должно даваться пациенту, например боли в PRN, илиподдерживать артериальное давление ниже 110 мм . Наличие текста в этомкомпоненте должно означать, что для определения того, как и/или когда должнодаваться лекарство, требуется вмешательство человека.4.4.9 Компонент текста (TX)Определение: полный вариант инструкции по выполнению заказа (не обязателен).4.4.10 Компонент сочетания (ID)Определение: ненулевое значение этого компонента означает, что последуетвторая спецификация срока, отделенная разделителем повтора. Это поле можетпринимать три значения:a) S = синхронно (Synchronous)Использовать следующую спецификацию срока после текущей (если иное незадано следующими компонентами: ORC-4^4-дата и время начала иORC-4^5-дата и время конца).Указание S подразумевает, что за первой спецификацией срока последуетвторая, например, в заказе может быть заданы измерения артериальногодавления каждые 15 минут в течение первого часа, затем каждые два часа втечение следующего дня.b) A = асинхронно (Asynchronous)Использовать следующую спецификацию срока параллельно текущей (еслииное не задано следующими компонентами: ORC-4^4-дата и время начала иORC-4^5-дата и время конца). Сочетание “A” означает две параллельныеинструкции типа тех, что используются для лекарственных назначений,например принимать преднизолон по 1 таблетке в понедельник, среду ипятницу, и по 1/2 таблетки во вторник, четверг, субботу и воскресенье.c) C = время активизацииЗа ним последует время завершения выполнения услуги. Этот код позволяетсделать различие между временем и приоритетом активизации услуги(например взятия крови) и временем и приоритетом завершения еевыполнения (например возвращения результатов анализа взятой крови).Для периодически или непрерывно выполняемой услуги момент фактическойостановки ее выполнения определяется компонентами ORC-4^5-дата и

время конца и ORC-4^3-длительность. Обычно указывается только один изэтих компонентов, но в случае, если сделан заказ ЭКГ с помощьюспецификации^I^QAM^X3^D10то ЭКГ надо выполнять только в течение трех дней, так как число повторений(3) задает более раннее время конца выполнения услуги.4.4.11 Порядок выполнения заказов (комплекс)Определение: во многих ситуациях, например при создании заказа на группурастворов для внутривенного вливания (ВВ), где надо указывать порядковыйномер применения отдельного раствора (каждый из которых представляет собойотдельный заказ). Существуют и другие ситуации, в которых часть инструкций повыполнению заказа содержат некоторое условие, например “PRN боль”. Внастоящее время существует компонент условия поля ORC-4-количество/срок,имеющий тип свободного текста и позволяющий указать любое условие. Однакодля того, чтобы обеспечить возможность указать полностью кодированныйвариант порядка выполнения заказов, в следующих абзацах определяется 10-йкомпонент поля ORC-4-количество/срок.Условия, задающие порядок выполнения и предусмотренные в 10-м компонентеполя ORC-4-количество/срок, основаны на завершении определенного заказа.Компоненты сверх 10-го зарезервированы на будущее с тем, чтобы в них можнобыло задавать несколько условий, которые должны быть проверены передвыполнением заказа. Любые такие будущие спецификации будут совместимыснизу с текущими определениями количества/срока.Примечание: Если 10-й компонент присутствует, то 7-й компонент(условие) должен рассматриваться как текстовое “примечание”,которое надо показать исполнителю заказа. Таким образом, не надоделать никаких попыток интерпретировать 7-й компонент как частьмашиночитаемой спецификации порядка выполнения заказов.4.4.11.1 Субкомпоненты порядка выполненияДля определения условий, связанных с порядком выполнения, 10-й компонентполя количества/срока разделяется на субкомпоненты, описанные на рис. 4.7.СубкопонентСодержание Примечания1 ФлагS для условия порядка выполнения, R зарезервированорезультатов/порядка для возможного будущего использования.выполнения2,3 Номер заказау заказчика4,5 Номер заказау исполнителя6 ЗначениеусловияпорядкаОбязательный/необязательный: два субкомпонентаиспользуются потому, что номер заказчика у заказчикаимеет два компонента, а в стандарте HL7 компонентыне допускаются.Обязательный/необязательный: два субкомпонентаиспользуются потому, что номер заказчика у исполнителяимеет два компонента, а в стандарте HL7субкомпоненты не допускаются.Допустимые значения условия имеют формат, обычноиспользуемый в методологиях планирования выполненияпроектов: +/- Первая буква кода означает начало (S) или конец (E)предшествующего заказа, задаваемого номером заказа у

7 Максимальноечислоповторенийзаказчика (субкомпонент 2, 3) или номером заказа уисполнителя (субкомпонент 4, 5).Вторая буква кода означает начало (S) или конец (E)следующего заказа, то есть того, который содержитданную спецификацию количества/срока.Указанное в формате условия время задает интервалмежду началом или концом выполненияпредшествующего или следующего заказа (см.следующие примеры).Спецификация времени задается следующим образом:S через секундM через минутH через часовD через днейW через недельL через месяцевМаксимальное число повторений используется толькодля циклических групп. Общее число повторенийограничивается датой и временем конца выполненияпоследнего повторения или датой и временем концавыполнения заказа-отца (берется более ранний моментвремени из этих двух).Примечания к использованию:Примем следующее предположение:Предшествующий заказ задан номером заказа у заказчика OE1000&OrdEnt,помещенном в субкомпоненты 2 и 3 компонента 10 поля ORC-4-количество/срок.ES + 10MВремя завершения выполнения заказа OE1000&OrdEnt (предшественника)плюс 10 минут задает время начала выполнения следующего заказа,OE1001&OrdEnt; таким образом, выполнение следующего (текущего) заказадолжно начаться через 10 минут после завершения выполненияпредшествующего ему заказа..SS - 10MВремя начала выполнения предшествующего заказа минус 10 минут задаетвремя начала выполнения следующего (текущего) заказа; таким образом,выполнение текущего заказа должно начаться на 10 минут раньшепредшествующего ему заказа.4.4.11.2 Циклическое повторение групп заказовВ особых случаях, когда необходимо обеспечить циклическое повторение группызаказов, в спецификации первого заказа группы должно быть использовано“условие порядка выполнения” с первым символом * (звездочка).Пример:*FS+10Mозначает: выполнять этот заказ в первый раз, не используя условие,указанное в 10-м компоненте; однако повторять выполнение этого заказатолько в том случае, если заданные извне дата и время начала или концавыполнения заказа удовлетворяют этому условию. Эта спецификация задаетповторение заказа для каждой итерации цикла.Примечание: Этот прием требует, чтобы приложение-заказчик былоспособно указать номер заказа у заказчика для последнего заказацикла в спецификации количества/срока первого заказа цикла.

Для реализации циклической группы, состоящей из четырех заказов на растворыВВ, используя парадигму отцов/потомков, в заказе-отце указывается группарастворов ВВ и производятся следующие присваивания:Поле ORC-4-срок/количество второго заказа-потомка указывает, что этотзаказ следует за первым заказом-потомком.Поле ORC-4-срок/количество третьего заказа-потомка указывает, что этотзаказ следует за вторым заказом-потомком.Поле ORC-4-срок/количество четвертого заказа-потомка указывает, что этотзаказ следует за третьим заказом-потомком.Для циклического повторения группы из четырех заказов-потомков производятсяследующие присваивания:Поле ORC-4-срок/количество первого заказа-потомка указывает, что этотзаказ должен выполниться однократно независимо от выполнения другихзаказов.Его следующее выполнение должно следовать за выполнением четвертогозаказа. См. пример в разделе 4.8.16.2.Эта схема позволяет получить следующую цепочку событий:Статус всей группы заказов сообщается обратно на уровне заказа-отца.Статус каждого отдельного заказа на раствор ВВ возвращается как статуссоответствующего заказа-потомка.Пример отдельных заказов:Та же самая группа заказов может быть послана как группа из четырехзаказов (без общего заказа-отца), связанная только содержанием их полейколичества/срока. В этом случае в стандарте HL7 нет средства передатьинформацию о статусе заказа в целом, не передавая статус каждого изчетырех отдельных заказов.4.4.11.3 Наследование статуса заказаСобытия отмены/прекращения/остановки выполнения заказа:• Эта логика предполагает нормальное выполнение предшествующего заказа.Таким образом, отмена, или прекращение, или остановка выполненияпредшествующего заказа влечет за собой отмену, или прекращение, илиостановку выполнения всех последующих заказов цепочки.• Если выполнение предшествующего заказа было отменено (прекращено илиостановлено), то текущий заказ наследует тот же статус.• В случае остановки ее прекращение для предшествующего заказа влечет засобой прекращение остановки текущего заказа (который затем можетвыполняться в соответствии со спецификацией, заданной в 10-м компоненте).4.4.12 Примеры применения количества/срока3^onceВыполнить услугу в один момент времени, например заказать переливание 3 дозкрови.1^QHS^X2Выполнить услугу дважды перед сном, например перелить одну дозу крови передсном в течение двух ночей.1^C^3DВыполнять услугу непрерывно в течение 3 дней.1^Q1H^X4^^^^Число экстрасистол>10/минВыполнять ЭКГ каждый час (не более 4 раз) при условии, что у пациентанаблюдаются более 10 экстрасистол в минуту.1^Q2J^^1432

Выполнять услугу каждый вторник в 14 час 32 мин.1^^^^198911210800Выполнить тесты до 8:00 21.11.1989г., например некоторые предоперационныетесты.1^Q3600S^X5^198911051030Выполнять услугу каждый час в течение 5 часов, начиная с 10:30 5.11.1989г.,например брать кровь для анализа содержания глюкозы.1^QAM^X3^^^^^S ~ 1^QOD^4D^^^если K+>5.5.Выполнять услугу каждое утро в течение 3 дней и затем выполнять ее через утро втечение 4 дней (т.е. не более 2 раз), если содержание калия в сыворотке кровипревысит 5.5.^^^198812120800^^T^^проба крови для микробиологии^C~^^^^^RВзять пробу крови ровно в 8:00 12.12.1988г. и присвоить заказу приоритетобычного.4.5 Заказы на выполнение исследования илипроведения диагностики4.5.1 Сегмент OBR - запрос на выполнение исследованияОбщие положения (взяты из стандарта ASTM 1238-91)Сегмент запроса на выполнение исследования OBR (Observation Request), иликратко сегмент заказа, используется для передачи информации, специфичной длязаказа на проведение диагностики, выполнение исследования, физическогоосмотра или оценки состояния пациента.Сегмент заказа определяет атрибуты конкретного запроса на диагностическиеуслуги (например выполнение лабораторных тестов или ЭКГ) либо клиническиеисследования, например антропометрию или физический осмотр. Этот сегментдолжен присутствовать в любом сообщении, в котором заказчик запрашиваетконкретный комплекс исследований. При заказе лабораторных тестов информацияв сегменте заказа обычно относится к одному образцу биоматериала. Однако вобщем случае не существует отношения один-к-одному между образцамибиоматериала и заказанными тестами. Различные комплекса тестов обычнотребуют указания собственных сегментов заказа даже если они выполняются наодном образце биоматериала. В этом случае информация о биоматериале должнадублироваться в каждом сегменте заказа, относящемся к одному и тому жеобразцу. Для других диагностических исследований, например рентгенографиигрудной клетки, для каждого исследования обычно задается отдельный сегментзаказа.Хотя в одном сегменте заказа можно затребовать несколько комплексовисследований, приложение-исполнитель должно создавать отдельный сегментзаказа для каждого комплекса, который обрабатывается независимо, напримерэлектролиты, подсчет числа клеток крови, антропометрия. Возвращая результатыисследований, приложение-исполнитель должно копировать соответствующуюинформацию заказа (о биоматериале) из исходного сегмента заказа в каждый изновых сегментов заказа с тем, чтобы отдельный сегмент “заказа” возвращалсязаказчику как “заголовок” каждого отдельного комплекса исследований.В случае, если заказанный комплекс исследований не может быть выполнен,например из-за гемолиза взятой крови, то сегмент заказа должен возвращатьсязаказчику со значением X в поле OBR-25-статус результата , означающим, чтоисследование не было выполнено. В таком случае ни одного сегмента результатовне передается.Если исследования выполнены успешно, то возвращаемое заказчику сообщениесодержит по одному сегменту заказа OBR, за которым следуют сегментырезультатов OBX, для каждого отдельного исследования, порожденного заказом

(см. главу 7). Число таким сегментов результатов зависит от числа отдельныхизмерений, проведенных в процессе выполнения заказа.Сегменты OBX могут быть посланы заказчиком в сообщении заказа с тем, чтобыпредоставить приложению-исполнителю клинические данные, необходимые дляинтерпретации результатов. (Детали структуры сегмента OBX см. в главе 7.)cП/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# Названиеэлемента1 4 SI Н 00237 Порядковый номерзапроса на выполнениеисследований2 75 CM Н 00216 Номер заказа узаказчика3 75 CM О 00217 Номер заказа уисполнителя +4 200 CE 00238 Универсальныйидентификатор услуги5 2 ID 00239 Приоритет6 26 TS У 00240 Дата и время начала7 26 TS У 00241 Дата и времяисследования #8 26 TS У 00242 Дата и времязавершенияисследования #9 20 CQ 00243 Объем сбора *10 60 CN Д 00244 Лицо, собравшеебиоматериал *11 1 ID 0065 00245 Код действия сбиоматериалом *12 60 CE 00246 Код опасности13 300 ST У 00247 Релевантнаяклиническаяинформация14 26 TS 00248 Дата и время получениябиоматериала *15 300 CM 0070 00249 Источникбиоматериала *16 80 CN Д 00226 Лицо, сделавшее заказ17 40 TN Д/2 00250 Телефон для справокпо заказу18 60 ST 00251 Поле заказчика 119 60 ST 00252 Поле заказчика 220 60 ST 00253 Поле исполнителя1 +21 60 ST У 00254 Поле исполнителя2 +22 26 TS 00255 Дата и времяформированияотчета орезультатах +23 40 CM 00256 Счет другому

лечебномуучреждению +24 10 ID У 0074 00257 Идентификаторучасткадиагностическогоподразделения25 1 ID 0123 00258 Статус результатов+26 200 CM 00259 Результатызаказа-отца +27 200 TQ Д 00221 Количество-срок28 150 CN Д/5 00260 Лицо, получающеекопию результатов29 150 CM 00261 Номер заказа-отца+30 20 ID 0124 00262 Способперемещения31 300 CE Д 00263 Причинаисследования32 60 CM 00264 Основнойинтерпретаторрезультатов +33 60 CM Д 00265 Помощникинтерпретаторарезультатов +34 60 CM Д 00266 Лаборант +35 60 CM Д 00267 Оператор +36 26 TS 00268 Плановые дата ивремя +Рисунок 4-8 Атрибуты сегмента OBR4.5.1.0 Определения полей сегмента OBRЭлементы сегмента, отмеченные в таблице знаком +, создаются не заказчиком, аисполнителем, который присваивает им значения, когда возвращает заказчикусегмент OBR как часть отчета о результатах выполненного исследования.Следовательно, когда исполнителю посылается новый заказ, эти поля не будутиметь значений, за исключением ситуации, когда заказ создается самимисполнителем. В этом случае номеру заказа у исполнителя будет присвоенозначение, а номер заказа у заказчика может быть пустым.Поля, отмеченные в таблице звездочкой (*), имеют смысл только тогда, когдаисследование связано с биоматериалом. Они заполняютсяприложением-заказчиком, если биоматериал получает заказчик, иприложением-исполнителем, если биоматериал получает исполнитель.Поля OBR-7-дата и время исследования и OBR-8-дата и время завершенияисследования представляют собой моменты времени психологического характера.Если для проведения исследования необходим биоматериал, они представляютмоменты начала и конца процедуры сбора биоматериала. Если исследованиепроизводится непосредственно над субъектом (например BP, рентгенография

грудной клетки), они представляют моменты начала и конца проведенияисследования.4.5.1.1 Порядковый номер запроса на выполнение исследований (SI)00237Определение: у первого переданного заказа порядковый номер должен быть равен1; у следующего заказа - 2, и т.д.4.5.1.2 Номер заказа у заказчика (CM) 00216Компоненты: ^Определение: это поле идентично полю ORC-2-номер заказа у заказчика .Первый компонент поля представляет собой строку длиной до 15 символов,идентифицирующую конкретный заказ (например OBR). Он присваиваетсязаказчиком (приложением, оформляющим заказ). Он идентифицирует данныйзаказ среди всех остальных, созданных данным приложением-заказчиком.Идентификатор приложения представляет собой строку длиной до шести (6)символов, которая однозначно определяет данное приложение. Учреждение илигруппа взаимодействующих учреждений должны создать единый списокприложений, которые могут быть потенциальными заказчиками и исполнителями, иприсвоить этим приложениям уникальные идентификаторы.Второй компонент является идентификатором приложения-заказчика. Двакомпонента отделяются друг от друга разделителем компонентов.4.5.1.3 Номер заказа у исполнителя (CM) 00217Компоненты: ^Определение: постоянный идентификатор заказа и всех связанных с нимисследований.Первый компонент представляет собой строку длиной до 15 символов,идентифицирующую конкретный сегмент заказа (например OBR). Онприсваивается исполнителем заказа (приложением, получающим заказ). Онидентифицирует данный заказ среди всех остальных, полученных даннымприложением-исполнителем (например клинической лабораторией).Второй компонент является идентификатором приложения-заказчика.Поле ORB-3-номер заказа у исполнителя идентично полю ORC-3-номер заказа уисполнителя.4.5.1.4 Универсальный идентификатор услуги (CE) 00238Компоненты: ^ ^ ^ ^ ^ Определение: код, идентифицирующий запрошенное исследование/комплекстестов. Эти коды могут задаваться местными соглашениями или быть“универсальными”. Целесообразнее использовать “универсальные” коды.Структура типа данных CE описана в разделе управления.4.5.1.5 Приоритет (ID) 00239Определение: не используется. Ранее это поле указывало приоритет заказа(STAT, ASAP и т.д.), однако в текущей версии эта информация передается вшестом компоненте поля OBR-27-количество/срок.4.5.1.6 Дата и время начала (TS) 00240Определение: не используется. Ранее это поле указывало дату и время началавыполнения заказа, однако в текущей версии эта информация передается вчетвертом компоненте поля OBR-27-количество/срок.

4.5.1.7 Дата и время исследования (TS) 00241Определение: клинически релевантные дата и время исследования. В случае,если исследование проводится непосредственно над субъектом, это полеозначает фактические дату и время получения исследования. Если исследуетсябиоматериал, то это поле должно содержать дату и время сбора или получениябиоматериала. (Данное поле относится к числу заполняемых после получениярезультатов, за исключением ситуации, когда заказчик или третья сторонаполучили биоматериал сами.)4.5.1.8 Дата и время завершения исследования (TS) 00242Определение: конечные дата и время выполнения исследования илипланируемого по времени сбора биоматериала. Если выполнение исследованиязанимает значительный промежуток времени, то это поле указывает моментзавершения выполнения исследования. Для моментальных исследований это поледолжно быть пустым. Данное поле относится к числу заполняемых послеполучения результатов, за исключением ситуации, когда заказчик или третьясторона получили биоматериал сами.4.5.1.9 Объем сбора (CQ) 00243Компоненты: ^ Определение: для лабораторных тестов это поле содержит объем биоматериала.По умолчанию единица измерения полагается равной ML (миллилитр). Единицыизмерения должны задаваться с помощью аббревиатур, указанных в стандартеISO (ISO-2955, 1977). Данное поле относится к числу заполняемых послеполучения результатов, за исключением ситуации, когда заказчик или третьясторона получили биоматериал сами. (Полная детальная информация о единицахизмерения приводится в главе 7.)4.5.1.10 Лицо, собравшее биоматериал (CN) 00244Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: если для проведения исследования необходим биоматериал, этополе идентифицирует лицо, отделение или учреждение, собравшее биоматериал.Либо идентификатор, либо фамилия, имя и отчество могут опускаться, но не обакомпонента сразу.4.5.1.11 Код действия с биоматериалом (ID) 00245Определение: означает действие, выполняемое с биоматериалом, сопутствующееили предшествующее выполнению данного заказа. Назначение этого поля -дальнейшее уточнение (если оно возможно) того действия, которое задано кодомуправления заказом, содержащимся в сопутствующем сегменте ORC. Например,если лаборатории посылается новый заказ (ORC-1-управление заказом = NW), тополе кода действия может содержат указание лаборатории. надо ли ей обеспечитьсбор биоматериала (значение кода действия L или O). Допустимые значения полясм. в таблице 0065 - код действия.ЗначениеAGLOPRSОписаниеДобавить заказанные тесты к существующему образцу биоматериалаПроизводный заказЛаборатории обеспечить сбор биоматериала у пациентаСбор биоматериала обеспечивается не лабораториейСбор биоматериала в процессе; заказ послан до его завершенияПересмотренный заказЗапланировать выполнение указанных ниже тестов

Таблица 0065 Код действия4.5.1.12 Код опасности (CE) 00535Компоненты: ^ ^ ^ ^ ^ Определение: код и/или текст, указывающий любую установленную илиподозреваемую опасность, исходящую от пациента или биоматериала, например упациента активная форма туберкулеза или биоматериал взят у пациента сгепатитом. Как код, так и текст могут отсутствовать. Однако код всегдапомещается в первый компонент, а текст во второй. Поэтому свободному текстубез кода должен предшествовать разделитель компонентов.4.5.1.13 Релевантная клиническая информация (ST) 00247Определение: здесь может быть помещена дополнительная клиническаяинформация о пациенте или биоматериале. Это поле используется для передачипредварительного диагноза и результатов клинических исследований в запросахна проведение интерпретируемых диагностических исследований. Примерамимогут служить количество вдыхаемой двуокиси углерода при анализе содержаниягазов в крови, число дней от начала последней менструации при анализе соскобаиз цервикального канала, а также другие условия. влияющие на интерпретациюрезультатов теста. Для некоторых заказов эта информация может быть послана вболее структурированном виде, используя ряд сегментов OBX (см. главу 7),указанных непосредственно за сегментом заказа.4.5.1.14 Дата и время получения биоматериала (TS) 00248Определение: если для проведения исследования необходим биоматериал, этополе означает фактический момент получения биоматериала диагностическойслужбой.4.5.1.15 Источник биоматериала(CM) 00249Компоненты: ^^^^Определение: область тела, которая служит источником биоматериала либоявляется предметом выполнения услуги.Первый компонент содержит название или код источника биоматериала (всоответствии с типом данных CE). (Даже в случае исследований, названиекоторых указывает на источник биоматериала, может потребоватьсядополнительное указание, например культура крови - сердечная кровь.)Второй компонент должен включать добавки к биоматериалу, например гепарин,EDTA или оксалат, если таковые делаются.Третий компонент, свободный текст, описывает способ сбора биоматериала, еслиэта информация является частью заказа. Если метод сбора логически связан срезультатом исследования, то его надо включать как сегмент результата.Четвертый компонент указывает область тела, которая служит источникомбиоматериала, а пятый компонент представляет собой его модификатор.Например, областью тела может быть локтевая ямка, а модификатором области -“правый”. Компоненты типа данных CE становятся субкомпонентами. Допустимыезначения см. в таблице 0070 - источник биоматериала.

Код Название Код Название Код НазваниеABS Абсцесс IT ИнтубационнаятрубкаSTONКаменьAMN Околоплодные воды LAM Ламелла STL ФекалииASP Аспират WBC Лейкоциты SWT ПотBPH Базофилы LN Стенка SNV СиновиальнаяжидкостьABLD Артериальная кровь LNA Стенка артерии TEAR СлезыBBL Кровяной пузырь LNV Стенка вены THRT ГорлоBON Кость LYM Лимфоциты THRB ТромбоцитыBRTH Дыхание MAC Макрофаги TISS ТканьBRO Бронхи MAR Костный мозг TISB Ткань костногомозгаBRN Ожог MEC Меконий TISG Ткань желчногопузыряCALC Конкремент MBLD МенструальнаякровьTISLТкань легкогоCDM Сердечная мышца MLK Молоко TISP Ткань брюшиныCNL Канюля MILK Грудное молоко TISU Ткань язвыCTP Наконечник катетера NAIL Ноготь TISC СоскобCSFСпинно-мозговаяжидкостьNOS Нос (носовой ход) TISPL Ткань плацентыCVM Цервикальная слизь ORH Прочий ULC ЯзваCVX Шейка матки PRT Транссудатбрюшной полостиUMBCOL Молозиво PER Брюшина URTH УретраCBLD Пуповинная кровь PLC Плацента UR МочаУмбиликальнаякровьCNJT Конъюнктива PLAS Плазма URC УрологическийзондCUR Curettageputum PLB Пузырь плазмы URT УрологическийкатетерCYST Киста PLR Плевральнаяжидкость(плевральнаяпункция)DRN Дренаж PMN ПолиморфоядерныенейтрофилыVOMBLDEAR Ухо PUS Гной BDY ТелоРвотные массыЦельная кровьELT Электрод SAL Слюна WICK ТампонENDC Эндокард SEM Жидкость спермы WND РанаENDM Эндометрий SER Сыворотка крови WNDA Абсцесс раныEOS Эозинофилы SKN Кожа WNDE Экссудат раныRBC Эритроциты SKM Скелетная мышца WNDD Дренаж раныFIB Фибробласт SPRM СперматозоидыFLT Фильтр SPT Мокрота

FIST Фистула SPTC Мокрота кашляFLU Жидкость тела,неуточн.SPTT Аспират мокротытрахеиGAST Желудочный сокGEN Половой органGENC МаткаGENL ЛохииGENV ВлагалищеHAR ВолосыТаблица 0070 Источник биоматериала4.5.1.16 Лицо, сделавшее заказ(CN) 00226Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентифицирует лицо, заказавшее тест. Значение поляOBR-16-лицо, сделавшее заказ то же, что у поля ORC-12-лицо, сделавшее заказ.4.5.1.17 Телефон для справок по заказу (TN) 00250Определение: номер телефона, по которому можно сообщить статус заказа илиего результат, в стандартном формате с расширением номера и/или числомгудков, если таковые должны присутствовать.4.5.1.18 Поле заказчика 1 (ST) 00251Определение: назначение поля задается пользователем. Текст, переданныйзаказчиком в этом поле, будет добавлен к возвращаемым результатам.4.5.1.19 Поле заказчика 2 (ST) 00252Определение: аналогично полю заказчика 1.4.5.1.20 Поле исполнителя 1 (ST) 00253Определение: назначение поля задается приложением-исполнителем(диагностическим подразделением) по своему усмотрению.4.5.1.21 Поле исполнителя 2 (ST) 00252Определение: аналогично полю исполнителя 1.4.5.1.22 Дата и время формирования отчета о результатах или изменениястатуса заказа (TS) 00255Определение: дата и время формирования отчета о результатах или изменениястатуса заказа. Это поле используется для указания момента времени, когдарезультаты были собраны в отчет и утверждены, или когда был введен илиизменен статус заказа (см. определение поля статус заказа). (Это полеотносится только к результатам.) Если другое приложение (напримерадминистративное приложение или приложение клинической базы данных)запрашивает у лабораторного приложения еще не переданные результаты, тоинформация из этого поля может быть использована для управления сеансомсвязи. Обычно приложению-заказчику нужны только те результаты, у которых датаи время формирования отчета позже даты и времени последних результатов,полученных запрашивающим приложением.4.5.1.23 Счет другому лечебному учреждению (CM) 00256

Компоненты: ^ Определение: счет за выполнение заказа (если необходим). Первый компонентпредставляет собой сумму в долларах, если она известнаприложению-исполнителю. Второй компонент представляет собой код оплаты,если он известен приложению-исполнителю. (Это поле относится только крезультатам.).4.5.1.24 Идентификатор участка диагностического подразделения (ID)00257Определение: участок диагностического подразделения, на котором выполненоисследование. Если исследование было выполнено внешней службой, здесьдолжен быть указан ее идентификатор. Допустимые значения см. в таблице 0074- идентификатор участка диагностического подразделения.Код Описание Код ОписаниеAU Аудиология OUS Ультразвуковая биометрия глазаBG Содержание газов в крови OT Цеховая терапияBLB Банк крови OTH ПрочиеCUS Исследования сердца: ультразвук OSL Внешняя лабораторияCTH Катетеризация сердца PHR АптекаCT Сканирование КТ (компьютерный PT Физиотерапиятомограф)CH Биохимия PHY Врач (история заболевания,диагнозы, выписной эпикриз ит.д.)CP Цитология PF ПульмонологияEC Электрокардиография (например RX РадиографияЭКГ, Холтер)EN Электронейрография (напримерЭЭГ)RUS Радиологическое ультразвуковоеисследованиеHM Гематология RC Лечение легочных пациентов(терапия)IMM Иммунология RT Радиационная терапияMB Микробиология SR СерологияMCB Микобактериология SP ГистологияMYC Микология TX ТоксикологияNMSСканирование ЯМР (ядерныймагнитный резонанс)VUSУльтразвуковое исследованиесосудовNMR Ядерный магнитный резонанс VR ВирологияNRS Сестринские измерения XRC РентгенокинематографияТаблица 0074 Идентификатор участка диагностического подразделения4.5.1.25 Статус результатов (ID) 00258Определение: статус результатов данного заказа. Статус характеризует всерезультаты (ALL), ассоциированные с данным заказом. Это поле обычно

используется в ответе на запрос статуса заказа, когда запрошенный уровеньдетализации ответа не включает сегменты OBX. Только приложение-исполнительможет присваивать значение этому полю.Если требуется получить сведения о статусе отдельного результата, то можновоспользоваться полем OBX-11-статус результатов исследования . Допустимыезначения см. в таблице 0123 - статус результатов .ISPОписаниеЗаказ получен; биоматериал еще неполученРезультатов пока нет; биоматериалполучен, исследование еще незавершеноРезультатов пока нет; выполнениеисследования запланировано, но ещене проведеноПредварительный: доступныпроверенные предварительныерезультаты, окончательныерезультаты еще не полученыЗначениеOЗначениеRFXYОписаниеРезультаты получены, ноеще не провереныОкончательныерезультаты; результатыполучены и проверены.Этот статус можноизменить только наскорректированныерезультатыРезультатов нет; заказотмененНет заказов на этот тест.(Используется только взапросах.)C Коррекция результатов Z Нет записи о данномпациенте. (Используетсятолько в запросах.)Таблица 0123 Статус результатов4.5.1.26 Результаты заказа-отца (CM) 00259Компоненты: ^ ^Определение: дается с таким расчетом, чтобы его можно было использовать и длядругих типов связей (например в токсикологии). Эта важная информация всочетании со значением поля OBR-29-номер заказа-отца однозначноидентифицирует сегмент результатов OBX заказа-отца, связанного с даннымзаказом. Значение этого сегмента OBX в результатах заказа-отца являетсяорганизм или химические субстанции, информация о которых сообщается врезультатах данного комплекса тестов. Если, к примеру, текущий комплекс тестовпредставляет собой исследования на чувствительность к антибиотикам, тосегмент результатов OBX, идентифицированный по заказу-отцу, содержитуказание на организм, для которого проводились проверки на чувствительность.Эта косвенная связь предпочтительнее, поскольку название организма врезультате заказа-отца может иметь различные предварительные значения доокончательного выявления.Третий компонент может использоваться для записи названия микроорганизма,непосредственно идентифицированного в результате заказа-отца. В этом случаеорганизм должен быть идентифицирован в точности так, как это сделано в

культуре заказа-отца.Это поле присутствует только в том случае, когда результат заказа-отцаидентифицируется значением поля OBR-29-номер заказа-отца. (Дополнительныедетали этой связи см. в главе 7.)Другой способ выражения этой информации связан с использованиемстандартного сегмента результатов исследований (OBX). Если присутствуетнесколько организмов, то для их различения используется полеOBX-4-дополнительный идентификатор. В этом случае первый сегмент OBX сдополнительным идентификатором N должен содержать значения об N-ммикроорганизме, а каждый последующий сегмент OBX с дополнительнымидентификатором N - результат теста га чувствительность этого организма кданному антибиотику.4.5.1.27 Количество/срок (TQ) 00221Компоненты: ^ ^ ^ ^ ^ ^ ^ ^ ^ Определение: информация о том, сколько услуг должно быть выполнено за одинпериод обслуживания, как часто должно повторяться выполнение этих услуг и накакой промежуток времени распространяется запрос на услуги. См. раздел 4.4.4.5.1.28 Лицо, получающее копию результатов (CN) 00260Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентифицирует лицо, которое должно получить копию результата.По местным соглашениям либо идентификатор, либо фамилия, имя и отчествомогут отсутствовать.4.5.1.29 Номер заказа-отца (CM) 00261Компоненты: ^ Определение: это поле идентично ORC-8-заказ-отец. Это поле связываетзаказ-потомок со своим отцом в ситуации, когда существует отношениеотцы-потомки. Например, в исследованиях, порожденных по результатампредыдущих исследований, скажем, в исследованиях чувствительностиантибиотиков, порожденные высеянными культурами крови, необходимо в этомполе указывать ссылку на заказ-отец (исследование культуры крови). Механизмотцов-потомков описан в примечаниях к полю управления заказом (см. примечанияк полям сегмента ORC в разделе 4.3.1.2.1). Если заказ является потомком другогозаказа, это поле является обязательным в сегменте.Номер заказа-отца состоит из двух компонентов. Первый компонент содержитномер заказа-отца у заказчика. Второй компонент является необязательным исодержит номер заказа-отца у исполнителя. Компоненты номеров заказа узаказчика и исполнителя преобразуются в субкомпоненты компонентов этого поля.4.5.1.30 Способ перемещения (ID) 00262Определение: каким образом перемещается пациент (если в этом естьнеобходимость). Допустимые значения см. в таблице 0124 - способ перемещения.ЗначениеCARTPORTОписаниеТележка - пациент перемещается на тележке или другомтранспортеИзмерительное устройство подвозится к месту пребыванияпациента

WALKWHLCПациент идет пешком в диагностическое отделениеКресло-каталкаТаблица 0124 Способ перемещения4.5.1.31 Причина исследования (CE) 00263Компоненты: ^ ^ ^ ^ ^ Определение: код или текст, используя соглашения для кодированных полей,изложенные в главе Управление/запросы (глава 2). Это поле требуется припроведении некоторых исследований для получения финансовой компенсации.4.5.1.32 Основной интерпретатор результатов (CM) 00264Компоненты: ^ ^ ^ Первый компонент описывает интерпретатора результатов (CN): & & & & & & & .Определение: идентифицирует врача или другого клинициста, которыйинтерпретирует выполненное исследование и несет ответственность засодержание документа, возвращаемого заказчику.4.5.1.33 Помощник интерпретатора результатов (CM) 00265Компоненты: ^ ^ ^ Первый компонент описывает помощника интерпретатора результатов (CN): & & & & & & & .Определение: клиницист, помогающий интерпретировать данное исследование.4.5.1.34 Лаборант (CM) 00266Компоненты: ^ ^ ^ Первый компонент описывает лаборанта (CN): & & & & & & & .Определение: лаборант, выполнивший исследование.4.5.1.35 Оператор (CM) 00267Компоненты: ^ ^ ^ Первый компонент описывает оператора (CN): & & & & & & & .Определение: оператор, который ввел в компьютер результаты исследования.4.5.1.36 Плановые дата и время (TS) 00268

Определение: дата и время, на которые исполнитель запланировал проведениеисследования, если таковые имеются (например в случае, когда код действия вполе OBR-11-действие с биоматериалом равен “S”). Это поле представляетсобой результат запроса на планирование конкретного теста и позволяетсообщить заказчику дату и время, на которые запланировано проведениеисследования (данное поле относится только к результатам.).4.5.2 Примеры использованияВ этом разделе показано, каким образом протокол ввода заказов можетиспользоваться в некоторых специфических ситуациях. Многоточия поставленывместо несущественных деталей. Для большей ясности приводятся комментарии,которым предшествуют символы //.4.5.2.1 Один заказ заменяется на три другихПредположим, что приложение с именем “PC” посылает заказ приложению EKGдля снятия трех ЭКГ в течение последовательных дней.Заказ может быть оформлен следующим образом:Сообщение ORM:MSH|...PID|...ORC|NW|A226677^PC||946281^PC|||N|3^QAM||198801121132|P123^АКВИТАНА^ЭЛЛНОР^””^ ““^””^MD|||4EAST// Заказ ЭКГOBR||||93000^EKG REPORT||||||||||||P030 ^ СМИТ ^ МАРТИН ^ ““^””^””^ MD|||||||||||3 ^ QAMBLG|...ORC||... // За этим заказом могут следовать другиеПервый компонент номера группы показывает, что создается группа заказов.Ответная реакция: поскольку приложение EKG должно преобразовать одинприведенный выше заказ в три заказа на три отдельные ЭКГ (услуги), торезультаты каждого из этих исследований должны возвращаться в отдельномсегменте OBR. В зависимости от флага ответа возможно несколько вариантовреакции:a) Если флаг ответа равен N (как в примере), то приложение-исполнитель EKGотвечает лишь, что оно получило заказ.”MSH|...MSA|...Отсюда вытекает лишь то, что заказ получен.Если бы флаг ответа имел значение E, то ответ мог бы оказаться тем жесамым, но тогда он означал бы, что приложение EKG обработало все заказыи их результаты доступны.b) Если бы флаг ответа имел значение R, то приложение-исполнитель EKGдолжно было бы сообщить приложению PC факт создания трехзаказов-потомков, опуская при этом все детали:MSH|...MSA|...ORC|PA|A226677^PC|89-458^EKG|94628^PCORC|CH|A226677^PC|89-551^EKG|94628... // Сегмент ORC первогопотомка.ORC|CH|A226677^PC|89-552^EKG|94628... // Сегмент ORC второгопотомка.ORC|CH|A226677^PC|89-553^EKG|94628... // Сегмент ORC третьегопотомка.... // За этим могут последовать другие части ответа.Этими сообщениями сказано: “Ваш заказ A226767 был расщеплен на тризаказа-потомка с именами 89-551, 89-552 и 89-553.” Обратите внимание, .чтономера заказа у заказчика во всех сегментах ORC заказов-потомковидентичны.

c) Если бы флаг ответа имел значение D, то приложение-исполнитель EKGдолжно было бы сообщить приложению PC факт замещения заказа, а такжеточные детали сегментов замещающих заказов:MSH|...MSA|...ORC|PA|A226677^PC|89-458^EKGORC|CH|A226677^PC|89-551^EKG|946282^PC|SC|A226677&PC^89-458&EKG|... ^^^^198901130500^ // Сегмент ORC первого потомкаOBR|||89-551^EKG|93000^Результаты ЭКГ |... // Сегмент OBRпервого потомкаORC|CH|A226677^PC|89-522^EKG|946282^PC|SC|A226677&PC^89-458&EKG|... ^^^^198901140500^ //Сегмент ORC второго потомкаOBR|||89-552^EKG|93000^Результаты ЭКГ|... //Сегмент OBR второгопотомкаORC|CH|A226677^PC|89-553^EKG|946282^PC|SC|A226677&PC^89-458&EKG|...^^^^198901150500^ // Сегмент ORC третьего потомкаOBR|||89-553^EKG|93000^Результаты ЭКГ|... // Сегмент OBRтретьего потомка// Могут следовать другие части сообщенияЗдесь добавились фактические сегменты OBR.Статус заказов-потомков возвращается равным SC (запланированы квыполнению).Поле ORC-4-количество/срок показывает, что снятие ЭКГ запланировано навремя после 0500 в последовательные дни.4.6 Заказы на диетпитаниеПищеблоку требуется получать некоторую специфическую информацию, наиболееважной является сам заказ на диетпитание. Ограничения диеты (частоназываемые кодом диеты) являются основными образующими блоками заказа надиетпитание.ORM Заказ на диетпитание ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 3[PV1] Информация о визите пациента 3]{ORC Общий сегмент заказа 4[{ODS}Заказ на диетпитание,дополнения и предпочтения 4[{NTE}] Примечания и комментарии (к сегменту ODS) 2{OBX Результаты 7[{NTE}]} Примечания и комментарии (к сегменту OBX) 2]}{[ORC Общий сегмент заказа 4{ODT} Инструкции по доставке пищи 4[{NTE}] Примечания и комментарии (к сегменту ODT) 2]}ORR Общее сообщение подтверждения ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2

[{NTE}] Примечания и комментарии (к сегменту MSA) 2[[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2{ORC Общий сегмент заказа 4[{ODS}] Заказ на диетпитание,дополнения и предпочтения 4[{NTE}] Примечания и комментарии (к сегменту ODS) 2}[{ORC Общий сегмент заказа 4[{ODT}] Инструкции по доставке пищи 4[{NTE}] Примечания и комментарии (к сегменту ODT 2}]]Сегмент ODS используется для того, чтобы обеспечить основное определениеодного кода диеты. Диетпитание может быть заказано как комбинация одного илинескольких спецификаций диеты, за которым следует любое число дополненийи/или предпочтений. Многие диеты являются общими для большого числаучреждений, например диета ADA 1500 ккал, и могут быть перечислены в таблице.Каждый код диеты представляет собой аббревиатуру длиной до шести символов.Сообщение заказа на диетпитание никогда не задает назначение более чем однойдиеты. Однако конкретный заказ на диетпитание может включать в себя указаниепрекратить одну диету и указать ее замещение другой диетой. В этом случаесообщение заказа на диетпитание должно содержать два сегмента ORC. Запервым сегментом ORC не будет следовать сегмент ODT. Спецификация доставкипищи может быть указана после второго сегмента ORC.Нередко весь заказ на диетпитание сводится к одному коду диеты. Код диетыопределяет, какую пищу может получать пациент. В тех ситуациях, когда пациентне имеет возможности выбирать отдельные блюда, назначение кода диетыэквивалентно заказу стандартных комплексов блюд. Чтобы пациент получал пищу,для него должен быть указан по крайней мере один код диеты.Дополнения диеты обеспечивают механизм заказа пациентом любогодополнительного блюда. Дополнения представляют собой блюда, которые даютсяпациенту независимо от кода его диеты. Эти блюда являются частью диетыпациента, которая не ограничивается любой другой частью заказа. Поэтому заказдополнений должен тщательно контролироваться с тем, чтобы избежатьполучение пациентом неподходящей или потенциально вредной для него пищи.Предпочтения представляют собой сведения о том, что нравится и что ненравится пациенту, какие требуются замены питания и его дополнения. Всущности, предпочтения представляют собой заказ на диетпитание, исходящий отпациента, но передаваемый в пищеблок от имени клинического отделения.Предпочтения могут изменяться. В эту версию стандарта включен механизмзадания предпочтений пациента. Предпочтения не зависят от заказа надиетпитание и не изменяются, если этот заказ поменялся. Однако в том случае,когда предпочтение нарушают условия назначенного диетпитания, выполнениеэтого предпочтения не разрешается.Существует дополнительная информация, необходимая для правильногофункционирования пищеблока, включая расписание доставки пищи,дополнительные порции, а также сообщения, связанные с доставкой порций и ихобработкой.В каждый момент времени для пациента может действовать только один заказ надиетпитание. Такой заказ состоит из кода диеты, дополнений и предпочтений,действительных на данный момент времени. Эти три спецификации определяют,какую пищу получит пациент. Обычно для диетпитания не задается время конца

заказа с тем, чтобы пациент в любом случае мог получить пищу (если только небыл передан заказ NPO).Коды диеты управляют питанием пациента двумя способами. Во-первых, естьблюда, которые просто не разрешены при данной диете. Во-вторых, некоторыедиеты включают в себя ограничения на обмен веществ, управляющие количествомопределенной пищи, которую может получать пациент. Некоторые коды диетыможно комбинировать при формировании конкретного заказа на диетпитание.Например диеты ADA 1500 и 2 грамма поваренной соли (NA2GM) могутсосуществовать, поскольку она не адресуются одному и тому же обмену веществ.Сочетание этих диет не приводит ни к конфликту, ни к наложению. Некоторыевиды кодов диет не могут сочетаться, например ADA 1500 и ADA 2000:невозможно кормить пациента, обеспечивая одновременно два разных уровнякалорийности. Эти ограничения не определены в таблице и зависят от смысловойнагрузки кодов диеты.Заказ задает полный набор блюд, который пациент может или должен получить вданном приеме пищи. (В зависимости от учреждения и заказа на диетпитаниепациент может иметь, а может и не иметь возможности выбора блюд. Напримердиета легких жидкостей нередко не дает возможности выбора, посколькуразрешенных в ней блюд очень немного.) Модификация диеты за счет добавлениякода диеты или дополнения может оказать существенное влияние на пищу,которую может получать пациент. В связи с этим любая модификация кодов диетыили дополнений должна оформляться в виде нового заказа. Следовательно, изпредыдущего заказа можно брать коды диеты или дополнения, которые будутприменимы и к новому заказу. Предположим, к примеру, что пациенту назначениядиета ADA 1500 ккал и вечерний прием порции снятого молока. Если к этой диетенадо добавить ограничение поваренной соли (2 грамма), то надо послать заказ скодами диеты ADA 1500 ккал и 2 грамма поваренной соли с дополнением в видепорции снятого молока. Если не сделать этого, то приложение пищеблока должнорассматривать новый заказ только как на диету с ограничением солевого обменадо 2 граммов. Этот метод позволяет тщательно отслеживать цепочки заказов надиетпитание и избегать неоднозначностей в их интерпретации.4.6.1 Сегмент ODS -заказ диеты, дополнений и предпочтенийПоследовательность элементов сегмента ORC, представляющая интерес приобсуждении структуры сегмента ODS, включает в себя поля ORC-1-управлениезаказом, ORC-2-номер заказа у заказчика, ORC-3-номер заказа у исполнителя,ORC-7-количество/срок, ORC-9-дата и время трансакции, ORC-10-лицо,которое ввело заказ и ORC-11-лицо, которое проверило заказ . При заказах надиетпитание поле ORC-1-управление заказом может принимать значения Новыйзаказ (NW), Запрос на отмену заказа (CA), Запрос на прекращение выполнениязаказа (DC), Запрос на изменение заказа (XO), Запрос на приостановкувыполнения заказа (HD) и Продолжить приостановленное выполнение заказа(RL). С помощью кодов HD и RL можно запрашивать приостановку выполненияуслуги на заданный промежуток времени. Поле ORC-4-количество/срок должноиспользоваться для задания того, является ли выполнение заказа непрерывнымили оно относится только к одному периоду обслуживания. Оно полезно длядополнений, которые хотя и являются частью заказа на диетпитание, но могутдаваться, скажем, только вечером каждого дня. Например:|1^QPM^^19910415|.П/П ДЛИНА ТИП О/Н ПОВТ/ # ТАБЛ# ЭЛЕМ# НАЗВАНИЕ ЭЛЕМЕНТА1 1 ID О 0159 00269 Тип2 60 CE Д/10 00270 Период обслуживания3 60 CE О Д/20 00271 Код диеты, дополненияили предпочтения4 80 ST Д/2 00272 Текст инструкции

Рисунок 4-9 Атрибуты сегмента ODS4.6.1.0 Определения полей сегмента ODSТип (ID) 00269Определение: задает тип диеты. Допустимые значения см. в таблице 0159-типдиеты.ЗначениеDSPОписаниеДиетаДополнениеПредпочтениеТаблица 0159 Тип диетыПериод обслуживания (CE) 00270Компоненты: ^ ^ ^ ^ ^ Определение: если это поле пусто, то модификатор применяется ко всемпериодами обслуживания. К примеру, заказы на диетпитание распространяются.как правило, на все периоды обслуживания. Это поле обычно используется приуказании дополнений. Оно позволяет задать модификацию для одного илинескольких периодов обслуживания в течение дня путем сочетания спецификацийуслуг. Периоды обслуживания имеют тип данных CE, определяемый местнымисоглашениями, и обычно принимают числовые значения. Рекомендуемые значениятаковы:• период обслуживания 1 - завтрак;• период обслуживания 2 - второй завтрак;• период обслуживания 3 - обед;• период обслуживания 4 - полдник;• период обслуживания 5 - ужин;• период обслуживания 6 - закуска перед сном.Пример: |1~5| означает период обслуживания 1 и период обслуживания 5 всоответствии с местными определениями этих периодов.Код диеты, дополнения или предпочтения (CE) 00271Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор элемента заказа для пациента; по своей функцииэто поле эквивалентно полю OBR-4-универсальный идентификатор услуги.Поскольку сегмент ODS может повторяться, различные элементы будутзадаваться в различных сегментах. Пример:

|^REG^L&FD7|, |023^^L&FD6|, |^NOLACT^L&FD5|, |^TUBEFD^L&FD4|, и|011^HIPRO100^L&FD1~123^LOFAT20^L&FD1|В случае, если этот сегмент запрашивает дополнение к диете, то есть полеODS-1-тип = S, то этот атрибут задает конкретный элемент или класс элементов.Если в учреждении предпочтения пациентов (P) закодированы, то они такжепередаются как кодируемый сегмент; в противном случае информация опредпочтениях должна передаваться в виде текста в описанном ниже четвертомкомпоненте сегмента ODS.Текст инструкции (ST) 00272Определение: специфическая инструкция для пищеблока. Такие инструкции могутсодержать указания на специфические нужды пациента, например потребность водиночестве. Инструкции заказчика питания передаются в этом поле каксвободный текст. Он может представлять собой полную инструкцию пищеблокуили указывать дополнительную информацию.4.6.2 Сегмент ODT -инструкции по доставке пищиЭтот сегмент содержит инструкции по доставке пищи. Они не зависят от кодовдиеты, дополнений и предпочтений и потому имеют отдельные номера заказа.П/П ДЛИНА ТИП О/Н ПОВТ/ # ТАБЛ # ЭЛЕМ # НАЗВАНИЕЭЛЕМЕНТА1 60 CE О 0160 00273 Тип доставки2 30 CE Д/10 00270 Периодобслуживания3 80 ST 00272 Текст инструкцииРисунок 4-10 Атрибуты сегмента ODT4.6.2.0 Определения полей сегмента ODTТип доставки (CE) 00273Компоненты: ^ ^ ^ ^ ^ Определение: задает тип доставки пищи пациенту. Допустимые значения см. втаблице 0160 - тип доставки.ЗначениеEARLYLATEGUESTNOMSGОписаниеРанняя доставкаПоздняя доставкаТребуется посторонняя помощьБез доставкиТолько сообщение о доставкеТаблица 0160 Тип доставки

Спецификации доставки полезны в ситуации, когда назначенная пациентупроцедура приходится на нормальное время приема пищи. Они могут бытьиспользованы также для предоставления питания на вынос, в случаях, когдадоставка не требуется, а также для передачи сообщений. Значение MSG означает,что сегмент ODT задает не тип доставки, а дополнительные инструкции к ужезаказанному типу доставки. Эту информацию можно взять из поля ODT-3-текстинструкций.Период обслуживания (CE) 00274Компоненты: ^ ^ ^ ^ ^ Определение: если это поле пусто, то способ доставки относится ко всемпериодами обслуживания. Оно позволяет указать один или несколько периодовприема пищи в течение дня путем сочетания кодов периода. Это поле можеткомбинироваться с количеством/сроком для указания на то, какой периодобслуживания связан с заказом. Это поле имеет тот же смысл, что и полеODS-2-период обслуживания. Другие детали см. в разделе 4.6.1.2.Текст инструкции (ST) 00272|ПЛАСТИКОВЫЙ СТОЛОВЫЙ ПРИБОР|.Определение: инструкции, связанные со способом доставки. Пример:4.6.3 Пример сообщений заказа на диетпитаниеНиже показана типичная последовательность заказов на диетпитание дляхирургического пациента:4.6.3.1 Первый заказ:MSH|...PID|...ORC|NW|1235^NURS|||||^^^199108021700||199108021200|^HRF|^MFW|ODS|D||^DB15^L&DO3|ODS|D||^NA2GM^L&DO3|Приостановить первый заказ:MSH|...PID|...ORC|HL|1235^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|Заказ NPO с питанием, требующим посторонней помощи:MSH|...PID|...ORC|NW|1236^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|ODS|D||^NPO^L&DO3|ORC|NW|1244^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|ODT|GUEST|5^^L&CBD|Легкое жидкое питание с посторонней помощью:MSH|...PID|...ORC|DC|1236^NURS|||||^^^199108041700||199108041200|^HRF|^MFW|ORC|NW|1237^NURS|||||^^^199108041700||199108041200|^HRF|^MFW|ODS|D||^DB15^L&DO3|ODS|D||^NA2GM^L&DO3|ODS|D||^CLRLIQ^L&DO3|ORC|NW|1245^NURS|||||^^^199108041700||199108041200|^HRF|^MFW|ODT|GUEST|5^^L&CBD|Жидкое питание с посторонней помощью:MSH|...PID|...ORC|DC|1237^NURS|||||^^^199108051700||199108051200|^HRF|^MFW|ORC|NW|1238^NURS|||||^^^199108051700||199108051200|^HRF|^MFW|ODS|D||^DB15^L&DO3|ODS|D||^NA2GM^L&DO3|

ODS|D||^FULLIQ^L&DO3|ORC|NW|1246^NURS|||||^^^199108051700||199108051200|^HRF|^MFW|ODT|GUEST|3^^L&CBD|Отменить приостановку предыдущего заказа и дать сообщение о выписке:MSH|...PID|...ORC|DC|1238^NURS|||||^^^199108061700||199108061200|^HRF|^MFW|ORC|RL|1235^NURS|||||^^^199108061700||199108061200|^HRF|^MFW|ORC|NW|1247^NURS|||||^^^199108061700||199108061200|^HRF|^MFW|ODT|MSG|5^^L&CBD|Вас выпишут завтра |4.6.3.2 Сложный заказБазовая диета: высокое содержание белка, низкое жиров. Дополнениями служатмороженое в 4-й период обслуживания и половина бутерброда с ветчиной в 6-йпериод обслуживания. Имеются также заказы на раннюю доставку в период 1,позднюю в период 3, и питание с посторонней помощью в обед.MSH|...PID|...ORC|NW|1234^NURS|||||^^^199108021700||199108021200|^HRF|^MFW|ODS|D||011^HIPRO100^L&FD1|ODS|D||123^LOFAT20^L&FD1|ODS|S|4|119^МОРОЖЕНОЕ^L&FD8|ODS|S|6|320^1/2 БУТЕРБРОДА С ВЕТЧИНОЙ^L&FD8|ORC|NW|1244^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|ODT|EARLY|1^^L&CBD|ORC|NW|1245^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|ODT|LATE|3^^L&CBD|ORC|NW|1246^NURS|||||^^^199108031700||199108031200|^HRF|^MFW|ODT|GUEST|^ОБЕД^L&CBD|4.6.3.3 Питание через трубкуВ этом заказе указаны Similac с маслом MCT и добавки полисахаров.MSH|...PID|...ORC|NW|1232^NURS|||||60^Q3H^^199108021700||199108021200|^HRF|^MFW|ODS|D||010^SIMILAC^L&DO1|ODS|D||011^MCT^L&DO1|ODS|D||012^ПОЛИСАХАРА^L&DO1|4.6.3.4 Предпочтения пациентаВ этом заказе указано, что пациент - вегетарианец.MSH|...PID|...ORC|NW|1232^NURS|||||60^Q3H^^199108021700||199108021200|^HRF|^MFW|ODS|D||123^LOFAT20^L&FD1|ODS|S|4|119^МОРОЖЕНОЕ^L&FD8|ODS|P||^^^ВЕГЕТАРИАНЕЦ|4.7 Заказы на расходуемые материалыДля заказа медицинских, хирургических расходуемых материалов, а такжепредметов ухода за пациентами используется сегмент деталей требования RQD(Requisition Detail). Предполагается, что учет этих материалов осуществляетсясистемой управления запасами, которая ведет справочно-нормативную базуноменклатуры всех материалов, используемых в больнице.Существуют два основных типа запасов, которые обычно называются складскимии внешними.Складские запасы, как на то указывает их название, хранятся в больнице вспециально отведенных для этого местах, например в пакгаузе, на центральномскладе, в складских комнатах на этажах, в операционной.При затребовании складских запасов приложению-отправителю заказа достаточнолишь указать соответствующую информацию в сегменте RQD. Предполагается,

что эта информация позволяет приложению-получателю однозначноидентифицировать запрашиваемый предмет. Если приложение-отправитель неуверено, что предмет находится на складе, то оно может в дополнение к сегментуRQD послать сегмент RQ1. В этом случае, как правило, для запрашиваемогопредмета дается описание в виде свободного текста.Внешние запасы не хранятся в больнице и должны заказываться у внешнегопоставщика или производителя.Если приложение-заказчик знает, что ему требуются внешние запасы, то оно такжеможет послать сегмент RQ1 в дополнение к сегменту RQD при условии, что покрайней мере одно поле сегмента RQ1 известно приложению-отправителю. Этоможет оказаться необходимым для того, чтобы приложение-получатель моглоправильно определить, где можно найти эти запасы. При этомприложение-получатель может опираться на развитую базу данных, содержащуюисторию требований приложения-отправителя.Заказы на складские запасы используют сообщение ORM. Сегмент RQDследующим образом заменяет сегмент деталей заказа в сообщении ORM:ORM Сообщение требования на складские запасы ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 3[PV1] Визит пациента 3]{ORC Общий заказ 4[RQD Детали требования 4[{NTE}] Примечания и комментарии (к сегменту RQD) 2[{OBX Исследование/результат 7[{NTE}] Примечания и комментарии (к результатам) 2}]][BLG] Сегмент оплаты 4}ORR Общее сообщение подтверждения заказа ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[[PID Идентификация пациента 3[{NTE}]]Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4RQD Детали требования 4[{NTE}] Примечания и комментарии (к сегменту RQD) 2}]Требования на внешние запасы используют сообщение ORM. При этом сегментдеталей в описании сообщения ORM следующим образом замещается на парусегментов RQD, RQ1:ORM Сообщение требования на складские запасы ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2

[PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 3[PV1] Визит пациента 3]{ORC Общий заказ 4[RQD Детали требования 4[RQ1] Детали требования-1 4[{NTE}] Примечания и комментарии (к сегменту RQD) 2[{OBX Исследование/результат 7[{NTE}] Примечания и комментарии (к результатам) 2}]][BLG] Сегмент оплаты 4}ORR Общее сообщение подтверждения заказа ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4RQD Детали требования 4[RQ1] Детали требования-1 4[{NTE}] Примечания и комментарии (к сегменту RQD) 2}]4.7.1 Сегмент RQD - детали требованияСегмент RQD содержит детальные сведения о каждом запрашиваемом предмете.См. сделанные выше предположения.П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАЗВАНИЕ ЭЛЕМЕНТА1 4 SI 00275 Номер строкитребования2 60 CE 00276 Код предмета -внутренний3 60 CE 00277 Код предмета - внешний4 60 CE 00278 Больничный кодпредмета5 6 NM 00279 Затребованноеколичество6 60 CE 00280 Затребованныеединицы измерения7 30 ID 00281 Код расчетного центраподразделения8 30 ID 00282 Бухгалтерский код

оплаты9 60 CE 00283 Пункт доставки10 8 DT 00284 Требуемая датаполученияРисунок 4-11 Атрибуты сегмента RQD4.7.1.0 Определения полей сегмента RQDНомер строки требования (SI) 00275Определение: номер, который идентифицирует строку требования.Код предмета - внутренний (CE) 00276Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор и описание требуемого предмета, однозначноидентифицирующее его для приложения-отправителя..Код предмета - внешний (CE) 00277Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор и описание требуемого предмета, однозначноидентифицирующее его для приложения-получателя..Больничный код предмета (CE) 00278Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор и описание требуемого предмета, однозначноидентифицирующее его для всех приложений больницы. Обычно перечень такихидентификаторов ведется больничной административно-финансовой системой всправочно-нормативном файле прейскурантов.Примечание: по крайней мере одно из трех полей с 4.7.1.2 по4.7.1.4 должно быть не пустым.Затребованное количество (NM) 00279Определение: затребованное количество предметов.Затребованные единицы измерения (CE) 00280Компоненты: ^ ^ ^ ^ ^ Определение: единицы измерения, в которых выражается затребованноеколичество.Код расчетного центра подразделения (ID) 00281Определение: код расчетного центра, который используется бухгалтерией дляучета расходов данного подразделения на затребованный предмет.Бухгалтерский код оплаты (ID) 00282

Определение: бухгалтерский код, который используется для учета оплаты заданный предмет.Пункт доставки (CE) 00283Компоненты: ^ ^ ^ ^ ^ Определение: уникальный идентификатор и описательное наименованиеподразделения/пункта, куда надо доставить затребованные предметы.Требуемая дата получения (DT) 00284Определение: дата, когда необходимо получить затребованные предметы.Примечание: Хотя из одно из этих полей не являетсяобязательным, для успешной обработки запросаприложением-получателем необходимо, чтобы из трехидентификаторов (код предмета - внутренний, код предмета -внешний, больничный код предмета) хотя бы один был указан.На усмотрение разработчика оставляется определение того, какой из кодовдолжен использоваться для обеспечения взаимодействия приложений. СтандартHL7 рекомендует использовать поле RQD-4-больничный код предмета.Больничной бухгалтерии требуется идентификатор, который используется длятого, чтобы выставить счет за затребованные предметы подразделению илипациенту. Если оплата за требование должна быть осуществлена пациентом, тоэтот идентификатор берется из сегмента идентификации пациента (PID), впротивном случае надо использовать поля RQD-7-код расчетного центраподразделения и RQD-8-бухгалтерский код оплаты. Рекомендуется, чтобыфинансовый код “конечного” подразделения, отвечающего за использованиезатребованных предметов, включался в сегмент даже в том случае, когда указанаидентификация пациента.Приложения больничной бухгалтерии используют сочетание значения поляRQD-7-код расчетного центра подразделения и поля RQD-8-бухгалтерский кодоплаты, чтобы отправить эту трансакцию в Главную книгу. Это сочетание должносоответствовать допустимому счету или субсчету в бухгалтерских приложениях,ведущих план счетов.4.7.2 Сегмент RQ1 - детали требования-1Сегмент RQ1 содержит дополнительные детали для каждого затребованноговнешнего предмета. Определение этого сегмента спарено с предшествующимсегментом RQD.П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАЗВАНИЕ ЭЛЕМЕНТА1 10 ST 00285 Ориентировочная цена2 60 CE 00286 Идентификаторпроизводителя3 16 ST 00287 Номер в каталогепроизводителя4 60 CE 00288 Идентификаторпоставщика5 16 ST 00289 Номер в каталогепоставщика6 1 ID 00290 Налогообложение7 1 ID 00291 Разрешение замены

Рисунок 4-12 Атрибуты сегмента RQ14.7.2.0 Определения полей сегмента RQ1Ориентировочная цена (SI) 00285Определение: справочная цена предмета в расчете на единицу измерения,известная затребовавшему предмет приложению. Она может быть, а может и небыть фактической ценой приобретения предмета у поставщика. Она также неявляется ценой, которая войдет в счет пациенту.Идентификатор производителя (CE) 00286Компоненты: ^ ^ ^ ^ ^ Определение: уникальный код, который идентифицирует производителяприложению, получающему требование.Коды могут быть взяты из справочников HIBCC Manufacturer's Labeler ID Code(LIC), UPC или NDC. Эти наборы кодов могут быть получены от одной изсоответствующих организаций, чьи адреса приведены на рис. 2-3 (раздел 2.4.5.17).Номер в каталоге производителя (ST) 00287Определение: номер или код предмета в каталоге производителя.Идентификатор поставщика (CE) 00288Компоненты: ^ ^ ^ ^ ^ Определение: уникальный код, который идентифицирует поставщика приложению,получающему требование.В связи со сказанным рекомендуется, чтобы каждый внешний предмет имелзаполненные поля RQ1-2-идентификатор производителя и RQ1-3-номер вкаталоге производителя или RQ1-4-идентификатор поставщика и RQ1-5-номерв каталоге поставщика. Возможна ситуация, когда затребовавшее внешнийпредмет приложение не знает коды, по которыи предмет числится в каталогепроизводителя или поставщика. В этом случае важно, чтобы в указанные вышекодированные поля был включен текстовый компонент с описанием предмета.Номер в каталоге поставщика (ST) 00289Определение: номер, название или код предмета в каталоге поставщика.Налогообложение (ID) 00290Определение: связано ли приобретение данного предмета с уплатой налогов?Обычно список затребованных внешних предметов печатаетсяприложением-получателем и затем обрабатывается человеком. Другими словами,человек должен связаться с поставщиком или производителем, чтобы получитьцены и другую связанную с покупкой информацию прежде чем передать заказвнешнему поставщику. См. таблицу 0136 - индикатор Да/Нет, определенную вглаве 2.Разрешение замены (ID) 00291Определение: указывает, имеет ли вспомогательное подразделение правозаменить заказанный предмет на его эквивалент. См. таблицу 0136 - индикатор

Да/Нет, определенную в главе 2.4.7.3 Примеры использования сегментов RQD и RQ1a) Первый пример представляет собой требование на два предмета дляпациента Джона Дж. Смита, передаваемое приложением ORSUPPLYприложению MMSUPPLY. Один из предметов (раствор для внутривенноговливания) может быть взят из складских запасов, а второй предмет -имплантант - является внешним и производится фирмой Detter. Требованию,сформированному приложением ORSUPPLY, присвоен номер RQ101.MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||ORM|100|P|2.2||PID|||100928782^9^MOD11|3781928|Смит^Джон^Дж||19690424|M|||||||||A|...100928782^4^MOD11||ORC|NW|RQ101^ORSUPPLY||||N|||19911105130000|jjones^Джонс^Джейн|sgomez^Гомез^...|MAINOR^2W|X2304RQD|1|1234^Соляной раствор, 2.25% ||S1786^Соляной раствор|1|BT^Бутылка|1234-5678|...ORSUP^Склад операционной |19901123RQD|2|23455^Имплантант, специальныйбедренный||I45323^Имплантант|1|EA^ Каждый|1234-5678|...ORSUP^Склад операционной|19901123RQ1|123.45|DET^Detter, Inc.|444456|DST^Local Distributors,Inc.|333-456|Nb) Второй пример представляет собой требование на пять складскихпредметов, предназначенных для пополнения запасов в подсобкеоперационной, передаваемое приложением ORSUPPLY приложениюMMSUPPLY. Требованию, сформированному приложением ORSUPPLY,присвоен номер RQ102.MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105152034||ORM|100|P|2.2||ORC|NW|RQ102^ORSUPPLY||||N|||19911105150100|jjones^Джонс^Джейн|sgomez^Гомез^Сьюзе...|MAINOR^2W|X2304RQD|1|1232^Солевой раствор, 1% ||S1784^Солевойраствор|5|BT^Бутылка|1234-5678|...ORSUP^Склад операционной|19901105RQD|2|1231^Солевой раствор, 0.2%||S1781^Солевойраствор|2|BT^Бутылка|1234-5678|...ORSUP^Склад операционной|19901105RQD|3|2342^Хирургическая нить, черный шелк ||SU123^Хирургическаянить|2|DZ^Дюжина|1234-5678|...ORSUP^Склад операционной|19901105RQD|4|2344^Хирургическая нить, черный шелк 3-0||SU124^Хирургическаянить|1|DZ^Дюжина|1234-5678|...ORSUP^Склад операционной|19901105RQD|5|4565^Бандаж, 4x4||B6345^Бандаж |3|BX^Коробка|1234-5678|...ORSUP^Склад4.8 Заказы на лекарства4.8.1 Сообщение ORM - рецепт для аптекиORM Рецепт для аптеки ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 2[PV1] Информация о визите пациента 3]{ORC Общий заказ 4[RXO Рецепт для аптеки 4

[{NTE}] Примечания и комментарии (к сегменту RXO) 2{RXR} Способ приема 4[{RXC} Аптечный компонент 4[{NTE}] Примечания и комментарии (к сегменту RXC) 2][{OBX Результаты 7[{NTE}] Примечания и комментарии (к сегменту OBX) 2}]][BLG] Информация об оплате 6}4.8.2 Сообщение ORR: ответ аптеки:ORR Описание ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии(к заголовку ответа) 2[[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4[RXO Рецепт для аптеки 4[{NTE}] Примечания и комментарии (к сегменту RXO) 2{RXR} Способ приема 4[{RXC}] Аптечный компонент 4[{NTE}] Примечания и комментарии (к сегменту RXC) 2]}]4.8.3 Сегмент RXO - рецепт для аптекиЭто “основной” сегмент заказа в аптеку. Он содержит общие данные заказа, неспецифические для компонентов или добавок. В отличие от сегмента OBR, он несодержит полей статуса заказа или других данных, типичных только длярезультатов.Он может использоваться для любого вида заказов в аптеку, включая заказы длягоспитализированных пациентов (с отпуском в разовой дозе или смешаннойразовой дозе), амбулаторных пациентов, растворы для внутривенного вливания, атакже растворы для полностью парентерального питания.Кроме фармацевтической информации этот сегмент содержит дополнительныеданные, например информацию о лечащем враче и текстовые комментарии.Поле количество/срок не требуется в сегменте RXO. Сегмент ORC содержит полеORC-7-количество/срок исходного заказа в том виде, как оно было затребовано.Его значение не изменяется при кодировании заказа, отпуске или приемелекарства.П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАЗВАНИЕ ЭЛЕМЕНТА1 100 CE О 00292 Затребованный кодпринимаемоголекарства2 20 NM О 00293 Затребованное

количествопринимаемоголекарства -минимальное3 20 NM Н 00294 Затребованноеколичествопринимаемоголекарства -максимальное4 60 CE О 00295 Затребованныеединицы принимаемоголекарства5 60 CE Н 00296 Затребованная формадозировки6 200 CE Н Д 00297 Указания лечащеговрача аптеке7 200 CE Н Д 00298 Указания лечащеговрача по приему8 12 CM У 00299 Место доставки9 1 ID Н 00300 Разрешение замены10 100 CE У 0161 00301 Затребованный кодотпускаемого лекарства11 20 NM У 00302 Затребованноеколичествоотпускаемого лекарства12 60 CE У 00303 Затребованныеединицы отпускаемоголекарства13 3 NM Н 00304 Число повторенийзаказа14 60 CN У 00305 Номер лечащего врача,сделавшего заказ,согласно системе DEA15 60 CN У 00306 Идентификаторфармацевта,утвердившего заказ16 1 ID Н 00307 Необходимостьособого внимания17 20 ST У 00308 Затребованныйинтервал приема(единица времени)Рисунок 4-13 Атрибуты сегмента RXO4.8.3.0 Определения полей сегмента RXOЗатребованный код принимаемого лекарства (CE) 00292Компоненты: ^ ^ ^ ^ ^

альтернативной системы кодирования>Определение: идентификатор медицинской субстанции, которая должна бытьпринята пациентом; по своим функциям это поле эквивалентно полюOBR-4-универсальный код услуги. Поля требования на отпуск, определяющие види количество того, что должен принять пациент (см. поля RXO-10-затребованныйкод отпускаемого лекарства, RXO-11-затребованное количество отпускаемоголекарства и RXO-12-затребованные единицы отпускаемого лекарства) необязательно коррелируют с инструкциями о том, какое количество должно быть“дано”, или принято пациентом с каждой дозой и могу быть, а могут и не бытьуказаны в заказе. Например, в той части заказа, которая относится к “приему”,может быть передано указание давать 15 мг либриума каждые 6 часов, в товремя как в части заказа, относящейся к отпуску, может содержаться указаниеотпустить 30 таблеток по 10 мг аналога лекарства, заказанного в этомрецепте для амбулаторного пациента. Если в код для приема не входит формадозировки, используйте поле RXO-5-затребованная форма дозировки.Затребованное количество принимаемого лекарства - минимальное (NM)00293Определение: заказанное количество. В заказе с переменной дозой онорассматривается как минимальное заказанное количество. С заказах снеизменяющейся дозой это количество представляет собой точное количествозаказа.Примечание: это поле не дублирует первый компонент поляколичества/срока, поскольку в заказах, не относящихся к аптеке,этот компонент может использоваться для задания кратныхзаказанному количеству.Выражая сказанное другими словами, для заказов в аптекукомпонент количества поля количества/срока относится к тому, чтодолжно быть принято пациентом в каждом интервале обслуживания;таким образом, в терминах заказов RX, первый компонент поумолчанию должен равняться 1. Следовательно, при фактическомвыполнении заказа значение 1 первого компонента поляколичества/срока всегда относится к одному приему лекарства вколичестве, указанном в данном поле (поле затребованногоколичества принимаемого лекарства).Затребованное количество принимаемого лекарства - максимальное (NM)00293Определение: В заказе с переменной дозой это поле рассматривается какмаксимальное заказанное количество. С заказах с неизменяющейся дозой этополе не используется.Затребованные единицы принимаемого лекарства (CE) 00295Компоненты: ^ ^ ^ ^ ^ Определение: единицы, в которых исчисляется количество принимаемоголекарства.Примечание: эти единицы могут быть “составными”, напримермогут содержать слова “в расчете на”. Скажем, микрограммы накилограмм (мкг/кг) являются допустимым значением и означают, чтоединицами служат микрограммы на кг (веса тела). Полный переченьединиц измерения в расширенном стандарте ISO+ см. в главе 7.Для определения стандартных аббревиатур составных единиц необходимо иметьсоответствующую таблицу. Пока такая таблица не будет согласована между всеми

сторонами, в каждой системе необходимо иметь пользовательскую таблицуединиц. Если интерпретация составной единицы требует знания некоторыхрезультатов исследований (например веса тела или роста), эти результаты могутбыть переданы в том же сообщении, используя необязательные сегменты OBX.Затребованная форма дозировки (CE) 00296Компоненты: ^ ^ ^ ^ ^ Определение: используется, если оба поля RXO-1-затребованный кодпринимаемого лекарства и RXO-10-затребованный код отпускаемого лекарстване содержат указания лекарственной формы.Указания лечащего врача аптеке (CE) 00297Определение: указания лечащего врача аптеке в виде свободного текста.Указания лечащего врача по приему (CE) 00298Определение: указания лечащего врача пациенту или медицинскому работнику,выполняющему лекарственное назначение, в виде свободного текста.Место доставки (CM) 00299Компоненты: ^ Определение: первый компонент содержит место размещениягоспитализированного или амбулаторного пациента, в которое аптека должнаотправить лекарство (если это требуется). По умолчанию (пустое) значениесоответствует текущему размещению пациенте (согласно системе учета коечногофонда). Таблица возможных значений зависит от местных соглашений. Этоткомпонент имеет ту же форму, что и поле PV1-3-место, закрепленное запациентом.Второй компонент может быть использован для указания адреса. Этот адресможет быть использован для заполнения шаблонов писем с ответом пациенту илилечащему врачу, или для выставления счета за помощь, оказанную на дому.Разрешение замены (ID) 00300Определение: допускаются следующие значения:ЗначениеNGTОписаниеЗамена не санкционирована (это значениеиспользуется по умолчанию)Допускается замена на синонимДопускается замена на терапевтический аналогТаблица 0161 Разрешение заменыПримечания к полям требования к отпуску:Иногда заказы бывают такими, что общее количество запрошенного для отпускалекарства не имеет прямой связи с дозами приема и расписанием приема. Например,заказ в аптеку для амбулаторного пациента может звучать принимать по четыретаблетки в день , Q6H (через каждые 6 часов) --отпустить 30 таблеток. Заказ в аптеку для госпитализированного пациента можетзвучать NS/D5W (нормальный солевой раствор с 5% декстрозы) по 1000 cc/час --

отпустить 3 бутылки по 1 литру раствора NSD5W. Поля требования к отпускуобеспечивают возможность подобного распространенного стиля заказов.Затребованный код отпускаемого лекарства (CE) 00301Компоненты: ^ ^ ^ ^ ^ Определение: что было или что должно быть отпущено; по функциям это полеэквивалентно полю OBR-4-универсальный идентификатор услуги. В зависимостиот приложения оно может присутствовать, а может и не присутствовать в заказе.Если оно отсутствует, а полям RXO-11-затребованное к отпуску количество иRXO-12-затребованные к отпуску дозы присвоены значения, то для данного поляподразумевается значение RXO-1-код лекарства, затребованного для приемапациентом. Если код затребованного к отпуску лекарства не содержит формудозировки, используется поле RXO-5-затребованная форма дозировки.Затребованное количество отпускаемого лекарства (NM) 00302Определение: количество, которое должно быть отпущено.Затребованные единицы отпускаемого лекарства (CE) 00303Компоненты: ^ ^ ^ ^ ^ Определение: единицы, в которых исчисляется количество отпускаемоголекарства. Это должны быть простые единицы, отражающие фактическоеколичество отпускаемой субстанции. Составные единицы не могут использоватьсяв этом поле.Количество повторений заказа (NM) 00304Определение: только для амбулаторных пациентов.Номер лечащего врача, сделавшего заказ, согласно системе DEA (CN)00305Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: если требуется в данном месте реализации.Идентификатор фармацевта (провизора), утвердившего заказ (CN) 00306Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентификатор фармацевта (провизора), утвердившего заказ.Используется, если это требуется аптечным приложением или местом реализациидля заказов (или некоторых подгрупп заказов) в дополнение к полю ORC-11-лицо,проверившее заказ.Пример:В месте реализации требуется, чтобы для заказа были указаны медицинскийработник, проверивший заказ (например медсестра) и фармацевт, утвердившийзаказ. Тогда первое поле, ORC-11-лицо, проверившее заказ , уже присутствует; темне менее необходимо указать и второе поле, RXO-15-идентификаторфармацевта, утвердившего заказ.Необходимость особого внимания (ID) 00307Определение: использует таблицу 0136 - индикатор Да/Нет. Значения этогополя имеют следующий смысл:0136 Индикатор Да/Нет

ЗначениеYNОписаниеДа (Yes) - означает, что фармацевт, контролирующий заказ,должен обратить особое внимание на текст, указанный в полеRXO-6-указание лечащего врача аптеке . ЯвляетсяпредупреждениемНет (No) - предупреждения нет. Является значением поумолчанию (при пустом поле)Таблица 0136 Индикатор Да/НетМожно привести следующий пример использования этого поля:Интеллектуальное приложение для ввода заказов сообщило о возможномлекарственном взаимодействии в некотором заказе, но лечащий врач,составляющий заказ, тем не менее настаивает на своем. В этом случае аптечноеприложение, получающее заказ, должно потребовать, чтобы фармацевт(провизор) проверил это взаимодействие и созвонился с лечащим врачом.Интервал приема лекарства (единица времени) (ST) 00308Определение: единица времени, используемая для вычисления частоты приемалекарства.Формат:S = секундM = минутH = часовD = днейW = недельL = месяцевПримечание: Здесь использован тот же формат, что и для значенийкомпонента ДЛИТЕЛЬНОСТЬ поля количества/срока, заисключением спецификации “X”.Это поле является обязательным при определенных условиях (например призаказе некоторых растворов для внутривенного вливания). Например, если“принимаемое количество/единицы” равны 300 мл и единица времени дляинтервала приема равна H1, то должны вводиться 300 мл/час и длительность этойдозы составляет 1 час. Таким образом, принимаемое количество и интервалприема определяют длительность услуги.Это поле отличается от компонента интервала поля количества/срока, но ономожет использоваться в сочетании с ним, например в указании вида ввести 300мл изотонического раствора в час в течение 1 час, повторяя два раза в день .4.8.4 Сегмент RXR - способ примененияСегмент способа применения содержит иную комбинацию пути введения, меставведения, устройства для введения и способа применения, нежели былапредписана. Аптека и/или сестринский персонал имеют возможность выбора путивведения в зависимости от своего профессионального суждения или указаний поприменению, данных врачом.

П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАЗВАНИЕ ЭЛЕМЕНТА1 60 CE О 0162 00309 Путь введения2 60 CE Н 0163 00310 Место введения3 60 CE Н 0164 00311 Устройство длявведения4 60 CE Н 0165 00312 Способ примененияРисунок 4-14 Атрибуты сегмента RXR4.8.3.0 Определения полей сегмента RXRПуть введения (CE) 00309Компоненты: ^ ^ ^ ^ ^ Определение: путь введения лекарства.Некоторые текущие “коды пути введения” , например те, что являютсяпроизводными от системы NDC, уже включают в себя указание места введения. Вэтих случаях весь код может быть помещен в это поле как “заданный в данномместе реализации” с типом данных CE. Допустимые значения см. в таблице 0162 -путь введения.ОписаниеЗначениеЗначениеОписаниеAP Наружное NS НосовойB Щечный NG НосопищеводныйDT Зубной OP ГлазнойGTT Питательная трубка OT УшнойGU Ирригация PO ОральныйIA Внутриартериальный PR РектальныйIC Внутрисердечный SC ПодкожныйID Внутрикожный SL ПодъязычныйIH Ингаляция TP МестныйIM Внутримышечный TD ЧрескожныйIN Внутриносовой TL ЧрезязычныйIO Внутриглазной UR УретральныйIP Внутрибрюшинный VG ВагинальныйIS ВнутрисуставнойIT ВнутриоболочечныйIV Внутривенный

Таблица 0162 Путь введенияМесто введения (CE) 00310Компоненты: ^ ^ ^ ^ ^ Определение: место введения лекарства. Допустимые значения см. в таблице0163 - место введения.ОписаниеЗначениеЗначениеОписаниеBE Оба уха NB РоговицаOU Оба глаза PA ПерианальноеBN Обе ноздри PERIN ПромежностноеBU Ягодица RA Правая рукаCT Плевральная трубка RAC Правая передняя половина груднойклеткиLA Левая рука RACF Передняя часть левого локтевогосуставаLAC Левая передняяRD Правая дельтовидная мышцаполовина грудной клеткиLACF Передняя часть левого RE Правое ухолоктевого суставаLD Левая дельтовидная REJ Правая внешняя яремная венамышцаLE Левое ухо OD Правый глазLEJ Левая внешняя яремная RF Правая стопавенаOS Левый глаз RG Правая средняя ягодичная мышцаLF Левая стопа RH Правая кистьLG Левая средняяRIJ Правая внутренняя яремная венаягодичная мышцаLH Левая кисть RLAQ Правый нижний абдоминальныйквадрантLIJ Левая внутренняя RLFA Нижняя часть правого предплечьяяремная венаLLAQ Левый нижнийабдоминальныйквадрантRMFA Средняя часть правого предплечьяLLFAНижняя часть левогопредплечьяRNПравая ноздряLMFA Средняя часть левого RPC Правая задняя часть грудной клеткипредплечьяLN Левая ноздря RSC Правая подключичная областьLPC Левая задняя часть RT Правое бедро

грудной клеткиLSC Левая подключичная RUA Правое плечообластьLT Левое бедро RUAQ Правый верхний абдоминальныйквадрантLUA Левое плечо RUFA Верхняя часть левого предплечьяLUAQLUFALVGLVLЛевый верхнийабдоминальныйквадрантВерхняя часть левогопредплечьяЛевая наружная косаямышца животаLeft Vastus LateralisRVLRVGПравая наружная косая мышцаживотаRight Vastus LateralislТаблица 0163 Место введенияИмея тип данных CE, это поле может быть расширено для охвата большего числакодов мест тела (например, если в качестве таблицы-источника используетсяноменклатура SNOMED).Устройство для введения (CE) 00311Компоненты: ^ ^ ^ ^ ^ Определение: механическое устройство, используемое для введения лекарства.Типичными примерами служат различные комплекты для внутривенного введения.Допустимые значения см. в таблице 0164 - устройство для введения.ОписаниеЗначениеЗначениеОписаниеAP Аппликатор IVS IV SolusetBT Бюретка MI Дозируемый ингаляторHL Heparin Lock NEB РаспылительIPPB IPPB PCA PCA PumpIVP IV PumpТаблица 0164 Устройство для введенияСпособ применения (CE) 00312Компоненты: ^ ^ ^ ^ ^

Определение: способ применения, идентифицирующий специфический способ,указанный для применения лекарства пациентом. Допустимые значения см. втаблице 0165 - способ применения.ОписаниеЗначениеЗначениеОписаниеCH Жевать NB РаспылитьDI Растворить PT Причинить больDU Посыпать PF ПерфузияIF Пропитать SH МытьIS Вставить SO ПропитатьIR Оросить WA ПолоскатьIVPB IV Piggyback WI ПротеретьIVP IV PushТаблица 0165 Способ применения4.8.4 Сегмент RXC - заказ компонентов в аптекеЕсли лекарство, заказанное в сегменте RXO, является составным ИЛИ растворомдля внутривенного вливания И в числе универсальных идентификаторов услугинет кода, задающего компоненты (основной и все дополнительные), то в этихслучаях компоненты (основной и все дополнительные) задаются двумя или болеесегментами RXC. Политика аптечных приложений по отношению к заменам науровне сегмента RXC идентична той, что используется для уровня сегмента RXO.П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАЗВАНИЕЭЛЕМЕНТА1 1 ID О 0166 00313 Тип компонента всегментах RX2 100 CE О 00314 Код компонента3 20 NM О 00315 Количествокомпонента4 20 CE О 00316 ЕдиницыкомпонентаРисунок 4-15 Атрибуты сегмента RXC4.8.4.0 Определения полей сегмента RXCТип компонента в сегментах RX (ID) 00313Определение: используются следующие значения:

ЗначениеBAОписаниеОсновнойДополнительныйТаблица 0166 Тип компонента в сегментах RXВ заказах не на внутривенные растворы значение “B” все равно можетприсутствовать. Например при заказе на изготовление кожной мази компонентомсо значением “B” может быть стандартная суспензия, с которой смешиваютсяостальные компоненты.Количество “основного” компонента, указанное в сегментах типа “B”, считаетсяравным тому количеству, с которым смешиваются компоненты, указанные всегментах типа “A”. Тем самым сегменты RXC, рассматриваемые как группа,задают “рецепт” для конкретного количества (определяемого по сегментам типа“B”). Доза приема, заданная в сегменте RXO, не обязана соответствовать этомуколичеству основного компонента. Например, в сегментах RXC может быть заданрецепт для литра стандартного солевого раствора с добавлением 1 граммаконкретного антибиотика, в то время как доза приема (из сегмента RXO) можетбыть задана как 2 литра указанного внутривенного раствора каждые 24 часа.Количество, указанное в каждом сегменте типа “A”, определяется как количество,добавляемое к основным компонентам, количество которых задано в их сегментахRXC.Если в сообщении присутствуют “основные” компоненты, то они должныпередаваться первыми. Первый “основной” компонент в сообщении долженрассматриваться как “главный”, если такое выделение требуется. Соответственно,первое “дополнение” в сообщении должно рассматриваться как “главноедополнение “, если это требуется.Код компонента (CE) 00314Компоненты: ^ ^ ^ ^ ^ Определение: эквивалентно полю OBR-4-универсальный идентификатор услуги.Оно определяет основной или дополнительный компонент тем же образом, что икоды принимаемого и отпускаемого лекарства. Как и в случае последних кодов,коды компонентов могут содержать только текст, только код, текст + код, текст +код + единицы (в явном или подразумеваемом виде). Соответственно, если полеRXC-4-единицы компонентов присутствует, то оно замещает единицы,включенные в код. Если в поле код компонента указан только текст, то аптечноеприложение должно обеспечивать визуальный просмотр заказа фармацевтомлибо запросить повторное указание компонента.Количество компонента (NM) 00315Определение: количество компонента, добавляемое к заданному количествуосновного компонента.Единицы компонента (CE) 00316Компоненты: ^ ^ ^ ^ ^ Определение: единицы измерения для количества компонента. Если это полеуказано, то его значение замещает единицы, включенные в поле RXC-2-кодкомпонента. Оно должно содержать простые единицы, отражающие фактическое

количество добавляемого компонента. Составные единицы в этом поле недопускаются.4.8.5 Группы внутривенных растворовВ заказах на группы внутривенных растворов, которые должны вводитьсяпоследовательно, можно использовать два похожих способа: отношенияотцы-потомки и отдельные заказы. В настоящей версии стандарта HL7поддерживаются оба способа заказа. Выбор способа передачи таких заказовдолжен быть предметом договоренности между лечебным учреждением ипоставщиками прикладного программного обеспечения. Дальнейшие детали см. вразделе 4.4.10.2 (циклические группы заказов).4.8.6 Сообщение RDE: закодированный аптекой заказЭто сообщение обеспечивает передачу закодированного аптечным приложениемзаказа в аптеку (сообщение ORM с сегментами RXO, см. выше). Оно может бытьпослано как прямое сообщение в ответ на отдельный заказ или на серию заказовдля данного пациента.Будучи зависящими от реализации, сегменты исходного заказа (сегмент RXO,сегменты RXR, ассоциированные сегменты RXC и любые сегменты NTE) могутбыть повторены в закодированном заказе (для сравнения).RDE Сообщение с закодированным аптекой заказом ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[ PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 2[PV1] Информация о визите пациента 3]{ORC Общий заказ 4[RXO Рецепт для аптеки 4[{NTE}] Примечания и комментарии (к сегменту RXO) 2{RXR} Способ приема 4[{RXC} Аптечный компонент (к сегменту RXO) 4[{NTE}] Примечания и комментарии (к сегменту RXC) 2]]RXE Заказ, закодированный аптекой 4{RXR} Путь приема 4[{RXC}] Аптечный компонент (к сегменту RXE) 4{[OBX] Результаты 7[{NTE}] Примечания и комментарии (к сегменту OBX) 2}}Примечания: сегменты RXC, следующие за сегментом RXO, могутне быть полностью закодированными, но те, что следуют засегментом RXE, должны быть полностью закодированными.(подтверждается сообщением)RREСообщение подтверждения закодированного аптекой заказаГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[

[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4[RXE Заказ, закодированный аптекой 4{RXR} Путь введения 4[{RXC}] Аптечный компонент 4]}]4.8.7 Сегмент RXE - закодированный аптекой заказСегмент RXE содержит детали кодировки заказа аптечным приложением. Он такжесодержит несколько полей статуса заказа, имеющих аптечную специфику,например RXE-16-число оставшихся повторений, RXE-17-число отпущенныхповторений /доз, RXE-18-дата и время последнего повторения/дозы, иRXE-19-общая суточная доза.Обратите внимание, что поле ORC-7-количество/срок имеет другое значение посравнению с полями RXE-1-количество/срок и RXG-3-количество/срок. Аптекаимеет “полномочия” (и/или потребность) планировать события отпуска/приема.Следовательно, аптека несет ответственность за кодированию этой информации опланировании в полях RXE-1-количество/срок и RXG-3-количество/срок. ПолеORC-7-количество/срок не изменяется: оно всегда задает затребованный планприема/отпуска, указанный в исходном заказе.П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАИМЕНОВАНИЕЭЛЕМЕНТА1 200 TQ О 00221 Количество/срок2 100 CE О 00317 Код принимаемоголекарства3 20 NM О 00318 Количествопринимаемоголекарства -минимальное4 20 NM Н 00319 Количествопринимаемоголекарства -максимальное5 60 CE О 00320 Единицыпринимаемоголекарства6 60 CE Н 00321 Форма дозировкипринимаемоголекарства7 200 CE Н Д 00298 Указания лечащеговрача по приему8 12 CM У 00299 Место доставки9 1 ID Н 0167 00322 Статус замены10 20 NM У 00323 Количествоотпускаемоголекарства11 60 CE У 00324 Единицы

отпускаемоголекарства12 3 NM Н 00304 Число повторенийзаказа13 60 CN У 00305 Номер лечащеговрача, сделавшегозаказ, согласносистеме DEA14 60 CN У 00306 Идентификаторфармацевта,утвердившего заказ15 20 ST О 00325 Номер рецепта16 20 NM У 00326 Число оставшихсяповторений заказа17 20 NM У 00327 Число отпущенныхповторений / Доз18 26 TS У 00328 Дата и времяпоследнегоотпущенногоповторения илидозы19 10 CQ У 00329 Общая суточнаядоза20 1 ID Н 00307 Необходимостьособого внимания21 200 CE Н Д 00330 Особые указанияпо отпуску22 20 ST У 00331 Интервал приема(единица времени)23 6 ST Н 00332 Интенсивностьприема24 60 CE Н 00333 ЕдиницыинтенсивностиприемаРисунок 4-16 Атрибуты сегмента RXE4.8.7.0 Определения полей сегмента RXEКоличество/срок (TQ) 00221Компоненты: ^ ^ ^ ^ ^ ^ ^ ^ ^ Определение: см. в разделе 4.8.7 модификацию этого поля, необходимую дляотражения зависимостей между заказами, которые требуется обеспечить дляаптечных заказов. Это поле используется аптекой для полностью кодированногопредставления моментов времени, связанных с отпуском и приемом лекарства.Его значение может отличаться от содержания поля ORC-7-количество/срок,указывающего затребованные количество/срок в исходном заказе.

Код принимаемого лекарства (CE) 00317Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор медицинской субстанции, которая должна бытьпринята пациентом; он кодируется аптекой и по своим функциям эквивалентенполю OBR-4-универсальный код услуги. В сегменте RXE этот идентификатордолжен быть полностью кодированным. Поля отпуска, определяющие вид иколичество того, что должен принять пациент (см. ниже поля RXE-11- количествоотпускаемого лекарства и RXE-12-единицы отпускаемого лекарства) необязательно коррелируют с инструкциями о том, какое количество должно быть“дано”, или принято пациентом с каждой дозой и могут быть, а могут и не бытьуказаны в заказе. Например, в той части заказа, которая относится к “приему”,может быть передано указание давать 250 мг ампициллина, в то время как вчасти заказа, относящейся к отпуску, может содержаться указание отпустить 30таблеток аналога лекарства, заказанного в этом рецепте для амбулаторногопациента.Количество принимаемого лекарства - максимальное (NM) 00318Определение: В заказе с переменной дозой это поле рассматривается какмаксимальное заказанное количество. С заказах с неизменяющейся дозой этополе не используется.Примечание: это поле не дублирует первый компонент поляколичества/срока, поскольку в заказах, не относящихся к аптеке,этот компонент может использоваться для задания кратныхзаказанному количеству.Выражая сказанное другими словами, для заказов в аптекукомпонент количества поля количества/срока относится к тому, чтодолжно быть принято пациентом в каждом интервале обслуживания;таким образом, в терминах заказов RX, первый компонент поумолчанию должен равняться 1. Следовательно, при фактическомвыполнении заказа значение 1 первого компонента поляколичества/срока всегда относится к одному приему лекарства вколичестве, указанном в данном поле (поле затребованногоколичества принимаемого лекарства).Количество принимаемого лекарства - максимальное (NM) 00293Определение: В заказе с переменной дозой это поле рассматривается какмаксимальное заказанное количество. С заказах с неизменяющейся дозой этополе не используется.Единицы принимаемого лекарства (CE) 00320Компоненты: ^ ^ ^ ^ ^ Определение: закодированные аптекой единицы, в которых исчисляетсяколичество принимаемого лекарства.Примечание: эти единицы могут быть “составными”, напримермогут содержать слова “в расчете на”. Скажем, микрограммы накилограмм (мкг/кг) являются допустимым значением и означают, чтоединицами служат микрограммы на кг (веса тела). Полный переченьединиц измерения в расширенном стандарте ISO+ см. в главе 7.Для определения стандартных аббревиатур составных единиц необходимо иметьсоответствующую таблицу. Пока такая таблица не будет согласована между всемисторонами, в каждой системе необходимо иметь пользовательскую таблицу

единиц.Форма дозировки принимаемого лекарства (CE) 00321Компоненты: ^ ^ ^ ^ ^ Определение: используется, если поле кода принимаемого лекарства не содержитуказания лекарственной формы.Указания лечащего врача по приему (CE) 00298Определение: указания лечащего врача пациенту или медицинскому работнику,выполняющему лекарственное назначение, в виде свободного текста.Используется, например, для нестандартных внутривенных растворов,экстемпоральной рецептуры, мазей.Место доставки (CM) 00299Компоненты: ^ Определение: первый компонент содержит место размещениягоспитализированного или амбулаторного пациента, в которое аптека должнаотправить лекарство (если это требуется). По умолчанию (пустое) значениесоответствует текущему размещению пациента (согласно системе учета коечногофонда). Таблица возможных значений зависит от местных соглашений. Этоткомпонент имеет ту же форму, что и поле PV1-3-место, закрепленное запациентом.Второй компонент может быть использован для указания адреса. Этот адресможет быть использован для заполнения шаблонов писем с ответом пациенту илилечащему врачу, или для выставления счета за помощь, оказанную на дому.Статус замены (ID) 00322Определение: допустимые значения см. в таблице 167 - статус замены. Еслибыла сделана замена, но при этом необходимо иметь сведения об исходномзапрошенном коде принимаемого лекарства (поле RXO-1), то в сообщение RDEможно включить необязательный сегмент RXO.ЗначениеNGTОписаниеПри отпуске не было замены (это значениеиспользуется по умолчанию)При отпуске была сделана замена на синонимПри отпуске была сделана замена на терапевтическийаналогТаблица 0167 Статус заменыКоличество отпускаемого лекарства (NM) 00323Определение: закодированное аптекой количество отпускаемого лекарства.Единицы отпускаемого лекарства (CE) 00324Компоненты: ^ ^ ^ ^ ^

Определение: закодированные аптекой единицы, в которых исчисляетсяколичество отпускаемого лекарства. Это должны быть простые единицы,отражающие фактическое количество отпускаемой субстанции. Составныеединицы не могут использоваться в этом поле.Количество повторений заказа (NM) 00304Определение: Общее количество повторений, указанное в исходном заказе.Используется только для амбулаторных пациентов.Номер лечащего врача, сделавшего заказ, согласно системе DEA (CN)00305Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: если требуется в данном месте реализации.Идентификатор фармацевта (провизора), утвердившего заказ (CN) 00306Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентификатор фармацевта (провизора), утвердившего заказ.Используется, если это требуется аптечным приложением или местом реализациидля заказов (или некоторых подгрупп заказов).Номер рецепта (ST) 00325Определение: присваивается аптечным приложением. Степень уникальностидолжна быть такой же, как у номера заказа у исполнителя-аптеки. В некоторыхместах реализации это может быть внутренний аптечный порядковый номер. Вдругих местах это может быть внешний номер.Оставшееся число повторений заказа (NM) 00326Определение: используется только для амбулаторных пациентов.Число отпущенных повторений /доз (NM) 00327Определение: используется только для амбулаторных пациентов.Дата и время последнего отпущенного повторения или дозы (TS) 00328Определение: дата и время последнего отпущенного повторения или дозы вформате TS.Общая суточная доза (CQ) 00329Компоненты: ^ Определение: общая суточная доза отпускаемого лекарства, выраженная втерминах фактических единиц отпуска.Необходимость особого внимания (ID) 00307Определение: использует таблицу 0136 - индикатор Да/Нет. Значения этогополя имеют следующий смысл:ЗначениеYNОписаниеДа (Yes) - означает наличие предупреждения.Приложение-получатель закодированного аптекой заказа должнопредупредить лицо, обеспечивающее прием лекарства, онеобходимости обратить особое внимание на текст, указанный вполе RXE-22-особые указания аптеки при отпуске.Нет (No) - предупреждения нет. Является значением по умолчанию(при пустом поле).

Таблица 0136 Индикатор Да/НетОсобые указания аптеки при отпуске (CE) 00330Определение: особые указания аптеки медицинскому работнику. отпускающемулекарство или обеспечивающему его прием.Интервал приема лекарства (единица времени), задаваемый аптекой (ST)00331Определение: единица времени, используемая для вычисления частоты приемалекарства.Формат:S = секундM = минутH = часовD = днейW = недельL = месяцевЗдесь использован тот же формат, что и для значений компонентаДЛИТЕЛЬНОСТЬ поля количества/срока, за исключением спецификации “X”.Это поле является обязательным при определенных условиях (например призаказе некоторых растворов для внутривенного вливания). Например, если“принимаемое количество/единицы” равны 300 мл и единица времени дляинтервала приема равна H1 (один час), то должны вводиться 300 мл/час.Интенсивность приема лекарства (CE) 00332Определение: интенсивность (число) приема субстанции.Единицы интенсивности приема (ST) 00333Определение: единицы интенсивности приема лекарства. Могут быть составными.Произведение интенсивности приема и единиц интенсивности дает фактическуюинтенсивность приема лекарства. Так, если интенсивность приема = 100 иединицы интенсивности = мл/час, то затребованная интенсивность приемасоставит 100 мл/час.4.8.8 Примечания к использованию аптечных сообщенийДля сообщений RDS (отпуск лекарства из аптеки), RGV (запланированный приемлекарства) и RAS (фактический прием лекарства), номера заказа у заказчика иисполнителя те же, что и в отцовском сообщении RDE (закодированный аптекойзаказ). В этих сообщениях номер заказа у исполнителя не обеспечиваетоднозначной идентификации конкретных операций (отпуск, назначение илиприем). Для решения этой проблемы каждый из определяющих операциюсегментов (RXD, RXG, и RXA) имеет соответствующим образом поименованноедополнение к идентификатору (дополнительный счетчик отпуска, дополнительныйсчетчик назначения и дополнительный счетчик приема). Комбинация номеразаказа у исполнителя (включая входящий в его состав идентификатор приложения)и соответствующего дополнительного счетчика однозначно идентифицируетконкретную операцию аптеки, указанную в этих сообщениях.Хотя по умолчанию код управления заказом в сообщениях RDE, RDS, RGV и RASимеет значение “RE”, бывают ситуации, когда аптечная система и

система-получатель сообщения должны обмениваться между собой изменениямив состоянии выполнения заказа. В зависимости от того, находится ли аптечнаясистема в состоянии заказчика или исполнителя по отношению ксистеме-получателю сообщения, значение по умолчанию “RE” может бытьзаменено на соответствующий ситуации код управления заказом.Система-получатель также может использовать соответствующий код управлениязаказом для обратной передачи статуса аптечной системе.Предположим, к примеру, что аптечная система посылает сообщения RGVинформационной системе для медсестер, которая должна обеспечить приемлекарства, и аптечная система должна потребовать, чтобы несколько назначенийприема по данному заказу были отменены. Для реализации такого требованиясообщение RGV может быть послано с кодом управления заказом “DC” (отменитьзапрос); при этом в полях дополнений к идентификатору в соответствующихсегментах RXG задается конкретная отменяемая операция. Если требуется датьуведомление аптеке о действиях, предпринятых в ответ на ее требование, тоинформационная система для медсестер может инициировать сообщение RGV скодом управления “DR” (выполнение отменено в соответствии с запросом),содержащие сегменты RXG, у которых поля дополнительного идентификатораописывают конкретные отмененные операции.4.8.9 Сообщение RDS - отпуск лекарства из аптекиСообщение RDS может быть создано аптечным приложением для каждого случаяотпуска лекарства, связанного с выполнением существующего заказа или заказов.В наиболее распространенной ситуации сообщения RDS передаютсяинформационной системе для медсестер или некоторому другому клиническомуприложению, которым требуются сведения об отпуске лекарства. Длясопоставления отпуска и исходного заказа в сообщении RDS могут быть переданынеобязательные сегменты RXO, RXE и ассоциированные с ними сегментыRXR/RXC, которые зависят от местной реализации.RDS Аптечное сообщение об отпуске ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[PID Идентификация пациента 3[{NTE}]Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 2[PV1] Информация о визите пациента 3]{ORC Общий заказ 4[RXO Рецепт в аптеку 4[{NTE} Примечания и комментарии (к сегменту RXO) 2{RXR} Путь введения 4[{RXC} Аптечный компонент 4[{NTE} Примечания и комментарии (к сегменту RXC) 2]]][RXE Закодированный аптекой заказ 4{RXR} Путь введения, назначенный аптекой 4[{RXC}] Аптечный компонент 4]RXD Отпуск из аптеки 4{RXR} Путь введения, назначенный аптекой 4[{RXC}] Аптечный компонент 4{OBX Результаты 7

[{NTE}] Примечания и комментарии (к сегменту OBX) 2}}(подтверждается сообщением)RRD Подтверждение аптечного сообщения об отпуске ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4[RXD Отпуск из аптеки 4{RXR} Путь введения, назначенный аптекой 4[{RXC}] Аптечный компонент 4]}]Сегмент ORC должен иметь не пустой номер заказа у исполнителя и кодуправления заказом RE. Сегмент RXE и ассоциированные с ним сегменты RXCмогут присутствовать, если приложению-получателю необходимы содержащиеся вних данные. Сегмент RXD несет сведения об отпуске для данного лекарственногоназначения: он может описывать однократную дозу, полусуточную дозу, суточнуюдозу, повторение рецепта и т.д. Сегмент RXD не представляет собой полнуюинформацию о заказе. Если необходима полная информация, то используютсятакже сегменты RXO и RXE. В этом случае данное сообщение будет представлятьсобой документ, передаваемый аптекой информационной системе для медсестер(или другому приложению) и содержащий сведения об отпуске лекарства, а такжеуказания по его приему.4.8.10 Сегмент RXD - отпуск из аптекиП/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАИМЕНОВАНИЕЭЛЕМЕНТА1 4 NM О 00334 Счетчикидентификации отпуска2 100 CE О 00335 Кодотпускаемого/принимаемоголекарства3 26 TS О 00336 Дата и время отпуска4 20 NM О 00337 Фактически отпущенноеколичество5 60 CE У 00338 Единицы фактическогоотпуска6 60 CE Н 00339 Фактическая формадозировки7 20 NM У 00325 Номер рецепта8 20 NM У 00326 Оставшееся числоповторений9 200 CE У Д 00340 Указания по отпуску10 200 CN Н 00341 Идентификатораптечного работника,

отпустившего лекарство11 1 ID Н 0167 00342 Статус замены12 10 NM Н 00328 Общая суточная доза13 12 ID У 00299 Место доставки14 1 ID Н 00307 Необходимостьособого внимания15 200 CE Н Д 00330 Особые указанияаптеки при отпускеРисунок 4-17 Атрибуты сегмента RXD4.8.10.0 Определения полей сегмента RXDСчетчик идентификации отпуска (NM) 00334Определение: начальное значение 1 присваивается счетчику при первом отпускелекарства по данному заказу. Увеличивается на 1 при каждом последующемотпуске.Код отпускаемого/принимаемого лекарства (CE) 00335Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор медицинской субстанции, заказанной для приемапациентом; эквивалентен полю OBR-4-универсальный код услуги. Полноеопределение поля RXE-2-код принимаемого лекарства см. в описании сегментаRXE.Примечание: содержание поля RXD-2-код отпускаемого/принимаемоголекарства должно быть идентично соответствующему полюсегмента RXE (RXE-2-код принимаемого лекарства). СообщениеRDS относится ТОЛЬКО к отпуску лекарства аптекой.Дата и время отпуска (TS) 00336Определение: момент отпуска лекарства аптекой. Имеет формат даты и времениTS.Фактически отпущенное количество (NM) 00337Определение: отпущенное количество.Единицы фактического отпуска (CE) 00338Компоненты: ^ ^ ^ ^ ^ Определение: единицы фактического отпуска. Задаются таблицей, зависящей отместной реализации. Как и в случае единиц принимаемого лекарства, еслиединицы являются частью кода фактически отпущенного лекарства, то данноеполе является необязательным, но уж если оно указано, то заменяет единицы,включенные в код фактически отпущенного лекарства. Данные единицы должныбыть простыми, отражающими реальное количество отпущенной субстанции.Составные единицы в этом поле не допускаются.Фактическая форма дозировки (CE) 00339

Компоненты: ^ ^ ^ ^ ^ Определение: это поле используется, если ни код принимаемого лекарства, ни кодотпускаемого лекарства не содержат указания на форму дозировки.Номер рецепта (ST) 00325Определение: присваивается аптечным приложением. Степень уникальностидолжна быть такой же, как у номера заказа у исполнителя-аптеки. В некоторыхместах реализации это может быть внутренний аптечный порядковый номер. Вдругих местах это может быть внешний номер.Оставшееся число повторений заказа (NM) 00326Определение: используется только для амбулаторных пациентов.Указания по отпуску (CE) 00340Определение: указания лицу, отпускающему лекарство, в виде свободного текста(может включать в себя исходные указания лечащего врача, провизора, а такжесведения из фармакологического справочника). Используется, например, длянестандартных внутривенных растворов, экстемпоральной рецептуры, мазей.Идентификатор аптечного работника, отпустившего лекарство (CN) 00341Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентификатор аптечного работника, отпустившего лекарство.Статус замены (ID) 00342Определение: допустимые значения см. в таблице 167 - статус замены.Общая суточная доза (NM) 00328Определение: общая суточная доза отпущенного лекарства, выраженная втерминах единиц фактического отпуска.Примечание: следующие два поля эквиваленты соответствующимполям сегмента RXE. Они включаются (как необязательные) всегмент RXD с тем, чтобы последний мог использоваться автономнокак результат указаний по отпуску.Место доставки (CM) 00299Компоненты: ^ Определение: первый компонент содержит место размещениягоспитализированного или амбулаторного пациента, в которое было отпущенолекарство (если это требуется). По умолчанию (пустое) значение соответствуеттекущему размещению пациента (согласно системе учета коечного фонда).Таблица возможных значений зависит от местных соглашений. Этот компонентимеет ту же форму, что и поле PV1-3-место, закрепленное за пациентом.Второй компонент может быть использован для указания адреса. Этот адресможет быть использован для заполнения шаблонов писем с ответом пациенту илилечащему врачу, или для выставления счета за помощь, оказанную на дому.Необходимость особого внимания (ID) 00307Определение: использует таблицу 0136 - индикатор Да/Нет. Значения этогополя имеют следующий смысл:

ЗначениеYNОписаниеДа (Yes) - означает наличие предупреждения. Приложение-получательсообщения от отпуске должно предупредить лицо, обеспечивающееотпуск или прием лекарства, о необходимости обратить особоевнимание на текст, указанный в поле RXD-15-особые указания аптекипри отпуске.Нет (No) - предупреждения нет. Является значением по умолчанию(при пустом поле).Таблица 0136 Индикатор Да/НетОсобые указания аптеки при отпуске (CE) 00330Определение: особые указания аптеки медицинскому работнику. отпускающемулекарство или обеспечивающему его прием.4.8.11 Сообщение RGV - указания аптеки по приему лекарстваСегмент RXD сообщения RDS несет данные об отпуске лекарства по данномуназначению; он может отвечать одной дозе, полусуточной дозе, суточной дозе,повторению рецепта и т.д. Но при этом он не содержит указания по приему илисведения о режиме приема. Если эти указания по приему необходимо передать отаптечного приложения другому приложению, то это можно сделать с помощьюсообщения RGV.Сообщение RGV использует сегмент RXG для передачи указания по приемулекарства. Оно может нести информацию об отдельном запланированном приемелекарства или о нескольких приемах лекарства. Если аптеке (или некоторомудругому приложению) требуется создать отчет о многократных приемах лекарства(MAR), где каждому приему соответствуют свои указания по дате и времени, то ономожет следующим образом использовать сообщение RGV:Для каждого запланированного случая приема лекарства аптека формирует либоотдельное сообщение RGV, либо одно сообщение RGV с несколькими сегментамиRXG, по одному на каждый случай приема. Информация о фактическом приеме(передаваемая в одном или нескольких сообщениях RAS) привязывается к плануприема с помощью записи в каждый сегмент RXA идентификации приема изсоответствующего сегмента RXG. Если необходимо выполнить привязку более чемодного события приема (как в случае регистрации изменения интенсивностивведения внутривенных растворов), то приложение, отвечающее за регистрациюприема, создает дополнительные сегменты RXA (привязанные к одному и тому жесегменту RXG). Если привязки не требуется, то полю идентификации приема всегментах RXA присваивается нулевое значение (0).В сегменте ORC должен быть указан номер заказа у исполнителя и его полеуправления заказом должно иметь значение RE. Сегмент RXE и ассоциированныес ним сегменты RXC могут присутствовать, если приложению-получателютребуется содержащаяся в них информация. Сегмент RXG несет сведения озапланированном приеме либо в виде отдельного “указания по приему”(однократная доза) лекарства либо в виде нескольких “указаний по приему”.Сегмент RXG не представляет собой полную информацию о заказе. Еслинеобходима полная информация, то используются также сегменты RXO и RXE. Вэтом случае данное сообщение будет представлять собой документ,передаваемый аптекой информационной системе для медсестер (или другомуприложению) и содержащий указания по его приему.RGV Отпуск лекарства из аптеки ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2

[PID Идентификация пациента 3[{NTE}] Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 2[ PV1 ] Информация о визите пациента 3]{ORC Общий заказ 4[RXO Рецепт для аптеки 4[{NTE} Примечания и комментарии (к сегменту RXO) 2{RXR} Путь введения, заданный аптекой 4[{RXC} Аптечный компонент 4[{NTE}] Примечания и комментарии (к сегменту RXC) 2]]][RXE Закодированный аптекой заказ 4{RXR} Путь введения, заданный аптекой 4[{RXC}] Аптечный компонент 4]{RXG Указания аптеки по приему лекарства 4{RXR} Путь введения, заданный аптекой 4[{RXC}] Аптечный компонент 4{[OBX] Результаты/исследования 7[{NTE}] Примечания и комментарии (к сегменту OBX) 2}}(подтверждается сообщением)RRG Подтверждение указаний аптеки по приему ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[[PID Идентификация пациента 3[{NTE}]] Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4[RXG Указания аптеки по отпуску 4{RXR} Путь введения, заданный аптекой 4[{RXC}] Аптечный компонент 4]}]4.8.12 Сегмент RXG - указания аптеки по приему лекарстваП/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАИМЕНОВАНИЕЭЛЕМЕНТА1 4 NM О 00342 Счетчик идентификацииприема2 4 NM Н 00333 Дополнительнаяидентификация отпуска

3 200 TQ О 00221 Количество/срок4 100 CE О 00317 Код принимаемоголекарства5 20 NM О 00318 Количествопринимаемоголекарства -минимальное6 20 NM Н 00319 Количествопринимаемоголекарства -максимальное7 60 CE О 00320 Единицы принимаемоголекарства8 60 CE Н 00321 Форма дозировкипринимаемоголекарства9 200 CE У Д 00343 Указания по приему10 20 ID Н 0167 00322 Статус замены11 12 ID Н 00299 Место доставки12 1 ID Н 00307 Необходимость особоговнимания13 200 CE Н Д 00344 Особые указанияаптеки для приема14 20 ST У 00331 Интервал приемалекарства (единицавремени)15 6 ST Н 00332 Интенсивность приемалекарства16 60 CE Н 00333 Единицыинтенсивности приемаРисунок 4-18 Атрибуты сегмента RXG4.8.12.0 Определения полей сегмента RXGСчетчик идентификации приема (NM) 00342Определение: используется, если данный сегмент RXG несет информацию ободном приеме лекарства. Начальное значение 1 присваивается счетчику дляпервого запланированного момента приема лекарства, указанного аптекой вданном сообщении. Увеличивается на 1 для каждого дополнительного моментаприема лекарства, заданного в данном заказе.Если сегмент RXG несет информацию о нескольких приемах лекарства, тозначение этого поля равно нулю, поскольку в этом случае привязка с сегментомRAS в отношении один-к-одному не может быть выполнена однозначно.Дополнительная идентификация отпуска (NM) 00334Определение: дополнительная идентификация отпуска, с которым связано данноесообщение о приеме лекарства.Количество/срок (TQ) 00221

Компоненты: ^ ^ ^ ^ ^ ^ ^ ^ ^ Определение: спецификация количества/срока, которые относится либо только котдельному указанию по запланированному приему, либо к нескольким указаниямпо приему. В первом случае поле RXG-1-счетчик идентификации приемапредставляет собой положительное число, большее или равное единице (1). Впоследнем случае поле RXG-1-счетчик идентификации приема имеет нулевоезначение (0). Количество должно быть всегда равно 1. Это поле количества/срокаможет отличиться от поля количества/срока, входящего в сегмент ORC исодержащего требуемые атрибуты количества/срока исходного заказа.Примечание: Содержание полей 3-8 должно быть идентичносоответствующим полям сегмента RXE (а именно, полям с RXE-2 поRXE-5).Код принимаемого лекарства (CE) 00317Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор медицинской субстанции, которая должна бытьпринята пациентом; по своим функциям он эквивалентен полюOBR-4-универсальный код услуги. Полное определение поля RXE-2-кодпринимаемого лекарства см. в описании сегмента RXE.Количество принимаемого лекарства - минимальное (NM) 00318Определение: В заказе с переменной дозой это поле рассматривается какминимальное заказанное количество. С заказах с неизменяющейся дозой это полене используется.Примечание: это поле не дублирует первый компонент поляколичества/срока, поскольку в заказах, не относящихся к аптеке,этот компонент может использоваться для задания кратныхзаказанному количеству.Выражая сказанное другими словами, для заказов в аптекукомпонент количества поля количества/срока относится к тому, чтодолжно быть принято пациентом в каждом интервале обслуживания;таким образом, в терминах заказов RX, первый компонент поумолчанию должен равняться 1. Следовательно, при фактическомвыполнении заказа значение 1 первого компонента поляколичества/срока всегда относится к одному приему лекарства вколичестве, указанном в данном поле (поле затребованногоколичества принимаемого лекарства).Количество принимаемого лекарства - максимальное (NM) 00293Определение: В заказе с переменной дозой это поле рассматривается какмаксимальное заказанное количество. С заказах с неизменяющейся дозой этополе не используется.Единицы принимаемого лекарства (CE) 00320Компоненты: ^ ^ ^ ^ ^ Определение: закодированные аптекой единицы, в которых исчисляетсяколичество принимаемого лекарства.

Примечание: эти единицы могут быть “составными”, напримермогут содержать слова “в расчете на”. Скажем, микрограммы накилограмм (мкг/кг) являются допустимым значением и означают, чтоединицами служат микрограммы на кг (веса тела.Для определения стандартных аббревиатур составных единиц необходимо иметьсоответствующую таблицу. Пока такая таблица не будет согласована между всемисторонами, в каждой системе необходимо иметь пользовательскую таблицуединиц.Форма дозировки принимаемого лекарства (CE) 00321Компоненты: ^ ^ ^ ^ ^ Определение: используется, если поле кода принимаемого лекарства не содержитуказания лекарственной формы.Указания по приему (CE) 00343Определение: указания в виде свободного текста лицу, обеспечивающему приемлекарства (могут включать исходные указания лечащего врача, указания аптеки, атакже сведения из фармакологического справочника).Статус замены (ID) 00322Определение: допустимые значения см. в таблице 167 - статус замены.Примечание: следующие два поля эквивалентны соответствующимполям сегмента RXE. Они включены (как необязательные) в сегментRXG, чтобы он мог использоваться “автономно “в качестве сегментауказаний по приему лекарства.Место доставки (CM) 00299Компоненты: ^ Определение: первый компонент содержит место размещениягоспитализированного или амбулаторного пациента, в которое аптека должнаотправить лекарство (если это требуется). По умолчанию (пустое) значениесоответствует текущему размещению пациента (согласно системе учета коечногофонда). Таблица возможных значений зависит от местных соглашений. Этоткомпонент имеет ту же форму, что и поле PV1-3-место, закрепленное запациентом.Второй компонент может быть использован для указания адреса. Этот адресможет быть использован для заполнения шаблонов писем с ответом пациенту илилечащему врачу.Необходимость особого внимания (ID) 00307Определение: использует таблицу 0136 - индикатор Да/Нет. Значения этогополя имеют следующий смысл:ЗначениеYNОписаниеДа (Yes) - означает наличие предупреждения.Приложение-получатель закодированного аптекой заказа должнопредупредить лицо, обеспечивающее прием лекарства, онеобходимости обратить особое внимание на текст, указанный вполе RXG-13-особые указания аптеки для приема.Нет (No) - предупреждения нет. Является значением по умолчанию(при пустом поле).

Таблица 0136 Индикатор Да/НетОсобые указания аптеки для приема (CE) 00330Определение: особые указания аптеки медицинскому работнику,обеспечивающему прием лекарства.Интервал приема лекарства (единица времени) (ST) 00331Определение: единица времени, используемая для вычисления частоты приемалекарства.Формат:S = секундM = минутH = часовD = днейW = недельL = месяцевЗдесь использован тот же формат, что и для значений компонентаДЛИТЕЛЬНОСТЬ поля количества/срока, за исключением спецификации “X”.Это поле является обязательным при определенных условиях (например призаказе некоторых растворов для внутривенного вливания). Например, если“принимаемое количество/единицы” равны 300 мл и единица времени дляинтервала приема равна H1 (один час), то должны вводиться 300 мл/час.Интенсивность приема лекарства (CE) 00332Определение: интенсивность (число) приема субстанции.Единицы интенсивности приема (ST) 00333Определение: единицы интенсивности приема лекарства. Могут быть составными.Произведение интенсивности приема и единиц интенсивности дает фактическуюинтенсивность приема лекарства. Так, если интенсивность приема = 100 иединицы интенсивности = мл/час, то затребованная интенсивность приемасоставит 100 мл/час.4.8.13 Сообщение RAS - информация о приеме лекарстваСообщение RAS может быть создано приложением, регистрирующим каждыйслучай приема лекарства (например информационной системой для медсестер),выполненный по существующему заказу. Если приложению регистрации приемалекарства требуется сообщить о нескольких случаях приема по данному заказу водном сообщении RAS, то каждый случай должен быть описан в отдельном(повторяющемся) сегменте RXA. Кроме того, сведения о приеме для группызаказов также могут быть переданы в одном сообщении за счет повторения группсегментов на уровне сегмента ORC.В наиболее распространенной ситуации сообщения RAS должны передаватьсяинформационной системой для медсестер аптечному приложению (либоприложению, сформировавшему заказ, или другому клиническому приложению),которое использует эту информацию для ведения истории лекарственныхназначений, принимаемых пациентом. Одному сегменту ORC могут сопутствоватьнесколько сегментов RXA, каждый из которых отвечает отдельному случаю приемалекарства, выполненному по данному заказу.

RAS Информация о приеме лекарства ГлаваMSH Заголовок сообщения 2[{NTE}] Примечания и комментарии (к заголовку) 2[PID Идентификация пациента 3[{NTE}]Примечания и комментарии(к идентификации пациента) 2[{AL1}] Аллергия 2[PV1] Информация о визите пациента 3]{ORC Общий заказ 4[RXO Рецепт в аптеку 4[{NTE} Примечания и комментарии (к сегменту RXO) 2{RXR} Путь введения 4[{RXC} Аптечный компонент 4[{NTE} Примечания и комментарии (к сегменту RXC) 2]]][RXE Закодированный аптекой заказ 4{RXR} Путь введения, назначенный аптекой 4[{RXC}] Аптечный компонент 4]{RXA} Информация о приеме 4RXR Путь введения, назначенный аптекой 4{[OBX Результаты 7{[NTE]} Примечания и комментарии (к сегменту OBX) 2]}}(подтверждается сообщением)RRA Подтверждение сообщения о приеме лекарства ГлаваMSH Заголовок сообщения 2MSA Подтверждение сообщения 2[ERR] Ошибка 2[{NTE}] Примечания и комментарии (к заголовку) 2[[PID Идентификация пациента 3[{NTE}]]Примечания и комментарии(к идентификации пациента) 2{ORC Общий заказ 4[{RXA} Информация о приеме лекарства 4RXR Путь введения, назначенный аптекой 4]}]4.8.14 Сегмент RXA - информация о приеме лекарстваСегмент ORC должен иметь не пустой номер заказа у исполнителя и кодуправления заказом RE. Будучи специфичными для конкретной реализации,сегмент RXO и ассоциированные с ним сегменты RXC и/или сегмент RXE (иассоциированные с ним сегменты RXC) могут присутствовать, еслиприложению-получателю необходимы содержащиеся в них данные. Сегмент RXAнесет сведения о приеме лекарства..

П/П ДЛИНА ТИП О/Н ПОВТ/# ТАБЛ# ЭЛЕМ# НАИМЕНОВАНИЕЭЛЕМЕНТА1 4 NM О 00342 Счетчик идентификациизапланированногоприема2 4 NM О 00344 Счетчик идентификациифактического приема3 26 TS О 00345 Дата и время началаприема4 26 TS О 00346 Дата и время концаприема5 100 CE О 00347 Код принятоголекарства6 20 NM О 00348 Количество принятоголекарства7 60 CE У 00349 Единицы принятоголекарства8 60 CE Н 00350 Форма дозировкипринятого лекарства9 200 CE У Д 00351 Указания по приему10 200 CN Н 00352 Лицо, обеспечившееприем лекарства11 12 ID У 00353 Место приема12 20 ST У 00354 Интервал приемалекарства (единицавремени)Рисунок 4-19 Атрибуты сегмента RXA4.8.14.0 Определения полей сегмента RXAСчетчик идентификации запланированного приема (NM) 00342Определение: используется для привязки данного сегмента RXA ксоответствующему ему сегменту RXG. Если обоим приложениям не требуетсясопоставления сегментов RXG и RXA, то значение этого поля полагается равнымнулю.Счетчик идентификации фактического приема (NM) 00344Определение: начальное значение 1 присваивается счетчику для первого моментаприема лекарства, указанного аптекой в данном сообщении. Увеличивается на 1для каждого дополнительного приема лекарства.Примечание: к одному сегменту RXG можно “привязать” болееодного сегмента RXA, как и в случае регистрации измененияинтенсивности вливаний внутривенных растворов.Дата и время начала приема (TS) 00345Определение: если заказ рассчитан на непрерывный прием (как в случаевнутривенных растворов), и интенсивность приема изменилась в определенныймомент времени после начала, то для регистрации этого изменения может бытьвыпущено сообщение RAS. В подобном сообщении RAS данное поле регистрируетмомент изменения интенсивности с прежнего значения на новое, переданное в

поле интервала приема (единицы времени) в этом же сообщении.Дата и время конца приема (если применимы) (TS) 00346Определение: если пусто, подразумевается значение, передаваемое в полеRXA-3-дата и время начала приема.Код принятого лекарства (CE) 00347Компоненты: ^ ^ ^ ^ ^ Определение: идентификатор принятой медицинской субстанции. По своейфункции это поле эквивалентно полю OBR-4-универсальный код услуги.Количество принятого лекарства (NM) 00348Определение: количество принятого лекарства.Единицы принятого лекарства (CE) 00349Компоненты: ^ ^ ^ ^ ^ Определение: в этом поле должны быть указаны простые единицы, которыеотражают фактическое количество принятой субстанции. Составные единицы вэтом поле не допускаются.Форма дозировки принятого лекарства (CE) 00350Компоненты: ^ ^ ^ ^ ^ Определение: это поле используется, если код принятого лекарства не содержитуказания формы дозировки.Указания по приему (CE) 00351Определение: указания лицу, обеспечивающему прием лекарства, в видесвободного текста. Может содержать описание нестандартных внутривенныхрастворов, экстемпоральной рецептуры, мазей.Лицо, обеспечившее прием лекарства (CN) 00352Компоненты: ^ ^ ^ ^ ^ ^ ^ Определение: идентификатор медицинского работника, обеспечившего приемлекарства.Место приема (CM) 00353Компоненты: ^ Определение: первый компонент содержит место размещениягоспитализированного или амбулаторного пациента, в которое было отпущенолекарство (если это требуется). По умолчанию (пустое) значение соответствуеттекущему размещению пациента (согласно системе учета коечного фонда).Таблица возможных значений зависит от местных соглашений. Этот компонентимеет ту же форму, что и поле PV1-3-место, закрепленное за пациентом.Второй компонент может быть использован для указания адреса. Этот адресможет быть использован для заполнения шаблонов писем с ответом пациенту илилечащему врачу, или для выставления счета за помощь, оказанную на дому.

Интервал приема (единицы времени) (ST) 00354Определение: определяет интенсивность приема лекарства, которая может бытьвычислена по этому полю и значениям полей количества и единиц принятоголекарства.4.8.15 Аптечные запросыПри соответствующих определениях в сегментах QRD и/или QRF, сообщения RDE,RDS, RGV и RAS могут служить моделями аптечных запросов, ориентированныхна результаты и возвращающих текущий профиль аптечных заказов (тип RDE),текущей истории отпуска (тип RDS), текущей истории дозировки (тип RGV) илитекущей истории приема лекарств (тип RAS). Примеры приводятся в разделе4.8.16.3.4.8.16 Примеры примененияВ этом разделе будут показаны примеры применения протокола обменааптечными сообщениями в некоторых специфических ситуациях. Незавершенныедетали обозначены многоточиями. Для большей ясности сообщения дополняютсякомментариями, которым предшествуют символы //.4.8.16.1 Примеры различных уровней кодирования заказаЗаказ принимать 500 мг ампициллина перорально каждые 6 часов в течение 10дней, всего 40 таблеток передан приложением OE приложению RX. Этот заказможет быть оформлен приложением ввода заказов с использованием различныхуровней кодирования:a) версия заказа для передачи по электронной почте (использует толькосвободный текст, передаваемый в поле RXO-6-указания лечащего врачааптеке или RXO-7-указания лечащего врача по приему ); полностьюзакодированная версия заказа может быть введена или утверждена вручнуюаптечным приложением.b) кодированные значения в полях RXO-2-затребованное количествопринимаемого лекарства - минимальное, RXO-4-затребованные единицыпринимаемого лекарства, ORC-7-количество/срок и свободный текст в полеRXO-1-затребованный код принимаемого лекарства.c) кодированные значения в полях RXO-1-затребованный код принимаемоголекарства, RXO-2-затребованное количество принимаемого лекарства -минимальное, RXO-4-затребованные единицы принимаемого лекарства,ORC-7-количество/срок, но при этом в поле RXO-1- затребованный кодпринимаемого лекарства нет указания единиц.d) кодированные значения в полях RXO-1-затребованный код принимаемоголекарства, RXO-2-затребованное количество принимаемого лекарства -минимальное, RXO-4-затребованные единицы принимаемого лекарства,ORC-7-количество/срок, и при этом в поле RXO-1- затребованный кодпринимаемого лекарства содержится указание единиц.В данном случае указание единиц является необязательным. В такихситуациях действует следующее правило (для заказов, результатов отпуска,результатов плана приема и результатов фактического приема): если всегменте единицы указаны в кодированной форме, то они замещают указаниеединиц в коде принимаемого лекарства (если таковое указание присутствует).a) Версия заказа для передачи по электронной почте: в сегменте RXO неткодированных полей.MSH|...PID|...ORC|NW|1000^OE||||E||||||||RXO||||||500 мг полициллина каждые 6 часов в течение 10 дней,отпустить 40 таблеток ||b) Частично кодированная версия заказа. В ней кодированные значения

передаются в полях RXO-2-затребованное количество принимаемоголекарства - минимальное, RXO-4-затребованные единицы принимаемоголекарства, ORC-7-количество/срок, но при этом поле RXO-1-затребованныйкод принимаемого лекарства содержит свободный текст.MSH|...PID|...ORC|NW|1000^OE||||E|^Q6H^D10^^^R|||||||RXO|^Полициллин 500 мг ТАБЛЕТКИ^|500||МГ|||||Y||40|RXR|PO|c) Версия того же заказа с большим числом кодированных полей(кодированные значения в полях RXO-1-затребованный код принимаемоголекарства, RXO-2-затребованное количество принимаемого лекарства -минимальное, RXO-4-затребованные единицы принимаемого лекарства,ORC-7-количество/срок, но при этом в поле RXO-1- затребованный кодпринимаемого лекарства нет указания единиц).MSH|...PID|...ORC|NW|1000^OE||||E|^Q6H^D10^^^R|||||||RXO|RX1001^Полициллин^L|500||МГ|||||Y||40|RXR|PO|d) Полностью кодированная версия (кодированные значения в поляхRXO-1-затребованный код принимаемого лекарства, RXO-2-затребованноеколичество принимаемого лекарства - минимальное, RXO-4-затребованныеединицы принимаемого лекарства, ORC-7-количество/срок, и при этом вполе RXO-1- затребованный код принимаемого лекарства содержитсяуказание единиц).MSH|...PID|...ORC|NW|1000^OE||||E|^Q6H^D10^^^R|||||||RXO|RX1001^Полициллин ТАБЛЕТКИ 500 мг^L|500||МГ|||||G||40|RXR|PO|e) Закодированная аптекой версия (сообщение RDE) передаетсяинформационной системе для медсестер (при отпуске была сделана заменана синоним).MSH|...PID|...ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||RXE|^^^199012100600^^R|0047-0402-30^Ампициллин ТАБЛЕТКИ 250 мг... ^NDC|2||TAB|||||G|80||||123456|rx#1001|RXR|PO|f) Результаты отпуска аптекой (сообщение RDS).MSH|...PID|...ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||RXD|1|0047-0402-30^Ампициллин ТАБЛЕТКИ 250 мг^NDC|199012100400|8|TAB||RX#1001|||123456|G|8g) План приема лекарства (сообщение RGV).MSH|...PID|...ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||RXG|1|1|^^199012100600^^R|0047-0402-30^Ампициллин ТАБЛЕТКИ 250мг^NDC|500||МГ|||G|RXR|PO|h) Результаты выполнения заказа, передаваемые информационной системойдля медсестер аптечному приложению или приложению ввода заказов.MSH|...PID|...ORC|RE|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||RXA|1|1|199012100615||0047-0402-30^Ампициллин ТАБЛЕТКИ 250 мг^NDC|2|TAB||

RXR|PO|4.8.16.2 Примеры экстемпоральных внутривенных растворовСегменты RXC используются в тех случаях, когда на уровне сегмента RXO нельзяполностью описать заказ или если описание включает в себя более одного кодалекарства. Такие “экстемпоральные” заказы могут использовать “отцовский” код науровне сегмента RXO; такой код может означать, к примеру “экстемпоральный В/Враствор, детали см. в сегментах RXC.” Вообще говоря, данное аптечноеприложение будет иметь в сегменте RXO поля типа CE следующего вида:RXCUSIV^Экстемпоральный В/В(для нестандартных В/В растворов)раствор ^МестныйRXCUSMIX^Экстемпоральная(для дерматологических и другихрецептура^Местнаяспециальностей)RXCUSSLV^Экстемпоральнаямазь^Местная(для дерматологических и другихспециальностей)Заказ передается приложением ввода заказов аптечному приложению вследующем виде:В/В раствор D5W < 1/2 NS 100 cc/час с добавление 20 мэк KCl в каждый третийлитр, начиная с первой бутылкиВыполнять непрерывно в течение 2 дней ( с 8:00 10 декабря 1993 года по 8:00 12декабря 1993 года)Критический фактор времени 30 минутa) Сегменты ORC/RXO для экстемпорального внутривенного раствора и двухлитров NSD5W в том виде, как они были сформированы приложением вводазаказов:MSH|...PID|...ORC|NW|2045^OE||||E|^C^199312100800^199312120800^^TM30^^^^|RXO|||3|L|IV|D5W С 1/2 NS С 20 МЭК KCL В КАЖДОЙ ТРЕТЬЕЙ БУТЫЛКЕНАЧИНАЯ С... ПЕРВОЙ||W8&825&A^|N||||||||H30RXR|IV|LA|IV-SET01^^L|b) Закодированная аптекой версия заказа передается на сестринский пост UnitWest 8 для палаты 825, койки A.Аптека посылает заказ в виде комплекса отец/потомки. В этом случае длязаказа 2045, сформированном в виде свободного текста, создаются двазаказа-потомка с двумя точно определенными запросами услуги. ПолеORC-4-количество/срок содержит условия срока, затребованное в исходномзаказе; таким образом, поле ORC-4-количество/срок задает затребованноевремя. Поле RXE-1-количество/срок задает аптечную интерпретацию заказа.MSH|...PID|...ORC|PA|2045^OE|123^PH||||E|^C^199312100800^199312120800^^TM30^^^^Первый полностью закодированный заказ-потомок представляет собой заказна экстемпоральный внутривенный раствор. Это повторяющийся заказ длянепрерывного приема, первый в циклической группе с числом повторений додвух. Первое повторение имеет дату и время начала 199312100800. Этотзаказ сам может быть отцом для других заказов и может быть расщеплен наиндивидуальные заказы приема. Он может быть послан системе учета приемалекарств (как в данном примере), которая обеспечивает контроль выполненияназначения.ORC|CH|2045^OE|124^PH|||E||2045&OE^123&PH|RXE|^C^H10^199312100800^199312120800^TM30^^^^S&&&125&PH&*ES+0M&2|RXCUSIV^ЭксВ/В раствор... ^L||1|L|IV||W8&825&A|N|||||||RX#1256|||||||H10|100|CC/HRRXR|IV|LA|IV-SET01^^L|RXC|B|IVDEX05^D5W С 1/2 NS^L|1|LRXC|A|CHEM_KCL^KCL^L|20|MEQ

Второй полностью закодированный заказ-потомок представляет собой заказна чистый раствор D5W. Он является вторым элементом циклической группызаказов и его введение начинается, как только завершится первое повторениезаказа с номером у исполнителя 124^PH (его начало следует за концомпредыдущего заказа без какого-либо промежутка). Максимальное число егоповторений равно двум. Этот заказ сам может быть отцом для других заказови может быть расщеплен на индивидуальные заказы приема. Он может бытьпослан системе учета приема лекарств (как в данном примере), котораяобеспечивает контроль выполнения назначения.ORC|CH|2045^OE|125^PH|||E||2045&OE^123&PH|RXE|^C^H20^199312101800^199312120800^TM30^^^^S&&&124&PH&ES+0M&2|IVDEX05^D5WС 1/2...NS^L||2|L|IV||W8&825&A|N||||||RX#1256||||||||H20|100|CC/HRRXR|IV|LA|IV-SET01^^L|c) Указания аптеки по приему (только для заказов на экстемпоральныевнутривенные растворы)Если информационная система для медсестер не выполняет декодированиесообщений RDE, но вместо этого требует передачи индивидуальныхсообщений с указаниями по приему, то можно воспользоваться следующимсообщением. Оно содержит указания сестринскому посту по введениювнутривенного раствора, специфицированного в первом заказе-потомке. Онопредставляет собой также аптечную запись, регистрирующую отпуск.Необязательные сегменты RXC используются, чтобы дать полное описаниеэкстемпорального внутривенного раствора. В данном примере полеRXG-3-количество/срок представляет фактическое время, запрашиваемоеаптекой для введения раствора. Компонент порядка выполнения заказов поляколичества/срока в этом сообщении не нужен.MSH|...PID|...ORC|RE|2045^OE|124^PH|||E|^C^199312100800^199312120800^^TM30^^^^|2045&OE^123RXG|1||^C^H10^199312100800^199312101800^^TM30|RXCUSIV^ЭкстемпоральныйВ/В раствор^L|1||L|...IV|||W8&825&A|||H10|100|CC/HRRXR|IV|LA|IV-SET01^^L|RXC|B|IVDEX05^D5W С 1/2 NS^L|1|LRXC|A|CHEM_KCL^KCL^L|20|MEQd) Приложение информационной системы для медсестер, обеспечивающееучет выполнения лекарственных назначений, сообщает результаты аптечномуприложению или приложению, выполняющему ввод заказовПриведенное ниже сообщение передается информационной системой длямедсестер, когда первая бутылка экстемпорального раствора введенапациенту. Второе приложение должно быть послано, когда будет введенраствор NS.MSH|...PID|...ORC|RE|2045^OE|124^PH|||E|^C^199312100800^199312120800^^TM30^^^^||||||||RXA|1|1|199312100800|199312101800|RXCUSIV^Экстемпоральный В/Враствор ^L|1|L|IV|||W8&825&A|H10RXR|IV|LA|IV-SET01^^L|Этим завершается первая серия сообщений, порожденных в связи с даннымлекарственным назначением.4.8.16.3 Другие примеры - ответы на запросыСообщение R0R - ответ аптеки на запрос о рецептахMSHЗаголовок сообщенияMSAПодтверждение сообщения[ERR] Ошибка{QRDОпределение запроса[QRF] Фильтр запроса[PID Идентификация пациента

{[NTE]}]{ORCRXO{RXR}{[RXC]}}}DSCMSHMSA[ERR]{QRD[QRF][PID{[NTE]}]{ORC[RXE{RXR}{[RXC]}]{RXA}RXR}}DSCMSHMSA[ERR]{QRD[QRF][PID{[NTE]}]{ORC[RXE{RXR}{[RXC]}]{RXD}{RXR}}}DSCMSHMSA[ERR]{QRD[QRF][PID{[NTE]}]{ORCПримечания и комментарии (к идентификации пациента)Общий заказРецепт для аптекиСпособ приемаАптечный компонентУказатель продолженияСообщение RAR - информация аптеки о приемеЗаголовок сообщенияПодтверждение сообщенияОшибкаОпределение запросаФильтр запросаИдентификация пациентаПримечания и комментарии (к идентификации пациента)Общий заказЗакодированный аптекой заказСпособ приемаАптечный компонентИнформация о приеме лекарстваПуть введенияУказатель продолженияСообщение RDR - информация аптеки об отпускеЗаголовок сообщенияПодтверждение сообщенияОшибкаОпределение запросаФильтр запросаИдентификация пациентаПримечания и комментарии (к идентификации пациента)Общий заказЗакодированный аптекой заказСпособ приемаАптечный компонентОтпуск из аптекиСпособ приемаУказатель продолженияСообщение RER - информация о закодированномаптекой заказеЗаголовок сообщенияПодтверждение сообщенияОшибкаОпределение запросаФильтр запросаИдентификация пациентаПримечания и комментарии (к идентификации пациента)Общий заказ

RXERXR{[RXC]}}}DSCЗакодированный аптекой заказСпособ приемаАптечный компонентУказатель продолженияСообщение RGR - информация аптеки о дозировкеMSHЗаголовок сообщенияMSAПодтверждение сообщения[ERR] Ошибка{QRDОпределение запроса[QRF] Фильтр запроса[PID Идентификация пациента{[NTE]}] Примечания и комментарии (к идентификации пациента){ORCОбщий заказ[RXEЗакодированный аптекой заказ{RXR} Способ приема{[RXC]} Аптечный компонент]{RXG} Указания аптеки по приему лекарства{RXR} Способ приема}}DSCУказатель продолженияЛабораторное приложение запрашивает у аптеки информацию о лекарствах,принимаемых пациентом с идентификатором 12345 в промежутке с 12/08/92 по13/08/92.MSH|...QRD|19920814165645|R|D|9200231|||30^RD|12345|RASQRF|PHM|19920812000000|19920813235959DSCMSH|...MSA|...QRD|...QRF|...ORC|RE||R23RXE|^BID^D5^199208120800^199208162000|10986^АМПИЦИЛЛИН|250||MGRXR|PORXA|1|1|199208120800|||250RXA|2|2|199208122000|||250RXA|3|3|199208130800|||250RXA|4|4|199208132000|||250ORC|RE||R76RXE|^TID^D7^199208120600^199208182200|12796^АСПИРИН|325||MGRXR|PORXA|1|1|199208120600|||325RXA|2|2|199208121400|||325RXA|3|3|199208122200|||325RXA|4|4|199208130600|||325RXA|5|5|199208131400|||325RXA|6|6|199208132200|||325DSCИнформационная система для медсестер запрашивает у аптеки информацию одозировке лекарств, принимаемых пациентом с идентификатором 12345 впромежутке с 12/08/92 по 13/08/92.MSH|...QRD|19920814172309|R|D|9200543|||100^RD|12345|RXGQRF|PHM|19920812000000|19920813235959DSC

MSH|...MSA|...QRD|...QRF|...ORC|RE||R23RXE|^BID^D5^199208120800^199208162000|10986^АМПИЦИЛЛИН|250||MGRXR|PORXG|1||199208120701||250RXG|2||199208121923||250RXG|3||199208130702||250RXA|4||199208131912||250ORC|RE||R76RXE|^TID^D7^199208120600^199208182200|12796^АСПИРИН|325||MGRXR|PORXG|1||199208120459||325RXG|2||199208121328||325RXG|3||199208122101||325RXG|4||199208130503||325RXG|5||199208131311||325RXG|6||199208132145||325DSCПриложение, обеспечивающее ввод заказов, запрашивает у аптеки информацию озаказах для пациента с идентификатором 12345 в промежутке с 12/08/92 по13/08/92.MSH|...QRD|19920814181254|R|D|9200785|||45^RD|12345|RDEQRF|PHM|19920812000000|19920813235959DSCMSH|...MSA|...QRD|...QRF|...ORC|RE|3346|R23RXE|^BID^D5^199208120800^199208162000|10986^АМПИЦИЛЛИН|250||MGRXR|POORC|RE|3987|R76RXE|^TID^D7^199208120600^199208182200|12796^АСПИРИН|325||MGRXR|PODSC4.9 Насущные вопросыОтсутствуют.4.10 Аптечные заказы и результаты в стандарте hl74.10.1 Диаграмма потоков трансакций для аптечных заказов ирезультатовНиже показаны возможные потоки трансакций при типичной реализации.

1. ORM/RXO:Система ввода заказов формирует заказ в аптеку (сообщение ORM с сегментом RXO и,возможно, дополнительными сегментами RXC) и посылает его аптечному приложению,информационной системе для медсестер, и/или другим приложениям, если этотребуется в рамках данной реализации.2. RDE/RXE:Аптечное приложение может послать сообщение RDE (полностью закодированныйаптекой заказ) информационной системе для медсестер, системе ввода заказов и/илидругим системам и приложениям, если это требуется в рамках данной реализации.3. RDS/RXD:Аптечное приложение может послать сообщение RDS (отпуск лекарства аптекой)информационной системе для медсестер или другим приложениям, которым этоположено в данной реализации, для каждого отпуска лекарства в соответствии сданным заказом. Для каждого заказа может быть послано несколько таких сообщений.4. RGV/RXG:Аптечное приложение может послать сообщение RGV (указания аптеки по приемулекарства) информационной системе для медсестер или другим приложениям,которым это положено в данной реализации, для каждого запланированного моментаприема лекарства в соответствии с данным заказом. Для каждого заказа может бытьпослано несколько таких сообщений.5. RAS/RXA:Информационная система для медсестер (или другое приложение) можетсформировать сообщение RAS (информация о приеме лекарства) при каждом приемелекарства пациентом. Для каждого заказа может быть послано несколько такихсообщений.