I would like to complete a pharmacy software proof concept. But I have a few questions I do not know.

Physician information

In order to refill or dispense a new RX the software needs to have access to a database of current doctors, is there a downloadable database or a service I can interact with to get a list of current practicing doctors ?

Medication information

needs to access a database of medications, which I believe companies like Medispan offer for a price. How much does interacting with these kinds of companies cost.


How can I interface be it with an insurance company, medicare, medicaid, etc for billing ? I have seen these programs are able to submit orders and get a response automatically for how much was billed and how much was paid etc.

What I have done

I started to just work on basic windows form application which would be the client and then I imagine I would have to connect it to my server in order to perform authentication etc before I billed for them from the server.

Are the client applications connecting with the APIs directly or just an intermediary web service which in turn does all the work ?

I also found one open source project http://www.anshealth.com/ but it seems like its pretty complicated to setup and there isn't much documentation. There hasn't been a post in their forums since last year.


I edited my question in order to make it more specific, I have asked specifically three questions.

  • 5
    Although I have voted to close this as too broad, I think there's a question here that has valuable answer. Taking out the specifics, its a common question. "I want to write a simple program to compete with the very large, very expensive, very complex solutions on the market, it all seems so hard and complex and expensive, please help be understand it?. The answer is 'We can't help. It is a very large, very complex and therefore very expensive system for a very good reason. You have under estimated the size, complexity and expense of solving this problem – mattnz Jul 10 '14 at 2:37
  • I dont think it should've been marked as too broad, as my question asks specific questions that someone in the industry might have been able to answer. As to how do current programs interface with medicare, does medicare have an api to bill, etc. Isn't this where broad or design questions are asked as opposed to stackoverflow where very specific issues are asked ? – Eduardo Dennis Jul 10 '14 at 13:56
  • @EduardoDennis: it's not one or two specific questions, it's a very large number of specific questions, many of which won't be known until deep in the project. – Steven A. Lowe Jul 10 '14 at 20:39
  • @StevenA.Lowe Uunless someone reading has gone "deep in the project" and can answer them or provide information and wouldn't mind enlightening the rest of the world, hence the purpose of asking the questions... – Eduardo Dennis Jul 10 '14 at 20:45
  • @EduardoDennis: that would be a book, not a paragraph ;) – Steven A. Lowe Jul 11 '14 at 2:00

Large software products start out as small software products and feature creep from there until it does everything the customer wants it to. Rarely are large products made ex nihilo.

Start small - very small - and increment.

You write the smallest simplest thing you can that works in the realm. Inventory tracking for example. Just write some code that handles inventory and have it grow from there. Once that piece works and could potentially be used, you find potential customers about what it lacks... then you write that piece. And keep going.

Learn from the big

The other option is to get a job in a company that actually has that in its realm of core competencies and has a product that you can sit down with and work to understand. This will let you get a better understanding of the entire architecture of the product.

Study the regulations

If you are trying to write a point of sales register, make sure you understand the PCI security standards so that your software doesn't run afoul of it. If you are working on trying to write something that fits into the healthcare industry, you will want to know and understand HIPAA. Neither of these are small things.

These regulations are part of the reason that the bar is so high - you will probably need a lawyer or an auditor familiar with the regulations (or both) to help you through the process.

In healthcare, there's also a fair amount of liability issues that you will want to work through with the lawyer.

You'll need to pay for the access

The companies that hold those huge amounts of data that they've built and collected over the years - the prescription drug databases with interactions and such... the way they make money is they sell access to that data. They don't just give it away for free.

You will need to come to licensing terms with them.

And each company that you need to work with, you will need to work with. Thats rather obvious, but well, you need to do the research for how to work with insurance providers (it may be you have a printer and a form next to it that runs a report each week and gets sent out or something... I don't know, I haven't researched it).

This is a very large product for one person (or even a small team)

This isn't something that you'll easily be able to dive into. It just isn't - the regulations, the companies that want printed reports with carbon paper because they haven't modernized yet. That system that only speaks EDI.

When you put all these parts together, it isn't a simple windows form that the pharmacist sees. Its a huge system of multiple parts that don't always fit together well and have grown organically over the past few decades.

The companies in this realm often have decades of entrenchment. If you want to learn about all the parts that are there - get a job with one of them to get a better idea of the scope of the software. I may be wrong about all I said (it may be easier, it may be much worse)... but I do know that this is a huge undertaking.

(I'm basing this off of I know how to write a point of sales system... and its a lot bigger than I thought it would be a decade ago... and thats 'easy' with the biggest liabilities being the mismatch of price and posted price in Michigan. Going to healthcare I can only imagine its much more complex... a register doesn't need to post an alert if someone buys regular nails and treated lumber at the same time)


The only way to get access to all those systems is to earn the TRUST of their creators/owners.
And I can tell you right now that you're not going to get that trust as a one person hobbyist or startup with no background in the field.
That's highly sensitive private and financial information you're talking about, data that needs to be seriously protected. Your company will need to go through all kinds of security screening before insurance companies and others will even consider dealing with you.

Yes, the bar is high, very high. And that's for reasons, very good reasons.
If your system makes a mistake, people can die. If it gets hacked, private information about thousands of people can end up on the street, to the great embarasment of your users, and probably severe financial consequences (and in many places criminal charges) for them, and likely for you as well.
If the system gets hacked, it's also an open conduit for massive fraud if you're interfacing with financial systems.

Can a small company earn that level of trust? Sure. But it takes time, lots of time.

Not the answer you're looking for? Browse other questions tagged or ask your own question.