Frequently asked questions

Yes, we build solutions to support HIPAA requirements when HIPAA applies, and we can work under a BAA where the project requires it.

But there is one thing I always explain here: there is no magic “HIPAA compliant AI” button. A major part of compliance sits inside the clinic itself — access policies, staff behavior, password management, devices, internal procedures, training, and the way people actually use the system.

We can make our side compliant and design the architecture correctly. We can also point out obvious problems on your side and help you fix them. What we cannot honestly do is guarantee that the whole clinic becomes compliant just because you bought software from us.

For projects handling PHI, we define where the data is stored, who can access it, what goes to external providers, what is logged, and whether any data needs to be anonymized or processed locally before an external model is called.

There is no one-size-fits-all answer, because the correct architecture depends on the country, your internal policies, your infrastructure, and what exactly the AI is doing.

In the simplest case, we store data in the relevant jurisdiction — for example inside the EU or inside a specific country if local rules require medical data to stay there.

If your policy requires it, we can deploy fully on-premises, including inside restricted network segments where nothing leaves the clinic.

The same applies to AI models. For a low-risk case, using a public model may be perfectly reasonable and much cheaper. For sensitive cases, we can use a local model. A very common hybrid approach is: local software removes PII/PHI first, and only the anonymized or permitted part goes to an external LLM.

From our side, developers do not need routine access to your production patient data. From your side, access is role-based and designed together with you.

So the real answer is: we do not force your clinic into our favorite infrastructure. We design around your actual requirements.

You get your data back. Then, subject to the agreed retention rules, we delete our copies.

I strongly dislike the model where a vendor quietly builds a wall around your own data and suddenly makes leaving extremely painful. Your patient data belongs to you, not to us.

We agree the export format and retention rules in advance. You request the export, we provide it, and we handle deletion according to the contract, applicable law, and backup-retention requirements.

We also do not use your data to train unrelated products for other customers — even if somebody tells you that “anonymized data is harmless.” If we want to use data for anything outside your project, that should be separately agreed with you.

If GDPR applies to your clinic, we design for GDPR. If another national privacy regime applies, we design for that instead.

GDPR started as an EU framework, but healthcare data rules are different across countries. Some jurisdictions impose their own requirements on medical-data storage, cross-border transfer, processors, retention, or access.

That is why I do not like answers such as “yes, we are GDPR compliant everywhere.” It sounds nice and means almost nothing.

For every project we check the actual jurisdiction, data flows, infrastructure, model providers, and the clinic’s own requirements. Then we build the solution around that reality.

For clinical decisions, our answer is: not autonomously.

We build AI that can save a doctor a lot of time — collect history, summarize records, pre-assemble a report, flag abnormalities, suggest what to review, or prepare a draft treatment plan. But for clinically meaningful output, a licensed physician stays in the loop and reviews it before it becomes a medical decision.

There are two reasons.

First, AI that diagnoses or recommends treatment can become regulated medical software depending on the use case and jurisdiction.

Second, modern LLMs can hallucinate. You can reduce this dramatically with RAG, ontologies, rules, constrained outputs, source checks and validation. You cannot honestly promise zero hallucinations.

So we do not build “AI doctor replaces doctor” systems. Besides being a regulatory headache, I simply do not think it is a sensible production architecture today.

It should say: “I don’t know.”

That sounds primitive, but in medical AI it is actually a feature.

One of the nastiest LLM behaviors is inventing a plausible answer when information is missing. A blank answer is visible. A confident wrong answer can slip through.

So we explicitly teach the system what to do when evidence is insufficient: say it does not know, ask for missing information, cite what it does know, or escalate to a human.

This is not solved by one clever prompt. Over years of working with grounding, rules and constrained AI behavior, we developed ways to make this much more reliable.

In healthcare, “I don’t know” is often the smartest answer the AI can give.

We don’t.

I would love to give you a more satisfying answer, but I would rather give you a real one because actual patients are involved.

There is no current LLM-based system that can honestly guarantee 100% absence of hallucinations. Anyone promising that is either using a very narrow deterministic system or doing marketing.

What we can do is reduce the risk dramatically: approved knowledge sources, RAG, structured data, rules, restricted answer formats, source citations, validation, escalation logic, test cases, and full logs.

And for clinically meaningful information, we insist on a human review step before it reaches the patient.

The correct engineering question is not “how do we make AI never wrong?” It is “how do we make it hard to be wrong, easy to detect, and safe when it happens?”

There is no universal answer. It depends on the country, the contract, what the AI actually does, whether it is regulated medical software, who reviewed the result, and who made the final decision.

What I can say operationally is this: do not design the process as if “the AI vendor will be liable, so we are safe.” That is a terrible risk-management strategy.

I compare AI to Excel. If a financial analyst puts the wrong formula into Excel and sends a wrong report, Microsoft does not suddenly become the analyst. AI is obviously more complex and higher-risk than Excel, which is exactly why you need stronger controls around it.

For serious deployments we define roles, audit trails, approvals, escalation paths and contractual responsibility in advance.

AI makes mistakes. That is an axiom. The job is not to pretend otherwise; the job is to build the workflow so one model mistake does not automatically become a medical mistake.

Yes. For production healthcare AI, auditability is not optional for us.

We can log the conversation, user request, data sources used, model/workflow version, retrieved documents, tool calls, generated result, staff approvals, escalations and final action.

Where there is explicit decision logic or rules, we can log that as well.

This is important for compliance, but even more for real life. Eventually somebody will say, “the AI told the patient something strange.” At that moment you either have a proper audit trail or five people start guessing what happened.

I prefer logs.

This is a bit like asking a dentist, “How much will it cost to fix all my teeth?” Nobody serious knows before looking.

A very small healthcare automation can cost a few thousand dollars. A sophisticated system with multiple integrations, custom infrastructure, clinical logic and validation can cost hundreds of thousands.

Our development rates start at around $90/hour, but we do not sell you a random pile of developer hours. A proper project also includes things like discovery, architecture, management, QA, integration, deployment and sometimes training.

The biggest cost drivers are usually not “AI tokens.” They are integration complexity, workflow complexity, infrastructure, security requirements, number of edge cases, and how reliable the thing needs to be in production.

We normally scope first, then give you a transparent estimate tied to actual deliverables.

And yes, our pricing is usually materially below typical US healthcare-development pricing. Being expensive is not a quality metric.

Usually it is mainly a one-time implementation project, followed by support if the system needs ongoing maintenance.

We can also structure it as a subscription if you want to spread costs over time or if the solution includes continuous infrastructure, model usage, monitoring and updates.

I do not believe every piece of software on earth has to become SaaS just because investors like recurring revenue.

We choose the commercial model that makes sense for the project.

That depends on the SLA you need.

At the simple end, it can be regular service-desk support: bugs, questions, technical issues and planned updates.

For critical systems, we can define stricter response times, priority levels, monitoring and 24/7 support.

Support may include technical troubleshooting, infrastructure issues, integration maintenance, staff assistance, workflow/model updates and planning additional development.

The important part is to decide this before launch. If a system is now handling hundreds of patient conversations every day, “call the developer when something breaks” is not really a support strategy.

Typically, a focused project takes around one to two months.

But I have seen useful pilots that can be done in a couple of weeks, and large complicated projects that take many months or even close to a year.

The biggest delays are often not coding. They are unclear workflows, slow access to existing systems, security approvals, vendor integrations, missing data, stakeholders changing their minds, and discovering that three departments use the “same” process in three completely different ways.

For bigger projects, we prefer phased implementation. Get one piece working, prove that it creates value, then expand.

Yes. In fact, we do not like rolling meaningful healthcare AI straight into full production without a pilot.

A demo proves that something works in a controlled scenario. A pilot shows what happens when a receptionist is busy, a patient writes something unexpected, data is missing, the integration is slow, and somebody clicks the wrong button.

That is the useful part.

Depending on the risk, we may pilot on historical data, in a sandbox, in shadow mode, with selected staff, or with a small percentage of real patient traffic.

The goal of a pilot is not to make a beautiful presentation. The goal is to find the ugly edge cases before the whole clinic depends on the system.