Length issue with account numbers in PID.#18

Wow!  The problem with whatever you do, is if your folks are used to seeing the MRN and speaking in terms of it, they will be confused by any new number generated for the Pharmacy system!

What application is the pharmacy using? Can you check with other people who use the same system what they have done? Does tech support for the new pharmacy system have any useful suggestions?

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

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

Do they have an alternate ID field, or some custom field you can use to store your real MRN?  You would rather have them maintain the table, then use one of your own.

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,

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!!