The AI Cardiologists Trust With Patients' Hearts

A DICOM file arrives from one device manufacturer with the ECG amplitudes encoded in microvolts. A second file, equally compliant with the same standard, arrives from another manufacturer carrying the same physical signal in millivolts. Neither file is malformed, so nothing throws and no alarm fires. Absorb that difference in the ingestion layer and the platform is genuinely vendor-neutral; miss it and the platform hands a cardiologist a number that is wrong by three orders of magnitude and looks entirely right.

That class of problem is what HeartSciences needed solved: a cloud backend for MyoVista Insights — their vendor-neutral ECG management platform — that could ingest studies from multiple device manufacturers, run AI inference across multiple model providers, participate bidirectionally in hospital clinical workflows over HL7 and FHIR, and satisfy medical-device regulatory requirements in two jurisdictions at once. ML LABS engineered the platform's backend — a medical-device cloud platform that reached clinical production in two countries. AIM Consulting built the frontend interface, and running two vendors in parallel gave HeartSciences throughput and shared risk across workstreams; AIM was a strong collaborator, responsive and easy to coordinate with. The architecture, the cloud-native backend, and the technical decisions across infrastructure, AI inference, EHR integration, and security were ML LABS' to make and to own.

Building a medical-device backend is not a normal software project, because every design decision carries regulatory weight — the guiding principles for good machine learning practice in medical devices (FDA, 2021) treat data management, model design, and deployment monitoring as design inputs, not as engineering preferences — and the distance between a working prototype and a system a regulator will accept is where the engineering actually lives. The interoperability surface is what makes it compounding rather than merely strict: a systematic scoping review of FHIR-based EHR implementations (JMIR Medical Informatics, 2024) catalogs five recurring failure categories across the field — manual ETL with information loss, hard-coded mappings that drift, semantic misalignment between systems, performance ceilings under real traffic, and scalability gaps when a new tenant onboards. Every one of those failures degrades a clinical workflow before anyone notices in production, which is a different and worse property than failing loudly.

graph LR
    A1["Multi-Vendor<br/>ECG Devices"] --> B1["DICOM<br/>Normalization"]
    B1 --> C1["Async AI<br/>Inference"]
    C1 --> D1["Clinical Report<br/>Workflow"]
    D1 --> E1["Bidirectional<br/>EHR Delivery"]

    style A1 fill:#1a1a2e,stroke:#0f3460,color:#fff
    style B1 fill:#1a1a2e,stroke:#ffd700,color:#fff
    style C1 fill:#1a1a2e,stroke:#ffd700,color:#fff
    style D1 fill:#1a1a2e,stroke:#e94560,color:#fff
    style E1 fill:#1a1a2e,stroke:#16c79a,color:#fff

Absorb Vendor Quirks Before Inference

Vendor neutrality is a claim about the parsing layer, not a claim about the marketing page. The DICOM Supplement 30 Waveform Interchange specification (NEMA) permits up to five Waveform Sequence Items per study across up to thirteen channels, and it deliberately leaves room for vendor-specific encoding choices — which means two fully compliant files from two manufacturers can describe the same heartbeat with different scalar units, different lead labels, and different acquisition templates. The failure modes the normalization layer absorbs are exactly that concrete: lead-order permutations that silently swap V1 and V4, amplitude scaling in microvolts on one device and millivolts on another, and measurement segments reporting Q-onset relative to either the start of the waveform or the start of the QRS complex.

The normalization layer ML LABS built extracts waveform data and clinical measurements out of each vendor's DICOM dialect into one unified internal representation, then validates the result against expected physiological ranges before the AI inference step is allowed to run. Duplicate submissions are recognized by waveform fingerprint and linked rather than re-stored, so a clinic that uploads the same study through two pathways does not pay twice or read two answers. The full ingestion pipeline for multi-vendor ECG data and the path from clinic capture to cloud carry that quirk catalogue in full — the part no specification will hand you.

Every device vendor encodes clinical data differently. Getting this wrong does not produce an error message. It produces a clinically incorrect value that looks right. The platform that handles this correctly becomes the one clinicians trust.

Multiple Providers, One Ledger

The AI layer runs studies through multiple AI model providers — rhythm analysis and cardiac function models for ejection fraction assessment among them — and each provider has its own latency behavior, its own availability pattern, and its own billing consequence. The signals that decide whether that layer is working in clinical production are not the aggregate accuracy numbers on a model vendor's data sheet. They are per-provider tail latency at the 95th and 99th percentile, retry rates broken down by failure class (network, malformed response, model error), and the share of studies where two providers disagree on a clinically actionable finding.

ML LABS built an async inference architecture that decouples ECG submission from AI result delivery, absorbs provider unavailability without dropping work, and supports per-organization model enablement so an algorithm can be rolled out to one organization before the rest. Adding a new AI model provider is a configuration task rather than an engineering project. Each inference request carries an idempotency key, so a retry after a provider timeout can never produce a second billable result for the same ECG, and reconciliation jobs catch any provider invoice that disagrees with the platform's own ledger before it reaches a customer — the discipline behind the usage-based billing system and the inference reliability pipeline that sit underneath.

The design property worth more than any of those metrics is this: every record reaches a definite terminal state, and that state is queryable. A study is not "probably fine" or "still processing since Tuesday" — it is in a state a query can name, which is what makes reconciliation a query instead of a heroic act. Note what this section does not contain. HeartSciences' study volumes, their measured inference latencies, and their production availability are the client's operational data, and ML LABS will not publish them to make a case study look more impressive. The architecture and the decisions behind it are ours, and they are the part a buyer is actually purchasing.

Enter The Clinical Order Loop

EHR integration means participating in the clinical order workflow, not merely reading patient demographics out of it. The platform receives an order message when a physician requests an ECG interpretation, processes the study through inference, and returns a result message carrying clinical measurements and the billing codes downstream hospital systems depend on for reimbursement — which means a malformed result message is not a logging problem, it is an unpaid claim and a clinician who never learns the answer came back. The HL7 result-delivery system is where that lives, and the reason it externalizes every site-specific value is that the standard itself refuses to decide: an analysis of HL7 v2 optionality (JAMIA, 2009) counted 4,132 data elements in the standard result message with 85% of them designated optional, which is why two hospitals working from the same specification produce messages that look alike and still reject each other's payloads.

On the FHIR side the platform implements per-organization authentication that prevents cross-tenant data access, and it uses the SMART App Launch specification (HL7 FHIR, 2024) for launch context so a clinician opens the right study for the right patient from inside their own EHR. Splitting the protocols this way — HL7 for the clinical order workflow, FHIR for data access and launch — is how EHR and FHIR integration actually behaves in production, and the sandbox scarcity that makes this work slow is why ML LABS also built a full EHR integration simulator rather than waiting on a vendor's test window.

Clinical reports are signed, confirmed, and locked through a lifecycle carrying legal and regulatory weight, so the report workflow enforces accountability at each stage and tracks every post-signature modification with a full audit trail. Security was remediated inside the delivery cadence rather than deferred to a hardening phase at the end: rotating secrets and least-privilege IAM, PHI kept out of logs and error responses and debug output, input validation across every externally reachable API surface, and per-organization session isolation with no fallback authentication path. The FDA's guidance on cybersecurity in medical devices (FDA, 2025) treats this as a design input rather than a release checklist, and the clinic-side security pipeline was built on the same assumption.

Onboarding Is Configuration, Never Code

The single most consequential decision on this platform was made before it had a second customer: it was designed from the start so that onboarding a new organization is configuration, never code. That is not a refactor anyone was heroic about later — there is no before-and-after here, because the multi-tenant seam was drawn at the beginning. Concretely, a new organization is defined by its HL7 field mappings, its enabled AI models, its invoice pricing, and its storage provisioning, and each of those is a configuration surface rather than a branch in the codebase.

The consequence is that HeartSciences adds hospitals, device vendors, and AI model providers by configuring them, not by commissioning engineering projects — and that the same codebase serves test, US production, and UK production as separate environments with data residency separation built into the infrastructure rather than bolted onto it. MyoVista Insights runs today as HeartSciences' core product across multiple healthcare organizations in US and UK production, giving clinicians one view of ECGs, AI results, and prior studies inside their own EHR, natural-language search over the clinical worklist instead of a filter interface with dozens of fields, and a research SDK for querying and exporting across every ingested format. That search layer is also the clearest case for why integrated search beats an off-the-shelf chatbot when the corpus is a live operational system.

Omar did outstanding work designing and building the backend for our cloud-native AI-ECG platform. I recommend him to any organization needing a skilled and reliable engineering partner.

— Jason Domask, Director of Software Engineering, HeartSciences

HeartSciences is an ongoing ML LABS engineering retainer client. The work delivered under that retainer includes the clinical billing automation system and the multi-site clinical operations automation — which is what delivery-then-ownership looks like when it is a history rather than a proposal.

When This Architecture Is Overbuilt

Configuration-first multi-tenancy is front-loaded, and front-loaded cost is real cost. Drawing the seams at the beginning means paying design time — modeling the per-organization surface, refusing to let site-specific values leak into the codebase, building validation that fails loudly when a required mapping is absent — before a single additional customer exists to justify it. In a domain with one device vendor, one model, one jurisdiction, and one billing scheme, that is a tax on variability that will never arrive, and the honest recommendation is to skip it.

The test is not ambition, it is the count of axes that are genuinely open. Device format, model provider, regulatory jurisdiction, billing scheme, identity provider: each axis that can plausibly gain a second value is a configuration surface you will otherwise discover as a migration, and each one discovered late in a clinical system is discovered inside a change-control process — the FDA now expects anticipated model changes to be declared and bounded in advance (FDA, 2025), which rewards the architecture that planned for variation and punishes the one that did not. Regulated builds concentrate this decision hardest, which is why how AI execution works in regulated systems is worth reading before the schema is written.

First Steps

1. Enumerate the open axes before the schema. List every dimension that can plausibly take a second value — device vendor, model provider, jurisdiction, billing scheme — and decide, on paper, which become configuration surfaces and which stay hard-coded.
2. Write the terminal-state list before the happy path. Name every end state a record may reach, then make each one queryable. If an engineer cannot answer "where is study X and why" with one query, the reconciliation burden is already being paid by an operator.
3. Instrument the tail, not the average. Per-provider p95 and p99 latency, retry counts split by failure class, and cross-provider disagreement on actionable findings tell you what an aggregate accuracy figure structurally cannot.

Design The Seams First

The microvolt file and the millivolt file are the whole argument. On this platform the hard part was never the model — it was the seams: vendor formats that are all standards-compliant and mutually incompatible, model providers that fail in different ways from each other, an EHR that expects standards-compliant messaging and enforces its own dialect of it, a second country that arrives with its own residency rules. Seams are cheap to design and expensive to retrofit, and in a clinical system a retrofit is a change-control event rather than a routine deploy.

So build the normalization, the idempotency, the terminal states, and the per-organization configuration surface while they are still design decisions, and the result is a platform that grows by configuration instead of by engineering project. When crossing systems is the hard part of what you are building, that is an AI system integration engagement — and it ships with its first 60 days of Operate included, because a live system tells you where its seams are unhappy long before a dashboard does. Get the seams right and the compliant-but-incompatible file becomes a solved problem you never think about again, which is precisely what a clinician trusting the number on their screen is entitled to.

References

1. NEMA. DICOM Supplement 30: Waveform Interchange. DICOM Standard, 2024.
2. Tabari, P., Costagliola, G., De Rosa, M., Boeker, M. State-of-the-Art FHIR-Based Data Model and Structure Implementations: Systematic Scoping Review. JMIR Medical Informatics, 2024.
3. HL7 International. SMART App Launch Implementation Guide. HL7 FHIR, 2024.
4. U.S. Food and Drug Administration. Cybersecurity in Medical Devices. Regulatory Reference, 2025.
5. Sujansky WV, Overhage JM, Chang S, Frohlich J, Faus SA. The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems. Journal of the American Medical Informatics Association, 2009.
6. U.S. Food and Drug Administration, Health Canada, and MHRA. Good Machine Learning Practice for Medical Device Development: Guiding Principles. Regulatory Reference, 2021.
7. U.S. Food and Drug Administration. Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices. Regulatory Reference, 2025.