TheFhirStorm

AdvancedMD API notes: access, data, writes and gaps

Vendor APIs · · Abhinav Srivastava

You ask AdvancedMD for API documentation and get a sales contact instead of a link. That is how the program works. AdvancedMD runs two API tracks with different rules. The proprietary Connect APIs sit behind a paid developer agreement. The regulatory FHIR R4 APIs are open to register for, read-only, and documented in public.

Two tracks

The developer solutions page lists the options.

  • Connect APIs, also called Partner APIs. Proprietary, in XML-RPC and REST formats. The page says they "replicate nearly all functionality available within the AdvancedMD user interface" and are meant for real-time, transactional work.
  • FHIR APIs. FHIR R4, tied to AdvancedMD's certified EHR status, read-only, authorized with SMART on FHIR OAuth 2.0.
  • ODBC. A driver for bulk read-only pulls into a data warehouse, with scripts for full and delta loads.

Lab, imaging and HL7 v2 interfaces go through the partners Ellkay and Falkon Data. The page states that AdvancedMD does not directly support custom HL7 2.x interfaces for external developers.

Access process for Connect APIs

The developer solutions page lists the steps. Request an API Developer license. Sign the Certified API Developer Agreement, which "includes associated licensing and support fees". Receive the full documentation and a sandbox. Demonstrate the integration to the Interoperability (InterOps) team. Receive production credentials, including a unique appname.

The API connection request page adds detail. It is for software developers; AdvancedMD clients who want to connect to an existing partner use a different form. Full documentation needs a signed NDA or Developer Agreement. The page states there are "typically both upfront and ongoing monthly costs" for the license and for the sandbox. It gives no amounts.

The interoperability page describes the sandbox as an API Sandbox Key: a demo office key with login credentials, documentation and build tools. Sandboxes cannot hold real patient data. Its go-live list is: complete the API vendor worksheet, schedule a test if your app adds data, purchase an API Connect Agreement, receive live credentials.

The developer portal itself, developer.advancedmd.com, returned a 503 error each time I fetched it while writing this. Its Get Started and FAQ pages sit behind the agreement in any case, so this post describes only the public pages for Connect.

Data available

The public pages publish no Connect API endpoint list. The interoperability FAQ gives examples: run searches, add patients, schedule, and create charges and payments. It describes the API as a way to "push and/or pull data", which is the only public statement on write support for Connect. The developer solutions page says Connect covers nearly all UI functionality, and it sends developers who need create, update or delete to Connect rather than FHIR.

For FHIR the picture is precise. The FHIR portal states support for USCDI v3, US Core 6.1.0, SMART App Launch 2.2, Bulk Data 1.0.1, OAuth 2.0 and TLS 1.2 or higher. The getting started guide lists the resources behind patient/ and user/ scopes: AllergyIntolerance, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Immunization, Location, MedicationDispense, MedicationRequest, Observation, Organization, Patient, Practitioner, Procedure, Provenance, RelatedPerson, ServiceRequest and Specimen. Coverage is the only billing-adjacent resource in that list. No claim, charge, payment or remittance data is in the FHIR set.

Write support

FHIR: none. The FHIR portal states: "There is no capability to write back to AdvancedMD using FHIR APIs." The getting started guide repeats that the APIs are GET only and sends anyone who needs POST or PUT to sales for the Partner API.

Connect: the public pages say "push and/or pull" and describe creating patients, charges and payments. The exact writable objects are in the gated documentation.

FHIR registration and auth

Register on the FHIR portal with an email address. Create an app and request exactly one product: FHIR Single Patient API or FHIR Bulk API. The guide says not to request a second product on the same app. Then open a ticket with InterOps Support using the "Have a FHIR Question" option and reference the app name. The app is inactive until they approve it. Each approved app gets a client key and a client secret.

The guide states that AdvancedMD supports 3-legged OAuth with the authorization code grant, and adds: "We do not support two-legged OAuth method that is used for system-to-system interactions." The same portal lists a FHIR Bulk API and says a real bulk app generates its own JWT and sends it to AdvancedMD for configuration. The public pages do not reconcile these two statements. Ask InterOps which flow a bulk app should use before you build it.

Patients must opt in. The guide states that the API can only read data for patients who allowed sharing through AdvancedEHR, AdvancedPM and the Patient Portal API. Each patient's credentials include an Office Key, the unique identifier of the AdvancedMD client that holds their data. A test SMART launch page with test patients and providers is on the portal. The documented API version is 2.0.0 against AdvancedMD v25.

Documentation gaps

  • No public endpoint reference, rate limits, or sandbox base URL for Connect. All of it sits behind the Developer Agreement.
  • No fee amounts for the license, the sandbox or the API Connect Agreement.
  • No stated review time for the InterOps demonstration. The interoperability page gives "normally within 24 hours" for a sandbox key request only.
  • Conflicting statements on two-legged OAuth for Bulk FHIR, described above.
  • No FHIR service base URL on the pages above. AdvancedMD's 2024 fall release notes say it publishes a machine-readable list of FHIR service base URLs at no charge, but the page does not link it.
All posts