How We Built CareAxis: Lessons from Healthcare Product Development

CareAxis started with a specific problem we kept encountering across healthcare client engagements: clinical staff spending 30–40% of their time on administrative coordination — scheduling, documentation, follow-up communication, insurance authorization — rather than patient care. The technology existed to automate most of this. The integration capability to connect across the fragmented healthcare technology landscape did not, at least not in a form that mid-sized health systems and specialty practices could actually deploy.

Building CareAxis taught us more about the gap between "technically possible" and "clinically deployable" than any other product we have built. This is the honest account of what we learned.

Table of Contents

• The Problem We Were Solving
• Early Architecture Decisions We Got Right
• The Mistakes We Made
• HIPAA and Security Architecture
• FHIR Integration: What We Expected vs Reality
• Clinical Workflow Research That Changed Our Design
• The AI Layer
• Deployment and Go-Live Lessons
• Where CareAxis Is Today
• What We Would Do Differently

Key Takeaways

• Clinical workflow research is not optional for healthcare software — we redesigned three major features after observing clinicians use prototypes in real care environments
• FHIR R4 is better than what came before, but real-world EHR FHIR implementations have enough variation to require significant EHR-specific adaptation work
• HIPAA compliance built into the architecture from day one is 3–5x cheaper than retrofitting it — we learned this by watching other products in the space
• The AI features that got the most clinical adoption were not the most technically sophisticated — they were the ones that fit naturally into existing workflows without requiring behavior change

The Problem We Were Solving

Healthcare administrative overhead is not a new observation — it has been documented, complained about, and partially addressed by technology for decades. What drew us to the problem in 2022 was a specific conversation with a practice administrator at a specialty orthopedic group. She showed us her team's workflow: 14 steps, across 5 systems, to complete a prior authorization for a joint replacement. Three of those systems had no API. Two of them required manual PDF processing. The total elapsed time from request to authorization decision was averaging 4.5 days. Clinical staff reported spending 2.5 hours per authorization on average.

This was not a data problem or a model problem — it was an integration and workflow automation problem. We had the capability to solve it. The question was whether we could build it in a form that health systems could actually implement without a year-long IT project.

Early Architecture Decisions We Got Right

FHIR-First API Layer

We decided early to build the CareAxis data layer entirely on FHIR R4 resource types, rather than defining a proprietary data model and mapping to FHIR for export. This was the right call. When we integrated our first Epic customer, having a FHIR-native architecture eliminated an entire mapping layer that would have been significant ongoing maintenance. It also meant we could participate in the broader FHIR ecosystem — smart app launch, patient access APIs, bulk data export — without integration work.

Event-Driven Architecture for Clinical Workflows

Clinical workflows are asynchronous by nature: a prior authorization request goes out, an insurance response comes back hours or days later, a clinician acts on it when they have time. Designing CareAxis as an event-driven system from the beginning — rather than a request/response system with polling — produced an architecture that matched the actual workflow structure better. Every state change in a clinical workflow produces an event; every interested component subscribes to relevant events. This pattern has proven extensible as we have added new workflow types.

Tenant Isolation with Separate Schemas

We chose separate PostgreSQL schemas per health system tenant from the start, despite the higher operational complexity. The rationale: healthcare regulatory requirements (HIPAA, potential HITRUST certification path) and customer security expectations in the sector made strong logical isolation a competitive requirement, not a nice-to-have. Retrospectively this was the right call — enterprise health system procurement security reviews consistently evaluate data isolation architecture, and our separate-schema approach has been a differentiator. See our multi-tenant architecture guide.

The Mistakes We Made

Underestimating EHR Variation

We assumed that FHIR R4 compliance by major EHRs would mean a largely standardized integration experience. We were wrong. Epic's FHIR implementation, Cerner's, and Meditech's are all R4 compliant but differ significantly in: which resource types are supported, which extensions are available, what the authentication flow looks like, and which bulk data operations work in practice versus what the specification allows. Our first three EHR integrations each required 3–4 weeks of EHR-specific adaptation work we had not budgeted. We now budget 8 weeks per EHR integration and are rarely surprised.

Over-Engineering the First AI Feature

The first AI capability we built was a complex prior authorization recommendation system that analyzed clinical documentation and predicted authorization likelihood across insurance combinations. It was technically sophisticated and clinically accurate in testing. It had single-digit adoption among clinical staff in the first three deployments.

The reason: it required clinicians to navigate to a separate CareAxis screen, enter a query, and interpret a probabilistic output before returning to their workflow. The friction was small in absolute terms but large relative to the mental cost of behavior change for busy clinicians. We replaced it with inline authorization hints embedded directly in the existing workflow screen — a simpler model, less accurate, but surfaced in the right place at the right time. Adoption went from 8% to 74% within 60 days. This lesson shaped every subsequent CareAxis feature: embed in the workflow, do not create new workflows.

HIPAA and Security Architecture

We built our HIPAA technical safeguards into the core architecture from the beginning rather than as a compliance overlay. Specifically:

• Every PHI access generates an audit log entry with: user ID, action, resource type, resource ID, and timestamp — these are immutable and partitioned by tenant
• All PHI fields are encrypted at the application layer with per-tenant encryption keys managed through AWS KMS — database compromise does not expose patient data
• Automatic de-identification pipeline for all data used in development and testing environments
• Role-based access control at the resource level: a care coordinator can see scheduling data but not clinical notes; a billing specialist can see claims but not diagnoses

This architecture cost additional development time upfront — approximately 6 weeks of additional engineering in the initial 8-month build. It has saved significantly more than that in customer security reviews (CareAxis passes enterprise security questionnaires with minimal supplemental documentation) and audit preparation. See our detailed HIPAA compliance guide.

The AI Layer

CareAxis uses AI for four primary functions: clinical documentation summarization for care transitions, prior authorization pre-screening, patient communication drafting, and scheduling optimization for high-demand appointment types. Each was built with the same philosophy: AI handles the administrative cognitive load; clinicians make all clinical decisions.

The documentation summarization feature has been the highest-value AI capability — generating structured care transition summaries from unstructured clinical notes reduces handoff documentation time by an average of 35 minutes per transition. It is also the feature where we invested most heavily in HIPAA-compliant AI inference: all patient data sent to AI models is transmitted through our own HIPAA-compliant proxy, with Business Associate Agreements with all model providers, and with zero data retention for PHI at the inference layer.

For related AI healthcare patterns, see our articles on AI agents in healthcare and AI-powered patient engagement. Learn more at CareAxis platform page.

What We Would Do Differently

• More clinical observation earlier: We did workflow research, but not enough of it in actual clinical environments before beginning development. The features we redesigned after clinical observation could have been designed correctly the first time with 2 additional weeks of field research.
• Earlier customer development conversations with IT leadership: Clinical staff adopt the product; IT and compliance teams approve and implement it. We underinvested in understanding IT stakeholder requirements in our first year.
• Simpler AI for earlier releases: The sophistication of our initial AI features was driven by what was technically possible, not what was clinically needed. Starting simpler and building complexity based on demonstrated value would have been faster to market and equally effective in early deployments.

If you are building healthcare software or evaluating CareAxis for your organization, contact our team. See also our healthcare software development guide and healthcare AI solutions.

Frequently Asked Questions

What EHR systems does CareAxis integrate with?

CareAxis has production FHIR integrations with Epic, Oracle Health (Cerner), Meditech Expanse, and Allscripts. Integration with additional EHRs is available through our professional services team — our FHIR-native architecture makes new EHR integrations faster than custom integrations. Each new EHR integration takes 6–10 weeks depending on the specific EHR's FHIR implementation maturity.

How does CareAxis handle HIPAA compliance for AI features?

All AI inference involving PHI is processed through our HIPAA-compliant infrastructure with BAAs signed with all model providers. No PHI is retained by AI model providers. PHI is de-identified for feature development and model evaluation. Our security documentation and BAA templates are available to prospective customers under NDA during the procurement process.

What was the most technically challenging aspect of building CareAxis?

The FHIR integration layer for EHR diversity. Each EHR presents a nominally FHIR R4 compliant interface with enough variation in implementation that we maintain EHR-specific adaptation code for each integration. Managing this across four production EHR integrations, across multiple EHR version updates per year, while providing consistent behavior to CareAxis customers is the ongoing engineering challenge we invest most heavily in.