Facilitated Management of Serial numbers

Template:Potential Change Data collectors currently collect one or more locations from one or more pools of serial number pools. 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).

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.

Added question to Serial_number#Special-Use_Serial_Numbers to find out if any serial numbers need to be "reserved".

Possible Solution 1

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

• 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

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? 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).--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)

• SMW

• Cargo

• Categories

Possible Solution 2

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).

Do you think this would be helpful? Can you see problems with this? 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.Trish Ostryzniuk 14:52, 2012 April 3 (CDT)

• SMW

• Cargo

• Categories

2016

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.

2019

As part of EPR Reports Integrator we changed to a logical delete of records; this will mean we will have a basis to generate new Patient IDs automatically.