Processing errors in patient data: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
m (moved this question and answer to link_suspect_negative_transit_time query )
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Discuss | who=Pagasa | question =
* It is not really clear what the steps are for Link Suspect Negative Transit Time in regards to checking and correcting between EPR and Centralized Data. --[[User:Srusnak|Srusnak]] 17:32, 2017 January 5 (CST) }}
Errors or inconsistencies may be discovered during many of our [[#Quality control processes that might detect errors]]. This article describes how to process them.
Errors or inconsistencies may be discovered during many of our [[#Quality control processes that might detect errors]]. This article describes how to process them.


Line 14: Line 11:


==Contact the data collector for additional info==
==Contact the data collector for additional info==
If the previous step does not fix the problem, contact the data collector using the [["email collector about patient data" button]]. This will set the [[RecordStatus field]] to "questioned" and exempt it from [["Vet all sent" button | being vetted]].
If the previous step does not fix the problem:
 
* contact the data collector using the [["email collector about patient data" button]] or the [["copy patient demographics for questioning" button]] as works better for the problem at hand.  
** This will set the [[RecordStatus field]] to "questioned" for "sent" and exempt it from [["Vet all sent" button | being vetted]].
 
{{TT | _dev_CFE
Automate the populating of notes so button just does it.
* raise an input box for a summary, if gets content put data and content into Notes, else put nothing.}}


{{Discuss | who=Pagasa | question =
'''''Rest of section probably needs to go; if any entries in notes field remain from this do we need to clean them up?'''' Ttenbergen 13:49, 2015 August 17 (CDT) }}


*As of Dec 9.14 - processor to put in beginning of NOTES" the following: Question:date sent: what question was asked.
=== when resolved ===
*if question is resolved she removes the notes when she reset record status from Question, back to SENT.
*When question is resolved [[Data processor]]
*record status is automatically set to '''question''' if Process uses the paste clipboard button.  Change of record status should only apply to SENT patients.
* removes the notes if it makes sense to do so
**'''
* resets [[RecordStatus]] from "questioned" back to "sent"


== Editing Patient_ID, location or D_ID ==
== Editing Patient_ID, location or D_ID ==
'''Patient_ID''' and '''location''' are used to generate the '''D_ID'''. If one of these needs to be edited, make sure the corresponding edits are done in both [[L_Log table]] and [[L PHI table]].
'''Patient_ID''' and '''location''' are used to generate the '''D_ID'''. If one of these needs to be edited, follow [[Changing D IDs]].


== Incomplete patients ==
== Incomplete patients ==
Line 32: Line 34:


== False Positives or known errors ==
== False Positives or known errors ==
If a query finds an error and review of the data shows that the data is correct then consider if this is a query that is can have false positives (e.g. visitAdmitDtTms that are really close together) or that should never have false positives (e.g. died and then re-admitted).  
If a query finds an error and review of the data shows that the data is correct then consider if this is a query that is can have false positives (e.g. visitAdmitDtTms that are really close together) or that should never have false positives (e.g. died and then readmitted).  
#* if can have false positives then treat as [[Known data errors]]
* if can have false positives then treat as [[Known data errors]]
#* if cannot have false positives then discuss problem with Tina or Herman to correct the query; '''don't''' treat as [[Known data errors]]
* if cannot have false positives then discuss problem with Tina or Herman to correct the query; '''don't''' treat as [[Known data errors]]


== Quality control processes that might detect errors ==
== Quality control processes that might detect errors ==
Line 41: Line 43:
** [[Correcting suspect links]]
** [[Correcting suspect links]]
** [[Quality Assurance queries in CFE]]
** [[Quality Assurance queries in CFE]]
== Related articles ==
{{Related Articles}}




[[Category: Data Processing]]
[[Category: Data Processing]]

Latest revision as of 14:22, 2022 March 24

Errors or inconsistencies may be discovered during many of our #Quality control processes that might detect errors. This article describes how to process them.

When an error or inconsistency is found, #Correct error from available sources for the correct information where possible. If that does not provide the needed information, #Contact the data collector for additional info.

Process any false positive or uncorrectable records as Known data errors.

Correct error from available sources

If the required change is obvious, apply it. An example for this would be a switch of two digits in a field where several previous records are available for the same patient.

If there is no obvious fix, consult the EPR.

Contact the data collector for additional info

If the previous step does not fix the problem:


_dev_CFE

Automate the populating of notes so button just does it. 
  • raise an input box for a summary, if gets content put data and content into Notes, else put nothing.
  • added: no added date
  • action: no action date
  • Cargo


  • Categories


when resolved

  • When question is resolved Data processor
  • removes the notes if it makes sense to do so
  • resets RecordStatus from "questioned" back to "sent"

Editing Patient_ID, location or D_ID

Patient_ID and location are used to generate the D_ID. If one of these needs to be edited, follow Changing D IDs.

Incomplete patients

If errors are found in incomplete patients any fixes done to CFE will be overwritten the next time the data is sent. Because of this, make sure to ask the data collector to make the same changes to their record.

False Positives or known errors

If a query finds an error and review of the data shows that the data is correct then consider if this is a query that is can have false positives (e.g. visitAdmitDtTms that are really close together) or that should never have false positives (e.g. died and then readmitted).

  • if can have false positives then treat as Known data errors
  • if cannot have false positives then discuss problem with Tina or Herman to correct the query; don't treat as Known data errors

Quality control processes that might detect errors

Related articles

Related articles: