> ## Documentation Index > Fetch the complete documentation index at: https://agents.nanonets.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # advancedmd_update_appointment_type > Change a booked AdvancedMD appointment's type while preserving its slot. Rewrites a booked appointment's type — for example converting a visit to a MIPS-eligible type — via AdvancedMD's scheduler API. ## Authentication AdvancedMD tools use the existing AdvancedMD connector. Users configure: * `office_code` * `username` * `password` The connector performs AdvancedMD's two-step API login, discovers the tenant API base URL, caches the security token, and refreshes it when needed. ## 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: * **`apptstatus` is 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. Practical consequence: **the appointment must exist and be readable**. If the visit lookup fails, nothing is written rather than an appointment being written with blank slot fields. ## Ids resolved for you Three ids AdvancedMD demands appear nowhere in its UI, so they are resolved rather than asked for: | Id | How it is resolved | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Column id | From the visit's own numeric column. Only if AdvancedMD omits it does this fall back to matching the column heading against the office's columns | | Profile id | From the visit's own profile | | Episode id | From the patient's episodes — automatically **only when there is exactly one** | 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 | Field | Required | Description | | --------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `visit_id` | yes | AdvancedMD visit/appointment id to update | | `patient_id` | yes | AdvancedMD patient id on that appointment | | `appointment_type` | yes | The new type's name, exactly as configured in AdvancedMD | | `appointment_type_id` | yes | The new type's AdvancedMD **numeric id** | | `color` | no | Scheduler colour, in the form AdvancedMD expects. Omit it and the appointment keeps its current colour, which the result reports back. | | `facility_id` | no | Omit or `0` to leave the facility unchanged | | `episode_id` | no | Required when the patient has more than one episode | | `dry_run` | no | Run the full resolution and report what would be written, without writing | ### 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 | Field | Description | | ------------------------------------------------------- | ----------------------------------------------------------------------- | | `status` | `success` or `dry_run` | | `visit_id`, `patient_id` | The validated ids the write used | | `column_id`, `profile_id`, `episode_id` | The ids that were resolved | | `start_datetime`, `duration_minutes`, `is_telemedicine` | The slot fields carried over unchanged | | `appointment_type`, `appointment_type_id` | What was written | | `color` | The colour written — the appointment's existing one when you omitted it | 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. ## Expected errors | Situation | Behaviour | | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Any required field missing, or `appointment_type_id` not positive | Error before AdvancedMD is contacted | | Visit not found | Error; nothing written | | `patient_id` is not the patient on that visit | Error; nothing written — the tool will not reassign an appointment to another patient. Zero-padded and float-encoded ids (`pat007`, `11157872.00`) are accepted as the same patient | | The visit read returns no patient id | Error; nothing written. The pairing cannot be verified, and unverified is not treated as approved | | Visit has no usable duration, start time or profile | Error naming the field; nothing written | | Column heading matches no scheduler column | Error; nothing written | | Patient has several episodes and `episode_id` was omitted | Error listing the episode ids; nothing written | | Patient has no episode | Error — the scheduler requires one | | Security token rejected | Re-authenticated and replayed once automatically |