- This topic has 9 replies, 5 voices, and was last updated 14 years, 1 month ago by
.
-
Topic
-
Hi all. I have a bit of a problem concerning patient account numbers.
Throughout our hospital, we use account numbers that are 13 digits long. 12 of these digits are significant. The first one is a leading 0, which is not really important. Also, the remaining 12 digits are not necessarily composed of the medical record number + 4 digits representing visit #, like other facilities do. Most of the time that’s the case, but not always.
The problem I have is this. I need to figure out how to send this account number from our registration system to a new pharmacy system, and then from the pharmacy system out to other systems throughout the hospital. The new pharmacy system will only accept 10 digits for the account number, not 12.
Is there anything I can do in Cloverleaf to somehow compress this 12 digit number down to 10 digits? I tried using the approach of converting the digits to hex, and also using other conversion routines such that the resulting account number contains letters, but these methods are unacceptable. The pharmacy system will only accept digits in PID.#18. I need to figure out a way to convert the 12-digit number going from registration to a 10-digit number going into pharmacy system, and then convert it back to the 12-digit number going out of pharmacy to anywhere else in the hospital.
Any thoughts? Thanks in advance.
George Kulz
Senior Java Programmer
Information Services
Memorial Hospital of Rhode Island
-
Replies
-
-
-
-
Any vendor worth their salt will adapt to an institution’s identification number size if they want the business and a happy customer.
My input is to ask the Pharmacy vendor to change to accomodate whatever size identifier your institution needs.
Assuming no progress can be made on that front (and as far as I am concerned that is the only REAL solution), a DB could be established which assignes a different 10 digit Pharmacy number to pair up with the source system’s number. This Db would be used in both directions to convert from source to Pharmacy and then back (for non-pharmacy systems who speak institutional id).
You could try to use sql-lite inside Cloverleaf – however that raises a whole lot of management issues and quite frankly I consider this a business rule not an integration rule and thus in my opinion does not belong inside Cloverleaf.
Another option is to have the Pharmacy folks manage the DB and just reference it from Cloverleaf (using Data Integrator for example) but that also raises some issues regarding DB availability, etc.
We recently brainstormed a similar challenge and convinced the applications it was their problem to resolve (we think the receiving system will adapt).
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Thanks for all the suggestions.
The vendor will not modify the MRNs for us. Nor do they have any suggestions for us, except to switch the entire hospital to their numbers, which is ludicrous for so many reasons.
Also, to make a DB within the pharmacy system will require extra coding, which will cost extra money.
I COULD go the route of coming up with a reference table/DB/what have you within Cloverleaf, or even outside of Cloverleaf through programming on the hospital’s end, but someone already said it best in that it’s not very maintainable, even if it’s outside of Cloverleaf.
The pharmacy is using Meditech btw.
I suppose I could see what others have dealt with in regards to using Meditech. I’ll see if there are other forums for Meditech users.
Thanks for your help so far. If anyone else has suggestions, I’m all ears.
-George
-
George,
Well I guess Meditech is one of those vendors that says do everything my way. Certainly not a candidate for participating in a ‘best of breed’ enterprise.
One would think that discrepency (and lack of flexibility) would have been detected in the RFP phase of product selection.
However that is water under the bridge so another potential resolution is the use of an MPI system.
This is certainly several orders of magnitude more complex and invasive than a simple DB – but – it is probably in your insititution’s future anyway (as it is for all of us) for a number of reasons (not the least of which is apparently nobody cares if the systems purchased can support common identifiers).
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
You need to push them hard to either change their MRN size or pass back your data in any outbound HL7 messages. You almost have to insist. do you have any leverage over them at all, or are you completely beholden to their will?
If you really need to hash the numbers down from 12 to 10 digits, you might be able to use some encoding scheme that converts Base 10 to some larger base, like Base 16 which would have less digits. The base 10 number 999999999999 converts to Base 16 E8D4A50FFF. Now that is 12 digits down to 10, so you are good there, but does the vendor accept alpha characters in the MRN field? If not, you need to find something more complex, or develop one yourself.
Good luck,
Robert Milfajt
Northwestern Medicine
Chicago, IL -
Greetings,
Just another viewpoint here: the PROBLEM is with the communicating applications and not the integration software. The business owners, aka business analysts and system analysts, need to communicate with each other and develop a solution. Then communicate to you if the Cloverleaf application can accommodate their solution(s). In short they solve the problem you code the solution – aka , get specifications.
Or the organization needs a new pharmacy application.
Sometimes Cloverleaf is just not a magic black box that can do everything for everyone.
Good luck, good hunting!!
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
