|
|
| (45 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| Data Repository containing:
| | ''see also [[Centralized_data.accdb Change Log]] |
| * [[Serial number]]
| | Centralized.data.mdb is a data repository containing a de-identified copy of all data sent from Critical Care and Medicine. Indentifiers are stored in [[PHI.mdb]] which is accessible only to [[:Category:Main Office|main office]]. |
| * [[Location field|Location]]
| | ==Live Date== |
| * [[Admit%2C_Transfer_and_Discharge_date_and_time#Admit_Date_and_Time | admit, transfer and discharge dates and times]]
| | May 20, 2014 |
| * [[Survive / Expired]]
| |
| * [[Med Var 1 - Admit-from Ward]] you will be able to send without this, but Julie will not get all the data she needs to link patient stays together
| |
| * [[Med Var 2 - Discharge-to Ward]] you will be able to send without this, but Julie will not get all the data she needs to link
| |
|
| |
|
| == Sending to ... == | | == Location == |
| {{Discussion}} | | {{Regionalserver|Output\[[Centralized_data.accdb]]}} |
| Meeting: Thur April 18 @ 1100 hrs IN JJ387 to review. Tina, Trish Julie[[User:TOstryzniuk|Trish Ostryzniuk]] 19:27, 2013 April 11 (EDT)
| |
|
| |
|
| | == Availability == |
| | [[Centralized_data.accdb]] might not be available at its network location outside of [[Designated sending times]]. See [[Pull down centralized data.vbs]] if it needs to be retrieved locally. |
|
| |
|
| [[CCMDB.mdb_Change_Log_2012#ver_2012-12-21 | version 2012-12-21]] implemented sending of data to Centralized_data.mdb.
| | ==Password== |
| | Located: {{M:|Passwords_MainOffice_use}} |
|
| |
|
| | == How does data get into [[Centralized_data.accdb]] == |
| | see [[Sending Patients]] |
|
| |
|
| This is accomplished by queries
| | == Dependencies == |
| * "Send_Centralized_update" (update existing records to data currently in the collector's ccmdb_data.mdb)
| | [[TISS28 Data.mdb]] pulls data from [[Centralized_data.accdb]]. |
| * "Send_Centralized_append" (append new records from the collector's ccmdb_data.mdb)
| |
|
| |
|
| {{Discussion}}
| | == Legacy == |
| ** why do we need 2 separate queries? - I think one is enough which will do both. If the DC sends their profiles from their ccmdb_data.mdb to the Centralized_data.mdb, the updating and/or appending should both occur depending on whether the profiles are previously sent or not - see below for more details. One important data I need is the field that will differentiate the completed profiles from incomplete ones (i.e. outstanding/ patients who are still in unit/ward). If that is already present, I need to know the label name. [[User:JMojica|JMojica]] 13:03, 2013 April 9 (EDT)
| | [[Conversion of Centralized data.mdb to Centralized data.accdb]] - some places refer to a .mdb, same file earlier version |
| *** I use two queries instead of a field to state if final. First query updates fields if a matching record exists. Second query adds the record if a matching record does not exist. Same idea, just done differently. The dataset does not keep track of whether the patient is final-checked. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| **We need it to be tracked. As mention further down about tagging completed released files with "Locked" tag as once final checked and sent.[[User:TOstryzniuk|Trish Ostryzniuk]] 19:19, 2013 April 11 (EDT)
| |
|
| |
|
| * If this is working as intended then any updates Pagasa makes to fix bad data will be re-overwritten with the bad data on the collection laptop every time the collector sends. Possible remedies are to make collectors delete sooner after sending or getting Pagasa to email collectors to fix errors at the root and waiting for that to update the dataset. That is assuming it works as intended. From your experience with the entries in L_Log and the sending/data retention habits of the collectors involved, does it sound like this is how it is working? Ttenbergen 18:05, 2013 April 8 (EDT)
| | == Related articles == |
| | | {{Related Articles}} |
| *[[User:JMojica|JMojica]] 11:24, 2013 April 9 (EDT) Here is my suggestion - Populate the Centralized_data.mdb from DC's laptop at sending time (once a week), not when the DCs back-up their data at laptop . The data will include both those "Final checked" as completed and "locked" after sent and also include those files that are incomplete.
| |
| ** It's already done at send time only. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| | |
| *On next's time sending (normally the following week or whatever frequency we decide), DC must make sure that the previously sent 'completed' are already removed from their laptop. This is required to avoid overwriting the data already in the Centralized_data.mdb which may have been changed by Pagasa due to some errors.
| |
| ** I am open to that if there are no collection concerns from Pagasa and Trish, and if they are willing to push that through with collectors. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| **another option, create another column, when completed files are FINAL CHECKED & SENT button is pressed, they are marked by the program as "Locked". Locked meaning: Data collectors would no longer be able RESEND to central.mdb or Edit them on their laptops. Also your programming will exclude them from the next sending if they haven't deleted. Once tagged with "locked" collector should not be able to edit on laptop(what decided as intuitive label. Any data that is FINAL CHECK and was SENT with final check, to central.mdb, any editing will only be under main office control. The delete sent files button then will only deleted those patient that have been tagged as LOCKED not those that are final checked. Collectors can then choose when to delete sent files rather than forcing auto delete after sending. Example. Debbie PN keeps profiles on her laptop for a week or more sometimes because of frequent readmissions within a week of discharge (as she stated in past). She can refer to comorbids and other pt ID information which would not have change. She is away on vacation until May 2 so, can't confirm her current practice.[[User:TOstryzniuk|Trish Ostryzniuk]] 19:11, 2013 April 11 (EDT)
| |
| | |
| *There will be again a batch of completed profiles, some are new and some are already included in the last week's sent; and another batch of incomplete profiles, some are new and some are already included in the last week's sent. Upon sending, these will populate the Centralized_data.mdb. Those previously incomplete profiles but are now complete will be overwritten (e.g. all data will be updated).
| |
| * Those previously incomplete profiles but still incomplete in this sending will also be overwritten (e.g. some data will be updated).
| |
| ** Both of those are what the update query does. It does not distinguish between complete/incomplete, doesn't need to. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| | |
| * Those with no previous profiles (complete or incomplete) will just be appended.
| |
| ** That's what the append query does.
| |
| | |
| * Finding Errors - The integrity checks of data will be applied to both complete and incomplete profiles.
| |
| ** We can do that. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| | |
| * Fixing Errors - Pagasa will do the fixing of errors in the Centralized_data.mdb but only for those with complete profiles. If Pagasa finds errors in the data of the incomplete profiles, she will tell the error(s) to the corresponding DC, ask her the correction and the DC will make any correction(s) in the laptop herself. The corrections for the incomplete profiles will be shown later in the next sending. Pagasa will do nothing in the incomplete profiles of Centralized_data.mdb.
| |
| ** This would mean we need to include the "FinalCheck" field (what tells CCMDB that it is complete and ready for sending) in the Centralized_data.mdb. I am starting to think I will need to include it, but I was hoping to change it from a boolean into a "status" field where we can designate the record as "incomplete", "sent", "finalized", and possibly "rejected" if we ever get to a point of pushing sent data back to collectors for fixing. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| **Sent means complete? For us Send would mean completed, released and finalized by collector, and send first time.
| |
| **What is "finalized" for? If file is not final check, this already mean that it is still incomplete and not finalized. Extra tags redundant.
| |
| **what is reject mean? Who will mark the reject, the program, the collector, Pagasa? What is a reject criteria? Example is it test data, or is it a patient that was entered but later found not true admit, or overlap admissions, duplicate patient admission with different serial number?
| |
| *if I need to use the data from the incomplete profiles of the Centralized_data.mdb and if there are some errors, I will substitute the erroneous value with the corrected value (provided by DC or Pagasa) in the SAS program in order to generate a correct report. Once the correction has been sent to the Centralized_data.mdb, I will just change the SAS program.
| |
| ** sounds good. Ttenbergen 14:06, 2013 April 9 (EDT)
| |
| | |
| == Dependencies == | |
| [[TISS28 Data.mdb]] pulls data from Centralized data.mdb.
| |
|
| |
|
| [[Category:Data Repository]] | | [[Category:Data Repository]] |
| | [[Category:Password]] |
| | [[Category:Centralized_data.accdb| *]] |