Custom software for medical practices

Most practices do not need custom software. They need one missing piece built around the certified EHR and practice management system they already pay for: an integration, a dashboard or a form. Full custom software is right in a narrow set of cases, and wrong more often than the people selling it will say.

Your EHR holds the clinical record and the certification your payer programs assume. Your PM system holds the charges, the payments and the schedule. Replacing either is a risk project with a multi-year tail. Building the one report or connector they are missing is a small project with a measurable result.

In short: keep the certified systems, build the gap.

When a custom build is the right answer

A build earns its place when one of these is true.

• The workflow is specific to your practice and no product matches it, for example a plan-of-care tracker that counts authorized visits the way your largest payer does.
• Two systems hold halves of the same answer and will not talk, so a person is the integration.
• You pay staff hours every week to re-key data that already exists in digital form.
• A product exists, but per-user pricing stops making sense at your headcount.

Skip the build when the opposite is true. A setting you never switched on, or a report builder nobody was trained on, beats a custom tool on cost and support. Do not build while the process still changes monthly, if the tool would hold the only copy of clinical data, or if nobody will own it after launch. Software without an owner rots quietly.

What practices actually build

Each of these replaces a spreadsheet, an inbox or someone’s memory.

• Collections and A/R dashboards. Pull from the PM system and show aging buckets, days in A/R by payer, denial reasons by volume, and expected versus posted payments. It is the most common first build: the data exists and nobody has time to assemble it weekly. Same decisions as A/R management.
• Secure online intake and forms. Demographics, insurance card capture, consent and history collected before arrival, landing in a structured record instead of scanned PDFs.
• Automated reminders and follow-ups. Appointment reminders, recall lists, no-show follow-up, balance reminders, and chasers for missing documents or signatures.
• Connectors between systems. Eligibility results written onto the schedule, phone-system call outcomes logged against the patient, remittance files summarized for the biller.
• Prior authorization and credentialing trackers. Authorization number, units approved and used, expiry and who is chasing it, the same fields prior authorization work runs on. On the credentialing side: attestation, revalidation and payer effective dates in one place.
• Staff workload reports. Claims touched per biller, calls per front desk seat, charts closed per provider, aged accounts assigned but untouched.

Configure, buy, integrate or build

Ask your PM and EHR vendors first, in writing, whether what you want already exists in a module you own. That question is free and closes a surprising number of projects. If the workflow itself is the problem, that is a practice management consulting conversation.

HL7 v2, FHIR and your right to get data out

Two standards do almost all the work, and one federal rule decides how hard your vendor can make it.

HL7 v2 is still the plumbing

HL7 Version 2 is a messaging standard first released in 1987. HL7 calls it “arguably the most widely implemented standard for healthcare in the world” and reports that 95% of U.S. healthcare organizations use v2.x. One system sends, another receives, usually through an interface engine. It is reliable and everywhere, but a poor fit for anything interactive: a feed is a one-way push, not something a dashboard can query.

FHIR R4 and the certified API criterion

The certification criterion at 45 CFR 170.315(g)(10), “Standardized API for patient and population services,” requires a certified Health IT Module to answer requests for a single patient’s data and for multiple patients as a group, to support the listed search operations, to let an application register with its authorization server, and to revoke an app’s access at the patient’s direction within one hour.

The standards it points to are named in 45 CFR 170.215: HL7 FHIR Release 4.0.1 as the base standard, the US Core Implementation Guide STU 6.1.0, SMART App Launch 2.0.0, OpenID Connect Core 1.0 and FHIR Bulk Data Access for group export. The criterion also requires complete API documentation to be reachable “via a publicly accessible hyperlink without any preconditions or additional steps.”

If a vendor will not give you the documentation link, that is not a technical problem.

Certified API developers also work under conditions in 45 CFR 170.404: publish business and technical documentation openly, describe fees in plain language, and charge an app developer nothing beyond the narrow set of fees the rule permits, which excludes anything needed to develop and deploy production-ready software. They may charge you, the practice, for development, deployment, upgrade and incremental hosting costs. Expect a bill on your side of that line, not on your developer’s.

Information blocking, and who it applies to

The information blocking rules in 45 CFR Part 171 apply to four kinds of actor: health care providers, health IT developers of certified health IT, health information exchanges and health information networks. A practice is an actor too, so the rule cuts both ways.

Information blocking means a practice likely to interfere with the access, exchange or use of electronic health information, unless it is required by law or fits an exception. The knowledge test differs: a developer or network is caught if it knows or should know, a provider only if it knows the practice is unreasonable and likely to interfere. Part 171 sets out exceptions covering preventing harm, privacy, security, infeasibility, manner, fees and licensing.

Enforcement is not symmetric. The OIG may impose civil money penalties of not more than $1,000,000 per violation on developers and networks. For providers it is a program disincentive: losing meaningful EHR user status for MIPS or the hospital programs, or, for ACOs and their participants, removal from the Medicare Shared Savings Program for at least a year.

What this means for a build: a vendor can charge permitted fees and insist on a particular manner of access, but “we do not allow third-party integrations” is a position it has to defend. Rules here change, so confirm the current text before building to it. If a refusal looks like blocking, check with your health care attorney.

HIPAA rules that apply to the software itself

Any tool that creates, receives, maintains or transmits electronic protected health information sits inside the Security Rule. Three things matter most.

Risk analysis is required, not advisory. 45 CFR 164.308(a)(1) sets the security management process standard, and all four of its implementation specifications are marked required: risk analysis, risk management, a sanction policy, and information system activity review. A new system changes your risk picture, so the analysis belongs inside the project.

Technical safeguards are the build spec. 45 CFR 164.312 names five standards: access control, audit controls, integrity, person or entity authentication, and transmission security. Under access control, unique user identification and an emergency access procedure are required. Automatic logoff, encryption and decryption, the mechanism to authenticate ePHI, and transmission integrity controls and encryption are listed as addressable. In a new build there is rarely a defensible reason to skip any of them, and your developer should show how each is handled.

Your developer and your host are business associates. HHS guidance on HIPAA and cloud computing states that a cloud provider handling ePHI is a business associate and that a business associate agreement is required, and that this holds “even if the CSP processes or stores only encrypted ePHI and lacks an encryption key for the data.” Data may sit outside the United States with an agreement in place, but the guidance warns that risks vary by location and belong in your risk analysis. Our HIPAA compliance and BAA page covers that side.

Watch rather than act on this one: HHS published a proposed Security Rule overhaul on January 6, 2025 (90 FR 898), comments closed March 7, 2025. It would expressly require encrypting ePHI with limited exceptions and add standards for a technology asset inventory, vulnerability management and compliance audits. As of October 2026 it is not final, so current requirements govern. Encryption everywhere, multi-factor sign-in and a written asset list cost little now and save a retrofit later.

What drives cost, time and ownership

Nobody can quote a build from a sentence. These variables move the number.

• Scope. One report is not one workflow. Roles, permissions, exceptions and the “what if the payer says no” path are most of the work.
• Number of integrations. Each system is its own project: credentials, a test environment, error handling, someone to call when it stops.
• Data migration. Historical data is messier than described, and cleanup is usually larger than the import.
• Security work. Access control, audit logging, encryption, backups, hosting review and the agreements that go with them.
• Testing. Real staff, real edge cases, and a period of running the old way alongside the new.
• Support. EHRs, clearinghouses and payer portals change. An unmaintained integration does not announce its failure, it goes quiet.

Settle ownership in the contract before anyone writes code. Who owns the source code, and do you get it in a repository you control? Can you export all of your data in a documented format on request? Whose cloud account hosts it? What does support cover after launch, and what counts as a bug rather than a billable change? What documentation do you get: data model, credentials, backup runbook? If you part ways, who could pick it up?

How to scope a build in six steps

1. Map the workflow as it is. Sit with the person doing it and write down every click and every piece of paper, not the handbook version.
2. List the data and the systems. For every field, name the one system that is the source of truth. Disagreements here are the real project.
3. Define one measurable outcome. “Cut the time the front desk spends re-keying insurance details by half” is a target. “Better visibility” is not.
4. Build the smallest useful version. One report, one form, one connector, in production, used by real staff. Then decide what is next with evidence.
5. Test with the people who will use it. Use realistic data, and do not put live PHI in a test system unless it carries the same safeguards and agreements as production.
6. Plan support before launch. Name who to call, what response time you are buying, and who owns the integration when a vendor pushes an update.

Before you hire anyone, ask: will you sign a business associate agreement, where will the data be hosted and who holds the agreement with that host, how is record access logged, how are backups taken and tested, and who maintains the integration when the EHR updates? Then ask to speak to a current client; we do that with the client’s permission.

What Reliable Care builds

We build the missing piece, not a replacement for your EHR: patient portals and secure intake, dashboards for collections, A/R and staff workload, integrations between your EHR, PM system and the other tools you run, automated reminders and reports, HIPAA-aware builds with the agreements in place, and support after launch rather than a handover and silence. The full scope is on our web design, software and social media page.

The useful part is who builds it. The same team runs medical billing for practices, so an A/R dashboard here is specified by people who read aging reports and denial reasons every day, not by developers guessing at what a biller needs.

We do not publish software prices: a quote before a review is a number pulled from the air. Start with a free review of the workflow you want fixed. If the answer is a setting you already own, we will say so.