L Problem table: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
No edit summary
m Text replacement - "[[Category: " to "[[Category:"
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:L_Problem table}}The [[L_Problem table]] in [[Centralized data.mdb]] contains [[known data errors]] to exclude them from several [[CFE Data Integrity Checks]]. This could be needed because we deliberately decided they were not worth fixing, or because a [[cross check]] delivers a false positive in some circumstances.  
{{DISPLAYTITLE:L_Problem table}}The [[L_Problem table]] in [[Centralized_data.accdb]] contains [[known data errors]] to exclude them from several [[CFE Data Integrity Checks]]. This could be needed because we deliberately decided they were not worth fixing, or because a [[cross check]] delivers a false positive in some circumstances.  


It is manually populated by the [[data processor]] as she encounters the errors or false positives, for example as part of [[vetting]].
It is manually populated by the [[data processor]] as she encounters the errors or false positives, for example as part of [[vetting]].
Line 24: Line 24:
|join on=DataIntegrityChecks._pageName=_pageData._pageName,DataIntegrityChecks._pageName=Discussions._pageName
|join on=DataIntegrityChecks._pageName=_pageData._pageName,DataIntegrityChecks._pageName=Discussions._pageName
|fields=
|fields=
CONCAT("\[\{\{fullurl:",DataIntegrityChecks._pageName, "{{!}}action=edit\}\} edit]")=edit,
DataIntegrityChecks._pageName=page, Status, Timing, Summary, Status
DataIntegrityChecks._pageName=page, Status, Timing, Firmness, Summary, question, who
|where=App="Centralized data front end.accdb " and (Status<>"retired" and Status<>"declined") and (L_Problem=true or L_Problem is null)
|where=App="Centralized data front end.accdb " and (Status<>"retired" and Status<>"declined") and L_Problem=true
|order by=question  
|order by=question  
|limit=0
|limit=20
|more results text=Link to table of cross-checks that use [[L_Problem table]] to exclude false-positives
|more results text=Link to table of cross-checks that use L_Problem table to exclude false-positives
|default=Nothing found
|default=Nothing found
|format=dynamic table
|format=dynamic table
|rows per page=1000
|rows per page=20
}}
}}


Line 38: Line 37:
{{Related Articles}}
{{Related Articles}}


[[Category: Data structure]]
[[Category:Data structure]]
[[Category: Data Processing]]
[[Category:Data Processing]]
[[Category:Data Processing]]
[[Category:Data Processing]]
[[Category:Centralized data front end.accdb]]
[[Category:Centralized data front end.accdb]]
[[Category:Centralized data.mdb]]
[[Category:Centralized_data.accdb]]

Latest revision as of 11:34, 30 July 2025

The L_Problem table in Centralized_data.accdb contains known data errors to exclude them from several CFE Data Integrity Checks. This could be needed because we deliberately decided they were not worth fixing, or because a cross check delivers a false positive in some circumstances.

It is manually populated by the data processor as she encounters the errors or false positives, for example as part of vetting.

L_Problem contains the fields

field type description
D_ID long unique record ID
Query text One of the following:
Notes text further explanations, eg why the error was not corrected or why it is a false positive

List of cross-checks that use L_Problems

page Status Timing Summary
page Status Timing Summary
Query NDC dx implying death across encounters implemented always Category:Diagnosis implying death across encounters
Link suspect dead then alive query implemented always Used in Correcting suspect links to find records where an earlier record with that PHIN was listed as dispo field deceased, but a later entry then shows up.
Link suspect negative transit time query implemented always Used in Correcting suspect links to find records where an earlier record for a patient with that PHIN has a Dispo DtTm that is later than the next record's Admit DtTm.
Link suspect mismatch pre inpt ours incomplete query implemented always Checks for patients where Pre-admit Inpatient Institution is one of ours but we don't have a corresponding record.
Link suspect mismatch pre inpt should be ours incomplete query implemented always What is description
Query cardiac arrest throughout admission ready to implement complete Any patient who is admitted to ICU from Med or another ICU with a #Cardiac Arrest dx should have one in their immediately preceeding Med or ICU record also.
Link suspect visitAdmitDtTm mult to-from-home query ready to implement always Checks for records that are likely part of the same admission but have different Visit Admit DtTm field.

Related Articles

Related articles: