|
|
| Line 2: |
Line 2: |
|
| |
|
| This article contains requested changes for [[Centralized data front end.mdb]]. See [[Centralized data front end.mdb Change Log]] for it's change log. | | 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 === | | === Error Checking Queries required === |
| Line 14: |
Line 8: |
| === SAS Views === | | === SAS Views === |
| * implement [[Created Variables in TMSX or Med TMS]] | | * 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) {{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.
| |
|
| |
|
|
| |
|
| [[Category: Development Documentation]] | | [[Category: Development Documentation]] |
| [[category:2013 data upgrades]] | | [[category:2013 data upgrades]] |