EMR Integration Isn't Enough: Why Molecular Genetics Labs Need Fast Middleware

Most conversations about laboratory software start in the wrong place. Lab directors and pathologists (where there are any) are usually asked the same question — "Doesn't your EMR already do that?" — and the honest answer is always much the same: yes, partly, slowly, and rarely where it actually counts.

A peer-reviewed study published earlier this year in the Journal of Medical Internet Research set out to quantify what happens when EMR systems are properly connected across care settings. The findings are striking, and for anyone running a molecular genetics or pathology lab they make the case for a different conversation entirely. The question is not really whether to have an EMR or not — most labs already do — but whether that EMR can realistically handle the dynamic, ever-shifting workflows that define a modern laboratory. In our experience, it simply cannot do it alone. It needs something more alongside it: a fast, customisable middleware layer that handles the parts the EMR was never designed to handle.

This post breaks down what that research showed, why those findings matter even more for labs than they did for the primary-to-specialist setting studied, and what "fast middleware" actually looks like when implemented for molecular pathology workflows. And for the labs that are finally moving onto a newer EMR after years of putting it off, there is a question worth pausing on, before the ink dries on the contract: does the system you are committing to actually provide the workflow customisation and lab management you will need a year from now, or three years, or five?

What the 2025 research proved

The JMIR study, published in April 2025, is among the first pieces of empirical evidence quantifying the operational benefits of EMR integration between primary care and specialist care institutions. Over a 12-month window before-and-after EMR integration, the research team measured outcomes across three dimensions: patient diagnosis tracking, patient care management, and patient coordination.

The numbers are not subtle:

• Specialist wait times fell by an average of 16.5 days — from 34.65 days down to 21.03 days, a 48% reduction in how long a referred patient waited to be seen (P < .001)
• Repeated procedures dropped significantly (P = .006)
• Repeat radiographies decreased (P = .02)
• Overall bill sizes fell by between 4.08% and 39.7% (P = .004)
• Clinical outcomes stayed essentially the same (P = .37)

That last finding is the most important one. The savings did not come from cutting corners on care; they came from eliminating waste, duplication, and the friction caused by disconnected systems. When clinicians could see what other clinicians had already done, they stopped reordering tests, stopped repeating procedures, and stopped chasing information that already existed somewhere in the system.

The paper frames this around a concept it calls the "medical neighbourhood" — a set of policies and integrated systems that support joint patient management across primary care, specialist care, and the rest of the healthcare ecosystem. It is a useful term, because it reframes the entire question. The goal is not to have one big system that does everything; the goal is to have connected systems that talk to each other reliably.

For anyone who has sat through a vendor pitch promising to replace everything with one unified platform, this distinction is important. The truth, as labs eventually discover, is that one application rarely covers every workflow well, and the cost of trying to make it do so is usually paid in flexibility, speed, and the patience of the staff who have to use it every day.

Why these findings apply even more strongly to labs

The JMIR study focused on the primary-to-specialist care interface. Molecular genetics and pathology labs sit further downstream than that, and the integration gap there is wider still.

Consider what happens in a typical molecular pathology case:

• A clinician orders a panel through the hospital EMR
• The order arrives at the lab — sometimes via HL7, sometimes via PDF, sometimes via a printed requisition, sometimes via email
• The sample is received, accessioned, and routed through extraction, library preparation, sequencing, bioinformatics, variant calling, ACMG curation, and multi-tier review
• A final report is signed out and returned to the EMR
• The clinician acts on the result

The EMR is involved at step 1 and step 4. Everything in between — the actual lab work — happens in a place the EMR cannot see, cannot manage, and cannot drive. This is not a criticism of EMRs. They were built for clinician-patient encounters, not for batch-based, multi-stage analytical pipelines with QC checkpoints, multi-user role assignments, instrument handoffs, and variant curation. Expecting an EMR to manage a 14-step NGS workflow is a little like expecting a calendar application to manage a construction project; the data model was simply not designed for it.

And even where an EMR could be made to accommodate some of these steps, the real issue is the speed of change. Imagine adding a new QC checkpoint, or revising a sign-out checklist, and then waiting on the EMR vendor's roadmap to action that request. The EMRs that labs work with day-to-day are reliable, accredited systems for storing and securing data, and that is genuinely valuable. They simply do not have the flexibility — or the iteration speed — required to keep up with the way modern laboratory workflows evolve.

The JMIR research found that connecting EMRs to other EMRs eliminated waste. The equivalent move for labs is not to replace the EMR, nor to bolt more features onto it, but to give the lab its own purpose-built workflow layer that connects to the EMR. A workflow layer that handles the parts the EMR was never meant to handle, while feeding the EMR the data it needs at the right moments. For a fuller breakdown of this argument from the case-management angle, see our earlier post on why pathology labs need dedicated case management.

That layer is what we mean when we talk about lab middleware. In simple terms, lab middleware is a lightweight, lab-centric workflow platform that sits between an EMR or LIS and the day-to-day operations of the laboratory — handling case management, sample tracking, variant curation, audit logging, and reporting, while pushing finalised results back to the EMR.

Where EMRs end and middleware begins

EMRs do four things very well:

• Document patient encounters and longitudinal medical history
• Manage prescriptions, allergies, and immunisations
• Generate clinical letters and discharge summaries
• Provide the system of record for billing and care continuity

EMRs are not built to do the following, and forcing them to ends badly:

• Track samples through multi-stage analytical pipelines
• Manage batch processing across instruments and runs
• Capture and version structured panel definitions and gene lists
• Drive multi-reviewer curation workflows with audit trails on every classification decision
• Handle the cross-references between cases, samples, variants, runs, panels, and family relationships
• Triage and reassign work in real-time across a lab team
• Produce lab-specific KPIs such as turnaround time by panel, diagnostic yield by indication, or coverage QC by run

When labs try to make their EMR do these things, one of two outcomes generally follows. Either the EMR vendor quotes a six-figure customisation project that takes 12 to 18 months and produces a clunky bolt-on nobody actually uses, or the lab gives up and falls back to spreadsheets, shared drives, and email. Both outcomes leave the lab roughly where it started, with no audit trail, no real-time visibility, and no scalable workflow.

The middleware approach sidesteps both of these failure modes. Rather than bending the EMR into something it was not designed to be, a thin, fast, lab-centric layer is placed between the EMR and the bench. The EMR continues to do what it does well. The middleware does what the EMR cannot.

What fast middleware means for labs

The word middleware gets used loosely. In the lab context, fast middleware refers to a workflow platform with a few specific properties.

It is lab-centric, not patient-centric. The data model is built around cases, samples, panels, runs, variants, and family relationships, rather than encounters and visits. This sounds like a minor distinction; it is not. It determines whether the system can actually represent the unit of work a molecular lab is doing on any given day.

It is lightweight to deploy. Implementations are measured in weeks, not quarters. There is no twelve-month consulting engagement before the system can be used in production. The architecture is web-based, with no heavy desktop installs, and the lab is able to adapt the configuration without a full-time admin or a long chain of vendor support tickets.

It connects rather than replaces. It accepts orders from the existing EMR or LIS via HL7, CSV import, API, or whatever interchange format is already in use, and pushes finalised results back into the EMR. It does not try to be the patient registry, the billing system, or the document of record. It does one thing — drive the lab workflow — and it does that one thing well. In doing so, it also captures the data needed for a layer of business intelligence and workload management that most labs currently piece together by hand.

It is configurable, not bespoke-rebuilt-for-each-change. Statuses, transitions, panel definitions, terminology, permissions, and report templates can all be adjusted without writing code. When a new gene panel goes live, the lab adds it. When a new pathology workflow is introduced, the lab configures it. The vendor does not need to be in the loop for routine changes.

It produces a complete audit trail by default. Every status change, every variant classification, every sign-out, and every panel version update is logged with user, timestamp, and context. This is the part that turns NATA audit preparation from a three-week scramble into a one-day exercise, and it is also the part EMRs structurally cannot do for lab workflows, because they cannot see the workflow happening in the first place.

A worked example: from EMR order to signed-out NGS report

The clearest way to see where middleware earns its keep is to walk through a real case. Consider a paediatric epilepsy panel.

The clinician orders the panel in the hospital EMR. The EMR sends an HL7 order message to the lab middleware. The middleware creates a case, parses the patient demographics, links the case to any prior cases on the same patient or family members, and slots the case into the appropriate workflow queue based on panel type and clinical priority.

The lab receives the sample, scans it in, and the middleware updates the case status. The sample moves through extraction, QC, library preparation, and sequencing, with each step captured against the case and the associated QC metrics attached. When the bioinformatics pipeline completes — most labs run this through their existing third-party variant calling and analysis tools — variants are loaded into the case and the case enters the Ready for Curation queue. A scientist picks it up, classifies the variants against ACMG criteria with ClinVar and gnomAD lookups, and submits the case for senior review. A senior scientist reviews and signs off. A pathologist completes the final sign-out.

The signed-out report is pushed back to the EMR as a finalised result. The clinician sees it and acts on it.

In that entire workflow, the EMR is involved at the first step (the order arriving) and the final step (the result returning). The middleware did everything in between, which is the part where lab work actually happens. The EMR did not have to be rebuilt. The lab did not have to manage anything in spreadsheets. And the audit trail captures every decision made along the way, automatically, with no manual logging required.

This is, in essence, what the JMIR researchers were pointing at, applied to the lab setting. Connected systems remove the friction. Each system does what it does best. The result is faster turnaround, less waste, and less stress at audit time, without compromising clinical quality.

How to evaluate lab middleware: five things to look for

The numbers from the JMIR study are hard to argue with, so the next practical question is what to actually look for in a middleware solution. Not every platform labelled as a "workflow platform" delivers the speed and fit that make this approach work, and there are a few things worth examining carefully.

The first is time to go-live. If a vendor cannot get the lab operational in weeks, the platform is too heavy. Six-to-twelve-month implementations tend to be a red flag that the system requires bespoke configuration the vendor controls, which generally means every future change will also cost six to twelve months.

The second is the cost and process around customisation. It is worth asking explicitly what it costs to add a new gene panel, a new status, a new report template, or a new test module. If any of those answers involve a formal quote and a project plan, the system is not configurable in the way that really matters.

The third is audit trail granularity. It is entirely reasonable to ask to see exactly what is logged, at what level of detail, and with what immutability guarantees. A NATA or ISO 15189 audit will ask the same question, and the lab needs to know the answer is yes, automatically before committing to a system.

The fourth is integration approach. The vendor should be comfortable with HL7, CSV import, API integration, and whatever else is in the existing stack. If they insist on owning the patient registry or replacing the EMR, the architecture has been misunderstood.

The fifth is data ownership and isolation. Each lab should get its own database and its own infrastructure. Multi-tenant SaaS, where data sits in shared tables alongside every other lab's data, is both a compliance liability and a data sovereignty concern, particularly in Australian and other jurisdictions with hard requirements on where patient data physically lives.

What the research really tells us

The JMIR study is important not because it discovered something surprising — anyone who has worked in a lab already suspected that disconnected systems waste time and money. It is important because it quantified the effect. Sixteen and a half days of specialist wait time saved per referral. Up to 39.7% reduction in unnecessary procedures. No reduction in clinical quality.

Those numbers came from connecting EMRs to other EMRs in a primary-to-specialist setting. For molecular pathology labs, where the gap between what the EMR can do and what the workflow actually requires is much wider, the potential gains from connecting the right systems together are likely to be larger still.

The takeaway here is not that EMRs are the problem. EMRs are essential, and they do what they do very well. The takeaway is that the answer to the EMR doesn't do what we need is rarely to ask the EMR to do more. The more sensible answer, in most labs we have worked with, is to give the lab its own fast, purpose-built layer, and to connect that layer to the EMR cleanly.

That is the middleware approach. That is what the research supports. And that is what we built CassianLab to deliver.