последовательная или параллельная обработка сообщений hl7

Мне было интересно, какие модели параллелизма используют люди для обработки входящих сообщений hl7 (adt,...) и сохранения их в нормализованной модели данных (реляционной или не-sql).

Я борюсь с мыслью о последовательной обработке сообщений (сопоставление с базой данных nosql) и многопоточности при преобразовании/обработке их из (java, .net, что угодно):

пример: если я обрабатываю сообщения, полученные и преобразованные клеверным листом (преобразованные для соответствия ожидаемой полезной нагрузке внутреннего веб-/остального API) и настроены на внутренний веб-сервер/остальный API-сервер (многопоточное веб-приложение Java), тогда я не могу гарантировать, что я анализирую сообщения последовательно из-за многопоточности.

если я обрабатываю сообщения последовательно, то сопоставление будет медленным...


hapi mirth hl7 hl7-v2 c-cda
person Sbham    schedule 16.10.2015    source источник
comment
IHE описывает транзакции обработки сообщений с использованием диаграмм последовательности UML с преимущественно синхронными сообщениями.   -  person xmojmr    schedule 16.10.2015

Ответы (2)


arrow_upward
3
arrow_downward

Возможность асинхронной обработки сообщений зависит от характеристик сообщений и вашей логики обработки. Рассмотрим эту последовательность:

  1. вы получаете регистрацию для нового пациента
  2. вы получаете эпизод, указанный против пациента
  3. вы получаете сообщение о слиянии нового пациента с другим пациентом

Что произойдет, если вы обработаете последнее сообщение перед предпоследним? будете ли вы рассматривать это как ошибку, потому что у вас есть новый эпизод объединенного пациента?

Вот почему нет простого ответа на этот вопрос. Это зависит

person Grahame Grieve    schedule 16.10.2015

arrow_upward
1
arrow_downward

Если отправляющее приложение использует MLLP, у вас может не быть другого выбора, кроме как выполнять последовательную обработку. Большинство клиентов MLLP будут ждать подтверждения принятия перед отправкой следующего сообщения.

Во многих случаях использования в здравоохранении последовательность имеет значение. Например, если отправляющее приложение создает сообщения ORU^R01, оно может сначала отправить предварительные результаты, а затем окончательные результаты. Если вы представляете эти данные пользователям, вы не хотели бы, чтобы предварительные результаты перезаписывали окончательные результаты только потому, что ваше приложение обрабатывало сообщения не по порядку.

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

person Nick Radov    schedule 16.10.2015
comment
Спасибо вам за отзыв. - person Sbham; 25.10.2015