Centralized ELR - updating data elements
All, with more and more PHAs updatign their systems it seems we may be able to support more of the HHS profile elements described here: https://confluence.hl7.org/display/OO/Proposed+HHS+ELR+Submission+Guidance+using+HL7+v2+Messages
and explictly described in the currenlty balloted (Sep2020) LRI guide.
Specifcially we are getting requests to support:
#1 repeat of MSH-21 (this is a Riki request, because I that's the right thing to do if we are adding these elements into the ELR message) - to indicate we follow HHS ELR profile
#2 elements in OBX segment to OBX-29, so that 'QST' can be sent there indicatign when an OBX is reporting an AOE rather than a result
We also have observed these issues (elements that are RE in ELR, but R in surveillance systems:
#A namespace in MSH-4.1 and PID-3.4.1 - we have made this adjustment already, but anywhere else?
#B support to not have OBX-19 required, when not applicable - for example for AOEs (as it is not an analysis/test) - can be based on OBX-29 = 'QST' and
#C to allow OBX-14 to be a different date for AOEs than for results (since for results this date is the same as the specimen collection date/time) - can be based on OBX-29 = 'QST'
Please respond which of these will cause issues, so we can decide on the approach to addressing these issues.
Riki
and explictly described in the currenlty balloted (Sep2020) LRI guide.
Specifcially we are getting requests to support:
#1 repeat of MSH-21 (this is a Riki request, because I that's the right thing to do if we are adding these elements into the ELR message) - to indicate we follow HHS ELR profile
#2 elements in OBX segment to OBX-29, so that 'QST' can be sent there indicatign when an OBX is reporting an AOE rather than a result
We also have observed these issues (elements that are RE in ELR, but R in surveillance systems:
#A namespace in MSH-4.1 and PID-3.4.1 - we have made this adjustment already, but anywhere else?
#B support to not have OBX-19 required, when not applicable - for example for AOEs (as it is not an analysis/test) - can be based on OBX-29 = 'QST' and
#C to allow OBX-14 to be a different date for AOEs than for results (since for results this date is the same as the specimen collection date/time) - can be based on OBX-29 = 'QST'
Please respond which of these will cause issues, so we can decide on the approach to addressing these issues.
Riki
For Utah, we have a problem with no value in OBX.19 for AOE OBXs. We realize this isn't a test/analysis, but it is still an OBX. To process the AOEs we take the collection date from the SPM, but without a lab test date in OBX.19 for those AOE OBXs, it is throwing errors in our system. And for the actual SARS-CoV-2 result, we map the lab test date from the OBX.19 so we can't adjust our mapping specifically for AOE OBXs and have it not affect the actual test result OBX. We might be able to figure our how to do this in the future, but with so many other competing priorities, this doesn't seem like something that can get done soon. If possible, it would be great to have CELR messages populate with a date in OBX.19.
Hope this helps. Thanks! -Emily, UDOH
- OK with NC.
#2 elements in OBX segment to OBX-29
- NC very much needs that.
#B support to not have OBX-19 required, when not applicable - for example for AOEs
- OK with NC. We built logic so that if an AOE OBX-19 is empty we copy OBX-14 to OBX-19 so would not fail validation. If that tweak were to occur on the APHL side that might help other jurisdictions.
#C to allow OBX-14 to be a different date for AOEs than for results
- OK with NC.
#1 repeat of MSH-21
- Shouldn't be an issue but would want NBS vendor to confirm NBS can accept with no issue.
#2 elements in OBX segment to OBX-29
- Fine with 'QST' in OBX-29 for AOEs
#B support to not have OBX-19 required, when not applicable - for example for AOEs
- OBX-19 not required in TN but able to accept if sent.
#C to allow OBX-14 to be a different date for AOEs than for results
- This is fine with TN.