Building: Smart Data Element (SDE) write back & synced variables
Purpose
Programs wish for W2H to write back information to Epic SDEs, which are like variables, to drive downstream functionality.
For example, when patients complete medication refill requests via text in our pharmacy programs, W2H writes back information like the medication name, dose, refills remaining, shipping address, and more, to distinct SDEs in Epic. Pharmacy technicians use an Epic Smart Phrase to automatically pull these SDE values into a note to maximize documentation efficiency.
In another use case, the I-Screen research trial at LGH, W2H writes back to an encounter-level SDE when patients receive an automated text message reminder to schedule their mammogram prior to an upcoming primary care appointment. This SDE being set drives a banner display in Epic when the PCP opens that patient’s encounter, nudging them to discuss the screening with the patient.
In the above use cases, W2H supported these efforts as custom integrations, but there is now a core platform feature to support this work!
When to use SDEs vs. Flowsheets?
Flowsheets are great for tracking data longitudinally because historical data is maintained – each time W2H writes to a flowsheet, a new column generates with the data from that submission, and all the prior columns remain. On the other hand, SDEs aren’t used to capture longitudinal data and are more like W2H variables, where updating the variable overwrites the previous value.
SDEs are the preferred approach when storing the data longitudinally isn’t required because they’re easier for IS analysts to implement.
Note that the pharmacy use case does maintain a longterm record of the medication information, yet that record is in the notes that the techs document using the current SDE values, even though the SDEs themselves are continuously being overwritten for patients at each refill check that they complete.
Best practices for SDE approvals and governance:
When deciding whether SDEs are the right solution for a project team, clinical leads should:
Discuss the challenge and solution with their peers in your department/area (to reach consensus and get buy-in)
Open a Service Desk request to get the proposed solution vetted by an expert (or to get alternative solutions)
Present it to the Governance group that is closest to their area.
If the expectation is that providers or staff from other departments will interact with the new work, then their governance would want to discuss it as well. For instance Derm has their own governance group which is fairly independent but when they expect say PCPs to do something they need to bring that to the Primary Care Service Line governance and may need to present it at the all-Ambulatory “EMR/Amb Operations”
If a department does not have their own dept/SL governance, then I believe it would trickle up to:
the EMR/AMB Ops if Amb,
IP-Enterprise if IP,
ED Providers/etc. if ED,
unknown for home health
If the request is to create new SDEs so that W2H can write to them via the Epic APIs for providers/staff to use that data in Notes via smart tools, then this would also go to the API/FHIR Governance group which meets monthly. These SDEs are often at the patient-level, but there are other options like encounter-level SDEs. It’s important to figure out which type we’ll need (most frequently W2H uses patient-level SDEs).
Creating new SDEs
Clinical leads should submit an IS ticket to have new SDEs created for each field or value of interest. Typically, there is an IS analyst dedicated to each department or group who can help with work like this. If not, talk to Mohan about the request. In select cases, we can request Gordon Tait’s help creating new SDEs.
Once built, we should request the SDE IDs and types (internal or SDI).
Configuring SDEs in a W2H build
Go to manage study > SDE configurations.
Click the +New SDE configuration button. Enter the SDE ID and type provided by IS and give the SDE a description, ideally describing the data that W2H will write to it.
Finally, indicate whether the SDE is at the patient or encounter level. Most often, SDEs we configure are attributed to the patient, like in the pharmacy use case described above.
If the SDE is intended to drive functionality for an encounter, like in the I-Screen use case described above, select encounter. Encounter-level SDEs require the inclusion of CSN, which can be determined by pulling the CSN from the participant’s W2H profile or a variable value.
Syncing variables to SDEs
Once your SDE configurations are complete, you may sync a W2H variable to a SDE in each variable’s configuration page as shown below. Once this connection is established, anytime the variable value updates for a participant in the program, W2H will update the corresponding SDE value in Epic for them.
Often, we will use logic defined on a form submission (like a completed conversation or survey) to modify variables, and doing so will update the synced SDE in Epic.