FHIR-native open-source RCM that unifies intake, coding, claims, and remittance for urgent care while shifting compliance and ops in-house.
Urgent care RCM works best when intake, coding, claims, and remittance use the same FHIR R4 record set.
CoverageEligibilityRequest and CoverageEligibilityResponse tie 270/271 checks to Coverage, so you can catch inactive plans and collect the right co-pay at check-in.Procedure and Condition link CPT 99202–99215 to ICD-10 support, and modifier 25 separates an E/M visit from a same-day procedure when both are billed.Claim maps to 837P with Place of Service 20 for freestanding urgent care, while ClaimResponse and PaymentReconciliation map payer results and 835 posting back to the same patient account.
FHIR-Native Urgent Care RCM Workflow: From Intake to Remittance
FHIR changes revenue cycle management by turning each handoff into a resource handoff instead of a messy app-to-app jump.
That shift matters. Intake, coding, billing, and remittance can all move through the same data model, which cuts down on friction and keeps each step tied to the source record.
| FHIR Resource | Revenue Cycle Stage | Function |
|---|---|---|
Patient / Coverage |
Intake | Registration data |
CoverageEligibilityRequest / CoverageEligibilityResponse |
Intake | 270/271 eligibility verification |
Encounter |
Visit | Visit lifecycle tracking |
Condition / Procedure |
Coding | ICD-10 and CPT mapping |
Claim |
Billing | 837P submission |
ClaimResponse |
Billing | Payer adjudication and denial capture |
PaymentReconciliation |
Remittance | Payment posting and balance closure |
In practice, Procedure carries CPT codes such as 99202–99215, while Condition carries the ICD-10 diagnosis that supports those codes. That link is a big deal for clean claims. If the diagnosis and procedure don’t line up, billing teams feel the pain almost right away.
The working-copy model adds another layer of control. Billing edits stay out of the signed chart. Instead, billing workflows clone Condition and Procedure resources into claim copies, and payer-specific edits happen on that copy. So the clinical record stays intact, while the billing team still gets room to do its job.
Access is split by role, which helps keep each team in its lane. ADMIN, PROVIDER, BILLING, and FRONT_DESK permissions are kept separate. For security, AES-256-GCM protects data at rest, and TLS protects data in transit. Immutable FHIR AuditEvent logs record every create, update, and delete, which gives teams a clear trail of what changed and when.
There’s also an infra payoff here. Terraform-managed environments make it possible to reproduce the same setup across AWS, Azure, and GCP. Cloud KMS manages encryption keys for encrypted storage, which keeps key handling tied to the cloud platform instead of scattered across custom scripts.
Real-time eligibility, accurate subscriber data, and card-on-file collection all happen in the intake workflow.
Real-time eligibility before the visit starts
Run CoverageEligibilityRequest during preregistration when a Coverage resource is created or updated. Then run the check again at Checked-In.
The CoverageEligibilityResponse gives staff real-time details on co-pay amounts, deductible status, and whether the plan is active. That means the team can collect the right co-pay for the visit type at check-in instead of trying to chase down a balance after adjudication.
Subscriber data and Place of Service 20
At registration, enter the subscriber ID, group number, and relationship to insured. Also set Place of Service 20 in registration before the Encounter opens.
Card on file through Stripe
Ottehr’s Stripe integration lets staff collect a card on file during check-in. Use the CoverageEligibilityResponse to estimate patient responsibility before checkout. After adjudication, the card on file is used to collect the remaining patient balance.
In a FHIR-native workflow, each diagnosis lands in Condition with ICD-10, each service lands in Procedure with CPT, and E/M 99202–99215 ties back to the Encounter resource.
That setup matters for one simple reason: billing works best when the chart and the claim speak the same language.
E/M codes 99202–99215 depend on MDM and total time stored in the Encounter resource. If MDM and time are documented in a structured way, the E/M level is much easier to support.
This is where clean data does a lot of heavy lifting. Instead of digging through loose notes, billing teams can pull from fields that map straight to the claim.
Use modifier 25 on the E/M code when an E/M service and a procedure happen on the same day. That tells the payer the visit work should be billed along with the procedure.
There’s another layer here too. Some payers use S9083 and S9088 for global case rates, so the charge master needs to switch codes by payer. Same visit, different billing logic depending on the plan.
Billing edits stay in a cloned claim copy, which leaves the signed chart unchanged. Ottehr's AI coding assistant suggests ICD-10 and CPT codes in the billing layer. A human reviewer approves the codes before claim drafting.
That “working copy” idea is practical. The clinical record stays locked as the source of truth, while the billing side gets room for claim-specific edits without muddying the chart.
Claims and remittance sit at the center of the back-office flow. Once coding is done, the next step is getting the claim out the door, posting the payer response, and sending denials to the right place.
ClaimResponse before PaymentReconciliation posts payment. That means mapping the 835 into PaymentReconciliation and denial codes into ClaimResponse, so the financial workflow stays tied to the FHIR setup with a standard, auditable trail.
Days in A/R and net collection rate both come back to 835 data. Days in A/R compares the 837 submission date to the 835 payment date. Net collection rate compares CLP04 with the allowed amount after CAS adjustments. One practical rule here: route denials before patient balances.
Open-source RCM gives the practice ownership of both the software and the data under AGPLv3 or MIT. That matters. The practice isn't boxed into a vendor's system, and it keeps control over how the setup is run and changed over time.
Billing rules live in modular adapter packs, while the canonical clinical store stays unchanged. In plain terms, billing logic can shift without rewriting the source clinical record. That separation helps keep payer-driven edits out of the core chart.
The compliance floor comes from role-based access, Consent enforcement, AuditEvent logs, and Terraform-managed infrastructure. Those pieces handle who can see what, whether permission is in place, what actions were taken, and how the stack is provisioned.
Billing staff review cloned claim drafts, and payer-specific edits remain outside the chart. That's a key line to hold. The claim may need tweaks for submission, but the clinical record should not be bent to fit a payer's rules.
Self-hosting also shifts more work to the practice. Patching, security governance, clinical risk management, and operational validation all become the practice's job. You get control, but you also carry the load.
Ottehr handles the intake, coding, claims, and remittance layer in an open-source EHR stack for urgent care RCM. Its main strength is simple: each revenue cycle task lives inside one FHIR-native stack instead of being split across disconnected tools.
Intake: The AI intake chatbot gathers HPI and medical history before registration. At check-in, Stripe-backed payment processing stores card-on-file details. That intake data then becomes the starting point for charge capture.
Coding: The ambient scribe records the encounter, and the AI coding assistant suggests CPT and ICD-10 codes for charge capture. Since Ottehr stores clinical data as FHIR resources, the coding layer can read Encounter, Condition, and Procedure resources directly. It does this without changing the original chart or narrative note.
Claims: Claims and remittance run through Ottehr's submission and posting layer. Denial management sends denied claims into a follow-up worklist. The 835 remittance drives payment posting, and Stripe collects the patient balance. FHIR-native analytics track clean claim rate, denial rate, days in A/R, net collection rate, and patient responsibility collection rate. Those metrics act as checks on claim quality, payment timing, and patient balance recovery.
Zambdas - Ottehr's serverless functions - handle key handoffs across the cycle. For example, a Zambda can trigger claim generation when a provider signs an encounter, route a denial to the billing worklist, and require a coding review before submission.
The open-source deployment can be self-supported by in-house technical teams. If that team is stretched thin, MassLight and Ottehr engineers can step in with implementation and operational support.
Open source RCM is a staffing and governance decision before it’s a licensing decision. You may cut out license fees, but compliance, security, and day-to-day operations don’t disappear. They move in-house.
No license fee is not the same as no vendor cost. Ottehr runs on Oystehr, a commercial hosted FHIR backend with platform costs. You also still need to pay for cloud infrastructure, PostgreSQL, Redis, Amazon S3, Keycloak or Auth0, and HashiCorp Vault. On top of that, third-party costs stay on the books for payment processing fees, EPCS fees, and SMS/fax gateway fees.
Over a multi-year period, total cost of ownership comes down to people as much as software. That usually means engineers who can work in React, Node.js, TypeScript, and Terraform; DevOps support for CI/CD and containers; a security lead for HIPAA controls and audit logs; and billing staff who can handle credentialing, claims, denial management, and patient A/R.
Put plainly, every core function needs a clear owner. That includes intake, coding, claims, remittance, security, and billing. If no one owns those jobs, the system starts to drift.
Open source RCM makes the most sense for organizations that are ready to staff those functions.
Open source RCM makes sense when one FHIR-native data model keeps documentation, eligibility, claims, and KPI tracking in sync. Billing edits stay tied to the chart. And each step in the revenue cycle moves through the same resource set, which helps avoid messy handoff gaps.
The tradeoff is simple: the practice owns the operations. HIPAA compliance, security, audit readiness, patching, and engineering ownership all stay in-house. And with Ottehr's commercial hosted FHIR backend and support model, there is still a platform cost. No license fee does not mean no vendor cost.
Open source RCM is a fit for practices that are ready to staff security, billing, and infrastructure on their own.
The working-copy model protects the chart by making cloned versions of FHIR resources for billing edits. Any payer-specific claim changes live in those copied resources, so the original clinical chart stays untouched.
In urgent care RCM, that separation helps keep the chart intact while billing works from resources like Claim, Condition, and Procedure for submission, remittance, and denial follow-up.
It marks the visit as urgent care, and that changes how the claim gets billed and processed.
In urgent care RCM, the care setting ties into real-time eligibility checks, coding for 99202–99215, and modifier 25 when it applies. The claim is then sent on an 837P, while the 835 remittance guides payment posting and net collection rate.
Open-source RCM shifts the work to your team. That means you need both revenue cycle staff and technical staff in place.
On the revenue cycle side, the team has to manage real-time 270/271 eligibility checks at intake, accurate ICD-10 coding, proper modifier 25 use, 837P claim submission, and 835 remittance posting.
On the technical side, self-hosting means you need in-house skill with React, Node.js, TypeScript, and Terraform. Your team also has to handle HIPAA configuration, patching, and audit readiness.
The tradeoff is pretty simple: license fees disappear, but staffing and infrastructure costs become your responsibility.
