Stream: conformance
Topic: CapabilityStatement.rest.resource
Michel Rutten (May 13 2018 at 12:54):
Concerning the CapabilityStatement.rest.resource element:
http://hl7.org/fhir/capabilitystatement-definitions.html#CapabilityStatement.rest.resource
The element description in the spec says: "Max of one repetition per resource type."
Is this correct?
I always assumed that a server can advertise e.g. different profiles for receiving and sending.
Michael Donnelly (May 13 2018 at 14:21):
I'd had a hunch that it worked the way you think, but I never dug into it before now.
Grahame Grieve (May 13 2018 at 14:22):
no one profile for both - separateing sending/receiving is in the messaging space
Lloyd McKenzie (May 13 2018 at 14:25):
Actually, it's not. There's a separate repetition of "rest" for sending vs. receiving. So you can have a profile for each resource within that.
Michael Donnelly (May 13 2018 at 14:27):
Is that the mode element, Lloyd?
Michael Donnelly (May 13 2018 at 14:27):
Or interaction?
Grahame Grieve (May 13 2018 at 14:28):
uh? it's for client / server not sending / receiving
Michael Donnelly (May 13 2018 at 14:28):
Yeah, I can't figure out where one would specify sending vs receiving for a server.
Michael Donnelly (May 13 2018 at 14:29):
The name sounds good for interaction, but the values for it don't make sense.
Lloyd McKenzie (May 13 2018 at 14:40):
Yes, you're right. It's not sending vs. receiving. It's "when you make requests" vs. "when you receive requests". There's no differentiation about what an inbound request needs to look like vs. what a response looks like for a server (or what an outbound request looks like vs. what an inbound response needs to look like for a client)
Lloyd McKenzie (May 13 2018 at 14:40):
Sorry for misleading.
Lloyd McKenzie (May 13 2018 at 14:40):
I can potentially see utility in having that differentiation though
Michael Donnelly (May 13 2018 at 14:41):
We do too. :)
Dennis Patterson (May 13 2018 at 14:41):
We're discussing use-cases for DocumentReference creation where, for example, a FHIR server would only accept text input, but would return html when that document is retrieved.
Dennis Patterson (May 13 2018 at 14:42):
...and trying to determine how that would be represented in conformance
Brett Marquard (May 13 2018 at 14:42):
When can we discuss with FHIR-I, we are creating a presentation for you
Dennis Patterson (May 13 2018 at 14:42):
Ideally, systems can return the format that was provided at input, but both Cerner and Epic are systems where that isn't the case
Grahame Grieve (May 13 2018 at 15:13):
@Brett Marquard what about?
Brett Marquard (May 13 2018 at 15:14):
Ability to advertise different profiles for sending/receiving.
Brett Marquard (May 13 2018 at 15:15):
although specific interest is a different value set for one element in a resource.
Michel Rutten (May 13 2018 at 15:15):
I also remember a (theoretical?) use case once mentioned by Grahame a while ago where a server would use "lenient/forgiving" profiles on the receiving side and "strict" profiles on the sending side.
A little bit like HTML5 rendering is defined.
Grahame Grieve (May 13 2018 at 15:39):
postel's law
Michel Rutten (May 13 2018 at 15:43):
I like that approach.
John Moehrke (May 13 2018 at 16:18):
I am an advocate for Postel's Law.. It is in my email signature.... but, I think that Postel's law in the discussion we are having is that the CapabilityStatement would indicate the strict StructureDefinitions I expect YOU to use when communicating with me, but I have actually installed validation that is more robust with strict rules only where I need strict rules, lenient rules where I can tolerate it. So I would advertise in my CapabilityStatement that I am strict,...
Last updated: Apr 12 2022 at 19:14 UTC
