For most of my career, I have built software for healthcare businesses from the outside, as a consultant, an analytics leader, or a vendor. Last year I co-founded one. Aevora Healthcare is a Georgia home care business focused on pediatric Medicaid nursing and private-pay adult services. We are pre-launch as I write this, in active build.
Building the software inside an operationally regulated business has changed how I think about the work, in ways that are worth recording.
The constraints feel different from inside
From the outside, the regulatory environment in home care looks like a set of compliance requirements you build to. From the inside, the regulations are the operational reality of the business. Every shift is documented. Every documentation gap is a billing risk and a survey risk. The software has to make the documentation easier, not harder.
This sounds obvious. The implication is not. A lot of software for this domain is built by teams who understand documentation as a feature requirement and have not run a shift. The result is software that captures the data the regulator wants and friction that the nurse on the shift absorbs. The software ships. The documentation gaps continue.
The user is not the buyer
In most enterprise software, the buyer is also the user, or the buyer is in the same building as the user. In home care, the buyer is the agency. The user is a nurse driving between patients in three counties. The buyer's incentives and the user's incentives are aligned in theory and not always in practice.
A specific example. The agency wants every visit to produce a detailed clinical note. The nurse, after a long shift, wants to fill the note quickly and get home. Software that requires the nurse to type the note from scratch will produce thin notes. Software that drafts the note from observations the nurse already entered, and lets the nurse edit and sign, will produce thicker notes.
We built our documentation flow around this idea. The nurse captures observations during the visit through a structured flow. The system drafts the narrative. The nurse reviews and edits. The note is signed. The documentation is more complete than it would have been if the nurse had typed it from scratch.
HIPAA is a design constraint, not a checkbox
I have built HIPAA-compliant systems before. Building one where the data is the operating data of the business is different. The audit log is not a compliance artefact. It is the record of who saw what about which patient. The access controls are not a feature. They are the line between an adequately governed business and a regulatory incident.
The implication. HIPAA controls have to be in the architecture from week one. Adding them later is more than a retrofit. It is a re-architecture. We made specific choices that other teams sometimes defer. Field-level access controls. Comprehensive audit logging on read as well as write. Encrypted at rest and in transit, with key management that has named owners. None of these were optional.
Scheduling is the hardest software problem in the business
I expected the clinical software to be the hardest part. It was not. Scheduling is.
Scheduling has to honour patient preferences, nurse qualifications, payer authorisation hours, geographic proximity, nurse availability, overtime constraints, and continuity of care. The constraints conflict. The cost of a wrong schedule is a missed visit, a patient complaint, or an unplanned overtime expense. The schedule is built and rebuilt continuously as authorisations change and nurses call out.
The software we built for this is more sophisticated than the clinical components. It is also where the business gets its operational leverage. A small operational team with good scheduling software can run a meaningfully larger book of business than the same team with average scheduling software.
AI has a place, with discipline
We use LLMs in specific places, with the architectural discipline I have written about elsewhere. Documentation drafting from structured inputs. Sepsis risk flagging on documented vitals patterns. Compliance review of submitted notes against payer requirements.
What we do not do is use LLMs as a control plane. The scheduling logic is deterministic. The billing logic is deterministic. The clinical decision support is rule-based, with LLMs in the role of pattern recognition over text, not of decision-making over patients.
The discipline matters because the regulatory and clinical risk of an LLM making the wrong control decision is high. The risk of an LLM drafting a note that a nurse reviews and signs is low. The architectural choice reflects the failure cost.
What I am taking forward
A few principles I am carrying out of this build.
Build the software for the user, with the buyer's incentives aligned. If the buyer needs documentation and the user resists documentation, the software has to make documentation feel like the path of least resistance, not the opposite.
Treat the regulated artefacts as design inputs, not deliverables. The audit log shape, the access control model, the documentation schema. These should be in the architecture from week one.
Pick the operational problem that is the leverage point. Scheduling for us. Something else for another business. Invest there.
Use AI in narrow, well-bounded roles. Reserve deterministic logic for the parts of the system where the failure cost is high.
The business is pre-launch. I will write more once the data is real.