Onboarding includes figuring out your data needs and operational workflow. Based on our extensive experience, we can help get the juices flowing to help you design your integration strategy with these areas to think about.
We recommend checking out our common API actions to get or send the data you need. Or, if you want to get more technical, review our API reference for the technical specifications for your integration.
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:
Single-sign on (SSO) may seem like a convenient trigger event if users launch your system from a patient context. But we recommend collecting patient data beforehand since the user has to wait for their redirect link. Otherwise, your system would be working to gather data and create a patient-specific landing page from scratch simultaneously. So, we recommend having the necessary data to launch so that all you need to do is send back the correct redirect.
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:
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:
Type of data
Redox data model
Patient encounter details
Diagnostic report or order results
Documents (e.g., PDFs)
Patient vitals or discrete clinical values
If you're unfamiliar with saving data to an EHR system, we recommend starting with non-discrete data, like sending a PDF (using DocumentReference with the Redox FHIR® API or Notes or Results with the Redox Data Model API).