Centralized data front end.accdb Change Request: Difference between revisions
Ttenbergen (talk | contribs) |
Ttenbergen (talk | contribs) No edit summary |
||
| Line 21: | Line 21: | ||
3. If she can’t find a match, she assigns the next pseudo PHIN number in her booklet to that patient. | 3. If she can’t find a match, she assigns the next pseudo PHIN number in her booklet to that patient. | ||
Propose we integrate this with the "PHIN Blank" check we are working out as part of [[ | Propose we integrate this with the "PHIN Blank" check we are working out as part of [[Centralized_data Vetting Process]]. If blank PHIN is found, check if the name/dob/chart match elsewhere. If so, use that PHIN. If not, find highest previous Pseudo-PHIN and assign x+1. | ||
This would mean that "blank PHIN" should be the first check applied so that all others don't trigger for this. Also, since the assignment of a new PHIN is a known and frequent process, this would likely benefit from automation. Any thoughts? Ttenbergen 12:45, 2014 January 13 (CST) {{discussion}} | This would mean that "blank PHIN" should be the first check applied so that all others don't trigger for this. Also, since the assignment of a new PHIN is a known and frequent process, this would likely benefit from automation. Any thoughts? Ttenbergen 12:45, 2014 January 13 (CST) {{discussion}} | ||
Revision as of 12:52, 13 January 2014
see the Development Documentation Category for other development logs
This article contains requested changes for Centralized data front end.mdb. See Centralized data front end.mdb Change Log for it's change log.
Requested Changes
Confirm Date_of_Birth#Age is right. Ttenbergen 12:18, 2014 January 13 (CST)
automate re-linking of tables
Ask for the phi and centralized directories and reconnect.
Error Checking Queries required
we should probably revisit Category:Cleaner.mdb Data Integrity Checks in this context.
SAS Views
- implement Created Variables in TMSX or Med TMS
Automate PseudoPHINs
As per email from Julie Mon 2013/Mar/18 15:27: 1. first search the database for that patient 2. if she finds a match in patient name and DOB and found out that the patient has already been assigned with a pseudo phin, she uses the same pseudo phin. If she finds that there was a PHIN instead of pseudoPHIN, she checked in other sources –KEAH / MB Health/ TISS addressograph to verify if indeed correct and then decide whether to use that PHIN. 3. If she can’t find a match, she assigns the next pseudo PHIN number in her booklet to that patient.
Propose we integrate this with the "PHIN Blank" check we are working out as part of Centralized_data Vetting Process. If blank PHIN is found, check if the name/dob/chart match elsewhere. If so, use that PHIN. If not, find highest previous Pseudo-PHIN and assign x+1. This would mean that "blank PHIN" should be the first check applied so that all others don't trigger for this. Also, since the assignment of a new PHIN is a known and frequent process, this would likely benefit from automation. Any thoughts? Ttenbergen 12:45, 2014 January 13 (CST) Template:Discussion
column headers
Variables headers for Registry, APACHE,SAPS, ADL elements – you may not necessarily make them in separate tables to be consistent with Ed’s output tables. Putting them together as in the L_Log but using the same headers as ED’s ( can be called as L_log of front end) are just fine. This will be less work in my end because I don’t need to merge these individual tables together.
Data formats
Data type/values for VERBAL, CHRONIC , ADMIT TYPE , RENAL, ADL - these need conversion as we had agreed and they are included under the L_Log of Front end.