10.07.2015 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

^Определение: регистрационный номер заказа, присвоенныйприложением-заказчиком.Это поле является составным. Первый компонент представляет собой строкудлиной до 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 символов, идентифицирующую конкретный сегмент деталей заказа

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!