Stream: smart
Topic: Is `context-standalone-patient` required by the ONC rule?
Isaac Vetter (Mar 10 2020 at 04:00):
context-standalone-patient and context-standalone-encounter are two SMART capabilities, included in the "core capabilities", but (I think) not widely implemented. They effectively require a SMART server to present a patient/encounter chooser during the launch process, before redirecting to the SMART app. Does the ONC rule require support for these capabilities?
Given the importance of these “SMART on FHIR Core Capabilities,” and in consideration of public comments and our own research, we have adopted the SMART IG, including mandatory support for the “SMART on FHIR Core Capabilities” in § 170.215(a)(3).
pg 383
That's a yes, right?
Josh Mandel (Mar 10 2020 at 15:22):
Yes -- and I think re: context-standalone-patient, basically every patient-facing SMART API does this today (often rather than a patient picker, it's just "here's your account").
Re context-standalone-encounter, I haven't seen this implemented in the wild
Josh Mandel (Mar 10 2020 at 15:24):
I'm puzzled that ONC would require support for all capabilities including the experimental smart_style_url.
Josh Mandel (Mar 10 2020 at 15:25):
Our recommendations were more focused (sso-openid-connect, launch-standalone, launch-ehr, client-public, client-confidential-symmetric, context-ehr-patient, context-standalone-patient, permission-patient, permission-user, permission-offline)
Isaac Vetter (Apr 06 2020 at 13:42):
Further, note that the CMS rule just picks up the ONC rule's language on SMART, so, for payers, core capabilities support is mandated beginning Jan 1, 2021. Do any of the "off the shelf" SMART servers support all of this?
Josh Mandel (Apr 06 2020 at 13:50):
Not that I've seen (but this kind of functionality is implemented in the SMART Launcher as a reference)
Josh Mandel (Apr 06 2020 at 13:51):
I'm not entirely clear on whether the core capabilities apply to payers (I'm not saying they don't, but I couldn't quite connect the dots) -- though in any case, supporting most of this is clearly in scope.
Isaac Vetter (Apr 06 2020 at 13:53):
“We are finalizing as proposed to require compliance with 45 CFR 170.215 as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). This requires use of HL7 FHIR Release 4.0.1, and complementary security and app registration protocols, specifically the SMART Application Launch Implementation Guide (SMART IG) 1.0.0 (including mandatory support for the “SMART on FHIR Core Capabilities”), which is a profile of the OAuth 2.0 specification, and the OpenID Connect Core 1.0 standard”
Josh Mandel (Apr 06 2020 at 13:59):
Thanks! That is exactly the thing I wanted, and I'd forgotten it or hadn't found it.
Isaac Vetter (Apr 10 2020 at 17:55):
Can anyone speak to the support of context-banner, context-style, context-standalone-patient, and context-standalone-encounter in off-the-shelf SMART servers, like Vonk, HAPI, Aidbox, WildFHIR, CareEvolution, others?
Isaac Vetter (Apr 10 2020 at 17:55):
@Michele Mottini - I'm consistently impressed with your encyclopedic knowledge, do you have a sense of this?
Michele Mottini (Apr 10 2020 at 18:15):
ah! not really - do not know about those off-the-shelf ones. Our server supports context-banner and context-standalone-patient and not the other ones. All US EHR server I know of (and that support SMART) supportcontext-standalone-patient, don't think they support context-standalone-encounter and don't know about style or banner.
Michele Mottini (Apr 10 2020 at 18:16):
(our server is not very much off-the-shelf, it runs only on top of our HIEBus HIE / data aggregation system)
Jenni Syed (Apr 10 2020 at 18:44):
Just for clarity, the ONC requires the standalone encounter and patient selection now for both provider and patient. I know many supported at least patient selection for patient, but maybe not provider
Isaac Vetter (Apr 10 2020 at 18:48):
Jenni - exactly. Michele, if you don't mind sharing, does your SMART server support context-standalone-patient for provider apps?
Michele Mottini (Apr 10 2020 at 19:06):
Sorry, forgot to specify: we support context-standalone-patient only for patient apps, not for providers (we do _not_ have a patient selector when you launch a stand-alone app with a user that is not a patient)
Isaac Vetter (Apr 15 2020 at 14:29):
Should HL7 create an "Additional (not core) capabilities" section in the SMART spec to accurately describe context-standalone-patient, context-standalone-encounter, context-style and context-banner and remove these capabilities from the list of core capabilities? Part of the problem here is that the naming of "Core Capabilities" was inaccurate, really, it's a full list of all capabilities in the specification.
Josh Mandel (Apr 15 2020 at 19:43):
I wouldn't mind labeling capabilities with a maturity of some kind -- though context-standalone-patient is more definitely Core. That's how basically every consumer app works, isn't it?
Josh Mandel (Apr 15 2020 at 19:44):
(Similarly, context-banner has been around since the beginning and is, I thought, widely supported)
Josh Mandel (Apr 15 2020 at 19:44):
Agree re: context-standalone-encounter and context-style.
Isaac Vetter (Apr 15 2020 at 21:47):
Hey Josh, context-standalone-patient (seems to) have no implementations for provider-facing apps ... but agree that it's a mature (and even core capability!) for patient apps. How about clarifying that it's a patient-facing app capability?
Isaac Vetter (Apr 15 2020 at 21:48):
in a similar vein, we should clarify that patient-banner only applies to EHR launchs.
Jenni Syed (Apr 15 2020 at 21:53):
I don't think the core capability was intended to be just patient facing for the standalone patient (or encounter) workflows, and they definitely make sense for both. They may just have more "proof" for the patient workflow today
Jenni Syed (Apr 15 2020 at 21:54):
There are definitely differences in the way the patient selection list is presented to both users, but that's "outside the spec" :grinning:
Isaac Vetter (Apr 17 2020 at 22:44):
Intended by whom?
The HL7, technical, specification should actually describe capabilities that are core in its core capabilities, right?
Isnt is objectively reasonable for context-standalone-patient to not be in this list for provider apps and context-standalone-encounter for either?
Robert Scanlon (Apr 20 2020 at 18:50):
Since 'core' isn't defined in the technical specification and is sufficiently vague, it is hard to justify removing any of the capabilities from the list based on the meaning of the term 'core'. Core Capabilities is defined simply by the values it contains. I personally do think it is confusing, and would advocate removing 'core' until there is the need for such a concept. But since the ONC rule now uses that term it would probably be hard to remove.
Robert Scanlon (Apr 20 2020 at 18:58):
I think the most unusual 'core capability' is context-style, because it is marked as experimental, doesn't have wide adoption, and probably isn't useful in a standalone use case. Fortunately it doesn't seem hard for servers to implement in a minimal sense if required.
Mikael Rinnetmäki (Apr 24 2020 at 16:09):
Would there be interest in having a small track on the upcoming online FHIR Connectathon, to gain visibility on
a) which SMART features have been implemented
b) is there a need to evolve the specification on things like styles?
Mikael Rinnetmäki (Apr 24 2020 at 16:10):
I could volunteer to get my feet wet in Connectathon activity and host the track, if there is indication of interest in participation. Especially from systems vendors.
Last updated: Apr 12 2022 at 19:14 UTC
