SD1023 - Check isn't designed properly

The issue seems to have been fixed in next validator version 1.4

Randall,

We had experience with that check also; the 1.4 validator seems to have addressed it to not produce the unwarranted warning anymore.

Best,

Joan

SD1023

The message and description are

• VISIT/VISITNUM values do not match TV domain data
• "Combination of Visit Name (VISIT) and Visit Number (VISITNUM) in subject-level domains should match that in the TV domain with the exception of Unscheduled and Unplanned visits"

I think Randal may be right though in that the rule eliminates unscheduled visits based on these text comparisons. 

VISIT is not null

VISIT <>  Upper('UNPLAN')

VISIT <>  Upper('UNPLANNED')

VISIT <> Upper('UNSCHED%')

Let me look into this.   the other area for improvement is assigning this rule to SV domain as well.

Visit Rules SD1017,18,19,23

I see the problem clearer now.  

• Checks SD1017,18,19 ensure consistency with SV domain against TV domain (except 19).
• Check 1023 ensures consistency between all subject domains and TV.   The problem is that the SVUPDES field is not available at the subject domain level.   Although based on your unscheduled visit format Randall, i'm wondering why you get those errors?   They appear to match our criteria for eliminating unscheduled visits

Check SD1023 should be retired

Because checks 0065, 1017, 1018 already cover the responsibility of check 1023. Having check 1023 not only introduces false positive as reported above, it also duplicates the error messages already reported by 0065+1017+1018.

(Just in case the logic is not clear: A. If subject domains agree with SV, and SV agrees with TV --> subject domains agree with TV. and B. If subject domains do not agree with TV --> either subject domains do not agree with SV, or SV does not agree with TV, or both)

Programmers in our company still experience this issue in V1.4.

If check SD1023 is to stay, then please modify the check so that it uses SV to identify unplanned visits, not based on the spelling of VISIT.

Check SD1023 should be retired

Because checks 0065, 1017, 1018 already cover the responsibility of check 1023. Having check 1023 not only introduce the false positive, it also duplicates the error messages already reported by 0065+1017+1018.

Just in case the logic is not clear: A) If subject domains agree with SV, and SV agrees with TV --> subject domains agree with TV. and B) If subject domains do not agree with TV --> either subject domains do not agree with SV, or SV does not agree with TV, or both

Programmers in our company still experience this issue in V1.4.

If check SD1023 is to stay, then please modify the check so that it uses SV to identify unplanned visits, not based on the spelling of VISIT.

Hi Jim,  Based on our

Hi Jim, 

Based on our experience SD1023 is a valid and valuable check. The issues related to violation of the SD1023 business rule are still in the Top10 list.

A combination of 0065+1017+1018 is not the same as SD1023.

We are still collecting statistics to create a more intelligent algorithm for filtering of Unplanned and Unscheduled visits to avoid false-positive messages. The usage info from the SV domain for this purpose will be tricky because there is no guarantee that those data are 100% correct. E.g., something like an "ALL VISITS" value may have description in SVUPDES. 

Could you share your particular cases as examples where SD1023 produces false-positive messages?

Regards, 

Sergiy