Stream: smart
Topic: Data conformance
Dave Carlson (Mar 07 2016 at 20:11):
While testing a client application, I get a warning when parsing Condition resources returned by SMART dtsu2 server: WARNING: Expecting nonoptional JSON property “verificationStatus” but it is missing
Josh Mandel (Mar 07 2016 at 20:57):
Thanks @Dave Carlson! And we had the clinicalStatus
wrong too. I've updated our sample data. We'll need to reload into our sandbox before you see the change.
Dave Carlson (Mar 07 2016 at 21:05):
Thanks Josh!
Josh Mandel (Mar 09 2016 at 23:03):
Sure thing. Updates are now available in our sandbox, by the way.
David Hay (Mar 10 2016 at 16:46):
does SMART use the DAF FHIR profile? This link suggests a simpler one...
David Hay (Mar 10 2016 at 16:49):
And do you plan to separate the authentication side of SMART from the FHIR Profile? The SMART connectathon track in May suggests that there could be a way for a SMART client to request a specific profile...
Josh Mandel (Mar 10 2016 at 17:13):
We aim to use DAF, yes. Some details still to be worked out (as we note on the page you linked to).
Josh Mandel (Mar 10 2016 at 17:15):
And yes, we've had interest in different data profiles (e.g. in different countries). @Lloyd McKenzie has actually shared a draft pack of profiles for Canada. So in brief: yes, the idea is a server can declare which "SMART Profile Pack" (or somesuch) it supports via Conformance.profile
. And the security protocols remain the same.
David Hay (Mar 10 2016 at 18:43):
excellent!
David Hay (Mar 18 2016 at 01:25):
Can I get clarification on what this statement (from the spec) means: DAF Responders who do not have the capability to store or return a data element tagged as Supported in DAF profiles can still claim conformance to the DAF profiles using the DAF conformance resources.
It seems to suggest that a server can still claim conformance to DAF, even if the server only supports a subset of DAF? Is 'profile' in this context actually 'Implementation guide'?
David Hay (Mar 18 2016 at 01:25):
and would the statement "SMART Profile Pack" actually be an Implementation Guide?
Grahame Grieve (Mar 18 2016 at 01:26):
I think it means that 'must-support' doesn't mean anything
David Hay (Mar 18 2016 at 01:29):
:)
Josh Mandel (Mar 18 2016 at 01:43):
Yes, "Profile Pack" sounds just like an implementation guide. Just my colorful language that I must have come up with before Implementation Guides existed (although I documented that long *after* they existed).
David Hay (Mar 18 2016 at 02:34):
Oh, I don't know. 'Profile Pack' kind of rolls off the tongue...
So we'd have a 'core' SMART spec which is the security/launching stuff (including scope) and then the ability for the client to indicate what IG's it needs, and the server to indicate what IG's it supports - either from the conformance resource, or maybe part of the scope?
In fact, presumably this could also operate at the profile (StructureDefinition) level - a simple client may only need a couple of resources...
Josh Mandel (Mar 18 2016 at 03:25):
Yes, that's about right I think.
Last updated: Apr 12 2022 at 19:14 UTC