aperezcrespo wrote on Thursday, March 01, 2007:
Hi
The Patient Medical record that is on the Prescription is the pid and not the pubpid. At least I think it should be the pubpid.
Where can I change it?
Thanks
penguin8r wrote on Monday, November 10, 2008:
It’s funny how the same problems keep coming back around to haunt us.
We’re running into the same problems with the pid/pubpid on prescriptions.
This is a huge problem for the end users since when they plug in the pubpid (which is the patient’s account number as far as they know), and run an rx report, they get nothing.
Since the prescriptions table stores data by pid, not pubpid, there’s no way to query for prescriptions with pubpid.
So, would it be better to write some cross-reference code to translate pubpid to pid & return the results that way? or has someone already written some code to do this they’d be willing to share?
Would it be better to add the pubpid field to the prescriptions table so that you can search for prescriptions by pubpid in the future? Of course the other way to do it would be to change the prescription routine to store the pubpid instead of pid, but that might create problems elsewhere, & would also require some kind of conversion routine to modify existing rx records to make them searchable by pubpid. Would it be better if the prescription table stored both pubpid AND pid?
Seems like this is something the devs would want to agree on going forward so that everyone can implement the same fix instead of everyone writing their own littel code hacks to deal with it.
What does everyone else think?
whimmel wrote on Monday, November 10, 2008:
I would think that if you want to run a report based on pubpid that you could join on patient_data.pid to get it. Something like…
select <fieldlist>
from prescriptions rx, patient_data pd
where rx.patient_id = pd.pid
and pd.pubpid = ‘$pubpid’
mike-h30 wrote on Tuesday, November 11, 2008:
I would like to have the option to have the pub_id print on prescriptions.
penguin8r wrote on Friday, November 21, 2008:
You could do a join, that’s true, but this is a problem in many more areas than in the prescription report.
also, the prescription report is nearly useless even when you can find the patient, because unless the medication was selected from the drop-down, it’s invisible. e.g., if the provider enters the medication manually & processes the rx, then the drug info is not stored in the database, so the entry in the prescription report is empty. This makes the prescription report absolutely worthless in the real world.
There should be some way to fix the prescription report, it’s the constant conflict between referencing patient by pid & pubpid that worries me.
whimmel wrote on Friday, November 21, 2008:
Really the pid should only be used internally for referential integrity. Not just on the prescription report, but everywhere in the EMR. Any time a user would look up a patient by id or chart number, the search should be done on pubpid with a join on patient_data.
If you don’t use a special value for pubpid in your practice, then it would be prepopulated with pid anyway. That value isn’t important. You don’t want to store pubpid anywhere else because the end user can change it at any time in the demographics. pid however remains the same.
As far as the prescription data itself I suppose it can only be as good as the data that is entered. If the provider isn’t filling in the field then the report can’t be relied upon. Perhaps e-prescribing will address this.
drbowen wrote on Sunday, November 23, 2008:
Sometimes it is better to have a controlled denormalization of the database. Would it work better to actual have both the pid and the pubpid in the prescription module so that both can be searched?
The pubpid was originally intended to be a bridge to a full use of the OpenEMR pid by the practice. So a lot of the development has not bothered to be backwards compatible with the pubpid.
In my practice we continue to use the pubpid. I get around the problems by forcing the pubpid to equal the the pid. But this sometimes gets out of sync and causes a lot of trouble.
The pid is not "prepopulated" with the pubpid. The pid is assigned as an incremental which is "1+ the highest pid". My billing office got the bright idea to assign account numbers of 80,000 and up to companies that send us work related injuries. Our pubpid range is currently approximately 14,000. If I assign a "pid" of 14001 what I really get is:
pubpid=14001
pid=80001
This is complicated by the fact that the “find” function for looking up patients by pid doesn’t actually use the pid, it uses the pubpid.
Using the "find" for 14001 returns the correct person. searching for 80001 is an empty result. This can be quite confusing for the end user.
Having the prescriptions module use and print the pid confuses the end user ever more. In my personal opinion, the current prescription module is not conforming to the reason there is a pubpid and should be altered to reflect this.
Sam Bowen, MD
aperezcrespo wrote on Wednesday, February 18, 2009:
Ok
The jury’s been out for awhile now. What’s the verdict on this. Will we have pid or pubid on Prescriptions?
Thanks
cfapress wrote on Wednesday, February 18, 2009:
OK,
To make sense of this all I’ve adjusted the prescriptions report, found in the Reports screen, to conform to search and order the database results by pubpid. The internally used ‘pid’ that links tables is no longer used for display purposes.
Jason
aperezcrespo wrote on Wednesday, February 18, 2009:
What about the actual prescriptions. What shows up is the pid not the pubid. Rather confusing…
Thanks
cfapress wrote on Wednesday, February 18, 2009:
ajperezcrespo,
I’ve corrected the two files affecting this feature and committed the changes to CVS
<oemr>/library/classes/Patient.class.php
<oemr>/controllers/C_Prescription.class.php
Jason