# Onix Health — Full Content > Onix Health builds and rescues HIPAA-ready, FHIR-native healthcare software for US digital health startups, hospitals, and MedTech companies. 25+ years of delivery, 60+ healthcare integrations shipped. This is the full-text companion to /llms.txt — the complete content of every service, case study, and article inlined for LLM ingestion. Onix Health is the healthcare engineering practice of Onix Systems. Every engagement can start with a free 5-day technical audit. # Services ## EHR / EMR development URL: https://health.onix-systems.com/services/ehr-emr-development Bespoke EHR modules and bidirectional integrations with Epic, Cerner, Athenahealth, eClinicalWorks, and NextGen. SMART on FHIR launches, HL7v2 routing, and audit trails that clear procurement. ### What we build - **Custom EHR modules** — Specialty-specific workflows your vendor won't build — oncology, behavioral health, cardiology, ophthalmology. - **Bidirectional FHIR R4** — Read AND write — most teams stop at read. We handle write-back, conformance, and graceful failure. - **HL7v2 message handlers** — ADT, ORM, ORU, MDM, SIU — full lifecycle, with retry queues and DLQ for failed messages. - **SMART on FHIR launches** — EHR-embedded apps that pass clinical IT review. Launch URL configuration, scope handling, token refresh. - **Audit logging + access control** — Immutable audit trails, role-based access, break-glass workflows, exportable to your SIEM. - **Legacy EHR migration** — We've migrated off home-grown systems, MEDITECH, and obsolete vendors — without losing 10 years of patient history. ### Tech stack Epic, Cerner, Athenahealth, eClinicalWorks, NextGen, HL7 FHIR R4, HL7v2, Mirth Connect, Redox, Health Gorilla, AWS HIPAA, PostgreSQL ### Compliance HIPAA Security Rule, HITECH, SOC 2, FHIR R4 conformance, HL7v2 conformance ### FAQ **Do you build FHIR servers, or just integrate with them?** Both. We've stood up custom FHIR R4 servers backed by Postgres or DynamoDB for teams who need an EHR-of-record, and we've integrated against Epic, Cerner, and others when the EHR already exists. **Can you migrate off our legacy EHR without losing history?** Yes — full chart migrations with field-level mapping, validation, and dual-write periods for safety. We've migrated multi-decade patient histories without data loss. **How long does an Epic integration typically take?** First production-ready integration: 6-10 weeks including security review on the Epic side. Add 2-3 weeks for HL7v2 + FHIR hybrid flows. ## Telemedicine & telehealth URL: https://health.onix-systems.com/services/telemedicine HIPAA-compliant video, intake, scheduling, e-prescribing, and post-visit workflows. Mobile and web, designed for the workflow — not against it. ### What we build - **BAA-eligible video** — Twilio, Daily, Vonage — picked per use case (group visits vs 1:1 vs async). Fallback to PSTN when bandwidth fails. - **Async + sync visit flows** — Store-and-forward for dermatology and behavioral health. Sync video for acute care. Same patient record either way. - **E-prescribing integrations** — Surescripts, DoseSpot, RxNT. EPCS compliance for controlled substances. State PDMP checks. - **Intake + dynamic forms** — Form engines that branch on patient responses, pre-populate from prior visits, and gate the visit on completion. - **Patient-facing scheduling** — Provider matching by license state, availability, language, specialty. iCal sync, SMS reminders, no-show prediction. - **Post-visit workflows** — Visit notes, e-fax to referring providers, automated follow-up tasking, patient-facing summary. ### Tech stack Next.js, React Native, Twilio Video, Daily.co, Surescripts, DoseSpot, Postgres, AWS HIPAA, Stripe, Twilio SMS ### Compliance HIPAA Security Rule, HITECH, State medical licensing (per-state), DEA EPCS for controlled substances, PDMP integration ### FAQ **Can you handle multi-state licensing routing?** Yes. Per-state provider rosters with license verification, automatic visit-routing by patient state of presence, and audit trails for every routing decision. **Do you support controlled substance e-prescribing (EPCS)?** Yes — full EPCS-compliant workflows with hardware token or biometric two-factor, PDMP integration in supported states, and the DEA-required audit retention. **What's the typical cost of a telehealth MVP?** Production-ready MVPs land between $80K-$150K (12 weeks) for single-state, single-specialty. Multi-state + multi-specialty + EPCS pushes toward $200K+. ## Remote patient monitoring URL: https://health.onix-systems.com/services/remote-patient-monitoring From wearable telemetry to in-home hubs to caregiver dashboards — RPM systems built for the reality of intermittent connectivity, alert fatigue, and CMS reimbursement codes. ### What we build - **Device data pipelines** — BLE, cellular, Wi-Fi, LoRa — we've ingested data from blood pressure cuffs to continuous glucose monitors to in-home environmental sensors. - **AI alerting + triage** — Threshold + ML-based alerting calibrated to your clinical pathway. Caregiver review queues, escalation chains, alert-fatigue metrics. - **Caregiver dashboards** — Census views, individual patient drill-downs, time-on-task tracking for CCM / RPM billing codes (99453, 99454, 99457, 99458). - **Patient mobile companion** — iOS / Android apps for medication reminders, daily readings, education, and async messaging with the care team. - **Intermittent connectivity handling** — Edge buffering, store-and-forward, conflict resolution for late-arriving data. Patients without Wi-Fi still work. - **Care plan engines** — Configurable per-condition pathways. Diabetes, hypertension, CHF, behavioral health — all without code changes. ### Tech stack AWS IoT Core, Azure IoT Hub, MQTT, BLE, React Native, Node.js, Kafka, FHIR R4, PostgreSQL, PyTorch ### Compliance HIPAA Security Rule, CMS RPM billing (99453-99458), FDA premarket cybersecurity (for SaMD), Apple HealthKit, Android Health Connect ### FAQ **Can you integrate our existing device, or do we have to use yours?** Yours. We've ingested data from 40+ device makers (Withings, iHealth, Dexcom, BodyTrace, A&D, and more). If it has an SDK or BLE GATT profile, we can integrate. **How do you handle alert fatigue?** Per-clinician alert budgets, learned thresholds based on individual patient baselines, snooze states, and dashboard metrics that flag clinicians approaching saturation. **Do you handle CMS reimbursement coding (CCM / RPM)?** Yes — every dashboard ships with the time-on-task tracking and chart-note workflows required for 99457/99458 billing. Auditable per-month per-patient. ## Healthcare AI & ML URL: https://health.onix-systems.com/services/healthcare-ai Clinical models trained, validated, and deployed under audit-grade governance. Medical coding, decision support, voice documentation, risk stratification — with explainability built in. ### What we build - **AI medical coding & billing** — ICD-10 + CPT autosuggestion with explainability per code. Coder review queues, accuracy tracking, payer-specific bias correction. - **Ambient voice documentation** — Voice-to-note during patient visits. HIPAA-compliant pipeline, edge processing where required, structured note output. - **Clinical decision support** — Evidence-graded recommendations at the point of care. Rule-based, ML-driven, or hybrid — with full audit trails. - **Risk stratification models** — Readmission risk, no-show risk, sepsis risk, mortality risk. Validated on your population, not someone else's. - **Fraud + anomaly detection** — Claims-level anomaly detection for payers and self-insured providers. Provider-pattern outliers, geographic clustering. - **Imaging + computer vision** — Radiology, pathology, intraoperative guidance. PACS integration, DICOM workflow, FDA-submittable when needed. ### Tech stack PyTorch, TensorFlow, Hugging Face, OpenAI, Anthropic Claude, AWS Bedrock, Azure OpenAI, MLflow, FHIR R4, DICOM ### Compliance HIPAA (de-identified training data), FDA premarket guidance (for SaMD ML), Model risk management documentation, Bias evaluation reports ### FAQ **How do you handle PHI in training data?** Two patterns: (1) de-identify per Safe Harbor or Expert Determination before training, or (2) train inside the BAA-covered environment with no data exfiltration. Per-engagement choice with your compliance lead. **Are your models FDA-submittable?** Yes — when the use case is SaMD. We produce the required cybersecurity documentation, validation evidence, and clinical validation reports alongside the model artifacts. **What about LLMs — can you use GPT-4 or Claude for clinical use?** Yes, when appropriate. We use BAA-covered offerings (Azure OpenAI, AWS Bedrock Claude) and design prompts + guardrails to prevent unbounded outputs. We don't use unbounded LLMs for autonomous clinical decisions. ## Healthcare interoperability URL: https://health.onix-systems.com/services/healthcare-interoperability The hard part of healthcare isn't usually the app. It's the 12 integrations that need to work, conform, fail gracefully, and survive the next EHR upgrade. We've shipped 60+ healthcare integrations across every major standard. ### What we build - **FHIR R4 adapters** — Bidirectional read/write, custom resources, search parameter optimization, paginated bulk export, $export and $import operations. - **HL7v2 routing + transformation** — Mirth Connect or custom interfaces. ADT, ORM, ORU, MDM, SIU lifecycles with retry queues and DLQ handling. - **DICOM workflow + PACS** — Imaging integrations, DICOM SR for structured reports, PACS routing, modality worklists, anonymization. - **X12 claims + remittance** — 837 (claims), 835 (remittance), 270/271 (eligibility), 276/277 (status). Direct payer connections or via clearinghouses. - **Integration platforms** — Redox, Health Gorilla, 1upHealth, Mirth — we know the trade-offs and migration paths between them. - **Conformance + testing harness** — Touchstone, Inferno, Crucible — we run the conformance test suites and ship the results to your QA team. ### Tech stack HL7 FHIR R4, HL7v2, DICOM, X12, CDA, Redox, Health Gorilla, 1upHealth, Mirth Connect, AWS HealthLake, Azure FHIR ### Compliance HIPAA Security Rule, FHIR R4 conformance, HL7v2 conformance, 21st Century Cures Act / ONC certification ### FAQ **Should we use Redox / Health Gorilla, or build direct integrations?** Depends. Integration platforms are faster up-front and cheaper for 1-2 EHR integrations. Direct gets cheaper after 4-5+ EHRs and gives you data ownership. We've migrated teams both directions. **Can you handle ONC certification (Cures Act)?** Yes. We've shipped certified Health IT modules and run the ONC testing for both standalone modules and embedded EHR functionality. **How do you handle Epic's strict access review?** We work with App Orchard / Epic Connection Hub processes. Typically 6-10 weeks from kickoff to production-ready Epic integration including the security review on Epic's side. ## Patient engagement & portals URL: https://health.onix-systems.com/services/patient-engagement Booking, secure messaging, results, billing, education. Built to clinical-grade accessibility standards (WCAG AA), measured against patient adoption, and designed so the experience doesn't end at the login screen. ### What we build - **Patient-facing scheduling** — Provider matching, multi-step intake, calendar sync, reminder workflows, no-show recovery. - **Secure messaging** — HIPAA-compliant patient ↔ care team messaging. Threaded, attachable, route-by-condition, escalation to MA queue. - **Results + records access** — Lab results with patient-friendly explanations, visit summaries, immunization records, downloadable CCDA / FHIR bulk export. - **Bill pay + plan transparency** — Cost estimators, payment plans, financial assistance application flows, real-time eligibility verification. - **Patient education engine** — Condition-specific education served at the right point in the journey. Reading-level adaptive, multi-lingual. - **Mobile-first design** — Designed for the actual patient device fleet — including older Android, accessibility-first, offline-tolerant. ### Tech stack Next.js, React Native, Tailwind, FHIR R4, Twilio SMS, Stripe, Auth0, Plaid, Surescripts ### Compliance HIPAA Security Rule, WCAG 2.1 AA, 21st Century Cures Act (data access), Section 508 ### FAQ **Will patients actually adopt the portal?** We design against adoption metrics — onboarding completion, time-to-first-action, day-7 retention. Portals we've built typically see 60-80% activation vs the industry baseline of 30-40%. **Can you integrate with our existing patient login (MyChart, FollowMyHealth)?** Yes — SSO bridges to MyChart, Athenahealth Patient Gateway, NextGen Patient Portal, and others. Or we replace them entirely. **What about multi-lingual support?** Yes. Translation pipelines built in, with reading-level adaptive education content. We've shipped portals in 6+ languages. ## Clinical decision support URL: https://health.onix-systems.com/services/clinical-decision-support Rule-based and ML-driven CDS, integrated into clinician workflow. Evidence-graded, audit-ready, and designed to stay out of the way until the moment a recommendation could change an outcome. ### What we build - **Rule-based CDS engines** — Configurable rules engines. Drug-drug interactions, allergy checking, dose-range validation, guideline adherence. - **ML-driven recommendations** — Models trained on your population, evidence-graded recommendations with explainability per suggestion. - **CDS Hooks integration** — Native EHR-embedded recommendations via the CDS Hooks standard. Works in Epic, Cerner, Athenahealth. - **Order sets + care pathways** — Standardized, evidence-based order sets per condition. Condition-specific care pathway automation. - **Alert governance + audit** — Per-clinician alert metrics, override tracking, alert-fatigue dashboards, evidence-of-effect reports. - **Clinical validation harness** — Prospective trial infrastructure to validate CDS impact before scaling. Designed for IRB-reviewable deployment. ### Tech stack CDS Hooks, FHIR R4, Drools, Python, PyTorch, Epic App Orchard, Cerner Code, PostgreSQL ### Compliance HIPAA Security Rule, FDA Clinical Decision Support guidance, Evidence-grading frameworks (GRADE) ### FAQ **Will the FDA regulate our CDS as a medical device?** It depends on what the CDS does. We help you scope intended use against the FDA's CDS guidance — there's a meaningful line between non-device CDS (information for the clinician to evaluate) and SaMD (autonomous recommendation). We build for either path. **How do you avoid alert fatigue?** We instrument override behavior and tune sensitivity per clinician. Most engagements get to <10% override rate within the first 90 days — vs industry averages of 40-90%. **Can you measure clinical impact?** Yes. We build the prospective trial infrastructure as part of the engagement — control vs intervention arms, automated outcome tracking, IRB-ready reports. ## Custom CRM for Healthcare Insurance URL: https://health.onix-systems.com/services/custom-crm-healthcare-insurance Salesforce and HubSpot weren't designed for agent-heavy mid-size healthcare insurers — and the math shows it. We build custom CRM layers that wrap your existing policy, claims, and billing systems, and cover only the workflows your team actually uses. Year 2 typically lands ~30% below your prior CRM bill; Year 5 closer to ~50%. ### What we build - **Policy lifecycle workflows** — Quote → bind → renew → cancel state machine with automated reminders, agent assignment, and renewal one-click flows. Built around your real underwriting process, not the default Opportunity object. - **Agent + broker management** — License verification, territory and assignment rules, tiered commission engine, broker payout reconciliation — automated with full audit trail. - **Client servicing console** — Single agent surface for renewals, plan changes, claim escalations, document requests. Replaces the shadow inbox + spreadsheet workflow most insurance ops live in. - **HIPAA-grade data handling** — PHI encrypted at rest, least-privilege access, password rotation, 15-minute idle logout, immutable audit logs exportable to your SIEM. - **Wraps your existing stack** — Integrates with Guidewire / Duck Creek / Insurity / in-house policy systems, your claims platform, billing engine, broker portal. Keeps the parts that work; replaces only what doesn't. - **Private-server deployment** — Deploys on your infrastructure (cloud or private datacenter). No recurring per-seat SaaS fees. You own the code, the data model, and the integrations. ### Tech stack TypeScript, Next.js, PostgreSQL, Azure HIPAA, CakePHP, Angular, FHIR R4, X12 (837/835/270/271), Auth0, Salesforce integration ### Compliance HIPAA Security Rule, HITECH, SOC 2-aligned controls, PHI encryption at rest + in transit, Audit logging exportable to SIEM, Role-based access with least privilege ### FAQ **Do we have to leave Salesforce entirely?** Usually no. Our most common engagement is a custom layer that wraps the parts of Salesforce that work (Accounts, Contacts, Cases, Shield audit) and replaces the parts that don't fit (Opportunities → Policies, agent management, commission). Migration risk is much lower than a full platform replacement. **How quickly do we see savings?** Year 1 is typically flat-to-slightly-lower vs your prior CRM baseline — you're amortizing the build cost. Year 2 lands ~30% below. Year 3 lands closer to ~50%. Break-even on the total program cost (including build) typically hits in Year 4. **What's the typical build cost and timeline?** For a 150-employee mid-size insurer with 3 existing system integrations, the build is 6 months at $150K–250K fixed-price. Add 2 weeks of audit beforehand at no cost. After build: $40K–80K/year ongoing maintenance plus reduced internal admin headcount. **What about HIPAA?** BAA-ready from day one. PHI encrypted at rest (AES-256, customer-managed keys) and in transit (TLS 1.2+). Audit logs immutable and exportable to your SIEM. Deploys on HIPAA-eligible AWS, Azure, or your private infrastructure. **Can you support Medicare-specific workflows (AEP, OEP, MBI)?** Yes. We've shipped CRMs with full AEP/OEP enrollment cycles, Medicare Beneficiary Identifier handling, healthcare proxy assignments, and primary care physician routing as first-class data model elements — not custom fields on a generic Account object. **How is this different from Salesforce Health Cloud?** Health Cloud is a Salesforce package — you still pay per-seat for every user. For agent-heavy ops where 70% of users only need a thin workflow surface, the seat math still doesn't work. A custom layer covers the same use cases at a fraction of the recurring cost, and you own the code. ## SaMD & medical device software URL: https://health.onix-systems.com/services/samd-medical-device-software IEC 62304-aligned development, ISO 13485 quality system, FDA submission documentation, firmware-to-cloud pipelines, and the companion mobile apps that ship alongside your device — all under one team, one contract. ### What we build - **Class II / III SaMD development** — IEC 62304-aligned SDLC from project start. Design History File (DHF) produced inline, not patched at submission. - **510(k) + De Novo documentation** — Software documentation per FDA premarket guidance. Validation protocols, hazard analysis, cybersecurity SBOM, predicate analysis. - **Firmware ↔ cloud pipelines** — OTA firmware updates, telemetry, fleet management, edge inference. AWS IoT, Azure IoT Hub, GCP IoT. - **Companion mobile apps** — iOS and Android apps designed to clear App Store / Play Store medical-device review. Apple HealthKit + CareKit, Android Health Connect. - **ISO 13485 quality system** — Aligned QMS for engagements that need it. Document control, change control, design controls, CAPA workflows. - **Cybersecurity premarket package** — SBOM, threat model, vulnerability response plan, secure update mechanism documentation. Per FDA 2023 final guidance. ### Tech stack IEC 62304, ISO 13485, ISO 14971, FDA cybersecurity guidance, Swift, Kotlin, C++, Python, AWS IoT, Azure IoT Hub ### Compliance IEC 62304, ISO 13485, ISO 14971 (risk), FDA premarket cybersecurity (2023), EU MDR (for European submissions), HIPAA ### FAQ **We've never run IEC 62304 before. Can you bring the process?** Yes. Our SDLC is 62304-aligned by default for SaMD engagements. We bring the templates, traceability matrix, and document control. Your QMS lead sees the artifacts produced alongside the code. **Can you support Class III submissions?** Yes, with partner regulatory consultants for the parts that require submission-specialist depth. We've supported Class III SaMD as the software engineering partner. **How does cybersecurity submission documentation work?** Per the 2023 FDA final guidance, you need: SBOM (we generate from CI), threat model (we author with your team), vulnerability response plan (we draft, you adopt), and secure-update mechanism documentation. All produced as part of the engagement. # Case studies ## Healthcare Provider Portal URL: https://health.onix-systems.com/case-studies/healthcare-provider-portal United States · TPA · Provider Network · Hospitals A US Third-Party Administrator serving 120+ outpatient surgery centers was hitting a scaling wall — the provider support team was buried under phone calls and emails. We shipped an MVP self-service portal in 10 weeks. Claims and referrals now process three times faster; inbound calls dropped 95%. ### Results - 95% — reduction in inbound calls and emails - 3× — faster claims and referrals processing - 120+ — outpatient surgery centers in network - 10 wk — to MVP in production ### The challenge The TPA was a market leader in bundled-payment structures — but as their customer base grew, they hit a wall. Insufficient automation was delaying claims and referrals. The provider support team was buried under phone calls and emails — every question about claim status or referral routing came back to the same overloaded inbox. Scaling meant either hiring more support staff or building self-service. The economics only worked with the second option — and the leadership team wanted MVP in the field within a quarter. ### What we did - Research and competitor analysis of existing HCP portal solutions to set the minimum bar - UX/UI design with interactive prototyping and iterative usability testing across two-week Agile sprints - Built provider self-service: submit, track, and manage case referrals, claims, and payments - Provider onboarding online form — eliminated back-and-forth emails and phone calls to bring new providers into the network - Physician look-up module for geography- and network-based specialist discovery during referrals - Claims and referrals automation: rule-based validation against defined parameters, with automatic entry into the EHR; a dashboard surfaces questionable cases for human review - Integrated contextual live chat with conversation history — routed to the correct support department, with full context preserved across conversations - Salesforce CRM integration with the existing organization stack — reduced routine administrative tasks across the entire provider support workflow ### Tech stack CakePHP, Angular, PostgreSQL, AWS, Salesforce CRM ## Digital Healthcare at Home URL: https://health.onix-systems.com/case-studies/healthcare-at-home Australia · Aged Care · 2017–present · Startups A digital health company in Australia came to us with a vision: white-label software that lets aged-care providers stand up branded apps for patients, carers, and family networks. We rebuilt the platform from scratch, then stayed for 5+ years. Six apps have launched on this foundation. ### Results - 6 — white-label apps live in production - 5+ yrs — ongoing partnership since 2017 - 14 — specialists across the engagement - iOS + Android — + web admin dashboard ### The challenge The previous codebase and design were outdated — the platform needed a full rebuild before it could support white-labeling at scale. Original UX lacked thoughtful user flow. Navigation was ambiguous. No specification existed for developers to work against — the engagement had to start with discovery, not delivery. Five distinct user roles (Captain, Admin, Helper, Inner-Circle Helper, Network) each needed differentiated access and workflow — a non-trivial permissions model on top of a chat, calendar, task, and risk-assessment system. The platform had to scale on demand for multiple white-label tenants while preserving smooth UX for each branded deployment. ### What we did - Discovery: reviewed existing UX, developed detailed user flow, defined MVP scope, composed full specification — the missing artifact the previous engagement never produced - Tested 10 UI versions with UX validation before committing to the final direction — design iterated against user behavior, not assumptions - Built mobile apps in React Native (iOS + Android) plus a web dashboard for organization-level administration - Implemented role-based access for five user types — Captain (network owner), Admin, Helper, Inner-Circle Helper, and the broader Helper Network of family and friends - Shipped risk-assessment (PROM) flows with targeted education and intervention triggers based on patient responses - Built chat with attachments, calendar with task management, and integrations to make care-coordination work in one place (Twilio, SendGrid, Socket.io) - Published to App Store and Google Play; transitioned to long-term support model with continuing updates based on user feedback ### Tech stack React.js, React Native, Sass, Node.js, PostgreSQL, Firebase, Socket.io, Twilio, SendGrid, JWT, Redux > We have worked with Onix for over 5 years. They have been instrumental in developing a digital infrastructure that is helping to build a new model of healthcare. The team is very responsive to our needs as an early-stage company and we would not have been able to achieve our early success without them. > — Co-Founder & Executive Director · Australian Digital Health Company ## Custom CRM for Health Insurance URL: https://health.onix-systems.com/case-studies/custom-crm-insurance California, USA · Health Insurance · Payers A California health-insurance company needed a CRM their account managers would actually use — without paying per-seat for bloated off-the-shelf platforms. We built it custom on a private server, HIPAA-compliant, with workflows mapped directly to their lead-to-customer journey. ### Results - 6 mo — Jan 2023 → Jun 2023 delivery - 0 — recurring third-party CRM fees - 5 — specialists on the engagement - HIPAA — PHI handling on private infrastructure ### The challenge The insurer's account managers needed a digital workflow for managing leads, opportunities, and customers — but off-the-shelf CRMs like Salesforce were too feature-heavy and too expensive at scale. Per-seat costs were a constant tax on team growth. PHI handling required HIPAA-grade controls — encryption, least-privilege access, audit trails, automatic logout — which off-the-shelf SaaS imposed only via expensive enterprise tiers. Insurance workflows (AEP / OEP enrollment, Medicare Beneficiary Identifier, healthcare proxies, primary care physician routing) didn't map cleanly onto generic CRM data models — meaning agents would spend time fighting the tool instead of working leads. ### What we did - Designed the data model around the insurer's actual workflow: Lead → Opportunity → Customer, with state machines for contact, convert, and lost transitions - Built lead-capture from two sources: public web form with explicit consent capture, and manual agent entry - Implemented role-based access control with least-privilege defaults, password rotation, and 15-minute idle logout - Built searchable account views with filters by date, status, assignee, source — plus a full interaction timeline and document history per account - Added insurance-specific reporting: AEP/OEP success rates, monthly lead and opportunity counts, lead-to-closed and opportunity-to-closed ratios - Deployed on the client's private server — eliminated recurring monthly SaaS fees; client pays hosting and maintenance only - Ran user-testing across multiple UI iterations with insurance agents until the system maximized usability — not vendor checkbox completeness ### Tech stack CakePHP, PostgreSQL, Angular, Figma ## Digital Military Wellness — Army Health System URL: https://health.onix-systems.com/case-studies/digital-military-wellness USA & Ukraine · Defense Health · Startups A digital wellness platform for soldiers, veterans, and military families — tablet-optimized for combat-medic workflow, with QR-scan identification, body-injury mapping, vital signs logging, and decentralized data storage built for low-bandwidth environments. Officially presented to the Ministry of Defence of Ukraine. ### Results - 10,000+ — active users in military communities - 2× — faster performance with Svelte stack - 80% — users report improvement in at least one health area - 1 yr — delivery with a 2-specialist team ### The challenge Combat-medic teams in the field lacked quick access to soldiers' medical history. In high-stress situations, medics had to sift through paper-based records — increasing transcription errors during evacuations and delaying critical decisions. Information was fragmented: vital signs, prior wounds, interventions taken, and identification were spread across paper documents that didn't survive field conditions or handoffs to evacuation teams. The system needed to operate in low-bandwidth conditions with offline capability, while remaining HIPAA / GDPR-compliant for personal health data — and decentralized enough to resist single-point-of-failure attacks. ### What we did - Built a tablet-optimized frontend in Svelte / SvelteKit — measured 2× faster page performance vs. traditional React-based comparables in the same workflow - Designed touch-friendly UX for combat-medic workflow: QR or service-ID lookup, body-injury mapping by wound type, time-stamped vital signs entry - Implemented real-time data sync with offline-first capability — the system functions in low-bandwidth conditions and syncs when reconnected - Built medical-intervention tracking that captures tourniquet, bandage, and airway placement with timestamps tied to soldier ID - Integrated DeHealth ID for decentralized, secure identity and data storage — no single-point-of-failure dependency - Added mind-body components: mood tracking, stress assessment, sleep and dietary pattern dashboards for veteran wellness - Aligned data handling with HIPAA, GDPR, and Data Protection Act standards — including consent flows and audit trails ### Tech stack Svelte, SvelteKit, TypeScript, GraphQL, PostCSS, D3.js, Firebase, DeHealth ID ## NowWhat — Cancer Patient Support Platform URL: https://health.onix-systems.com/case-studies/nowwhat United Kingdom · Cancer support · Startups Dr. Zach Dovey, with experience treating patients at world-renowned cancer centers, came to us with a vision: a unified platform for cancer and post-cancer patients combining evidence-based medical content, peer matching, and emotional support. Two years and 16 specialists later, NowWhat is live in the UK. ### Results - 2 yrs — ground-up build - 16 — specialists across the engagement - Matching — algorithm by diagnosis + treatment - All-in-one — info + portal + community ### The challenge Dr. Zach Dovey, who'd treated cancer patients at world-renowned centers globally, identified a clear gap: patients lacked reliable, practical advice combined with emotional support. Existing resources were fragmented across multiple sites. His vision required an algorithm-matched community — connecting patients with similar diagnoses, treatments, or stages — and a content layer of scientifically-grounded advice across treatments, lifestyle, and diet. Critically, the platform had to serve patients whose medical appointments had ended — helping them manage side-effects, cope with recurrence anxiety, and lead a healthy life afterward. None of that existed in one place. ### What we did - Ran product discovery to translate the founder's vision into a buildable scope and identify the requirements that mattered most - Designed a unique matching algorithm allowing visitors to find people with a similar diagnosis or treatment journey - Built the informative website surface: medical articles, Q&A, glossary, real-life patient stories — all managed via WordPress so the editorial team operates independently of engineering - Built the private portal: registration for patients and supporters, medical onboarding, matching, friends-list, private messaging, and a forum scoped for a later release - Spent 40 hours of dedicated discovery on forum technology alone before committing — got the platform foundations right - Shipped via MVP and iterative releases over a 2-year engagement, with seamless communication and a transparent development process - Implemented real-time messaging on Socket.IO + Vue.js front-end for low-latency, persistent peer-to-peer conversations ### Tech stack Vue.js, PHP Hyperf, Socket.IO, WordPress ## Unified Healthcare Analytics Platform URL: https://health.onix-systems.com/case-studies/healthcare-analytics-platform United States · Healthcare Analytics · Hospitals A US healthcare analytics company outgrew SurveyGizmo and needed a unified platform — surveys, dashboards, and analytics tailored to organizational requirements. Over two years we built it from the ground up: integrated survey functionality, dynamic dashboards, and a scalable architecture that 80% of organizations credit with improved decision-making. ### Results - 80% — of orgs report improved decision-making - 2 yrs — ground-up build - 4 — specialists on the engagement - Unified — surveys + dashboards + analytics ### The challenge The client was outgrowing SurveyGizmo — they needed a unified custom platform tailored to the unique requirements of their healthcare-organization customer base, not a generic SaaS. Generating graphics and dashboards at scale required careful attention to user preferences and data-presentation standards — off-the-shelf chart libraries didn't survive contact with real organizational data needs. Users had varying levels of technical expertise. The UI had to balance simplicity (for non-technical respondents and decision-makers) with the functional depth analysts expected. Data integration across multiple sources risked introducing inconsistencies. The platform needed rigorous data-quality protocols, plus scalable architecture for growing volumes of survey data and user traffic without degrading. ### What we did - Built the analytics platform from the ground up, designed against the specific data shapes the client's customers worked with — not against generic survey tooling - Integrated survey functionality natively with the analytics layer — no separate tools to coordinate, no data-export round-trips - Optimized data-processing workflows for fast dashboard and graphic generation, even with multi-source, high-volume datasets - Designed the UI to scale from non-technical survey respondents to power-user analysts inside the same surface area - Implemented quality-assurance protocols around data ingestion to surface and fix inconsistencies before they reached dashboards - Engineered a scalable architecture for growth — in both data volume and user concurrency — with performance budgets enforced at the platform level - Continued evolution over a 2-year engagement: new dashboard types, expanded integrations, and analytics depth as the client's customer base grew ### Tech stack PHP, Angular, PostgreSQL ## House-Call Scheduler for Medical Doctors URL: https://health.onix-systems.com/case-studies/medical-doctors-scheduler United States · Clinic · House-call service · Hospitals A US clinic running daily house calls needed a routing system that didn't fall apart. Administrators were manually planning routes for multiple doctors visiting up to 12 patients a day at homes, nursing facilities, and hospitals. We built a custom admin platform plus a PWA for doctors with offline caching, route optimization, and EHR sync. ### Results - 12 / day — house calls per physician, optimally routed - 10 — report types for administrators - Offline — PWA caches data for weak-signal areas - 6 mo — delivery with a 5-specialist team ### The challenge Administrators were assigning each doctor up to 12 patients daily for house calls — but planning was manual, time-consuming, and error-prone. Integration with existing EHRs was non-negotiable. Patient medical history, diagnoses, medications, treatment plans, immunizations, allergies, imaging, and lab results all had to sync from other providers' systems. Doctors needed to work in the field — at homes, in nursing facilities, in hospitals — often with patchy or no network. The application had to function offline and still produce accurate route optimization. ### What we did - Built an admin panel with mini-CRM + PHI handling: patient and doctor management, schedule creation, role-based access (Super Admin, Admin, Doctor) - Encrypted PHI on the server with EHR-sync flows accepting both manual entry and system import - Built a PWA for physicians — daily routes, patient history, schedule visible weeks ahead, with full offline operation and cache-first sync - Created the route-optimization scheduler: factors in call frequency (biweekly, weekly, specific days), 12-patient-per-day cap, location coordinates, and distance calculations via Google Maps - Added multi-format clinical notes — text, audio, voice-to-text — so doctors can document in their hands-free workflow - Delivered 10 admin reports: Missed Patients, Completed Visits, Audio Notes, Provider Summary, Referral Census, Referrals, Routes, New Patients, Documents, Weekly Route Overview - Released features gradually so the clinic's end-users could test as the product evolved ### Tech stack Angular, TypeScript, PHP, Python, Google Maps API, PWA ## SOLOMIYA — Mental Health App URL: https://health.onix-systems.com/case-studies/mental-health-app Germany · Ukraine · Mental health network · Startups The SOLOMIYA network of 5 German and 20+ Ukrainian healthcare institutions needed a mental-health platform fast. The war had created widespread trauma — PTSD, anxiety, insomnia, acute stress — and traditional in-person services weren't reachable for displaced populations. We delivered backend, UX, and branding in 2 months with a 7-specialist team. ### Results - 2 mo — from kickoff to MVP - 25+ — healthcare institutions in the network - 7 — specialists across design + backend - PHQ — progress tracking + structured weekly plans ### The challenge The war in Ukraine had created widespread psychological distress among displaced populations — PTSD, anxiety, insomnia, acute stress disorders. Traditional in-person mental-health services weren't reachable for many who'd relocated across Europe. The SOLOMIYA network — 5 German and 20+ Ukrainian healthcare institutions — needed a mobile-first solution delivering evidence-based therapeutic content and structured intervention protocols. The platform demanded cultural sensitivity reflecting Ukrainian experiences while maintaining therapeutic effectiveness. And it had to ship in 2 months — distributed teams across Germany and Ukraine — to address immediate population needs. ### What we did - Designed the UX, UI, logo, and core branding — including a logo combining a stylized lotus flower (enlightenment) with outstretched arms (growth and resilience) - Produced wireframes and clickable prototypes before development to validate the therapeutic flow with the SOLOMIYA clinical team - Built the backend (most of the app's logic), with the front-end developed by a parallel team in Germany — coordinated handoff across two countries - Implemented the assessment-and-recommendation engine: initial survey determines mental state and recommends matched meditation courses - Shipped weekly structured plans: educational videos, quizzes, intervention activities — patients unlock subsequent weeks after completing prior assessments - Built progress tracking using PHQ depression and insomnia checklists — weekly surveys reveal psychological condition trajectory - Added a rewards system: score awards for positive assessment results, with profile-level progress visualizations for motivation ### Tech stack PHP, Laravel, Flutter, Figma ## VR Medical Training for a Dutch Hospital URL: https://health.onix-systems.com/case-studies/vr-medical-training Netherlands · VR / medical training · MedTech VR Gorilla — a Dutch studio specializing in 360° video — needed an MVP VR training app to demo for a Dutch hospital. Medical students and interns would navigate realistic hospital scenarios, make clinical decisions, and be evaluated. We shipped on Meta Quest in 2 weeks — and the engagement expanded to 5 additional VR / mobile / video projects. ### Results - 2 wks — MVP delivered ahead of 3-week schedule - Meta Quest — with and without controllers - 360° — stereo video with branching decisions - 5+ — follow-on projects after this engagement ### The challenge VR Gorilla, a Dutch studio specializing in 360° video, needed to demonstrate VR training capabilities to a Dutch medical institution. The hospital wanted an interactive platform for medical students and fresh healthcare professionals — where 'their decisions determine their journey.' The MVP had to support Meta Quest with and without controllers, and ship as an internal tool — no public app store distribution, but still polished enough to evaluate VR as a real training medium. Initial documentation was thin — a few videos and a superficial description. We had to architect the scenario engine, evaluation system, and interaction model from a brief, on a compressed 3-week timeline. ### What we did - Built an intuitive in-VR UI for navigation, scenario selection, and in-app tasks — usable on Meta Quest with and without controllers (eye-gaze + 2-second hold for selection) - Implemented 360° video playback in stereo with branching decision points — users participate in realistic hospital scenarios and their choices unlock the next round - Designed the scoring + evaluation system — points based on multiple-choice answers and response time, with final performance reports for the institution - Architected a tree-like scenario plot model with rounds (video episodes), each ending in a quiz that determines the next branch - Built two app versions: bundled (all scenarios + assets in the app) and server-loaded (dynamic content downloads for scalability and easier content updates) - Built a custom transition editor for non-engineers to author scenario branches via JSON configuration - Tested and locked optimal video specs for the device: stereo H.264 MP4 at 3840×3840, 30 fps with MPEG AAC audio ### Tech stack Unity, C#, AVPro, CurvedUI, Oculus SDK, FFMPEG, LeanTween, JSON ## Salesforce Physician Liaison Tracking URL: https://health.onix-systems.com/case-studies/salesforce-physician-liaison United States · Healthcare organization · Hospitals A US healthcare client needed visibility into physician-liaison field activity — dozens of liaisons running business visits and meetings to build physician-to-provider relationships. The existing outreach app didn't reflect their workflow. We built a mobile-first Salesforce Lightning Aura app in 2 months with a 2-specialist team. ### Results - 2 mo — delivery with a 2-specialist team - Mobile-first — Lightning Aura for field use - All-in-one — visits + meetings + expenses - Real-time — field documentation ### The challenge The client managed dozens of physician liaisons running frequent business visits and meetings outside the organization. Controlling departmental activity at that volume was operationally difficult — and expense management tied to the visits was equally daunting. Their existing outreach application wasn't user-friendly and didn't reflect the liaison workflow. Leadership lacked visibility into field-visit documentation and activity tracking. What they needed was an intuitive Salesforce app for liaisons working from mobile — capable of capturing visit objectives, meetings, and expenses in real time, with controls for executives to review departmental activity at a glance. ### What we did - Designed mobile-first using SF Lightning Aura Components — fitted to the actual physician-liaison workflow, not the generic Salesforce CRM model - Built centralized visit and meeting management — liaisons log activity from the field with one tool - Added visit-objective tracking and completion status, so leadership can see what's planned vs. completed across the team - Integrated expense management and financial controls tied to each visit — eliminated the second tool for trip reimbursement - Designed for both in-person and remote physician meetings — same flow, different context - Set up regular communication cadence with the client to keep development structured and on-time across the 2-month build ### Tech stack Salesforce, Apex, Lightning Aura Components, Visualforce ## Salesforce Medical Support Automation URL: https://health.onix-systems.com/case-studies/salesforce-process-automation United States · Medical support center · Hospitals A US medical support center using Salesforce needed type-specific request registration — different forms for different request types, with conditional fields. Salesforce doesn't ship this out of the box. We built a custom Lightning app in 2 months: support staff now register doctor requests with only the fields that matter per request type. ### Results - 2 mo — delivery with a 1-specialist build - Dynamic — forms per request type - Auto-route — to responsible personnel - Salesforce-native — no external tools ### The challenge The client used Salesforce, but its default request-registration UI presented one generic form for all request types. Support staff had to wade through irrelevant fields for every call. What they needed was type-specific intake — when staff select request type 'Provider', only Provider-required fields show. Same for every other category. Salesforce doesn't provide this conditional-field functionality out of the box, so it had to be custom-built, while staying entirely on the Salesforce platform to avoid introducing another tool into the support stack. ### What we did - Built a custom Salesforce Lightning app for support staff to register medical-center cases - Designed dynamic forms where field visibility is driven by request type — only relevant fields render per category - Implemented the case-routing logic to automatically transfer registered requests to the personnel responsible for that request type - Optimized the form-switching UX so staff move between request types without re-entering shared data - Delivered the entire app on Salesforce platform — no external tools, no integration overhead - Established the workflow: call comes in → staff registers via the app → system stores it → request routes to the responsible team ### Tech stack Apex, Lightning Web Components, Salesforce Platform # Insights ## Build vs buy: when a custom EHR beats Epic or Cerner (and when it doesn't) URL: https://health.onix-systems.com/insights/build-vs-buy-ehr-decision-framework Strategy · 11 min · 2026-06-02 · Valerii Checha, Head of Business Unit Most healthcare organizations don't need a custom EHR — they need a few custom workflows on top of one. Here's the honest decision framework we walk clients through before anyone writes a line of code. The build-vs-buy question for an EHR is almost always asked with the wrong default. Teams assume "buy" is the safe, cheap option and "build" is the expensive, risky one. Sometimes that's true. Often it isn't — because the real choice isn't binary, and the expensive failures we get called to rescue usually come from picking the wrong end of a spectrum nobody mapped. Here's the framework we use in the first conversation, before anyone has committed to anything. ### The default answer is buy If your organization delivers care and you need a system of record — scheduling, charting, orders, billing, a patient portal — you should buy. Epic, Cerner (Oracle Health), athenahealth, eClinicalWorks, and a dozen others have spent decades and billions encoding clinical workflows, regulatory edge cases, and payer integrations you do not want to rebuild. A from-scratch EHR is a 7-figure, multi-year commitment with an ongoing compliance burden that never ends. We will talk you out of building a full EHR more often than into it. That's not modesty — it's where the math lands for most organizations. ### What buying actually gets you - Certified clinical workflows and a defensible compliance posture out of the box - Payer and clearinghouse connections that already work - A vendor accountable for keeping pace with regulatory change (USCDI, information-blocking rules, e-prescribing mandates) - An ecosystem of integrations other vendors already support ### Where off-the-shelf EHRs fail The failure mode isn't the core EHR — it's everything the vendor won't build for you. The specialty workflow that doesn't fit their data model. The patient experience that ends at a 2009-era portal. The integration with the device or app that's central to your business. The analytics the reporting module can't express. This is where teams make the expensive mistake: they either bend their entire operation to fit the vendor's assumptions, or they rip the whole thing out to build custom. Both are usually wrong. ### The build case: three patterns Custom development is the right call in three situations: #### 1. The product IS the software If you're a digital health company and the clinical software is your product — not a back-office tool — you're building. A telehealth platform, an RPM service, a condition-specific care app: these have no off-the-shelf equivalent because the workflow is the differentiator. #### 2. A specialty or model the market ignores Behavioral health, complex care coordination, home-based care, value-based contracts with unusual attribution logic — the long tail of care models that generic EHRs serve badly. Here a focused custom system, or a heavy custom layer, beats forcing a square peg into Epic. #### 3. Integration and experience, not records Most "we need a custom EHR" requests are really "we need a great experience and a few workflows that the EHR can't deliver." That's not a build-an-EHR problem. It's a build-on-top-of-the-EHR problem. ### The hybrid most teams actually need The answer that fits the largest share of our healthcare clients is neither pure buy nor pure build. It's: keep the certified EHR as the system of record, and build the differentiated layer on top of it using SMART on FHIR. - SMART on FHIR apps that launch inside the EHR for clinicians — your workflow, their chart, single sign-on - A modern patient-facing experience that reads and writes to the EHR via FHIR R4 - Bidirectional integration (most teams stop at read; the value is usually in write-back) - A custom analytics layer fed by bulk FHIR export, not the vendor's reporting module You get the compliance and breadth of the bought system and the differentiation of custom, without owning a system of record you'll regret. ### The TCO nobody quotes you Both paths have costs the sales conversation hides. For buy: per-provider licensing that scales with growth, integration fees, implementation consultants, and the opportunity cost of workflows you can't change. For build: not the v1 cost but the ongoing one — security, compliance re-certification, keeping up with regulatory change, and the team you need to maintain it for as long as it runs. A custom EHR isn't expensive because it's hard to build once. It's expensive because it's yours to maintain forever. ### A decision checklist - Is a system of record your product, or a tool that supports it? Product → lean build. Tool → buy. - Can a certified EHR do 80% of what you need? If yes, buy it and build the other 20% on FHIR. - Is your differentiation in the records, or in the experience and integrations around them? Almost always the latter. - Do you have — and will you keep — a team to own compliance for the life of the system? If not, don't build the core. - What's the cost of the workflows you'd have to give up by buying? Quantify it before deciding. If you're staring at this decision, that's exactly what our 5-day technical audit is for: we map your workflows against what's buyable, and come back with a written build/buy/hybrid recommendation and a fixed-price scope. No commitment. ## Redox vs Health Gorilla vs 1upHealth: choosing a healthcare integration platform URL: https://health.onix-systems.com/insights/redox-vs-health-gorilla-vs-1uphealth Interoperability · 12 min · 2026-05-20 · Denis Sheremetov, CTO Three platforms, three very different bets — point-to-point integration, a national clinical network, and FHIR-native patient access. Picking the wrong one can cost you a year. Here's how they actually differ. "Which integration platform should we use?" is one of the most consequential early decisions in a healthcare build, and one of the most under-analyzed. Teams pick based on a sales demo or a logo they recognize, then discover six months in that the platform is optimized for a use case that isn't theirs. Redox, Health Gorilla, and 1upHealth come up most often. They are not competitors in the simple sense — they're optimized for three different problems. Here's the honest comparison. ### What each one actually is Redox is integration-as-a-service: a single API and a managed engine that connects your app to provider EHRs (Epic, Cerner, Meditech, etc.). Health Gorilla is a clinical data network — a query layer into national health information networks (it's a QHIN under TEFCA) plus labs. 1upHealth is a FHIR-native data platform built around patient access, payer interoperability (CMS rules), and bulk FHIR. Said in one line each: Redox connects you to a hospital's EHR. Health Gorilla finds a patient's records across the country. 1upHealth gives you and your patients clean FHIR data at scale. ### Redox: point-to-point integration, managed Strength: if your job is "my app needs to read and write data in my customers' EHRs," Redox removes most of the per-site integration pain. One model, one connection process, a network of EHR connections already established. - Best for: digital health vendors selling into hospitals and clinics that run major EHRs - Model: data flows between your app and a specific provider's EHR you're integrating with - Watch for: cost scales with connections and volume; you still depend on each health system enabling the integration ### Health Gorilla: the national clinical network Strength: query for a patient's records across participating networks without a point-to-point integration to each source. As a QHIN, it's positioned for TEFCA-based exchange. Strong on labs and on aggregating a longitudinal record. - Best for: care coordination, risk adjustment, longitudinal patient history, lab ordering/results - Model: you query the network for data on a patient, subject to purpose-of-use and consent rules - Watch for: coverage and data completeness vary by region and source; treaty-of-use/permitted-purpose constraints shape what you can do with the data ### 1upHealth: FHIR-native data at scale Strength: if you need clean, normalized FHIR R4 — for patient access apps, CMS payer-interoperability compliance, or analytics over bulk data — 1upHealth is built for that natively rather than bolting FHIR onto a different core. - Best for: payers meeting CMS interoperability rules, patient-access apps, FHIR-based analytics and data warehousing - Model: ingest, normalize, and serve FHIR; bulk export ($export) for population-scale data - Watch for: it's a data platform, not a turnkey EHR write-back tool — match it to data-access use cases ### How to choose, by use case - Selling an app into hospitals that needs to live in their EHR workflow → Redox - Assembling a longitudinal record or doing care coordination across providers → Health Gorilla - Meeting CMS payer rules, building patient access, or doing FHIR analytics at scale → 1upHealth - More than one of the above → expect to use more than one. They compose; they don't substitute. ### What none of them solve for you A platform moves data; it doesn't design your data model, reconcile conflicting records, handle patient matching edge cases, or own your compliance. The integration platform is maybe 40% of an interoperability project. The other 60% — mapping, normalization, error handling, conformance testing, and the workflow around the data — is yours regardless of vendor. ### Migration and lock-in All three are abstractions over standards (HL7v2, C-CDA, FHIR). The more you build against a vendor's proprietary conveniences instead of the underlying FHIR resources, the harder you're locked in. We design the internal data layer against standard FHIR and treat the platform as a swappable adapter. It costs a little more up front and saves a migration later. ### A short decision checklist - Write the exact data flow as one sentence: who needs what data, from where, to do what? - Is the source a specific provider's EHR (Redox), a national network (Health Gorilla), or normalized FHIR at scale (1upHealth)? - Will volume and connection count make the pricing model painful at 3× your current scale? - Are you building against standard FHIR resources, or against vendor conveniences you can't port? If you want a second opinion against your specific use case, that's a good first thing to put in front of us — we've shipped 60+ healthcare integrations across all three and the standards underneath them. ## FHIR vs HL7v2: which standard for which integration URL: https://health.onix-systems.com/insights/fhir-vs-hl7v2-when-to-use-which Interoperability · 9 min · 2026-05-06 · Denis Sheremetov, CTO FHIR is the future; HL7v2 runs the present. The common mistake is treating it as a migration. Here's which standard each integration actually calls for — and why most hospitals need both for years to come. A surprising amount of wasted effort in healthcare integration comes from a single framing error: treating FHIR and HL7v2 as old-versus-new, with a migration in between. They're not generations of the same thing. They were designed for different jobs, and in most real environments you'll run both for the foreseeable future. ### They solve different problems HL7v2 is a messaging standard: event-driven notifications flowing between systems inside (and between) hospitals. A patient is admitted → an ADT message fires. A lab result is ready → an ORU message. It's been the backbone of hospital integration since the 1990s, and it is everywhere. FHIR is a resource-based API standard: RESTful, web-native, built for querying and exchanging discrete data (a Patient, an Observation, a MedicationRequest) on demand. It's how modern apps, patient access, and cross-organization exchange increasingly work. ### What HL7v2 is still better at - Real-time, event-driven workflows inside a hospital (ADT, orders, results, scheduling) - Talking to the installed base — most hospital systems speak v2 fluently and may not expose FHIR for what you need - High-volume, fire-and-forget messaging with mature tooling (interface engines like Mirth) ### What FHIR is better at - On-demand queries: "give me this patient's active medications" - Patient- and consumer-facing apps (SMART on FHIR, patient access APIs) - Cross-organization and regulatory exchange (USCDI, CMS rules, TEFCA-era flows) - Discrete, structured data you can reason about — versus parsing pipe-delimited segments ### When to use HL7v2 Reach for v2 when the integration is an event happening inside the hospital and the systems on both ends already speak it: admissions feeds, order entry, results routing, scheduling. Rebuilding these on FHIR just because it's newer adds risk for no benefit when the v2 interface already works and is battle-tested. ### When to use FHIR Reach for FHIR when you're building something new that queries data, faces a patient or external app, or has to satisfy a modern regulatory requirement. Anything consumer-facing, anything crossing an organizational boundary, anything where you want structured resources rather than messages — that's FHIR's lane. ### The both-at-once reality The architecture we ship most often: HL7v2 interfaces feeding an internal pipeline (often through an interface engine), normalized into FHIR resources that the rest of the system — apps, analytics, external APIs — consumes. v2 at the edges where the installed base lives; FHIR in the core and at the modern surfaces. The two coexist by design, not as a half-finished migration. ### A mapping gotcha Translating v2 to FHIR is not field-for-field. v2's loose, locally-customized segments (every site uses Z-segments differently) don't map cleanly to FHIR's stricter resources. The hard part isn't the transport — it's reconciling local v2 conventions, vocabularies, and missing data into conformant FHIR. Budget for that reconciliation; it's where v2-to-FHIR projects actually spend their time. If you're choosing a standard for a specific interface and want a sanity check, send us the data flow — we run the conformance suites (Touchstone, Inferno) and have shipped both standards across 60+ integrations. ## Multi-state telehealth: the licensing routing problem (and what to build) URL: https://health.onix-systems.com/insights/multi-state-telehealth-licensing Engineering · 10 min · 2025-09-12 · Serhii Kholin, CEO Every telehealth platform that grows past one state hits the same wall — every state has different licensing rules, scope-of-practice limits, and e-prescribing requirements. Here's the routing architecture that survives all 50. Every telehealth platform that grows past one state hits the same wall. The MVP shipped in one state, the platform worked, you raised. Now you want to expand to five states, and your provider routing — which was a function that returned the same provider regardless of patient state — starts producing illegal visits. This article is the practical version of what most telehealth platforms eventually need: a multi-state licensing architecture that doesn't depend on heroics or spreadsheets. ### State lines are software boundaries A telehealth visit is regulated at the patient's state of presence — not the provider's state, not the patient's residence, not the company's HQ. If a patient is in Ohio at the moment of the visit, the visit must comply with Ohio's medical practice rules. The provider needs an Ohio license. E-prescribing must follow Ohio's PDMP rules. Scope-of-practice must match Ohio's NP or PA rules. None of this is the same as the patient's billing address. Every multi-state platform we've shipped routes visits at session-bind time based on patient state of presence — captured explicitly, not inferred from IP or billing. ### The three things state licensing actually controls #### Who can practice (license verification) Every state has a board of medicine (and separate boards for nursing, behavioral health, pharmacy, etc). Each board issues licenses with a status and expiration. License status changes — providers move states, take licenses inactive, fail license renewal. A platform that assumed a provider's Ohio license is still valid 18 months after onboarding is a platform that will eventually conduct an unlicensed visit. License verification is a recurring requirement, not a one-time check. #### What they can do (scope-of-practice) A nurse practitioner in California has independent practice authority. A nurse practitioner in Texas does not — they require physician supervision. Same license type, two states, different scope. Your platform's "who can prescribe what" logic needs to encode this. #### How they prescribe (state-level e-prescribing + PDMP) E-prescribing of controlled substances (EPCS) is federal-required, but state-level PDMP (prescription drug monitoring program) integrations vary widely. Some states require a PDMP check before every Schedule II prescription. Others before every controlled substance. Your e-prescribing flow needs to know which state's PDMP applies and integrate with it. ### The routing problem At visit-bind time — the moment a patient confirms a visit and the system assigns a provider — three pieces of state data converge: - Patient's state of presence (captured explicitly during intake) - Eligible providers' state licenses (must include patient's state) - Provider availability (calendar) intersected with state-eligible providers The output is a single provider assignment plus an audit log of why. The audit log is critical — if a board ever asks why a Texas patient was matched with a Florida provider, you need to show the licensing match in your routing decision. ### License verification — manual or automated There are state licensing board APIs. Few states publish them officially; most are scraped via partners (Nursys for nursing, AMA for physician verification, and CredentialMyDoc / similar for multi-discipline). Your options: - Manual verification at onboarding, manual re-verification quarterly. Cheap but error-prone. - Vendor (Verifiable, CertifyOS, similar) for automated continuous monitoring. Costs ~$15–40 per provider per month but handles status changes. - Self-built scraping of license boards. Possible but maintenance is expensive — boards change their sites. For platforms above ~50 providers, vendor-automated monitoring is the right call. The error mode (provider's license lapsed and you didn't catch it) is too costly otherwise. ### Compact licenses — IMLC, NLC, PSYPACT There are three big compacts: - IMLC (Interstate Medical Licensure Compact) — for physicians. Member states (40+) accept a streamlined application process, not a single license. - NLC (Nurse Licensure Compact) — for RNs and LPNs. ~40 states have full reciprocity. - PSYPACT — for psychologists. ~40 states. Compacts simplify the licensing application process, but they don't simplify your routing logic — providers still hold individual state licenses (just acquired faster). Your routing engine still needs to know which states each provider is licensed in. Compacts also have gaps. Controlled substance prescribing typically requires state-by-state DEA registration even within a compact. Behavioral health has its own compact (PSYPACT) separate from medical. ### What we build for multi-state platforms Architecture that survives 50-state expansion: - Provider state matrix — explicit record of which states each provider is licensed in, expiration dates, scope-of-practice tier - Visit routing engine — at bind time, filters available providers by patient state of presence, then by scope match, then by calendar availability - License monitoring — continuous (daily delta against state board data, via vendor) - Audit log — every routing decision logged with state, license version, and timestamp - Scope-of-practice rules engine — configurable per state, encodes what each license type can do ### Common failures #### Patient-state vs patient-residence assumption Patient's billing address is in Ohio. Patient is on vacation in Florida. The visit is regulated by Florida law. Platforms that route by billing state catch this only when there's a complaint. Capture state of presence explicitly during intake — every visit, every time. #### Stale license cache A provider's license expires. Your platform's cache says "valid until 2027" because it was checked once at onboarding. You schedule a visit. The visit happens. The board audits. You owe an explanation. License verification should refresh on at least a daily cadence in production. Monthly is too slow. #### Missing scope-of-practice rules NP in California can prescribe Schedule II independently. NP in Texas needs physician supervision for Schedule II. Same license type, different scope. If your platform doesn't encode this, your routing will produce illegal prescriptions in restrictive states. ### The minimum to build before you cross state #2 - Patient state of presence captured at visit start (not just at registration) - Provider state matrix table (one row per provider × state combo) - Visit binding logic that filters by state license match - Audit log of routing decisions - License expiration monitoring (manual at first, vendor by provider #50) Everything else (compact handling, scope-of-practice rules, PDMP integration) is build-as-needed when expanding to specific states. But the basics above are non-negotiable on the day you accept your second state. Multi-state telehealth is solvable. It's not a one-week task. Plan for 4–8 weeks of architecture work the first time you cross state lines — much cheaper than the audit that's coming if you don't. ## Remote patient monitoring without burning out caregivers URL: https://health.onix-systems.com/insights/rpm-alert-fatigue-design Engineering · 11 min · 2024-04-17 · Denis Sheremetov, CTO Alert fatigue kills RPM programs faster than any technical issue. Here's the framework we use to design alert systems that surface the right thing at the right time — and the metrics that tell you it's working. Every failed RPM rollout has the same diagnosis: alert fatigue. The platform technically works. The devices report data. The dashboards display vitals. The caregivers stopped looking at them three weeks ago because they were buried in alerts that mostly weren't actionable. Alert fatigue is a design problem, not a data problem. Here's the framework we use to design RPM alert systems that surface the right thing at the right time — and the metrics that tell you it's working before adoption collapses. ### What alert fatigue actually is Alert fatigue isn't "too many alerts." It's a specific cognitive phenomenon: when alerts predict reality poorly, humans learn to ignore them. Once a caregiver has dismissed 30 false positives in a row, the 31st alert — even if it's the real critical one — gets the same dismissive response. The mechanism is well-documented in aviation, ICU monitoring, and now in RPM. The fix is the same in all three contexts: alerts must predict reality well enough that humans trust them. ### Per-patient baselines, not population thresholds The default RPM alert design uses population thresholds: "BP > 140/90 → alert." This is wrong for almost everyone outside the population mean. A 78-year-old patient with chronic hypertension on three medications has a stable resting BP of 142/88. They have lived at that BP for five years. The population threshold fires every reading. The caregiver mutes the patient. The patient's BP spikes to 168/102 a week later — and the alert fires identically to the previous 30 false alerts. It's ignored. The fix: per-patient baselines learned over the first 4–6 weeks of monitoring. Alerts fire on deviations from the patient's individual normal, not from population norms. Same patient, BP 168/102 = deviation from their 142/88 normal = real alert. BP 144/90 = within their normal range = no alert. This requires more data plumbing but the alert quality improvement is dramatic. Override rates in our deployments drop from 50–70% (population thresholds) to <10% (per-patient baselines) within 90 days. ### The four-layer alert hierarchy Not all alerts are equal. We use a four-layer hierarchy: - Critical — call now. Maximum 2–3 per caregiver per week. Above-baseline deviation + sustained + worsening trend. - Concern — review within 4 hours. Deviation but not sustained; may resolve on its own. ~5–10 per caregiver per week. - Trend — review at shift change. Subtle pattern change; informational. Shows up in a dashboard, not a notification. - Trace — data only, no caregiver action. Goes into the audit log and clinical history. The hierarchy isn't visual — it determines the delivery channel. Critical alerts pop. Concern alerts list. Trends sit on a dashboard. Traces are searchable. A patient triggering a trace 50 times a week makes no caregiver noise; a patient triggering one critical alert is a phone call. ### Override-rate as a feedback signal When a caregiver dismisses an alert without action, that's a data point. Aggregated, the override rate per alert type is the most important signal in your RPM platform. We instrument every dismissal with: timestamp, caregiver, alert type, patient, reason (structured dropdown plus optional free text). The override rate dashboard shows: - Override rate trending up over weeks → likely alerts are getting noisier (drift, threshold drift, population change). Investigate. - Override rate spiking for one alert type → that alert type's threshold is wrong. Tune it. - Override rate spiking for one caregiver → either training gap or workflow issue specific to that caregiver. - Override rate spiking for one patient → that patient's baseline needs recalibration. Without override-rate instrumentation, you have no feedback signal. You'll find out about alert fatigue when adoption craters — six months too late. ### Shift-aware design The same alert at 3pm and 3am should behave differently. At 3pm, a "concern" alert can wait until the caregiver finishes their current task. At 3am, there's no current task — the caregiver is asleep. A concern alert at 3am should not wake them, but a critical alert should. Shift-aware alert routing means encoding caregiver schedules (day shift, night shift, on-call rotation) and adjusting delivery rules: - During scheduled shift — standard delivery - Off-shift / asleep — only criticals, with explicit acknowledgment requirement - On-call — criticals + escalation chain if no acknowledgment in 5 minutes - Handoff window — re-deliver outstanding concerns to incoming shift This sounds elaborate. It's the difference between "RPM that worked for 6 months" and "RPM that's still working at year 3." ### Soft-mute as a feature Dismissing an alert as "I saw it, don't show me again for 4 hours" is a useful feature. Dismissing it as "this alert type is wrong and I'm muting it forever" is not — but caregivers will do the latter if you don't give them the former. We always ship: - Snooze (dismiss for X hours) — legitimate response to "I'm dealing with this" - Acknowledge with reason — dismissal with structured input - Mute alert type for this patient — requires reason; goes to clinical review We never ship a permanent dismiss button. Permanent dismissal happens via clinical review with an audit trail. > Alert fatigue isn't 'too many alerts.' It's when alerts predict reality poorly enough that humans learn to ignore them — including the one that's right. ### Measuring success Three metrics tell you whether your RPM alert system is working. If any of them moves wrong, the system is broken regardless of what the technical dashboards say. - Override rate trend — should be flat or declining. Rising = something is changing in your population or your thresholds. - Critical-alert response time — should be under 30 minutes for true criticals. If it's longer, caregivers don't trust the criticals (alert fatigue). - Caregiver NPS on the alerting system — measured quarterly. Below 5 (out of 10) = adoption is at risk. We've shipped RPM with all three metrics in green for 18+ months. We've also rescued RPM platforms where two of three were red — and the fix was almost always alert hierarchy and per-patient baselines, not better devices. ### The minimum design before launch - Per-patient baselines (4–6 weeks of data before alerts fire) - Four-layer alert hierarchy with distinct delivery channels - Override-rate instrumentation with weekly review - Shift-aware delivery rules - Snooze + structured-reason acknowledgment Without these, you're shipping a dashboard, not a monitoring system. The dashboard will be ignored within 90 days. With these, the system survives turnover, scope changes, and the eventual reality that one of your alert types was wrong from day one. Override-rate instrumentation tells you which one before the program collapses. ## CDS Hooks: shipping clinical decision support clinicians actually use URL: https://health.onix-systems.com/insights/cds-hooks-clinician-adoption Engineering · 9 min · 2023-11-08 · Serhii Kholin, CEO CDS Hooks is the standard for delivering decision support inside the EHR — but standards don't drive adoption. Here's what separates CDS that gets accepted from CDS that gets disabled in week two. CDS Hooks is HL7's standard for embedding clinical decision support in EHR workflow. It's been around since 2018, it's well-supported in Epic and Cerner and Athena, and it's the right primitive for shipping recommendations inside the tools clinicians already use. It also has a well-earned reputation for going unused. We've audited CDS deployments where the technical integration was textbook — and where the clinical adoption was zero within two weeks. The standard isn't the problem. The deployment design is. ### What CDS Hooks gives you CDS Hooks defines "hooks" — workflow events in the EHR — and the contract between EHR and CDS service. Common hooks: - patient-view — fires when a clinician opens a patient chart - order-select — fires when a clinician begins ordering (lab, medication, imaging) - order-sign — fires when a clinician is about to sign an order - encounter-start, encounter-discharge — workflow milestones The CDS service receives the workflow context (patient, encounter, current orders, draft order), returns "cards" — small structured recommendations that the EHR renders inside the clinician's UI. Cards can be informational, suggest alternative orders, or link to external apps (via SMART on FHIR). The protocol is good. It standardizes integration with Epic, Cerner, Athenahealth, eClinicalWorks, NextGen — meaning your CDS service can ship to multiple EHRs from a single codebase. That's the half of the problem CDS Hooks solves. ### Three adoption-killing design mistakes The other half — adoption — has the same failure modes regardless of which EHR. Three patterns kill adoption faster than anything else. #### Firing too often A CDS card that fires on every patient-view is a card clinicians will mentally tune out within a week. The "wolf-cry" problem from alert design applies to CDS Hooks too. Rule of thumb: a card should fire on no more than 5–10% of relevant workflow events. If it's firing on every patient-view, your filter logic is too loose. Narrow the condition. #### Firing without evidence "Consider checking ferritin levels" is a worse card than "Patient's last hemoglobin was 9.2 (Aug 15) — consider checking ferritin." The second card shows the data that justifies the suggestion. The first leaves the clinician wondering why this is appearing now. CDS Hooks cards have a "source" and "indicator" structure for exactly this. Use it. Show the data inline. The clinician's decision is faster (and more likely to accept) when the evidence is visible. #### Firing at the wrong workflow step A medication interaction warning that fires at patient-view (when the clinician hasn't yet decided to prescribe) is annoying. The same warning at order-select (when the prescription is being composed) is useful. Same content, wrong hook, opposite adoption outcome. Match the hook to the moment the decision is being made. ### The trust-building deployment #### Shadow mode first Run the CDS service for 2–4 weeks in shadow mode — fire the same cards, but don't show them to clinicians. Log what the cards would have suggested, and (separately) what the clinicians actually decided. Shadow mode is your sanity check. If the cards would have fired 12 times per visit on average, your filters are wrong. If 80% of cards would have suggested the same thing the clinician already did, the value is low. Iterate before showing anything to users. #### Expert validation panel Before exposing cards to general clinical staff, run them past a panel of 3–5 senior clinicians representative of the user base. They'll catch contextual issues that shadow data won't — "this card is correct but the wording suggests overruling the diagnostic process, and our doctors will hate it." Iterate wording, not just thresholds. #### Phased rollout by specialty Roll out CDS to one specialty at a time, not the whole organization. Adoption signals from each phase inform the next: - If primary care accepts a card at 60% but cardiology accepts the same card at 15%, the card's threshold or context is wrong for cardiology. - If a card has consistently high override rates with consistently consistent reasons, you have data to retire or reword that card. ### Designing the suggestion Specific design rules we apply per card: - Show the evidence inline (the lab value, the prior note, the drug-drug pair) - Make dismissal one click (CDS Hooks supports "dismiss with reason" — use it) - Provide a single, specific suggestion ("order ferritin" not "consider further workup") - Include a link to deeper context for clinicians who want it (don't dump the full citation into the card) - Cap the card body at 2–3 sentences Clinicians scan, not read. Cards are scanned. If they don't get the gist in 2 seconds, they're dismissed regardless of clinical merit. ### When NOT to use CDS Hooks CDS Hooks fires on workflow events. It's not the right tool for: - Real-time monitoring of physiological data (use streaming + alerts, not workflow hooks) - SaMD-class recommendations that require regulatory clearance (CDS Hooks cards are typically non-device CDS; SaMD has different deployment and validation requirements) - Background risk scoring that updates daily (compute it overnight, deliver via dashboard, not workflow card) If your CDS needs to fire outside the moment a clinician is making a decision, CDS Hooks is the wrong primitive. Use it for the moment, not for the ambient signal. ### Measuring CDS that works Three metrics. Acceptance rate is the leading indicator: - Acceptance rate (not "fire rate") — % of fired cards where the clinician accepted the recommendation. Above 50% is excellent; below 20% means the card is firing at the wrong threshold or context. - Override-with-reason captures — structured input on dismissals. Cluster reasons monthly; patterns tell you which cards to retire or reword. - Clinical outcome correlation — does accepting the recommendation correlate with better outcomes? Hardest to measure but the only metric that matters long-term. A CDS that fires 1,000 times per month at 80% acceptance is delivering value. One that fires 10,000 times at 15% acceptance is consuming attention without delivering anything. Both look identical in basic "cards delivered" metrics. Acceptance separates them. ### Closing CDS Hooks is a well-designed protocol. It will not save you from a poorly-designed deployment. The standard solves integration; adoption is solved by shadow mode, by per-card iteration with senior clinicians, by per-specialty rollout, and by ruthless instrumentation of acceptance. The teams shipping CDS Hooks at >50% acceptance treat each card like a product, not a feature. The teams shipping at <15% treat it like a checkbox. ## Custom CRM vs Salesforce vs HubSpot for Healthcare Insurance: An Honest TCO Comparison URL: https://health.onix-systems.com/insights/custom-crm-vs-salesforce-vs-hubspot-tco Strategy · 14 min · 2025-03-22 · Valerii Checha, Head of Business Unit Every healthcare insurance CFO asks the same question — did we consider Salesforce? Did we consider HubSpot? Here's what the math actually looks like for a mid-size insurer over five years. Every healthcare insurance CFO asks the same question on the same call: "Did we consider Salesforce? Did we consider HubSpot?" The honest answer is yes — and the honest result, for most mid-size insurers, is that the comparison is not what the vendor websites suggest. We've sat across the table from CFOs running this analysis a half-dozen times. Here's what the math actually looks like. This is the long version. If you want the short version: by Year 2, a custom CRM layer typically costs ~30% less than the equivalent Salesforce setup for a 150-employee healthcare insurer. By Year 5, the gap is closer to 50%. Below, we walk through why — and where each platform actually makes sense. ### Why this comparison is harder than it looks for insurers #### What "TCO" actually includes Most "Salesforce vs HubSpot" comparisons stop at license cost. That's the smallest piece of total cost of ownership for an operations-heavy insurance business. TCO actually includes: - Licenses (the line item everyone quotes) - Implementation (3–6 months of consulting partners, $1.5–3K per day) - Customization (every policy lifecycle, agent commission, broker workflow needs custom dev) - Integrations with the systems you already own (policy management, claims, billing, broker portal) - Internal operations time (admins, sysadmins, the "report person", training for every new hire) - Switching costs at year 3 when the platform doesn't fit anymore When you compare only on license cost, you're comparing the bumper sticker, not the car. #### Why mid-size insurers (50–300 employees) sit in the worst pricing tier of off-the-shelf CRMs This is the part nobody warned you about. Off-the-shelf CRM pricing is built around two segments: small business (under 50 seats, big discounts, limited features) and enterprise (1,000+ seats, deep discounts, full features). Mid-size — 50 to 300 employees, agent-heavy — sits in the worst possible spot. You're too big for the small-business pricing tier, and too small for enterprise negotiation leverage. For a 150-employee insurer with 70 agents, 30 internal users, and 50 broker users, both Salesforce and HubSpot want you in their Enterprise tier. You'll pay full sticker per seat. That's the trap. ### Salesforce for healthcare insurance — strengths and blind spots #### Where Salesforce wins Some things Salesforce genuinely does well, and you shouldn't dismiss them: enterprise-grade audit trails (auditors love it — the Field History Tracking + Shield combination is unmatched), the AppExchange ecosystem (need a broker portal? there's probably one for sale), and HIPAA-eligibility once you're on the enterprise edition with Shield. For an insurer with a heavy enterprise B2B sales motion (selling group plans to large employers), Salesforce's pipeline tooling is mature and the integrations are battle-tested. #### Where it breaks down for healthcare insurance Three places, consistently. Per-seat pricing on agent-heavy teams: an agent who logs in four times a day to update a renewal note costs the same as your sales VP. The math gets ugly fast. Policy lifecycle gaps: Salesforce's default object model — Accounts, Contacts, Opportunities — fits B2B sales beautifully. It does not fit insurance policy lifecycle (quote → bind → renew → claim → loss-run → cancellation). You can customize, but every workflow becomes an Apex + Flow project. Admin overhead: a 150-person Salesforce org typically needs 1.5–2 FTE of Salesforce admin/dev time to keep customization, integrations, and user provisioning running. That's $150–250K/yr in headcount alone, on top of the platform cost. #### Real cost ranges for a 150-employee insurer - Sales Cloud Enterprise: $165/user/month × 150 users = $297K/yr - Service Cloud Professional add-on for 70 agents: $50/agent/month = $42K/yr - Shield (audit logging, encryption) for HIPAA: ~$30K/yr - Implementation (initial 6 months): $150–400K one-time - Ongoing customization retainer (Apex/LWC partner): $80–150K/yr - Internal admin headcount: 1.5 FTE = $150–220K/yr Year 1 lands at roughly $750K–$1.1M. Years 2–5 settle to $550–750K/yr, with annual license creep of 5–7% built into most enterprise contracts. ### HubSpot for healthcare insurance — strengths and blind spots #### Where HubSpot wins HubSpot is the best modern CRM for marketing-led operations. If your insurer is direct-to-consumer (D2C health plans, supplemental insurance, brokerage marketing), HubSpot's content and marketing automation tools are genuinely class-leading. Setup is faster than Salesforce. The UX is modern. Reporting is reasonable out of the box. For insurers under 50 employees with a marketing-heavy go-to-market, HubSpot is often the right call. #### Where it breaks down for healthcare insurance Policy and agent workflows have no native object. HubSpot's data model is built around Contacts, Companies, Deals — same B2B sales bias as Salesforce. Building policy lifecycle on top of Deals doesn't work cleanly. You end up with custom objects that don't integrate with HubSpot's automation primitives. Compliance configurability is limited. HIPAA-eligibility requires Operations Hub Enterprise plus a third-party partner add-on (or a HIPAA-vault middleware layer). It's possible but expensive, and the audit-trail tooling is less mature than Salesforce Shield. Hub upsell math. To get the full feature set most insurers need, you're buying Marketing Hub Enterprise + Sales Hub Enterprise + Service Hub Enterprise + Operations Hub Enterprise. The bundled "CRM Suite Enterprise" is $5K/month base, then per-user costs on top. The "we'll grow into it" pricing trap is real. #### Real cost ranges for a 150-employee insurer - CRM Suite Enterprise: $5K/month base = $60K/yr - Per-user pricing (70 agents at $90/user/month): $76K/yr - Implementation (3 months): $50–150K one-time - HIPAA partner add-on: $15–25K/yr - Custom object/workflow customization: $40–80K/yr - Internal admin: 1 FTE = $120–160K/yr Year 1 lands at $360–550K. Years 2–5 settle to $310–440K/yr. ### Custom CRM layer — what it is and isn't #### It's not "build everything from scratch" When CFOs hear "custom CRM" they reasonably think two-year project, $2M budget, white whale that ships late and breaks. That's how custom CRM USED to be built. It's not what we mean by "custom layer." #### It integrates with what you already have A modern custom CRM layer sits on top of the systems that already work — your policy management system, your claims platform, your billing engine, your broker portal. It's a unified workflow surface, not a rebuild. Concretely: a thin Postgres database, a TypeScript or Python API, integrations into your existing systems via REST/SOAP/JDBC, and a UI built against the actual workflows your team uses every day. #### It only covers workflows your team actually uses The fundamental cost asymmetry: SaaS CRMs charge for every feature regardless of whether you use them. A custom layer covers only what your team uses — typically 12–25% of what's in Sales Cloud or HubSpot Hub bundles. We've never built a CRM with all of Sales Cloud's features. We've built CRMs that do every single thing the customer team needs, 100% of the time, with no workarounds. ### Side-by-side TCO comparison over 5 years #### Year 1 (build/setup heavy for custom, license-heavy for SaaS) - Salesforce 150-employee total Y1: $750–1,100K - HubSpot 150-employee total Y1: $360–550K - Custom CRM layer total Y1: $300–500K (build + first year of internal admin) #### Years 2–3 (where custom starts winning — ~30% saving) The shape of the math changes dramatically once the build phase is over. Custom CRM has a maintenance retainer (typically $40–80K/yr) plus a part-time internal admin. SaaS keeps charging full freight. - Salesforce Y2–3: $550–750K/yr (with 5–7% annual creep) - HubSpot Y2–3: $310–440K/yr (with creep + hub upsell pressure) - Custom Y2–3: $80–150K/yr (maintenance + small internal admin) That's roughly a 30% saving vs HubSpot and 60% vs Salesforce in steady state — but Year 1 amortization pulls the effective rate lower in the first two years. #### Years 4–5 (break-even and compounding savings — ~50%) The compounding effect kicks in. SaaS license creep keeps adding 5–7% per year. Custom maintenance stays roughly flat. By Year 5, the gap widens noticeably. - Salesforce 5-year total: $2.8–4.0M - HubSpot 5-year total: $1.6–2.3M - Custom 5-year total: $500–800K That's roughly 50–60% savings against Salesforce, 40–50% against HubSpot over the 5-year horizon. And critically: the custom layer is YOUR asset. You own the data model, the code, the integrations. #### Comparison table — assumptions stated Assumptions used above (state these explicitly when running your own numbers): - 150 employees total: 70 agents, 30 internal sales/ops, 50 broker users - HIPAA required (PHI handling) - Integration with 3 existing systems (policy management, claims, billing) - US-based, mid-market insurance segment - 5–7% annual SaaS license creep (industry typical) - Internal admin/dev time priced at $100–160K/yr fully loaded ### When each option actually makes sense #### Stay on Salesforce if… You already have an enterprise license across the parent organization (you're "consuming" capacity not paying incremental), your sales motion is enterprise B2B with large employer groups, you have a mature Salesforce admin team in-house, and your compliance team specifically requires Shield's audit-trail features. #### Stay on HubSpot if… Your insurance product is direct-to-consumer (supplemental, accident, voluntary), marketing-led acquisition dominates your funnel, you have fewer than 50 agents, and you're comfortable wrapping HubSpot with HIPAA middleware. #### Switch to custom layer if… - License utilization is below 60% across your existing CRM seats (audit it monthly for 3 months) - Your team has built shadow spreadsheets for at least 3 of: policy renewals, agent commission, broker payouts, claim escalations - Your annual customization / integration retainer with your existing CRM exceeds $100K - You have 2+ FTE on internal Salesforce admin/dev for under 300 seats If two or more of those signals are true, custom starts winning fast. ### How to run a 2-week CRM cost & fit audit before you commit #### What to inventory Two weeks is enough for a real audit. Here's what to inventory: - License count vs daily-active-user count (over 30 days, per role) - Feature usage per module (your CRM admin can pull this) - Manual workarounds (interview team leads — every shadow spreadsheet is data) - Integrations: cost (annual), breakage rate (per quarter), maintenance hours - Admin/dev FTE allocation - Reports the team rebuilds in Excel every month (these are workflow gaps) #### The four metrics that decide the call - License utilization rate — % of seats actively used in last 30 days. Below 60% = strong move signal. - Workflow coverage — % of business processes that need workarounds. Above 25% = strong move signal. - Admin time ratio — FTE per 100 users. Above 1.0 for <300 seats = strong move signal. - 3-year trend in CRM cost vs revenue — CRM growing faster than revenue = strong move signal. Three of four says you should switch. Four of four says you should have switched 18 months ago. > The vendor-driven framing of 'custom CRM is risky, SaaS is safe' is increasingly inverted for mid-size healthcare insurers — where the SaaS economics work against your operating model and the 'safe' choice is to fight the platform every quarter for the next decade. ### The honest summary Salesforce, HubSpot, and custom layers all have legitimate use cases. The vendor-driven framing of "custom CRM is risky, SaaS is safe" is increasingly inverted for mid-size healthcare insurers. If you're running a healthcare insurance org between 50 and 300 employees, the answer is probably custom layer — with a careful audit before commitment, not a year of analysis paralysis. Two weeks of audit. Six months of build. Two-year payback. We've done this. Read the numbers from a real engagement on the Custom CRM for Health Insurance case study, or book a free 2-week CRM Cost & Fit Audit. ## Why Mid-Size Healthcare Insurance Companies Overpay for Salesforce by 2–3× URL: https://health.onix-systems.com/insights/why-healthcare-insurance-overpays-salesforce Strategy · 9 min · 2024-08-05 · Valerii Checha, Head of Business Unit Every healthcare insurance CFO has had this conversation: the Salesforce invoice lands, it's up 8% over last year, and the renewal includes an Enterprise Tier upgrade you weren't warned about. Here's how the overpay actually happens — and how to spot it in your own bill. Every healthcare insurance CFO has had this conversation: the Salesforce invoice lands, it's up 8% over last year, and the renewal includes an "Enterprise Tier upgrade" because you crossed a seat threshold. You weren't told about the threshold. The migration costs more than the upgrade. You're trapped. This isn't a Salesforce-is-bad article. Salesforce is a legitimately powerful platform. It's a "the pricing model wasn't designed for your business" article. Mid-size insurance ops — 50 to 300 employees — overpay for Salesforce by a factor of two or three. Here's why, and how to spot it in your own bill. ### The pricing trap nobody warned you about #### How per-seat licensing punishes agent-heavy ops Salesforce pricing assumes a "knowledge worker" model: most users log in daily, use 60–70% of the features, and add direct revenue value per seat. That model fits sales orgs and account management teams beautifully. It does not fit insurance agents. An agent might log in three to five times a week — to check a renewal, update a policy note, log a broker call. They use maybe 8–15% of the features. They cost the same per seat as your VP of Sales. For a 150-employee insurer with 70 agents, you're paying $165/agent/month for someone who uses Salesforce like email — occasionally, narrowly, transactionally. That's $138K/yr for tooling that's worth maybe $30K/yr in actual value to the business. #### The "we'll grow into it" promise that rarely materializes The promise during the sales cycle: "You're getting Enterprise Edition, you have headroom, you'll use Sales Cloud + Service Cloud + Marketing Cloud + the AppExchange ecosystem as you grow." The reality 24 months later: you're using Sales Cloud for accounts, a fraction of Service Cloud for support tickets, none of Marketing Cloud (which you bought because you "might"), and three AppExchange apps that don't talk to each other. You bought a complete platform and use it as a glorified database. ### The 4 places overspend actually shows up #### Unused licenses (typical: 40–60% of seats inactive monthly) Pull your license utilization report. Filter for "users who haven't logged in in the last 30 days." For most mid-size insurance Salesforce orgs we've audited, that number is 35–55% of total seats. Inactive seats aren't a Salesforce billing problem — you keep paying for them. They're an operations signal: you bought seats for roles that didn't materialize, or for people who quietly stopped using the system. #### Unused features (you bought Service Cloud, you use 12% of it) Each Salesforce "Cloud" includes hundreds of features. Most insurance ops genuinely use a slim subset: - Sales Cloud — Accounts, Contacts, Opportunities, Activities, basic Reports. Maybe 15–25% of features actually touched. - Service Cloud — Cases, basic Knowledge, Omni-Channel. Maybe 12–20% touched. - Marketing Cloud — typically untouched in insurance ops where marketing runs on a separate tool. You paid for the full bundle. You use a fraction. This isn't your fault — feature bundling is the SaaS pricing strategy. But it's overspend. #### Customization bills that compound Every workflow your team needs that doesn't fit the default Salesforce object model needs custom development. Apex, Flow, LWC. Insurance has a LOT of workflows that don't fit defaults: policy lifecycle, agent commission, broker payouts, loss-run reporting, group plan administration. Your customization retainer with a Salesforce partner is probably $80–150K/year. After three years, that's a quarter-million dollars in customization compounding on top of license costs. And every Salesforce major release means re-validating your customizations. #### Admin headcount required to keep it running A typical 150-employee Salesforce org needs 1.5–2 FTE of internal Salesforce admin/dev time. That's $150–250K/year fully loaded. You're paying for a person whose entire job is making Salesforce do what your team needs. When the admin leaves (and they leave often — Salesforce admins are in high demand), you spend 6–12 months ramping a replacement. Knowledge transfer is incomplete. Things break. ### Why "consolidation" promises don't hold up in insurance ops #### Policy, agent, and client data don't fit the default object model Salesforce's default object model is built around B2B enterprise sales: Account (company) → Contact (person) → Opportunity (deal). Insurance ops have a different shape: Client (insured) → Policies (multiple per client, with renewals) → Agents (managing relationships across many clients) → Brokers (third-party distribution) → Claims (lifecycle events on policies). You CAN model this in Salesforce. You just end up with custom objects that don't natively integrate with the standard automation, reporting, and AppExchange ecosystem you were sold on. The "consolidation" benefit erodes. #### The integrations you still pay for separately Insurance ops typically need integrations into: policy management systems (Guidewire, Duck Creek, Insurity, or in-house), claims platforms, billing engines, broker portals, document management. Salesforce doesn't replace any of these — it sits alongside them. Each integration is a separate cost. Maintained separately. With its own breakage cycle. The "single source of truth" promise becomes "an additional source of truth that integrates with all the others, expensively." ### The three workarounds that signal you're overpaying #### Shadow spreadsheets for agent commission tracking If your sales operations team maintains an Excel file for agent commission calculations — and updates it monthly by exporting from Salesforce, transforming in Excel, and emailing it around — you have a workaround. That workaround is a workflow your $400K/year CRM doesn't actually cover. #### Manual policy renewal reminders despite "automation" If anyone on your team has a calendar reminder titled "Check Q4 renewals due in Salesforce," your renewal automation isn't working. You're paying for automation features and supplementing them with human attention. #### Reporting exports rebuilt in Excel every month If the monthly board pack starts with someone exporting CSVs from Salesforce and rebuilding them in Excel because the Salesforce reports don't quite work — that's reporting overspend. You bought reporting tools. You're using Excel. One workaround is "we haven't gotten around to building that." Three or more workarounds is "the platform doesn't fit the work." ### What the math looks like for a 150-employee insurer #### Real numbers - License cost: $297K/yr (Sales Cloud Enterprise × 150 users) - Service Cloud add-on: $42K/yr (70 agents) - Shield (HIPAA audit): $30K/yr - Customization retainer (external partner): $100K/yr - Internal admin: 1.5 FTE = $200K/yr - Total: ~$670K/year For comparison, the underlying business value the team actually uses — the activities they couldn't do without — is probably worth $200–300K/year of CRM functionality. #### What 30% savings would fund instead A 30% reduction is roughly $200K/year. That's: - Two additional product managers focused on broker experience improvements - A real data analytics function for actuarial/underwriting - Building the agent mobile app you've talked about for three years - A 2-year custom CRM build that pays for itself in year two Or, prosaically: it stays in operating income. ### What to do this quarter, not next year #### Run a license utilization audit This week. Pull the Salesforce "User Last Login" report. Filter for the last 30 days. Count the dormant seats. Multiply by your per-seat cost. That number is the easiest cost to cut and the hardest to justify keeping. #### Map the workarounds — that's your real CRM Take a half-day with your sales and ops leads. List every spreadsheet, every manual process, every "we just send an email to do X" workflow. Each one is a feature your CRM doesn't cover. Together they describe your actual operational model — not the model the vendor sold you. #### Decide: optimize, layer, or replace Three real paths: - Optimize — shed unused seats, kill unused modules, renegotiate at renewal. Saves 15–25% with low risk. - Layer — build a custom workflow layer on top of the parts of Salesforce that genuinely work. Saves 30–50% over 3 years. - Replace — replace Salesforce with a custom CRM stack. Saves 50–70% over 5 years; highest implementation risk. We've done all three with insurers. None is universally right. But almost no one stays on full-stack Salesforce after they actually run the math. See how we did a TCO comparison for an insurer your size — read the pillar comparison or the proof-point case study. ## How We Cut CRM Costs ~30% in Year Two — A Healthcare Insurer Case Study URL: https://health.onix-systems.com/insights/how-we-cut-crm-costs-30-percent-case Strategy · 12 min · 2026-02-11 · Valerii Checha, Head of Business Unit The proof point behind the pillar TCO comparison. A real engagement: a California health-insurance company, custom CRM layer delivered in 6 months, Year 2 came in roughly 30% cheaper. Forward this to your CFO. This case study is the proof point behind the pillar article on Custom CRM vs Salesforce vs HubSpot. It's a real engagement: a California health-insurance company that came to us in late 2022 with a CRM bill they couldn't justify and ops workflows they couldn't fix from inside Salesforce. We delivered a custom CRM layer in 6 months. Year 2 came in roughly 30% cheaper than Year 0. Year 3 is on track for ~50%. The numbers below are anonymized at the request of the client. The methodology is exact. ### The starting point — fragmented ops, growing CRM bill #### Company profile Mid-size US health-insurance company. California-based. Roughly 150 total employees: 65 licensed insurance agents, 28 internal sales/ops staff, 12 management, 45 broker users. Two main product lines: individual Medicare supplement plans and small-group employer plans. Annual CRM-related spend approaching $720K when we engaged. #### The stack before Before our engagement, the operational stack looked like this: - Sales Cloud Enterprise for the entire 150-user population - Service Cloud Professional add-on for agents handling client servicing - A Shield add-on for HIPAA audit trail - Two AppExchange apps — a quote generator and a document e-signature integration - An external Salesforce partner on a $9K/month customization retainer - 1.7 FTE internal Salesforce admin/developer time Per-seat costs: $165/user/month on Sales Cloud Enterprise. Service Cloud add-on: $50/agent/month for 65 agents. Shield: $30K/year. Implementation legacy debt: still amortizing $180K spent in 2020. #### What the CFO was actually worried about The CFO laid out the brief in the first call. It wasn't "I want to leave Salesforce." It was three concerns: - The Salesforce bill had grown 22% over two years while revenue grew 11% - The internal Salesforce admin had left; the replacement took 7 months to hire and is still ramping - The board had asked specifically how much of the Salesforce spend translated to revenue impact, and nobody could answer The brief: figure out where the money is going, what it's worth, and what the alternatives look like. ### What we found in the audit We ran a 2-week audit. Three things came out of it. #### License utilization (% of seats actively used) Of 150 paid seats, 87 were active in any given 30-day window. 58% utilization. The dormant 63 seats cost $125K/year in licenses alone. Many were users from a 2021 acquisition who'd been provisioned and never deprovisioned. Some were agents who'd quit and whose seats were still active because the admin process to deactivate involved a ServiceNow ticket and approval chain. #### Feature utilization (which modules sat dormant) We pulled Salesforce feature usage reports across the prior 90 days. The breakdown: - Accounts, Contacts, Activities, Tasks — heavy use (90%+ of users in last 30 days) - Opportunities — moderate use (40% of users); most policies don't move through Opportunities cleanly - Cases (Service Cloud) — heavy use by agents (85%) - Knowledge — 8%; no one builds or uses the knowledge base - Marketing Cloud — 0%; paid for but disconnected - Pardot — 0%; paid for but disconnected - Reporting features — ~15%; the rest used Excel exports Two full Clouds paid for and untouched. #### The hidden cost: ops hours spent on workarounds The audit interview surfaced workarounds: - A senior ops manager spent 4 hours/week maintaining the agent commission spreadsheet — exporting from Salesforce, applying commission rules in Excel, emailing payouts to finance - Renewal tracking: a calendar reminder per agent for "check Q1 renewals due" — manual, missed deadlines - Loss-run reports: rebuilt monthly in Excel from Salesforce CSV exports because the Salesforce reports didn't match how underwriting needed the data - Broker portal: a separate system entirely; broker payouts reconciled by hand against Salesforce We estimated ~22 person-hours/week across the ops team spent on workarounds. At fully loaded rates, that's roughly $115K/year in operational labor that Salesforce was supposed to eliminate. #### The three workflows that mattered Out of dozens of workflows, three drove ~80% of the operational pain: - Policy lifecycle (quote → bind → renew → cancel) — didn't map to Salesforce Opportunities cleanly - Agent management (productivity tracking, commission, license verification) — entirely in Excel - Client servicing (renewal reminders, plan changes, claim escalations) — partially in Cases, partially in inbox These three were the entire reason ops felt the platform didn't fit. Fix these three and most of the workarounds disappear. ### The decision — why "custom layer" beat "replace platform" #### Migration risk vs build risk Replacing Salesforce entirely was on the table. We didn't recommend it. Two reasons: First, migration risk. Three years of customer history, audit trails, and integration touch-points lived in Salesforce. Migrating all of that to a new platform is a 12–18 month project with a real risk of data loss and operational disruption. Second, the parts of Salesforce that worked, worked. Accounts/Contacts/Activities, Cases, Shield audit trail — these were genuinely useful and the ops team trusted them. The right call: keep the parts of Salesforce that worked. Build a custom layer for the three workflows that didn't fit. Deprecate the Clouds and seats that weren't being used. #### Timeline to value A pure-replacement project would have delivered nothing for 12+ months. The custom-layer approach delivered value in 6 months: by month 3 the policy lifecycle was running on the new layer; by month 6 the agent management and client servicing flows had migrated. #### What we kept, what we replaced, what we wrapped - Kept — Sales Cloud for Accounts, Contacts, Activities. Shield for audit trail. Service Cloud Cases for support tickets. - Replaced — Marketing Cloud (deprecated, replaced with Mailchimp at 1/20th the cost). Pardot (deprecated). The customization retainer (in-housed via the custom layer). - Wrapped — Opportunities (we built our own Policy object with proper lifecycle states, sitting alongside SF's Opportunities). Cases (we built agent-facing workflows that surfaced Cases without requiring agents to learn Service Cloud UI). ### What we built #### Centralized data model for client, policy, agent A Postgres database with three first-class objects: Client (insured person or company), Policy (with lifecycle state machine: quote → bound → active → renewing → cancelled), and Agent (with license verification, geographic territory, commission rules). This data model sat alongside Salesforce, not in front of it. Salesforce remained the system of record for Accounts and Contacts. The custom layer became the system of record for Policies and Agents. #### Automated lifecycle workflows (renewals, onboarding, commission) Concrete workflows we automated: - Policy renewal — 90-day, 60-day, 30-day reminders to agents with one-click renewal flow - Onboarding — new client → agent assignment → license verification → underwriting question packet → policy bind - Commission — monthly calculation from policy data, with rule engine for tiered commission structures - Broker payouts — monthly reconciliation against bound policies, with audit trail All of these had been manual or partially-manual in Salesforce. After 6 months, they ran themselves. #### Integrations with existing claims/billing/portal systems The custom layer integrated with three external systems: the claims platform (read-only sync of claim status), the billing engine (write claim adjustments, read payment status), and the broker portal (bidirectional sync of broker activity and payouts). Integration patterns: REST for claims, SOAP for billing (vendor legacy), event-driven webhook for the broker portal. We built a small middleware layer to normalize the three. #### What we deliberately did NOT build Worth naming what we didn't build, because that's where SaaS bundling math fails: - A full marketing automation tool — Mailchimp covers it - A separate analytics warehouse — existing data warehouse picked up the data - A document management system — kept the existing one - A general-purpose ticketing system — Salesforce Cases remained the system of record Each of these would have added $50–150K/year in license cost or build cost. None were needed. ### The numbers #### Year 1 — investment phase Year 1 was a net spend year — partly amortizing the previous Salesforce contract while standing up the new layer: - Salesforce reduced footprint — $310K (vs $497K prior year, after Marketing Cloud and unused seats deprecated) - Custom build (one-time) — $185K (6-month engagement, fixed-price) - Custom layer hosting + ongoing — $35K - Internal admin time — 0.8 FTE = $110K (down from 1.7 FTE) - Year 1 total — ~$640K (vs prior baseline of ~$720K; already 11% lower in Year 1) #### Year 2 — ~30% CRM cost reduction (breakdown by category) - Salesforce footprint — $245K (further seat reduction + renegotiated at renewal) - Custom layer maintenance — $55K - Internal admin — 0.5 FTE = $70K - Year 2 total — ~$370K, a 48% reduction vs prior baseline ($720K), or roughly 30% reduction year-over-year after Y1 amortization smoothing The 30% figure in the article title is the apples-to-apples Year 2 number after smoothing for Year 1's one-time build cost. The raw Year 2 vs Year 0 number is closer to 48%. #### Year 3 projection — ~50% reduction Year 3 (running now) is on track for $360K total — driven primarily by further Salesforce seat reduction as more workflows migrate to the custom layer. Projected total reduction vs Year 0: 50%. #### Year 4 — break-even on total program cost Year 4 is the break-even year on the cumulative program cost, including the one-time Year 1 build investment. After Year 4, the program is net cost-positive every year forward. #### Soft wins (agent NPS, time-to-quote, fewer support tickets) Beyond the dollar numbers, three operational wins: - Agent NPS on internal tooling went from 4.1 to 7.8 (10-point scale, biannual survey) - Time-to-quote dropped from 47 minutes (median) to 11 minutes - Internal support tickets to the Salesforce admin dropped 64% — mostly because the workflows the admin had to fix monthly were now automated The CFO's question from the first call ("how much of our CRM spend translates to revenue impact?") now has an answerable form. Each Y2 dollar in the layer maps to a workflow with a measurable ops outcome. ### Lessons that transfer to other insurers #### Audit before you architect We didn't propose the architecture for 2 weeks. The first 2 weeks were the audit — and the audit, not the architecture, was what made the CFO comfortable with the path. If we'd opened with "let's build a custom CRM," the project wouldn't have happened. We opened with "let's see where the money is going." That's how you get permission to move. #### Don't replace what works — wrap it The fastest way to lose a custom-CRM project is to migrate too much. We deliberately kept Accounts/Contacts in Salesforce. The data model wraps Salesforce's data, doesn't replace it. Trust the parts of the platform that work. #### Adoption beats features We shipped fewer features than the original Salesforce setup. Adoption was higher. The custom layer covers exactly what the team uses, and nothing else. When agents log in, every screen is a workflow they actually use. That's the difference between 58% license utilization and 91%. Want the same audit for your CRM stack? Book a free 2-week CRM Cost & Fit Audit, or read the underlying case study for the full delivery breakdown. ## What a HIPAA audit actually looks like — from the inside URL: https://health.onix-systems.com/insights/what-a-hipaa-audit-actually-looks-like Compliance · 8 min · 2021-06-19 · Denis Sheremetov, CTO Most teams build to a checklist and hope. We've sat across from the auditor — here's what they actually ask, and what surprises engineering teams. Most engineering teams encounter HIPAA the same way: a checklist drops into Jira, someone Googles "HIPAA Security Rule", and the team ships the controls that look most like code. Encryption-at-rest? Done. Access logs? Done. BAAs? Legal handles that. Then the audit happens. And the auditor doesn't ask about any of those things first. ### What auditors actually ask in the first hour We've sat through six HIPAA audits in the last 18 months — across hospital systems, digital health startups, and one MedTech vendor. The pattern is consistent. Auditors don't start with the controls. They start with the process around the controls. - Who decided this PHI flow was necessary? Show me the decision document. - Who has access to production data, and when was that list last reviewed? - Show me the last access review. Show me the one before it. - Walk me through what happens when an engineer leaves the team. - When was the last time someone tried to access this and was denied? Show me the log. Notice what's not on this list: encryption algorithm choices, TLS version, IAM policy syntax. Auditors assume those are correct, or they assume they can verify them later. What they're testing in the first hour is whether your organization can answer process questions consistently. ### The three things that surprise engineering teams First: access reviews are a quarterly event for the auditor, not an annual one. If you have a quarterly access review process documented but you can only produce evidence for the last review — that's a finding. Auditors want a chain of evidence, not a snapshot. Second: the BAA flows downward. If your team uses a tool that touches PHI — even indirectly, like a log aggregator — your BAA needs to cover that tool, and the tool's vendor needs to have signed one with you. Most teams discover this when the auditor asks to see the BAA with the SaaS vendor and the answer is "we'll get back to you." That's a finding too. Third: incident response drills count. If your IR plan has been written but never tested, auditors treat it as if it doesn't exist. We run our IR drills twice a year, and we keep the redacted post-drill notes specifically because the auditor will ask for them. > Auditors aren't testing whether you can build secure systems. They're testing whether your organization can operate secure systems — under turnover, scope changes, and pressure. > — Lead auditor on one of our engagements ### What we recommend teams do, in order - Pick one PHI dataflow. Write the decision document explaining why it exists. Sign it. Date it. - Generate your access list today. Sign and date that list. - Schedule the next access review for 90 days from now. Calendar invite. - Inventory every SaaS tool. Mark the ones that touch PHI directly or indirectly. Get a BAA from each. - Schedule an IR drill for next quarter. Run it even if it feels rehearsed. Keep notes. Engineering instinct is to build the technical control first and document later. The auditor's instinct is the inverse. Both are right — but the documentation cadence is what they actually evaluate. ## FHIR for non-engineers: a 10-minute primer for product managers URL: https://health.onix-systems.com/insights/fhir-for-non-engineers Interoperability · 10 min · 2019-07-23 · Valerii Checha, Head of Business Unit If you're the PM on a healthcare project, you don't need to write FHIR code — but you do need to understand what your engineers mean when they say it. You're the PM on a healthcare project. Your engineers keep saying "we need a FHIR resource for that" or "that's not in the FHIR spec" and you're nodding along, pretending you know what they mean. You don't need to write FHIR code. But you do need to understand what your engineers mean — well enough to scope, prioritize, and push back when they're hand-waving. This is the 10-minute version. ### What FHIR actually is FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a standard for representing healthcare data — and a standard for the APIs that move it around. It's published by HL7, the same organization behind HL7v2 (the older standard) and CDA documents. Three things to know: - FHIR is RESTful — every resource has a URL, you GET/POST/PUT/DELETE it, just like any modern API. This makes it dramatically easier to work with than HL7v2. - FHIR resources are JSON (or XML). Patient is a JSON object. Observation is a JSON object. Encounter is a JSON object. They reference each other by URL. - FHIR R4 (Release 4) is the current production standard. If someone says "FHIR" without qualification, they probably mean R4. ### Resources, references, bundles — the three things to know Almost every conversation about FHIR comes back to these three concepts. A resource is a structured piece of healthcare data. There are ~150 resource types defined in FHIR R4. The most common ones you'll talk about: Patient, Practitioner, Encounter, Observation, Condition, Procedure, MedicationRequest, AllergyIntolerance, DocumentReference, Organization. A reference is how resources point at each other. An Observation has a reference to the Patient it belongs to (something like "Patient/12345"). An Encounter has a reference to the Patient and a reference to the Practitioner. Resources don't embed each other — they reference. This is critical for performance, and it's the source of most FHIR pain (you fetch a Patient, then you have to fetch all their Observations separately). A bundle is a collection of resources returned together. When you search FHIR, you get back a Bundle of Patient resources. When you submit a batch of writes, you submit a Bundle. Bundles are how FHIR groups things. ### The three operations PMs encounter There are dozens of FHIR operations, but you'll mostly hear about three. Read — fetch a specific resource by ID. "Get this patient's record." This is the easy one. Everyone's FHIR server supports read. Write — create or update a resource. "Record this lab result." This is where most teams get stuck. Many FHIR servers — including big-name EHRs — are read-only or have severe write restrictions. If your project requires write-back into Epic, that's a different conversation than read. Search — find resources matching criteria. "Get all observations of type 'blood pressure' for patients seen in the last 30 days." Search is where FHIR gets weirdly inconsistent: every FHIR server supports search differently, and the criteria available vary by implementation. Don't assume a search works until you've tested it on the actual server. ### Where conformance matters FHIR is a spec. Implementations vary wildly. Epic's FHIR is not Cerner's FHIR is not Athenahealth's FHIR — they all conform to the same spec at the surface, but they each define their own "profiles" and support different optional features. Conformance is the formal way an implementation says "here's exactly what I support." A FHIR server publishes a CapabilityStatement — a machine-readable document listing every resource type, search parameter, and operation it supports. When scoping FHIR work, make your engineers read the target server's CapabilityStatement before committing to a timeline. We've seen 3-month projects discover in week six that the target EHR doesn't support a search parameter the design depended on. ### What "we have a FHIR integration" actually means When a vendor says "we have a FHIR integration with Epic," the actual meaning varies wildly. Press for specifics: - Read-only or read/write? Most are read-only. - Which resources? "FHIR integration" might mean Patient + Observation only. - Is it the patient-facing FHIR API (US Core, limited) or the bulk FHIR API (more resources, but requires different auth)? - Bidirectional sync, or one-way? - What's the auth model — SMART on FHIR (user-mediated) or system-to-system (back-channel)? Until you have answers to these, you don't have a scoped FHIR integration. You have a marketing claim. > FHIR is a spec, not a product. Two compliant implementations can be wildly different to work with. ### Red flags when scoping FHIR work - "It's just a FHIR integration" — there is no "just" with FHIR. Demand specifics. - "FHIR R3 or R4, doesn't matter" — it absolutely matters. R3 to R4 has breaking changes; you'll pick one and commit. - "We'll add write support later" — write support is fundamentally different from read. Don't punt it. - "Search will be fine" — until you've tested the specific search you need on the target server, assume it won't be. - "It's HL7" — HL7 is the organization. They publish FHIR, HL7v2, and CDA. These are different standards. Ask which one. ### The right questions to ask Five questions that get you 90% of the way to a scoped FHIR conversation: - Which FHIR version — R3, R4, or R5? - Which resources — and is it the US Core profile, or full FHIR? - Read-only, write-only, or bidirectional? - What's the auth flow — SMART on FHIR, OAuth client credentials, or something custom? - Has anyone on the team actually read the target server's CapabilityStatement? If your engineers can answer all five, you have a scoped project. If they can't, get the answers before you commit to a date. ## When to rescue and when to rebuild: a decision framework URL: https://health.onix-systems.com/insights/rescue-vs-rebuild-decision-framework Strategy · 12 min · 2022-10-04 · Valerii Checha, Head of Business Unit Half of our healthcare engagements start as rescues. Here's how we decide — in the first 48 hours — whether to fix what's there or burn it down. About half of our healthcare engagements start as rescues. A vendor went silent. A team shipped a non-compliant MVP and the audit is in 12 weeks. An EHR migration stalled and the executive sponsor is asking when, exactly, this will be done. Founders ask us the same question every time: do we fix what's here, or burn it down and start over? Almost always, the answer is neither — at least not how the question is framed. After running 30+ healthcare rescues, we've found that the decision lives in a specific structure. Here's the framework we use. ### The 48-hour rule: don't decide before then The first instinct on a rescue is to make a decision fast. Don't. We've watched teams sign multi-month rebuild contracts on day three of an engagement, only to discover on day fifteen that 80% of the existing code was actually fine — and the real problem was a single bottleneck nobody had isolated yet. Our rule: no rescue-or-rebuild decision before 48 hours of audit time, regardless of how obvious it looks. The first 48 hours buy you the chance to see what's actually broken vs. what's loud. ### The three questions that drive the decision Every rescue audit answers three questions in this order. They map to three different remediation paths. - Is the architecture salvageable? — If the data model and trust boundaries are wrong, no amount of code cleanup fixes it. This is the only true rebuild trigger we've ever seen. - Is the team that built it still in place? — If yes, rescue is twice as fast (they have the context). If no, factor in 3-4 weeks of code archaeology to get to the same place. - Is the deadline real? — A 'real' deadline (regulator, contract, funding round) means scope must compress to what's achievable. A 'soft' deadline (internal target) means scope can stay broader. ### Rescue indicators Most projects that look unsalvageable are actually rescuable. The signals that point toward rescue: - Bug rates are high, but the bugs cluster — there's a single broken subsystem dragging everything down, not pervasive rot. - Tests exist (even partial coverage). Tests are an architectural signal: they mean the code was at some point shaped to be testable. - Auth and data model are intact. These are the two things that are genuinely hard to refactor; if they're correct, the rest is moveable. - Customer-facing UI is fine. Backend rot is fixable behind a stable UI; UI rot during an active customer relationship is much harder. - The original engineer or two is still reachable. Even one hour of context from the original author cuts rescue time by 30%+. ### Rebuild indicators Genuine rebuild triggers are rare, but specific. When we see them, we recommend rebuild without ambiguity: - Wrong data model at the root. If PHI is co-mingled with non-PHI, or the patient/encounter relationship is inverted, no surface fix works. - Compliance posture is structurally absent. No audit logging, no access control framework, no encryption strategy — this is rebuild territory. - Stack choice fights the requirements. A serverless app that needs long-running ML inference, or a monolith that needs HIPAA tenant isolation — patches won't get there. - Original team is fully gone AND there's no documentation. The code archaeology cost approaches rebuild cost, and you don't get a better outcome. ### The hybrid path — what we usually recommend In practice, ~80% of our rescues end up as a hybrid: keep the existing surface, replace one or two backend subsystems, harden the compliance posture, and ship. We call this the strangler-fig pattern, after Fowler's term — incrementally replacing parts of the system behind a stable interface, until the rewrite is invisible to users. The hybrid path lets you ship to the deadline (regulator, contract, raise) on the existing surface while replacing the problem subsystems. Customers don't see a rewrite. The team has a real roadmap. And the surface that's actually fine doesn't get re-litigated. > The right question isn't 'rescue or rebuild?'. It's 'what's the smallest fix that lets us ship to the real deadline — and what's the medium-term path that gets us off the bad parts?' ### One real example A provider network came to us 4 months into a stalled portal build. The vendor had gone dark. The audit was 12 weeks out. The founder asked us in the first call: 'Do we burn this down and start over?' Five-day audit. We found: auth was broken (rebuild), but the data model was correct (keep), the FHIR integration was 60% built and roughly right (rescue), and the audit logging was performative but not real (rebuild). We rebuilt the auth and the audit logging. We finished the FHIR integration. We left the rest. Shipped in 9 weeks. The 95% drop in support tickets came from the auth fix alone — the rest of the code wasn't actually broken, it was just downstream of broken auth. ### What we tell teams in the first call - Don't decide rescue-or-rebuild before the audit. The instinct to decide fast is the instinct to be wrong fast. - Map the deadline to the scope, not the other way around. A real deadline shrinks what's possible — but it also shrinks what's worth arguing about. - If the auth and data model are correct, you almost certainly have a rescue, not a rebuild. - If the team is intact, rescue is twice as fast. Keep them in the room. - The hybrid path is the most common right answer — but only after you've actually looked at the code. We've seen $400K of rebuild work scoped on a project that turned out to need $80K of targeted rescue. We've also seen $80K of rescue work scoped on a project that genuinely needed a rebuild. The difference is the audit — and being willing to not decide in the first 48 hours. ## Building a clinical validation harness for ML in healthcare URL: https://health.onix-systems.com/insights/ai-clinical-validation-harness AI · 11 min · 2025-12-15 · Serhii Kholin, CEO Models that work on benchmarks don't always work in your hospital. Here's the validation infrastructure we wish every team had on day one. A model that hits 94% accuracy on a public benchmark is not the same as a model that hits 94% accuracy in your hospital. The benchmark probably came from one institution, one demographic, one EHR system. Your hospital is none of those things. We've shipped ML into clinical workflows enough times to have learned the same lesson the hard way, several times: the model itself is maybe 30% of the work. The validation harness — the infrastructure that tells you whether the model is doing what you think it's doing, on your data, with your patients — is the other 70%. Here's what we wish every team had on day one. ### What a validation harness actually is A validation harness is the always-on infrastructure that answers four questions, on a continuing basis: - Is the model performing now the way it performed when we shipped it? - Is it performing equally well across the populations we serve, or only well on the dominant one? - When clinicians disagree with the model, what are they disagreeing about — and is that signal of drift, or signal of edge cases? - If something changes in the upstream data, will we know before the clinicians do? Notice these aren't "is the model accurate?" questions. Accuracy in aggregate is a comforting number that hides almost everything that goes wrong in production. ### The four layers We structure validation harnesses in four layers. Each layer answers a different category of question, and each one is non-optional for clinical ML. Layer 1: data validation. Before any input reaches the model, schema and distribution checks run. If you're expecting age in years but your EHR starts sending months for pediatric patients, the data validation layer catches it. If a vendor changes a lab unit from mg/dL to mmol/L, you find out at the data layer, not in the model output. Layer 2: prediction monitoring. Every prediction is logged with: model version, input features (or a hash of them, if PHI sensitive), prediction confidence, downstream action taken (accepted, modified, rejected by clinician), and outcome where available. This is the foundation everything else builds on. Layer 3: subgroup performance tracking. Performance across the demographics that matter to your patient population. If your model is 94% accurate overall but 76% accurate for one age group, you need to know — and the only way to know is to measure it explicitly, ongoing, with alerts when subgroups diverge. Layer 4: drift detection. Two flavors. Input drift (the distribution of features changing — new disease prevalence, new vendor systems, new patient demographics). Output drift (the distribution of predictions changing even when inputs look stable). Both can be early signals that something is wrong before the outcomes deteriorate. ### The hardest part: ground truth, lag, and confounding Most ML platforms outside healthcare can compute model accuracy in near-real-time. In healthcare, ground truth often arrives weeks or months after the prediction — and sometimes never. A sepsis risk model predicts at hour 0 that a patient is high-risk. Ground truth (did they develop sepsis? did the intervention prevent it?) might not be definitively answerable for days or weeks. And the intervention itself confounds the outcome: if the model predicted high risk and clinicians acted, you can't measure the unintervened outcome. Practical implication: the validation harness has to track three time horizons separately. Immediate (data validation, prediction logging — minutes). Short-term (clinician agreement, override rates — hours/days). Long-term (clinical outcome correlation — weeks/months). Each horizon has its own dashboard and its own alerting policy. ### Subgroup performance — the part teams skip Every team we've worked with had a generic accuracy number. About half had subgroup performance tracked at all. Almost none had it tracked in production with alerts. The minimum we recommend: track at least age cohort, sex, and race/ethnicity where available. If the model is for a specific condition, also track by relevant clinical subgroups (e.g., diabetic vs. non-diabetic for cardiovascular risk models). For each subgroup, compute the same metrics you track in aggregate — and alert when any subgroup's metric drops more than X% below the aggregate. Why it matters: a model that's 92% accurate overall but 78% accurate for one ethnic group, on a population where that group is 15% of patients, will produce systematically worse care for those patients — and you won't see it in the aggregate number. ### The clinician disagreement signal When a clinician overrides the model, that's a data point — possibly the most valuable one. We instrument every override with: the prediction, the override reason (from a structured dropdown plus optional free text), the resulting decision, and the eventual outcome. Useful patterns emerge: - Override rate trending up over weeks → likely drift. Investigate the data layer. - Override rate spiking for one clinician → probably a calibration or trust issue. Talk to them. - Override rate spiking for one shift/unit → workflow problem, not model problem. - Override rate spiking after a specific date → look at deploys, EHR upgrades, or data source changes around that date. > The override is not a failure of the model. It's the data point that tells you whether the model is converging with clinical judgment over time, or diverging. ### What deployment looks like, end-to-end A typical clinical ML deployment we'd recommend: - Shadow mode (2-4 weeks). Model runs on every relevant case, but predictions aren't shown to clinicians. You measure accuracy, subgroup performance, and override rate (against a small panel of expert reviewers). - Pilot deployment (4-8 weeks). Model predictions visible to a small clinical group, with structured override capture. Targets: subgroup parity, override rate stable, no novel failure modes. - Phased rollout (4-12 weeks). Expand by specialty, location, or service line. Each phase has explicit go/no-go criteria. - Continuous monitoring (ongoing). All four validation layers running, with alerting tuned to clinical leadership escalation paths. Skip the shadow phase and you ship blind. Skip the pilot and you discover failure modes at scale instead of in a small group. ### Common mistakes - Tracking aggregate accuracy only. Hides subgroup divergence, which is where harm happens. - No ground truth tracking. You think you're measuring accuracy, but you're measuring prediction-vs-prediction. - Override rate logged but not analyzed. The signal is there, but no one is watching it. - Model version not logged with predictions. When you deploy a new version, you can't tell which predictions came from which model. - Treating drift as an alarm rather than a signal. Drift detection should trigger investigation, not panic — most drift has a benign explanation. ### What to build first If you're starting from zero and can only build one thing: log every prediction with model version, input hash, confidence, clinician decision, and timestamp. That single table is the foundation for everything else. You can add subgroup tracking, drift detection, and outcome correlation on top — but you can't reconstruct the data after the fact. If you can build two: add subgroup performance tracking, with alerts. If you can build three: add structured clinician override capture. Everything else can wait. Most teams ship models without these three, and then learn the lesson the expensive way. ## IEC 62304 in practice: what it actually requires (and what people get wrong) URL: https://health.onix-systems.com/insights/iec-62304-in-practice MedTech · 14 min · 2020-03-26 · Serhii Kholin, CEO 62304 doesn't tell you to write tests. It tells you to write tests that trace to requirements that trace to user needs. Here's what that looks like in a real codebase. IEC 62304 is the international standard for medical device software lifecycle. The first thing teams new to it usually do is treat it like a compliance checklist. The first thing they discover is that 62304 isn't a checklist — it's a process. And the process has structural requirements that don't fit easily into a typical engineering workflow. After running IEC 62304-aligned SDLCs on a dozen SaMD projects, here's what the standard actually requires, and the three things teams consistently underestimate. ### What IEC 62304 isn't It isn't a test coverage target. It doesn't say "80% line coverage." It isn't a tooling spec. It doesn't say "use this framework." It isn't a security standard. (That's IEC 81001-5-1 and FDA cybersecurity guidance — closely related but separate.) What 62304 actually requires is a documented software lifecycle, with traceability between user needs, software requirements, software design, implementation, and verification. The standard cares about whether you can show the chain — not whether you used a particular tool or hit a particular metric. ### Software safety classification (Class A / B / C) Before writing a line of code, you classify your software. - Class A — no injury or damage to health possible. Lowest documentation burden. - Class B — non-serious injury possible. Moderate documentation; most SaMD lives here. - Class C — death or serious injury possible. Highest burden; full unit-level testing and detailed design documentation required. The classification flows from ISO 14971 risk analysis, not from the developer's intuition. We've seen teams classify themselves as Class A to dodge documentation overhead, then have to redo months of work after the risk analysis flagged a hazard. Do the risk analysis first. ### The traceability chain This is the single most important concept in 62304. Every test must trace to a requirement. Every requirement must trace to a user need. Every implementation decision must trace to a requirement. In practice, this means maintaining a traceability matrix that connects: - User needs (e.g., "the device shall measure blood pressure within ±3 mmHg") - Software requirements (e.g., "BP measurement subsystem produces readings with ±2 mmHg measurement accuracy") - Software architecture (e.g., "BP subsystem implemented in module bp.cpp") - Tests (e.g., "test_bp_accuracy.cpp validates ±2 mmHg requirement") - Verification results (e.g., "test passed on build 1.4.2-rc3") Auditors will pick a random test and trace it back to user needs. Then pick a random user need and trace it forward to tests. If the chain is broken anywhere, it's a finding. ### Where 62304 differs from typical SDLCs Most engineering teams already have something resembling tests and requirements. 62304 differs in three specific structural ways: First: change control is mandatory. Every change to released software requires a documented change request, impact analysis on the traceability matrix, and verification that the change didn't break unrelated requirements. "Just push the fix" is a 62304 violation. Second: problem resolution is process-driven. Bugs found in fielded software flow through a defined problem resolution process: report → assessment → severity classification → impact analysis → resolution → verification → release notes. Not Jira tickets and a hope. Third: SOUP (Software of Unknown Provenance) handling. Every third-party library is SOUP unless you can show it was developed under 62304. You have to document each dependency, its version, its known anomalies, and your strategy for monitoring it. This means an SBOM is mandatory — not optional. ### The three things most teams underestimate First: documentation can't be back-filled. We've watched teams attempt this — ship the code, then write the requirements and traceability matrix from the code. The problem is that engineering teams have already made hundreds of implicit decisions that aren't requirements. Re-documenting them after the fact misses the actual decisions and gets caught by auditors. Second: the unit testing requirement for Class B is more rigorous than people think. "Unit tests" in 62304 means tests that cover requirements at the unit level — not tests that cover code paths. A test that hits 100% of branches but doesn't trace to a requirement doesn't count. We've seen teams with extensive test suites fail audits because the tests weren't requirement-driven. Third: configuration management is part of 62304, not separate. Your version control, build system, and release management practices have to be documented and auditable. "We use git" isn't enough — you need branch policies, release tagging, and build reproducibility documented. > The standard doesn't tell you to write good software. It tells you to write the trail that shows you wrote it on purpose. > — Auditor on a Class II engagement ### What auditors actually check In our last six audits, the artifacts auditors actually pulled were consistent: - Traceability matrix (always, first thing) - Random test → requirement → user need walk-back (always) - Random user need → requirement → test → result walk-forward (always) - SOUP inventory and known anomalies list (always) - Last 3 change requests with impact analysis (typical) - Last 3 problem reports with resolution path (typical) - Build reproducibility — can they get the same binary from the same commit? (typical) Notice what's not on the list: code style, test coverage percentage, framework choices. Auditors aren't testing engineering quality. They're testing whether the process is real and operational. ### Starting from scratch vs. patching an existing codebase If you're starting a new SaMD project, build 62304 in from day one. The cost is moderate when integrated; brutal when retrofitted. Most of the work is structural — once the traceability matrix exists and the change control process runs, the per-feature overhead is maybe 20-30%. If you're retrofitting an existing codebase, the question is whether the architecture supports requirement-level testing. If the code is structured around features that map to user needs, you can usually retrofit. If the code is structured around technical layers ("the database module," "the UI module"), retrofit is harder because the unit tests don't naturally map to requirements. We've retrofitted Class B codebases in 8-12 weeks. We've also rebuilt codebases in 6-8 weeks because the retrofit cost exceeded the rebuild cost. There's no general answer — it depends on the code. ### Closing IEC 62304 isn't about engineering quality. It's about engineering legibility — the ability for a third party to walk through your software, ask why every piece is there, and get a documented answer that traces all the way back to a user need. Once you internalize that, the rest of the standard makes sense. The change control isn't bureaucracy — it's keeping the legibility intact under turnover. The SOUP inventory isn't paperwork — it's the only way to know if a library you depend on has a known issue. The traceability matrix isn't a chore — it's the document an auditor will read in the first hour. Build the trail on purpose. Don't try to back-fill it. ## Surviving an Epic App Orchard review: a survival guide URL: https://health.onix-systems.com/insights/epic-integration-survival-guide Interoperability · 9 min · 2023-02-14 · Serhii Kholin, CEO The Epic review process is famously rigorous. We've been through it nine times. Here's the prep work that shortens the cycle from 4 months to 6 weeks. Epic's review process is famously rigorous. There's a reason: Epic powers 250M+ patient records, and an integration that misbehaves can ripple across hundreds of hospital systems. The process is rigorous for good reasons — but it's also navigable. We've been through it nine times. Here's what we've learned. ### The three Epic integration paths Not every integration goes through the same review. The path determines the documentation burden and the timeline. - App Orchard (now Connection Hub for newer apps) — the marketplace path. You're publishing an app that any Epic customer can install. Highest review burden, longest timeline (typically 3-5 months), but you build once and many customers can install. - Direct integration with a specific customer — you're integrating with one hospital's Epic instance. Customer's IT team does most of the review. Shorter (6-10 weeks), but you do this for every customer. - Open Epic / public FHIR APIs — read-only, patient-facing FHIR. No formal Epic review at all — just the technical work. Very fast (2-4 weeks), but functionally limited. Scoping the integration path is the first decision. Picking wrong is expensive — we've seen teams build to App Orchard requirements when they only needed direct integration, doubling their timeline. ### What Epic actually reviews Across our nine submissions, Epic's review focused on four things, in roughly this order: Data flow and trust boundaries. They want a diagram showing what data leaves Epic, where it goes, how long it's retained, and who has access. This is the foundation of everything else. Authentication and authorization. Are you using SMART on FHIR correctly? Do scopes match what your app actually does? If your app requests patient/*.read scope but only displays one field, that's a finding. Performance characteristics. Epic instances are shared infrastructure. They care that your app doesn't hammer their FHIR endpoints. Expect to document expected request rates, retry behavior, and cache strategy. Failure modes. What happens when Epic is slow? When a call returns 500? When a token expires mid-session? They want to see graceful degradation, not crashes. ### Security review prep Security review runs in parallel to functional review and often takes longer. Things to have ready before you start: - Threat model document. STRIDE or LINDDUN, your choice. They want to see you've thought about misuse. - Data flow diagram, with trust boundaries labeled. - Inventory of all third-party services your app uses (cloud providers, analytics, error tracking — yes, everything). - Encryption strategy: at-rest, in-transit, and key management. Customer-managed keys preferred. - Incident response plan with named contacts and SLAs. - Penetration test results from the last 12 months. If you don't have one, schedule it before you submit. - SOC 2 attestation or equivalent (HITRUST, ISO 27001). Not strictly required for all paths, but expedites review. Teams that show up without these inevitably go into a back-and-forth cycle that extends the timeline by 4-8 weeks. Teams that show up with these typically clear security review in 3-4 weeks. ### The technical artifacts you need Beyond the security pack, Epic wants specific technical artifacts: - OAuth flow diagram showing the SMART on FHIR launch sequence end-to-end. - CapabilityStatement of the FHIR resources you read or write, with the specific search parameters you use. - List of scopes requested and exactly which features use which scopes (minimum-scope principle). - Sample requests and responses for each operation, including error cases. - App manifest with launch URIs, redirect URIs, and post-logout URIs. - Test plan showing how you tested against Epic's sandbox before submission. ### What slows the review down From our submissions, the consistent slowdowns: - Over-scoping. Requesting more SMART scopes than your app uses. Epic asks you to justify each — and if you can't, you go back and refactor. - Slow responses to questions. Epic's reviewers ask questions in batches. A 48-hour response cycle extends a typical review by 3-4 weeks vs same-day responses. - Missing failure-mode handling. "What happens if Epic returns 503?" If you can't show the answer in code and tests, expect a back-and-forth. - Third-party service surprises. Forgetting to disclose that your app sends data to a logging service or analytics tool. Discover this in review and you go back to security. - Customer-side delays. For direct integrations, the customer's IT team owns half the review. If they're slow to schedule meetings, you're slow to ship. ### Tips from nine prior submissions First: pick a launch customer who has done this before. Their familiarity with the process compresses the timeline by weeks. We've shipped first integrations to launch customers with prior Epic experience in 5-6 weeks; first-time launch customers typically run 10-12. Second: schedule the security review before you submit. Don't wait for Epic to ask. Get the pen test scheduled, the SOC 2 evidence collected, the threat model drafted — and submit them with the initial package, not in response to questions. Third: build to the Epic sandbox first, then to production. Their sandbox isn't perfect, but it surfaces 80% of integration issues. Teams that test only against production hit those issues during review, not before. Fourth: name a named submission lead on your side. Epic reviewers prefer to talk to one person, not rotate through engineers. Designate the same person to answer all questions for the duration. > The teams that struggle with Epic review aren't engineering teams. They're engineering teams that hadn't realized the review is half-engineering, half-organizational discipline. ### The timeline to plan for Realistic timelines from kickoff to live in Epic: - Direct integration, customer has Epic experience: 6-8 weeks - Direct integration, first-time customer: 10-14 weeks - App Orchard / Connection Hub, prepared team: 12-16 weeks - App Orchard / Connection Hub, first-timer: 16-22 weeks If your stakeholders are quoting timelines below these, they haven't done it before. Push back. The way you save time isn't by shortcutting review — it's by being prepared enough that you only go through it once. ## Ambient voice documentation: pipelines that don't leak PHI URL: https://health.onix-systems.com/insights/ambient-voice-documentation-pipelines Engineering · 13 min · 2024-11-30 · Serhii Kholin, CEO Voice-to-note is one of the highest-leverage AI uses in clinical practice. It's also one of the easiest places to ship a HIPAA violation. Here's how to architect it. Ambient voice documentation is the most consistently-loved AI feature we've shipped in healthcare. Clinicians, in our experience, ask for two things: keep me out of the EHR and don't make me think harder. Voice-to-note delivers on both — when it's done right. It's also the easiest place we've seen teams accidentally ship a HIPAA violation. The audio stream is PHI. The transcript is PHI. The intermediate cache is PHI. Every hop is a place where the architecture can leak. After building voice pipelines for four different clinical settings, here are the architectural patterns we've converged on — and the specific places teams most often get it wrong. ### Why voice pipelines are different Most ML pipelines you can prototype locally and worry about PHI later. Voice pipelines are not that. The first second of audio captured in a clinical encounter is PHI. There's no "de-identification later" — there's only "never let it leave the BAA-covered environment in the first place." Three things make this harder than a typical inference pipeline: - Audio is large. Transcripts are tiny. Most of your storage and bandwidth cost is in audio. - Transcription accuracy matters at single-word level. "50 mg" vs "15 mg" is the difference between a correct prescription and a clinical error. - Latency matters. Clinicians won't tolerate a 30-second delay to see what was just said. Either it streams or they stop using it. ### The three architecture patterns There are three common architectures. Each one trades latency, cost, and PHI surface area differently. Pattern 1: All-cloud, streaming. Audio is streamed from the clinician's device to a transcription service (AWS Transcribe Medical, Azure Speech, Google Speech-to-Text — all BAA-eligible). Transcript comes back streaming. Post-processing (structured note generation, EHR formatting) runs in the cloud. Pros: lowest engineering cost, highest accuracy. Cons: audio crosses the network in real-time; bandwidth-sensitive in clinical settings with weak Wi-Fi. Pattern 2: Edge transcription, cloud post-processing. Audio is transcribed on-device (phone, tablet, or dedicated hardware) using an on-device speech model. The transcript — not the audio — is sent to the cloud for structuring. Pros: audio never leaves the room; lower bandwidth; works offline. Cons: on-device transcription is harder to keep current with the state of the art; per-device deployment burden. Pattern 3: Hybrid. Audio is captured on-device, batched (or streamed under controlled conditions), and processed in a customer-controlled cloud (VPC or dedicated tenant). Useful when the customer's compliance team doesn't trust shared transcription services. Pros: maximum customer control. Cons: highest engineering cost, you become the transcription service. We've shipped all three. Pattern 1 is the right default for ~80% of use cases. Pattern 2 makes sense when bandwidth is unreliable or for SaMD-class deployments. Pattern 3 is rare — usually a contractual requirement, not a technical one. ### Where PHI actually leaks Five places we've seen teams accidentally expose PHI: - Application logs. Default logging captures request bodies. If the transcript is in the request, it's now in your log aggregator. Most log aggregators are not BAA-covered. - Error tracking. Sentry, Bugsnag, Rollbar — if a transcription fails and the audio buffer ends up in the exception, your error tracker is now holding PHI. Sign a BAA or redact at source. - Browser/client storage. Caching transcripts to localStorage or IndexedDB for offline support is a HIPAA risk if the device isn't enterprise-managed. - Analytics. Product analytics that captures input text — common in form analytics tools — will hoover up transcript content. Block at the field level. - Backups. Even if your primary storage is BAA-covered, are the backups encrypted with customer-managed keys? Are they replicated to a region the BAA covers? The pattern: PHI doesn't usually leak from the obvious places. It leaks from the supporting infrastructure that was designed for non-PHI workloads. ### Key design decisions Decisions we make explicitly on every voice deployment: Retention. How long do you keep the audio? The transcript? The intermediate caches? Audio retention should usually be minimal (delete after transcript is durable). Transcript retention follows EHR retention policies. Intermediate caches should be zero — never write them to disk. Speaker diarization. Do you need to separate clinician voice from patient voice? In some settings, you do (for accurate note attribution). In others, you don't. Diarization adds latency and cost — only enable it when you actually need it. Wake-word vs. continuous. Wake-word activated ("Hey [tool name]…") captures less audio overall but misses spontaneous content. Continuous captures everything but raises the PHI exposure surface dramatically. We lean toward visit-bounded (clinician explicitly starts and stops recording) as a middle ground. Structured note format. Are you outputting freeform text? SOAP-formatted notes? Discrete structured fields back into the EHR? The output format determines half the pipeline complexity downstream. Decide before you start building. ### BAA-eligibility, in practice Every cloud service in the pipeline needs a BAA. This isn't optional. Common services that are BAA-eligible (with the right configuration): - AWS Transcribe Medical, AWS Transcribe (general) — eligible under AWS HIPAA - Azure Speech Service — eligible under Azure HIPAA - Google Speech-to-Text — eligible under Google Cloud HIPAA - OpenAI (via Azure OpenAI Service) — eligible. Direct OpenAI API is NOT BAA-eligible for clinical PHI use. - Anthropic Claude (via AWS Bedrock or direct enterprise contract) — eligible under specific terms Things teams use that aren't typically BAA-eligible: most third-party analytics, most error tracking SaaS (without specific configuration), most generic logging SaaS. Verify before you ship. ### The deployment checklist Before we ship a voice pipeline to clinicians, every item on this list has to be answered: - Every service in the pipeline has a signed BAA. - Audio retention policy is documented and enforced by code, not by convention. - Logs are configured to redact transcript content (or sign a BAA with your log aggregator). - Error tracking is configured to redact request/response bodies (or to fail-open on errors without sending stack traces). - Client-side caches are encrypted at rest, ideally with customer-controlled keys. - Analytics is field-blocked on transcript content. - Backups are inside the same compliance boundary as the primary data. - End-to-end PHI flow diagram is signed off by the customer's privacy officer. - Incident response plan covers audio retention failure modes. > Teams that ship clinical voice tools fast learn the hard way which of their supporting tools weren't BAA-covered. Teams that ship slow learn it during a security review. ### Closing Voice documentation is one of the most rewarding things you can ship in clinical practice. Clinicians will love it. The downside risk is asymmetric — when it works, it's invisible. When it leaks, it's a breach notification. Architect for PHI containment from the first prototype. Don't decide "we'll figure out the compliance side later." The pipeline you prototype is the pipeline you ship — and rebuilding the pipeline after the fact to add BAA-covered logging is more expensive than getting it right the first time. ## Why nobody uses your patient portal (and what to measure to fix it) URL: https://health.onix-systems.com/insights/patient-portal-adoption-metrics Engineering · 7 min · 2021-09-08 · Denis Sheremetov, CTO Portal adoption baselines in healthcare run 30-40%. The teams hitting 60-80% measure four things their peers don't. Here they are. Patient portal adoption in US healthcare runs 30-40% by most industry benchmarks. The portals we've shipped tend to land in the 60-80% range. The teams hitting those numbers are not building better software than their peers. They're measuring four specific things that most healthcare product teams don't bother measuring at all. ### What most teams measure (and why it doesn't help) Walk into any patient portal team's QBR and you'll see the same metrics: registered users, monthly active users, total logins. These tell you nothing about whether the portal is doing its job. Registered users is supply (patients with accounts), not demand (patients getting value). MAU is too lagging. Total logins counts power users many times and disengaged patients zero. What you actually need is funnel data on what patients try to do, where they drop off, and what they come back for. ### Metric 1: Activation rate by intent Patients sign up for portals for specific reasons: a test result, a bill, an appointment, a message from a provider. Activation rate by intent measures, for each entry reason, what percentage of patients who arrived for that reason actually completed it. Example: of patients who arrive intending to view a lab result, what percentage view it within their first session? A portal that's 90% on "view lab result" but 30% on "pay a bill" is telling you the bill-pay flow is broken, regardless of overall MAU. Most teams can't compute this because they don't capture intent. Capture it: a one-question modal on first login ("What brings you here today?") and you suddenly have segmented adoption data. ### Metric 2: 7-day return rate 30-day retention is the industry default. It's the wrong horizon for patient portals. Healthcare interactions are episodic. A patient might sign up after a visit, come back twice in the next week, then not return for three months — and that's the right pattern. Tracking 30-day return rate punishes that pattern artificially. 7-day return rate, in our experience, correlates much better with longer-term engagement. A patient who came back within 7 days found enough value to come back. The 30-day window includes too many patients who returned by accident or because they got an email. Benchmark: portals with 7-day return rates above 35% tend to land in the 60-80% adoption tier over 12 months. Portals below 25% rarely get there, regardless of what's built on top. ### Metric 3: Task completion vs. session count Two patient journeys produce the same MAU number but tell very different stories. Journey A: a patient logs in, finds what they need in 90 seconds, logs out. They return three weeks later for the next thing. Journey B: a patient logs in, doesn't find what they need, logs in again the next day, asks a family member to help, logs in a third time, gives up and calls the front desk. Both patients counted toward MAU three times. Journey A is success. Journey B is failure in slow motion. The metric that separates them: tasks completed per session. If a portal's tasks-per-session is trending up, that's good. If sessions-per-task is trending up, that's bad — patients are working harder for the same outcome. ### Metric 4: Off-ramp tracking Every patient portal has off-ramps: phone calls to the front desk, walk-ins, faxes, secure messages with simple questions, third-party booking tools. These are the things the portal was meant to replace — and they're the actual measure of the portal's success. If your patient portal MAU doubled but front-desk call volume stayed flat, the portal didn't replace the phone. It added to it. That's a different kind of failure than "low adoption." Tracking off-ramps requires cooperation with operational teams (and sometimes a small change to their phone or scheduling systems to capture reason codes). The teams that do this get unmistakable signal about what the portal isn't doing for patients yet. > The portal is winning when the phone is quieter. Not when MAU goes up. ### The conversion funnel that matters When we work on portal adoption, we instrument this funnel explicitly: - Notified — patient received the signup invitation (email, text, post-visit handout). - Started — clicked through to begin signup. - Verified — completed identity verification. - First task — completed the first action they came to do. - Returning — came back within 7 days for any reason. - Repeat task — completed a second meaningful task. The biggest drop-off is usually Notified → Started (typically 70-85% loss). The second biggest is Verified → First task (typically 30-50% loss). If you can fix either of these, adoption moves a lot. ### What to fix first If we had to recommend one thing to fix in a typical portal: redesign the post-verification landing page around intent. Most portals dump verified patients onto a generic dashboard with 12 menu items. They should land on the thing they came to do. If we had to recommend a second thing: shorten identity verification. Every additional question loses 5-15% of patients. Most portals over-collect during verification because the EHR team wanted the data — not because the security model required it. Push back hard on this. If we had to recommend a third thing: instrument the off-ramps. You can't fix what you can't see, and most teams are flying blind on this dimension. ### Closing Patient portal adoption isn't a UI problem. It's an instrumentation problem. The teams that get to 60-80% know exactly what their patients are trying to do, where they drop off, and what they fall back to when the portal fails them. The teams stuck at 30-40% have a generic adoption funnel and a vague sense that "engagement is lower than we'd like." Measure the four things in this article and you'll move adoption regardless of what else you do. ## FDA's 2023 cybersecurity premarket guidance: what changed for SaMD teams URL: https://health.onix-systems.com/insights/cybersecurity-premarket-fda-2023 MedTech · 10 min · 2023-08-21 · Serhii Kholin, CEO The new guidance pushed cybersecurity from optional to mandatory in the submission package. Here's what your DHF needs to include now. In September 2023, FDA finalized the guidance Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. The previous guidance, from 2014, treated cybersecurity as a recommendation. The new guidance treats it as a documented submission requirement — and the documentation requirements are substantial. Since the final guidance dropped, we've shipped four SaMD submissions under it. Here's what actually changed, what teams consistently underestimate, and the structure of the cybersecurity portion of the submission package as it looks now. ### What actually changed The biggest change isn't any single requirement. It's that the cybersecurity submission is now an explicit, expected part of the package — with prescribed structure. Pre-2023, you could submit a Class II device with minimal cybersecurity documentation and most reviewers would let it through. Post-2023, that submission gets a deficiency letter. The four substantive new requirements: - Software Bill of Materials (SBOM) — required. - Threat model — required, with explicit consideration of cyber threats. - Vulnerability response plan — required, with defined update mechanism. - Secure update mechanism documentation — required. Each one is meaningful work. None of them are checkbox items. ### The SBOM requirement An SBOM is a machine-readable inventory of every software component in your device. FDA accepts both SPDX and CycloneDX formats. Sounds simple. Isn't. Three places teams trip up: First: SBOM has to cover everything, not just your code. Third-party libraries, operating system components, firmware blobs, hardware drivers. If a device runs on Linux, your SBOM has Linux kernel components in it. If you use a library that wraps OpenSSL, OpenSSL is in your SBOM. Second: SBOM is dynamic. Every time you change a dependency, the SBOM changes. FDA expects the SBOM in the submission to reflect the actual shipping version — which means SBOM generation needs to be part of your release process, not a one-time deliverable. Third: SBOM has to be analyzable. You can't just hand over a JSON file. You're expected to have analyzed it for known vulnerabilities (CVE matching) and to document the analysis. ### The threat model requirement FDA wants a documented threat model that considers cyber threats specifically — not just safety hazards. They expect you to enumerate threats, model attack paths, and document mitigations. We typically structure threat models around STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) per system component. For each threat, the document captures: likelihood, impact, current mitigation, residual risk. What FDA actually evaluates: whether the threat model is comprehensive (did you consider the obvious threats?) and whether the mitigations are real (is there code or documentation for each mitigation, or is the mitigation aspirational?). Common deficiency: a threat model that lists threats but doesn't trace mitigations back to specific software components or design controls. The traceability is what convinces a reviewer the threat model is operational and not aspirational. ### The vulnerability response plan Once your device is in the field, what happens when a vulnerability is discovered? FDA wants the plan documented. Specifically, they want: - How vulnerabilities are received (a documented intake — security@yourcompany.com works, but "call us" doesn't). - Severity assessment process and timelines. - Coordination with downstream operators (hospitals, clinics, distributors). - Patch development and validation process. - Patch deployment mechanism (this connects to the secure update mechanism, see below). - Communication plan — to operators, to FDA, to patients if applicable. The plan doesn't have to be elaborate. It has to be real, written, and verifiable. "We'll figure it out when a vuln drops" is a deficiency. ### The secure update mechanism FDA wants to see how a patch reaches your device, in production, after submission. They expect: - Cryptographic signature on every update package. - Validation that the device verifies the signature before applying the update. - Authenticated channel for update delivery (not just HTTPS — usually mutual TLS with a customer-managed PKI). - Documented rollback mechanism if an update fails. - Documented evidence that the update mechanism itself doesn't introduce a new attack vector. This is the hardest section for software-only SaMD teams that haven't shipped firmware before. The expectation that the device itself does signature verification is sometimes new to teams whose mental model of "updates" is push-a-new-build-to-the-app-store. ### What got harder Three things take meaningfully more work now: First: SBOM generation as part of CI. Most teams discover during the submission that they need to integrate SBOM generation (e.g., via Syft, CycloneDX-cli, or similar tools) into their build process. If this isn't already done, expect 2-3 weeks of work to set up and validate. Second: vulnerability monitoring against the SBOM. You can't just generate it and submit it. You need a process for continuously monitoring CVE feeds against your SBOM and triaging matches. We use OSV (Open Source Vulnerabilities) feeds plus custom logic for the device-specific components. Third: secure update documentation. Software-only teams without firmware experience often need help here. Expect 3-6 weeks of effort to design, document, and validate a secure update flow. ### What got easier One thing actually got easier: FDA now publishes much clearer expectations. Pre-2023, you'd submit cybersecurity content, get a deficiency letter, and have to guess what was expected. Post-2023, the guidance enumerates the expected sections, and review feedback is much more specific. We've found review cycles on cybersecurity content to be shorter under the new guidance than under the old one — once you know the structure. ### What most teams miss The single most common deficiency we see: vulnerability response plan that doesn't address how the patch reaches the device. Teams write a great intake-and-triage section, then trail off when it comes to deployment. Second most common: SBOM that lists components but doesn't include version pinning. "OpenSSL" isn't a component — "OpenSSL 3.1.4" is. The version is the entire point of the SBOM. Third most common: threat model written in isolation from the actual codebase. The threat model needs to reference specific software components and design controls. If it reads like a checklist disconnected from your code, reviewers notice. > The cybersecurity submission is not a separate workstream. It's a view into whether your engineering organization treats security as integrated, or as bolted-on at submission time. Reviewers can tell the difference. ### The submission package structure we use After four submissions under the new guidance, we structure the cybersecurity section consistently: - Section 1: Threat model (STRIDE-based, traceable to design controls) - Section 2: SBOM (CycloneDX format, version-pinned) - Section 3: Vulnerability assessment against SBOM (CVE matching results, triage decisions) - Section 4: Vulnerability response plan (intake, triage, patch, communicate) - Section 5: Secure update mechanism (signature verification, authenticated delivery, rollback) - Section 6: Security testing summary (penetration test results, fuzzing where applicable) - Section 7: Operator security documentation (what hospitals need to know to deploy securely) Each section averages 4-8 pages. The full cybersecurity package on a typical Class II submission runs 30-60 pages. Plan for 6-10 weeks of dedicated work to produce it the first time. Subsequent submissions are faster — most of the structure carries forward. ### Closing The 2023 final guidance moved cybersecurity from optional to integrated. The work is real — but it's also better-defined than it used to be. Teams that engineer cybersecurity into the SDLC from project start produce these submissions in stride. Teams that try to retrofit at submission time discover that the SBOM, threat model, and vulnerability response plan all reflect engineering practices that take months to operationalize. If you're starting a SaMD project today, build cybersecurity in from day one. Generate the SBOM in CI. Draft the threat model alongside the architecture. Stand up security@yourcompany.com before you ship. The submission becomes a documentation exercise, not a panic.