Posts Tagged ‘mdtoolbox’

ePrescribing has arrived

May 22, 2014

We are proud to present our users with our new ePrescribing system!  Partnered with MDToolbox, we were able to do a fast screen integration to easily log our providers and nurse assistants into the ePrescribing  program, and implement a behind-the-scenes SOAP interface to safely retrieve information about sent prescriptions.

Screen integration does not require a full-blown prescription network certification, but does include a basic audit (in this case, by Surescripts).

There are a lot of ePrescribing solutions out there, and a lot are built into larger vendors’ EMR functionality (e.g. Allscripts).  We chose MDToolbox because they support importing of medication list by using RxNorm concept ids, which is the dataset on which we have based our medication list and their cost structure is very flexible.

So far our users have had overwhelmingly positive responses. We are not yet cleared for ePrescribing of controlled substances (EPCS) but that will be implemented in the coming weeks.

 

Looking forward:

We consider Ankhos to be a mature clinical oncology platform and going forward, we are looking at ways to improve profitability, not just productivity.

Our current mission is to develop features in Ankhos to ensure that our medical coders have the information they need to bill properly and with lower risk of claims rejection. This will include implementing reminders for clinicians about what drugs are indicated for which diagnosis codes, and make sure that we have the correct information on file.

Some documentation requirements are as simple as “requires diagnosis code 123”, others are more complex: “Must have a diagnosis of xyz AND must have failed 2 prior treatments”. It is easy for a computer to tell us if a patient has a certain diagnosis on their problem list, it is harder to make more Human decisions like “… have failed x treatments, one of which is Oxaliplatin.”

Questions like “Did the patient’s disease progress on drug ABC or was it discontinued for another reason?” are not reliably answered by a computer. We will have to be very careful about how we implement this interface to not lose all of the physician and nurse productivity gains we have made so far, and at the same time increase our reimbursement rates with well-documented encounters.

The American healthcare payment system is constructed around this delicate balance of taking care of patients and getting paid. As developers we must be diligent about listening to our users and must take great care to not trade too many clicks for cash, lest we succumb to the dark side of the Mega-Click EMR.