Sending Patients - Revision history

Lkaita at 15:56, 4 March 2026

2026-03-04T15:56:44Z

← Older revision		Revision as of 10:56, 4 March 2026
Line 10:		Line 10:
	*At each send, [[Minimal Data Set]] applies.		*At each send, [[Minimal Data Set]] applies.

	~~{{Discuss\| JALT~~
	* 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? --[[User:JMojica\|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. [[User:Ttenbergen\|Ttenbergen]] 01:19, 3 December 2025 (CST)~~
	* I heard nothing from the collectors about errors in sending since we started this new schedule. If they work from home, can we allow them to send? They can send early or after 04:30 PM. [[User:PTorres\|PTorres]] 14:27, 3 December 2025 (CST)
	** Open to it. If things work fine now, changing process may break them again. [[User:Ttenbergen\|Ttenbergen]] 11:50, 17 December 2025 (CST)
	}}

	== Ongoing preparation during collection ==		== Ongoing preparation during collection ==

Ttenbergen: /* Data Collector Sending Frequency */

2025-12-17T17:50:08Z

Data Collector Sending Frequency

← Older revision		Revision as of 12:50, 17 December 2025
Line 10:		Line 10:
	*At each send, [[Minimal Data Set]] applies.		*At each send, [[Minimal Data Set]] applies.

	{{Discuss\| ~~Task~~		{{Discuss\| JALT
	* 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? --[[User:JMojica\|JMojica]] 16:37, 2 December 2025 (CST)		* 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? --[[User:JMojica\|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.		** 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.
Line 17:		Line 17:
	:: It might be possible to find a compromise that re-balances risk and benefit. [[User:Ttenbergen\|Ttenbergen]] 01:19, 3 December 2025 (CST)		:: It might be possible to find a compromise that re-balances risk and benefit. [[User:Ttenbergen\|Ttenbergen]] 01:19, 3 December 2025 (CST)
	* I heard nothing from the collectors about errors in sending since we started this new schedule. If they work from home, can we allow them to send? They can send early or after 04:30 PM. [[User:PTorres\|PTorres]] 14:27, 3 December 2025 (CST)		* I heard nothing from the collectors about errors in sending since we started this new schedule. If they work from home, can we allow them to send? They can send early or after 04:30 PM. [[User:PTorres\|PTorres]] 14:27, 3 December 2025 (CST)
			** Open to it. If things work fine now, changing process may break them again. [[User:Ttenbergen\|Ttenbergen]] 11:50, 17 December 2025 (CST)
	}}		}}

PTorres: /* Data Collector Sending Frequency */

2025-12-03T20:27:47Z

Data Collector Sending Frequency

← Older revision		Revision as of 15:27, 3 December 2025
Line 16:		Line 16:
	:: 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.		:: 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. [[User:Ttenbergen\|Ttenbergen]] 01:19, 3 December 2025 (CST)		:: It might be possible to find a compromise that re-balances risk and benefit. [[User:Ttenbergen\|Ttenbergen]] 01:19, 3 December 2025 (CST)
			* I heard nothing from the collectors about errors in sending since we started this new schedule. If they work from home, can we allow them to send? They can send early or after 04:30 PM. [[User:PTorres\|PTorres]] 14:27, 3 December 2025 (CST)
	}}		}}

Ttenbergen at 07:19, 3 December 2025

2025-12-03T07:19:27Z

← Older revision		Revision as of 02:19, 3 December 2025
Line 15:		Line 15:
	:: There might be ways to make sending faster or more reliable. This would take a fair bit of analysis and testing.		:: 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.		:: 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.		:: It might be possible to find a compromise that re-balances risk and benefit. [[User:Ttenbergen\|Ttenbergen]] 01:19, 3 December 2025 (CST)
	}}		}}

Ttenbergen at 07:19, 3 December 2025

2025-12-03T07:19:03Z

← Older revision		Revision as of 02:19, 3 December 2025
Line 9:		Line 9:
	*'''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 [[pull]]s 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.		*'''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 [[pull]]s 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.		*At each send, [[Minimal Data Set]] applies.
	{{Discuss\| 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? --[[User:JMojica\|JMojica]] 16:37, 2 December 2025 (CST)}}
			{{Discuss\| 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? --[[User:JMojica\|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.
			}}

	== Ongoing preparation during collection ==		== Ongoing preparation during collection ==

JMojica: /* Data Collector Sending Frequency */

2025-12-02T22:37:49Z

Data Collector Sending Frequency

← Older revision		Revision as of 17:37, 2 December 2025
Line 9:		Line 9:
	*'''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 [[pull]]s 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.		*'''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 [[pull]]s 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.		*At each send, [[Minimal Data Set]] applies.
			{{Discuss\| 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? --[[User:JMojica\|JMojica]] 16:37, 2 December 2025 (CST)}}

	== Ongoing preparation during collection ==		== Ongoing preparation during collection ==

Lkaita: /* Checks hat people are sending inside the Designated sending times */

2025-09-05T02:34:15Z

Checks hat people are sending inside the Designated sending times

← Older revision		Revision as of 21:34, 4 September 2025
Line 48:		Line 48:
	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.		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 ~~hat~~ people are sending inside the [[Designated sending times]] ==		== 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]].		[[CFE]] query ''Sending_at_wrong_time'' will show who sends out of the [[Designated sending times]].

Ttenbergen: Text replacement - "[[Category: " to "[[Category:"

2025-07-30T17:05:15Z

Text replacement - "[[Category: " to "[[Category:"

← Older revision		Revision as of 12:05, 30 July 2025
Line 55:		Line 55:


	[[Category: IT Instructions]]		[[Category:IT Instructions]]
	[[Category: Data Collection Guide]]		[[Category:Data Collection Guide]]
	[[Category: Sending]]		[[Category:Sending]]
	[[Category:Laptop identifier]]		[[Category:Laptop identifier]]

Ttenbergen: Text replacement - "[[Centralized_data.accdb]]" to "Centralized_data.accdb"

2025-07-23T19:54:14Z

Text replacement - "[[Centralized_data.accdb]]" to "Centralized_data.accdb"

← Older revision		Revision as of 14:54, 23 July 2025
Line 1:		Line 1:
	Data collectors "send" the data from [[CCMDB.accdb]] to [[[[Centralized_data.accdb]]]] and [[PHI.mdb]].		Data collectors "send" the data from [[CCMDB.accdb]] to [[Centralized_data.accdb]] and [[PHI.mdb]].

	== Email Notification to suspend sending ==		== Email Notification to suspend sending ==

Ttenbergen: Text replacement - "Centralized data.accdb" to "Centralized_data.accdb"

2025-07-23T19:52:00Z

Text replacement - "Centralized data.accdb" to "Centralized_data.accdb"

← Older revision		Revision as of 14:52, 23 July 2025
Line 1:		Line 1:
	Data collectors "send" the data from [[CCMDB.accdb]] to [[[[~~Centralized data~~.accdb]]]] and [[PHI.mdb]].		Data collectors "send" the data from [[CCMDB.accdb]] to [[[[Centralized_data.accdb]]]] and [[PHI.mdb]].

	== Email Notification to suspend sending ==		== Email Notification to suspend sending ==
Line 38:		Line 38:
	* send phi xls		* send phi xls
	* set [[RecordStatus field]] to sent in local [[L_Log table]]		* set [[RecordStatus field]] to sent in local [[L_Log table]]
	* set [[RecordStatus field]] to sent in [[~~Centralized data~~.accdb]]		* set [[RecordStatus field]] to sent in [[Centralized_data.accdb]]

	== Error messages during sending ==		== Error messages during sending ==