Stream: implementers
Topic: FHIR Conformance and Compatibility Statements
Mario Hyland (Dec 25 2016 at 00:03):
Over the next few weeks we will are working with a number of FHIR Implementers to address issues with their Server Conformance and Compatibility statements - anyone wishing to participate please let either myself of Richard Ettema know.
Mario Hyland (Dec 25 2016 at 00:09):
Question: Can someone explain to me the Conformance Resource element "kind" - what is it purpose (yes, I have read the FHIR web site and the Content Logical Definition) - Does anyone have a write up explaining how it is used - sender/receiver? I currently see a variety of values (is there a code-value list anywhere or are the three values the entire list (values I have seen "capability", "instance", I have yet to locate anyone using "requirements"). Note a number of Public FHIR Implementations are missing the "kind" from their conformance statements. Appreciate learning more on this item.
Mario Hyland (Dec 25 2016 at 00:14):
Question: During the last HL7 FHIR Connectathon and after party events - we were discussion the need for FHIR Clients to publish or post a Conformance or Compatibility Statement; Is anyone currently developing a FHIR Client who is (or plans to) publish a FHIR Conformance or Compatibility Statement as a client for a FHIR Server to locate and interogate?
Mario Hyland (Dec 25 2016 at 00:19):
Question: Are any FHIR Server implementations currently interrogating (or have plans in the future) inbound FHIR requests to ensure the client (or server) making the request are compatible with the response message about to be generated? Example, if you expose a FHIR 1.4.0 End-point (with a FHIR Conformance Statement, which identifies your server as 1.4.0) - do you worry or evaluate the requestor to ensure they are a either a 1.4.0 client or 1.4.0 server? How would your server act/respond if say a FHIR Client with 1.8.0 made a request (we know depending on the resource their could be breaking changes)? Thoughts or ideas?
Grahame Grieve (Dec 25 2016 at 20:33):
how could a server interrogate a client conformance statement?
Grahame Grieve (Dec 25 2016 at 20:34):
kind is basically redundant with software and implementations - for making invaraints
Grahame Grieve (Dec 25 2016 at 20:35):
I will participate with testing around conformance
Lloyd McKenzie (Dec 26 2016 at 03:30):
Requirements is what we use for all of the conformance statements defined in IGs - it sets out what systems should do rather than what a particular system does do
gulraiz joyia (Jan 05 2017 at 11:46):
Sir I want to write code for hl7 - ADT - A03, with HAPI-FHIR, Can any buddy help me!
Simone Heckmann (Jan 05 2017 at 13:30):
@gulraiz joyia : Please refer to our guidelines on how to ask: http://wiki.hl7.org/index.php?title=FHIR_Rules_for_asking_questions
Theo Stolker (Apr 21 2017 at 07:16):
Hi there, we have a use case in which the capabilities available to one user might be different from another user. In this case, some patients are welcome to submit self-measurements because they participate in a certain chronic disease program, while other patients aren't supposed to send in these self-measurements.
I understand the Capability Statement explains what an application type or instance supports, and that the above could be viewed more of an authorization thing, and we could have the server remove scopes that aren't valid for a user during the Authorization flow. However, the Capability statement seems like a great way to express also the capabilities a specific user is authorized for.
Any ideas on how to deal with this use case?
Grahame Grieve (Apr 21 2017 at 07:27):
my server will return a different CapabilityStatement if a user is logged in than if they aren't
Theo Stolker (Apr 21 2017 at 07:31):
Hi Grahame, that makes perfect sense, thanks as always for the quick turnaround :)
Grahame Grieve (Apr 21 2017 at 07:34):
np
David Hay (Apr 21 2017 at 07:53):
I never appreciated that the CapabilityStatement could be user dependant...
Lloyd McKenzie (Apr 21 2017 at 08:03):
It's probably a good idea for us to make that explicit. Otherwise a system might query it with one user and presume it'll be the same for everyone else and not bother re-querying. Or query without a logged on user and presume that reflects the set of capabilities it will always have.
Theo Stolker (Apr 21 2017 at 08:28):
Lloyd, David, Please read my orginal question. You may not "like" it that the CapabilityStatement is also used to reflect user-specific capabilities, but we have the use cases that require it. Please do not dismiss this use case to quickly.
John Moehrke (Apr 21 2017 at 12:56):
We should not confuse Capabilities, with Rights. A server may have capabilities that are not allowed to all users, all workflows, or against all patients. These deviations are driven by Privacy (consent), Security (RBAC), or other business rules (workflows). One should not expect that all capabilities published are allowed.
John Moehrke (Apr 21 2017 at 12:59):
I think @Grahame Grieve concept of customizing the capabilities based on the user is interesting, and would not discourage it. However it is not a general solution to the problem, it just helps subset. It does enable apps to better predict what might succeed, or more specifically what is clearly not going to succeed. The apps need to be robust to the facts of being denied an activity.
Lloyd McKenzie (Apr 21 2017 at 15:10):
@Theo Stolker I wasn't dismissing the use-case, just saying that we should document that that's permitted behavior so people are aware.
Michele Mottini (Apr 21 2017 at 18:18):
Our server can disable access to certain resources based on user permissions, and I was about to reflect that in the capability statement but then I decided against it: the capability is the only resource that can be accessed without having to login - and in that case you do not know which user to use to customize the response, so the server would end up sending different responses to the client before and after login.
Michele Mottini (Apr 21 2017 at 18:19):
Considering this problem I think it won't be a good idea to allow different capability statements depending on the user
Grahame Grieve (Apr 21 2017 at 20:32):
There was a presentation last year at devdays about someone who puts up workflow specific end-points so that they can provide capability statements specific to the work flow.
Grahame Grieve (Apr 21 2017 at 20:32):
e.g. an endpoint specific to a user/appointment combination
Theo Stolker (Apr 23 2017 at 15:17):
@Lloyd McKenzie , thanks, I misunderstood what you said. Documenting this sounds like a great plan!
Lloyd McKenzie (Apr 23 2017 at 15:27):
@Theo Stolker Care to submit a change request? :)
Pascal Pfiffner (Apr 24 2017 at 17:56):
The need to fetch /metadata to get at the auth URLs, login and then fetch /metadata again is the flip side of this coin, though.
Grahame Grieve (Apr 24 2017 at 18:53):
yes. but how else could it be?
Brian Postlethwaite (Apr 26 2017 at 21:18):
This one does hit my sore point with _summary and extensions not being in there, as the SMART security values are in extensions, and thus you need to grab the (sometimes very large) capabilitystatement.
Lloyd McKenzie (Apr 26 2017 at 23:47):
So your proposal would be for an extension to be able to define whether it should appear in a summary?
Brian Postlethwaite (Apr 27 2017 at 01:01):
I don't know, just this one with security bothers me.
John Moehrke (Apr 27 2017 at 12:02):
as we bring SMART into FHIR, we should think throgh this. Might be good to have a standalone resource for these things.
John Moehrke (Apr 27 2017 at 12:05):
my understanding is that _summary is not intended to be used for low bandwidth use, so much as to support when many results are returned for the purpose of displaying choices to users. Thus the _summary items might not be picked for technical usefulness, but more for UI usefulness. These are two different purposes, do we need a counter to _summary for requesting all the most important technical bits and non of the UI bits? It isn't exactly the inverse of _summary as there would be overlap in some cases, and missing items from both sets.
Mario Hyland (Apr 29 2017 at 15:47):
To circle back to the original question - "should a FHIR Server vary its capabilityStatement based on User Rights and Security?" - I am inclinded to disagree. As I read the FHIR specifications today, the CapabilityStatement is provided to establish what the Server is "capable" of doing. Sure in simple use cases Client to Server we can see benefits to customizing the CapabilityStatements, sure even I can see value here. But, wider FHIR implemetations server-to-server and Micro-Service, and ESB/SOA I could see Server-to-Server FHIR exchanges happening where the user initiating the request could change with each request. I would recommend we think on this bit more. Would like to hear from a few more Enterprise Integration folks. Good idea, and worth further discussions.
Lloyd McKenzie (Apr 29 2017 at 23:15):
I think there's utility for both. Sometimes a client wants to know what a system can do in general. Other times, it only matters what the user can do. So having different behaviors when there's a user id indicated vs. not seems appropriate - so long as we document this behavior.
Pascal Pfiffner (Apr 30 2017 at 20:07):
Agree with Brian and John that there may be desire to use _summary for what it wasn't designed to be. Even the most basic SMART on FHIR clients will always need to fetch the capability statement only to get at the auth URLs, they usually don't inspect anything else in there, issuing pre-programmed REST requests. That's 2+ MB of data just for three URLs. There should be a better way, maybe even a new resource dedicated to auth and available from /auth or similar. As a side effect this would obviate the need to double-fetch the capability statement and could uncouple capabilities independent of the user from capabilities dependent on the user.
Josh Mandel (Apr 30 2017 at 20:27):
I'd be happy to explore developing an approach for this kind of information! @Pascal Pfiffner do you prefer the idea of a new resource, vs a top level property on the CapabilityStatement to list auth details? (Top level seems important to support something like &elements=auth -- but given that many servers won't support all that fancy element subselection stuff, a separate resource has its appeal. On that subject, do most servers support the summary concept?)
Pascal Pfiffner (May 01 2017 at 02:28):
My thought would have been that _summary is a good solution to this problem, provided auth details move from extension to their own element, but @John Moehrke points out that this isn't the intention of _summary. I also don't know the level of support for summaries, except that most DSTU-2 servers haven't supported it because our Swift and Python clients would otherwise not have worked (they used to only request the summary conformance). :)
I never realized that a different capability statement may be returned based on who is logged in. I can see that there is appeal in this even when it's conflating capabilities and rights. I feel it would be cleaner if parts that change and parts that don't change – depending on user/system – would live in separate resources, but then I would also expect /metadata to serve what's user independent and something like /capabilities to serve what may depend on the user. Maybe we are too late for a clean separation, i.e. a two resource solution?
Grahame Grieve (May 01 2017 at 06:06):
so there's a few different issues at play here. One is how to retrieve a subset that includes the smart on fhir extensions (my server has those extensions as a special case). Another is whether the capabilities is limited per user. What we can say for sure is that the capabilities the server offers may not all be accessible depending on the user's context and rights
Lloyd McKenzie (May 01 2017 at 16:37):
A third is whether there's utility to identifying certain extensions as appropriate to include in summaries
Pascal Pfiffner (May 01 2017 at 16:51):
I think there's agreement that the current approach is not ideal for the use-case where a client or service needs to discover auth methods and endpoints before looking at capabilities – which I'm assuming to become a default behavior for traditional client-server setups, certainly on the app level.
If we ensure that all necessary auth information is returned when reading the capability statement as a _summary_ (and that it's otherwise lightweight, i.e. the summary resource is much shorter than the full resource) we can improve this workflow with what we already have at our disposal. If servers don't support _summary, we'll be transporting waste but nothing breaks. I'm a little less optimistic about implementers properly including necessary extensions in summaries.
But I'm starting to think that introduction of a resource pertaining to auth only and to make it available from /auth or similar would be worthwhile. It would be cleanly separated from context-dependent capabilities, timing is not bad now that we're bringing SMART in (because it informs the resource, not because it is FOR SMART) and FHIR would still be auth-agnostic, but have the necessary hooks.
Elliot Silver (May 01 2017 at 16:58):
I'm going to add another twist that I think there is an occassional need to differentiate between what a system can do and what it is currently configured to do.
Grahame Grieve (May 01 2017 at 21:06):
does it need to be a resource? COuld just be a json fragment like the well-known stuff - not everything has to be a resource.
Eric Haas (May 01 2017 at 22:16):
"well-known stuff"? can you clarify what you mean?
Pascal Pfiffner (May 01 2017 at 22:37):
@Eric Haas it's a concept used by e.g. OpenID: https://tools.ietf.org/html/rfc5785 , JSON "resources" that live at well-known, e.g. .../.well-known/openid-configuration
Pascal Pfiffner (May 01 2017 at 22:38):
So yes, using well-known would also work for this purpose.
Brian Postlethwaite (May 03 2017 at 03:40):
I like this suggestion too.
Jenni Syed (May 06 2017 at 14:21):
... the "what the user can do" could start to delve into the HATEOS portion of rest, depending on how nitty-gritty this is getting. I feel like a static resource for that specific scenario won't really work for user-specific privs
Jenni Syed (May 06 2017 at 14:22):
I know there have been some passionate disscussions of HATEOS
Jenni Syed (May 06 2017 at 14:22):
But when you start getting into the "this user can't modify a control X med", it will start to be resource instance by resource instance
Jenni Syed (May 06 2017 at 14:24):
We flex our confomrance based on user type right now. But to the outside world, those look like different servers (different FQDN)
Jenni Syed (May 06 2017 at 14:25):
we do not currently flex it user by user - they would get 403/forbidden if they tried to do something they shouldn't. But the app wouldn't know to flex UI so that they can't even see/access features they can't use.
Chris Grenz (May 08 2017 at 08:35):
+1 to Jenni's comment on resource instance by instance - I'd extend that to element by element within the resources. It is very difficult (impractically so) to design an app with a reasonable user interface when the client can't discover what instances and/or elements the server will communicate. + all the stuff above.
Josh Mandel (May 08 2017 at 08:46):
So an easy thing we could for SMART discovery would be to define [fhir-base]/.well-knwon/smart-configuration as returning a JSON document with the OAuth and OIDC and SMART capability basics. We'd probably want to retain our existing extensions in CapabilityStatement for backwards compatibility (but we could avoid creating a whole bunch more).
Chris Grenz (May 08 2017 at 09:28):
I think we're shooting ourselves in the foot by not assuming a large future set of capabilities and discovery needs. For instance, a set of analytics capabilities. IMO, it would be prudent to abstract the concept of a capability with a unique URI for each (probably a Capability resource). Effectively a triple-store, this would allow:
- A specification of any current, future, localized, etc. capabilities (e.g. SMART)
- A complete listing of capabilities (as is possible now)
- Definition of packages of capabilities (possible now only for known capabilities) that could be published as well-known or common capability sets.
- Client interrogation of known or future capabilities individually or as a set (via ReST or operations) by URI
This could also better cover the overlap of content vs. API capabilities.
Last updated: Apr 12 2022 at 19:14 UTC
