-
Certification
-
Resolution: Done
-
Minor
-
None
-
A confusing Postal Code warning message is generated even if a valid postal code is provided.
-
DECC/PQRS
-
Dave Wade
-
The actual constraint should be rewritten or, alternatively, the requirement that the code be validated should be ignored.
In the 2016 Base QRDA-1 HL7 IG (i.e. "HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture Category I (QRDA I); Release 1, DSTU Release 3 - US Realm, Draft Standard for Trial Use, Volume 2 - Templates and Supporting Material, June 2015") there is this constraint for the Postal Code in the US Realm Address section...
5. SHOULD contain zero or one [0..1] postalCode, which SHOULD be selected from ValueSet PostalCode urn:oid:2.16.840.1.113883.3.88.12.80.2 DYNAMIC (CONF:81-7294).
It is beyond our current capabilities to maintain a current PostalCode valueSet and, as far as I know, no such valueSet currently exists.
Besides that problem, this constraint is very badly written. There are actually two separate constraints but only one CONF number.
This constraint should be rewritten as simply...
5. SHOULD contain zero or one [0..1] postalCode (CONF:81-7294).
Due to these problems, the ESAC provided Schematron assertion for this constraint opted to always display the warning whenever a US Realm Address is provided. They did this by coding the assertion like this...
<sch:assert id="a-81-7294-c" test="not(.)">SHOULD contain zero or one [0..1] postalCode, which SHOULD be selected from ValueSet PostalCode urn:oid:2.16.840.1.113883.3.88.12.80.2 DYNAMIC (CONF:81-7294).</sch:assert>
The 'test="not(.)"' means that the assertion always fires.
This problem was handled in 2014 and 2015 but ignoring the validation half of the constraint and only firing if the user did not provide a postalCode. Considering that the base HL7 IG will probably not be corrected anytime soon, this constraint should be handled the same way it was handled in the two previous years.