Stream: smart
Topic: launch-ehr
Grahame Grieve (Oct 08 2018 at 21:11):
The smart spec say that you must include launch-ehr in your core capabilities. This means that an 'headless' EHR that doesn't include a UI interface can't be conformant to SMART App Launch - is that what is intended?
Grahame Grieve (Oct 08 2018 at 21:12):
same for the context-* capabilities... bizarre....
Josh Mandel (Oct 08 2018 at 21:24):
Can you point out where? This doesn't sound like it matches our intent.
Josh Mandel (Oct 08 2018 at 21:24):
(or our ballot resolutions)
Grahame Grieve (Oct 08 2018 at 21:28):
where what?
Grahame Grieve (Oct 08 2018 at 21:34):
http://www.hl7.org/fhir/smart-app-launch/conformance/core-set/
Grahame Grieve (Oct 08 2018 at 21:34):
"To be conformant with SMART on FHIR’s Core Capabilities, an EHR must support the following capabilities"
Josh Mandel (Oct 08 2018 at 21:58):
That's a holdover then -- need to cut it to match our resolution.
Josh Mandel (Oct 08 2018 at 21:59):
But wait, that link was to the pre ballot spec
Josh Mandel (Oct 08 2018 at 21:59):
http://build.fhir.org/ig/HL7/smart-app-launch/conformance/index.html is the result
Grahame Grieve (Oct 08 2018 at 22:40):
ok. that makes sense and this looks better. @Robert Scanlon what's the version policy for inferno?
Grahame Grieve (Oct 08 2018 at 22:41):
as in, what version of the SMART App Launch spec are you (supposed to be) based on?
Robert Scanlon (Oct 09 2018 at 03:27):
Inferno is based on the pre-balloted version right now. It seems to make sense to update Inferno to the balloted version, but I don't have a definitive answer at the moment. @Josh Mandel do you know when it will be finalized?
Grahame Grieve (Oct 09 2018 at 03:44):
well, what are you testing against? Since both the pre-ballot version and the candidate version both post-date argonaut implementation by a long time, don't you have to test what the argonaut spec asked for?
Robert Scanlon (Oct 09 2018 at 03:56):
We are testing this: http://www.fhir.org/guides/argonaut/r2/ which points to the SMART on FHIR Authorization Guide, which is a dead link but presumably it now lives at http://docs.smarthealthit.org/authorization/. From what I can tell, that is the same as http://www.hl7.org/fhir/smart-app-launch/.
Josh Mandel (Oct 09 2018 at 13:11):
It's close, minus the fine grained "capabilities" -- but the target spec should be our 1.0.0 publication, which we still need to get approved/published. It will eventually live at http://www.hl7.org/fhir/smart-app-launch but is currently at http://build.fhir.org/ig/HL7/smart-app-launch . It's designed for backwards compatibility, but we alias "fhirUser" to the OIDC "profile" claim, and we clarify what's expected in OIDC; and we add a JSON discovery document endpoint.
Robert Scanlon (Oct 09 2018 at 13:23):
Right, fhirUser and .well-known are the two things that I earmarked for further thought. They are technically easy to test, but it is unclear to me what should be required, and what is considered 'optional'. In the short term I was thinking of just adding these as 'optional'.
Josh Mandel (Oct 09 2018 at 13:26):
Ideally the capabilities framework would give you a way to drive some more specific testing in groups by use case, and by discrete capability. So: at least systems advertising the sso capability should support fhirUser.
Josh Mandel (Oct 09 2018 at 13:26):
Overall though: optional makes sense (outside of a specific advertised capability)
Robert Scanlon (Oct 09 2018 at 13:29):
Right, if it is advertised it shouldn't be optional
Robert Scanlon (Oct 09 2018 at 13:30):
but a server that does 'profile openid' instead of 'fhirUser openid' wouldn't qualify as supporting the sso capability?
Josh Mandel (Oct 09 2018 at 13:30):
Right -- should support a request with the fhirUser scope and a response with the fhirUser claim.
Robert Scanlon (Oct 09 2018 at 13:33):
Was smart capability advertisement removed altogether from the server conformance/capability statement or is it like the oauth endpoints where it is recommended you move them to the json discovery document?
Josh Mandel (Oct 09 2018 at 13:42):
We say: do both. And plan to remove the /metadata in a future version.
Robert Scanlon (Oct 09 2018 at 15:02):
Ok, so 'backwards compatibility' is very much about client backwards compatibility, and not server backwards compatibility? If so, great!
Josh Mandel (Oct 11 2018 at 12:21):
Correct, re: fhirUser data.
Last updated: Apr 12 2022 at 19:14 UTC
