Stream: smart
Topic: SMART for Scheduling
Shamil Nizamov (Nov 01 2019 at 16:07):
I’m just wondering if it’s a correct use of SMART standard to schedule appointments. The idea is to bring a SMART App from a “scheduling” server, populate with data from the local EMR and send data back to the “scheduling” server or even third-party server to book the appointment.
This is somehow different what SMART is originally intended to do (handling and processing local EMR data). Also, there is an IHE mRFD profile that describes quite similar use case but it’s implemented differently.
Lloyd McKenzie (Nov 01 2019 at 16:13):
@Josh Mandel @Isaac Vetter
Tim Berezny (Nov 01 2019 at 17:00):
This is the main thing I use SMART for, everybody i've run the idea by who knows a thing or two about SMART has said it's good.
Shamil Nizamov (Nov 01 2019 at 17:09):
This is the main thing I use SMART for
@Tim Berezny Any link to a similar use case where a SMART app is used?
Isaac Vetter (Nov 01 2019 at 17:22):
Hey Shamil, your description sounds very much like a good use for SMART. I wouldn't say that there are "correct" uses of SMART, rather, the SMART app launch protocol is appropriate when the user's identity is known the EHR*, the app is user-facing and the app might want to interact with the EHR's apis.
*where EHR is short-hand for any system with an oauth and probably fhir server.
Isaac Vetter (Nov 01 2019 at 17:23):
Overall, it's extremely common for a SMART app to interact with sources of data other than the EHR/FHIR server associated with the SMART server.
Isaac Vetter (Nov 01 2019 at 17:23):
Lastly, my understanding of IHE's mRFD is that it's intended to describe HL7's SMART on FHIR in an IHE profile.
Shamil Nizamov (Nov 01 2019 at 17:28):
Overall, it's extremely common for a SMART app to interact with sources of data other than the EHR/FHIR server associated with the SMART server.
I see it as the case when the app is prepopulated with data from EMR which (data) then sent to some third-party (external) destination this SMART server is associated with. It's obviously can be done with SMART but is there rational of doing it if EMR may HTTP POST such data directly?
Isaac Vetter (Nov 01 2019 at 17:36):
I don't understand the bolded part:
the app is prepopulated with data from EMR which (data) then sent to some third-party (external) destination this SMART server is associated with.
but, otherwise, the rationale for using an app in-between the EHR and the scheduling system would be to provide additional UI and workflow as part of the submission of the appointment data to the scheduling system. If the SMART app is simply proxying information from the EHR to the scheduling system and doesn't need the user to interact with it's UI, I'd think that this integration isn't a great use for a SMART app launch.
Last updated: Apr 12 2022 at 19:14 UTC
