Urgent Care Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as a replacement for the chart?

Because the electronic medical record is the system everyone complains about, so it is the system that gets named in the brief. That is the most reliable way to lose a year and a budget in this category.

Rebuilding the chart means rebuilding electronic prescribing, interaction checking, controlled substance workflow, laboratory device interfaces for waived testing and the coding scaffolding underneath all of it. Experity and athenahealth have spent well over a decade and large engineering teams in that territory, and you will not catch them. Worse, you would be putting the clinical record at risk to solve problems that are not in the clinical record. The queue, the payer mix, the occupational medicine billing and the results follow up are all operations problems living above the chart, and the chart is not where they are solved.

The fix: scope the operations layer and leave the system of record alone. The layer needs an arrival ledger across every location, real door to door timing, a payer mix view that is current rather than retrospective, and a results register. Write into the brief explicitly that the electronic medical record remains the system of record and the build does not write clinical documentation. That one sentence removes a category of scope creep that otherwise arrives in month three when somebody asks whether providers could just chart here instead.

What goes wrong with the arrival and remittance data?

Two data problems decide whether the operations layer is useful. The first is that networks assembled by acquisition carry several electronic medical record or practice management instances, and the same concepts do not line up across them. Location codes differ, visit types differ, and the chief complaint captured at check in is free text in one instance and a picklist in another, so any acuity or resource mapping has to be built per instance and maintained per instance.

The second is payer identity. A registrar picks from a dropdown with hundreds of rows and several plausible entries for the same carrier that route to different payer identifiers, so the plan on the visit and the plan on the remittance are different objects. Without a mapping between them, you cannot join a denial back to the visit, the registrar or the card image that caused it, and the denial stays anonymous.

The fix: build a canonical location, visit type and payer model first, with an explicit per instance mapping that has an owner. Ingest a historical extract of check ins, visit timestamps, procedure codes and remittance files so forecasting has your own arrivals to learn from rather than a vendor's benchmark. Treat mapping drift as an exception with an alert, because a new plan added at one site and not mapped will silently misclassify every visit that uses it.

Why do the EMR and clearinghouse interfaces break after launch?

Because the method differs by vendor and each method has its own failure style. Experity in practice means health level seven feeds and scheduled extracts rather than a modern interface, so the operations layer is downstream of a message stream that can stall without erroring. athenahealth exposes real interfaces with partner approval and per transaction fees, which means a volume spike has a cost attached. An Epic connection means a formal vendor services process measured in months, which belongs in your timeline before the build starts, not during it.

The characteristic production failure is a stalled feed rather than a broken one. Messages stop arriving from one site, the queue board shows that site as quiet, and the operations team reads quiet as good news until somebody phones. Eligibility checks fail the same way: the clearinghouse returns nothing for a plan it cannot resolve, and a visit proceeds as though coverage were confirmed.

The fix: monitor message rate per site against its own normal band and alert on absence rather than on error, since absence is what actually happens. Distinguish no patients from no data on the board, so an operator can tell the difference. Treat an unresolved eligibility response as a hold with a task for the front desk while the patient is still in the building, never as a pass. Start the vendor interface paperwork in week one, because it is the critical path and no amount of engineering shortens it.

What happens when results follow up and privacy engineering are not covered?

A culture comes back positive on Thursday for a Tuesday patient. That afternoon the teleradiology overread flags a fracture the reading provider called a sprain. Both land in an inbox belonging to a provider who is off for three days, or on a printed list at the front desk. This is simultaneously a patient safety event and a revenue event, and the electronic medical record inbox has no service level and no escalation.

Privacy is the parallel gap. The failure is rarely a dramatic breach. It is protected health information leaking into application logs and error monitoring where it will be retained indefinitely, production data copied into a staging environment for a debugging session, and no record level audit log of who read what. Then a hospital partner or a payer asks for evidence before signing, and the answer takes months to construct.

The fix: build a closed loop results register owned by a role rather than a person, with a clock on every item and defined escalation when it stays open. Nothing closes silently, and every closure is logged with who and when, which is the artefact your malpractice carrier and a hospital partner will both ask for. On privacy, sign business associate agreements before the first line of code, scrub protected health information out of logs and error monitoring by construction rather than by policy, enforce that production data never reaches staging, and budget the security work as a real percentage of the build rather than negotiating it down.

Should you build custom or configure what you already own?

If you run one to three clinics on a single electronic medical record instance and what you actually want is online check in and a published wait time, buy Solv or Clockwise.MD, publish the number and go run your clinics. Below roughly forty thousand annual visits an operations layer will not pay for itself, and your regional director's spreadsheet is the correct tool. We would say that on the first call.

Keep Experity, athenahealth or eClinicalWorks as the chart. Keep QGenda or your existing scheduling tool for credentialing and fairness constraints, and let the operations layer feed it demand rather than replace it. Keep your clearinghouse. The build is the layer above all of them.

Build when you are past five sites or sixty thousand annual visits, when two or more record systems from acquisitions leave you with no single view, when occupational medicine has passed a meaningful share of visits and still runs out of an accounting package and a folder of faxes, when somebody's full time job is rebuilding a report, or when a payer or health system contract requires reporting your chart simply does not produce.

How do hidden costs get into the quote?

Interfaces are the first and largest. Each inherited record system is its own integration, the interface engine is a line item plus a per site monthly charge, and per transaction fees on some platforms mean your integration cost scales with your busiest weeks. Real time reliability is the second: a queue board that dies at 6pm on a Tuesday is worse than no queue board, so you are paying for redundancy and on call rather than a hobby deployment.

Revenue cycle scope is the third, because reading remittance files and modelling contract rates per payer per procedure roughly doubles the data model. Occupational medicine is the fourth and is effectively a second product, with employer rate cards, purchase orders, authorisation capture, a portal that shows an employer outcomes without disclosing information they are not entitled to, and invoicing. Privacy engineering is the fifth, and it is the one most often cut.

The fix: ask for interfaces priced per instance with the engine and its recurring cost stated, and ask what happens to the number when a sixth site on a different record system joins. Ask for occupational medicine quoted separately so you can sequence it. Then insist that one site is running the queue in production by week eight or nine rather than accepting a single launch across the network, because anything that has not touched a real lobby by week ten is a demonstration.

What separates a build that works from one that fails here?

Make them draw your data model before they quote. Patient, visit, encounter, employer, claim, authorisation, result and panel are eight different things with different lifetimes and different owners. If the whiteboard says appointments and users, they think this is a booking application. Ask where a workers compensation injury visit for an employee of a panel employer, with an adjuster authorisation and a state fee schedule, sits in their model, and watch whether they hesitate.

Make them prove interface experience rather than saying the word integration. Have you shipped health level seven admission and result feeds into production, through which engine, and what happened when the vendor quoted a per site monthly charge for the feed. Who did you deal with on the partner side and how many weeks did it take. Anyone can say interface. Very few have sat in that queue.

Treat compliance as engineering rather than a document, and ask specifically what they do about protected health information reaching error monitoring, because a monitoring service will happily retain a patient name forever. Then settle ownership and exit on day one: repositories in your organisation, infrastructure in your cloud accounts, secrets in your vault, and a runbook another firm could pick up cold. Ask to see a handover they have already done, then ask for the phone number of an operator they shipped this for and ask that operator what broke in week three.