Microchip search improvement
When we currently search a microchip number, we have to have the exact sequence right or the system can't handle it. For visual ease we usually enter a microchip number as numbers of 4,4,4,3 with spaces, eg
9820 0000 1234 678
Not all staff have done this so we may also have microchip numbers recorded as follows:
982 000 001 234 678, or
982000001234678
It would be a valuable improvement if the search function for identities ignored spaces as above. Is this possible ?
Re: Microchip search improvement
Try searching for the last three numbers only: using your example, search for "%678" (percent + numbers) with all patients and search identities checked. This will return microchip numbers containing the three numbers together anywhere in the chip number - this should narrow it down to a few results and from there you can read off the rest of the number for a match.
Re: Microchip search improvement
Thats a good suggestion Yuri
However I think that Microchip numbers should be dealt with in the same way as phone numbers when entered...strip out the spaces no matter how its entered and allow some sort of preset display view, possibly user configured. eg xxxx xxxx xxxx xxx or xxx xxx xxx xxx xxx.
This would mean searching is done on the raw data spaces or no spaces. and the display/print display is customisable.
Ben
Re: Microchip search improvement - formats
We should be careful of locking in formats. The Hong Kong practice I am converting sees multiple microchip formats (because of the expat community): the ISO 15 digits, AVID as 999*999*999, FECAVA as 10 character alpha numeric, and (rarely) the TROVAN 5562 10 char alphanumeric.
Hence a complete solution to the microchip data entry validation/presentation format problem requires multiple microchip entityIdentity.microchip archetypes.
Ben - the current (1.6b3) system does not seem to strip blanks from phone numbers - do you have a local mod that does this? That is, I can enter as phone number as 1234 5678 or 12345678 or even ABCDEFGH - the phone number is just a string with no validation.
Regards, Tim G
Re: Microchip search improvement - formats
Ok, I think we're getting mixed up here with searching/validation/presentation.
The OP asked about searching for a microchip number given the possible variables of data entry. I agree that trying to enforce a data entry validation on the myriad numbers of chips would be difficult (=expensive). I wouldn't support locking in a data entry format.
I can see why the OP's staff put spaces in: the current Trovan ISO chips have 4-5 zeros so doing a 4+4+4+3 presents a visual validation: 9560 0000 0852 123 is a lot easier to read/validate than 956000000852123.
Which is why I asked a couple of months ago for a character counter (similar to one on the SMS form but that one counts down from 160, not up) as a quick way to check that you have 15 characters (or 9 or 10 or whatever - the data entry operator knows how long the number should be). I figured that as that particular bit of coding had already been done for SMS forms, it would be a simple (=cheap+timely) drop-in module.
This is how I envisioned it would look:
Now Tim, where you're getting confused is with "stripping out" blanks in phone numbers for SMSs. The issue arose because of the desire to send SMSs from within OV. OV 16b3 strips out spaces/letters etc when you go to send an SMS (nothing to do with presentation or display). This was because mobile phone numbers are stored in as many different ways as there are users of OV. I use 04nn in the Area code and nnn-nnn in the number field. Some users may then write a comment ("ask for Jane" was the beta test example) or somesuch after the number for further clarification.
You can write phone numbers any way you want in OV. The example I used when beta testing this feature was Area Code 0411, Number 987-654 (ask For Jane) When you want to send an SMS, OV takes the 0411 plus 987-654 (ask for Jane) and turns it into a string such as 0411987654 (see discussion at http://www.openvpms.org/documentation/setting-email-sms-using-generic-sms-gateway-one-users-experience for a more complete explanation). v16b3 sends SMSs beautifully: my staff send 20-30 SMSs per week straight out of OV with just a few clicks of the mouse and a few macros.
HTH.
Re: Microchip search improvement - formats
For microchips, I think it would be better if there was a separate archetype for each microchip format, and a presentation pattern for its editing, validation, and display.
So for Trovan ISO, you might be presented with 4 numeric fields of fixed length (4, 4, 4, 3). These would be stored internally without any spaces to avoid problems when querying.
Phone numbers could be treated in a similar manner.
-Tim
Re: Microchip search improvement - formats
I agree with Tim A that the full solution to this is to have multiple archetypes, one per microchip format. If fact its quite possible to do this now. However, one really needs to update the source to make the getMicrochip routine to specify all microchip archetypes - ie
not: return getIdentity(patient, "entityIdentity.microchip");
but: return getIdentity(patient, "entityIdentity.microchip*");
Then one can clone entityIdentify.microchip to make entityIdentify.microchipISO and so on.
Since TimA has published the fix for getting regular expressions to work (see OVPMS-1267) one can now do the validation. If you do want to add the validation now, apply the above fix, then add an assertion.regularExpression assertion node to the microchip field and specify the expression as
([0-9]{4} [0-9]{4} [0-9]{4}[0-9]{3})|([0-9]{3}\*[0-9]{3}\*[0-9]{3})|([A-Z,0-9]{10})
and the error message as
Format must be 9999 9999 9999 999 or 999*999*999 or 10 characters alpha numeric
If you only want ISO format, use [0-9]{4} [0-9]{4} [0-9]{4}[0-9]{3} and the expression and set the error message to 'Format must be 9999 9999 9999 999'
Note that I agreed with Tim A's comment that the full solution should include 'store internally with no spaces, present and enter with spaces'. However, there is enough flexibility in the current system to validate the data to have your specified format.
Regards, Tim G