Stream: conformance
Topic: Specifying a client CapabilityStatement
John Moehrke (Dec 04 2017 at 19:59):
I am working on the conformance resources for some IHE profiles. How do I specify that a Client Actor (CapabilityStatement.kind = requirements) ( a ) shall use X query parameter, and ( b ) may use Y query parameters, while ( c ) should not use Z parameters (or can use them but with no expectation of compliance to the IG/profile)? It seems there is only a way to specify rest.resource.searchParam that are supported. Where is is not clear if supported means shall, may, should-not?
Eric Haas (Dec 05 2017 at 03:08):
Check the extensions here:http://build.fhir.org/capabilitystatement-profiles.html
John Moehrke (Dec 05 2017 at 13:15):
What I am trying to specify is not as complex as combinations. It is possible don't understand the combinations extension. Further, this is a concept that IHE finds needed in all profiles, so I hope it is no relegated to an extension.
John Moehrke (Dec 05 2017 at 13:46):
Ah, I didn't notice the 'expectation' extension..This does seem what I want... I still assert this should be core not extension as it is necessary in .kind=requirements.... http://build.fhir.org/valueset-conformance-expectation.html
John Moehrke (Dec 05 2017 at 13:48):
for example when defining a client actor in an IG, one will say that ithey are allowed to use any of the defined query parameters; but they are not required to use them.
John Moehrke (Dec 05 2017 at 13:49):
also missing, how do I indicate that ANY other parameter is allowed? Or that ANY other parameter is forbidden?
Eric Haas (Dec 05 2017 at 15:35):
My take on this is that this extension is more for the standards side and not necessarily needed for servers declaring there caps in the field - hence an extension.
John Moehrke (Dec 05 2017 at 15:39):
I would agree at it is not very useful for operational. But if we put all elements that were needed only in one .kind; then we would remove a large number of operational items that are not needed in requirements kind. The rules of inclusion in core need to be consistent. Is it possible that using the same resource definition for the three .kind of use-cases is not optimal?
Eric Haas (Dec 05 2017 at 15:43):
Its also a place I find extensions handy since you can insert them in many placed without have to repeat the inline element in a half a dozen spots.
Eric Haas (Dec 05 2017 at 15:43):
..so I would recommend keeping on extension island...
John Moehrke (Dec 05 2017 at 15:45):
I noticed that benefit... useful indeed... but then begs the question of if something like that could be done using something less clumsy than an extension...... I am glad that I can do what I need to do... just would like R4 to be a bit less difficult
John Moehrke (Dec 12 2017 at 17:50):
Can I see a sample where someone has used his CapabilityStatement-Expectation extension in a CapabilityStatement? @Eric Haas ?
Eric Haas (Dec 12 2017 at 18:58):
http://hl7.org/fhir/us/core/CapabilityStatement-client.html
Last updated: Apr 12 2022 at 19:14 UTC
