"EHR integration" for Acumatica means one thing in practice: a one-way (or carefully scoped two-way) financial feed from a purpose-built Electronic Health Records system into the ERP's general ledger and AR. It does not mean Acumatica consumes or stores clinical records — I want that stated plainly before the architecture, because the integration design only makes sense once that boundary is fixed.
HL7/FHIR lives on the EHR side, not in Acumatica
Acumatica has no native HL7 or FHIR support — it is not a healthcare interoperability platform and was never built to be one. The EHR (or an integration engine sitting in front of it) is where FHIR resources like Encounter, Claim, or ExplanationOfBenefit get produced. The realistic integration point is a middle layer — a small service you own, or the EHR's own export/webhook capability — that consumes clinical-billing events and translates only the financial fields into Acumatica's REST API shape.
EHR (FHIR Claim / ExplanationOfBenefit event)
| webhook or scheduled export, FHIR resource
v
Integration service (translates: strips diagnosis/clinical
| codes, keeps billed amount + date + payer)
v
Acumatica REST API POST /entity/Default/24.200.001/ARInvoice
(invoice references an external claim ID for reconciliation,
not a patient identifier)What crosses the boundary, explicitly
The translation step in that middle layer is the actual engineering work, and its job is subtractive: take a rich clinical-billing event and keep only what accounting needs — billed amount, service date, payer, an external claim reference for reconciliation — while dropping diagnosis codes, procedure detail tied to a named patient, and anything else that would pull PHI into the ERP unnecessarily. An external claim ID lets someone reconcile an Acumatica AR line back to the EHR's record without the EHR ever having to hand over clinical content.
Polling versus webhooks, and why it matters more here
Acumatica supports both scheduled REST polling and outbound Business Events/webhooks for triggering integration flows. For an EHR feed I lean toward the integration service polling the EHR (or receiving the EHR's own webhook) and pushing to Acumatica on its own schedule, rather than exposing an inbound webhook endpoint on the Acumatica side that the EHR calls directly. Reasoning: it keeps the credential and network exposure on the integration service, which you control end to end, rather than requiring the EHR vendor to hold Acumatica API credentials.
The most common failure I have seen in claims-to-ERP feeds is a non-unique or reused external claim reference, which causes duplicate AR invoices or silently overwrites a prior one. Enforce uniqueness on the external reference field with a database constraint or a graph-level duplicate check before insert, and log every rejected duplicate rather than silently dropping it — a silently dropped claim is a silently missing invoice, discovered at month-end close.
Wrapping up
EHR integration with Acumatica is a financial-summary feed, not a clinical data pipeline — HL7/FHIR processing happens upstream, and the integration layer's real job is stripping clinical content down to the billing facts Acumatica actually needs. Keep the translation boundary explicit, own the credentials on your side, and guard against duplicate claim references from day one.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.