Facilitated Management of Serial numbers: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
← Older edit
m still an issue
mNo edit summary
 
(69 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Potential Change}}
== Collection instruction ==
Data collectors currently collect one or more locations from one or more pools of serial number pools.
The [["Add Patient with Serial Helper" button]] on the [[Patient List]] launches a form that lets the collector pick a [[Service/Location]], and that proposes the next sequential [[Serial number]] for that laptop based on any current or recently deleted records on the laptop.  
Details of the serial number system are located in [[Serial number]]. This has been flagged as one reason why people find paper printouts of the most recent patients sent useful.


Serial numbers have to be unique for a collection location, so if a ward like HSC_H4H is collected on by multiple collectors then a serial number must never be re-used. This is currently achieved by assigning blocks of numbers for each 100 possible serial numbers to a given collector (again, see [[Serial number]] for details).  
If no previous entry, the number used for a new [[laptop identifier]] as per [[Serial_number#Special-Use_Serial_Numbers]] will be used.


A serial number must be entered before any other data since access uses it to set the relationships for the data. To accomplish that, function new_pat_id() opens a window requesting the serial number pops up when "add new patient" is clicked on the patient list.  
== Background ==
Data collectors used to collect one or more locations from one or more pools of serial number pools. All laptops now use one pool of serial numbers per [[Service/Location]].


Added question to [[Serial_number#Special-Use_Serial_Numbers]] to find out if any serial numbers need to be "reserved".  
Details of the serial number system are located in [[Serial number]]. This has been flagged as one reason why people find paper printouts of the most recent patients sent useful. The need to keep track of this is one reason given by collectors to keep using the [[Data collection log form]]. We would like to eliminate reasons for this additional paperwork.


==== Possible Solution 1 ====
Before [[Update of D ID to include a laptop identifier]]s, Serial numbers had to be unique for a collection location, so if a ward like HSC_H4H is collected on by multiple collectors then a serial number must never be re-used. This is currently achieved by assigning blocks of numbers for each 100 possible serial numbers to a given collector (again, see [[Serial number]] for details).  
The program would provide a default serial number. For locations with only one serial pool, this would be a one-step, transparent process. Collectors with more than one serial number pools would get a dropdown list of possible pools; upon choosing one the program would default to serial (most recent+1). Collectors using only blocks of serial numbers would have to keep track if they are "leaving" their block (e.g. if you are using only 20-39 and the program defaults to 1140, you would have to realize that and change it to 1220).  


To accomplish this, the _info table would store
A serial number must be entered before any other data since access uses it to set the relationships for the data. To accomplish that, function new_pat_id() opens a window requesting the serial number pops up when "add new patient" is clicked on the patient list.
* variable: serial_pools, value: comma-separated list of wards
* for each ward, a variable "Serial_pool" & <ward> (e.g. Serial_pool_HSC_H4H) with the most recent value used, updated automatically by the serial wizard


{{discussion}}
=== Potential problems moving to one pool per laptop for all? ===
* Any thoughts about this? Do you think it would/wouldn't work or be helpful? Especially, do you think collectors would consistently "catch" the ends of blocks?
'''Not a problem: large Serials will increase size of D_ID'''
**This may not work as planned as there are times when the data collector assigns a number to a patient file in her log book but is unable to use it immediately and must use numbers out of order (even though the numbers are assigned in the right order).--[[User:CMarks|CMarks]] 08:39, 30 November 2010 (CST)
*** what if the collector were to not put a number into the paper log (wherever that is still used) until the record is entered on the laptop. Would that work? Ttenbergen 08:44, 2014 September 9 (CDT)


==== Possible Solution 2 ====
[[D_ID]] is currently limited to 18 characters. The only unit who has 18 right now is [[HSC_WRS3]]; the laptop is at 14600ish. The highest local serial is 40500ish for STB_ACCU. It will be a long time before these roll over to 10000. This should not be a problem.
If we are not able to provide the next number on the list, we could at least suggest it, and then do error checking on what is chosen.  
Scenario: When the "Add Patient" button is clicked on the Patient List, the msg box could default to (highest serial currently on the laptop)+1. If a different number is desired, the collector could change it. This would be followed by the existing checks for a blank ID and for an existing ID. The program would then check if the ID was '''smaller''' than the largest ID already present (since some collectors use multiple indices, this error would be ignorable). The program could also check if the new Patient ID is more than “X” greater than the previous max(Pat_ID) (what would be a reasonable "X"?) (again, this error would be ignorable).
{{discussion}}
* Do you think this would be helpful? Can you see problems with this? [[User:Ttenbergen|Ttenbergen]] 14:14, 15 July 2011 (CDT)
**Hi Collectors - is this still something that would be helpful or not?  Please advise, if not we will take it off change request list.  Thanks kindly.[[User:TOstryzniuk|Trish Ostryzniuk]] 14:52, 2012 April 3 (CDT)


== 2016 ==
'''Not a problem: Negative and presumably decreasing serials '''
This was discussed again at [[Team Meeting June 8, 2016]] as a reason to keep using the [[Data collection log form]]. We would like to eliminate reasons for this additional paperwork.
There is a temporary situation of  [[HSC_WRS3]] using negative serial numbers. This is not the usual thing, this was done initially to solve the duplicate records (i.e. before and after covid) but after changing the process, the positive serial number sequence has been followed. No new negative serials are expected, so not a problem.
If we needed to use negative numbers again in the future we could, they just wouldn't be managed automatically.
 
== Related articles ==
{{Related Articles}}

Latest revision as of 14:23, 5 August 2020

Collection instruction

The "Add Patient with Serial Helper" button on the Patient List launches a form that lets the collector pick a Service/Location, and that proposes the next sequential Serial number for that laptop based on any current or recently deleted records on the laptop.

If no previous entry, the number used for a new laptop identifier as per Serial_number#Special-Use_Serial_Numbers will be used.

Background

Data collectors used to collect one or more locations from one or more pools of serial number pools. All laptops now use one pool of serial numbers per Service/Location.

Details of the serial number system are located in Serial number. This has been flagged as one reason why people find paper printouts of the most recent patients sent useful. The need to keep track of this is one reason given by collectors to keep using the Data collection log form. We would like to eliminate reasons for this additional paperwork.

Before Update of D ID to include a laptop identifiers, Serial numbers had to be unique for a collection location, so if a ward like HSC_H4H is collected on by multiple collectors then a serial number must never be re-used. This is currently achieved by assigning blocks of numbers for each 100 possible serial numbers to a given collector (again, see Serial number for details).

A serial number must be entered before any other data since access uses it to set the relationships for the data. To accomplish that, function new_pat_id() opens a window requesting the serial number pops up when "add new patient" is clicked on the patient list.

Potential problems moving to one pool per laptop for all?

Not a problem: large Serials will increase size of D_ID

D_ID is currently limited to 18 characters. The only unit who has 18 right now is HSC_WRS3; the laptop is at 14600ish. The highest local serial is 40500ish for STB_ACCU. It will be a long time before these roll over to 10000. This should not be a problem.

Not a problem: Negative and presumably decreasing serials There is a temporary situation of HSC_WRS3 using negative serial numbers. This is not the usual thing, this was done initially to solve the duplicate records (i.e. before and after covid) but after changing the process, the positive serial number sequence has been followed. No new negative serials are expected, so not a problem. If we needed to use negative numbers again in the future we could, they just wouldn't be managed automatically.

Related articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Facilitated_Management_of_Serial_numbers&oldid=145649"