Healthcare Software

Integrating a 3rd-party E-Prescribe Engine Into Your EMR

Why use a 3rd party e-prescribe application in your EMR instead of building one from scratch?

There are many reasons to do this - developing an e-pharmacy module is a significant development effort and requires a lot of domain-specific expertise.

Moreover, e-prescribing tools only become really effective once they are SureScripts certified and they need to be continually updated with the latest prescription data. A lot of effort in cost and time if it's not your core competency. 

So with 100+ certified e-prescribe engines already out there, why re-invent the wheel? 

A typical E-Pharmacy integration - What does it look like?

Almost all e-pharmacy integrations are done as 2 independent applications: your EMR and the E-Prescribe application.

Depending on which 3rd party you chose, the e-prescribe application can be client/server desktop (e.g. ScriptSure eRx) or a web application running in a browser (e.g. Rcopia by DrFirst).

Most 3rd parties allow their e-pharmacy applications to be re-branded to have your company name and logo, but otherwise the UI cannot be customized. The reason for this is that any further customization of the UI requires you to re-apply for SureScripts certification, which can take between 6-12 months, after you have developed the code. 

Some solutions such as Rcopia offer full UI customization, to the point that your e-prescribe module can appear as just another feature within your EMR application. As well they offer support in getting your custom UI SureScripts-certified and CCHIT-certified . But again there is a time trade-off - wait the additional 6-12 months for certification, or go to market sooner with a visibly distinct e-prescribe application. 

We've heard of organizations who opt for a dual strategy - the basic branding in the first release, and the fully integrated version later on. The trade-off, however, is that initially the look and feel of the EMR application and e-prescribe module can be totally different.

Where Does the Data Go?

While some E-Prescribe vendors might offer customization so that their module is actually reading and writing all of its data in your EMR's databases, the typical model is to periodically synchronize data between the 2 systems:

• the master copy of the EMR users (physicians, nurses, etc.) is stored in your EMR, and mirrored on a regular basis in the E-Prescribe database allowing for single sign-on
• the master copy of the EMR patient demographics and patient allergies is stored in your EMR, and mirrored in the E-Prescribe database
• the master copy of all e-prescribe data (submissions, events, receipts, etc.) is stored in the 3rd party vendor's secure cloud, and mirrored in your EMR

The last one might be a showstopper for some who absolutely need all data stored in their own system's DB, though for most EMR vendors the compromise should be acceptable.

Another thing to be aware of is that your EMR must store its patient allergy information in NDC code format, otherwise the e-Prescribe module will probably not be able to use that data to warn of adverse effects of various medications.

The time and cost savings of integrating a 3rd party solution are very compelling, but there are some trade-offs. If your organization is planning to go the 3rd-party route, keep these trade-off's in mind, and include business and risk mitigation strategies as before you sign-off on your EMR software development plan.