|
|
| (38 intermediate revisions by 8 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]] - one serial pool for laptop G9 & unit GRA MICU[[User:Gens|Gens]] 12:45, 2020 June 3 (CDT)
| |
| * G8 - [[GRA_N3]], [[GRA_N5]] (N3a, N5a) -
| |
| * G7 - [[GRA_N5]]/[[GRA_S3]] - Since Lisa came to show us the integrator, I've been using this for adding new profiles. We weren't shown if the Serial Helper works with the integrator so we've been manually adding in our profile numbers through the integrator.
| |
| * H9 - old HSC_ICUa -
| |
| * H8 - old HSC_ICUb - service locations are pooled
| |
| * H7 - old HSC_ICUd -
| |
| * H6 - [[HSC_A4]] -
| |
| * H5 - [[HSC_B3]] (& [[HSC_WRS3]])- H5 laptop collects on the following:
| |
| a.) all medicine patients in B3 and WRS3 regardless of which service is looking after the patient.
| |
| b.) Patients transferred from B3 & WRS3 to contingency units (H6, WRS2) and High Obs unit(B2)
| |
| c.) WRS2 patients under unknown service
| |
| d.) All Nephrology patients for Kidney Transplant directly admitted to B2 (High Obs)
| |
| e.) EMIPs admitted from the 1st to the 14th of the month.
| |
| >>>Please Note: The serial numbers for B3, WRS3 and contingency units (H6 & WRS2) are all from the same number pool.
| |
| Serial numbers for B2 (High Obs)are from a different pool.
| |
| Serial numbers for EMIPs are also from a different pool.
| |
|
| |
|
| * 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. Service "Unknown" patients from D4, as well as H6 are also collected on this laptop. EMIP's are collected at HSC by date, not by service, so this laptop will potentially have any services EMIP's between a certain period of time. This exact dates that we collect on will be changing over the next few months, as vacant positions are filled. The EMIP's also have their own unique number pool.
| | 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). |
| * 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]]) - Should this change to STB_E6? Currently displaced E6 unit (A7S/A7W) entered as location A7B, Covid unit E6C, all covid suspect units currently A6S but could include any 6th floor unit per service: A service as E5 with boarding location and B service as A7B with boarding location. Patients transferred to E5 (A service) continue to be followed-all from same number pool. In addition overs are tracked 1-15th inclusive every month and assigned/entered according to service. EMIPs 1-15th every month are tracked and entered using a separate serial number pool.
| |
| * S4 - old STB_MedD ([[STB_E5]]) -
| |
|
| |
|
| *SBGH - E5 uses one set of serial numbers, and the emip's that I collect are a completely different set of serial numbers [[User:DPageNewton|DPageNewton]] 07:26, 2020 June 4 (CDT)
| | 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 |
| |
| * 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)
| |
| ** if you follow the higher number sequence per laptop (discontinue the lower one). There will be no problem for unique record. However, those outstanding (incompletes) wards with lower number sequence will become orphans in the master database which Pagasa has to delete. I think the deletion will be easy and Pagasa need not crosscheck at all or confirm with the DC - simply delete the ones with lower serial number. The drawback for following the higher sequence order (currently 5 digits) is the growing number of digits over time which consequently has an effect on D_ID.
| |
| ***Another option, have a fresh start with a new lower number (2 or 3 digits) or continue the lower number sequence for all laptops. This would mean changing something to all profiles having laptop identifier (say, make the serial # negative or change the laptop identifier ,e.g. H9 to HS9). Any change for the incompletes will result to orphans and more orphans if this is the option. --[[User:JMojica|JMojica]] 08:48, 2020 June 3 (CDT)}}
| |
| | |
| === Negative and presumably decreasing serials ===
| |
| {{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?
| |
| ** 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. --[[User:JMojica|JMojica]] 08:46, 2020 June 3 (CDT) }}
| |
| | |
| == 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}} |
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