Warning regarding Version 7.x e-prescribe integration - especially after upgrades

OpenEMR Development
1

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.

Version 7.0.x Ensora questions
2

Hi @Penguin8R

That is v useful information for some circumstances. However, there’s a caveat that makes it so that one really ought not be in the situation to experience that issue.

You shouldn’t be trying to activate Ensora yourself, you need an approved/ credentialed vendor, who is the one who will be configuring OpenEMR to work with Ensora. And last time I heard, MI-Squared is the only authorized vendor, and I am the only one here at MI-Squared trained on configuring OpenEMR for Ensora eRx. So if you do manage to get Ensora working without a service contract with us it’s basically theft of our services.

There are some other issues with the basic presumption of your use case but since I know how to deal with them, we don’t really need to discuss them.

Feel free to ask me any questions that you may have!

Best- Harley

3

Hey Harley! It’s Chad, you know me, and you know I’m not doing any kind of unauthorized Ensora access, you can’t get into their system or SureScripts without proper credentialing. There is actually more than 1 Ensora vendor that will provide access to their services via OpenEMR, and it most definitely requires paperwork and subscription fees to get enrolled and establish the connection, but you already know how all that bureaucracy goes.

It really comes down to whether or not the OpenEMR site was originally provisioned for billing either when or before the practice got onboard with e-prescribing. We’ve seen enough issues now with account numbers (or lack thereof) and the system inserting a “1” as a default/placeholder value, that it’s worth letting people know to watch out for it. It can create huge post-upgrade headaches if you’re not aware of it and know to re-check all those site specific values before a system goes “live”. I’m just trying to get the word out so that people doing version upgrades can either avoid these issues, or help them find a resolution quickly if it happens.

4

Hi Chad-
Right, didn’t remember your handle; good to hear from you. Sorry I got a little huffy, we have had people try to sign up to use our Ensora credentials without paying us.

But I get what you’re saying about the EIN etc-- I imagine it’s fairly common for people to try to turn on eRx before the EIN is entered for billing purposes. So thanks for the PSA!
Best- Harley