Authentication
AdvancedMD tools use the existing AdvancedMD connector. Users configure:office_codeusernamepassword
AdvancedMD replaces the whole appointment on save
The scheduler endpoint is a whole-appointment replace, not a patch: any field left out of the payload is cleared. So this tool reads the current visit first and writes its time, duration, provider column, profile and telemedicine flag back unchanged. That is why it needs no arguments for them, and why it makes several AdvancedMD calls for one update. Two fields are worth knowing about:apptstatusis not sent. AdvancedMD appears to preserve it across a replace — fleming’s client omits it too and runs this endpoint in production daily — but that is inference from two agreeing clients rather than a verified fact. If a type change is ever seen to reset a confirmed or arrived appointment, this is the first place to look.- The telemedicine flag is carried from the existing appointment, because AdvancedMD exposes no lookup saying whether the new type is a telemedicine type. Converting into or out of one therefore preserves the old flag, which affects how the visit bills. Check it afterwards if that matters.
Ids resolved for you
Three ids AdvancedMD demands appear nowhere in its UI, so they are resolved rather than asked for:
If the fallback is reached and the heading matches nothing, the update is aborted before writing: an appointment saved without a valid column id moves off its provider’s schedule.
If the patient has several episodes, the tool stops and asks you to pass
episode_id — there is no “current” episode marker to choose by, and picking wrong bills the visit to the wrong episode.
Inputs
Both the name and the numeric id are required
The scheduler rejects an update whose type node carries no id, and there is no API that maps a type name to its id — so both have to be supplied together. A name/id mismatch is accepted by AdvancedMD and produces an appointment labelled one thing and coded as another.Outputs
The appointment’s
comments are carried over too, so a scheduling note survives the replace.
Eight fields AdvancedMD cannot tell us
Seven of them —colorv2, instruction, transitionofcare, tocrequestedavailable, iswaitlist, islegacy and istelemedtranscription — are not returned by any AdvancedMD read this tool can make, so a whole-appointment replace cannot echo them and sends AdvancedMD’s defaults instead. An appointment relying on a non-default value in one of those seven will have it reset. The values sent are pinned by a test so the set cannot change silently.
facilityid is in the same position — AdvancedMD returns the facility’s name and code on a visit read, never its numeric id — with one difference: rather than send a guess, it is omitted unless you pass facility_id. That matches the behaviour in production use today. If your appointments depend on a facility being set, pass facility_id explicitly rather than relying on the omission.
Dry run
dry_run additionally returns current_type — what is about to be replaced.
A dry run performs every lookup and guard the real write does: the visit read, the column, profile and episode resolution, and the abort conditions below. So a preview that succeeds has already cleared the checks that would otherwise fail on write, and a preview that fails names the same reason. It differs from a write in exactly one respect: it does not send the PUT.
This writes to a live schedule
A successful call changes what staff and the patient see. There is no undo: reverting means calling again with the original type and its numeric id.dry_run reports the current type’s name as current_type, but not its id — AdvancedMD returns @appointmenttype as a name on every read this tool can make, and exposes no lookup from name to id. So capture the id from wherever you got the one you are writing (the same source that told you the new type’s id) before you overwrite it; the tool’s own output cannot give it to you.