Sending Patients

Data collectors "send" the data from CCMDB.accdb to Centralized_data.accdb and PHI.mdb.

Email Notification to suspend sending

At times, there are unexpected issues with the main database. Main office notifies staff by email to suspend sending operations and will send an updated email when the problem is resolved. It is important that Collectors check their email at the beginning of each shift AND before sending.

Data Collector Sending Frequency

Because the Data Processor needs dedicated access to Centralized_data.accdb the time during which collectors are able to send is limited as follows:

• when working from hospital site: Monday to Friday 07:00-09:30 and 14:00-16:15
• sending should be done every day a collector is working on site
• Sending should only be done when on site and on the network. (no sending from home)
• Only 1 laptop can send at any given time, so sites need to coordinate this amongst themselves
  • SBGH- will be assigned sending between 0700-0900
  • HSC – will be assigned sending between 0900-0930 and 1400-1515
  • GGH – will be assigned sending between 1515-1615

• If there is a special circumstance where you need to send outside of the assigned time, the collector is to email the site that is assigned that time slot to verify no one else is sending or negotiate a time to send.

• Do not send outside these hours unless requested by main office.
• Don't cut it close - if you have come really close to the end of the send window and might not finish sending before the window closes, just don't send and let Pagasa know. If you are still sending while Pagasa pulls the data we get discrepancies that need to be resolved. It's easier if we just know you didn't get to it and can organize to have you send later if needed.
• At each send, Minimal Data Set applies.

Task Can we again revisit the pros and cons of sending only when working on site against sending from home? There is always a need of updated data and I do not want to be emailing everyone to send when data are needed. This can be solved by sending in all days the collector works regardless onsite or from home during the assigned time slots. In addition, I think this practice of submitting data frequently will also mean lesser new data on the laptop if unfortunate incident happens on the laptop and there is a need to re-enter data again. Do we still experience problem in sending when we set up the sending time schedule by site? --JMojica 16:37, 2 December 2025 (CST) Sure, let's discuss. As far as I know, the following errors related to sending: Error "Invalid SQL statment..." when sending, Error "Unrecognized database format" when sending, Error: Centralized data.mdb not found. Contact the main office and find out if it is off-line right now.. I might be missing others. Sending from home takes considerably longer and has led to more errors. The fact that it takes longer requires longer send windows and reduces Pagasa's time to clean the data. When errors do happen and we need to recover this also takes significant time on Pagasa's part. AFAIK failure of the data set on the collector's laptop is very rare, I can't remember the last time I helped someone recover from that. There might be ways to make sending faster or more reliable. This would take a fair bit of analysis and testing. One reason I have not pursued this is the prospect of re-platforming. A cloud based system would eliminate sending; it might cause new process tangles but that's a different topic. So it would be good to have an idea of the time horizon for this to decide if the work to mitigate the errors and reduce sending restrictions is worth it. It might be possible to find a compromise that re-balances risk and benefit. Ttenbergen 01:19, 3 December 2025 (CST)

• SMW

• Cargo

• Categories

Ongoing preparation during collection

Whenever you complete collection for a patient, set the RecordStatus field to "complete". This runs some routines to check the data and marks the patient for export during the next send.

At any point during collection you might want to run the Pre-send Checker to find errors in your data. This will check on some of the data that we send for patients even if they are not final checked. If you run this occasionally during your collections then your chances of running into errors when you are ready to send become less.

Sending Data

To send:

• run News and Backup so you have a backup with the most possible information & also the latest CCMDB.accdb
  • NOTE: News and backup does not update the master database. Only the action of sending does.
• check that all patients whom you want to send have the RecordStatus field set to "complete" in the Patient List
• click the Send Records button
• click "OK" and put in your initials (see that article on information to default the initials to your own)
• After sending is complete, exit out of CCMDB.accdb and run News and Backup once again to create a backup of the patients files now remaining in your CCMDB data.mdb.

Deleting Sent Patients

• profiles should be deleted the next shift that the collector works, you can delete sent patients (who now have "sent" in their Record field) by pressing the "Delete Sent Patients" button. The program tells you how many rows are being deleted.
• For PHIA reasons you should not keep "sent" patient records on your laptop.

What happens when patients are sent

See the "Sending" module in CCMDB.accdb itself for info on what happens when data is sent. As of 17:18, 2015 April 30 (CDT) the order of steps inside the process is as follows. Listed here to help in troubleshooting.

• check for previously completed (ie no longer incomplete) records, quit if any found
• send centralized_data.mdb
  • update, then append
  • delete then update the other L-tables
  • append new L-tables
• send phi xls
• set RecordStatus field to sent in local L_Log table
• set RecordStatus field to sent in Centralized_data.accdb

Error messages during sending

Occasionally you will get an error during sending and Access will start an email message for you to send to the office.

Short version: when an error generates an email, please do send us these emails, even if it seems like sending went through. You don't need to delay going home after you send that email, further communication about this can happen at the next shift.

Long version: We have suspected for some time that there are occasional glitches during sending that are not evident from looking at the data. The send process still completes, and the records are still set to "sent", but not everything is getting to the centralized repository as it should. So, we changed our program to trap more errors and to make it as easy as possible to pass them on to us. We need those emails to understand the patterns of these problems, even if all the data is sent, to find out how common these problems are and whether we need to change the program and/or our processes further to prevent the underlying problem. Most of the time Pagasa will check and let you know that all was sent correctly and you can delete the data. You do not necessarily need to wait around after you send the email, just don't delete the batch of data you sent. If something went wrong with it, next day re-send will usually be quick enough. So, really, sending this email should not add to your time spent, so there is no reason not to send it.

Checks that people are sending inside the Designated sending times

CFE query Sending_at_wrong_time will show who sends out of the Designated sending times.