Design your integration strategy

First things first, when and how do you become aware of a patient you need to work with? In other words, when should you start collecting and storing data about a patient from a technical perspective?

It's helpful to identify the appropriate trigger event (operationally, not technically) and whether it occurs in your system or your connection's system. Here are a few common trigger events:

1. Searching for a patient: You may start your operational workflow by searching for a patient in your connection's system so that you can tie your patient record to the one in the EHR system.
2. Scheduling a patient appointment: If your workflow centers around appointments, your workflow may begin after getting notified about a new appointment in your connection's system.
3. Searching for admitted patients: If your workflow centers around admitted patients, you may want to begin by querying for a full list of patients.
4. Placing an order for a patient: If your workflow centers around services ordered for a patient, your workflow may begin after getting notified about a new order or querying for orders yourself.

Trigger events typically have related API actions (check out our API actions). For example, if the trigger occurs in your connection's system, they could send an event-based notification with the data being recorded at the time of the event. Or, if the trigger occurs in your system, you may need to write data back to your connection's system.

Keep in mind that not all EHR systems support related API actions, so talk to your Redox team and your connection about what to expect. Also, if the workflow starts in your system, you should consider how to best tie your patient record or data to the EHR system record and whether there’s any additional data you need to query for to complete the patient record in your system. 

Trigger events and their related data may not be enough to complete the patient record in your system. You may need to gather additional data after you start storing data about a patient. You could do this by querying for more details, or you may want to receive a feed of more data to keep your system up-to-date.

Most importantly, you must be able to identify when the additional data is created or sent from your connection's system. For example, if your system requires discharge information to complete your workflow, but the trigger event is a notification that the patient was admitted to a hospital, you may need to wait for the discharge to happen before being able to access the necessary data. To determine the best timing for gathering additional data, you should consider:

1. Do you have the right trigger event? It's possible that a later event would be more appropriate if the data isn't available earlier.
2. Is there data you receive that can't be queried and needs to be stored until you're ready to use it later?
3. Does your connection's system have any timing limitations for providing additional data or does another event need to occur first?

After completing patient care or capturing clinical details, you may need to update a patient's chart in your connection's system. Not all EHR systems require or support writeback messages, but some require it if the data you capture is necessary for their clinical decision making.

Here are some common FHIR® resources or data models you can use for saving data: