Stream: argonaut
Topic: How do servers 'claim conformance' to a profile?
Robert Scanlon (Oct 15 2019 at 19:10):
Is there a computable statement somewhere (e.g. CapabilityStatement.rest.resource.profile / supportedProfile) that SHALL be returned by responders so that requesters know which profiles are supported? Those elements are SHOULD in the base spec. This is mainly an issue for those resources that have multiple US Core profiles.
Eric Haas (Oct 15 2019 at 19:39):
I would expect a Responder to list the profiles that they support:
Eric Haas (Oct 15 2019 at 19:42):
...
"type" : "AllergyIntolerance",
"supportedProfile" : [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance"
],
....
Lloyd McKenzie (Oct 15 2019 at 19:44):
What do you mean by 'support'? Do you mean they'll accept the data? Actually store the data? Be able to search by the profile if you happen to declare the profile in the instance? Generally a server just declares which elements it allows and supports. That declaration may be conformant with a variety of profiles, but there's no specific way to declare that right now.
Eric Haas (Oct 15 2019 at 19:46):
(deleted)
Eric Haas (Oct 15 2019 at 19:48):
I see what you are saying. @Robert Scanlon We don't say anything about requiring discovery of the supported profiles via the Capability Statement.
Eric Haas (Oct 15 2019 at 19:51):
at least explicitly...
Robert Scanlon (Oct 15 2019 at 19:52):
Are you responding to my original question or Lloyd on that "I see what you are saying". (edit: clarified, thanks)
Stephen MacVicar (Oct 15 2019 at 19:52):
Yes, https://build.fhir.org/ig/HL7/US-Core-R4/CapabilityStatement-us-core-server.html#behavior says that the server SHALL "Support the US Core Patient resource profile" (and one other), but the profile/supportedProfile fields are not required in the CapabilityStatement, so it's not clear how it is possible to verify that a server supports those profiles.
The base FHIR spec only says that servers "SHOULD also specify profiles for each resource type." https://www.hl7.org/fhir/capabilitystatement.html#notes
Michele Mottini (Oct 15 2019 at 19:58):
What would a client do with that information?
Eric Haas (Oct 15 2019 at 19:59):
a client could discover what it can query for. Otherwise they just query anyway and figure it out pretty quickly. for testers is a bigger deal.
Robert Scanlon (Oct 15 2019 at 20:10):
Yeah I'm just coming at it from a conformance perspective, and it seemed odd that the server doesn't really "claim" to support a profile, you just have to see what it sends back. Good point regarding value to the client.
Robert Scanlon (Oct 15 2019 at 20:11):
Thanks for the clarification :thumbs_up:
Michele Mottini (Oct 15 2019 at 20:12):
You just have to see what it sends back anyway - I've yet to connect to production servers that do not have some kind of problems in at least some of the returned resources - regardless of what they claim in the conformance (including our own server)
Robert Scanlon (Oct 17 2019 at 20:10):
A follow up conformance question for @Eric Haas -- is it ok to just support Patient + Provenance profiles here to meet the 'Patient + 1 requirement"? Unless I'm missing something it seems the answer is "yes" (though a server just supporting those two wouldn't be particularly useful). https://build.fhir.org/ig/HL7/US-Core-R4/CapabilityStatement-us-core-server.html#behavior
Eric Haas (Oct 17 2019 at 20:28):
Yes that is what is written, its an editorial oversight but so is Medication+Patient ... practically speaking, both of those combinations are pretty useless
Robert Scanlon (Oct 17 2019 at 20:52):
Understood, thanks for the confirmation.
Last updated: Apr 12 2022 at 19:14 UTC
