Could RxOps one day become a closed ecosystem?

RxOps was originally conceived solely as a workspace for preparing prompts. However, when my wife, a pharmacist, and I thought aloud about the advantages and disadvantages of this approach, we concluded that the answer was not so simple. In the long term, it may even be better and safer to take this path. It offers several advantages, which I would like to examine one by one. I will then play devil's advocate and consider the disadvantages as well.

Advantages of a closed ecosystem

Tool safety and quality would be easier to guarantee and communicate

If a user currently finishes at the third step, they leave with a prepared prompt consisting of:

• a specially prepared template that includes a description of the task, guidance on the response format, the structure of the final output, the intermediate step, and so on;
• data entered by the professional user.

The problem is that we do not know what happens to the prompt afterwards. We can recommend procedures, train people, and prepare good documentation. However, we can never guarantee what happens to it: which tool the user pastes it into, which model they use, or which reasoning level they select.

Moreover, every web interface has its own particularities and system instructions, which we have no way of knowing. Not to mention that new models are released every month. This is the opposite of laboratory conditions—the kind of conditions that, as the operators of a healthcare IT tool, we would want to establish at least to some extent so that we could control the most important factors affecting the output.

We therefore do not control the main value of RxOps—the tool's final output—and cannot guarantee it to a sufficient degree.

If we close the ecosystem and the entire chat takes place within RxOps, we can select a handful of models and then let users choose from a pool that we have curated. We can control which AI tools the agent uses, such as web search or a code interpreter. We can also control the reasoning level, including at the level of each individual tool. This setup would allow us to prepare high-quality test scenarios tailored to our situation and use them to assess the output returned by the AI. We would have the entire process under our control.

By refining our testing and the resulting metrics, we could then see in black and white what works and what does not. This would help us offer the product to healthcare professionals, whose first question is likely to concern safety: “How do we know that the AI is not hallucinating or lying?”

Structure of the intermediate review and final output

The main intermediate review currently looks roughly like this:

• a brief analysis followed primarily by text such as: “Weight: __ kg; allergy to penicillins/cephalosporins: __; duration of treatment with MEDOCLAV: 7 days; UNIFLOX for nasal use was explicitly prescribed by a physician: __; exact dosing of Mometasone: __; Sinupret: 15 drops 3× daily; ProbioMaxík: Dr.Max, 1 tablet daily. I approve the final proposal with these details incorporated.”

We expect the user to copy the prompt and fill in the blank fields. Within our application, we could turn this step into an attractive, interactive, and practical dynamically generated form. The user could quickly move through it with the Tab key, complete the fields, and start generating the final analysis.

The final output could also take a different form—for example, we could open the PDF immediately after generating it.

Sending files directly from RxOps

We could upload photographs directly for processing, such as pictures of medicine packaging or medical reports from which identifying details have been removed beforehand. This would be a particularly valuable advantage because it could solve one of RxOps's more significant current problems: the slow process of entering medicines and filling in their dosing. We have already introduced Import/Export, but that helps with testing more than it helps a real user. If users could simply upload a photograph of their medicine boxes, that would be an excellent additional aid.

Disadvantages of a closed ecosystem

Setting up billing and its complexity

If we kept RxOps solely as a tool for managing and assembling inputs, billing would be simpler because all processing and usage data would remain with us. If we want to use the OpenAI API, however, we also have to account for the cost of using the models. We will need to think through and calculate the costs carefully so that we do not lose money while keeping the service reasonably priced.

Put simply, our expenses would increase significantly.

Testing will be valuable but expensive

From the beginning, I believe we need to use the best possible model, or at least one of the highest quality. Testing will therefore also cost money, but the investment could later pay off by giving us solid evidence that we can put on the table when answering questions about safety and quality assurance.

More expenses.

Development complexity

I have already mentioned this somewhere on the blog, but connecting to a third-party API creates a great deal of work in the application. It also requires a commitment to keeping both the application and its connection to the third-party API healthy and functional. This will be a challenge.

More expenses, mainly in development time.

Conclusion

I would probably end with what will be obvious to anyone who has read the preceding text: if we want something more and something better, it will cost us. The question is when the right moment to take this path might come in the future.