Best Pulmonology EHR Software in 2026: What the Off-the-Shelf Options Actually Miss

Why Pulmonology Breaks the Generic EHR Model

Most specialty EHR conversations start with a features list. I want to start with the data model, because that’s where the actual mismatch lives.

A pulmonary function test doesn’t produce one number. It produces a structured set: FEV1 (forced expiratory volume in one second), FVC (forced vital capacity), the FEV1/FVC ratio, total lung capacity, and DLCO (diffusing capacity), each with pre- and post-bronchodilator values, and each one meaningful only when trended against the patient’s prior tests.

A peer-reviewed analysis in the American Journal of Respiratory and Critical Care Medicine put a name to something pulmonologists already knew from experience: PFT data typically sits on an isolated lab server that was never interfaced to the EHR, and the obstacles are the ones you’d expect: interface cost, the IT hours to build it, and the fact that there’s still no single, coherent standard for which PFT data elements belong in the chart. So the results get scanned in as a PDF, or worse, retyped by a medical assistant from a printout. Either way, the trend line a pulmonologist needs to actually manage a COPD or ILD patient over years isn’t sitting in a structured field. It’s buried in a stack of static documents.

Home oxygen is the second structural mismatch, and it’s a documentation and reimbursement problem before it’s a clinical one. CMS requires a recent in-person evaluation, a qualifying oxygen saturation reading from an arterial blood gas or pulse oximetry test, and a completed Certificate of Medical Necessity before a home oxygen claim gets paid, per CMS’s own home-oxygen coverage guidance.

Most general EHRs have no dedicated CMN workflow. That means a front-desk or billing staffer is manually assembling a document packet outside the chart every time a patient needs oxygen renewed, and if one element is missing when the DME supplier submits the claim, it comes back denied.

Sleep and CPAP data is the third mismatch. A clean prior-auth submission for a CPAP device needs the physician order, the sleep study results, the ICD-10-CM diagnosis (typically G47.33 for obstructive sleep apnea), the AHI/RDI/PLM scoring data, the physician’s interpretation notes, and the specific device model, all living in the same encounter, not scattered across a sleep lab’s separate system and a DME supplier’s portal. HCPCS code E0601 governs CPAP device billing specifically, and the documentation packet has to satisfy every LCD-mandated element before the claim goes out clean. Once a patient’s on therapy, ongoing CPAP compliance tracking (hours of nightly use, mask-seal data) is what payers check before authorizing a device replacement, and that data typically lives in a manufacturer’s cloud dashboard, the EHR never touches.

Stack those three gaps up and you get the actual pulmonology EHR requirement list: structured, trendable PFT capture; a built-in DME/CMN documentation workflow; and a sleep-and-CPAP data bridge that doesn’t depend on a staffer copying numbers between systems. Almost nothing on the market handles all three natively.

What a Pulmonology EHR Actually Needs to Include

Before a single demo, here’s the checklist I’d hand a practice administrator.

1. Structured PFT capture with automatic trending. Real-time import of FEV1, FVC, FEV1/FVC, TLC, and DLCO from the pulmonary function lab, not manual entry, with automatic flagging when a value crosses a clinically meaningful threshold from the prior test.

2. A built-in Certificate of Medical Necessity workflow. The oxygen saturation reading, the in-person evaluation date, and the CMN itself generated from data already in the chart, not assembled by hand outside it.

3. Sleep study and CPAP data in one encounter. Order, AHI/RDI/PLM scoring, physician interpretation, and device compliance data (nightly hours, mask seal) visible on the same patient timeline, not split across a sleep lab portal and a manufacturer dashboard.

4. Imaging and radiology handoff without a second login. A single-click order-to-review path for chest imaging tied to the respiratory workup, since bronchoscopy and imaging findings drive the next clinical decision immediately.

5. Asthma/COPD action plans with adherence tracking. Structured, patient-facing care plans that a patient can actually follow, not a printed handout that gets lost.

6. Audit-ready documentation for controlled respiratory medications and Prior Auth. Biologics (like Dupilumab) and certain inhaler classes increasingly require prior authorization; the system needs a documented, trackable Prior Auth status, not a fax-and-hope process.

Where Epic, Cerner, and Athena Actually Stand in 2026

Every “best pulmonology EHR” list on page one right now is a SaaS review aggregator (EMRFinder, EMRSystems, EHR Source, and similar sites) recycling the same three or four enterprise names. None of them tell you honestly where those platforms fall short, so here’s the version I’d give a practice administrator on a call.

Epic runs the largest respiratory-specialty install base among academic and large health systems. Its strength is genuine: if your hospital already runs Epic across cardiology, radiology, and the ED, a pulmonology service line on the same instance gets real interoperability benefits, one chart, one MyChart portal, one set of audit logs. The gap is that Epic’s pulmonary-specific templates weren’t purpose-built around structured PFT trending or a native CMN workflow; both typically require build-out through Epic’s own configuration process, which means budget and a project timeline before the gap actually closes (verify current module scope at your Epic tier before assuming it’s included).

Cerner, now Oracle Health, has a respiratory-specific template set and a real install base in large health systems, but its interoperability layer still leans on older HL7 v2.5 interfaces in a lot of production environments even as FHIR support expands, and billing integration for DME and Prior Auth workflows tends to be handled through bolt-on modules or third-party bridges rather than natively (verify current FHIR maturity at your specific Cerner/Oracle Health version, since this is a fast-moving area for the platform).

athenahealth (athenaOne) is cloud-native and genuinely strong on billing and patient engagement, which is exactly why it shows up so often in general specialty EHR shortlists. Its template library, though, was built around primary care and general specialty workflows first. Respiratory-specific data capture, PFT trending especially, usually needs a third-party bridge or manual workaround rather than a native field.

Two more names worth knowing exist because they surface in respiratory-specific searches: Greenway Health (PrimeSuite) offers ambulatory clinical and financial workflows with configurable specialty templates, and ChartLogic bundles EHR, practice management, and e-prescribing for ambulatory practices. Both can be configured toward respiratory workflows, but neither ships a pulmonology-native PFT or CMN module out of the box (verify current specialty-module scope directly with either vendor before shortlisting).

The honest read: every one of these platforms can run a pulmonology practice. None of them were built starting from a spirometer. That’s the gap a custom build closes, and it’s also the gap that makes off-the-shelf viable for a lot of practices that don’t need it closed badly enough to justify a build.

When Building Custom Actually Pencils Out

Not every pulmonology group should build. Most shouldn’t. But the math changes once a specific set of conditions line up, and I want to walk through it honestly rather than push a build recommendation on a practice that doesn’t need one.

We built a full custom, AI-first EHR for a precision-medicine practice running a functional and longevity-focused care model, on Medplum with a FHIR-native data layer, deployed in under 90 days. The build cut provider documentation time by 70% through an ambient scribe tuned to the practice’s own clinical vocabulary, cut post-visit task delays by 60% through automated follow-up scheduling, and lifted patient engagement 50% through an AI-driven patient assistant, with a 30% improvement in care-coordination turnaround on referrals.

The mechanism that matters for a pulmonology group specifically: because the FHIR data model was built from scratch, PFT values, sleep study results, and CPAP compliance data all live as structured, queryable fields from day one, not workarounds bolted onto someone else’s schema.

On the other end of the scale, we built a full national-scale EHR platform for a Caribbean nation’s health ministry, standing up clinical infrastructure across its public hospital network on open-source foundations, an engagement in the low six figures. That’s not a pulmonology build specifically, but it’s the proof point that matters here: if a government can systematize clinical workflows at country scale on this same architecture, a 50-bed respiratory hospital or an 8-clinic pulmonology group is a smaller, faster, and cheaper problem to solve.

The decision rule I actually use with a practice: custom makes sense when you’re running 3 or more respiratory-focused clinics (multi-site standardization is where the economics turn), when PFT and DME documentation are central to daily workflow rather than occasional, when your current system forces staff into manual CMN assembly or dual-screen imaging review every day, and when you can absorb an 18 to 24 month ROI horizon in exchange for a 90 to 150 day build instead of a 6 to 12 month enterprise implementation.

If none of that describes your practice, don’t let anyone, including me, talk you into a custom build you don’t need. A well-configured Epic, Athena, or Cerner instance with the gaps above understood going in is the right call for a lot of respiratory practices. For the ones where it isn’t, custom EHR development is the actual conversation to have, not a vendor pick.

The Real Cost and Timeline Math

Sticker price is the wrong first number to compare. Total cost of ownership and time to go-live tell the real story.

A custom Medplum-based build for a pulmonology group typically runs $200,000 to $600,000 depending on scope (basic clinical module versus a full EHR replacement), deployable in 90 to 150 days. Add $20,000 to $50,000 for legacy data migration, $10,000 to $25,000 for staff training, and $2,000 to $5,000 a month for cloud hosting. All-in 12-month cost of ownership lands around $400,000 to $850,000, with an 18 to 24 month ROI payback driven by reduced charting time, faster billing cycles, and fewer denied DME claims.

Off-the-shelf implementation on Epic, Cerner, or Athena typically runs $150,000 to $500,000 in year-one licensing and implementation, over a 6 to 12 month go-live timeline. Hidden costs stack up here too: workaround training for the gaps above, template customization labor, and an annual license renewal of $50,000 to $150,000 that keeps recurring.

All-in 12-month TCO usually lands in a similar $300,000 to $750,000 range, but the ROI payback stretches to 24 to 36 months, in part because the vendor’s own roadmap, not yours, decides when a respiratory-specific gap actually gets closed (verify current licensing tiers directly with each vendor at time of evaluation, since pricing shifts by bundle and practice size).

The number that should actually drive the decision isn’t total cost, since both paths land in a broadly similar range. It’s speed to a working system that fits your workflow, and who controls the roadmap for closing the remaining gaps once you’re live.

I almost wrote “custom is cheaper” in an earlier pass of this section. It isn’t, not reliably. The honest comparison is that custom and off-the-shelf land in the same cost neighborhood over 12 months; the real difference is where the money goes and who decides what gets fixed next.

What CMS-0062-P and USCDI v3 Change for Pulmonology Specifically

Two federal moves matter for anyone evaluating a pulmonology EHR in 2026, and both push in the same direction: toward FHIR-native systems that can adapt fast, and away from systems still waiting on their vendor’s roadmap.

CMS-0062-P requires health plans and providers to exchange prior authorization requests through FHIR APIs instead of fax or phone. For pulmonology specifically, that covers inhalers, biologics like Dupilumab, home oxygen, and sleep study equipment, all categories that regularly hit Prior Auth. A system with a native FHIR layer can automate that handshake, and our broader look at FHIR-based Prior Auth APIs covers the mechanics in more depth than fits here. A system still running older interface standards inherits the lag (verify your specific platform’s current compliance timeline before assuming coverage).

ONC’s USCDI v3 standardizes the clinical data elements every certified EHR has to export via FHIR, including imaging referrals, lab results, and vitals. For a pulmonology practice, that means the handoff from respiratory to radiology to cardiology should happen at API speed rather than manual entry, once vendors finish implementing to spec. A FHIR-native custom build starts from that standard. A legacy platform has to retrofit toward it.

Neither of these is a hypothetical future requirement. They’re active in 2026, and the gap between “our vendor is working on it” and a FHIR-native system that’s already there is a real operational difference, not a marketing point.