Building software for healthcare is different from building an ordinary SaaS product.
The system does not simply need to be fast, scalable, and easy to use. It also needs to preserve trust, maintain clear data provenance, handle sensitive workflows, and ensure that automation never quietly becomes a clinical decision.
At RXI Care, these challenges have shaped many of the engineering decisions behind its Clinical OS. From enforcing AI approval at the database level to choosing a modular monolith over microservices, the lessons are less about following technology trends and more about building software around the realities of clinical work.
Here are some of the key lessons.
1. AI Approval Should Be an Architectural Rule
One of the most important principles in an AI-powered clinical system is that an AI-generated draft should not automatically become part of the clinical record.
A simple implementation would be to enforce this rule inside the application through permissions, middleware, or a service-layer check.
But application-level rules can eventually be bypassed.
A new endpoint, background job, migration script, or administrative tool could unintentionally create another path around the original restriction.
For a clinical system, that is more than a technical inconvenience.
An unapproved AI-generated observation could end up looking like something written or confirmed by a practitioner.
That is why the approval boundary can be enforced at the database level. The architecture itself helps prevent an AI draft from becoming an approved clinical observation without passing through the required practitioner approval process.
The broader lesson: if a rule is important enough to define in your architecture, it should be enforced at a layer where future code cannot easily bypass it.
2. Sometimes a Modular Monolith Makes More Sense Than Microservices
Microservices are often presented as the natural next step for growing software platforms.
But distributed architecture is not automatically better architecture.
RXI Care takes a modular monolith approach: multiple clearly separated modules operating within a single deployable system.
The reasoning is practical.
A small engineering team may not have the organisational problem that microservices are designed to solve. Introducing multiple services too early can instead add distributed-system complexity—more network boundaries, partial failures, harder transactions, and additional observability requirements.
A modular monolith can provide many of the benefits of strong service boundaries without immediately introducing the network between them.
Clear ownership of data, explicit interfaces, and disciplined module boundaries can keep the architecture organised while leaving room to separate a module later if it genuinely needs independent scaling.
The lesson is simple:
Build the boundaries first. Distribute them when there is a real reason to do so.
3. The Smallest Unit of Clinical Data May Not Be the Consultation
When designing clinical software, it is natural to think of the consultation as the fundamental unit.
One patient visit.
One consultation.
One clinical note.
But a consultation is actually a container for many smaller clinical observations.
A symptom may have a modality. It may come directly from the patient, from the practitioner’s observation, from a previous record, or from an AI-generated draft that was later confirmed by the practitioner.
Thinking at the observation level creates important advantages.
It makes provenance easier to represent: where did this information come from?
It also makes longitudinal comparison more meaningful. Instead of searching through several free-form notes, the system can potentially track how a particular observation changes across multiple visits.
Most importantly, approval becomes a property of the observation itself rather than simply a property of an entire document.
This is a powerful principle for healthcare data modelling:
The data model should reflect the actual unit of work being performed.
When it does, auditing, comparison, and future functionality become easier to build.
4. Voice AI Costs More Than Just the Language Model
Voice-first healthcare software introduces another engineering challenge: understanding what actually drives infrastructure costs.
It is easy to focus on the cost of the large language model because LLM pricing receives most of the attention.
But an end-to-end voice pipeline contains several components.
Audio must first be processed through speech-to-text. In clinical consultations, the amount of audio can be substantial, and diarised transcription adds another layer of processing.
In RXI Care’s measurements, speech-to-text represented roughly five times the language-model cost for the same consultation.
That has a direct impact on product and pricing design.
If infrastructure costs are driven primarily by audio duration, then measuring usage simply by the number of consultations can hide significant differences between a short follow-up and a lengthy first consultation.
For voice-based healthcare software, audio minutes can therefore be a more honest usage metric than consultation count.
The lesson extends beyond healthcare:
Before designing pricing around usage, measure the entire technical pipeline.
5. Healthcare Software Must Be Designed Around the Clinician
Technology adoption becomes difficult when software expects users to adapt their workflow around the product.
Clinical software faces an even greater challenge because the user’s attention is already occupied.
A doctor may have only a few minutes between patients. During a consultation, their attention belongs to the person sitting in front of them—not to learning a complicated software system.
That changes how healthcare software should be designed.
Features should be understandable without extensive training. Failures should be visible and recoverable. Most importantly, AI-generated information should be clearly distinguishable from information that has been confirmed by the practitioner.
This is especially important for AI clinical documentation.
If an AI system produces a draft, the interface should make its status obvious. The practitioner should know what the system generated, what has been reviewed, and what has actually entered the clinical record.
Good UX in healthcare is therefore not simply about making software attractive.
It is about reducing cognitive load during a clinical interaction.
6. What These Lessons Mean for AI Healthcare Software
These engineering decisions point toward a broader principle.
Building AI healthcare software is not simply about connecting an LLM to a clinical workflow.
The surrounding architecture matters just as much.
A reliable clinical platform needs to consider:
- Where AI-generated information can enter the system
- How practitioner approval is enforced
- How clinical observations are represented
- How information is traced back to its source
- How patient information can be compared over time
- What actually drives infrastructure costs
- How the interface behaves when clinicians are busy
- How clearly AI-generated information is distinguished from practitioner-confirmed information
The AI model is only one component.
The real product is the system around it.
The Future of Clinical Software Is About Trust as Much as Intelligence
The next generation of healthcare software will likely become increasingly capable of capturing, structuring, and working with clinical information.
But capability alone is not enough.
For clinicians, trust comes from knowing what the system did, where information came from, what remains a draft, and where human approval is required.
That makes architecture a clinical concern—not merely an engineering concern.
At RXI Care, this philosophy shapes the Clinical OS: technology should reduce unnecessary cognitive and administrative load while keeping the practitioner firmly in control of the clinical record.
The goal is not to build software that replaces clinical judgment.
It is to build software that respects it.
Frequently Asked Questions
What is clinical software architecture?
Clinical software architecture is the technical structure behind software used in healthcare workflows. It covers how clinical data, AI-generated information, users, approvals, modules, and system components interact while maintaining reliability and traceability.
Why is AI approval important in clinical software?
AI-generated information should not automatically become part of a clinical record. A clear approval workflow allows practitioners to review and confirm AI-generated content before it becomes an approved clinical observation.
Is a modular monolith suitable for healthcare software?
A modular monolith can be suitable when a development team needs clear module boundaries without immediately taking on the complexity of distributed systems. Individual modules can later be separated if there is a genuine need.
How is AI used in clinical documentation?
AI can assist with capturing and structuring information from clinical interactions, creating drafts that practitioners can review. The practitioner remains responsible for reviewing and approving the final clinical information.
Why is data provenance important in healthcare?
Data provenance shows where a clinical observation originated. Distinguishing between patient statements, clinician observations, previous records, and AI-generated drafts can improve traceability and support auditing.
Final Takeaway
The hardest part of building AI for healthcare is not necessarily choosing the latest model or framework.
It is designing a system where technology, data, workflow, and human judgment work together without compromising trust.
That means enforcing important rules at the right architectural layer, modelling clinical information at the right level, measuring the real cost of voice infrastructure, and designing around clinicians rather than forcing clinicians to adapt to software.
For healthcare technology, those fundamentals may matter more than any individual AI model.