Custom healthcare software development for teams shipping in regulated environments.

Healthcare software development is harder than it looks. In 2026 it's harder than it was last year.

The job description for a healthcare software development team has expanded in two directions at once.

On the regulatory side: HIPAA hasn't changed substantially, but the enforcement posture has — HHS audits have shifted from paperwork checks toward technical control verification. State-level privacy laws (California's CMIA, Washington's My Health My Data Act, similar statutes following) layer additional scope on top of federal rules. Procurement teams at health systems now send 80-page security questionnaires before they'll evaluate your product. The bar for "compliant" used to be attestation. Now it's evidence.

On the technical side: AI is rewriting what's possible. LLMs can summarize chart notes, draft prior-authorization letters, transcribe clinical encounters, surface patterns across longitudinal records — all things that previously required either a clinician's time or a multi-million-dollar rules engine. But none of these are usable in production until the architecture handles PHI correctly. Building "HIPAA-compliant AI" isn't a setting you toggle on; it's an architecture you commit to.

Most healthcare software development teams aren't keeping up with both tracks at once. Established vendors lean conservative — they ship slow, they over-document, and their AI roadmaps are PowerPoint. New entrants ship fast and discover three months later that their stack can't legitimately handle PHI. The teams who win in the next 24 months will be the ones who can move at AI-era pace while staying audit-grade throughout. That's a narrow band of capability, and it's where we live.

HIPAA-compliant architecture is the foundation. Most teams treat it like a checklist.

HIPAA compliance is often discussed as a list of administrative, physical, and technical safeguards — which is accurate but unhelpful. What it actually means for a software development team is a set of architectural decisions made at the start of a project that compound through every line of code afterward. Reverse-engineering compliance into a finished system is more expensive than building it in. Often dramatically so.

What we mean by "HIPAA-compliant architecture"

The core question is: which components of your system can touch Protected Health Information, and what controls do you have on those components? Once you've drawn that boundary clearly, most of the downstream decisions follow.

In practice, our HIPAA-compliant architectures share several common patterns:

• A clear PHI envelope. Services that can touch PHI are explicitly tagged; services outside the envelope cannot receive it. This is enforced at the network layer, not just by developer discipline. Cross-envelope traffic goes through documented APIs with sanitization at the boundary.
• BAA inventory as code. Every third-party service that could touch PHI has a corresponding BAA on file. We maintain this as a checked-in document, not a forgotten PDF in someone's email — so when a new dependency is added in a PR, the BAA gap is caught in review.
• Audit logging as a first-class concern. Every access to PHI is logged with user identity, resource accessed, action taken, and timestamp. Logs are append-only and stored separately from the application database. We use cryptographic verification to detect tampering.
• Encryption everywhere, with documented key custody. At rest, in transit, and increasingly in use (memory encryption where it matters). The harder question — who has access to the keys — gets answered upfront and revisited on every personnel change.
• Identity that procurement believes. SSO via enterprise IdPs (Okta, Azure AD), MFA enforced on admin access, session expiry tuned to clinical workflow realities (not just security maximalism).
• Backup and recovery that's tested. The distinction between "we have backups" and "we have tested restore" is the difference between passing and failing a serious audit.

HIPAA-compliant infrastructure

On the infrastructure side, we typically deploy on AWS, GCP, or Azure — all of which offer HIPAA-eligible services and will sign a BAA covering the eligible service inventory. The work isn't in choosing a cloud provider; it's in choosing the right subset of services within that provider's catalog. Not every AWS service is HIPAA-eligible. We maintain a current inventory of which services we use, which BAA covers them, and which we explicitly avoid.

For U.S.-hosted workloads, we default to US-region deployments with data-residency controls — partly because some clients require it contractually, partly because cross-region data movement adds audit surface.

Building HIPAA-compliant AI in healthcare software

The most common question we got in 2025 was "can we use OpenAI in our healthcare product?" In 2026, that question has evolved. Founders aren't asking whether to use AI anymore — they're asking which architecture lets them ship LLM features without breaking their compliance posture, slowing their roadmap, or building something that can't survive an audit.

The answer depends on three architectural choices, and we'll walk through them as we'd walk through them with you on a call.

1. The PHI boundary on the model

Where does the model run, and what does it see? Options range from "nothing PHI ever reaches the model" (you strip identifiers before inference) to "the model handles PHI directly under a BAA" (OpenAI's Enterprise tier, AWS Bedrock with the appropriate BAA, Anthropic's Claude via authorized providers). Each option has implications for what features you can build, what data leaves your environment, and what changes if you switch model vendors.

For most products, the right answer is a hybrid: structured extraction can often run on de-identified inputs, while conversational features that require context need the model inside the BAA envelope. Our default architecture isolates AI inference into a dedicated service with a clear input/output contract, so you can swap the underlying provider without rewriting product code.

2. Audit and observability for AI

Every AI inference that touches PHI needs the same audit trail as any other PHI access. That sounds obvious, but most early AI implementations skip it because the foundational logging assumptions don't apply cleanly to model calls. We design AI audit logging upfront: which user invoked the model, what prompt was sent (or a hash if the prompt itself contains PHI), what response came back, how long it took, what version of the model.

The same audit log doubles as the dataset for evaluating model quality drift over time. You don't want to discover that your AI assistant got 12% worse after a vendor's silent model update; you want to detect it from your own logs.

3. Human-in-the-loop where it matters

The fastest way to break trust with clinicians is to ship an AI feature that bypasses their judgment on decisions they're professionally responsible for. We design AI features as assistive by default: the model proposes, a human disposes, and the human's decision is the system of record. For some workflows that's a UX detail. For others (clinical decision support that meets the FDA's SaMD definition, for instance) it's a regulatory requirement.

Tools we work with

OpenAI (via Azure OpenAI for BAA coverage), Anthropic Claude (via AWS Bedrock with BAA), open-source models hosted on dedicated infrastructure for the most sensitive workloads, LangChain and the Model Context Protocol (MCP) for orchestration, and the standard set of vector databases and embedding models. We bias toward MCP as the integration layer between LLMs and internal tooling — it's emerging as a useful standard for composing AI features inside complex enterprise stacks.

How we work on healthcare software development engagements

We try to be more transparent about our process than the typical dev shop, because in regulated healthcare software the process matters as much as the result.

1. Discovery and architectural framing (1-2 weeks)

For new engagements, we start by understanding the regulatory envelope, the user populations, the integration surfaces, and the quality bar. We come out with a written architectural framing — a short document that describes the PHI boundary, the major service components, the integration plan, and the build sequence. This is a deliverable, not a slideshow. You own it.

2. Build sprints with weekly demos

Most engagements run in two-week sprints with a Friday demo that shows working software, not a status update. Friday is for showing; Monday is for adjusting scope based on what we just saw. We don't run agile theater — there's no story-point ritual unless the client wants it. We run agile in substance: working software every sprint, scope flexes to reality.

3. Compliance evidence built into the cadence

Audit trails, control mappings, BAAs, and risk-analysis updates are produced as work happens, not retrofitted before procurement reviews. By the time a customer asks for evidence, you have it.

4. Embedded code review and security posture

Every PR gets reviewed. Security-relevant changes get a second review. We run static analysis and dependency vulnerability scanning in CI. We pen-test our own work, and we'll coordinate with your external auditors when they want to test ours.

5. Documentation that doesn't rot

We write documentation as code (architecture decision records, runbooks, BAA inventory, control mappings) and check it into the repo alongside the code it describes. Documentation that lives next to the code stays current; documentation that lives in Confluence rots.

Geography and timezone alignment

Our engineering team is in Montevideo, Uruguay (Eastern Time aligned) with expansion in Colombia (within 3 hours of US West Coast). Our co-founder David Boucher is U.S.-based — when something needs an accountable, U.S.-resident person on the phone, that's him. This isn't a "follow the sun" pitch. It's standard business hours overlap with U.S. East Coast clients and a U.S. point of accountability when it matters.

Healthcare software development — frequently asked questions

How much does custom healthcare software development cost?

The honest range for a senior nearshore healthcare software development team is $25–60/hour, blended. For a small new build (e.g., an MVP patient-facing app with one EHR integration), most engagements land at $75,000–$200,000 over three to six months. Multi-year platform work scales from there. We have a $25,000 minimum because below that we can't ship our quality bar; we'd rather refer those engagements out than ship work we're not proud of.

How long does an EHR integration take?

Six to sixteen weeks is typical for a first integration, depending on the EHR vendor, the depth of integration, and the customer's IT cooperation. The variance isn't in our engineering time — it's in the customer's IT department's response time on sandbox provisioning, security review, and go-live coordination.

Are you HIPAA-compliant?

We sign BAAs with all healthcare clients. Our internal practices (workforce training, access controls, incident response, audit logging on our own systems) are aligned with HIPAA's requirements for business associates. We host PHI on customer infrastructure or on cloud accounts we operate under BAA — never on uncontrolled internal tooling.

Can you build HIPAA-compliant AI features?

Yes — see the Healthcare AI section above. Short version: we architect the PHI boundary on the model upfront, isolate AI inference into a dedicated service with documented data flows, and ensure every inference is auditable. The hard part isn't the AI; it's the architecture around it.

Do you work with Epic, Cerner, Athenahealth?

We've shipped integrations against all three, plus eClinicalWorks, NextGen, and several specialty-focused EHRs. We use the appropriate API surface for each (App Orchard for Epic, the Cerner/Oracle Health APIs for the Cerner family, the relevant REST or HL7 v2 endpoints for the others) and adapt our patterns to each vendor's quirks.

What healthcare software development methodologies do you use?

Agile in substance, not in theater. Two-week sprints with weekly demos of working software. Architecture decisions documented upfront so we're not redesigning during the build. Compliance evidence produced as we go, not retrofitted. We don't impose a methodology on clients who have one that works; we adapt.

Where is your team located?

Engineering in Montevideo, Uruguay (Eastern Time aligned), with a Colombia expansion for U.S. West Coast clients (within 3 hours of PT). Co-founder David Boucher is U.S.-based. U.S. presence in Florida.

How do you protect intellectual property?

Mutual NDAs before any commercial conversation. Standard work-for-hire clauses in our MSA. Code lives in your repos, on your accounts, from day one. We don't keep customer code on our infrastructure.

Can you augment our existing team rather than replace it?

Yes. About a third of our engagements are staff augmentation — senior engineers embedded with an existing client team for six to eighteen months, working under the client's engineering leadership. Common for clients who have strong in-house teams but need surge capacity or specific healthcare regulatory expertise.