Fellow Chuggers,
Since you are all wayyyy smarter than me, I am looking for some good solution ideas.
Problem: When the Lab Result XREF file was set up (10 years ago) between our affiliate hospitals lab system and GE CEMR, OBSTERM units were not taken into consideration. There are approximately 250 result OBSTERMS where the unit from the Lab system does not match and is causing the values to be automatically converted. This was identified by a patient when reviewing lab results via the portal because the reference range did not match. Ideally, all OBSTERMS used within the XREF file would be "text" type with no associated units.
Potential Solutions that I've identified:
1. Identify/create all new OBSTERMS that are "text" type without units for the 250 mismatched and change the XREF file to reflect the change. Downside to this approach includes inventorying and changing clinical content referencing these OBSTERMS (forms, flowsheets, handouts, letters, reports, etc.) which is a manual process. This solution would also require that all historical data be scripted into the new OBSTERMS. Ughhh...
2. Work with GE to develop a script that modifies the existing OBSTERMS in OBSHEAD table to remove the units and change the data type to "text". Downside to this approach is that it would require the script be re-run anytime an OBSKIT is imported into GE. Running scripts against the DB always involves risk. This solution would still require some scripting to move de-convert historical data, but at a much smaller volume. This solution would not require inventorying and modifying all of the existing clinical content.
There must be better solutions and I'd love to hear them. Give me your best CHUG!
We try to use the numeric obs terms when they exist; mostly as a matter of accuracy.
Why not map the results to the correct obs term with the correct unit of measure? That fixes results going forward. From there, it's fairly easy to move/copy existing lab values to the correct obs terms in the database, although you would want to be familiar with SQL before trying it. I can't say 100% that there aren't other database dependencies there, but I don't think so.
I have Mirth doing some of this where Centricity doesn't have a matching unit of measure for some reason. I can have Mirth do the math to convert where needed or change the unit as appropriate.
Centricity also has a translation table for this. Take a look at the "importing unit conversions" section in the managing interfaces guide. If the imported units are converting incorrectly, you may need to look at that file.
-dp