Facilitated Management of Serial numbers: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(52 intermediate revisions by 12 users not shown)
Line 1: Line 1:
== Collection instruction ==
== Collection instruction ==
The [["Add Patient with Serial Helper" button]] on the [[Patient List]] launches a form that lets the collector pick a [[Service/Location]]. The form then proposes the next sequential [[Serial number]] based on the location chosen and any current or recently deleted records (we keep track since [[EPR Reports Integrator]]) on the laptop.  
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 of that location is found, the number used for a new location as per [[Serial_number#Special-Use_Serial_Numbers]] will be used.
If no previous entry, the number used for a new [[laptop identifier]] as per [[Serial_number#Special-Use_Serial_Numbers]] will be used.


=== Question - Serial series per laptop or per [[Service/Location]] ===
== Background ==
{{Discuss |
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]].
* As people are testing [[Cognos Admitter]] and [["Add Patient with Serial Helper" button]], I am hearing that there are two ways to generate the next [[Serial number]]. Some use a serial pool per [[Service/Location]], and some use one serial pool for everything on their laptop. There might be a third option where some service locations are pooled but there also is a second pool for another service location. This makes automation or vacation coverage problematic. Could you please fill in what you do on your laptop? }}


Please put something like "per laptop" or "per unit", or narrative if it's more complicated than that:
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.
* G9 - [[GRA_MICU]] -
* G8 - [[GRA_N3]], [[GRA_N5]] (N3a, N5a) -
* G7 - [[GRA_N5]]/[[GRA_S3]]  -
* H9 - old HSC_ICUa -
* H8 - old HSC_ICUb - service locations are pooled
* H7 - old HSC_ICUd -
* H6 - [[HSC_A4]] -
* H5 - [[HSC_B3]] (& [[HSC_WRS3]]) -
* H4 - [[HSC_D5]] and [[HSC_D4_COVID]] - As of May 27th, this laptop now collects D4, along with the D service patients on H6, WRS2 and B2. The serial numbers for D4 and it's boarding locations of H6 and WRS2 are all from the same number pool. The serial numbers from B2 (which is currently the High Obs unit), are a different pool of serial numbers.
* H3 - [[HSC_H4]] -
* S9 - old [[STB_ACCU]] -
* S8 - old [[STB_CICU]] -
* S7 - old [[STB_MICU]] (MISI) -
* S6 - old STB_MedB ([[STB_B5]]/[[STB_IMCU]]) -
* S5 - old STB_MedA ([[STB_E6_B]]) -
* S4 - old STB_MedD ([[STB_E5]]) -


{{Discuss |
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).
* Would anyone see a problem if we standardized this to using one serial number pool per laptop? What would be the problems? Ttenbergen 19:55, 2020 June 2 (CDT)
}}


=== Negative and presumably decreasing serials ===
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.
{{Discuss |
* Looks like [[HSC_WRS3]] uses negative and possibly decreasing serial numbers. That would throw a wrench into automatic number suggestion. Is this a usual thing or just something to solve problems generated by the COVID moves? }}
 
== Background ==
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).
=== Potential problems moving to one pool per laptop for all? ===
'''Not a problem: large Serials will increase size of D_ID'''


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


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.
'''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 ==  
{{Related Articles}}
{{Related Articles}}

Latest revision as of 14:23, 2020 August 5

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: