Healthcare Software Development
We build HIPAA-compliant platforms, integrate EHR and EMR systems, design FHIR APIs, and ship healthcare AI architectures that actually pass audit. Founders and engineering leaders at U.S. healthtech companies trust us to turn modernization roadmaps into shipped software, without the offshore quality drift or the boutique price tag.
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.
We work across the full lifecycle of regulated healthcare software, from architecture decisions made on day one to integrations shipped in year five. Engagements range from focused 6-week sprints (e.g., adding FHIR support to an existing product) to multi-year embedded teams (e.g., rebuilding a legacy HIPAA platform on modern infrastructure while keeping it live).
Greenfield builds of healthcare platforms: patient engagement systems, clinical decision support tools, remote monitoring software, healthcare marketplaces, care coordination platforms. We start from the regulatory envelope (what PHI is in scope, what BAAs you'll need, what state residency requirements apply) and work outward into the application architecture. The result is software that's compliant at the foundation, not retrofitted later.
Most healthcare software touches at least one EHR or EMR system, usually Epic, Cerner (now Oracle Health), Athenahealth, eClinicalWorks, NextGen, or one of the dozen smaller systems used by specialty practices. We build integrations over FHIR, HL7 v2, SMART on FHIR, CDS Hooks, and legacy proprietary APIs. Our EHR integration engagements typically include data mapping, idempotency design, error reconciliation patterns, and the often-undervalued work of testing against sandbox environments that don't match production.
Whether you're exposing your platform's data over FHIR or consuming FHIR endpoints from a partner, we design resource models that survive schema drift across versions (R4, R4B, R5). We've shipped FHIR implementations against the Argonaut profiles, US Core, and several payer-specific extensions. We also know when not to use FHIR. Some integrations are still faster as direct HL7 v2 over MLLP.
Sometimes the engagement is a design, not yet a build. We bring architects who've shipped multiple HIPAA-regulated platforms to review your proposed architecture or design a new one. Deliverables include control mapping (which technical controls satisfy which HIPAA requirements), data flow diagrams, BAA inventory, audit log design, and a written risk analysis. Procurement teams ask for these documents; we help you have them before they ask.
Adding LLM-powered features to a healthcare product: clinical note summarization, intake automation, prior-auth drafting, conversational interfaces, without breaking your compliance posture. We design the PHI boundary (what data the model sees, where inference runs, what gets logged) before we write the first prompt. More on this below.
The patient-facing surfaces of healthcare platforms have their own stack of concerns: WCAG accessibility, multi-language support, identity proofing, OAuth flows that survive the realities of consumer email and SMS, telehealth video with HIPAA-acceptable encryption, and integration with patient identifiers that aren't quite SSNs but aren't quite arbitrary IDs either.
Building the data infrastructure underneath healthcare products: analytics, longitudinal patient records, claims data integration, de-identification pipelines, research data sharing. We use the same modern data stack the rest of the industry uses (dbt, Snowflake or Redshift, Airbyte/Fivetran), but with PHI-aware patterns layered on: tokenization at ingest, row-level access controls, query-time audit logging, lifecycle policies that handle Right of Access requests under HIPAA §164.524.
We engage as a fixed-scope project team (most common for new builds and well-defined integrations), as an embedded dedicated team (multi-year platform work), or as staff augmentation when you have a CTO and architecture in place and just need senior engineers who can ramp quickly on regulated work. Minimum project size is $25,000; most engagements land in the $50,000 to $200,000 range. We don't take work below that threshold because we can't ship our quality bar at that scale.
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.
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:
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.
Every healthcare software product that wants to reach hospital systems or large practice groups eventually has to integrate with the EHR. This is one of those problems that looks tractable from the outside and gets harder the closer you look at it.
The visible part of the iceberg: the EHR has APIs. Some are FHIR. Some are HL7 v2. Some are proprietary. Documentation exists. Sandbox environments exist. There's a Postman collection.
The submerged part:
We've shipped EHR integration software across Epic, Cerner/Oracle Health, Athenahealth, eClinicalWorks, and several smaller systems used by specialty practices. The lesson isn't a clever pattern; it's that the work is more careful than it looks. Plan accordingly.
The distinction between EMR (Electronic Medical Record) and EHR (Electronic Health Record) has become mostly semantic. Most modern systems are EHRs in practice. We use "EMR integration" when working with practice-focused systems used by single or small group practices, and "EHR integration" when working with enterprise-grade hospital systems. The technical work overlaps significantly but the operational realities (who has access to configure things, how fast support tickets get answered, what downtime windows look like) differ.
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.
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.
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.
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.
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.
RecoveryLink came to us with a working healthcare platform that had outgrown its original architecture. Compliance was on attestation, not evidence. Adding features required regression-testing everything because the system was a monolith with implicit coupling. The team wanted to move to microservices, but doing it while keeping the platform live and compliant was the challenge.
We led the architectural rewrite over a phased migration. PHI boundaries were redrawn explicitly, with services tagged by data sensitivity and traffic flowing through documented APIs at every boundary. Audit logging was redesigned as an append-only stream with cryptographic chaining. Encryption key custody was moved to a dedicated KMS with documented rotation procedures. The architecture passed a HIPAA risk assessment with no findings.
The result: a platform that ships features 3-4x faster than the previous monolith and survived its first formal HIPAA audit without remediation requirements.
Read the RecoveryLink case study →
Hub Central is a digital village platform helping older adults stay independent at home, with conversational AI avatars, themed health pavilions, and integrations with HealthKit and Fitbit. The product crosses several regulatory domains: consumer health data, HIPAA-covered scenarios when health data is shared with care providers, and the practical realities of building voice interfaces for users with vision and hearing differences.
We architected the AI conversational layer with the PHI boundary described above, designed the device integration patterns for health data ingestion, and shipped the WCAG-AA accessible patient experience. The conversational AI runs in a model-isolated service so the rest of the platform doesn't carry the AI architecture overhead.
Read the Hub Central case study →
Not every engagement we're proud of is on the public site. Some clients prefer their vendor relationships stay private. If you're evaluating us for a healthcare software development engagement, we'll share references and case material under NDA, including work for some of the named enterprise clients you'll see on our homepage.
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.
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.
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.
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.
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.
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.
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.
We get a fair question on every initial call: "Why you, not one of the other twenty options?" The honest answer is some combination of these:
The honest range for a senior nearshore healthcare software development team is $25 to $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 to $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.
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.
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.
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.
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.
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.
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.
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.
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.
A first conversation is 30 minutes. We'll listen to what you're building, ask sharper questions than a sales person would, and tell you honestly whether we're the right team for it. If we're not, we'll usually know one.
