We have found an issue with labs imported using the 'Import New Demographic' functionality and labs coming in via the HL7 Lab Upload / Mule upload.
These two areas in oscar store lab data in seperate tables (hl7TextMessage and labPatientPhysicianInfo). However, they use the same tables to store meta-data about labs (i.e. providerLabRouting). They both use their respective primary keys as the 'lab number'. This causes key conflicts in the meta-data tables.
The end result is that we are seeing new labs come in that say they have been acknowledged already by providers, often from providers that the lab is not assigned to, and always on a date before the lab was even uploaded. This is confusing for doctors, and may even be dangerous, as a provider could theoretically have a lab come in that ends up with the same lab number as an imported lab that was already acknowledged by that provider (I don't think it would even show up in the inbox in this case).
To reproduce, simply import demographic data using 'Admin' -> 'Import New Demographic' (make sure it includes lab data). Acknowledge these labs. Then, import a lab using 'Admin' -> 'HL7 Lab Upload'. You will be able to see the new labs seem to be already acknowledged.
I tried the two files upload and cannot repeat the problem. I would like to ask you to provide the test files for us so we can repeat the issue. Could this be database specific? Please provide more details. I am attaching my test files here. You can check the QA system on the patinet John Smith.
Last edit: Daniel Sin 2014-07-04
second file
Hi Daniel,
The exported test data (xml) had invalid duration values. OSCAR is crashing during import of that file (at least for me, running 12.1.1).
Also, it was choking when importing the data directly from the xml file (not sure why). After I zipped the file (.zip) it uploaded more or less
ok (some drugs didn't get imported).
8 labs get imported in to the labPatientPhysicianInfo table, and 8 corresponding entries get populated in providerLabRouting.
I then searched for Smith, John and openned all the labs. I found one that was not acknowledged (it was the first one imported, and had
lab_no 1) and acknowledged it.
I then uploaded the sample GDML file. It appeared in table hl7TextMessage with lab_id 1. It also had a corresponding entry in providerLabRouting.
However, now providerLabRouting has 2 rows with lab_no 1 - one from hl7TextMessage and one from labPatientPhysicianInfo.
If you now go into OSCAR and search on the Inbox, you will find the GDML lab you uploaded, and you should see that it is acknowledged (which it shouldn't be).
Last edit: Jarrett Chisholm 2014-07-04
Thank you for the detailed instructions. I tried to replicate the issue on local host R12.1 build# 410 but unsuccessfully. Started off with the fresh database and followed the steps provided above. Zip file (Test datafiles.xml.zip) was imported.
Observed: As mentioned, the problem with the 'lab number' keys does exist as providerLabRouting table has 2 rows with lab_no 1 when GDML file has been uploaded(see the attached screen shot).
However, not able to replicate the last step -> when search for the Inbox new uploaded GDML file, it shows as NOT acknowledged.
Hi Suni,
You'll need to acknowledge the imported lab before uploading the HL7 lab.
Hi Jarrett,
Please check the status column in the providerLabRouting table on the screen shot, It appears that the imported lab was acknowledged first (status A) and then HL7 lab was uploaded (status N).
I also attached inbox screen shot for the reference.
Jarrett - something Jay suggested: could you look at the types in the providerLabRouting table? It should be fine for labs to share IDs provided they are different types but perhaps some mismatch is happening in this scenario. The imported labs should be showing up as CML in this case, and the uploaded lab should be HL7.
Hi Sarah,
Yes, they are differing types. However, this doesn't seem to have any bearing on this bug appearing for our customers.