Healthcare software development, as we practice it, is the unglamorous systems a clinic or health-tech product actually runs on: patient intake, records workflows, imaging pipelines, and the integrations between systems that were never designed to talk to each other. The difference from every other vertical is not the code. It is that one day someone — an auditor, a payer, a regulator, your own counsel — will ask the system to prove what it did, who touched which record, and why. Software that works but cannot answer those questions is a liability with a user interface.
So the controls go in first, not last: access scoped to role, every read and write of patient data logged with who and when, protected health information kept out of application logs and error traces, and a human gate on anything that touches a chart, a bill, or a message to a patient. Not because a framework demands it — because retrofitting an audit trail onto a live system is the most expensive way to build one.
One thing we will not do is wave a badge. We hold no certification, and we will not imply one. What we build is software designed to survive your compliance review: the access-control matrix, the audit-log design, and the data-flow documentation your reviewer will ask for, written down and handed over. Whether your operation is compliant is a determination your counsel makes — a vendor who claims to make it for you is selling something they do not own.
If what you need is an off-the-shelf EHR module or a form tool you already pay for, we will say so on the call. Custom software you have to maintain is a cost, not a trophy, and plenty of clinic problems are process problems wearing a software costume.
Scope
The paper form that gets retyped, the portal nobody uses, the eligibility check that fails silently, the same patient existing under different spellings in different systems. We build the workflow around deterministic matching rules — and a merge that a named person reviews, because a silent auto-merge of two patient records is how the wrong chart gets treated.
Least-privilege access by role. Every read and write of patient data logged with who, what and when. Encryption in transit and at rest. Protected health information kept out of application logs, error traces, analytics events and model prompts. Development and testing run on synthetic or de-identified data — production PHI is not a test fixture.
A record merged, a result released, a bill generated, a message sent to a patient — those pass a named human before they execute. Every gated decision is logged with its inputs, so months later it can be explained to a reviewer instead of reconstructed from memory.
FHIR interfaces, lab feeds, imaging systems, and the EHR export that does not match its own documentation. Real healthcare data arrives malformed: the field that is free text upstream, the feed that goes quiet without an error, the study that arrives before its order. We build for the message that breaks the spec, because it will be sent.
A written runbook, a tested rollback path, and the documents your compliance review will request: the access-control matrix, the audit-log design, where data lives and who can reach it. Yours to run and yours to show — no dependency on us to keep it alive or to answer for it.
Custom — built against your workflow, owned by you outright. The honest trade-off: custom healthcare software development services cost more up front than configuring a platform, and they are the wrong purchase when an existing EHR module or practice-management feature already does the job. The first call is where we sort which one you are actually buying, and we will tell you if the answer is neither.
Ask questions a badge cannot answer. Where does patient data live during development, and is it real or synthetic? Who on their side can read production data, and what records that access? What happens when the lab feed goes down at night — who is notified, and what does the system do with results that arrive late? When you compare healthcare software development companies, the audit-log design tells you more than the logo wall does — ask to see one before you watch a demo.
During the build: development and testing run on synthetic or de-identified data, so PHI never sits in a developer environment. In production: access is least-privilege and scoped by role, every read and write is logged with the person and the timestamp, data is encrypted in transit and at rest, and PHI is kept out of the places it habitually leaks — application logs, error traces, analytics events, support tickets, model prompts. We also keep less of it: fields that are never used are fields that never get breached, and deletion is a designed path, not a manual favour.
No — and in the official sense, neither is anyone else: HHS certifies no vendor, so a 'HIPAA certified' badge is a private company's stamp, not a regulator's. That is worth knowing when you see one on another firm's site. Compliance is assessed across your whole operation — policies, training, agreements — and our part of it is the technical controls: access scoping, audit logging, encryption, minimum-necessary data handling, each documented so your counsel or auditor can verify it rather than take our word.
It depends entirely on what your vendor exposes, and we find that out before scope is signed, not after. Some systems expose a FHIR API, some a nightly export, some a portal and nothing else — and the difference decides what is buildable. The integration path and its limits go into the written scope, so nobody discovers mid-project that the EHR only exports PDFs and calls it interoperability.
Only behind gates, and never as the decision-maker. A model can draft a summary, flag a mismatch, or triage a queue — a human releases anything that reaches a chart or a patient, and the model's output is logged next to the human's decision. PHI does not go to a third-party model API without your written sign-off and the data agreements your counsel requires. Where a rule can be deterministic, it stays deterministic; a model is for judgment calls, not arithmetic and not record-keeping.
Then we say so on the call, before there is a scope to sign. The test we apply: can something you already run do this through configuration rather than code — an EHR feature nobody switched on, a template in a tool you hold a licence for, a shared-inbox discipline? Custom software is the right answer when the workflow is genuinely yours and everything off the shelf genuinely fails it, and that is a claim we test together on a call rather than assume on your invoice.
Founder · he answers these himself
Fixed fee, scoped in writing before anything starts. No hourly billing, no verbal scope.
Related: AI consulting · MVP development · Staff augmentation · How we work