From the data we have seen so far, FRAG_NUM increases monotonically, but as mentioned in the linked question, you can get resets in the middle of a FRAG_NUM sequence (so counting can re-start from 0).
If you have access to a dictionary data structure, it's not too difficult to address the case for out of order fragments. I agree it would be nicer for the manual to specify this outright so that we don't have to guess either way.
I guess this explains the guid uniqueness:
"A single MRN data item publication is uniquely identified by the combination of RIC, MRN_SRC and GUID."
Now I'm just curious to know whether fragments belonging to the same message will always arrive in order of the FRAG_NUM. Documentation doesn't seem to confirm nor deny this.
Thanks for this. As long as we know that out of order and duplicate fragments are possible we can cater for this.
This does raise the question, if we can receive 'duplicates' (retransmissions) will the same fragment numbers always have the same boundaries, e.g. if we already have a FRAG_NUM==2, will a duplicate fragment with FRAG_NUM==2 have the same starting and ending position as the previously received fragment in the overall message? I guess it will but it would be nice to have this confirmed.