android - IHE 和 HL7。 PCD-01 确认

Question

我正在尝试将数据从监视器获取到 Android 应用程序，我已将 IHE - PCD-01 事务作为模型。

方案很简单，就是基于实现显示器和平板的互联，显示器不断发送信息，应用监听。

但我不明白的是我是否需要在每条消息后收到 ACK。有人可以帮我解决这个问题吗？

Answer 1

TL;DR 是的，这里没有什么特别的，支持由 MSH-15、MSH-16 字段驱动的通常的 HL7 ACK/NACK。
默认情况下对所有内容进行 ACK 是“更好安全然后抱歉”

---

文档“IHE 患者护理设备 (PCD)，技术框架，第 2 卷 (PCD TF-2) 交易，修订版 1.0 - 最终文本，2011 年 8 月 12 日”，网址为 http://www.ihe.net/technical_framework/upload/ihe_pcd_tf_vol2_ft_2011-08-12.pdf说

..The common static definition of the HL7 acknowledgement (ACK) message is described in Appendix G, "HL7 Implementation Notes"..

说

G.1 Network Guidelines

The HL7 2.6 standard does not define a network communications protocol. Beginning with HL7 2.2, the definitions of lower layer protocols were moved to the Implementation Guide, but are not HL7 requirements. The IHE Framework makes these recommendations:

1. Applications shall use the Minimal Lower Layer Protocol defined in Appendix C of the HL7 Implementation Guide.

2. An application that wants to send a message (initiate a transaction) will initiate a network connection to start the transaction. The receiver application will respond with an acknowledgement or response to query but will not initiate new transactions on this network connection

G.1.1 Acknowledgment Modes

ACKNOWLEDGMENT MESSAGES

Acknowledgment messages may be defined on an application basis. However the simple general acknowledgment message (ACK) may be used where the application does not define a special message (application level acknowledgment) and in other cases as described in Section 2.9, "Message Processing Rules".

The IHE PCD transaction PCD-03 supports „enhanced mode‟ acknowledgements. See discussion under PCD-03 Transactions as well as in B.1 MSH – Message Header Segment and B.2 MSA – Message Acknowledgement Segment

和文档“Health Level Seven, Version 2.6 © 2007, Chapter 2: Control”来自“HL7 Messaging Standard Version 2.6”包，可以从http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185 下载。描述接受和验证行为

2.9.2 Message response using the original processing rules

..too long to quote..

2.9.3 Response using enhanced acknowledgement

..too long to quote..

取决于 HL7 消息中 MSH-15 Accept Acknowledgment Type 和 MSH-16 Application Acknowledgment Type 字段的值

HL7 标准的上述章节包含您想要阅读和实现/支持的内容。

编辑:

简单地说，在 HL7 协议(protocol)中，在发送的每条消息中，发送方都可以通过在消息头段中标记适当的字段来请求 ACK 接收。 IHE 不会删除此规则，也不强制执行任何其他规则，但可以在应用程序基础上定义任何其他约定。正确的预期行为由 HL7 规范定义，为了正确执行并创建符合要求的实现(没有给您的第 3 方带来隐藏的惊喜)，您可能需要多次阅读它(另请参见 Stack Overflow: How can I make my system HL7 certified?)

例如这就是HAPI库处理 ACKing， fragment 来自 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()");
}