You may want to listen for encounter updates if you want to follow up with patients after an outpatient visit. Typically, you can use this API action so that you are notified when any of these events occur within your connection’s EHR system:
You can use this API action if your system does any post-visit work, like sending a customer survey, providing post-appointment information, or offering services after an appointment. Or you may want to use this if you’re tracking general population health. The main purpose is if your system cares that a patient arrived for a visit or that there’s updated clinical information after a patient visit.
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.
Depending on your connection’s capabilities, you can opt in for lightweight or detailed notifications.
Typically, a lightweight notification is a bare bones message that says “something is new” or “something has changed,” along with the relevant identifier (e.g, patient, visit #). 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 has changed. This might be useful if you need to persist all that data in your system to complete your own unique workflow.
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 initiates a daily batch request 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.
Keep in mind that for the FHIR® API, encounter updates are different from scheduling updates. A scheduling update is related to new appointments, changes to appointments, or patient pre-work before an appointment. An encounter update, on the other hand, notifies you that a patient arrived for an appointment and that clinical data may be available. Learn more about listening 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.
If you want to follow up with a patient after a completed visit, we recommend that you listen for and time your workflow from the visit arrival instead of visit completion. This is a more reliable method since visit completion can be inconsistent.
A common use case for this is if you send patient surveys after a completed visit. In this case, you could listen for the visit arrival, then send the survey X hours after the visit arrival time. Whatever the use case, you can determine the most appropriate amount of time to begin your system’s workflow after the patient arrives for the visit.
It’s also important to note that you may not receive notification of a visit arrival immediately; these notifications are sent in batches, so you may receive notification of a visit arrival three to five days after the patient actually arrived for the visit. No-show notifications also may be delayed. Take that potential delay into account when determining the timing of your workflow.
If you want to track inpatient visits in addition to outpatient visits, we recommend that you listen for hospital admission updates too. Learn more about hospital admission updates.
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 one specific appointment or surgical case. An encounter ID could potentially 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.
Does this API action seem like a good fit for your unique workflow? If so, let your Redox rep know! You can begin development by downloading the relevant resource schema (which is noted in the relevant action step below), and deciding which data elements you need. Then head over to our Quickstart guide to dive right in.
If you're not engaged with our sales team yet, talk to a Redoxer to get started.
The EHR system sends a notification for each individual patient that checks in for a hospital or outpatient visit. To review technical specifications for this notification, refer to the Patient Arrived schema.
If you're listening for outpatient encounters, this step is required.
Upon receiving this type of message, you only need to respond with the relevant HTTP status code. After that, you decide what your system should do with the notification.
{"id": "PatientAdminEventPatientArrivedBundleExample","type": "message","entry": [{"resource": {"id": "RedoxMessageHeaderExample","source": {"name": "Good Health Clinics","endpoint": "05107c08-fe2f-4740-8c1d-c7107d18ebe5"},"eventCoding": {"code": "PatientAdmin-event-patient-arrived","system": "urn:redox:event-type"},"resourceType": "MessageHeader"}},{"fullUrl": "https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development/Patient?identifier=urn:redox:redox-fhir-sandbox:MR|kyHGADnvX3xbkU4V9ayaqh","resource": {"resourceType": "Patient"}},{"fullUrl": "https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development/Encounter?identifier=urn:redox:encounterId|zzz123Encounter","resource": {"class": {"code": "AMB","system": "http://terminology.hl7.org/ValueSet/v3-ActEncounterCode"},"status": "arrived","resourceType": "Encounter"}}],"timestamp": "2021-06-17T20:33:22.422Z","resourceType": "Bundle"}
For a visit context, the EHR system sends a notification for these scenarios:
To review technical specifications for this notification, refer to the Patient Registered schema.
Upon receiving this type of message, you only need to respond with the relevant HTTP status code. After that, you decide what your system should do with the notification.
{"id": "PatientAdminEventPatientRegisteredBundleExample","type": "message","entry": [{"resource": {"id": "RedoxMessageHeaderExample","source": {"name": "Good Health Clinics","endpoint": "05107c08-fe2f-4740-8c1d-c7107d18ebe5"},"eventCoding": {"code": "PatientAdmin-event-patient-registered","system": "urn:redox:event-type"},"resourceType": "MessageHeader"}},{"fullUrl": "https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development/Patient?identifier=urn:redox:redox-fhir-sandbox:MR|kyHGADnvX3xbkU4V9ayaqh","resource": {"resourceType": "Patient"}},{"fullUrl": "https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development/Encounter?identifier=urn:redox:encounterId|zzz123Encounter","resource": {"class": {"code": "AMB","system": "http://terminology.hl7.org/ValueSet/v3-ActEncounterCode"},"status": "planned","resourceType": "Encounter"}}],"timestamp": "2021-06-17T20:33:22.422Z","resourceType": "Bundle"}