ГОСТ РИСО 21090—2016
В этом выражении указано несколько иное, а именно, что нет информации о преобразовании
данного кода в систему кодирования SNOMED-CT. В отдельных случаях такая информация может ока
заться значимой, хотя такое бывает редко.
7.3.3.7.3 Атрибут updateWode
Атрибут рожима изменений updateMode принципиально важен при взаимодействии тесно свя
занных систем передачи и обработки сообщений. Тесно связанной системой является та. у которой
ограниченное число приложений используется по строго определенным соглашениям между партне
рами. а поток информации, передаваемой и принимаемой этими приложениями, хорошо организован и
понятен. В этих условиях может оказаться выгоднее договориться, что вместо передачи в каждом
сообщении всей имеющейся информации передаются только сведения об изменениях, произошедших в
каждой транзакции. Это дает то преимущество, что стоимость реализации обмена информацией су
щественно снижается как для отправителя, так и для получателя, но при этом возрастает риск потери
искажения информации, если порядок получения сообщений нарушен. Для правильного указания той
информации, которая изменилась в транзакции, требуется атрибут updateMode.
В более общем случае, например для передачи медицинских документов или электронных ме
дицинских карт, подобная обработка транзакций не применима, поэтому в таких контекстах атрибут
updateMode обычно должен иметь фиксированное значение null.
Ниже показано несколько примеров того, как атрибут updateMode может использоваться в тесно
связанных системах передачи и обработки сообщений. Эти примеры не должны рассматриваться как
рекомендуемые руководства по использованию атрибута updateMode и соответствующей обработке,
основанной на транзакциях.
В первом наборе примера рассмотрен простой случай, когда обьектная модель имеет простой
атрибут даты рождения лица birthDate:TS.
Пользователь открывает диалоговую форму для редактирования данных пациента и изменяет
дату рождения на 21 июня 1975 года. Так как в системе уже хранится дата рождения, то она заменяется.
Это приводит к тому, что тесно связанному целевому приложению передается экземпляр, содержащий
следующий фрагмент:
<birthDate value-".9Т50621" upaateMoae-"R"/>
Приложение проверяет полученную информацию, определяет, что у него дата рождения уже хра
нится и заменяет ее на вновь полученное значение. Если бы прежней даты рождения не было, то это
означало бы ошибку, хотя на практике обработка такой ситуации зависит от местных соглашений по
безопасной обработке подобных случаев.
Позже другой пользователь открывает диалоговую формудля редактирования данных пациента и
удаляет дату рохщения. Это приводит к тому, что тесно связанному целевому приложению передается
экземпляр, содержащий следующий фрагмент:
<birthDate nullFlavor-"NI" updateMode-"D"/>
Следует обратить внимание, что для придания этому значению допустимости требуется причина
пустоты nullFlavor. Данный фрагмент означает, что дата рождения должна быть удалена и заменена на
пустое значение с причиной пустоты N1. Это эквивалентно фрагменту:
<birthDate nullb’lavor-^Nl" updateMcde-"R"/>
означающему, что дата рождения должна быть заменена на пустое значение с причиной пустоты N1. Как
видно из этого примера, в подобных случаях в атрибуте updateMode нет особой необходимости. Он
становится полезным, когда необходимо различать информацию, переданную в связи с ее измене нием
(UpdateMode.R). от информации, переданной для обеспечения идентификации. Для иллюстрации этого
предположим, что в соглашении о транзакционной обработке было указано, что при изменении записи
о пациенте в качестве идентификационных данных всегда должны передаваться фамилия, имя,
отчество, пол и дата рождения. В этом случае экземпляр всегда содержит дату рождения. Исполь
зуя значение атрибута updateMode. равное «К» (ключ), можно отметить, что атрибут даты рождения
birthDate передан для идентификации, а не в связи с его изменением:
cbirthDate nullfc’Lavor-"NI" updateMode-"K"/>
28