Healthcare practice
Healthcare software, shipped to hospitals, since 2018.
FHIR-R4-conformant integrations. HIPAA-ready infrastructure. SOC2 Type II. A named engineering principal owns every engagement and signs the SOW. We have built clinical decision support, lab-integration backends, and patient-facing platforms for hospitals on three continents.
Compliance posture
Half the security questionnaire is already answered here.
Procurement teams scan this section first. We surface it first. Each posture below is a single declarative statement; the linked public documentation carries the audit-grade detail. Where the documentation is under NDA, the discovery call is the path.
- SOC2 Type II
- Annual audit by [Auditor Name]; current report dated [YYYY-MM]. Available under NDA in the discovery call.
- HIPAA-ready
- Business Associate Agreements signed with all hosted-PHI clients. Encryption at rest (AES-256) and in transit (TLS 1.3). Key rotation policy: 90 days.
- FHIR R4 conformant
- Integrations against Epic, Cerner, and Allscripts gateways. Public conformance statement at /compliance/fhir-conformance once published.
- Clinical workflow grounded
- Every healthcare engagement includes a clinical advisor on the build team. We do not ship UI to nurses or physicians without their input on the workflow.
Named product · Kimera
Kimera is the clinical decision-support platform we built first and the one we evolve most.
Kimera began in 2018 as a single-hospital pilot at [Memorial Health], surfacing antibiotic-stewardship recommendations to attending physicians at point of order entry. The original requirement was modest: pull the patient’s current culture results, cross-reference the hospital’s antibiogram, suggest a narrower-spectrum alternative when the data supported one. The harder requirement, the one that took longer than the engineering, was building enough trust that the physician would read the recommendation rather than dismissing the modal.
Eight years later, Kimera is in production at eleven hospitals across the United States, Canada, and one large network in [Singapore]. The platform now covers oncology dose adjustments, sepsis surveillance, and the post-surgical re-admission risk score that several of our client systems built into their discharge workflow. The engineering team is eight people: three full-stack, two infrastructure, one ML, one clinical, one site-reliability. Dr. [Principal Name] has been the engineering principal on Kimera since the original pilot and continues to sign the SOW for every new hospital onboarding.
We are deliberate about what Kimera is not. It is not a black-box AI product. Every recommendation Kimera surfaces is traceable to a specific piece of evidence in the patient’s record, a specific protocol in the hospital’s clinical library, and a specific model version with a published evaluation. When a clinician overrides a recommendation, the override is captured and feeds into the next quarter’s model retraining. Kimera ships behind the EHR, not in front of it.
Engineering approach
We integrate with the EHR. We do not replace it.
The stack is opinionated and earns its opinions case-by-case. Next.js 14 on the application tier because the hospitals that buy our software send us their CTO before they send us their security officer; the developer experience matters as much as the runtime. The clinical-workflow services run on Python 3.12 with FastAPI for the FHIR-facing endpoints and SQLAlchemy 2.0 over PostgreSQL with row-level security policies per-tenant.
FHIR integrations live in their own adapter package, one module per major EHR family (Epic, Cerner, Allscripts, Athenahealth, the older Meditech installs we still see). Each adapter conforms to the same internal interface; the differences between EHRs land in the adapter layer, not in the application code. We have shipped enough of these now that an adapter for a new hospital’s EHR is two to four engineer-weeks of work, not a quarter-long project.
On-call posture is a real commitment, not a contractual gesture. Every healthcare engagement carries a 24/7 on-call rotation with at most a four-engineer roster (so context is preserved across the rotation) and a six-minute initial-response SLA on Sev-1 pages. The on-call runbook is co-authored with the client’s SRE team during the integration phase and updated quarterly as the deployment evolves.
We sign Business Associate Agreements with every client that processes Protected Health Information through systems we operate. PHI never sits in a development environment. The synthetic patient generator that drives our integration tests is open-source and well-fuzzed; clinicians on our team review the generated cases for medical plausibility before they enter the test corpus.
Where we explicitly do not ship: front-line clinical UI without a physician on the build team; clinical decision support without a published evaluation methodology and a model version that can be pinned to a specific recommendation in production; and any system that depends on a vendor SDK we cannot replace within ninety days.
Case study · [Memorial Health]
A multi-site antibiotic-stewardship rollout that earned its place at the order-entry screen.
In the second half of 2022, [Memorial Health] approached us with a clear ask: their existing stewardship pop-up was being dismissed 87% of the time without being read, and the infectious-diseases service line had data showing the dismissals correlated with the same six prescribers across two hospitals. The system needed to surface the recommendation in a way that physicians would engage with, not a way that drove them to muscle-memory dismiss.
Our intervention was deliberately small. We did not replace the EHR pop-up. We replaced the content of the pop-up: instead of a generic “consider narrower-spectrum” line, the recommendation now opened with the specific susceptibility result from the current culture, named the alternative agent, and showed the cost differential per dose. The model surfacing the recommendation was unchanged in its underlying logic; the surfacing was rebuilt around what a busy physician at 3am would actually read.
Eighteen months after rollout across all three hospital sites, the dismissal-without-read rate is 41%, down from 87%. Defined-daily-dose of broad-spectrum agents has fallen 22% across the system. The infectious-diseases service line continues to own the clinical content; NEXLESS owns the surfacing engine, the FHIR adapter, the model-evaluation pipeline, and the 24/7 on-call.
- Client
- [Memorial Health], 3-hospital network
- Engagement
- 18 months, ongoing on-call retainer
- Principal
- Dr. [Principal Name]
- Stack
- Next.js, FastAPI, PostgreSQL, FHIR R4 (Epic), Datadog
Healthcare engineering principal
Dr. [Principal Name]
Engineering Principal, Healthcare · NEXLESS
Fifteen years building production software for hospitals. Trained originally as a clinician; published on FHIR integration patterns in the JAMIA. Has been the engineering principal on Kimera since the original 2018 pilot and has signed every Kimera SOW since. Owns the engagement end-to-end: scope, architecture, the people who write the code, the on-call rotation, the SOC2 evidence collection. Is the person who shows up to the hospital’s quarterly business review.
Book 30 min with Dr. [Principal Name]The booking page is a real Calendly URL on the principal’s actual calendar. There is no SDR routing layer; you are booking time directly with the engineering principal who would own your engagement.