Результат лаборатории обновился: статус и версия в клинике

При интеграции лаборатории учитывайте отдельно заказ, отчёт, его версию и переданный статус. Окончательный отчёт может позднее получить исправление, поэтому нельзя молча заменять уже выданный файл и терять прежнюю историю. Сопоставление статусов согласуйте с реально выбранными системами; готовность отчёта не означает медицинскую нормальность его содержания.

Один номер заказа не описывает весь обмен

По заказу могут приходить несколько сообщений и документов. Одно относится к промежуточному состоянию, другое — к завершению, третье — к исправлению. Если сохранять только последний полученный файл под именем заказа, приложение потеряет объяснение, что было выдано раньше и к чему относится новое сообщение.

В CRM клиники предусмотрите связь пациента, заказа и конкретного отчёта через согласованные идентификаторы. Не выбирайте получателя только по похожему имени. Для технической проверки используйте вымышленные записи без анализов, диагнозов и других данных пациентов.

В FHIR R5 статусы имеют разный смысл

Набор DiagnosticReportStatus версии FHIR R5 различает partial, preliminary, final и последующие изменения, в том числе corrected. Частичный отчёт может быть неполным или непроверенным; предварительный допускает проверенные ранние данные при ещё не окончательном целом. Final описывает завершённость и проверку уполномоченным лицом, а не оценку здоровья.

Это пример конкретной спецификации, не утверждение, что любая российская лаборатория использует именно такие поля и коды. Для выбранной интеграции прочитайте её договор обмена. Нельзя сопоставить все ненулевые состояния с одной надписью «готово» только потому, что так проще выглядит интерфейс.

Учебная история одного отчёта

Ниже собственный сценарий без медицинского содержания. Р-01 — вымышленный отчёт; В-1, В-2 и В-3 — условные обозначения версий примера. Их нумерация не предлагается как универсальный способ сравнивать версии внешней системы.

Время доставки не равно порядку версий

Сообщения могут прийти повторно или с задержкой. Определите, какими данными источник обозначает отчёт, версию и отношение исправления к прежнему состоянию. Простое правило «последний входящий побеждает» способно вернуть старую версию поверх принятого исправления.

Не сортируйте произвольные внешние идентификаторы как числа без договорённости. Временная отметка тоже требует понятного смысла: создание, изменение, публикация и доставка отличаются. Если связь версий не установлена, сохраните вопрос на разбор, а не придумывайте порядок по названию файла.

Исправление не должно уничтожать след прежнего документа

Сохраняйте, какая версия была доступна и что фактически выдали через предусмотренный канал. Новое актуальное представление можно показывать отдельно от истории. Тогда сотрудник сможет установить, к какому документу относилось прежнее действие.

В автоматизации документов связывайте исправленную версию с источником и результатом обработки. Не считайте перезаписанный PDF доказательством, что все адресаты увидели исправление. Отправка, доставка и предусмотренное подтверждение остаются отдельными событиями.

Кто должен увидеть незавершённый вопрос

Клиника определяет роли и порядок работы с изменённым отчётом. Система может создать задачу уполномоченному сотруднику и показать связь версий. Она не должна сама интерпретировать медицинское значение изменения или выбирать лечение по техническому статусу.

Если задача не принята или канал обмена дал ошибку, это должно быть видно ответственным. Общая зелёная отметка «файл загружен» скрывает незавершённую работу. При этом не нужно раскрывать весь документ людям, которым достаточно организационного состояния задачи.

Неизвестный код лучше явной задачи, чем неверного перевода

Предусмотрите обработку неподдержанного статуса или изменившегося формата. Сохраните исходный код и сведения о сообщении, объясните, что сопоставление не выполнено. Не заменяйте неизвестное значение автоматически на окончательное или отменённое.

Для API-интеграции нужны согласованные правила повторов и конфликтов. Два разных содержимых с тем же заявленным ключом нельзя незаметно считать одинаковой доставкой. Такое расхождение требует диагностики по договору источника, а не тихого удаления одного варианта.

Как отделить технический мониторинг от содержания

Оператору обмена полезны идентификатор сообщения, время, результат сопоставления и открытая ошибка. Полное содержимое отчёта не обязательно должно попадать в технический журнал. Состав сохраняемых данных и доступ определяют по задачам и применимым требованиям.

В уведомлениях избегайте ненужного распространения информации. Короткая задача о поступившей версии может ссылаться на защищённый рабочий экран с подходящими правами. Это архитектурная рекомендация, а не заявление, что одна ссылка сама обеспечивает выполнение всех требований к медицинской системе.

Приёмка на синтетическом обмене

1. Создайте вымышленные заказ и отчёт без медицинских значений. Согласуйте соответствие статусов по выбранному протоколу.
2. Передайте промежуточную, затем окончательную версию. Наличие первого файла не должно завершить весь сценарий автоматически.
3. Передайте исправление после окончательной версии. Сохраните связь с ранее выданным документом и предусмотренное действие ответственному.
4. Доставьте прежнюю версию позже исправления. Проверьте, что порядок не определяется одной датой получения.
5. Повторите ту же доставку и добавьте неизвестный статус. Дубликат не создаёт лишний отчёт, неизвестность не превращается в выдуманный готовый результат.
6. Сверьте историю выдачи, принятие задачи и технический журнал. Права доступа и состав данных должны соответствовать согласованным ролям.

Готовый обмен позволяет объяснить, какой отчёт актуален, что известно о прежней выдаче и где остался открытый вопрос. Он не обещает медицинскую оценку по статусу и не подменяет работу специалистов. Это способ сохранить достоверную техническую историю между системами.