You might assume that this project came out of a single evening and some “brainstorming” with an AI agent. In terms of the method, you would not be far from the truth. In terms of time, however, that would be very wide of the mark. The journey to this point was long, and I tried many different things. The current form of RxOps is the result of several prototypes and a great deal of thought about what makes sense and where to invest my precious time.
The idea
It began with a simple question that remains central to me today:
How can I bring large language models (LLMs) into a pharmacist's workflow in a way that feels natural and delivers real value?
Other questions gradually followed, and I still think about them:
- “How can I make sure a new tool does not draw the pharmacist away from an in-person professional consultation, but instead supports and improves it?”
- “What is worth developing independently, and which part of the workflow should I leave to existing state-of-the-art tools?”
- “How can I achieve the greatest possible reliability and explain, in such a regulated environment, that an AI response may differ even when the input is the same?”
There is more to it than that. Eight years after leaving community pharmacy, an inner desire to return to pharmacy also draws me to this project. For a long time, I have been considering how to support the professional role of pharmacies and pharmacists in a natural way—one that provides a counterweight to the marketing drive of today's pharmacy chains and other retailers in Slovakia.
Inspiration from the legal sector
-
Praktik AI is a Slovak startup that sells a specialised AI chatbot for lawyers (and, by now, quite a few related products). Its added value comes from a direct connection to the Collection of Laws of the Slovak Republic and, above all, case law. I recall that its website originally said explicitly that this was implemented using RAG.
-
For another client, I also work as part of a larger team developing a chatbot for the legal sector.
Lawyers are a natural target audience. They already spend a great deal of time researching and looking for relevant legislation. They sit at a computer in an office, often alone, and can set aside a longer period for focused work. That gives them room for a deeper discussion with an AI tool. I wondered whether something similar might also suit the pharmaceutical sector.
The sector includes several professions in different settings, each offering different opportunities for working with AI. There are certainly interesting applications in pharmaceutical research, specialised roles in pharmaceutical companies, pharmacovigilance, and clinical trials. I decided, however, to focus on the profession closest to me: the pharmacist, probably also the role with which the public is most familiar.
I made this choice because I worked as a pharmacist for approximately two years and can judge what the work looks like. That experience also revealed the biggest obstacle—one I had in mind from the start but did not always give my full attention. In a traditional pharmacy process, involving a brief handover of a medicine and basic information, a pharmacist has little time to engage deeply with AI and cannot wait long for a response. Even so, I first tried an approach very similar to Praktik AI. I had seen how it worked for lawyers and thought it might work just as well for pharmacists.
Materia Medica—the first project
The application's data foundation was intended to be a collection of summaries of product characteristics (SmPCs) for every registered medicine. I obtained the SmPCs through automated downloads from the Slovak State Institute for Drug Control (ŠÚKL) and the European Medicines Agency (EMA). I then matched the documents to registered products in a database and split them into smaller sections. Using a local model on my gaming computer's graphics card, I turned them into embeddings—numerical representations of text used to find relevant passages. These passages provided context for AI responses through a retrieval-augmented generation (RAG) approach.
I also built a clear search across all medicines in the ŠÚKL registry, covering not only brand names but active substances as well. The search had its own section in the application, but its best feature was that users could find medicines and connect them directly to an AI prompt, incorporating them into its context.
I gradually added a connection to the Slovak Ministry of Health and its reimbursement classification, so every classified medicine also included its current patient co-payment. I planned to add further connections to PubMed or ScienceDirect.
After a while, however, I set the project aside. Of all the projects discussed here, I probably spent the most time on this one. Testing the application and thinking about its use taught me several things:
-
For an independent developer, building a system that matches the quality of ChatGPT and other leading tools such as Claude and Gemini is difficult, even with AI-assisted development.
-
AI could often find and read the information I was processing through RAG after receiving only simple directions in the prompt.
-
How would this actually be used in a pharmacy? That was the question that bothered me most. The analysis took too long. Good things may take time, but this was too slow for ordinary pharmacy work.
The first point in particular led me to the next project. People already use well-known chatbots, and their providers continually improve them. It therefore seemed more useful to build an extension—a “plugin”—where I could focus mainly on AI prompts and context. That was where I saw the project's main value, not in developing and designing yet another piece of software.
ai-pharmacist—a set of tools for Codex
Even before Materia Medica, I used OpenAI's Codex desktop application to develop software. Unlike a web application, it lets you open a local folder and allows an AI agent—like other programming tools such as Claude Code or OpenCode—to create, edit, and delete the files stored there efficiently. It can use command-line tools, Docker, and other tools on your computer that are unavailable directly on the provider's website or cloud for reasons such as computing cost or security.
In this new project, I decided to create a set of “skills”. These are specialised instructions for an AI agent, packaged in standardised files that the agent can use when needed. Their use can also be disabled, leaving only the user able to invoke a particular skill. To simplify the concept, imagine a toolbox from which the AI agent selects a hammer, saw, measuring tape, or another tool according to the job at hand.
The skills I created covered areas similar to Materia Medica: public sources from ŠÚKL and the Slovak Ministry of Health, this time joined by the National Health Information Centre (NCZI); skills for reading scientific sources; and even one for visualising a medical analysis. Some served as orchestrators. For example, slovak-health-context only delegated tasks to other skills that worked with Slovak data.
One interesting feature was—and still is, because the project remains active in my Codex workspace—that the agent created and updated databases of registered medicines and medical devices, reimbursement data, and NCZI statistics on demand as SQLite files in the local project. Whenever data was needed, the AI agent ran a Python script that refreshed the local data and then used it to generate the response.
The drawback is probably clear by now: getting this project into the hands of non-technical users—pharmacists—would be difficult. If software engineers were the target audience, sharing a public GitHub repository would be enough. I needed something simpler and more intuitive. The project's nature also meant it would not work in a web interface. It would work only in desktop applications, and I did not want to create another barrier for pharmacists.
Lily—a “plugin” for pharmacy software
From the beginning, I considered two options:
- give the pharmacist a general-purpose chatbot that accepts text and let them decide how to use it;
- or prepare a tool for a specific professional task, so the pharmacist has to spend as little time as possible thinking about how to phrase the request.
This idea was a detour from my main line of thought. Initially, I believed in it strongly, even though it ultimately created problems and barriers that would be difficult to overcome.
The central idea was to create something immediately available to the pharmacist, with no need to navigate elsewhere: they could remain in the application they used most often, the point-of-sale interface. In Slovakia, that mainly means software such as WinLSS, Apostar, and NRSYS. Following an approach similar to Pharminfo, a Slovak company whose portfolio includes adcc.sk, I wanted to develop a “plugin” and offer it to the makers of this software.
I began developing a server application in NestJS. Through a REST API, it would return a set of dispensing recommendations: short points intended to form the basis of a consultation with a patient. Its inputs would be the contents of the “basket”, other medicines that the pharmacist learned about during the consultation, and the patient's medical history or other important clinical context. At this point, the concept was already getting close to what RxOps offers today. 🙂
The point was that when a queue of patients is waiting in the pharmacy, a pharmacist does not have time for a lengthy analysis. This was meant to be an aid or outline for a better dispensing conversation.
I left the project at an early stage, however. Without contacts or experience, finding business customers (B2B)—the makers of pharmacy software—seemed difficult. Something fully under my control and aimed directly at end users (B2C) suited me better.
Tete—my own NestJS server and a custom GPT
Tete was my first attempt to adapt ai-pharmacist so that it would be technically accessible to non-technical users as well.
It was almost the same as ai-pharmacist, but used different technologies. I replaced the local SQLite databases with a NestJS server under my control and a PostgreSQL database, regularly populated with data from the Slovak government sources mentioned earlier. I intended to use a custom GPT as the user interface. With a short set of instructions and a connection to an external source—my NestJS server—it provided a preconfigured ChatGPT interface that users could find in the publicly available library of custom GPTs.
Yes, “could”. While I was developing the project, OpenAI announced that it was discontinuing public custom GPTs. Users would only be able to create a custom GPT for their own private use. That removed the interface on which my plan depended.
OpenAI can currently also work through a system of “plugins”, but I did not take that route. I had thought of something better—and this finally brings me to what I am building now.
RxOps—the culmination of all these ideas
This brings me to the current project. It certainly does not solve every problem I have mentioned in this article, but I believe it is the best thing to emerge from my AI development workshop in recent months.
It is a platform that addresses only the part of AI analysis that I can influence most: the input. The entire application—the Next.js user interface and the Supabase database, where I keep an updated list of registered medicines synchronised from ŠÚKL—is designed to give pharmacists:
- ideas for using AI;
- a quick, professionally prepared dialogue for assembling context;
- carefully written instructions for AI that they would otherwise have to write themselves every time.
Once the AI prompt is assembled, I send the pharmacist away from RxOps. That is an intentional part of the design. It also offers a broader benefit, because many people already subscribe to premium versions of leading AI tools. I do not lock people into my ecosystem; I give them the freedom to choose what they use. The market offers plenty of options: Claude, ChatGPT, Gemini, Chinese open-weight models, and many other providers.
I provide a tool for preparing a high-quality AI prompt and a place where ideas for useful applications in practice can emerge. I present the complete final prompt to the user transparently instead of hiding it as a trade secret. I also consider the concept of a workbench important. I know it from AI programming tools, where developers see the outputs and can control their workflow. RxOps is intended to be that kind of workbench for pharmacists.
I assume and emphasise that the person making the request has full control over the final form of the result. They are responsible for it and hold all the cards. In my experience, AI-assisted development also produces the best results when a professional uses AI to extend their abilities without giving up control. That is what I want to bring to RxOps.
Vision
The direction of the product will certainly change. The project's development over recent months—and the rapid evolution and availability of AI tools—has already shown me that.
The vision deserves its own blog article, which I will write later. In short, however, I want this project to improve pharmacy, not transform it into something else. I want RxOps to strengthen what is so valuable in a pharmacy: direct, personal contact between a patient and a professional. The bandwidth of ordinary human communication may never match the speed at which computers communicate. Yet human communication carries something deeper that is difficult to name—perhaps empathy, compassion, or goodwill. Alongside the medicines dispensed, that human quality can also contribute to the success of prescribed pharmacotherapy.