Software Development Trends

What are software development trends in healthcare?

Software development trends in healthcare are lasting changes in how clinical and administrative software is designed, secured, integrated and run. A trend belongs on a build plan when a regulation, a standard or a recurring workflow failure requires it, such as FHIR APIs under ONC certification or payer APIs under CMS-0057-F.

A trend compared with a tool

• Trend: Standards-based APIs, because certified EHRs and regulated payers must expose FHIR APIs.
• Trend: Governed AI, because federal civil rights rules and FDA guidance now speak directly to decision support tools.
• Trend: A documented secure development lifecycle, because medical device law and federal frameworks now expect evidence of it.
• Tool: A new JavaScript framework, a vector database or a low-code builder. Each may support a trend, but none is the trend.

How do you tell a trend from noise?

Run each candidate through a four-step filter before it becomes a line item. If it fails the first step, it goes on a watch list rather than the roadmap.

• 1. Name the driver: The regulation, standard, customer requirement or operational failure that makes the change necessary.
• 2. Map the workflow: Who uses it, which data it touches, which systems it connects and what a failure costs, such as a wrong chart entry, a denied claim or downtime.
• 3. Pilot with controls: One workflow, one site, one data set, with human review for AI, logging, a business associate agreement where PHI is involved, and a written exit test.
• 4. Adopt or retire: Give a passing trend a home in shared identity, APIs, monitoring and CI. Remove the code path of a pilot that missed its exit test.

The one-page decision record

• Trend: The name and a one-sentence description.
• Driver: The rule, standard or failure it answers, with a link to the primary source.
• Scope: The workflow, users and data classes in the pilot.
• Owner: The person accountable for the pilot result.
• Exit test: The measurable result that decides adopt or retire, set before the pilot starts.
• Retire date: When the code path is removed if the exit test fails.

Which healthcare trends are already written into rules?

Several trends have dates and citations attached. These are the ones to plan for first, because they show up as certification gaps, payer contract terms or accessibility complaints if ignored.

• Payer APIs: CMS-0057-F sets prior authorization decision timeframes of 72 hours for expedited and 7 calendar days for standard requests from 1 Jan 2026, and requires Prior Authorization, Provider Access and Payer-to-Payer APIs from 1 Jan 2027.
• Patient Access API: The Patient Access API itself dates from the 2020 CMS Interoperability and Patient Access final rule (CMS-9115-F). CMS-0057-F adds enhancements to it.
• Certified EHR APIs: ASTP/ONC criterion 45 CFR 170.315(g)(10) defines a standardized read API for patient and population services using US Core, SMART App Launch and Bulk Data.
• Decision support fairness: Under Section 1557 at 45 CFR 92.210, covered entities must not discriminate through patient care decision support tools, with compliance from 1 May 2025.
• Accessibility: The HHS Section 504 rule at 45 CFR 84.84 adopts WCAG 2.1 Level AA for the web content and mobile apps of HHS-funded recipients, with compliance dates of 11 May 2027 for recipients with 15 or more employees and 10 May 2028 for smaller ones.

The Da Vinci CRD, DTR and PAS implementation guides are recommended for the prior authorization work, not required, so treat them as the likely path rather than a mandate.

What the payer API dates mean for a build

A payer or a vendor building for payers needs FHIR R4 APIs with OAuth 2.0 authorization, member and provider identity matching, attribution logic for the Provider Access API, and consent handling for Payer-to-Payer exchange. Provider-side products that submit prior authorization requests should plan for the payer's FHIR endpoints while keeping existing X12 278 and portal workflows until each payer is live.

What is changing in certification and national exchange?

Certification is shrinking around FHIR APIs, and national exchange is growing through TEFCA. Both point the same way: build on standard APIs and exchange frameworks rather than one-off interfaces.

• HTI-5 final rule: Published by ASTP/ONC in the Federal Register on 28 Oct 2026 and effective 28 Dec 2026, with some provisions from 1 Jan 2027, it removed 14 certification criteria and revised 7. Developers no longer submit annual real-world testing plans.
• Model card removal: HTI-5 removed the predictive decision support intervention source-attribute requirements under (b)(11), so certification no longer demands them, although customers may still ask for model documentation.
• Information blocking unchanged: HTI-5 did not change the information blocking regulations in 45 CFR Part 171.
• TEFCA growth: HHS announced in June 2026 that more than one billion health records had been exchanged under TEFCA.

For a build plan, this means FHIR R4, US Core and SMART on FHIR skills are worth more each year, while effort spent on certification paperwork for removed criteria can be redirected.

How should AI features be governed in clinical software?

AI features should ship with a named human reviewer, documented intended use, monitoring and a check of FDA device status. The frameworks below give teams a vocabulary for that work without making any one of them a legal requirement.

• Risk framework: The NIST AI Risk Management Framework (AI 100-1, January 2023) organizes AI risk work into four functions: govern, map, measure and manage. It is voluntary.
• Generative AI: NIST AI 600-1 (July 2024) is the generative AI profile of that framework, covering risks such as confabulation and data privacy.
• Device status: FDA's final Clinical Decision Support Software guidance, issued 6 Jan 2026 and re-issued 29 Jan 2026, explains which clinician-facing functions fall outside the device definition. Software that analyzes medical images or device signals does not qualify for that carve-out.
• Human review in the workflow: Drafting, coding or triage features should require a clinician or coder to accept the output before the chart or claim changes, with the reviewer and edits recorded.

Evidence an AI feature should ship with

• Intended use: Who the feature is for, which decision it supports and what it must not be used for.
• Data description: What the model was trained or tuned on and which patient groups that data covers.
• Performance by group: Results across age, sex and other relevant groups, which supports a Section 1557 review.
• Monitoring plan: The metric watched in production, the threshold for action and the owner.
• Override record: How often reviewers change or reject the output, tracked as a signal of drift.

Is secure development now a buyer requirement?

For medical device software it is a legal requirement, and for other healthcare software it is a reasonable thing for buyers to ask for. Federal law sets specific cybersecurity evidence for cyber devices, and NIST gives every other supplier a common standard to show its practices against.

• Secure development framework: NIST SP 800-218, the Secure Software Development Framework, describes practices for preparing the organization, protecting software, producing well-secured software and responding to vulnerabilities.
• Cyber devices: Section 524B of the FD&C Act requires device makers to provide a software bill of materials, a plan to monitor and address postmarket vulnerabilities, and processes that give reasonable assurance of cybersecurity.
• HIPAA safeguards: The HIPAA Security Rule requires audit controls, unique user identification and person or entity authentication for systems holding ePHI. HHS proposed in January 2025 to make MFA and encryption required, but that rule is still a proposal.

Platform engineering as a supporting trend

Shared identity, an API gateway, environment promotion, logging and monitoring built once and reused by each product team is how small healthcare engineering groups keep pace with the rules above. It has no regulatory driver of its own, which is why it should earn its place through the filter like any other trend.

Where trend adoption goes wrong

• Consumer lists in a clinical backlog: Trend lists written for consumer software ignore PHI, safety and interoperability constraints.
• Tool before workflow: The license is bought, the interface work is never scheduled, and the feature never reaches a patient.
• PHI in an uncovered service: A new data store or model host receives PHI without a business associate agreement or a threat model.
• Rewrite without a reason: Rebuilding a working system in a new language with no interoperability, safety or cost driver.
• Accessibility and logging later: Both are cheaper at design time and harder to add after go-live.
• No retire date: A half-adopted pilot stays in production as technical debt.
• No owner: Nobody is accountable for the pilot result, so the trend neither ships properly nor gets removed.
• Driver never checked again: A rule changes, as HTI-5 did, and the team keeps building for a requirement that no longer exists.

How Agnotic can help

Deciding what not to build is often the most valuable call a technical lead makes in a quarter. Agnotic Technologies provides healthcare fractional CTOs who run trends through that filter against your workflows, rules and customers, write the decision records, and then build the architecture, integrations and delivery path for the trends that pass.

Sources

• CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet
• ASTP/ONC: HTI-5 Final Rule
• 45 CFR 92.210: Nondiscrimination in the use of patient care decision support tools
• Federal Register: Section 504 web and mobile accessibility compliance date extension (11 May 2026)
• NIST: AI Risk Management Framework (AI 100-1)
• NIST AI 600-1: Generative Artificial Intelligence Profile
• NIST SP 800-218: Secure Software Development Framework (SSDF)
• 21 U.S.C. 360n-2 (FD&C Act section 524B): Ensuring cybersecurity of devices