我試圖從監視器獲取數據到Android應用程序,並將IHE-PCD-01事務作爲模型。IHE和HL7。 PCD-01 ACK
該方案簡單,基於實現顯示器和平板電腦之間的互連,監視器不斷髮送信息和應用程序正在監聽。
但我不明白的是,如果我在每封郵件後都需要一個ACK。有人可以幫助我嗎?
我試圖從監視器獲取數據到Android應用程序,並將IHE-PCD-01事務作爲模型。IHE和HL7。 PCD-01 ACK
該方案簡單,基於實現顯示器和平板電腦之間的互連,監視器不斷髮送信息和應用程序正在監聽。
但我不明白的是,如果我在每封郵件後都需要一個ACK。有人可以幫助我嗎?
TL; DR是的,這裏沒什麼特別的,支持MSH-15,MSH-16字段驅動的通常的HL7 ACK/NACK。
ACK-ING一切都默認爲 「更好的安全,然後對不起」
「IHE病人護理設備(PCD)文件,技術框架,第2卷(PCD TF-2)的交易,修訂版1.0 - 最終文本8月12日,2011" 可在http://www.ihe.net/technical_framework/upload/ihe_pcd_tf_vol2_ft_2011-08-12.pdf說
(ACK)消息中的附錄G中描述的HL7確認,的..The普通的靜態定義 「HL7實現說明」 ..
其說
G.1網絡準則
的HL7 2.6標準沒有定義的網絡通信協議。從HL7 2.2開始,較低層協議的定義已移至「實施指南」,但不是HL7的要求。 IHE的框架,使這些建議:
應用程序將使用在HL7實施指南的附錄C中定義的最小低層協議。
想要發送消息(啓動事務)的應用程序將啓動網絡連接以啓動事務。接收端應用程序將與確認或響應於查詢進行響應,但此網絡連接
G.1.1確認模式的信息將不會啓動新事務
確認消息
確認消息可以被定義在申請的基礎上。然而,可以使用簡單的通用確認消息(ACK),其中應用程序未定義特殊消息(應用程序級別確認)並且在其他情況下如第2.9節「消息處理規則」中所述。
IHE PCD事務PCD-03支持「增強模式」確認。參見PCD-03交易以及B.1 MSH-消息報頭段和B.2 MSA消息確認段下的討論
和文檔「Health Level Seven,Version 2」。6©2007,第2章:控制可以從http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185下載HL7消息標準版本2.6‘包裝」從未來’描述了使用原來的處理規則
在2.9.2消息響應的接受和驗證行爲
..too長引述..使用增強確認
2.9.3響應
..too長引述..
取決於在HL7消息
MSH-15 Accept Acknowledgement Type
和MSH-16 Application Acknowledgment Type
字段的值從HL7標準以上章節包含你想讀和執行/支持什麼。
編輯:
簡單地說,在HL7協議在每個消息中發送的發送者可以通過在消息頭部段標記相應的字段請求ACK
收據。 IHE不刪除這條規則,也沒有強制執行任何其他規定,但是可以在應用基礎上定義。正確的預期行爲是由HL7規範定義的,爲了讓它正確並創建一個符合實現(對於第三方沒有隱含的意外),您可能需要多次讀取它(另見Stack Overflow: How can I make my system HL7 certified?)
例如,this是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()");
}
謝謝您的回答:)當然,最好是使用一個ACK,以確保如果接收器收到消息的 ,但我想要的東西知道它是否是強制使用PCD-01交易。
我讀過你的文件,並就我的理解是,使用ACK取決於內容的MSH-15和MSH-16場,但具有下列信息:
一個應用程序,想要發送消息(啓動事務)將啓動網絡連接以啓動事務。接收器應用程序將回應一個確認或響應查詢,但不會啓動此網絡連接上的新交易
我知道ACK只在連接的開始而不是每個消息後,是不是?
最好(也是正常的)確認每條消息,並在一段時間後重新發送,如果你沒有得到答覆。否則信息可能會丟失。有時PCD類型的消息沒有確認消息發送,因爲沒有人願意花費任何時間丟失消息 - 它們會丟失,並且會在別處發出警報。 (我不知道IHE會怎麼說) – 2014-11-06 19:01:58
**否**,如果您(作爲應用程序創建者)沒有另外指定,則在每條消息或每條第二條消息之後也是允許的方案。請參閱我編輯的答案以獲得更多指示 – xmojmr 2014-11-07 09:04:33