Specification - Extended

HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes DSTU Release 2.1 - US Realm

Document Description

extended per extended per TSC tracker 12437, again with 14128 and jira.hl7.org/browse/TSC-38

Existing Wording

The US Realm Address and US Realm Patient Name templates both make it clear that nullFlavors are allowed. (Of course, if you know a patient's name and address you should send them, and stuff like USCDI requires this anyway, but if, say, you genuinely don't know a patient's address, it's not like that's supposed to make it impossible to send a C-CDA document about them.) * If addr/@nullFlavor is present, the remaining conformance statements SHALL NOT be enforced * If name/@nullFlavor is present, the remaining conformance statements SHALL NOT be enforced However, because these caveats are just written as free text in the IG, the schematron doesn't recognize them and still throws errors when these elements have a nullFlavor. This affects the following schematron rules: * r-urn-oid-2.16.840.1.113883.10.20.22.5.1-errors * r-urn-oid-2.16.840.1.113883.10.20.22.5.1.1-errors * r-urn-oid-2.16.840.1.113883.10.20.22.5.2-errors As well as the following two asserts: * a-1198-10483-c * a-1198-10484-c

Proposed Wording

Each of the three rules above has a context comprising a long list of places where the name or address may appear. Since what we really want is for these rules to apply to such elements that also don't have a nullFlavor, I think the best fix is to change the rule to reflect that. (That said, I'm not sure if there's an easy way to do this in Trifolia and have it persist across future changes to the schematron.) For example: Before: After: The same addition of [not(@nullFlavor)] to each cda:name or cda:addr should work for the other two rules as well. As for the asserts, I think there's no easy way to fix those other than to manually add in the option for a nullFlavor: