Stream: argonaut
Topic: Scheduling
Josh Mandel (Jun 03 2019 at 21:10):
In the scheduling IG, this section on open scheduling for patients suggests that a scheduling client can post a new patient to the EHR:
New Patients
To register a new patient, The Client SHALL use the standard FHIR RESTful create API as follows:
POST [base]/Patient
Josh Mandel (Jun 03 2019 at 21:11):
Has this been implemented by anyone? @Brandon LaRue do you have any context on this?
Brandon LaRue (Jun 03 2019 at 22:54):
Cerner has a non-Argonaut scheduling implementation that has implemented a patient create. https://fhir.cerner.com/millennium/dstu2/individuals/patient/#create
Josh Mandel (Jun 04 2019 at 17:04):
@Jenni Syed is this Patient create used as part of Cerner's open scheduling support?
Drew Torres (Jun 04 2019 at 17:05):
Yes
Josh Mandel (Jun 04 2019 at 17:06):
Thanks Drew! For clients that call this API, how are they authorized/authenticated? Is this a SMART Backend Services type scenario?
Drew Torres (Jun 04 2019 at 17:08):
Yes and no. We haven't fully implemented SMART Backend Services, but it is the client credential flow for OAuth using the SMART scopes of system/Patient.create
Josh Mandel (Jun 04 2019 at 17:11):
Cool!
Cooper Thompson (Jun 04 2019 at 21:50):
Epic also supports patient.create for our Argonaut scheduling implementation. One caveat is that our current implementation of the Argonaut scheduling IG is "provider-to-provider". I.e. we don't use FHIR for open patient self-scheduling. We also use OAuth2 client credentials.
Josh Mandel (Jun 04 2019 at 21:53):
Thanks! I'm curious for the open patient scheduling scenario: has anyone considered a workflow that looks a bit more like airline booking, where the available slots are exposed to various scheduling apps through a read API but a user is sent over to the health system via deep link to actually complete the booking?
Drew Torres (Jun 05 2019 at 13:51):
The slots are open, but the user being sent over via deep link may be problematic. They don't have a person record, and as such the app has to establish the person record before allowing the patient to complete booking.
Josh Mandel (Jun 05 2019 at 13:58):
I guess the question is why does the app need to do this part? When I click from Travelocity to Delta, they don't need to send Delta a record who I am
Josh Mandel (Jun 05 2019 at 13:58):
In this analogy, the app is travelocity and the health system is Delta
Drew Torres (Jun 05 2019 at 14:04):
But someone does collect demographics from you to complete the booking.
Josh Mandel (Jun 05 2019 at 14:05):
Yes, and I'm wondering if this could be captured at the health system (e.g. in their web portal, etc).
Josh Mandel (Jun 05 2019 at 14:05):
Just trying to understand the design of the current system, which has a lot of moving parts on the standards level and has not yet and widely adopted.
Josh Mandel (Jun 05 2019 at 14:07):
I seem to require a lot of trust in third party apps, to look up arbitrary patient and create new records, etc. System level trust.
Drew Torres (Jun 05 2019 at 14:07):
What is the problem you are trying to understand? I may be oversimplifying, but what you describe seems identical to what is happening in production today with the APIs we provide.
Josh Mandel (Jun 05 2019 at 14:08):
Cerner may have an API like this in production for open scheduling, but I'm not sure that others do. and I'm not sure what it takes for me to develop an app that's allowed to connect to the Cerner endpoints. Seems like I would need to achieve a very high level of trust.
Josh Mandel (Jun 05 2019 at 14:09):
I'm just coming late to the discussion and trying to understand the trade-offs that went into it
Drew Torres (Jun 05 2019 at 14:48):
You are absolutely correct about the high level of trust to create appointments. We view this feature as a "premium" capability that requires additional vetting of the developers trying to interact with these particular APIs.
Drew Torres (Jun 05 2019 at 14:48):
There is a bit of a chicken and egg problem too because some organizations don't support self scheduling at all. So deep linking may result in a site that gives you a phone number to call.
Drew Torres (Jun 05 2019 at 14:51):
But to counter your point a bit though about the high bar. At Cerner, we have open sandbox that allows you to test all of this functionality with no interaction from us or our clients (the registration may take a day or 2 while we provision the system app), but the discovery/R&D phase should quickly determine whether the desired goal is achievable.
Josh Mandel (Jun 05 2019 at 17:03):
OK, thanks! A sandbox is great, but dev tooling a separate question from production support.
Josh Mandel (Jun 05 2019 at 17:03):
Are there organizations that do support self scheduling through some kind of form where deep links would work? Or would that be imagining whole new kinds of capability from scratch?
Drew Torres (Jun 05 2019 at 17:20):
That does exist in the wild. It is generally coupled with the identity provider. Health systems that protect their infrastructure using their own homegrown or purchased IdP have their own mechanisms that allow for this user record to be created. Depending on the "level of validity" the user may be allowed to do different things (view education vs actually scheduling). When a client is using Cerner's portal they would step through our account creation and scheduling workflows.
Both scenarios aren't always ideal because it requires the account to be created. Some health systems don't want to create barriers and just want the patient to have a confirmed appointment. There has been some supporting information about the likelihood of canceled appointments being lowered because it was self scheduled.
I think ultimately answers/desired states will vary amongst the different health systems. I have had a health system tell me: "I don't even care if EMPI happens. I want new patients to be able to book online."
Last updated: Apr 12 2022 at 19:14 UTC
