With its substantial benefits for both patients and physicians, e-prescribing is growing rapidly. In fact, every state in the U.S. now allows e-prescribing and over 70% of U.S. physicians have transmitted at least one prescription electronically. These e-prescriptions can prevent prescription drug errors, speed up the medication process, provide more information to patients, prevent the number of lost prescriptions, and the list goes on. The current issue with e-prescriptions is that the doctor's signature isn't authenticated, making it unreliable, but with apothecary we will be able to change that.

What it does

apothecary is a web application that connects patients with doctors to seamlessly allow for the transfer of e-prescriptions. By implementing DocuSign's API, the doctor is able to provide an authenticate and verifiable signature which can reduce the number of forged prescriptions and related drug overdoses. Furthermore, apothecary immediately emails the patient their prescription which makes it easier and faster for them to buy their medication without losing the prescription.

How we built it

We built apothecary by integrating the DocuSign and MongoDB API's into a Node JS web application environment. We used a non-relational database such as MongoDB to store object-like data such as Provider user info and Patient user info to keep a record of relative user data. DocuSign's API was an integral part of our design as it allowed us to use an "envelope" system to send and receive signed documents between different users. Node JS was ultimately our language of choice because it allowed us to use the node package manager to install routing/rest manipulation packages such as express to help us organize all our REST APIs, which tied well with the REST-like API that DocuSign uses.

Challenges we ran into

Implementing the DocuSign API was a bit challenging due to the authentication that was involved in setting our development environment up with DocuSign. DocuSign makes sure that its API is never compensated (which is a good thing), and as a result their API use requires a double authentication system in which an API key exchanges for an authorization token to allow access to API calls. There were multiple ways to do this authentication on the documentation, but ultimately we had to use a confusing syntax combining different methods of authentication to get access to the DocuSign API calls.

Accomplishments that we're proud of

The biggest accomplishment we're proud of is being able to use DocuSign's API to create an organized work-system in which signed prescriptions are sent to providers to be signed and then directly to the patient to be downloaded directly for use. The envelope system that was implemented not only lets patients experience a more convenient method to attain prescriptions, but also legitimizes any real prescriptions that a provider signs, hopefully avoiding any future prescription fraud.

What we learned

The most valuable skill we learned from completing this project is learning how to implement valuable and secure API into our projects so that we do not have to create functions from scratch. Prior to this project, many of us would create simple projects where its uses and purposes would be coded from scratch. However, with the use of public APIs such as DocuSign and MongoDB, we as developers have to focus less on creating complex interactions, and have more time to focus on making our products a more consummate experience.

What's next for apothecary

Apothecary hopes to implement the FDA API in the future so that patients can find out valuable information about the drugs they are being prescribed to by their providers. By doing so, Apothecary not only brings prescription drugs to e-documentation, but also better educates people on how to practice safe prescription drug use.

Share this project: