TheFhirStorm

Office Ally integration when the PM has no public API

Vendor APIs · · Abhinav Srivastava

A practice runs its schedule and billing in Office Ally Practice Mate and asks you to pull its patients and claims. You look for a Practice Mate API and find none. Office Ally's Practice Mate page lists scheduling, billing, claims and reports as features and says nothing about an API, an export or an interface. The developer page that Office Ally does publish covers its clearinghouse, not its practice management system. This shape is common: the PM has no general API, but the billing traffic around it is standard X12 and reachable.

What Office Ally does publish

The developer page offers REST APIs for eligibility, claim status and CMS esMD attachments, with sign-up at api.officeally.io. The EDI Clearinghouse page lists the transactions: 270/271 eligibility, 837P, 837I and 837D claims, 276/277 claim status, 835 remittance, and attachments, over SFTP, API, SOAP or MIME, in real time or batch.

The RestAPI companion guide states the entry condition: you must be an Office Ally customer with an account number, and you email realtime_support@officeally.com to be set up as a Realtime RestAPI EDI Submitter and receive an API key. The guide points to an OpenAPI document at https://edi.officeally.io/swagger/v1/swagger.json. The v2 document lists these operations, each authenticated with an API key in the Authorization header.

POST /v2/professional-claims         submit an X12 837P file (max 1 MB)
POST /v2/professional-claims/search
POST /v2/institutional-claims        submit an X12 837I file
POST /v2/dental-claims               submit an X12 837D file
POST /v2/eligibility                 JSON 270 in, JSON 271 out
POST /v2/eligibility/x12             raw X12 270 wrapped in JSON
POST /v2/claim-status                JSON 276 in, JSON 277 out
GET  /v2/eligibility/{transactionId}
GET  /v2/claim-status/{transactionId}

The Realtime EDI companion guide covers the older path: CAQH CORE SOAP at https://wsd.officeally.com/TransactionService/rtx.svc and MIME at https://wsd.officeally.com/TransactionSite/realtime-request/MIME, with a username and password issued at onboarding, receiver ID OFFALLY, and X12 5010 270 or 276 payloads inside a COREEnvelopeRealTimeRequest.

For clinical data, a separate FHIR R4 access document for EHR 24/7 lists ten read-only resources: Patient, AllergyIntolerance, Condition, Procedure, Observation, DiagnosticReport, DocumentReference, MedicationRequest, Immunization and CarePlan. Access goes through a request form and a review. The document states that "submitting a request does not guarantee access" and that write access "is not currently available". None of this reaches the Practice Mate schedule or ledger.

What practices and vendors do instead

Treat the clearinghouse as the integration point

Office Ally runs both the PM and a clearinghouse. Claims the practice sends through the clearinghouse are 837 files. Remits come back as 835 files. Status comes back as 277 responses and as EDI status reports. A vendor that needs claim and payment data can work at that layer. The forms and manuals page publishes 837P and 837I companion guides, a Custom CSV EDI Status Report guide, and ERA setup instructions. Each payer needs its own ERA enrollment, documented on the payer ERA enrollment page.

Submit on the practice's behalf

A billing vendor can build the 837 in its own system and submit it under the practice's Office Ally account, over SFTP or through the REST claim endpoints above. The 837P companion guide and the "Claim Workarounds for Print Image Submitters" guide on the forms page exist for this third-party submitter case. Practice Mate publishes no import for those claims, so the PM and the vendor's system hold separate records.

Use the real-time transactions for front-desk work

Eligibility (270/271) and claim status (276/277) are available in real time by REST, SOAP or MIME. An intake or scheduling product can check coverage before a visit without touching Practice Mate, as long as the practice is the Office Ally customer and the vendor is set up as its submitter.

Work the portal by hand

What the files and transactions do not carry, staff read from the web application. Appointment lists, demographic changes and ledger detail stay inside Practice Mate. Some vendors automate a browser against the portal. Office Ally's user agreement governs that use. Read it before you build on it, and expect the portal to change without notice.

Tradeoffs

  • You learn X12. The REST endpoints accept JSON 270 and 276, but claim submission takes an X12 837 file and the 835 is X12. The companion guides assume you hold the X12 TR3 licenses.
  • Access rides on the practice's account. The API key, SFTP login and submitter ID belong to the customer. If the practice leaves Office Ally, the integration goes with it.
  • Payer enrollment is per payer and per transaction type. ERA and some eligibility connections need forms before data flows.
  • You get the billing stream, not the PM record. Appointments, patient balances as Practice Mate computes them, and notes are out of reach. Two systems hold two versions of the patient.
  • Latency differs by channel. Eligibility and claim status are real time. Claim acknowledgements and remits arrive in batch on the payer's schedule.
  • Pricing is not on the developer page. The Practice Mate page says there is no monthly fee but transactional fees may apply. Ask before you size the volume.

The same pattern applies to any PM that publishes no general API. Find where the standard transactions enter and leave, obtain submitter access under the practice's account, and accept that the PM's own screens stay a manual step. TheFhirStorm returns claim, eligibility, claim status and remit data in one schema regardless of which system produced it.

All posts