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)