(например 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