Healthcare software development is the work of building and maintaining clinical, patient, and administrative systems that handle protected health information under US rules. Woltrio builds these for providers, payers, and health tech companies.
What changed recently is not the definition. It is that a meaningful share of healthcare software work is no longer discretionary. Federal rules now attach dates to engineering, and the nearest hard one is January 2027.
That reframes the usual question. For a lot of organisations the decision is no longer whether to invest in custom healthcare software development, it is what has to exist by a fixed date and what can wait. So this piece is organised by the clock rather than by topic.
Already in force
Some obligations landed at the start of 2026 and are live now.
Under the CMS Interoperability and Prior Authorization Final Rule, finalised in January 2024, impacted payers have been operating under shortened prior authorisation decision timeframes since 1 January 2026. Seven days for standard requests, seventy two hours for expedited ones, and denials must carry a specific reason rather than a generic code.
Note what that is. It reads as a policy change and it is an engineering change. Faster decisions with structured reasons require the underlying systems to produce, store, and surface that information reliably, and most legacy authorisation workflows were never built to.
Due 1 January 2027
Four FHIR based APIs, in production, for impacted payers.
APIWhat it doesPatient AccessMembers and authorised apps retrieve claims, encounters, clinical data, and prior authorisation informationProvider AccessIn network providers retrieve member data for treatment and care coordinationPayer to PayerMember data transfers when coverage changes, to maintain continuityPrior AuthorizationSubmitting, tracking, and returning authorisation decisions
They are built on FHIR R4 with US Core, SMART on FHIR, and the relevant Da Vinci implementation guides. That last part is where the work concentrates, because implementation guides are where a general standard becomes a specific contract, and conformance is tested against them rather than against FHIR in the abstract.
One precision point worth having, because a lot of published summaries get it wrong. The Provider Directory API is not new here. It came from the earlier Patient Access rule and continues to apply. Counting it as a fifth new obligation inflates the scope of what is actually being added.
CMS has also signalled enforcement discretion around the HIPAA X12 278 prior authorisation transaction standard, which matters if your roadmap assumed that transaction stays fixed.
Who this applies to, and who it does not
The rule reaches Medicare Advantage organisations, Medicaid and CHIP managed care entities, state Medicaid and CHIP fee for service programmes, and Qualified Health Plan issuers on the federally facilitated exchanges.
Providers carry no direct compliance obligation under it. That distinction gets lost constantly, and it matters in both directions. If you are a provider organisation, nobody is going to fine you over this. You will still feel it, because the authorisation workflow your staff use every day is about to change shape, and the organisations that prepared for that will spend 2027 with an advantage over the ones that treated it as somebody else's rule.
If you are a health tech company selling into payers, this is the largest scheduled buying event in your market for several years.
What a deadline changes about how you build
Three things, and they are the reason this section exists rather than a feature list.
Sequencing stops being negotiable. When the date is fixed, the order of work is determined by what has the longest lead time, not by what is most interesting. Data location is usually first. Payer data on members, prior authorisation history, and clinical records is commonly spread across many systems with inconsistent identifiers, and reconciling identity is slow work that everything else waits on.
Conformance testing has to be scheduled, not assumed. Validating against reference implementations takes real calendar time, and it is the step that most often reveals that a build interpreted an implementation guide differently from the people who will assess it. Book it early. A go live date set without a conformance window in front of it is a guess.
Build and buy stop being opposites. Under a deadline the practical answer is usually neither purely one nor the other. Compliance does not require replacing core systems, and modular components layered onto what you already run will hit the date more often than a rebuild will. Woltrio's work in this area sits mostly in that middle ground, through backend development, cloud engineering, and integration against existing platforms.
What is not on the clock
Worth stating plainly, because deadline pressure distorts budgets and the discretionary work is where competitive advantage actually lives.
Nothing compels you to build a good patient experience. Healthcare app development, patient portals, intake flows, and the interfaces people actually touch are all optional in regulatory terms, and they are the reason a member chooses your plan or a clinician tolerates your product. The same goes for AI development and workflow automation, which are where most of the operational return sits and which no rule requires.
The failure mode to avoid is spending the whole of 2026 on the mandatory work and arriving in 2027 compliant and undifferentiated. The compliance build is a floor. Everyone impacted will clear it, on roughly the same date, using roughly the same standards.
Where Woltrio fits
Woltrio is a healthcare software development company working with US providers, payers, and health tech firms across custom builds, integration, and long term support.
For deadline driven work, engagements usually start with an inventory rather than a proposal, because the honest scope depends entirely on where the data currently lives and what the existing platform already exposes. Some organisations need far less built than they expect. Others discover the identity reconciliation problem in month two rather than month eight, which is the difference between hitting a date and missing it.
Beyond compliance, the same foundations carry the discretionary work: custom EMR and EHR development where the record layer is the constraint, and UI and UX design for the patient and clinician facing products that regulation will never mandate and buyers will always judge you on.
Start with a scoped discovery from Woltrio.
