Ran into another hidden glitch in the Version 7 interface to Ensora/NewCrop earlier this week. It’s not necessarily a bug, but if you are an existing user of the Ensora/NewCrop RX service, and you upgrade to OpenEMR Version 7, there are some things to watch out for. A site noticed that when they recorded “NKDA” for “No Known Drug Allergies”, which is numeric code 232 in the Ensora system, that data never makes it back into the EMR. While investigating this issue, I realized that it wasn’t just the NKDA data that was missing, their OpenEMR 7 instance hasn’t recorded and stored a single patient allergy record from Ensora since their recent upgrade to V7. This is potentially a massive issue, and it seems counterintuitive that the eRX interface capabilities in Version 7 would actually be a downgrade from the previously working software. In addition, we also saw a global problem with their Ensora integration, as their eRX transactions suddenly started coming through the Ensora API with their EIN number, which broke all their existing provider registrations with Ensora and destroyed their EPCS capability.
I did some extra checking to confirm that Allergy code 232 for NKDA was still valid per Ensora, and it is. And if a provider opens the patient through Ensora, you can see the NKDA, or other recorded allergies there, but even after multiple communication attempts, you won’t get any RX or Allergy data back.
After digging a little further, we found the root cause. For some inexplicable reason, the eRx routines in OpenEMR Version 7 decided to start using the EIN number from the primary business facility as a unique identifier. This is a horrible idea, there is already a unique Ensora/NewCrop Account ID number for anyone using the service. So in addition to breaking the provider registrations , this also causes the RX/Allergy data retrieval to fail, but the system changes the import flag for the patients to a status of “4” anyway, and stops trying to refresh the patient’s RX/Allergy data.
As it turns out , the default behavior of previous versions of the NewCrop/Ensora interface, was to use a “1” as the site identifier if no EIN was available in the OpenEMR facility records. So, if your EIN was blank when you started using e-prescribe, and then you later update your facility information and add the EIN, Ensora will suddenly assume that all your registered prescribers have moved to a different facility, all their eRX transactions will fail, and they will lose any EPCS capabilities they may have had.
All these things can be fixed, but it takes time and creates a huge headache for both Ensora and the physicians who are affected. Not really sure what logic led to using an EIN as a prescription parameter. SureScripts isn’t the IRS, they don’t care about taxes. DEA numbers, or NPI, sure, those are relevant, but nobody at the DEA or FDA, or the pharmacy, has any interest in an EIN number, it’s literally got nothing to do with prescribing.
Anyway, sorry for the wall of text, but it seemed this might be useful information that could potentially help anyone doing a system upgrade who suddenly encounters massive problems with e-prescribing and starts to wonder what has gone wrong.