Encounter.ID will be based on the visit number (PV1.19) if it's a CX type and assigning authority (PV1.19.4) is set.
Assigning authority is optional, though, and visit number can also be a NM type for backwards compatibility. So it may just be a number.
When this happens, the ID/_Encounter.liquid template will use the entire PV1 segment to generate the ID, which means that an A01 admit and A03 discharge event with the same visit number may get different encounter IDs if anything else in the PV1 segment is different across the two messages (for example: admit/discharge in different rooms).
Wondering if ID/_Encounter.liquid should fall back to PV1.19.1 first before falling back to PV1 or if there's a reason for not?
Note that the Encounter template will use visit number alone in identifier -- treats the number as the value and the assigning authority as the system
Encounter.ID will be based on the visit number (PV1.19) if it's a CX type and assigning authority (PV1.19.4) is set.
Assigning authority is optional, though, and visit number can also be a NM type for backwards compatibility. So it may just be a number.
When this happens, the
ID/_Encounter.liquidtemplate will use the entire PV1 segment to generate the ID, which means that an A01 admit and A03 discharge event with the same visit number may get different encounter IDs if anything else in the PV1 segment is different across the two messages (for example: admit/discharge in different rooms).Wondering if
ID/_Encounter.liquidshould fall back to PV1.19.1 first before falling back to PV1 or if there's a reason for not?Note that the Encounter template will use visit number alone in
identifier-- treats the number as thevalueand the assigning authority as thesystem