Healthcare software development services, for the admin side of care

What is the first question to answer?

Whether you are a covered entity, a business associate, or neither. It determines your obligations, what agreements you must sign, and how much of the design is constrained before anyone writes code. Most health technology companies are business associates and carry direct liability for protected health information they handle.

The third row is where founders get caught. A wellness product with no provider relationship may sit outside these obligations entirely, and then the first health system signs as a customer and the position changes. If a provider customer is anywhere on your roadmap, design as though the obligations apply, because retrofitting an access model is a rebuild rather than a feature.

Which category you fall into is a question for your counsel, not your developer. We build to whatever that answer is and we will not guess at it on your behalf.

What does EHR integration actually require?

More time and more parties than a technical estimate suggests. Reading data through a FHIR sandbox is straightforward and free. Getting to production at a real health system involves that organisation's governance, their budget with the EHR vendor, and for write access a clinical safety review. Published guidance puts first go live anywhere from two to fourteen months depending on scope.

Some specifics, with the caveat that they come from integration consultancies rather than the vendors themselves and that fees change, so confirm current figures on the vendor's own developer portal before budgeting.

For Epic, standard FHIR access carries no developer fee, with a paid vendor membership reported at around 1,900 dollars a year and a small listing fee for the marketplace. The larger cost sits with the health system: reported figures for production FHIR API access run from a few thousand to tens of thousands of dollars a year per instance, paid by them rather than by you. A marketplace listing also requires a live production connection at a customer site, which is a chicken and egg problem worth planning around. Authorisation is SMART on FHIR, which is OAuth 2.0 with OpenID Connect.

For Oracle Health, the comparable programme centres on their Ignite APIs with FHIR R4 and SMART App Launch, and each customer environment needs its own registration and provisioning.

The practical consequence for your plan: treat each health system as a separate commercial and technical engagement, not a configuration change. Reported incremental cost per additional site runs in the thousands, with a two to four week go live each. A roadmap that says "then we roll out to twelve hospitals" is describing twelve projects.

Is FHIR enough, or do you still need HL7 version 2?

Both, in most real integrations. FHIR is the modern standard and what new work targets, but HL7 version 2 interfaces still carry a great deal of production traffic in hospitals, particularly for admissions, orders and results. Assuming FHIR covers everything is a common and expensive planning error.

The honest way to scope this is to ask the health system's integration team, early, which interfaces exist today for the data you need. The answer is frequently that FHIR covers the patient demographics and clinical summary you want to read, while the event you actually need to react to arrives as an HL7 version 2 message through an interface engine.

Three practical notes. Reading is far easier than writing in every EHR, so design a first release that reads if you possibly can. Data available through a standard does not mean populated: a field can exist in the specification and be empty at that site, and only looking at real data tells you. And interface engines are usually owned by a team with their own queue, which is a scheduling constraint rather than a technical one.

What did the information blocking rule change?

The information blocking rule changed the incentives around sharing data, and enforcement is now active rather than theoretical. Regulations finalised in July 2023 authorise civil monetary penalties of up to one million dollars per violation for health IT developers, information exchanges and networks, effective from September 2023 and not retroactive. Providers face reductions to their Medicare payment update rather than fines.

This matters to a software vendor in a specific way. If you build or supply health IT, practices that unreasonably interfere with access, exchange or use of electronic health information can expose you, not only your customer. Enforcement has been described as prioritising conduct that causes patient harm, significantly impairs care, persists over time, or causes losses to federal programmes.

It has also moved from policy to practice. In February 2026 the Assistant Secretary for Technology Policy began issuing letters of nonconformity to certain electronic health record developers over potential information blocking and API noncompliance. That is a meaningful signal about the direction of travel.

The engineering consequence is straightforward and worth designing for deliberately. Export should be a first class feature rather than a grudging one. A patient or a provider asking for their data should get it in a standard format without a support ticket. Charging in a way that effectively prevents access, or building a format only you can read, are the kinds of design decisions that now carry regulatory weight as well as commercial cost.

Whether any specific behaviour constitutes information blocking is a legal determination and not one we make. What we can do is build so the question does not arise.

What is coming for payer facing products?

The CMS interoperability and prior authorisation rule. Business process requirements began on 1 January 2026, with standard prior authorisation decisions generally due within seven calendar days and expedited ones within 72 hours. Public reporting of prior authorisation metrics started in 2026. The required APIs carry a deadline of 1 January 2027.

Four APIs sit in that rule: patient access, provider access, payer to payer, and prior authorisation. If your product sits between a payer and anyone else, those deadlines are planning constraints rather than background reading, and the 2027 date is closer than it looks once you account for testing and partner coordination.

On TEFCA, the common agreement reached version two in January 2026 with several qualified health information networks onboarded and able to support FHIR based exchange. For most product teams this is context rather than an immediate requirement, but it is the direction national exchange is moving and it is worth knowing which networks your health system customers participate in.

As with everything on this page, confirm current dates and obligations against the CMS and ASTP publications themselves. Regulatory timelines in this area have moved more than once.

What does HIPAA actually require of the software?

Today: access control, audit logging, integrity controls, transmission security and the rest of the Security Rule's technical safeguards, implemented in a way you can evidence. A substantial update has been proposed but is not yet law, and it would make several things that are currently flexible into firm requirements.

The proposed update was published in the Federal Register in January 2025 and drew thousands of comments, including a push from hospital and provider groups to withdraw or substantially revise it. As of this writing it remains a proposal, with the regulatory agenda pointing at 2027 for final action, and the government's own estimate of first year compliance cost across regulated entities ran to several billion dollars.

What it would change, if finalised broadly as proposed: encryption of electronic protected health information would stop being an addressable item and become required, at rest and in transit. Multi factor authentication would be required across technology assets, with exceptions for certain legacy systems and older approved medical devices under a transition plan. Risk analysis would have to rest on asset inventories and data flow mapping. Commentary also describes annual penetration testing, vulnerability scanning twice a year, a restoration standard measured in hours, and annual written verification of safeguards from business associates.

Our position on this is simple and we would give you the same advice if you never hired us. Build as though encryption, multi factor authentication, an asset inventory and real audit logging are required, because they are good engineering regardless of what the final rule says, and because retrofitting them later is substantially more expensive than including them now.

We design and implement these controls. We do not assess or certify compliance, because an assessor must be independent of whoever built the system. Where a project needs formal readiness work, our SOC 2 readiness page describes how we handle the equivalent in that framework.

When can you use patient data for analytics or AI?

When your legal basis permits it, which is a determination your privacy officer or counsel makes rather than your engineering team. What we can tell you is that the technical answer usually involves de-identification, and that de-identification done casually is the most common serious mistake we see in health data projects.

Removing names and dates of birth is not de-identification. There are recognised methods for doing it properly, and they exist precisely because a dataset stripped of obvious identifiers can often be re-identified by combining fields. A rare diagnosis, a zip code and an admission date can be sufficient.

Three engineering habits that keep this tractable. Separate identified and de-identified data physically rather than by a flag in a column, because a flag will eventually be wrong. Make the de-identification step a pipeline that is tested and versioned, so you can answer which method produced a given dataset. And log access to identified data at the row level, because the question you will be asked is who looked at this record, not who had permission to.

If your product trains or fine tunes a model on patient data, treat that as a decision requiring explicit sign off rather than an engineering implementation detail. We will raise it rather than quietly proceeding, and the answer may reasonably be no.

How do you get administrative staff to actually use it?

Build it with them, in front of them, and make it faster than what it replaces. Administrative staff in healthcare have usually been handed several systems chosen without them, so scepticism is earned. The fastest way through it is a working screen in week two that removes one job they hate.

Adoption failures here look different from clinical ones. Nobody refuses outright. They use the new system for the easy cases and keep the old process for anything unusual, and within a month you have two systems and worse data than before.

What prevents it, in order of effect.

Start with their worst job, not your best feature. Ask which task they would most like never to do again. It is usually re-typing something that already exists in another system, and automating exactly that buys you the credibility to change anything else.

Handle the unusual cases explicitly. Every administrative workflow has exceptions, and the exceptions are where the old process survives. Ask what happens when the referral has no insurance detail, when the patient has two records, when the form arrives incomplete. Designing for those is what stops the parallel process forming.

Do not make them wait. A screen that takes three seconds to load will lose to paper, every time, regardless of what it does afterwards.

Give them a way to report a problem that gets answered. If the first three issues raised go nowhere, nobody raises a fourth and you lose your best source of information about how the system is actually being used.

One pattern worth copying from the clinical side: shadow somebody for an hour before designing anything. Not a workshop, not a requirements session. Sit beside the person doing intake and watch what they actually do, including the parts they would never think to mention because they are so routine.

What should a small practice automate first?

Appointment reminders, then intake, then whatever is currently being re-typed between two systems. Reminders are first because they are simple, measurable within a fortnight through the no show rate, and they pay for themselves faster than anything else on a typical practice's list.

Small practices get a worse deal from healthcare technology than anyone. The products are priced for health systems, the integrations assume an IT department, and the vendor's support model assumes somebody whose job is this. So the sequencing matters more here than it does for a hospital.

First, automated reminders and confirmations. Measurable, uncontroversial, and it touches no clinical data beyond an appointment. If your systems already offer this and nobody switched it on, that is the whole project and we will tell you so.

Second, digital intake. Forms completed before arrival, validated on entry, landing where they need to be. This removes a re-typing job and shortens the waiting room, and patients broadly prefer it.

Third, whatever is being copied between two systems. Every practice has at least one. Someone exports from one system and types into another, weekly, and has done for years. It is usually a small integration and the hours saved are easy to count.

What we would not start with: a patient portal. Portals are visible, they feel like progress, and they are the thing most likely to sit unused if the underlying processes have not been fixed first. Build the thing that saves staff time, then give patients a window onto a process that already works.

Where is the line you will not cross?

Clinical decision making. We build administrative and operational software around care, and we do not build systems that diagnose, triage by acuity, or recommend treatment. Software that influences a clinical decision can fall under medical device regulation, and that determination belongs to a regulatory advisor before architecture rather than before launch.

We say this plainly because the boundary is blurrier than it sounds and crossing it accidentally is possible. A dashboard that surfaces waiting times is operational. The same dashboard sorting patients by a computed risk score is doing something else, and whether that something else is regulated is not a question a software agency should answer for you.

What we will do is flag it the moment it appears in a requirement, and keep flagging it. If the answer from your regulatory advisor is that the product is a device, you need a firm with a quality management system built for that, and we will say so rather than taking the work.

What do you build for healthcare organisations?

The administrative layer: intake, referrals, scheduling, document automation, portals, operational dashboards and the integrations underneath. Most projects start with whichever of those currently consumes the most staff time, because that produces a measurable number within a month.

The one most often underestimated is document automation. Letters, referrals, discharge summaries and reports assembled by hand are usually a larger time cost than anybody has measured, and they are well suited to automation because the inputs are already structured somewhere.

Should you commission custom healthcare software development services or configure what you have?

Configure first, and we will tell you when that is the answer. Custom healthcare software development services are worth commissioning when your workflow genuinely differs from what your systems assume, when you need something that sits between two systems neither vendor will build, or when the product is what you sell.

The pattern we see repeatedly: a practice or a health system feels administrative pain, concludes it needs new software, and nobody checks whether the existing systems already support the workflow with configuration. A fortnight with the vendor's own configuration team is cheaper than a quarter of development, and we would rather lose that work than build something that duplicates a module you already own.

Where custom is genuinely the right answer, the common shapes are an integration layer joining systems that will not talk, a patient facing surface the incumbent vendor does not provide, or an operational tool for a workflow specific to how your organisation runs. All three are reasonable. Replacing a clinical system is not a project we would take on and not one we would recommend lightly to anyone.

When should you not build?

Four cases, and we check all of them before quoting: the existing system already does it, the product might be a regulated device and nobody has asked, there is no compliance lead to approve design decisions, or the underlying disagreement is between departments rather than between systems.

There is a fifth worth naming. If the integration you need depends on a health system's governance committee and nobody from your side has spoken to them, the timeline is unknowable. Not long, not short: unknowable. Start that conversation before you commission the build, because it routinely takes longer than the engineering.

What should you have ready before the first call?

Four things, none technical. Which systems you run and who administers them, who can approve a decision about patient data, one workflow that is currently painful, and whether a health system integration is in scope. With those, scoping takes an hour.

The systems and their administrators. Names are enough. We will find out what each one exposes, and knowing who to ask is frequently the difference between a two day answer and a three week one.

Who approves decisions about patient data. This is the single most useful thing you can establish before engaging anyone. Every design question about access, logging or retention routes to that person, and projects without one stall quietly rather than failing loudly.

One painful workflow, described as a day rather than a feature list. Who does this, at what point, under what pressure, and what goes wrong. A paragraph is plenty, and it shapes the design more than a requirements document would.

Whether EHR integration is in scope. If it is, say so immediately, because the governance conversation with the health system should start before the build rather than after. That is the long pole in almost every healthcare project and it is the one thing engineering cannot accelerate.

What you do not need is a specification. In healthcare particularly, specifications written before anyone has checked what the existing systems can do tend to describe a product that duplicates a module you already own.

How does a healthcare project run with Voliom?

Your compliance lead is in the room from the first call, not shown the design at the end. We scope one workflow, agree the access model before anything is built, and ship something usable in four to six weeks. Integration work is planned against the health system's governance calendar rather than ours.

1. 01

   Scope one workflow

   Days 1 to 5

   Usually intake or referrals. We map who touches what, what each system already does, and where the time is actually going. This is also where we tell you if configuration beats building.

2. 02

   Access model and sign off

   Week 1

   Who can see which record, what gets logged, how long it is kept. Your compliance lead approves this before code, because it is architecture rather than configuration.

3. 03

   Build and demo weekly

   Weeks 2 to 6

   Working software in front of the people who will use it. Administrative staff find the gaps in a workflow faster than any specification review.

4. 04

   Integrate on their calendar

   In parallel, longer

   EHR connection work runs alongside, paced by the health system's governance and provisioning rather than by us. We plan for it to be the long pole, because it usually is.

One thing we ask for and will not proceed without: a named person on your side who can approve a decision about patient data within a day. Not a committee. Projects without that person do not fail dramatically, they stall at the first access question and then drift.

We also do not want production access to patient records. We work against test environments and synthetic data. If something genuinely cannot be reproduced that way, the right fix is better logging, not a vendor holding PHI.

What do healthcare software development services cost?

Scope decides it and we quote line by line after mapping one workflow. A first administrative build is typically four to six weeks. EHR integration is quoted separately, because its timeline depends on a third party's governance rather than on engineering effort, and pretending otherwise would be dishonest.

Budget separately for the things that are not our invoice: what your health system partner pays their EHR vendor for production API access, any vendor programme fees, and ongoing security assessment work. Industry guidance puts annual compliance activity for a health technology product in the tens of thousands of dollars, and leaving it out of a business case is a common oversight.

Indicative until we have scoped the work. We are a small remote team working US business hours with engineering based in Pakistan, which matters here because your compliance obligations may restrict who can access what and where data may be processed. Establish that early. You can read about the team, and if you need engineers alongside your own rather than a delivered outcome, IT staff augmentation is the lighter engagement.

• Custom software for healthcareAdministrative tools built around access control
• AI and automationAutomating admin, not clinical judgement
• Dedicated development teamsEngineers who work inside your compliance process
• SOC 2 readinessWhen enterprise customers start asking
• Cloud security assessmentAccess, logging and retention, reviewed
• Systems integrationJoining systems that will not talk