Stream: V2
Topic: Implementation in High Latency Environments
Aaron (Mar 23 2021 at 19:25):
Question about implementation of HL7v2 ADT feeds in high latency environments. Are there any widely adopted mechanisms to help maintain sequencing of ADT messages when communicating over a WAN?
I’m trying to work out how to best manage roughly 1.5 million daily ADT messages into my system over a 40 millisecond (round-trip time) environment. Simply waiting for ACK prior to firing off the next message (how I’ve always seen MLLP implemented) seems to be a problem here. Any implementers have any advice to mitigate the impact of high latencies in high volume environments?
Vassil Peytchev (Mar 23 2021 at 20:46):
Multiple MLLP connections, split by one or more of ( source | destination | mrn mod X |...)?
Aaron (Mar 23 2021 at 21:50):
Thanks. In the past, I've been able to get away with splitting feeds when patients didn't share a common patient ID so we could build isolated feeds that didn't interact with each other. In this case, there is a single source system generating the feed and we haven't identified a safe way to split the feed without the potential for one feed overlapping with another in some way.
Moving to multiple feeds will work if we can manage to determine when we are receiving a stale message.
Vassil Peytchev (Mar 23 2021 at 21:59):
If it is a single source system, wouldn't they have a unique identifier within that system? I have seen implementations where the split was on a simple hash of the identifier. The only issue to solve would be merged patients where there are two valid IDs depending on the time of the message...
Aaron (Mar 24 2021 at 13:12):
Thanks for your responses and thoughts! We were also entertaining the same concept where we split based on some attribute of the patient id and then come up with a mechanism to safely manage merges, moves, etc.
Cooper Thompson (Mar 24 2021 at 13:35):
I'm seen folks split feeds based on odd/even MRN and other stable patient-level factors. If you split the feed based on patient level data, then you don't run into per-patient FIFO issues. If your feed involves merges, you will need to handle that, but you can send the merge messages on both feeds (if the two patients have different odd/even MRNs, for example). Bed swaps and other multi-patient messages get trickier.
Last updated: Apr 12 2022 at 19:14 UTC
