IHE и HL7. PCD-01 ACK

Question

Я пытаюсь получить данные с монитора в приложение для Android, и я взял транзакцию IHE-PCD-01 в качестве модели.

Схема проста, основана на достижении взаимосвязи между монитором и планшетом, где монитор постоянно отправляет информацию и приложение прослушивает.

Но я не понимаю, нужен ли мне ACK или нет после каждого сообщения. Кто-нибудь может мне помочь?

Answer 1

TL; DR Да, ничего особенного здесь, поддерживайте обычный HL7 ACK/NACK, управляемый полями MSH-15, MSH-16.
ACK-ки все по умолчанию является "береженого тогда извините"

---

Документ «IHE Уход за больными устройства (PCD), Техническая структура, Том 2 (PCD TF-2) Операции, версия 1.0 - Заключительный текст , 12 августа 2011" доступен на http://www.ihe.net/technical_framework/upload/ihe_pcd_tf_vol2_ft_2011-08-12.pdf говорит

..следующего общее статическое определение подтверждения HL7 сообщения (ACK) описаны в Приложении G "Примечание по реализации HL7" ..

который говорит

Руководство G.1 сети

HL7 2,6 стандарт не определяет протокол сети связи. Начиная с HL7 2.2, определения протоколов нижнего уровня были перенесены в Руководство по внедрению, но не являются требованиями HL7. IHE Framework делает эти рекомендации:

1. Приложение должно использовать Минимальный нижний слой протокол, определенный в Приложении C Руководства по осуществлению HL7.

2. Приложение, которое хочет отправить сообщение (инициирование транзакции), инициирует сетевое подключение для начала транзакции. Приложение приемник будет реагировать с подтверждением или ответ на запрос, но не будет инициировать новые транзакции данного сетевого подключения Режимы

G.1.1 квитирования

СООБЩЕНИЯ

квитирование

квитирования сообщения могут быть определены на основе заявки. Однако может быть использовано общее сообщение подтверждения (ACK), где приложение не определяет специальное сообщение (подтверждение уровня приложения), а в других случаях, как описано в разделе 2.9 «Правила обработки сообщений».

Плата PCD-03 IHE PCD поддерживает подтверждение «расширенного режима». См обсуждение в PCD-03 сделок, а также в В.1 MSH - Message сегмент заголовка и В.2 MSA - сообщение квитирования Сегмент

и документ «Здоровье Уровень Seven, Version 2.6 © 2007, Глава 2: Контроль»идет от„2.6 пакета HL7 Messaging Standard Version“, который можно загрузить с http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185 описывает принимать и проверять поведение в

2.9.2 Ответное сообщение, используя оригинальные правила

обработки

..too долго цитировать ..

2.9.3 Ответ с использованием расширенного подтверждения

..too долго цитировать ..

в зависимости от значений MSH-15 Accept Acknowledgement Type и MSH-16 Application Acknowledgment Type полей в сообщении HL7

Вышеперечисленные главы из стандарта HL7 содержат то, что вы хотите прочитать и реализовать/поддержки.

EDIT:

Проще говоря, в протоколе HL7 в каждом сообщении отправлен отправитель может запросить ACK получения путем маркировки соответствующих полей в сегменте заголовка сообщения. IHE не удаляет это правило и не применяет никаких других, но позволяет определить любое другое соглашение на основе приложения. Правильное ожидаемое поведение определяется спецификацией HL7 и для правильной реализации и создания соответствующей реализации (без скрытых сюрпризов для ваших третьих сторон), возможно, потребуется прочитать его несколько раз (см. Также Stack Overflow: How can I make my system HL7 certified?)

Например, это это как HAPI библиотека обрабатывает ACKing, фрагмент происходит от http://sourceforge.net/p/hl7api/code/764/tree/tags/Root_REL_1_2/hapi-mvn/hapi-base/src/main/java/ca/uhn/hl7v2/protocol/impl/ProcessorImpl.java

/** 
* @see ca.uhn.hl7v2.protocol.Processor#cycle(boolean) 
*/ 
public void cycle(boolean expectingAck) throws HL7Exception { 
    log.debug("In cycle({})", expectingAck); 

    cleanReservations(); 
    cleanAcceptAcks(); 
    cleanReservedMessages(); 

    Transportable in = null; 
    try { 
     if (expectingAck) { 
      in = tryReceive(myContext.getLocallyDrivenTransportLayer()); 
     } else { 
      in = tryReceive(myContext.getRemotelyDrivenTransportLayer()); 
     } 
    } catch (TransportException e) { 
     try { 
      Thread.sleep(1000); 
     } catch (InterruptedException e1) {} 
     throw e; 
    } 

    // log 
    if (in != null) { 
      log.debug("Received message: {}", in.getMessage()); 
    } else { 
     log.debug("Received no message"); 
    } 

    // If we have a message, handle it 
    if (in != null) { 
     String acceptAckNeeded = null; 
     // String appAckNeeded = null; 
     String ackCode = null; 
     String ackId = null; 

     try { 
      String[] fieldPaths = {"MSH-15", "MSH-16", "MSA-1", "MSA-2"}; 
      String[] fields = PreParser.getFields(in.getMessage(), fieldPaths);   
      acceptAckNeeded = fields[0]; 
      // appAckNeeded = fields[1]; 
      ackCode = fields[2]; 
      ackId = fields[3]; 
     } catch (HL7Exception e) { 
      log.warn("Failed to parse accept ack fields in incoming message", e); 
     } 

     if (ackId != null && ackCode != null && ackCode.startsWith("C")) { 
      long expiryTime = System.currentTimeMillis() + 1000 * 60; 
      myAcceptAcks.put(ackId, new ExpiringTransportable(in, expiryTime)); 
     } else { 
      AcceptAcknowledger.AcceptACK ack = AcceptAcknowledger.validate(getContext(), in); 

      if ((acceptAckNeeded != null && acceptAckNeeded.equals(AL)) 
       || (acceptAckNeeded != null && acceptAckNeeded.equals(ER) && !ack.isAcceptable()) 
       || (acceptAckNeeded != null && acceptAckNeeded.equals(SU) && ack.isAcceptable())) { 
       trySend(myContext.getRemotelyDrivenTransportLayer(), ack.getMessage());  
      } 

      if (ack.isAcceptable()) { 
       if (isReserved(ackId)) { 

        log.debug("Received expected ACK message with ACK ID: {}", ackId); 

        removeReservation(ackId); 
        long expiryTime = System.currentTimeMillis() + 1000 * 60 * 5;     
        myAvailableMessages.put(ackId, new ExpiringTransportable(in, expiryTime)); 

       } else { 

        log.debug("Sending message to router"); 
        Transportable out = myContext.getRouter().processMessage(in); 
        sendAppResponse(out); 

       } 
      } else { 
       // TODO: should we do something more here? Might be nice to 
       // allow a configurable handler for this situation 
       log.warn("Incoming message was not acceptable"); 
      } 

     } 
    } else { 
     String transport = expectingAck ? " Locally driven " : "Remotely driven"; 
     log.debug("{} TransportLayer.receive() returned null.", transport); 
    } 

    sleepIfNeeded(); 

    log.debug("Exiting cycle()"); 
} 

Answer 2

Спасибо за ваш ответ :) конечно, что лучше использовать ACK, чтобы убедиться, если получатель получает сообщение, но то, что я хотел знать, было ли это обязательным или не использовать транзакцию PCD-01.

Я прочитал ваши документы и то, что я понял, что использование ACK зависит от MSH-15 и MSH-16 полей контента, но со следующей информацией:

Приложение, которое хочет отправить сообщение (инициировать транзакцию), инициирует сетевое подключение для начала транзакции. Приложение приемник будет реагировать с подтверждением или ответ на запрос, но не будет инициировать новые транзакции данного сетевого подключения

Я понимаю, что ACK только в начале соединения не после каждого сообщения, правильно ли это?