# Listen for outpatient encounters You may want to listen for encounter updates to follow up with patients after an outpatient visit. ## Use cases This API action may be a good fit for your organization if you want to be notified about these events in your connection’s EHR system: - A patient arrived for a scheduled outpatient appointment. - A patient arrived for a telehealth appointment and is waiting for a provider. - A patient arrived for a walk-in outpatient appointment. After getting these notifications, you can query for more information or kick off your post-visit or general population health workflow, like these types of use cases: - Send a customer survey. - Provide post-appointment information. - Offer patient services after an appointment. Ultimately, this API action is useful if your organization cares that a patient showed up for a visit or that there’s updated clinical information after a patient visit. ## Supported systems You can receive notifications like this with the Redox FHIR API. Your connection's system can push notifications with a polling or subscription type of system. > **Lightweight or detailed notification** > > Depending on your connection’s capabilities, you can opt in for lightweight or detailed notifications. > > A lightweight notification is typically a bare bones message with the relevant identifier (e.g., patient, visit #) and an indication of “something's new” or “something has changed.” Lightweight notifications generally trigger you to do something within your own workflow or to query for more information. > > On the other hand, a detailed notification means that you receive all the data about what’s new or what's changed. This might be useful if you need to persist all that data in your system to complete your own unique workflow. ## Things you need to know
Not real-time updates While you _do_ get notified that a patient arrived for an appointment, the EHR system doesn’t necessarily provide real-time notifications. The EHR system typically sends a daily batch with data payloads for all patients that arrived for a scheduled appointment or walked in for an appointment. However, the batch may contain data for appointments that occurred three to five days beforehand. Just take that into account as you’re planning your own workflow around this data.
Encounter versus scheduling Encounter updates are different from scheduling updates. An encounter notification is related to a patient arriving for an appointment. Usually, if a patient arrived for an encounter, then clinical data might be available. After getting this kind of notification, you can either ask for more information or follow up with the patient (e.g., send a patient survey). A scheduling notification, on the other hand, is related to new appointments, changes to appointments, or pre-work before a patient appointment. [Learn about listening for scheduling updates](/fhir-api-actions/visit-and-scheduling/listen-for-scheduling-updates).  There should be a related encounter for a scheduled appointment, but there won’t be an encounter if the patient is a no-show. Also, an encounter may exist without a scheduled appointment if a patient is a walk-in. 
Visit arrival instead of visit completion If you want to follow up with a patient after a completed visit, we recommend listening for and timing your workflow from the visit arrival, not visit completion. This is a more reliable method since visit completion can be inconsistent. A common use case is for organizations sending patient surveys after a completed visit. If this is your use case, you could listen for the visit arrival, then send the survey X hours after the visit arrival time. You determine the appropriate amount of time between patient arrival and kicking off your unique workflow, no matter the use case. Keep in mind, though, that you likely won't receive real-time notifications when a patient arrives for a visit. Visit arrival notifications are typically sent in batches. So, it's possible to receive visit arrival notifications three to five days after the patient actually arrived for the visit. No-show notifications may also be delayed. Take those potential delays into account when determining the timing of your workflow.
Inpatient and outpatient visits If you want to track inpatient visits in addition to outpatient visits, we recommend listening for hospital admission updates, too. [Learn about hospital admission updates](/fhir-api-actions/visit-and-scheduling/listen-for-hospital-admission-updates).
Encounter ID versus visit ID You may hear the terms encounter ID and visit ID (or encounter number and visit number for the Data Model API). A visit ID represents a specific appointment or surgical case. An encounter ID could represent one specific appointment or a bundle of appointments related to a single event. For example, a surgery encounter may include pre-op evaluation, surgical case, and post-op all under one encounter ID, but there would be three separate visit IDs. Some EHR systems prefer using the encounter ID instead of the visit ID because of how it's filed in their system. We recommend that you check with your connection to see which one you can expect to use.
> **What's next? ** > > Does this API action seem like a good fit for your unique workflow? Let your Technical Account Manager know! To start development, download the resource schema noted in the related action step. Then decide which data elements you need. > > If you’re new to Redox, [use the Quickstart guide](/quickstart-for-redox) to dive in. If you’re not engaged with our sales team yet, [talk to a Redoxer](https://redoxengine.com/forms/contact-us/) to get started.