Update of D ID to include a laptop identifier
This page documents our move to a D_ID that contains a laptop identifier.
Why do we need to do this?
Our D_IDs consist of the site and location and the Pat ID/Serial number, e.g. HSC_A4-123. They must be unique. If two collectors wanted to enter for the same ward on two different laptops, we would need to make sure that there are no duplicate D_IDs used. Right now we use two methods for this.
- coordinate to not use same Pat ID/Serial numbers
- tedious for collectors; somewhat error prone, but since this will result in an error on sending rather than data corruption it is somewhat low risk
- HSC EMIP,
- add "fake" locations with a post-fix to make the D_ID unique that way (eg HSC_H4Ha, see Property:Collection Location workload designation, STB Medicine Workload splitting)
- this means we need additional entries in s_dispo for each laptop/location combination, and analysis of data is somewhat more messy than it needs to be
If/when we move to PatientFollow Project, the first solution would become completely impractical, and we would have to add dozens of fake entries to S dispo table to use the second solution, so we should fix it right instead. Also, with current understaffing, it would be nice to be able to do this as necessary to help others out. Finally, the situation of "unknown location" patients at HSC leads us to a situation where we may not know for much of a pt's stay which laptop they should go on, so it would be best to collect as we go and be able to edit location to what it needs to be later.
This also needs to be addressed to better collect HSC Unknown Service.
What do we need to do?
We need to add the Laptop identifier to the beginning of the D_ID.
|
this needs fleshing out |
deal w orphans
When we do, there will be Orphans in Centralized data.mdb, so we need an easy way to tell "real" orphans from ones that should just be cleaned up after this. In other words a query for Pagasa to help make that determination.
update sending
We will need to update the send functionality for this. Sending_Patients#What_happens_when_patients_are_sent This requires a change to a lot of queries, so we would want to proof this before rolling it. Probably best to make a test patient on Tina's laptop send before and send after, and then test that Pagasa Query to see if pt us successfully excluded from orphans.
Any concern for Julie? Confirm no parsing of D_ID for meaning will break because of this
|
|
TISS Scanning
|
|
How will we deal with TISS / TISS28 Form Scanning - can we stamp forms for this? Or otherwise capture them? |
Related articles
| Related articles: |